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