On Mon, 11 Oct 2021 at 18:17, Jan Sikorski jsikorski@codeweavers.com wrote:
On 11 Oct 2021, at 17:40, Henri Verbeet hverbeet@gmail.com wrote: This seems fragile. We'd need to keep this in sync with the other cleanup path, and that path is not trivial. If this is purely about avoiding taking the lock on the CS thread, it would seem preferable to just check for that, using something similar to wined3d_from_cs()/wined3d_not_from_cs().
It’s not just that, adapter_destroy_texture calls wined3d_cs_destroy_object, which is wined3d_cs_emit_callback, and that races with the application thread emitting commands into the queue. Maybe that too could be made to behave differently depending on the thread and execute the callback immediately if it’s the CS, but it also seemed error prone and convoluted to me. I’ll see what more could be done to share this code.
I don't think that's supposed to race[1], what happens exactly?
[1] In particular, note that wined3d_cs_mt_require_space()/wined3d_cs_mt_finish() will call wined3d_cs_st_require_space()/wined3d_cs_st_finish() when called from the CS thread. It has to work that way to allow calling those from the CS at all; consider what would happen to e.g. wined3d_texture_load_location() calls backed by the blitter otherwise, or e.g. trying to submit an operation while the queue is full.