[Mesa-dev] [PATCH 0/3] intel: Untangle physical vs logical surface dimensions.

[Chad Versace]

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.versace at linux.intel.com>