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

Paul Berry stereotype441 at gmail.com
Tue Jan 8 14:26:59 PST 2013

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

- 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

[PATCH 1/3] intel: Move compute_msaa_layout earlier in file.
[PATCH 2/3] intel: Add a force_y_tiling parameter to intel_miptree_create().
[PATCH 3/3] intel: Clean up confusion between logical and physical surface dimensions.

More information about the mesa-dev mailing list