> On Apr 27, 2017, at 7:50 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > > On Thu, Apr 27, 2017 at 8:45 PM, Cherniak, Bruce > <bruce.chern...@intel.com> wrote: >> >>> On Apr 27, 2017, at 7:38 PM, Ilia Mirkin <imir...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev