[PATCH 5/5] wined3d: Set color keys through the command stream.

[Henri Verbeet]

On 7 April 2015 at 12:53, Stefan Dösinger <stefandoesinger at 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.