Kernel: 2.6.35+ Mesa: git master d64a119c28376d7ce069dcec044ff9af7f93ff9c Results for shaders/glsl-const-builtin-derivatives Returncode: 1 Errors: r300 FP: Compiler Error: r300_fragprog_emit.c::translate_rgb_opcode(): translate_rgb_opcode: Unknown opcode DDX Using a dummy shader instead. If there's an 'unknown opcode' message, please file a bug report and attach this log. Output: Probe at (15,15) Expected: 0.000000 1.000000 0.000000 Observed: 0.000000 0.000000 0.000000
Created attachment 37673 [details] glxinfo.log OpenGL vendor string: X.Org R300 Project OpenGL renderer string: Gallium 0.4 on RV370 OpenGL version string: 2.1 Mesa 7.9-devel OpenGL shading language version string: 1.20
Unfortunately, the hw does not support the DDX/DDY opcodes and they can't be emulated.
i915 is going to have the same problem when we enable GLSL there. Our plan is to emit a warning in the shader log and have DDX and DDY always return 0. We've also discussed having a driconf option to enable / disable the behavior. That might be worth trying for r300 as well.
We have a shader which outputs (0,0,0,1) when there is an unsupported instruction. I guess it won't make any difference if we fake the instruction like you said, compared to what we have now. I am going to remove the message saying that a user should file a bug report because we have enough bug reports now and we know very well what the hardware and the shader compiler can do and what not. We were thinking about failing to compile a GLSL shader, which, I guess, should be ok from the specification point of view, but I doubt any application checks whether a shader has compiled successfully.
Well, applications of course check whether a shader has been compiled successfully, but I really doubt it has a replacement shader which is good enough so that it does not distract a user.
(In reply to comment #4) > We were thinking about failing to compile a GLSL shader, which, I guess, should > be ok from the specification point of view, but I doubt any application checks > whether a shader has compiled successfully. Most apps only check the compilation status during development. If the shader is syntactically and semantically correct, the driver is not supposed to fail compilation. The spec doesn't provide any mechanism to fail compilation in this case. AFAIK, the only cases where resource limits are allowed to cause failures is for various types of shader inputs and outputs and texture samplers.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.