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. 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
