Created attachment 80344 [details] 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.
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).
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?
I think the GLSL compiler only eliminates unused user-defined varyings, unused legacy varyings are not eliminated. I'm taking this task.
Cool, thanks!
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.
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.
Fixed by a commit series which starts here: http://cgit.freedesktop.org/mesa/mesa/commit/?id=74edd56927801e8c646c7d5cddba397c2f54b4ef
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.