Luca,
Where the semantic indicates some relationship to actual system resources, I
agree that the number is constrained by the number of those system resources.
In the case of the gallium "GENERIC" semantic, there is explicitly no system
resource that semantic is referring to and hence no limit on the index.
I feel like we're going in circles here. We agree that we want to improve
linkage, you have a patch that helps your driver, but please accept that it
doesn't solve the wider problem.
Keith
________________________________________
From: luca.barbi...@gmail.com [luca.barbi...@gmail.com] On Behalf Of Luca
Barbieri [l...@luca-barbieri.com]
Sent: Monday, February 01, 2010 10:50 AM
To: Keith Whitwell
Cc: mesa3d-dev@lists.sourceforge.net
Subject: Re: [Mesa3d-dev] light_twoside RE: [PATCH] glsl: put varyings in
texcoord slots
> I haven't tried to probe crazy high numbers, but within reason, my experience
> is that the numbers are unconstrained.
No, according to that document if you use TEXCOORD[n] then n < NUM_TEXCOORDS.
<<
TEXCOORD[n] Texture coordinates float4
[...]
n is an optional integer between 0 and the number of resources
supported. For example, POSITION0, TEXCOOR1, etc.
>>
Also look at the spec for ARB_fragment_program:
<fragAttribItem> ::= "color" <optColorType>
| "texcoord" <optTexCoordNum>
[...]
<optTexCoordNum> ::= ""
| "[" <texCoordNum> "]"
<optColorType> ::= ""
| "." "primary"
| "." "secondary"
<texCoordNum> ::= <integer> from 0 to MAX_TEXTURE_COORDS_ARB-1
fragment.texcoord has the index limited by MAX_TEXTURE_COORDS_ARB.
It seems to me pretty clear from the above references that *all* 3D
APIs (i.e. DX9, DX10 and GL) have semantic indices in the range
0...N-1 where N is the limit appropriate for the specific semantic.
I think these references contradict your hypotesis that there is no
constraint in DX9.
Am I misunderstanding something completely?
Do you disagree with the fact that those references clearly show that
semantic indices are limited by hardware resources?
> Now, your particular hardware has a additional limitation which is fairly
> unique, and you're pushing a change to gallium which would mimic the
> restrictions of your hardware. I'm not actually interested in adjusting
> gallium to the constraints of one particular driver, but *am* quite
> interested in finding a way to improve linkage issues across the hardware we
> support.
No, it is a limitation that any hardware that does a direct
implementation of OpenGL has.
For instance, I'd guess that the VMWare driver works around that
problem somewhere since it ultimately uses the host OpenGL
implementation.
With my proposal, it could just convert GENERIC[0] into
fragment.texcoord[0] and likewise for others.
> But your change does dramatically alter the meaning of one part of gallium
> and introduces a new raft of hardware capabilities we'd have to be checking
> and respecting in every state tracker.
Not at all.
All code except the GLSL linker will work optimally as is, since it
uses indices sequentially starting from 0 (or implements an API that
does).
I provided a patch to fix the GLSL linker.
> If we are going to adjust gallium, lets figure out a way to improve linkage
> generally. Adding a per-driver, per-semantic maximum index query just for
> the benefit of one driver doesn't strike me as a good trade-off.
It is already necessary to have that to implement glGet of
GL_MAX_TEXTURE_COORDS_ARB, for the TEXCOORD capability.
------------------------------------------------------------------------------
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
