[Mesa-dev] gallium-array-textures branch

[Marek Olšák]

On Mon, Jun 14, 2010 at 9:58 PM, Corbin Simpson
<mostawesomedude at gmail.com>wrote:

> On Mon, Jun 14, 2010 at 4:09 AM, Roland Scheidegger <sroland at 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?
>

No, they can't. The 3rd dimension (depth) is not minified in mipmaps, so the
first and last mipmap may be e.g. 128x128x64 and 1x1x64, respectively. I
don't think DX9-level GPUs can do that.

-Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100620/db29fac6/attachment.html>