R500 Mesa Is Still No Match To An Old Catalyst Driver

[BlackStar]

Well i also like xbmc, now xbmc gained vaapi support too which is a good move. xbmc only uses opengl to render, but fglrx fails to use the auto mode which is usally the same as glsl renderer. nvidia cards have got no problems using glsl renderer.

9 times out of 10 this is caused by stupid developers using Cg syntax in GLSL shaders. I can't be bothered to go through XBMC's shaders right now but I'm willing to bet on this.

AMD's drivers may have tons of bugs but their shader compiler is reliable and strict. Nvidia's compiler, on the other hand, is a weird half-breed that accepts illegal HLSL/Cg syntax unless explicitly told not to. Add the fact that most developers are clueless and the result is a compatibility shitstorm on the users' backs - or ugly vendor lock-in, depending on how you look at it.

Mesa will also pay the price once the next round of distros picks GLSL support.

[Kano]

Well i think ATI cards are not really common for xbmc dev, even VAAPI support is developed with NVIDIA...

[nanonyme]

Although if what BlackStar says is true, the biggest problem is not the developers not having ATi cards but instead being completely oblivious to language standards and implementing things wrong.

[BlackStar]

Although if what BlackStar says is true, the biggest problem is not the developers not having ATi cards but instead being completely oblivious to language standards and implementing things wrong.

To their defence, some mistakes are nigh impossible to catch without rigorous testing:

gl_FragColor = vec4(color, 1);

That's incorrect by GLSL standards (no implicit conversions from int to float), yet nvidia will accept it. Fglrx/mesa, on the other hand, will raise an error. (The correct code is, of course, "vec4(color, 1.0)").

Head over to the blender forums or gamedev.net and you'll see bugs like these are very very common. Most developers won't think twice before signing off a shader (hey, it works fine here!) but it's the users that pay the price in the end.

In my experience, at least 50% of all GLSL shaders contain such defects. Maybe XBMC has actually hit a fglrx bug (does it work on mesa?) but I think a genuine programmer error is at least as likely.

[nanonyme]

Hmm, I'll make a note of that if I end up writing OpenGL. It kinda puzzles me though that you can't have the compiler cry out for stuff like that. Should probably read into vec4 implementations.

[rohcQaH]

It kinda puzzles me though that you can't have the compiler cry out for stuff like that.

Which compiler? GLSL is compiled by the gfx driver when your program is running.
The driver will complain, but your IDE doesn't (cannot).

[nanonyme]

Oh, ick. Couldn't you write a GLSL validator for use with IDE's though?

[nanonyme]

(namely a parser, not a compiler; a parser should be able to spot the things against the standard, right?)

[BlackStar]

Even on nvidia, you can enable strict mode using a #version pragma (which will turn most portability warnings into errors and stop the code from running). Most developers don't bother to add version pragmas either.

An offline validator wouldn't really help. No two GLSL implementations are 100% the same, so even if your program passes the validator it might not run on real hardware (intel being the biggest offender, but fglrx and nvidia have their share of bugs, too. Just try playing with arrays of structures/uniforms/varyings to see what I mean ).

So far, I've found the least painful approach is to develop on Ati, port to Nvidia (about 95% chances of working out of the box) and try to port to Intel if absolutely necessary (about 0% chances of running without modifications). If you go with Nvidia first and then port to Ati, you'll have about 80% chance of running without issues, so it's not as efficient. If you go with Intel first, you'll simply waste your time - their OpenGL drivers simply don't follow the specs to any reasonable extent (admittedly, it's better on the Linux side, but their Windows drivers are simply awful).

In any case, you will need at least two GPUs to test - at least if you value portability. Yes, we have it easy nowadays. Back in 2004, only nvidia produced working drivers for OpenGL, everything else was utter garbage!

[whizse]

Mesa does have a stand-alone GLSL compiler:

http://mesa3d.org/shading.html

(And of course you can always run a software implementation of Mesa regardless of the 3D driver used. It's painfully slow, but can be good enough to check for problems.)