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 ------------------------------------------------------------------------------ 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
