[Mesa-dev] [PATCH 09/12] i965/fs: Add support for gl_ViewportIndex input

[Roland Scheidegger]

Am 28.01.2014 21:45, schrieb Ian Romanick:
> On 01/26/2014 02:31 PM, Chris Forbes wrote:
>> Ian,
>>
>> I'd thought about that a bit while building this, and struggled to
>> find cases where this was observable in a defined fragment shader
>> execution.
> 
> Yeah, I've been thinking about it a bit too.
> 
>> The ARB_viewport_array spec says:
>>
>>     If the value of the viewport index is outside the range zero to the value
>>     of MAX_VIEWPORTS minus one, the results of the viewport
>>     transformation are undefined.
> 
> There is similar language for layer.
> 
>> It seems absurd to carry around an extra real slot which only adds any
>> value in a case where we're not required to be performing any
>> particular fragment shader invocations at all.
> 
> That's the rub.  If there are no invocations, then we shouldn't have to
> carry it.  If there are invocations...  We can test that with a simple
> fragment shader:
> 
>     #version 150
>     #extension GL_ARB_fragment_layer_viewport: require
>     in int viewport_index;
>     layout (binding = 0, offset = 0) uniform atomic_uint invocations;
>     layout (binding = 0, offset = 4) uniform atomic_uint matches;
> 
>     void main()
>     {
>         atomicCounterIncrement(invocations);
>         if (gl_ViewportIndex == viewport_index)
>             atomicCounterIncrement(matches);
>     }
> 
> If invocations and matches match after rendering, we should be good.
> 
>> I can see cases where an out-of-range gl_Layer *almost* makes sense --
>> only interactions with the framebuffer are undefined, so you could
>> have no framebuffer writes, no fragment tests, and then do something
>> based on gl_Layer with atomics, images, or shader storage buffers. But
>> it's still a mad thing to do.
>>
>> Do you know the rationale for having this language in the spec?
> 
> I believe DX has a similar requirement.  I'm not sure if there's some
> additional method by which out-of-range values can be observed.

That is very much true and probably why it's in there. That said, d3d10
has a LOT of very well defined error behavior usually going way beyond
what OpenGL requires, to the point of being silly (but yes the tests
will test all of that error behavior).
For viewport, like GL, it also has the fs input value being the same as
gs output. Furthermore however, d3d10 also requires defined behavior for
vp indices out of range for vp transform (index is set to 0) - hence the
behavior of such an input in the fs is well defined and makes a bit more
sense probably with d3d10 than it does in GL. Not that I'd expect any
app outside whck to rely on that.

Roland

>> In any case, happy to park this for now -- it just looked like an easy
>> win, and it turns out it's not quite.
>>