On 01/08/2013 02:26 PM, Paul Berry wrote: > In the process of reviewing Chris Forbes' patches to implement > ARB_texture_multisample, we discovered considerable confusion in the > code that refers to surface dimensions: some functions expected > logical surface dimensions (in units of pixels, as used by GL API > functions such as glTexImage3D()), and others expected physical > surface dimensions (which have been scaled up according to the MSAA > layout, to make room for multiple samples to be stored per pixel). It > wasn't always clear from reading the code whether logical or physical > surface dimensions were needed, and to make matters worse, logical > surface dimensions weren't always available. Similar (but subtly > different) confusions existed in the case of cubemap textures (where > the logical depth is 1 but the physical depth is 6). > > I'm aware of at least two bugs arising from this confusion (an > assertion failure with depthstencil cubemap textures, and a benign > overallocation of memory for MCS buffers on Gen7). > > This patch series fixes those two bugs, and cleans things up so that: > > - All intel_mipmap_tree.c functions deal with logical surface > dimensions. > > - All mipmap layout functions deal with physical surface dimensions. > > - Both logical and physical dimensions are stored in the > intel_mipmap_tree structure. > > I'm hoping that Chris can rebase his ARB_texture_multisample patches > on top of this series, and in doing so avoid some of the hacks he had > to do to get texture multisampling to work. > > This patch series can also be found in branch > "physical_logical_surface_dims" of > git://github.com/stereotype441/mesa.git.
The cleanups and conventions established by the series look good. And the commit message for patch 3 makes really clear the what and why. Reviewed-by: Chad Versace <chad.vers...@linux.intel.com> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
