On 03/15/2011 12:22 AM, Marek Olšák wrote:
There is a fail path in r300g that has been working very well for us. If
shader compilation fails, a dummy shader emitting one instruction is
used (usually outputting (0,0,0,1) into the first output). This approach
allows the applications with failing shaders to run with misrendering on
specific objects (in case of a fragment shader failure) or with missing
objects (in case of a vertex shader failure). The fact there is no crash
or abort or anything preventing the apps from running makes some of them
usable. It also makes debugging easier, because all failing shaders must
go through the r300 compiler and we can analyze whether the compiler is
doing a good job in reducing the number of instructions and temporaries,
and whether we can do something about it to make it better.
If we are about to introduce new shader error enums, I'd like to
preserve the current r300g behavior for OpenGL apps, because it appears
to be a win in most cases.
The problem with this is if someone is developing a GL app with the
R300 driver and is seeing black pixels instead of getting a compiler
error when something's wrong with the shader, the developer is going
to think the bug/problem is in the driver and not his shader.
I think this is especially important for a low-end GPU driver. If I
were developing an app with non-trivial shaders, I'd want to test on a
low-end or older GPU to see if it works. That generally means the
shader will work on a newer/better GPU. The other way around doesn't
work as well, of course.
What you describe sounds useful, but it should probably be controlled
by an env var or something.
-Brian
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
