michal wrote on 2010-03-11 17:59: > Keith Whitwell wrote on 2010-03-11 16:16: > >> 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? >> >> > OK, I see your point. I will make the necessary changes and ping you > when that's done. > > Keith,
I changed my mind, went ahead and implemented sampler view caching in mesa state tracker, rather than inside cso context. I strongly believe that doing caching on cso side would be slower and more complicated. A state tracker has a better understanding of the relationship between a texture and sampler view. In case of mesa, this is trivial 1-to-1 mapping. Later, when we'll need more sampler views per texture, we can have a per-texture cache for that, and yes, the code for that would be in cso. There are two other state trackers that need to be fixed: xorg and vega. The transition should be similar to mesa -- I can help with doing that, but I can't do it myself. Once that's done we can purge one-shot sampler view wrappers. What do you think? ------------------------------------------------------------------------------ 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
