[Mesa-dev] RFC: gallium-array-textures changes
sroland at vmware.com
Wed Nov 24 18:28:11 PST 2010
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 13397 bytes
Desc: not available
More information about the mesa-dev