https://bugs.freedesktop.org/show_bug.cgi?id=29439
Summary: [r300g] shaders/glsl-const-builtin-derivatives unknown opcode DDX Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: plaes@plaes.org
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
https://bugs.freedesktop.org/show_bug.cgi?id=29439
--- Comment #1 from Priit Laes (irc: plaes) plaes@plaes.org 2010-08-07 09:40:58 PDT --- Created an attachment (id=37673) --> (https://bugs.freedesktop.org/attachment.cgi?id=37673) 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
https://bugs.freedesktop.org/show_bug.cgi?id=29439
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX
--- Comment #2 from Alex Deucher agd5f@yahoo.com 2010-08-07 10:16:32 PDT --- Unfortunately, the hw does not support the DDX/DDY opcodes and they can't be emulated.
https://bugs.freedesktop.org/show_bug.cgi?id=29439
--- Comment #3 from Ian Romanick idr@freedesktop.org 2010-08-07 12:19:01 PDT --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=29439
--- Comment #4 from Marek Olšák maraeo@gmail.com 2010-08-07 13:49:59 PDT --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=29439
--- Comment #5 from Marek Olšák maraeo@gmail.com 2010-08-07 13:54:47 PDT --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=29439
--- Comment #6 from Ian Romanick idr@freedesktop.org 2010-08-07 16:20:53 PDT --- (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.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org