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

Reply via email to