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

[Stéphane Marchesin]

2011/9/2 Jose Fonseca <jfonseca at vmware.com>:
> ----- 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)

Another bit I don't get: since pipe_resources don't have a pointer to
the context, how do you go back to the corresponding context/surface
when all you have is the pipe_resource?

Stéphane