Re: [PATCH v4 0/9] MR9987: opengl32: Generate extension lists with basic GLES support.

[Elizabeth Figura (＠zfigura)]

> I don't really know well but it seems to me that GL_APPLE_fence is a fallback for GL_ARB_sync, and GL_APPLE_flush_buffer_range a fallback for GL_ARB_map_buffer_range. I'm not sure about GL_APPLE_rgb_422 and GL_APPLE_ycbcr_422 but I suppose that they aren't available outside of macOS, and the latter described as only available on legacy contexts, so I assume they are only optional for wined3d operation?

Sort of.

While we use ARB_sync and APPLE_fence in more or less the same way, I don't think the semantics of ARB_sync are a subset of those of APPLE_fence in general. In fact they are probably a superset if anything. It wouldn't be appropriate to implement ARB_sync on top of APPLE_fence. The reason we fall back is because an implementation might expose APPLE_fence but not ARB_sync. I don't know for sure but it wouldn't surprise me if Apple machines do this very thing. That's the case for many extensions, including APPLE_flush_buffer_range vs ARB_map_buffer_range.

In the case of YUV, we have fallback implementations, since, as you mention, those extensions aren't actually exposed outside of Mac as far as I know. They do require more work on our part, but I wouldn't be surprised if they're not actually less efficient for that. Now that we require GLSL anyway, there may not really any point continuing to use the Apple extensions.

I'm not really about to delete something from wined3d if it's not getting in the way, though, and I think that's the main point here. GL_APPLE extensions are just like any other vendored extensions. You see vendors implementing each others' extensions all the time. There's no reason to treat them separately, and I don't see why they'd be a problem for opengl32 translation. (GLX_APPLE_* would be another story, if any such extensions existed, but then the operative part there is really "GLX", and I assume we already filter out GLX_*.)

If a Windows application did in fact choke on seeing any APPLE extensions, we could remove them, and decide what we want to do about that in d3d, but I don't think there's any reason to do that preemptively.

In fact, I would be surprised if this happens, because looking now, it seems at least one Apple extension, namely APPLE_packed_pixels, is frequently implemented on both Linux and Windows, including the radeonsi machine I'm typing from.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/9987#note_128701