[Mesa-dev] [PATCH 11/17] mesa: Get GL_MAX_VARYING_FLOATS_ARB from VertexProgram.MaxOutputComponents
Paul Berry
stereotype441 at gmail.com
Fri Sep 13 11:45:55 PDT 2013
On 11 September 2013 16:28, Ian Romanick <idr at freedesktop.org> wrote:
> On 09/11/2013 04:05 PM, Paul Berry wrote:
> > On 10 September 2013 12:10, Ian Romanick <idr at freedesktop.org
> > <mailto:idr at freedesktop.org>> wrote:
> >
> > From: Ian Romanick <ian.d.romanick at intel.com
> > <mailto:ian.d.romanick at intel.com>>
> >
> > Signed-off-by: Ian Romanick <ian.d.romanick at intel.com
> > <mailto:ian.d.romanick at intel.com>>
> > ---
> > src/mesa/main/get.c | 4 ----
> > src/mesa/main/get_hash_params.py | 2 +-
> > 2 files changed, 1 insertion(+), 5 deletions(-)
> >
> > diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
> > index 34eb6be..ae45bf8 100644
> > --- a/src/mesa/main/get.c
> > +++ b/src/mesa/main/get.c
> > @@ -718,10 +718,6 @@ find_custom_value(struct gl_context *ctx, const
> > struct value_desc *d, union valu
> > ASSERT(v->value_int_n.n <= ARRAY_SIZE(v->value_int_n.ints));
> > break;
> >
> > - case GL_MAX_VARYING_FLOATS_ARB:
> > - v->value_int = ctx->Const.MaxVarying * 4;
> > - break;
> > -
> > /* Various object names */
> >
> > case GL_TEXTURE_BINDING_1D:
> > diff --git a/src/mesa/main/get_hash_params.py
> > b/src/mesa/main/get_hash_params.py
> > index c0dbf45..3d47443 100644
> > --- a/src/mesa/main/get_hash_params.py
> > +++ b/src/mesa/main/get_hash_params.py
> > @@ -365,7 +365,7 @@ descriptor=[
> >
> > # GL_ARB_vertex_shader
> > [ "MAX_VERTEX_UNIFORM_COMPONENTS_ARB",
> > "CONTEXT_INT(Const.VertexProgram.MaxUniformComponents),
> > extra_ARB_vertex_shader" ],
> > - [ "MAX_VARYING_FLOATS_ARB", "LOC_CUSTOM, TYPE_INT, 0,
> > extra_ARB_vertex_shader" ],
> > + [ "MAX_VARYING_FLOATS_ARB",
> > "CONTEXT_INT(Const.VertexProgram.MaxOutputComponents),
> > extra_ARB_vertex_shader" ],
> >
> > # GL_EXT_framebuffer_blit
> > # NOTE: GL_DRAW_FRAMEBUFFER_BINDING_EXT ==
> GL_FRAMEBUFFER_BINDING_EXT
> > --
> > 1.8.1.4
> >
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org <mailto:
> mesa-dev at lists.freedesktop.org>
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
> > Doesn't MAX_VARYING_FLOATS need to be MIN2(MAX_VERTEX_OUTPUT_COMPONENTS,
> > MAX_FRAGMENT_INPUT_COMPONENTS)? I can imagine an implementation where
> > MAX_FRAGMENT_INPUT_COMPONENTS is the smaller constraint (in fact, ES3's
> > minimum maximums constitute just such a case).
>
> It's all so much more horrible than you think. :)
>
> OpenGL 3.2 sets:
>
> MAX_VARYING_COMPONENTS: 60
> MAX_VERTEX_OUTPUT_COMPONENTS: 64
> MAX_FRAGMENT_INPUT_COMPONENTS: 128
>
> OpenGL ES 3.0 sets:
>
> MAX_VARYING_COMPONENTS: 60
> MAX_VARYING_VECTORS: 15
> MAX_VERTEX_OUTPUT_VECTORS: 16
> MAX_VERTEX_OUTPUT_COMPONENTS: 64
> MAX_FRAGMENT_INPUT_VECTORS: 15
> MAX_FRAGMENT_INPUT_COMPONENTS: 60
>
Oddly, I don'tsee MAX_VERTEX_OUTPUT_VECTORS or MAX_FRAGMENT_INPUT_VECTORS
in the GLES 3 spec; only MAX_VARYING_VECTORS.
>
> BUT the description of MAX_VARYING_COMPONENTS in GLES3 says:
>
> "Number of components for output variables."
>
> So... OpenGL 3.2 makes no sense, and OpenGL ES 3.0 seems self
> contradictory. The core problem seems to be the way that each API (and
> each driver) counts gl_Position and gl_FragCoord. Some say it's
> counted, some say it's not counted, and some say it might be counted.
> Our existing infrastructure may not be sufficient to handle all
> combinations of those cases.
>
I've spent a while digging through the specs, and I actually don't think
it's quite as complicated or counterintuitive as it sounded at first.
First of all, we don't need to worry about the distinction between
COMPONENTS and VECTORS, because MAX_foo_COMPONENTS always equals
MAX_foo_VECTORS * 4. Similarly, there's no need to distinguish between
MAX_VARYING_COMPONENTS and MAX_VARYING_FLOATS.
As for the question of whether gl_Position and gl_FragCoord count against
these limits, all GL specs since 2.0, and all GLES specs since 2.0 seem to
agree that gl_Position is *not* counted for MAX_VARYING_COMPONENTS, however
MAX_*_OUTPUT_COMPONENTS and MAX_*_INPUT_COMPONENTS count *all* inputs and
outputs. I think reasonable to infer that the spec writers probably
intended for the same to apply to gl_FragCoord and gl_FrontFacing (namely,
they don't count against MAX_VARYING_COMPONENTS, but the do count against
MAX_FRAGMENT_INPUT_COMPONENTS).
Interestingly, ARB_vertex_shader doesn't specifically mention that
gl_Position is excluded from MAX_VARYING_FLOATS, but it defines
MAX_VARYING_FLOATS as the number of "interpolators" that are available, so
I think it's a reasonable interpretation that gl_Position is not intended
to be counted (especially given that this is the interpretation that the GL
spec authors chose when promoting the extension into GL 2.0).
Note that all the specs allow for the possibility that device-dependent
optimizations may allow for more than the advertised number of
inputs/outputs/varyings to be supported in some circumstances, so if a
certain piece of hardware has dedicated input/output locations for certain
variables, that's not a problem; it simply means that in some situations
the driver may be able to successfully compile and link a shader that isn't
strictly guaranteed by the spec to work.
So it seems to me that there's a single consistent interpretation: clients
may assume that MAX_VARYING_{FLOATS,COMPONENTS,VECTORS} applies just to
things that are truly varyings (gl_Position, gl_FragCoord, and
gl_FrontFacing are exempted), but to be safe, clients must assume that
MAX_*_OUTPUT_COMPONENTS and MAX_*_INPUT_COMPONENTS apply to all shader
inputs/outputs. However, implementations are free to choose not to count
certain inputs/outputs against these limits, causing them to successfully
compile and link shaders that would otherwise fail.
(There is the minor wrinkle that certain implementations have a
hardware-imposed limit of 64 on the number of vertex output components
(including gl_Position), so they aren't strictly able to support GL
3.0-3.1's requirement that MAX_VARYING_COMPONENTS >= 64. I'm not sure if
Mesa supports any of these implementations; but if it does, I think we can
finesse that issue).
>
> In the end, I opted to use VertexProgram.MaxOutputComponents because
> MAX_VARYING_FLOATS was added by GL_ARB_vertex_shader.
>
> I guess I'm not sure what the "right" answer actually is now. :(
>
Now that I've spent a day thinking about all this, it seems to me that Mesa
front end shouldn't ever try to infer MAX_VARYING_COMPONENTS from
MAX_VERTEX_OUTPUT_COMPONENTS and MAX_FRAGMENT_INPUT_COMPONENTS, because the
relationship between them depends on exactly what the hardware limitations
are. For example, once my 128-varyings patches land, Mesa on i965/gen6+
will be able to support:
MAX_VARYING_COMPONENTS 128
MAX_VERTEX_OUTPUT_COMPONENTS 128
MAX_FRAGMENT_INPUT_COMPONENTS 128
because the hardware has dedicated locations for gl_Position, gl_FragCoord,
and gl_FrontFacing. But implementations that don't have those dedicated
locations might support as little as:
MAX_VARYING_COMPONENTS 120
MAX_VERTEX_OUTPUT_COMPONENTS 128
MAX_FRAGMENT_INPUT_COMPONENTS 128
So I think the back-end should just specify all three of these values
independently, and Mesa should expose them to the client without applying
any further math to them (other than the factor of 4 to convert between
component and vector counts).
Another question which we haven't really addressed is how Mesa's front end
linker should check these limits, given the fact that some implementations
have dedicated locations for certain shader inputs/outputs. I have a few
ideas about this, but it's probably something that we should save for a
future patch series.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130913/a5d4a803/attachment-0001.html>
More information about the mesa-dev
mailing list