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