Re: [PATCH v2 0/14] MR10349: opengl32: Implement wglGetProcAddress on the client side.

[Rémi Bernon (＠rbernon)]

On Thu Mar 26 11:12:56 2026 +0000, Jacek Caban wrote:
> On ARM Windows, OpenGL is implemented on top of Mesa’s D3D12 backend, so
> all extensions exposed by Mesa can potentially be present on actual
> Windows. Filtering them therefore seems counterproductive, unless we
> want to filter based on vendor or something similar, which sounds
> brittle and would require a strong justification.
> We are currently exposing all of those extensions, and we have years of
> testing showing that they do not cause problems (at least for the
> applications we already support). As such, exposing them should not
> introduce regressions. The intention behind adding those entries is to
> limit the impact of the patch that tokenizes extensions. Hypothetically,
> if we do have a reason to filter any of them after all, I think it would
> be better to remove them from make_opengl in a separate change, so that
> a potential bisect clearly points to the filtering change rather than to
> a commit whose primary purpose is tokenization. That said, even for
> extensions currently not exposed by Windows drivers, I believe filtering
> would be counterproductive and not forward-compatible by definition, as
> future Windows drivers may start exposing them at any time.
> Perhaps we should consider adding even more of them to make_opengl. I
> initially added the ones observed on my drivers, which seemed like a
> reasonable compromise.
> Well arguably we have years of testing showing that exposing these extensions do not break the applications *which are currently working*. It says nothing about applications that don't work or that weren't tested. I've recently fixed some compatibility issue caused by passing through host GL_RENDERER string as is, which broke an application in some cases, as it was expecting a shorter string than what we returned.

Anyway, I don't mind too much adding support for registered extensions, although I think we should argue whether it does fix anything, rather than whether not exposing them breaks something, but I don't think we should be hardcoding extensions which aren't in the registry. There's no reason to list Mesa extensions more than other vendors, and we have a general policy in Wine not to add vendor or backend specific workaround unless proven necessary, ie: that it *is* native behavior and that doing it fixes some application.

If ARM Windows uses Mesa for its OpenGL implementation, and if some application depends on a Mesa specific extension in such situation, we could *then* consider adding them in such case, but that actually would need to be done regardless of the host GL implementation because Wine on ARM isn't always going to run with Mesa. Note that this probably means that we would be better off with PE Zink in such case anyway, because otherwise we might end up being simply unable to implement the missing extension if the host cannot do it for us.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/10349#note_133862