Bug 29439 - [r300g] shaders/glsl-const-builtin-derivatives unknown opcode DDX
Summary: [r300g] shaders/glsl-const-builtin-derivatives unknown opcode DDX
Status: RESOLVED WONTFIX
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r300 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-07 09:40 UTC by Priit Laes (irc: plaes)
Modified: 2010-08-07 16:20 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
glxinfo.log (21.89 KB, text/plain)
2010-08-07 09:40 UTC, Priit Laes (irc: plaes)
Details

Description Priit Laes (irc: plaes) 2010-08-07 09:40:33 UTC
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
Comment 1 Priit Laes (irc: plaes) 2010-08-07 09:40:58 UTC
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
Comment 2 Alex Deucher 2010-08-07 10:16:32 UTC
Unfortunately, the hw does not support the DDX/DDY opcodes and they can't be emulated.
Comment 3 Ian Romanick 2010-08-07 12:19:01 UTC
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.
Comment 4 Marek Olšák 2010-08-07 13:49:59 UTC
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.
Comment 5 Marek Olšák 2010-08-07 13:54:47 UTC
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.
Comment 6 Ian Romanick 2010-08-07 16:20:53 UTC
(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.