<div dir="ltr">On 11 September 2013 16:28, Ian Romanick <span dir="ltr"><<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a>></span> wrote:<br><div class="gmail_extra"><div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>On 09/11/2013 04:05 PM, Paul Berry wrote:<br>
> On 10 September 2013 12:10, Ian Romanick <<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a><br>
</div><div>> <mailto:<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a>>> wrote:<br>
><br>
> From: Ian Romanick <<a href="mailto:ian.d.romanick@intel.com" target="_blank">ian.d.romanick@intel.com</a><br>
</div>> <mailto:<a href="mailto:ian.d.romanick@intel.com" target="_blank">ian.d.romanick@intel.com</a>>><br>
><br>
> Signed-off-by: Ian Romanick <<a href="mailto:ian.d.romanick@intel.com" target="_blank">ian.d.romanick@intel.com</a><br>
> <mailto:<a href="mailto:ian.d.romanick@intel.com" target="_blank">ian.d.romanick@intel.com</a>>><br>
<div><div>> ---<br>
> src/mesa/main/get.c | 4 ----<br>
> src/mesa/main/get_hash_params.py | 2 +-<br>
> 2 files changed, 1 insertion(+), 5 deletions(-)<br>
><br>
> diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c<br>
> index 34eb6be..ae45bf8 100644<br>
> --- a/src/mesa/main/get.c<br>
> +++ b/src/mesa/main/get.c<br>
> @@ -718,10 +718,6 @@ find_custom_value(struct gl_context *ctx, const<br>
> struct value_desc *d, union valu<br>
> ASSERT(v->value_int_n.n <= ARRAY_SIZE(v->value_int_n.ints));<br>
> break;<br>
><br>
> - case GL_MAX_VARYING_FLOATS_ARB:<br>
> - v->value_int = ctx->Const.MaxVarying * 4;<br>
> - break;<br>
> -<br>
> /* Various object names */<br>
><br>
> case GL_TEXTURE_BINDING_1D:<br>
> diff --git a/src/mesa/main/get_hash_params.py<br>
> b/src/mesa/main/get_hash_params.py<br>
> index c0dbf45..3d47443 100644<br>
> --- a/src/mesa/main/get_hash_params.py<br>
> +++ b/src/mesa/main/get_hash_params.py<br>
> @@ -365,7 +365,7 @@ descriptor=[<br>
><br>
> # GL_ARB_vertex_shader<br>
> [ "MAX_VERTEX_UNIFORM_COMPONENTS_ARB",<br>
> "CONTEXT_INT(Const.VertexProgram.MaxUniformComponents),<br>
> extra_ARB_vertex_shader" ],<br>
> - [ "MAX_VARYING_FLOATS_ARB", "LOC_CUSTOM, TYPE_INT, 0,<br>
> extra_ARB_vertex_shader" ],<br>
> + [ "MAX_VARYING_FLOATS_ARB",<br>
> "CONTEXT_INT(Const.VertexProgram.MaxOutputComponents),<br>
> extra_ARB_vertex_shader" ],<br>
><br>
> # GL_EXT_framebuffer_blit<br>
> # NOTE: GL_DRAW_FRAMEBUFFER_BINDING_EXT == GL_FRAMEBUFFER_BINDING_EXT<br>
> --<br>
> 1.8.1.4<br>
><br>
> _______________________________________________<br>
> mesa-dev mailing list<br>
</div></div>> <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a> <mailto:<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a>><br>
<div>> <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
><br>
> Doesn't MAX_VARYING_FLOATS need to be MIN2(MAX_VERTEX_OUTPUT_COMPONENTS,<br>
> MAX_FRAGMENT_INPUT_COMPONENTS)? I can imagine an implementation where<br>
> MAX_FRAGMENT_INPUT_COMPONENTS is the smaller constraint (in fact, ES3's<br>
> minimum maximums constitute just such a case).<br>
<br>
</div>It's all so much more horrible than you think. :)<br>
<br>
OpenGL 3.2 sets:<br>
<br>
MAX_VARYING_COMPONENTS: 60<br>
MAX_VERTEX_OUTPUT_COMPONENTS: 64<br>
MAX_FRAGMENT_INPUT_COMPONENTS: 128<br>
<br>
OpenGL ES 3.0 sets:<br>
<br>
MAX_VARYING_COMPONENTS: 60<br>
MAX_VARYING_VECTORS: 15<br>
MAX_VERTEX_OUTPUT_VECTORS: 16<br>
MAX_VERTEX_OUTPUT_COMPONENTS: 64<br>
MAX_FRAGMENT_INPUT_VECTORS: 15<br>
MAX_FRAGMENT_INPUT_COMPONENTS: 60<br></blockquote><div><br></div><div>Oddly, I don'tsee MAX_VERTEX_OUTPUT_VECTORS or MAX_FRAGMENT_INPUT_VECTORS in the GLES 3 spec; only MAX_VARYING_VECTORS.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
BUT the description of MAX_VARYING_COMPONENTS in GLES3 says:<br>
<br>
"Number of components for output variables."<br>
<br>
So... OpenGL 3.2 makes no sense, and OpenGL ES 3.0 seems self<br>
contradictory. The core problem seems to be the way that each API (and<br>
each driver) counts gl_Position and gl_FragCoord. Some say it's<br>
counted, some say it's not counted, and some say it might be counted.<br>
Our existing infrastructure may not be sufficient to handle all<br>
combinations of those cases.<br></blockquote><div><br></div><div>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.<br>
<br></div><div>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.<br>
<br></div><div>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).<br>
<br></div><div>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).<br>
</div><div><br>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.<br>
<br></div><div>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.<br>
<br></div><div>(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).<br>
</div><div><br></div><div> </div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In the end, I opted to use VertexProgram.MaxOutputComponents because<br>
MAX_VARYING_FLOATS was added by GL_ARB_vertex_shader.<br>
<br>
I guess I'm not sure what the "right" answer actually is now. :(<br>
</blockquote></div><br>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:<br><br><div class="gmail_quote">MAX_VARYING_COMPONENTS 128<br></div><div class="gmail_quote">MAX_VERTEX_OUTPUT_COMPONENTS 128<br></div><div class="gmail_quote">MAX_FRAGMENT_INPUT_COMPONENTS 128<br><br></div><div class="gmail_quote">
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:<br><br>MAX_VARYING_COMPONENTS 120<br></div><div class="gmail_quote">MAX_VERTEX_OUTPUT_COMPONENTS 128<br></div><div class="gmail_quote">MAX_FRAGMENT_INPUT_COMPONENTS 128<br><br></div>
<div class="gmail_quote">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).<br></div><div class="gmail_quote"><br><br></div>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.<br></div></div>