[2/5] WineD3D: Add an internal event query finish function

Henri Verbeet hverbeet at gmail.com
Wed Jan 27 06:45:54 CST 2010


On 27 January 2010 13:07, Stefan Dösinger <stefandoesinger at gmx.at> wrote:
> Am 27.01.2010 um 11:19 schrieb Henri Verbeet:
>> You shouldn't need that. It only flushes for the current context anyway.
> From section 5.2.2 in the extension:
>>    If the sync object being blocked upon will not be signaled in finite
>>    time (for example, by an associated fence command issued previously,
>>    but not yet flushed to the graphics pipeline), then ClientWaitSync
>>    may hang forever.
> I don't know if there is any driver that waits forever for more commands before flushing at some point, but I noticed that with single buffering and no glFlush or glFinish fglrx keeps queuing commands until it runs out of memory. So I think we need it.
>
You certainly need to flush, but that's not the point. Using
GL_SYNC_FLUSH_COMMANDS is either unnecessary if you already flush
after glFenceSync(), or doesn't solve the problem for fences in
different contexts if you don't. Note that the existing code doesn't
have to flush after glFenceSync() because we use a 0 timeout in
GetData().

> I'd say we should get rid of the parent objects entirely and client libs can use SetPrivateData/GetPrivateData to find their interfaces in places like GetRenderTarget, GetTexture, etc. That way we don't make any assumptions about client library objects.
>
There would be some problems with such a scheme, but it's really not
relevant to this series. I still think you're trying way too hard to
fit IWineD3DQuery into a role for which it was never meant, for no
good reason.

>>> +/* The caller provides a context and GL locking and binds the buffer */
>>> +static void buffer_sync_apple(struct wined3d_buffer *This, DWORD flags)
>>> +{
>> ...
>>> +    LEAVE_GL();
>>> +    hr = wined3d_event_query_finish(This->query);
>>> +    ENTER_GL();
>> ...
>>> +        LEAVE_GL();
>>> +        IWineD3DQuery_Release(This->query);
>>> +        ENTER_GL();
>> ...
>>> +}
>> Don't do that. Patch 6 adds another one of those.
> I disliked the idea of having a LEAVE_G(); buffer_sync(); ENTER_GL() in the caller, when the two most common cases(NOOVERWRITE and DISCARD) don't need them, but ok.
>
You shouldn't just move the problem to the caller either, of course.



More information about the wine-devel mailing list