On 7 April 2015 at 12:53, Stefan Dösinger stefandoesinger@gmail.com wrote:
This one is different in that it operates on a texture, and anything that would need to read the color key would then need to either wait for the texture to become idle, or run from the CS itself.
The color key is currently read by the texture loading code, which is either called by draws (called through the CS) or by blits (which we want to call through the CS at some point). I don't see a clean way to move the read to the main thread.
In principle it's probably ok if it can't be directly read/written by the main thread unless the texture is idle. (But note that this also affects e.g. preload calls.) It would probably be a good idea to make that explicit though. E.g. one approach could perhaps be something like this:
struct wined3d_texture { ... /* Explanation here. */ struct { struct wined3d_color_key dst_blt_color_key; ... } async; };
So that anything touching those fields is aware of what is and isn't safe to touch from the main thread.
I haven't looked at the async CS patchset in while now, but I gather that you're sending pretty much anything that might need a GL context at some point through the CS, supposedly because of issues with various proprietary drivers. It's probably no huge surprise that if that's the case, that justification doesn't fill me with great joy. Regardless, I'd like to at least keep it possible to do resource updates from threads other than the CS thread, at least until the performance trade-offs are well understood, particularly for applications that use D3D from multiple threads.