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
<[email protected]>
                                To:
[email protected]
<[email protected]>,
Keith Whitwell<[email protected]>
                           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

_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to