2011/9/2 Jose Fonseca <jfons...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
