Before, the set_sampler_views() and restore_sampler_views() functions
used MAX2(old,new) to tell the driver how many samplers or sampler
views to set. This could result in cases such as:
pipe->set_fragment_sampler_views(pipe, 4, views={foo, bar, NULL, NULL})
Many/most gallium drivers would take this as-is and set
ctx->num_sampler_views=4 and ctx->sampler_views={foo, bar, NULL, NULL, ...}.
Later, loops over ctx->num_sampler_views would have to check for null
pointers. Worse, the number of sampler views and number of sampler CSOs
could get out of sync:
ctx->num_samplers = 2
ctx->samplers = {foo, bar, ...}
ctx->num_sampler_views = 4
ctx->sampler_views={Foo, Bar, NULL, NULL, ...}
So loops over the num_samplers could run into null sampler_views pointers
or vice versa.
This fixes a failed assertion in the SVGA driver when running the Mesa
engine demo in AA line mode (and possibly other cases).
It looks like all gallium drivers are careful to unreference views
and null-out sampler CSO pointers for the units beyond what's set
with the pipe::bind_x_sampler_states() and pipe::set_x_sampler_views()
functions.
I'll update the gallium docs to explain this as well.
{
uint i;
+ /* reference new views */
for (i = 0; i < count; i++) {
pipe_sampler_view_reference(&info->views[i], views[i]);
}
+ /* unref extra old views, if any */
for (; i < info->nr_views; i++) {
pipe_sampler_view_reference(&info->views[i], NULL);
}
- set_views(ctx->pipe,
- MAX2(count, info->nr_views),
- info->views);
-
info->nr_views = count;
+
+ /* bind the new sampler views */
+ set_views(ctx->pipe, count, info->views);
}
void
pipe_sampler_view_reference(&info->views[i], NULL);
}
- set_views(ctx->pipe,
- MAX2(info->nr_views, info->nr_views_saved),
- info->views);
+ /* bind the old/saved sampler views */
+ set_views(ctx->pipe, info->nr_views_saved, info->views);
info->nr_views = info->nr_views_saved;
info->nr_views_saved = 0;