On Thu, 2010-03-11 at 08:59 -0800, Jerome Glisse wrote: > 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.
Jerome, The driver view in both cases is as you describe - it's just a question of whether the state tracker does the create/bind/destroy itself, or if we can build a helper module to do that logic for it. Keith ------------------------------------------------------------------------------ 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
