Jump to content

Shaders don't work in Linux with the open-source Radeon driver


Mircea Lobo
 Share

You are about to reply to a thread that has been inactive for 3788 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Although the SL viewer has been giving me issues since moving to Linux (on openSUSE 12.3 currently) I'm usually able to run it ok. I have an ATI Radeon HD 6870 card, and currently use the fglrx driver since the open-source Radeon driver has problems running some games. I tested SL on both fglrx and radeon, and performance is the same on either without major bugs. However, there's one issue which happens with the open-source driver; Shaders can't be enabled.

The "Shaders" checkbox in the video preferences menu isn't grayed out so I can turn it on. Once I enable shaders I can also enable the other individual effects (such as depth of field). However, no change is visible in the world after I click ok, although they're persisted in the menu. After I restart the viewer, I find the shader option turned off again.

This sounds like the viewer is unable to detect shader support under the open-source Radeon driver (works fine with fglrx, the proprietary ATI driver). I know the Radeon driver & mesa are capable of running any shader (possibly apart from some OpenGL 3.0 features) since I run Linux games with advanced graphics and all shaders worked fine.

I'm prolly not going to post this on Jira since even minor tickets take years to get noticed by Linden Lab, then a few more years to get solved. If someone else with more popularity there wants to post it in my place, that would be apperciated. Note that I'm staying on fglrx until the radeon driver fixes some problems, so I can only test again after my next distribution upgrade when I'll be trying the free driver again.

Link to comment
Share on other sites

  • 1 month later...

Mircea, I've spent a good 3 hours today hacking through a raft of LL shader compile issues I've encountered on Fedora 18 and 19 with Catalyst 13.4, 13.6-beta, and the radeon kernel driver.

 

I wrote up the following notes to remind myself what I might have to do each viewer upgrade, which may help you out too:

http://allenkerensky.com/shader_hacking

 

  1. Error 1: Uninitialized i in LIGHT_LOOP(i) function.
  2. Error 2: ukiOpen* function errors cause viewer to drop into "Indirect rendering" (and be basically unusable as it crashes
  3. Error 3: EXTENSION directive/keyword undefined
  4. Error 4: uniform float delta errors
  5. Error 5: __ only for reserved macros
Link to comment
Share on other sites

  • 4 months later...

I upgraded to openSUSE 13.1 yesterday, thanks to the software repositories which were made available earlier than the DVD release. With this upgrade, I dumped fglrx and let Linux switch to the Radeon driver with Mesa. I then ran Firestorm again to see how things go.

Sadly it's pretty bad. Absolutely no shaders seem to work at all. I can run SL fine and at optimal performance, but cannot enable any effects (not even glow). The "Basic shaders" preference can be ticked on, but does not persist a viewer restart.

I'm not going back to the proprietary driver, since it's very buggy in Linux and removing it was already a pain. I need a way to fix this and get shaders working with this setup. Mesa 9.2 supports openGL <= 3.1, so I'm confused why GLSL would fail so horribly.

Here is the console output the viewer prints when I'm already in-world and try to enable the shaders. What can I try?

Link to comment
Share on other sites

Sorry for posting so many times in a row... this thread is pretty inactive apart from myself. I spoke with the teams of components involved in the issue (X11, Mesa, Radeon) and they found a problem in the viewer's shaders. Apparently a statement is written incorrectly, and Mesa isn't meant to support that. Here is exactly the reply I got:

"According to the GLSL specification (1.30, page 14), #extension directives must come before any non-preprocessor tokens. These shaders are invalid and we correctly fail to compile them. So, this is a bug in the Second Life viewer. I would try filing a bug with them."

I posted the problem on Jira, and hope this is something Linden will get to soon. Also, here is my and another person's report filed for Mesa about the same problem (the last one has a lot more information):

https://jira.secondlife.com/browse/BUG-4451

https://bugs.freedesktop.org/show_bug.cgi?id=71591

https://bugs.freedesktop.org/show_bug.cgi?id=69226

In the meantime, does anyone know how I can manually repair these shaders until the viewer fixes them?

Link to comment
Share on other sites

Finally, I found a simple way to temporarily fix most of the shaders. I can now enable Basic Shaders followed by Atmospheric Shaders, but Advanced Lighting Model will still not work. Seemingly due to the same issue, but in a form that's not as easy to fix. I would be grateful if someone could use the knowledge I posted up to this point to figure out how to solve those as well.

What fixes the primary shaders is commenting out all #extension lines the from glsl files. To make it easy for everyone to apply the fix, I created a bash script that does it automatically. Create an empty file in SecondLife/app_settings/shaders and paste the code below inside, then save and execute it. Make sure to backup your shaders folder first, this will permanently edit your glsl files!

EDIT - I was able to fix the remaining shaders today. Their cause was different: Double underscores are not allowed in macro names under Mesa. The shader file class1/deferred/fxaaF.glsl contains multiple uses of this. I updated the script below to also correct this problem, and rename "__" to "_". At this point all shaders can be enabled, but there is graphical corruption which might or might not be related to the sloppy fixes I used here.

#!/bin/bash
# this script does a sloppy correction of Second Life shaders for Mesa compatibility
files=$(find ./* -type f -name *.glsl)
for f in ${files}
do
    echo "Fixing shader file ${f}"
    # #extension directives must come before any non-preprocessor tokens
    sed -i 's/#extension/\/\/ #extension/g' ${f}
    # macros may not containin two consecutive underscores
    sed -i 's/__/_/g' ${f}
done

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3788 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...