wined3d relies on `WGL_WINE_query_renderer` to get information about current render. The issue is that EGL driver does not implement this extension, which often leads to troubles for wined3d in trying to apply their quirks based only on a `GL_RENDERER` string. Because VRAM size becomes unknown, wined3d refuses to render due to "lack of memory". This MR solves the issue by implementing `WGL_WINE_query_renderer` for EGL driver.
In EGL there's no extension like `GLX_MESA_query_renderer`, so we have to implement it ourselves.
Some caveats of this implementation:
- Obtaining some attributes involves context switching for direct quries to OpenGL driver. I tried to avoid risk of situation where we might lose current driver context, and from my tests it works, but maybe I’m missing something.
- Getting vendor and device PCI IDs is done through DRM, which is a bit tricky at the moment as we have to go through devfs. This can be made cleaner through libdrm, but I don’t think we should introduce a new dependency just for a few attributes.
- The `GL_NVX_gpu_memory_info` extension is used for VRAM size. It is quite common but not supported everywhere, unfortunately there is no simpler way to get information about VRAM.
- There is no API for `WGL_RENDERER_UNIFIED_MEMORY_ARCHITECTURE_WINE`. Same as for winemac.drv, but it’s not a big problem since it doesn’t seem to be used now.
Some advantages:
- Unlike GLX, we are not tied to Mesa specific extensions, which allows it to work for NVIDIA as well, sparing wined3d from having to guess something based only on the GPU name.
- Unlike the same GLX, we can actually query multiple devices. Although `GLX_MESA_query_renderer` also proclaims this, in fact Mesa does not implement anything other than queries to the current renderer:
https://gitlab.freedesktop.org/mesa/mesa/-/blob/32a10ccbdd1e6750c84aac3393d…
Hope I didn’t miss anything.
Signed-off-by: Vasiliy Stelmachenok <ventureo(a)cachyos.org>
--
v3: win32u: Advertise WGL_WINE_query_renderer extension
win32u: Add wglQueryRendererStringWINE implementation for EGL driver
win32u: Add wglQueryRendererIntegerWINE implementation for EGL driver
win32u: Add wglQueryCurrentRendererStringWINE implementation for EGL driver
win32u: Add wglQueryCurrentRendererIntegerWINE implementation for EGL driver
https://gitlab.winehq.org/wine/wine/-/merge_requests/9116
This MR adds support for the simpler fields in `D3DX10_IMAGE_LOAD_INFO`. I've deferred handling the `Filter` fields to another MR as I'm currently in the process of figuring out what the default values for those fields are. :)
--
v2: d3dx10: Add support for handling the format field in D3DX10_IMAGE_LOAD_INFO.
d3dx10: Add support for custom texture dimension arguments in D3DX10_IMAGE_LOAD_INFO.
d3dx10: Create 3D textures for images representing 3D textures.
d3dx10: Fill pSrcInfo structure in D3DX10_IMAGE_LOAD_INFO if passed in.
d3dx10/tests: Add tests for the D3DX10_IMAGE_LOAD_INFO structure argument.
https://gitlab.winehq.org/wine/wine/-/merge_requests/9089
Overwriting ctx->hWnd with the current focus window breaks the
relationship between the HIMC handle and its associated window.
This direct assignment does not update the corresponding state
in the wine server, leading to inconsistencies between client and
server.
Signed-off-by: chenzhengyong <chenzhengyong(a)uniontech.com>
--
v7: imm32: Do not overwrite input context window with GetFocus() in ime_ui_update_window.
https://gitlab.winehq.org/wine/wine/-/merge_requests/9097
Starting with macOS 10.15, `mmap()` for a file with `PROT_EXEC` fails with `EPERM`. But for some reason, doing separate `mmap()` and then `mprotect()` calls works.
This fixes `NtUserRegisterClassExWOW: Failed to get shared session object for window class` errors seen when running a 32-bit EXE lacking the NX compat bit. The shared memory object being used for window classes was being mapped executable, this was failing because of the above, and then `map_file_into_view()` was falling back to `pread()` which doesn't make sense for a shared memory region. (It seems like a bug to use `pread()` in this scenario rather than return an error, although I'm not sure how that could be detected).
I don't love the preprocessor black-magic to replace every mmap() call, but it avoids having to modify any other functions. If we want to avoid that, `map_pe_header()` and `map_file_into_view()` are the `mmap()` calls that I know need to be changed.
CrossOver has used an almost-identical hack for years.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/9126