On 16 February 2010 14:59, Stefan Dösinger stefandoesinger@gmx.at wrote:
Patch 1:
if (!pData || !dwSize) return S_OK;
...
- if (data)
This should be unnecessary, since you already checked "pData" above. Otherwise the patch looks reasonable.
Patch 4:
GLenum gl_ret = GL_EXTCALL(glClientWaitSync(query->object.sync, GL_SYNC_FLUSH_COMMANDS_BIT, ~0U));
...
/* We don't expect a timeout for a ~584 year wait */
Actually, ~0U would be slightly more than 4 seconds.
Patch 7:
- for(i = 0; i < This->num_buffer_queries; i++)
- {
wined3d_event_query_issue(This->buffer_queries[i], This);- }
You should do this before the flush, otherwise the query might never finish if it's in a different context.
Concerning GL_SYNC_FLUSH_COMMANDS:
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().
The existing code has to honor D3DGETDATA_FLUSH if the app passes it. The 0 timeout doesn't help us if the app does something like this
BOOL data; do { IWineD3DQuery_GetData(event_query, D3DGETDATA_FLUSH, &data); } while(!data);
in a single threaded environment.
Sure, but if you want queries to work reliably across contexts you need to flush after issuing them.