Ian Romanick <i...@freedesktop.org> writes: > On 05/21/2013 04:52 PM, Paul Berry wrote: >> This series implements fast color clears, a Gen7+ feature which >> reduces memory bandwidth by deferring the memory writes involved in a >> glClear() until the same memory is later touched during rendering. >> >> From a broad overview point of view, fast color clears work in a >> similar way to HiZ: an auxiliary "MCS" buffer keeps track of which >> parts of the buffer have been cleared but haven't yet had the >> necessary memory writes performed. Whenever a color buffer needs to >> be accessed by the CPU, or by a part of the GPU that is not >> fast-color-aware, we have to perform a "resolve operation" to force >> any pending memory writes to occur. >> >> This patch series adopts a slightly different strategy (compared to >> HiZ) for making sure the resolves happen when needed. Instead of >> modifying each code path that might need to do a resolve so that it >> does one if needed, we create an accessor function that does the >> resolve if needed and then provides the caller with access to the >> miptree's underlying memory region. This lets us have a lot more >> confidence that we didn't miss any code paths, which is important >> since color buffers are accessed by a large number of code paths. To >> discourage future maintainers from trying to bypass the accessor >> function, it is inline (so that overhead is negligible), and the field >> it provides access to has been renamed to region_private. >> >> Patch 01 ifdefs out some code so that it does not appear in the i915 >> (pre-Gen4) driver--this makes it easier to be confident that these >> changes won't regress i915. Patch 02 introduces the aforementioned >> accessor function. Patches 03-11 are the guts of the implementation, >> and patch 12 enables the new feature. >> >> No piglit regressions. I have additional piglit tests which validate >> specific important corner cases--I hope to get those out to the list >> later this week. > > I sent some comments and review for the tests, and I've sent some other > comments about these patches. My only concern is whether the case of > swapping a non-current drawable (that had a fast-clear as the last > render) produces the correct result. In the piglit thread, I suggested > adding a test specifically for this case. > > I suspect that if fast-clear fails in that case, then multisampling also > fails. Both can probably be fixed as follow-on work. Does that seem > plausible?
Swapping a non-current drawable doesn't work in direct rendering, at all, since as far back as I was able to figure out. I saw no way forward toward making it possible. I don't think we should distract this series with this issue.
pgp8F8UvG0yd6.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
