[4/5] WineD3D: Implement manual fencing with GL_APPLE_flush_buffer_range

Stefan Dösinger stefandoesinger at gmx.at
Tue Jan 5 05:22:07 CST 2010

Am 05.01.2010 um 11:50 schrieb Henri Verbeet:
>> +            if(This->resource.device->adapter->gl_info.supported[APPLE_FENCE])
> I'm not sure you can test for APPLE_fence to determine if event
> queries are available.
directx.c disables NV_fence if APPLE_fence is available. We prefer the APPLE extension over the NV one due to the interactions with other APPLE extensions, and I think we should prefer it over the ARB one for the same reason.

> The buffer code can't assume an event query is implemented with APPLE_fence.
Since it is the preferred fence extension and the above check only accepts APPLE_fence it can assume this.

That said, I first thought that APPLE_flush_buffer_range requires APPLE_fence, but this is not the case - the extension says to use glFinish() if APPLE_fence is not supported. I assume NV_fence would work just fine too, even though this is not explicitly mentioned(NV_fence is 5 years older than APPLE_flush_buffer_range).

I can make the code more flexible and allow NV_fence or potentially ARB_sync as well, but so far I haven't seen a mac that doesn't support APPLE_fence, and I haven't seen a mac that supports NV_fence. I expect that when Apple ships support for ARB_sync, they'll also support ARB_map_buffer_range(with a nicer sync API than APPLE_). Thus the sync code without APPLE_fence would be dead code and it's better to just disable the manual fencing if APPLE_sync is not available.

More information about the wine-devel mailing list