On Wed, 2010-11-24 at 18:28 -0800, Roland Scheidegger wrote: > From: > Roland Scheidegger > <[email protected]> > To: > [email protected] > <[email protected]>, > Keith Whitwell <[email protected]> > Subject: > RFC: gallium-array-textures changes > Date: > Wed, 24 Nov 2010 18:28:11 -0800 > (25/11/10 02:28:11) > > > Hi, > > gallium currently lacks array textures, and the gallium-array-textures > branch is trying to fix this (I've attached just the interface changes > here as the branch got ugly over time - guess will need a squash > merge). > > In short there's a new array_size field in pipe_resource - note this > is > meant to be mutually exclusive with the depth0 field (that is only one > of them can be larger than one), since 3d arrays don't exist and the > rest of the interface (surfaces/sampler views/transfers) are > restricted > to 3 dimensions in total. > Also, pipe_subresource is eliminated - this is a concept which maps > well > to dx10 but not much else. For example, in OpenGL you can have > transfers > (by using TexImage3D for 2d arrays) which cover more than one array > slice. In that sense, d3d10 distinguishes between array slices and the > depth slices of a 3d texture, whereas OGL does not. So, at the gallium > interface level, transfers / copy region etc. are allowed to span > several array slices (or cube faces which is basically the same), just > like it is for depth slices (this uses the "layer" term for meaning > either depth, face, or array member). This also means some of the > functions which had both face and zslice arguments now instead use a > single layer argument. > Aside from these changes, this also finally cleans up the surface > interface. Creating and destroying surfaces is now handled much the > same > as sampler views, i.e. per context functions. And more, previously > surfaces (due to historical reasons) were used for other things, but > now > they are really meant to be used as render (or depth_stencil) targets > only (much the same as sampler views are used to bind textures (or now > buffers too at least in the interface though nothing implements this > yet)). pipe_surface still has some fields in there which should go > away > (width/height) but that was too intrusive for now (was hard enough to > get rid of offset...). > Surfaces and sampler views now also can span several layers (well for > cube and 3d textures this was always implicit in the sampler views > before), which is needed for dx10. > > I suspect though I've broken a fair number of things (nvfx driver, > python and d3d1x state trackers being the most likely), everything > compiles for me but someone familiar with these pieces taking a look > before any merge would be appreciated. > > Any questions? > > Roland >
Roland, This all looks good to me, thanks for keeping on with this change. I agree it would be good for interested folks to check this over before it merges, though I think that there should be a time-limit to that -- let's propose merging this on Wednesday if there are no further comments. Keith _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
