[Mesa-dev] RFC: ARB_sample_shading in gallium

[Ilia Mirkin]

On Fri, Mar 28, 2014 at 6:41 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> 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

I believe the use-case for the partial thing is in issue #3 of the
ARB_sample_shading spec (although I'm not 100% sure what they're
talking about, they do seem to be talking about a gl_Sample*-less
shader). Based on the _mesa_get_min_invocations_per_fragment impl, as
soon as gl_Sample* gets used by the shader, it flips into per-sample
mode (which wasn't at all my reading of the spec, but I assume this
was done by people who understand things). Presumably there's some
benefit to doing the per-some-sample mode, otherwise the spec wouldn't
have introduced the MinSampleShadingARB call. Although it'd be
entirely within the spec (if not efficient) to ignore it entirely and
just assume that it's always 0 or 1.

I think I'm going to start by adding a set_sample_shading() call that
takes a [0,1] float, and see where that takes me. In any case, it
should be fairly simple to change should it be decided that a
different thing is needed.

  -ilia