[Mesa-dev] [PATCH 3/3] intel: Clean up confusion between logical and physical surface dimensions.
stereotype441 at gmail.com
Fri Jan 11 07:57:09 PST 2013
On 10 January 2013 20:23, Chris Forbes <chrisf at ijw.co.nz> wrote:
> Hi Paul,
> They do work -- they just take the same path as TEXTURE_2D_ARRAY by
> this point. It's possible that we're missing some assert(depth0 % 6 ==
> 0) for sanity there.
> Have a look at this piglit:
> tests/spec/arb_texture_cube_map_array/cubemap.c; it uses a 2-layer
> cubemap array, and depth0 is 12 in intel_miptree_create_internal.
> -- Chris
Aha, ok. I understand now. Cube map arrays work just fine, and the tests
are thorough enough. The detail I wasn't aware of is that with cubemap
arrays, client code is expected to take care of multiplying the depth by 6
(see ARB_texture_cube_map_array issue 4). So from Mesa's point of view,
the logical depth (the depth specified by the user in the call to
glTexImage3D()) is equal to the physical depth. Only non-array cubemaps
have this depth=1 vs depth=6 ambiguity. So the code is fine as is.
Chris, in regards to some assert(depth0 % 6 == 0) being missing, I'm not
concerned. texture_error_check (teximage.c) verifies that depth % 6 == 0,
and after that the depth just gets passed straight down to
intel_miptree_create_internal() without anyone mucking with it.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mesa-dev