[Mesa-dev] RFC: gallium-array-textures changes

[Brian Paul]

On 11/29/2010 06:27 AM, Keith Whitwell wrote:
> On Wed, 2010-11-24 at 18:28 -0800, Roland Scheidegger wrote:
>>                               From:
>> Roland Scheidegger
>> <sroland at vmware.com>
>>                                 To:
>> mesa-dev at lists.freedesktop.org
>> <mesa-dev at lists.freedesktop.org>,
>> Keith Whitwell<keithw at vmware.com>
>>                            Subject:
>> RFC: gallium-array-textures changes
>>                               Date:
>> Wed, 24 Nov 2010 18:28:11 -0800
>> (25/11/10 02:28:11)
>>
>>
>> Hi,
>>
>> gallium currently lacks array textures, and the gallium-array-textures
>> branch is trying to fix this (I've attached just the interface changes
>> here as the branch got ugly over time - guess will need a squash
>> merge).
>>
>> In short there's a new array_size field in pipe_resource - note this
>> is
>> meant to be mutually exclusive with the depth0 field (that is only one
>> of them can be larger than one), since 3d arrays don't exist and the
>> rest of the interface (surfaces/sampler views/transfers) are
>> restricted
>> to 3 dimensions in total.
>> Also, pipe_subresource is eliminated - this is a concept which maps
>> well
>> to dx10 but not much else. For example, in OpenGL you can have
>> transfers
>> (by using TexImage3D for 2d arrays) which cover more than one array
>> slice. In that sense, d3d10 distinguishes between array slices and the
>> depth slices of a 3d texture, whereas OGL does not. So, at the gallium
>> interface level, transfers / copy region etc. are allowed to span
>> several array slices (or cube faces which is basically the same), just
>> like it is for depth slices (this uses the "layer" term for meaning
>> either depth, face, or array member). This also means some of the
>> functions which had both face and zslice arguments now instead use a
>> single layer argument.
>> Aside from these changes, this also finally cleans up the surface
>> interface. Creating and destroying surfaces is now handled much the
>> same
>> as sampler views, i.e. per context functions. And more, previously
>> surfaces (due to historical reasons) were used for other things, but
>> now
>> they are really meant to be used as render (or depth_stencil) targets
>> only (much the same as sampler views are used to bind textures (or now
>> buffers too at least in the interface though nothing implements this
>> yet)). pipe_surface still has some fields in there which should go
>> away
>> (width/height) but that was too intrusive for now (was hard enough to
>> get rid of offset...).
>> Surfaces and sampler views now also can span several layers (well for
>> cube and 3d textures this was always implicit in the sampler views
>> before), which is needed for dx10.
>>
>> I suspect though I've broken a fair number of things (nvfx driver,
>> python and d3d1x state trackers being the most likely), everything
>> compiles for me but someone familiar with these pieces taking a look
>> before any merge would be appreciated.
>>
>> Any questions?
>>
>> Roland
>>
>
>
> Roland,
>
> This all looks good to me, thanks for keeping on with this change.  I
> agree it would be good for interested folks to check this over before it
> merges, though I think that there should be a time-limit to that --
> let's propose merging this on Wednesday if there are no further
> comments.

Looks good to me too.

-Brian