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

[Jan Sikorski]

> On 11 Oct 2021, at 20:29, Henri Verbeet <hverbeet at gmail.com> wrote:
> 
> 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.

Oh right, no, I didn’t observe any issues at runtime, I forgot that check was there and also didn’t notice there was a separate queue for the _st_ version. I guess conditional locking it is, which is maybe passable with an explanatory comment..

- Jan