[PATCH 1/5] wined3d: Send present operations through a command stream.

Henri Verbeet hverbeet at gmail.com
Fri Sep 27 09:15:25 CDT 2013

On 27 September 2013 15:23, Stefan Dösinger <stefandoesinger at gmail.com> wrote:
> Hash: SHA1
> Am 2013-09-27 14:19, schrieb Henri Verbeet:
>> Perhaps, I'm not sure. For that kind of comment to be useful it
>> should have a clear set of implications, and I'm not sure it has
>> that until we work out the details of the multi-threaded
>> implementation.
> Works for me.
> Afaics the main implication will be that functions that are called
> through the CS shouldn't place any commands into the stream. Depending
> on the synchronization between writer and reader this may work, but
> waiting for the CS to finish inside the command stream will never work
> right.
Yeah, the main things I can think of is that you shouldn't generally
generate CS ops from inside the CS, and you can't access device state.
I'm not sure in how far those are going to be issues that require this
kind of annotation though. The only things that should access device
state are going to be the various device getters and stateblock
capture, but those should only ever have external callers. The main
cases for generating CS ops from inside the CS are probably blits, and
perhaps resource maps. The basic rule should probably be that anything
that makes wined3d_cs_emit_*() calls should only have callers outside
of wined3d, which shouldn't be too hard to verify.

More information about the wine-devel mailing list