> In GL, there doesn't seem to be a requirement for sequential usage - an app
> using ARB_vp/fp could explicitly pass TEXCOORD[10] and ignore 0..9 if it
> wanted to. In ARB_vp, that effectively means the shader would be using
> discontiguous register numbers, ie OUTPUT[0], OUTPUT[10], etc.
Yes, but TEXCOORD[10] will only work if the hardware supports 11 textures.
>
> In DX9, there is also no requirement for sequential usage - an app can use
> TEXCOORD[1] without [0], or COLOR[0] and [2] without [1] or [3]. I would
> expect any DX9 gallium state tracker would also end up using non-sequential
> indices if it directly translated DX9 semantics to gallium.
I think there is some terminology confusion.
I'm not proposing to require indices to be "sequential" in the way you
are describing.
By "sequential" I mean that if the hardware supports 8 interpolators,
then the available semantic indices should run from 0 to 7.
Thus, the *available* semantic indices are sequential, but the user is
free to use any subset of them.
So you can start with OUTPUT[10], but only if at least 11
interpolators are supported (so that the used set {10} is a subset of
the available set [0-10]).
> With quote:
> --------------
> In Direct3D 10, adjacent stages effectively share a register array, where the
> output shader (or pipeline stage) writes data to specific locations in the
> register array and the input shader must read from the same locations. The
> API uses shader signatures to bind shader outputs with inputs without the
> overhead of semantic resolution.
> --------------
>
> So right now, we seem to actually be close to the DX9 and GL models. If we
> were going to change, I'd suggest moving closer to DX10 > rather than coming
> up with some new way of doing things.
According to the document you quoted, it seems the difference is that
in DX10 vertex and fragment shaders must match exactly, i.e. no vertex
shader output may be left unused and no fragment shader input may be
default zero/undefined.
We can't go with the DX10 model because it will break GL.
We should however decide whether fragment inputs not written by the
fragment shaders are zero or undefined, and make sure all drivers
correctly implement this.
What I'm proposing, excluding the routing table stuff, is exactly the
idea of having output shader and input shader read/write from a
(conceptual) register array.
If you have 8 interpolators, you use vertex outputs 0-7 and fragment
inputs 0-7 with identity mapping.
If we want to add routing support, I suggested adding the ability to
explicitly set a mapping from shader outputs to shader inputs as a set
of pairs.
Unlike the current method, this allows to layer GLSL-like match by
name semantics over it, which is impossible which the current
proposal, since you can't map strings to integer, and you can't
specify routing separately from shaders.
> Ultimately, it shouldn't be all that important as everybody should be running
> these shaders through a proper optimizer for their hardware, which should
> have no trouble translating this stuff into any format it likes.
This is only true if the optimizer works on both the vertex and
fragment shaders together, which is something that would be nice to
avoid (at least, avoid _having_ to do it, it might possibly be
beneficial sometimes).
If they are optimized/compiled separately, the routing and semantic
index choice is fundamental.
------------------------------------------------------------------------------
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
