Corbin Simpson wrote:
On Mon, Jun 14, 2010 at 4:09 AM, Roland Scheidegger <srol...@vmware.com> wrote:
I'm planning to merge this branch soon, though I'll fix some broken things
first. In any case, the probably most fundamental change is that
get_tex_surface not only got renamed (to create_surface) but also moved to
context. In short, pipe_surface is not (or no longer as there were free
standing surfaces once upon a time in gallium) some kind of "2d surface"
which should be used in (non-rendering) state trackers to move any kind of
images around. pipe_surface is meant to be used to attach resources to
depthstencil and color render target outputs (similar to DX10 DepthStencil
and RenderTarget Views).
One thing though I'm not quite sure is if for array textures, the same field
should be used in the resource as for storing depth of 3d textures (the
depth0 field). Using the same "layer" field both for faces, array index and
3d depth seems to make a lot of sense for transfers, the sampler views and
in pipe_surface, but I'm not sure the same field should be used in the
resource itself. I've actually converted some code to do that (but not quite
all for instance the mesa state tracker is broken there).
The reason for using the same field would be that it's mutually exclusive
anyway (unless someone introduces 3d array textures...), hence not really 2
fields are necessary. But OTOH depth behaves differently to arraysize (and
cube faces) because it doesn't get minified for smaller mips. So if someone
has convincing reasons what should be preferred I'll follow it :-).
One this is for sure though we need some way to store array size, and cube
maps will follow that pattern since for resource handling they are pretty
much the same as a 2d array texture with array size of 6.
This all seems fine. Drivers for pre-texture-array chipsets can handle
all this by forcing off trilinear filtering, right?
This is not connected to trilinear filtering.
But yes, basically drivers not being able to do this should not need
(further) changes, since the state tracker should not give them state
they can't handle (like binding multiple layers to a rendertarget view)
as usual.
I'll do some further changes though, pipe_surface is still not quite
what we need.
Roland
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
