On 10/24/2011 10:12 AM, Roland Scheidegger wrote:
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...
What about http://www.opengl.org/registry/specs/SGIS/texture4D.txt?
Just kidding. :)
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
