Am 23.10.2011 02:25, schrieb Kenneth Graunke: > On 10/21/2011 08:45 PM, Chad Versace wrote: >> For all texture targets except GL_TEXTURE_CUBE_MAP, the 'nr_images' and >> 'depth' fields of intel_mipmap_level were identical. In the exceptional >> case, nr_images == 6 and depth == 1. >> >> It is simple to determine if a texture is a cube or not, so the presence >> of two fields here was not helpful. Worse, it was confusing. >> >> This patch removes 'nr_images' and assigns to 'depth' a consistent >> meaning: depth is the number of two-dimensional slices at each miplevel. >> The exact semantics of depth varies according to the texture target: >> - For GL_TEXTURE_CUBE_MAP, depth is 6. >> - For GL_TEXTURE_2D_ARRAY, depth is the number of array slices. It is >> identical for all miplevels in the texture. >> - For GL_TEXTURE_3D, it is the texture's depth at each miplevel. It's >> value, like width and height, varies with miplevel. >> - For other texture types, depth is 1. > > I'm not sure I like this. What about Cube Arrays? > http://www.opengl.org/registry/specs/ARB/texture_cube_map_array.txt > > Admittedly it's not core until 4.0 (AFAICT), but there's nothing > preventing us from doing it earlier...
Not really commenting on the patch itself, but what's the problem with cube map arrays? You simply would have a depth which is 6*nr_array_slices (and can figure out an individual face likewise). The only thing which wouldn't work is 3d arrays, but I've not yet seen that anywhere... Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
