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

[Keith Whitwell]

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.

Keith