<div dir="ltr">On 10 January 2013 20:23, Chris Forbes <span dir="ltr"><<a href="mailto:chrisf@ijw.co.nz" target="_blank">chrisf@ijw.co.nz</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi Paul,<br>
<br>
They do work -- they just take the same path as TEXTURE_2D_ARRAY by<br>
this point. It's possible that we're missing some assert(depth0 % 6 ==<br>
0) for sanity there.<br>
<br>
Have a look at this piglit:<br>
tests/spec/arb_texture_cube_map_array/cubemap.c; it uses a 2-layer<br>
cubemap array, and depth0 is 12 in intel_miptree_create_internal.<br>
<span class=""><font color="#888888"><br>
-- Chris<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">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.<br>
<br></div><div class="gmail_extra">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.<br>
</div></div>