[Mesa-dev] RFC: ARB_sample_shading in gallium

[Roland Scheidegger]

Am 28.03.2014 22:56, schrieb Ilia Mirkin:
> On Fri, Mar 28, 2014 at 5:47 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>> Am 28.03.2014 22:18, schrieb Ilia Mirkin:
>>> Hey guys,
>>>
>>> I was thinking of taking a shot at implementing ARB_sample_shading for
>>> nv50 (well, nva3-nva8) this weekend. One of the issues is that it's
>>> not implemented in gallium at all right now, so I need to pipe it
>>> through somehow. I believe that the only piece of data that needs to
>>> be piped through is the value returned by
>>> _mesa_get_min_invocations_per_fragment, which is a function of the fp,
>>> the drawbuffer, and the MS state. When that value is > 1, sample
>>> shading is effectively enabled. (I guess even when it's == 1, things
>>> like gl_SampleID still need to work, perhaps it's worth adding a
>>> separate enabled bit too.)
>>>
>>> Should this single integer get its own set_* callback, similar to
>>> set_sample_mask, or should it be included somewhere, e.g.
>>> pipe_framebuffer_state? Or even added to the set_sample_mask call?
>>>
>>
>> Would something like in d3d10.1 work where you simply say that inputs
>> are interpolated at sample frequency? That way you can also have some
>> inputs which are not interpolated at sample frequency (I thought there's
>> opengl functionality for this too somewhere - even if not I'd really
>> like to have that functionality in gallium). It would just need new
>> interpolation mode enums.
>> Though I guess this does not fully cover ARB_sample_shading - this
>> extension allows you for instance to have msaa 4x, but run fs at 2x (I
>> could be wrong but I don't think you can do that in d3d, I don't know if
>> hw can do it presumably some can otherwise it wouldn't be in the
>> extension, though it is definitely worded in a way that makes it
>> possible to just run at full sample frequency).
> 
> I have 0 familiarity with d3d, but it does indeed seem like part of
> the point of ARB_sample_shading is to run on less than 100% of the
> samples. This appears to be supported by NVA3+ hardware based on our
> current docs in rnndb, although the current piglit tests don't really
> exercise all the functionality. [I haven't checked, but I assume NVC0+
> as well.] Although only 1/2/4/8 are supported, based on those docs
> (e.g. you can't tell it to run on 5 samples).
> 
> An alternative to passing in the result of
> _mesa_get_min_invocations_per_fragment is to just pass the percentage
> (which, I guess for D3D10.1 would either be 0 or 100?),
Yes I guess it would be just 0 or 100.

> and redoing
> the calculation inside of gallium based on the same criteria.

That would be doable too indeed.
Though indeed OpenGl also allows "sample" interpolation qualifier, so it
looks like we're going to need this anyway (ARB_shading_language_420pack
for instance). Don't ask me though how this is supposed to work if
simply enabling ARB_sample_shading already causes all inputs to be
interpolated per sample anyway?
The gl spec (4.4 core, end of chapter 14.3.1 and 14.3.1.1 has some
explanation how it could work - so if there's at least one "sample"
qualifier in the fs inputs, that causes those inputs to be evaluated per
sample (which implies running the fragment shader at sample frequency).
The interactions with SAMPLE_SHADING are not resolved, though, and imho
anything but obvious.

So if the ability to run the fragment shader at something else than
per-pixel or per-sample frequency is useful, then something is needed to
set this value one way or another. Otherwise new interpolation modes
should do just fine and make things easier.

Roland