I tested this on Windows, using nVidia driver 195 on nv40, and it
seems we are all partially wrong.
SM3 does indeed allow semantics unrelated to hardware resources.
However, the semantic indices for any semantic type must be in the
range 0-15, or D3DX will report a compiler error during shader
On Wed, 2010-02-03 at 01:42 -0800, Luca Barbieri wrote:
I tested this on Windows, using nVidia driver 195 on nv40, and it
seems we are all partially wrong.
SM3 does indeed allow semantics unrelated to hardware resources.
However, the semantic indices for any semantic type must be in the
On Wed, Feb 3, 2010 at 4:42 AM, Luca Barbieri l...@luca-barbieri.com wrote:
I tested this on Windows, using nVidia driver 195 on nv40, and it
seems we are all partially wrong.
SM3 does indeed allow semantics unrelated to hardware resources.
However, the semantic indices for any semantic type
Luca Barbieri wrote on 2010-02-01 21:42:
1. All the semantic indices in OpenGL are limited, according to the
ARB specification
2. All the sematic indices in DirectX 9/10 are limited, according to
http://msdn.microsoft.com/en-us/library/ee418355%28VS.85%29.aspx
At least for SM3.0, one can
On Tue, Feb 2, 2010 at 3:54 PM, michal mic...@vmware.com wrote:
Luca Barbieri wrote on 2010-02-01 21:42:
1. All the semantic indices in OpenGL are limited, according to the
ARB specification
2. All the sematic indices in DirectX 9/10 are limited, according to
At least for SM3.0, one can specify a vertex shader output semantic like
COLOR15 and have it running as long as one has also a pixel shader with a
matching input semantic. Though I agree with you we don't really want to go
this route and have something more sensible.
Do you know of any
Personally I'm
going to take a break from this thread, spend a couple of days looking
at i965, etc, to see what can be done to improve things there, and
maybe come back with an alternate proposal.
Yes, I think that the most important step is to precisely determine
how both hardware (and
On Tue, Feb 02, 2010 at 07:09:12PM +0100, Luca Barbieri wrote:
Otherwise, we will need to recompile either of the shaders at link
time, so that foo is assigned the same slot in both shaders, which
is what we do now in GLSL linking, but is somewhat inefficient and in
particular can lead to
On Tue, Feb 2, 2010 at 1:16 PM, Luca Barbieri l...@luca-barbieri.com wrote:
Personally I'm
going to take a break from this thread, spend a couple of days looking
at i965, etc, to see what can be done to improve things there, and
maybe come back with an alternate proposal.
Yes, I think that
On Tue, Feb 2, 2010 at 7:38 PM, Olivier Galibert galib...@pobox.com wrote:
On Tue, Feb 02, 2010 at 07:09:12PM +0100, Luca Barbieri wrote:
Otherwise, we will need to recompile either of the shaders at link
time, so that foo is assigned the same slot in both shaders, which
is what we do now in
:09 AM
To: Michal Krol
Cc: mesa3d-dev@lists.sourceforge.net
Subject: Re: [Mesa3d-dev] light_twoside RE: [PATCH] glsl: put varyings in
texcoord slots
The documentation I found seems to support to opposite statement, as
the following line:
n is an optional integer between 0 and the number
Christoph, Luca,
Twoside lighting has is a bit of a special case GL-ism. On a lot of hardware
we end up implementing it by passing both front and back colors to the fragment
shader and selecting between them using the FACE variable. If we removed the
implicit fixed-function support for
On Mon, Feb 1, 2010 at 5:31 PM, Keith Whitwell kei...@vmware.com wrote:
Christoph, Luca,
Twoside lighting has is a bit of a special case GL-ism. On a lot of hardware
we end up implementing it by passing both front and back colors to the
fragment shader and selecting between them using the
, February 01, 2010 8:44 AM
To: Keith Whitwell
Cc: Christoph Bumiller; mesa3d-dev@lists.sourceforge.net
Subject: Re: light_twoside RE: [Mesa3d-dev] [PATCH] glsl: put varyings in
texcoord slots
On Mon, Feb 1, 2010 at 5:31 PM, Keith Whitwell kei...@vmware.com wrote:
Christoph, Luca,
Twoside
DX9 semantic indexes are apparently unlimited
According to http://msdn.microsoft.com/en-us/library/ee418355%28VS.85%29.aspx,
this is not the case.
Here is the relevant text:
These semantics have meaning when attached to a vertex-shader
parameters. These semantics are supported in both Direct3D
: [PATCH] glsl: put varyings in
texcoord slots
DX9 semantic indexes are apparently unlimited
According to http://msdn.microsoft.com/en-us/library/ee418355%28VS.85%29.aspx,
this is not the case.
Here is the relevant text:
These semantics have meaning when attached to a vertex-shader
On 01.02.2010 17:31, Keith Whitwell wrote:
Christoph, Luca,
Twoside lighting has is a bit of a special case GL-ism. On a lot of hardware
we end up implementing it by passing both front and back colors to the
fragment shader and selecting between them using the FACE variable. If we
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
...@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
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
A possible limitation of this scheme is that it doesn't readily map to
hardware that can configure its own interpolators to behave either as
GENERIC, COLOR (or some other semantic) dynamically.
However, it seems to me that at least ARB_fragment_program only
requires and supports 2 COLOR registers
21 matches
Mail list logo
