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. [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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev