[Mesa-dev] State tracker pipe_surface woes...

[Jose Fonseca]

----- Original Message -----
> Hi,
> 
> While debugging some code I ran across the following situation:
> 
> - pipe_context c1 is created
> - pipe_surface s1 is created
> - strb-> surface is set to s1 (s1's refcount goes up)
> - pipe_context c1 is destroyed
> - strb is destroyed
> - strb->surface is destroyed (so s1's refcount is now 0 and we want
> to
> destroy it)
> 
> At that point s1 references c1 which is not available any more, so
> when we try to call ctx->surface_destroy to destroy s1 we crash.
> 
> We discussed this a bit on IRC, and we agreed that the proper
> solution, since surfaces outlive their context, is to make surfaces
> screen-bound instead. I'm going to  implement that unless someone
> objects.
> 
> As a side note, the same issue will happen with sampler_views, so
> it'll get a similar fix.

Sampler views and surfaces were previously objects bound to screen, and we changed that because of poor multithreading semantics.  Per-context sampler views / render targets actually matches the 3D APIs semantics better, so I don't think that reverting is the solution.

It looks to me that the issue here is that pipe_context should not be destroyed before the surfaces. strb->surface should only be used by one context, and should be destroyed before that context is destroyed.

IIUC, strb matches GL renderbuffer semantics and can be shared by multiple context. If so, strb is treating pipe_surfaces as a entity shareable by contexts when really shouldn't.

The solution is:
- strb can only have pipe_resources, plus the key for the surface (face, level, etc)
- the pipe_surfaces that are derived should be stored/cached in the GLcontext.
- when the GLcontext / pipe_context is being destroy, the pipe surfaces can be destroyed before

This may seem a bit complex, but the benefit is that by having surfaces unshareable between contents, they need no mutex protection, and therefore are much more efficient.

Jose