[Mesa-dev] gallium-array-textures branch

Roland Scheidegger sroland at vmware.com
Mon Jun 14 04:09:25 PDT 2010

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.


More information about the mesa-dev mailing list