On Fri, Apr 28, 2017 at 3:58 PM, Cherniak, Bruce <bruce.chern...@intel.com> wrote: > >> 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:
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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev