On Fri, Jan 29, 2010 at 12:31 PM, Brian Paul <brian.e.p...@gmail.com> wrote: > On Fri, Jan 29, 2010 at 9:49 AM, Brian Paul <brian.e.p...@gmail.com> wrote: >> On Fri, Jan 29, 2010 at 12:48 AM, Luca Barbieri <l...@luca-barbieri.com> >> wrote: >>> 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? >> >> Luca, I'm OK with this change in principle but I need a bit more time >> to review the problem and your patch... > > Luca, > > Let me make sure I understand the problem here. > > Are you specifically concerned about the GENERIC[x] semantic > labels/indexes that are attached to VS outputs and FS inputs? > > I hacked a Mesa GLSL demo to use texcoords and varying vars and saw > something like this: > > VERT > DCL IN[0] > DCL OUT[0], POSITION > DCL OUT[1], GENERIC[0] > DCL OUT[2], GENERIC[10] > ... > > FRAG > DCL IN[0], GENERIC[0], PERSPECTIVE > DCL IN[1], GENERIC[10], PERSPECTIVE > DCL OUT[0], COLOR > ... > > > We use the semantic names/labels GENERIC[0] and GENERIC[10] but note > that the actual inputs/outputs are in consecutive slots. > > This is as intended. The semantic indexes are used to match up > inputs/outputs logically but they should not effect which hardware > interpolation slots are used. >
FWIW, I think DX10 required or at least encouraged semantic mapping support in hardware. R6xx+ radeons support this and r3xx-r5xx hardware do to a lesser degree. You can use arbitrary, driver specific ids and the hardware will match up inputs and outputs based on those ids. Alex > Prior to Keith's commit 07fafc7c9346aa260829603bf3188596481e9e62 the > generic semantic indexes were consecutive, BTW. > > -Brian > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
