<div class="gmail_quote">On Mon, Jun 14, 2010 at 9:58 PM, Corbin Simpson <span dir="ltr"><<a href="mailto:mostawesomedude@gmail.com" target="_blank">mostawesomedude@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div>On Mon, Jun 14, 2010 at 4:09 AM, Roland Scheidegger <<a href="mailto:sroland@vmware.com" target="_blank">sroland@vmware.com</a>> wrote:<br>
> I'm planning to merge this branch soon, though I'll fix some broken things<br>
> first. In any case, the probably most fundamental change is that<br>
> get_tex_surface not only got renamed (to create_surface) but also moved to<br>
> context. In short, pipe_surface is not (or no longer as there were free<br>
> standing surfaces once upon a time in gallium) some kind of "2d surface"<br>
> which should be used in (non-rendering) state trackers to move any kind of<br>
> images around. pipe_surface is meant to be used to attach resources to<br>
> depthstencil and color render target outputs (similar to DX10 DepthStencil<br>
> and RenderTarget Views).<br>
> One thing though I'm not quite sure is if for array textures, the same field<br>
> should be used in the resource as for storing depth of 3d textures (the<br>
> depth0 field). Using the same "layer" field both for faces, array index and<br>
> 3d depth seems to make a lot of sense for transfers, the sampler views and<br>
> in pipe_surface, but I'm not sure the same field should be used in the<br>
> resource itself. I've actually converted some code to do that (but not quite<br>
> all for instance the mesa state tracker is broken there).<br>
> The reason for using the same field would be that it's mutually exclusive<br>
> anyway (unless someone introduces 3d array textures...), hence not really 2<br>
> fields are necessary. But OTOH depth behaves differently to arraysize (and<br>
> cube faces) because it doesn't get minified for smaller mips. So if someone<br>
> has convincing reasons what should be preferred I'll follow it :-).<br>
> One this is for sure though we need some way to store array size, and cube<br>
> maps will follow that pattern since for resource handling they are pretty<br>
> much the same as a 2d array texture with array size of 6.<br>
<br>
</div></div>This all seems fine. Drivers for pre-texture-array chipsets can handle<br>
all this by forcing off trilinear filtering, right?<br></blockquote><div><br>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.<br>
<br>-Marek<br>
</div></div>