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

[Cherniak, Bruce]

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

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.

Thanks,

Bruce