<div dir="ltr"><div dir="ltr">On Sun, Mar 10, 2019 at 1:20 AM Mathias Fröhlich <<a href="mailto:Mathias.Froehlich@gmx.net">Mathias.Froehlich@gmx.net</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Brian,<br>
<br>
One question also for my own education inline below:<br>
<br>
On Friday, 8 March 2019 23:52:09 CET Brian Paul wrote:<br>
> After a while of running google-chrome and viewing Bing maps, we'd see<br>
> "context mismatch in svga_sampler_view_destroy()" messages and<br>
> eventually crash because we leaked too many sampler views (the kernel<br>
> module would have too many sampler views).<br>
> <br>
> When a texture object is being deleted, we call<br>
> st_texture_release_all_sampler_views() to release all the sampler<br>
> views.  In the list, there may sampler views which were created from<br>
> other contexts.<br>
> <br>
> Previously, we called pipe_sampler_view_release(pipe, view) which would<br>
> use the given pipe context to destroy the view if the refcount hit<br>
> zero.  The svga error was triggered because we were calling<br>
> pipe->sampler_view_destroy(pipe, view) and the pipe context didn't<br>
> match the view's parent context.<br>
> <br>
> Instead, call pipe_sampler_reference(&view, NULL).  That way, if<br>
> the refcount hits zero, we'll use the view's parent context to<br>
> destroy the view.  That's what we want.<br>
<br>
That sounds plausible so far.<br>
<br>
What I wonder, is calling into an 'arbitrary' different context and do work there<br>
thread safe for any gallium driver?<br></blockquote><div><br></div><div>Right.  Before this patch there was the problem of trying to destroy a sampler view with a context different from the one which created it.  That's fixed, but now there's the multi-threading issue as you say, and which I believe, is a less-common situation.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Especially since pipe_sampler_view_reference in its documentation says that the<br>
views provided need to originate from the same context and that this must<br>
be the 'current'.<br>
<br>
I have been taking a quick look into iris and radeonsi and both seem to be safe<br>
in terms of threads for dereferencing the views finally.<br>
But either the documentation of pipe_sampler_view_reference should be updated <br>
or I may miss an other piece of the puzzle to see that it is still save to do so.<br></blockquote><div><br></div>Last week I posted a patch series for the VMware driver which handled the thread issue with a list of "zombie" sampler views.  Jose suggested moving that up into the state tracker, and that is a better long-term solution.</div><div class="gmail_quote"><br></div><div class="gmail_quote">I'm almost done with a patch series that does that.  I'll likely post it tomorrow.</div><div class="gmail_quote"><br></div><div class="gmail_quote">-Brian</div><div class="gmail_quote"><br></div></div>