In the future, we won't have to save all the sampler views anyway. Note that cso_context only saves the states it needs to save meta ops. It doesn't save the clip state and it also doesn't save all vertex buffers except for the first one, because only the first one needs to be saved and restored for certain meta ops. Even though it's currently hardcoded to be the first vertex buffer slot, it can be changed to anything, e.g. the last one = 15. The users of cso_context are required to call cso_get_aux_vertex_buffer_slot() to get the slot index for meta ops and are only allowed to bind resources to that slot, because the other slots are not saved. We will probably do something like that for sampler views and sampler states too, and the nr_views variable will be removed.
Marek On Tue, Nov 26, 2013 at 3:44 PM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 26.11.2013 06:24, schrieb Zack Rusin: >> The entire series looks good to me. >> >>> Now that it is possible to query drivers for the max sampler view it should >>> be safe to increase this without crashing. >>> Not entirely convinced this really works correctly though if state trackers >>> using non-linked sampler / sampler_views use this. >> >> I'm not sure if I get this. What would be the problem in that case? >> > > It looked to me like the code isn't really prepared for this, though > actually I guess it would be more of a problem with not updating all > views or samplers from 0 to count rather than different number of views > / samplers. (The code stores the "count" paramater as nr_views etc. and > will then save/restore views based on nr_views starting at zero). > In any case this change shouldn't make it worse. > > Roland > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
