On Mon, Jun 14, 2010 at 9:58 PM, Corbin Simpson <mostawesomed...@gmail.com>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? > 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
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
