[Mesa-dev] [PATCH] intel: Kill intel_mipmap_level::nr_images

[Ian Romanick]

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. :)