On 27 January 2010 13:07, Stefan Dösinger <stefandoesin...@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.
