Luca, In GL, there doesn't seem to be a requirement for sequential usage - an app using ARB_vp/fp could explicitly pass TEXCOORD[10] and ignore 0..9 if it wanted to. In ARB_vp, that effectively means the shader would be using discontiguous register numbers, ie OUTPUT[0], OUTPUT[10], etc.
In DX9, there is also no requirement for sequential usage - an app can use TEXCOORD[1] without [0], or COLOR[0] and [2] without [1] or [3]. I would expect any DX9 gallium state tracker would also end up using non-sequential indices if it directly translated DX9 semantics to gallium. In DX10, it seems to be the same, but there are additional changes to simplify things. Here's a link to some msdn about DX9 and DX10 semantics: http://msdn.microsoft.com/en-us/library/ee415668%28VS.85%29.aspx#Porting_Shaders With quote: ---------------------- A semantic is a string attached to a shader input or output that conveys information about the intended use of a parameter. Semantics are required on all variables passed between shader stages. The syntax for adding a semantic to a shader variable is shown here (Variable Syntax (DirectX HLSL)). In general, data passed between pipeline stages is completely generic and is not uniquely interpreted by the system; arbitrary semantics are allowed which have no special meaning. Parameters (in Direct3D 10) which contain these special semantics are referred to as System-Value Semantics. ---------------------- This is fairly close to gallium. It's hard to tell what goes on at the assembly level in DX10, as HLSL is the public interface. But it seems that DX10 goes further than gallium, and also matches based on register number, ie PS.input[0] always corresponds to VS.output[0], though I'm not sure how that works in the face of things like the "face" register which appears for the first time in the PS. Here's a link: http://msdn.microsoft.com/en-us/library/ee418358%28VS.85%29.aspx With quote: -------------- In Direct3D 10, adjacent stages effectively share a register array, where the output shader (or pipeline stage) writes data to specific locations in the register array and the input shader must read from the same locations. The API uses shader signatures to bind shader outputs with inputs without the overhead of semantic resolution. -------------- So right now, we seem to actually be close to the DX9 and GL models. If we were going to change, I'd suggest moving closer to DX10 rather than coming up with some new way of doing things. Ultimately, it shouldn't be all that important as everybody should be running these shaders through a proper optimizer for their hardware, which should have no trouble translating this stuff into any format it likes. Keith ________________________________________ From: luca.barbi...@gmail.com [luca.barbi...@gmail.com] On Behalf Of Luca Barbieri [l...@luca-barbieri.com] Sent: Thursday, January 28, 2010 11:48 PM To: Brian Paul; Keith Whitwell Cc: Luca Barbieri; mesa3d-dev@lists.sourceforge.net Subject: Re: [PATCH] glsl: put varyings in texcoord slots I'd like to have some more definitive review comments on this patch (sending to Brian and Keith for this). Right now GLSL is the *only* Gallium user that does not use sequential indexes starting from 0 for vertex shader outputs and fragment shader inputs. This causes problems for some drivers such as nv30/nv40 that don't remap the indexes right now. This can be addressed in two ways: 1. Don't require Gallium users to use sequential indices, and require vertex shader inputs and fragment shader outputs to match perfectly 2. Don't require Gallium users to use sequential indices, and change nv30/nv40 and possibly other drivers to remap indices 3. Fix the only problematic user, GLSL, to use sequential indices (1) will break the Mesa state tracker in a very hard to fix way. (2) is complex and means that nv30/nv40 and maybe other drivers can no longer compile vertex and fragment shaders independently. (3) is a simple fix, provided by this patch. I feel that (3), implemented by this patch, is the best solution, since driver simplicity is one of the Gallium design goals, and I don't see any significant advantages in supporting discontiguous vertex shader output / fragment shader input values. OpenGL and DirectX 9/10 don't seem to allow arbitrary numbers for vertex shader outputs and fragment shader inputs, and instead require 0-7, 0-15 or 0-31 depending on feature level. If this is wrong, please correct me. I propose that Gallium should also require 0-x indices and not arbitrary values. Thus, GLSL should be fixed to respect that. Note that this change cannot be done in the state tracker because it requires to see both the fragment and vertex shaders at once, which only happens in the GLSL linker. Thus, while the change has been discussed with Gallium in mind, it is done at the Mesa program level, and it actually results in Mesa programs with contiguous indices. This also potentially benefits non-Gallium drivers. What do you think? ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
