Tag: SL Issues

Update, March 21st: AMD have release a new set of Catalyst™ drivers, version 15.3 beta, which include a potential fix for the rigged mesh issues, negating the need for this workaround – see my notes here.

Update, Sunday, December 14th: user DMC Jurassic reports that the process outlined below can also be used with the OpenGL .DLL files from the AMD Catalyst 14.4 drivers. However, no ZIP file of the extracted DLLs are currently available, so Yoho’s notes at the end of the article will need to be followed to obtain them.

Also note that Singularity have issued a supplemental update to address mesh rendering issues.

On Tuesday, December 9th, I blogged about the continuing issues impacting  those with AMD GPUs using the latest Catalyst and Omega drivers.

Second Life resident, and contributor to this blog, Yoho Waco offered a workaround to the problem for Windows users who would prefer to use the latest Catalyst drivers, rather than rolling back to an earlier version.

The workaround should fix the mesh rendering issue, and while Yoho uses Windows 7 64-bit, the basic approach should work with all flavours of support windows, 64-bit and 32-bit.

I can’t actually test it myself, as I use Nvidia, but feedback indicates it works well, and so with Yoho’s permission, I’m reprinting his instructions here so that it might get broader visibility.

As many have pointed out, the issue lies in the fact that the more recent Catalyst drivers use a late version of OpenGL that is supported by SL. This being the case, Yoho provides instruction on using an earlier version of OpenGL with the more recent drivers:

It seems that the problem is in the OpenGL version has the new driver 14.12.

I tried a small solution is to take the DLL’s from version 14.9 and place them inside the folder .\SecondLifeViewer

It works perfectly, no problems or fall FPS.

Yoho provides the required files in a  ZIP file users can download – just copy them to your viewer’s installation folder, as he notes above.

Note that if you’re using a viewer other than the official SL viewer, you’ll need to drop the files into the relevant installation folder, rather than .\SecondLifeViewer (e.g. in the case of Windows 64-bit, instead of dropping the files into C:\Program Files\SecondLifeViewer, you would  place them in C:\Program Files\[name of your viewer]).

Commenting to me about the fix, Yoho said:

I had to install version 14.9 on my computer and search for the files inside C:\Windows\System & C:\Windows\System32. Once copied, I completely uninstalled the version of the Catalyst 14.9 drivers and reinstalled the new version 14.12 Omega drivers. I used and application called DDU, as  it is best to fully uninstall a driver to avoid conflicts. However, this is all very complicated, so I published my DLLs [in the dropbox link above] so users can access them and copy them to their viewer.

Do note that this workaround won’t solve the shadows issues which occur with the Catalyst 14.9.x drivers (see BUG-7947 and BUG-7627), however, Yoho informs me that when he has the time, he may try to see if he can use the OpenGL DLLs from the 14.4 drivers to see if they can be used in this approach to resolve issues, both with mesh rendering and with shadows.

In the meantime, those who would prefer to use the latest drivers and have tried this approach state it works, but as always, your mileage may vary, and the workaround is offered without liability or responsibility on either Yoho’s or my part.

My thanks to Yoho for his work in this and notifying me.

Firestorm users: don’t miss my review of the 4.6.9 release.

Update, March 21st: AMD have release a new set of Catalyst™ drivers, version 15.3 beta, which include a potential fix for the rigged mesh issues – see my notes here.

Update, February 28th: Singularity have issued a supplemental update to address mesh rendering issues.

Update, December 13th: Yoho Waco offers a work-around for this problem – see his comment following his article. As an Nvidia user, I cannot test the workaround myself, but feedback indicates it works. I’ve also added Yoho’s workaround with additional information as an article in its own right.

Update: I have been informed (see the comment following this piece from JC de Bes, that this issue also extends to the most recent  Omega drivers release.

Whirly Fizzle dropped me a line concerning the latest AMD Catalyst™ drivers update, 14.12, which is apparently being pushed out by AMD via automatic update.

As those on systems using AMD graphics cards are likely to be aware, there have been ongoing issues with the Catalyst drivers which have impacted Second Life, notably with regards to rigged meshes which, since the deployment of the 14.9.2 drivers by AMD, cause rigged mesh to be invisible unless hardware skinning is disabled (see BUG-7653).

The 14.12 Catalyst™ drivers currently being deployed by AMD do not address this issue; worse, as it is being pushed via automatic update from AMD, it may see an increase in issues being experienced for anyone using an AMD GPU, regardless of the viewer they are using, and even if they have recently rolled back to an earlier version of the driver.

The two ways of dealing with the problem / avoiding it, are to:

• Either turn off hardware skinning off in the viewer (Preferences > Graphics > uncheck Hardware skinning), which is hardly ideal, or
• Roll back to pre-14.9.2 Catalyst drivers via the AMD download site. Those affected should consider using (at the latest in terms of release numbers) version 14.9.1 – but be aware this driver has issues of its own (see BUG-7947 and BUG-7627). Therefore, the 14.4 drivers might be a better option.

Uninstalling  the current AMD video drivers may be warranted prior to installing older drivers, and there is a request within the JIRA report linked-to above that those affected by the issue also raise a bug report directly with AMD to help bring this matter more to their attention.

On Wednesday October 15th, and as a result of the Padding Oracle On Downgraded Legacy Encryption (Poodle) vulnerability reported by Google, the Lab issued a Grid Status update, warning those who use the viewer’s built-in browser may not be able to access certain websites.

The update from the Lab reads in part:

[Posted 12:15 PM PDT, 15 October 2014] Residents may be unable to open certain websites using the viewers internal browser. This is due to a security related change made by many web sites in response to a vulnerability announced today by Google.  This issue will affect Media-on-a-Prim for those sites, and will block initial setup of some SLShare accounts.

You may be able to access those sites by setting your viewer to use an external browser: go to Me/Preferences/Setup and check “Use my browser (Chrome, Firefox, IE) for all links.

We are aware of the issue and working on a fix.

Unlike recent security vulnerabilities, like Heartbleed, Poodle targets the client-end of things. It does this by exploiting a flaw in the design of SSL 3.0 protocol, which despite being 18 years old, is used as a fallback security protocol within most browsers, including Chrome, Firefox and Internet Explorer. However, there are a couple of caveats to its effectiveness: for the attack to work, the attacker must be on the same wireless network as you (or in the path of your communications), and your client must be running JavaScript.

Essentially what happens is that the attacker initiates a series of connection failures between the browser and website, which in turn trigger what is called a “downgrade dance” where the browser eventually falls back to using the SSL 3.0 protocol to maintain communications. The attacker then uses the vulnerability within SSL 3.0 to grab sensitive data.

Because of its nature, and the fact that certain requirements must be met (as noted above) in order for it to work, Poodle is regarded as less far-reaching than something like Heartbleed. However, it has prompted Google to issue an advisory that websites disable SSL 3.0 support or that tools that support TLS_FALLBACK_SCSV (Transport Layer Security Signalling Cipher Suite Value) are used which prevent the “downgrade dance” attacks on services that can trigger the vulnerability. Google have also stated they plan to scrub SSL 3.0 support from its Chrome browser, and Mozilla are going to do the same with Firefox.

Related Links

• Viewer Issues with Loading Webpages – Linden Lab
• This POODLE bites: exploiting the SSL 3.0 fallback – Google
• POODLE Security Vulnerability Breaks SSLv3 Secure Browsing  – James Lyne, Forbes
• A Web encryption vulnerability opens ‘encrypted’ data to hackers – Roberto Baldwin, TNW