[PATCH 1/7] wined3d: Don't call wined3d_texture_decref() in the CS thread.

[Henri Verbeet]

On Mon, 11 Oct 2021 at 18:17, Jan Sikorski <jsikorski at codeweavers.com> wrote:
> > On 11 Oct 2021, at 17:40, Henri Verbeet <hverbeet at 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.