| Summary: | [r300g] shaders/glsl-const-builtin-derivatives unknown opcode DDX | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Priit Laes (irc: plaes) <plaes> |
| Component: | Drivers/DRI/r300 | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | glxinfo.log | ||
|
Description
Priit Laes (irc: plaes)
2010-08-07 09:40:33 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
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.