[Mesa-dev] [PATCH v2] swr: move msaa resolve to generalized StoreTile

[Ilia Mirkin]

On Fri, Apr 28, 2017 at 3:58 PM, Cherniak, Bruce
<bruce.cherniak at intel.com> wrote:
>
>> On Apr 27, 2017, at 7:50 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>
>> On Thu, Apr 27, 2017 at 8:45 PM, Cherniak, Bruce
>> <bruce.cherniak at intel.com> wrote:
>>>
>>>> On Apr 27, 2017, at 7:38 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>>
>>>> Erm, so ... what happens if I render to FB1, then render to FB2, then
>>>> render to FB1 again (and I have blending enabled)? Doesn't the resolve
>>>> lose the per-sample information? Or does the resolve merely precompute
>>>> the resolved version on the off chance that it's needed, without
>>>> losing the source data?
>>>
>>> The resolve occurs into a secondary, driver private, surface.  All per-sample
>>> information is maintained in the original surfaces.
>>>
>>> Yes, the resolve is currently done "on the off chance that it’s needed”.
>>> There is likely an optimization to be had there, but it should be functionally
>>> correct.
>>
>> Got it. May I ask why this isn't done on-demand instead? Is it a pain
>> to plug into swr's execution engine? I'm just concerned that
>> StoreTile() may get called a lot, more than even there are draws, as
>> tiles are swapped in and out of "hotness", and I wouldn't be surprised
>> if resolves were needed only a fraction of the time.
>>
>> Cheers,
>>
>>  -ilia
>
>
> Good observation.  I haven’t yet seen this to be the case in the scientific
> visualization applications I’ve been running. But, I can envision where that
> becomes a performance concern.
>
> Do you mean a blit based “state_tracker initiated” on-demand resolve (via
> pipe_blit)?  If so, here are my thoughts:

Yes. The resolve is always initiated via a blit() call anyways (with a
dst surface with nr_samples == 0).

> 1) The software winsys and state trackers don't support multisample surfaces
>    for software renderers, nor will/should they (except for swr).  So, I
>    thought keeping most of the changes local to our driver would be most
>    desirable and safest, as far as swrast and llvmpipe are concerned.  Not
>    sure about wgl yet, but I don't see it.
>
> 2) A blit based resolve causes a pipeline reconfiguration (save/restore around
>    the blit) that is inherently less efficient than simply
>    storing-out/resolving HotTiles.
>
> 3) A blit based resolve needs to sample from the multisample surface using a
>    texture sampler with 2DMS/3DMS support.  We’re currently using llvmpipe's
>    sampler which doesn't need this support.  I’m looking into extending it, as
>    I know we need the functionality for compliance; it’s just not there yet.
>
> I may be off-base on any of these thoughts.  If so, please correct me.
>
> We’ll probably move to a “driver internal” on-demand resolve, implemented
> similar to StoreTiles.  It's a simple matter to only resolve for the times we
> know it's needed and the multisample surface is in HotTiles.  But, I need to
> work out the LoadTiles case for surfaces that aren’t currently in HotTiles.
> Tricky, since we're checking the resolve status of the secondary (resolved)
> surface and the HotTile state of the multisample surface.
>
> Thanks for the feedback.  Getting this completely correct and optimized is
> going to be iterative.  This current patch, while maybe not optimal, helps
> with functionality.  So, I think it's a step in the right direction.

I hope you realize I wasn't looking to derail your attempts at
progress, more like providing some things to think about on your march
towards perfection :) MS textures/fbo's are definitely a thing,
probably more so than MS winsys surfaces these days. At least for
games, maybe not visualization software, with which I have next to no
experience. Try it with e.g. Unigine Heaven or Valley (with MSAA
enabled). I'm fairly sure that at least Heaven uses MSAA textures.

I believe most hardware uses MSAA compression, based on the
observation that it's pretty common for all samples in a pixel to have
the same color, or bg color + fg color + coverage mask. TBH I'm not
sure how it all works. Something for the future when you get all the
basics right.

Some hardware has built-in resolve functionality (e.g. Adreno, maybe
other tilers as well) for moving a MS FBO out of a "hot tile", while
most hardware requires the pipeline reconfiguration + blit. Perhaps
it'd make sense to add a special FE command for computing the resolved
version of all the tiles, and have that state get dirtied when you
render. There are also extensions like
GL_EXT_multisampled_render_to_texture which support the
"insta-resolve" use-case more directly. However they're not
implemented in mesa AFAIK.

Cheers,

  -ilia