On Tue Mar 24 13:37:32 2026 +0000, Rémi Bernon wrote:
The issue I see is that exposing extensions that aren't expected to be there by applications have a chance of confusing them. It's possible for instance that an application check for GL_ANGLE extension and decide to enable some ANGLE specific rendering mode. On Windows the AMD drivers do not support those extensions, but on Wine most of the time Mesa is used for AMD GPUs and they would be exposed. The same logic applies to platform specific extensions like GL_APPLE or other platform extensions that are currently filtered out. Sure `make_opengl` could support some of them, and sure, GL extensions aren't restricted and some other driver could implement them including on Windows, but it's not the case in practice and passing them through creates a runtime environment that differ from any possible native environment Windows applications have been developed for. Filtering out extensions which aren't, or very rarely, there on Windows is less likely to break anything, because no application is expected to benefit from them anyway. 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. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10349#note_133857