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? ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson <mostawesomed...@gmail.com> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
