https://bugs.freedesktop.org/show_bug.cgi?id=65416
Priority: medium Bug ID: 65416 Assignee: dri-devel@lists.freedesktop.org Summary: r300g does not eliminate unread varyings Severity: normal Classification: Unclassified OS: All Reporter: stefandoesinger@gmx.at Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r300 Product: Mesa
Created attachment 80344 --> https://bugs.freedesktop.org/attachment.cgi?id=80344&action=edit Example shaders
r300g tries to interpolate varyings written by the vertex shader even if the fragment shader does not read them. The attached program code illustrates this with two sample shaders.
The shaders in question were generated by Wine's fixed function pipeline replacement, generated from a fixed function setup set up by 3DMark 2000.
The visible issues caused by this are broken fog because the driver runs out of varyings and reduced performance due to the extra shader instructions.
An argument could be made that this is Wine's bug, and it should not generate such inefficient shaders. Doing this would be a major inconvenience though because the vertex and fragment shader are generated independently. As far as I can see the proprietary drivers optimize this inefficiency away.
https://bugs.freedesktop.org/show_bug.cgi?id=65416
--- Comment #1 from Stefan Dösinger stefandoesinger@gmx.at --- Fwiw, I don't know if r600g is affected. The HW has enough varyings to run the unoptimized shaders, and the applications affected by this performance wise are CPU limited on my r600g system.
Wine has some checks to prevent writing texture coordinates in the vertex shader when there is no input to generate them. Unfortunately 3DMark 2000 and Unreal Tournament 2004 use a strange vertex processing setup that breaks those checks(D3DTSS_TEXCOORDINDEX of all texture stages is 0, thus they're reading the first texture coordinate input, which does exist).
https://bugs.freedesktop.org/show_bug.cgi?id=65416
--- Comment #2 from Alex Deucher agd5f@yahoo.com --- Couldn't this be done in a device independent manner in mesa when linking shaders? Drop outputs if there is no matching input in the subsequent shader stage?
https://bugs.freedesktop.org/show_bug.cgi?id=65416
--- Comment #3 from Marek Olšák maraeo@gmail.com --- I think the GLSL compiler only eliminates unused user-defined varyings, unused legacy varyings are not eliminated. I'm taking this task.
https://bugs.freedesktop.org/show_bug.cgi?id=65416
--- Comment #4 from Stefan Dösinger stefandoesinger@gmx.at --- Cool, thanks!
https://bugs.freedesktop.org/show_bug.cgi?id=65416
--- Comment #5 from Marek Olšák maraeo@gmail.com --- I have implemented it, but there is a problem. If I enable the optimization, EXT_separate_shader_objects must be disabled. Is it okay with you?
This is a valid sequence with EXT_sso: glUseProgram(prog_with_vs_and_fs); glUseShaderProgramEXT(prog_with_fs);
prog_with_vs_and_fs cannot be optimized, because the program object can be bound partially (in this case only the vertex shader from the program object is bound).
ARB_separate_shader_objects doesn't have this issue.
https://bugs.freedesktop.org/show_bug.cgi?id=65416
--- Comment #6 from Stefan Dösinger stefandoesinger@gmx.at --- I guess that's ok for wined3d's purposes. We don't use either extension right now, and if we ever use one of them we'll probably go with the ARB one anyway.
https://bugs.freedesktop.org/show_bug.cgi?id=65416
Marek Olšák maraeo@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #7 from Marek Olšák maraeo@gmail.com --- Fixed by a commit series which starts here: http://cgit.freedesktop.org/mesa/mesa/commit/?id=74edd56927801e8c646c7d5cddb...
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org