https://bugs.freedesktop.org/show_bug.cgi?id=29137 --- Comment #13 from Henri Verbeet <hverbeet@xxxxxxxxx> 2010-08-21 06:02:33 PDT --- (In reply to comment #12) > Henri, > > I was thinking about this issue and realized that the way you allocate constant > space in wine is wrong. The problem is you create one large array "uniform vec4 > VC[256]". If this array is addressed indirectly, that is using e.g. > VC[index+20] where "index" cannot be evaluated at compile time, we must assume > *any* element in the array may potentially be used and therefore we cannot > eliminate unused elements, because there appears to be none. > Yes, but that's because of the way d3d9 works. I.e., you just have one big block of 256 float constants (in SM2 and SM3, SM1 only requires 96). Direct3D 10 and 11 constant buffers are much nicer in that regard. The problem is that wined3d needs a couple of extra constants for its own fixups, and often the driver needs a couple as well. For shaders where no relative addressing is used, wined3d could declare separate uniforms instead of one big array. We'll probably make that change in the near/medium future, unless changes in Mesa make it a non-issue for us. I nevertheless think it would be a valid enhancement to the Mesa GLSL compiler to make that observation on its own. > We can do the optimization if there is no indirect addressing, but we cannot do > this for all cases and say "it's fixed once and for all". Similarly, wined3d can't split up the d3d9 constant array when relative addressing is used. This is not just a problem with Mesa for us, it affects e.g. fglrx and pre-GF8 nvidia hardware as well. The reason this isn't much of an issue on GF8+ nvidia hardware is that it simply reports 4096 uniforms as being available. Extensions like NV_shader_buffer_load suggest GF8+ hardware can simply access arbitrary buffer objects / video memory from a shader. The workaround we use when relative addressing is used by a shader is to simply subtract our internal constants, in addition to our (most likely flawed) estimate of what the driver itself needs, from the number of constants available to the application. This breaks down when applications allocate from the end of the range of available constants. I.e., using c[255] while at the same time using relative addressing for e.g. vertex blending. http://bugs.winehq.org/show_bug.cgi?id=17818 is an example of a bug caused by this. In short, I don't expect Mesa to be able to do much, if anything, to help solve this. There may be some things we can try on the Wine side though. For example, on hardware the supports immediate constants like r600 we could take advantage of that and just hardcode our fixups into the shaders, and have multiple versions of the shader instead. These fixups are things like compensating for differences in pixel center between d3d9 and GL, or texture origin when rendering to an FBO, which at least some drivers will have to do themselves anyway, but the other way around. If we get lucky they may even cancel out and get optimized away. The y-flip when rendering to FBO is especially sad, because it ends up being a multiplication by -1.0, which would often be free as a negate. The other way out is that while we can't determine which uniforms are read by the shader, we can determine which ones are set by the application. Constants that are never set would be our best bet for stuffing our own fixups in, although that strategy depends on the application really treating those as undefined, rather than relying on them being set to e.g. 0.0. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
