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

[Henri Verbeet]

2010/1/5 Stefan Dösinger <stefandoesinger at gmx.at>:
>
> 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.
>
Well, ARB_sync works across contexts...

>> 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.
>
No. Regardless of the assumption being true or not, it's an
implementation detail of event queries. You're not supposed to depend
on those. Of course you shouldn't be poking at event query internals
from the buffer code anyway, APPLE_fence or not.

> 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.
>
See above. This is more of an argument for adding ARB_map_buffer_range
support first though.