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

[Cherniak, Bruce]

> On Apr 28, 2017, at 3:20 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> 
> 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.

We always value and appreciate your input.  And, while we’re primarily
focused on sci vis software, we’d like to be compliant as possible; which
means running a wide variety of applications… even *gasp* games.

I’ll definitely give Unigine a try.  Not expected great performance, but
we can at least strive for correct functionality.

> 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.

“march towards perfections” :)

> 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


I’m sure I’ll continue to ping you for advice and insight.

Thanks again,

Bruce