On Thu, Mar 11, 2010 at 03:16:32PM +0000, Keith Whitwell wrote: > On Thu, 2010-03-11 at 06:05 -0800, michal wrote: > > Keith Whitwell wrote on 2010-03-11 14:21: > > > On Thu, 2010-03-11 at 03:16 -0800, michal wrote: > > > > > >> Hi, > > >> > > >> I would like to merge the branch in subject this week. This feature > > >> branch allows state trackers to bind sampler views instead of textures > > >> to shader stages. > > >> > > >> A sampler view object holds a reference to a texture and also overrides > > >> internal texture format (resource casting) and specifies RGBA swizzle > > >> (needed for GL_EXT_texture_swizzle extension). > > >> > > > > > > Michal, > > > > > > I've got some issues with the way the sampler views are being generated > > > and used inside the CSO module. > > > > > > The point of a sampler view is that it gives the driver an opportunity > > > to do expensive operations required for special sampling modes (which > > > may include copying surface data if hardware is deficient in some way). > > > > > > This approach works if a sampler view is created once, then used > > > multiple times before being deleted. > > > > > > Unfortunately, it seems the changes to support this in the CSO module > > > provide only a single-shot usage model. Sampler views are created in > > > cso_set_XXX_sampler_textures, bound to the context, and then > > > dereferenced/destroyed on the next bind. > > > > > > > > The reason CSO code looks like this is because it was meant to be an > > itermediate step towards migration to sampler view model. Fully > > converting all existing state trackers is non-trivial and thus I chose > > this conservative approach. State trackers that do not care about extra > > features a sampler view provides will keep using this one-shot CSO > > interface with the hope that creation of sampler objects is lighweight > > (format matches texture format, swizzle matches native texel layout, > > etc.). > > On the surface, this hope isn't likely to be fulfilled - lots of > hardware doesn't support non-zero first_level. Most cases of drivers > implementing sampler views internally are to catch this issue. > > Of course, it seems like your branch so leaves the existing > driver-specific sampler view code in place, so that there are > potentially two implementations of sampler views in those drivers. > > I guess this means that you can get away with the current implementation > for now, but it prevents drivers actually taking advantage of the fact > that these entities exist in the interface -- they will continue to have > to duplicate the concept internally until the state trackers and/or CSO > module start caching views. > > > Ideally, everybody moves on and we stop using CSO for sampler > > views. I prefer putting my effort into incremental migration of state > > trackers rather than caching something that by definition doesn't need > > to be cached. > > The CSO module exists to manage this type of caching on behalf of state > trackers. I would have thought that this was a sensible extension of > the existing purpose of the CSO module. > > Won't all state-trackers implementing APIs which don't expose sampler > views to the application require essentially the same caching logic, as > is the case with regular state? Wouldn't it be least effort to do that > caching once only in the CSO module? > > Keith >
I didn't read anything about sampler view stuff, thus i can be completely wrong here, but from driver pov i prefer having most of the state going through create,bind,destroy pattern ie having the CSO doing the caching. Cheers, Jerome ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev