[PATCH 0/40] MR1010: Draft: opengl32: Path towards wow64 support.
I was watching some random YouTube stream and then heard a voice telling me to do this. This can run wglgears on wow, though there's plenty of missing pieces which I don't have any idea how to fix (like buffer mapping, etc.). Opening it as a draft for now to show the whole thing, if it seems alright I'll send it in batches. -- This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/1010
No idea why the macOS build failed, maybe some shenanigans with symbol visibility, or something with the build state. I think that commit is mostly moving a function around. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1010#note_10050
glMapBuffer will be very difficult. Did anything come out of the Vulkan discussion? In hangover I solved it by blocking all address space > 4GB, but that is a bad solution. Crossover solves it with a mac-specific remap syscall that creates a second mapping for arbitrary memory. Afaiu the vulkan plan was some vulkan extension to give the caller a way to use a specific address with MMAP_FIXED to force using it even if there are preexisting mappings e.g. due to Wine holding all < 4GB memory. Using the crossover way would mean going through winex11/winemac -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1010#note_10054
fwiw without any specific extension you can use HeapAlloc'ed shadow memory and memcpy between that and an arbitrary glMapBuffer mapping. That will be slow and you can't support coherent mappings and might need to hide some extension support / downgrade the GL version because of that. But it could be a fallback if other options are not available. (and there is the low chance that GL luckily gives you a low address map anyhow) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1010#note_10055
On Fri Oct 7 14:59:39 2022 +0000, Stefan Dösinger wrote:
fwiw without any specific extension you can use HeapAlloc'ed shadow memory and memcpy between that and an arbitrary glMapBuffer mapping. That will be slow and you can't support coherent mappings and might need to hide some extension support / downgrade the GL version because of that. But it could be a fallback if other options are not available. (and there is the low chance that GL luckily gives you a low address map anyhow) Yes, I'm doing that now (not in this MR), and it works. I can run Diablo II (which crashes as soon as you click).
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1010#note_10056
On Fri Oct 7 14:59:39 2022 +0000, Rémi Bernon wrote:
Yes, I'm doing that now (not in this MR), and it works. I can run Diablo II (which crashes as soon as you click). In the long run I will look into making wined3d a pe/so 32on64 aware thing. It'll matter a lot for ARM, but might also be a performance improvement for x86 32on64. In wined3d we have a few more options in part because d3d <= 11 doesn't have coherent mappings, but wined3d uses it for its own purposes.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1010#note_10057
On 10/7/22 10:03, Stefan Dösinger (@stefan) wrote:
In the long run I will look into making wined3d a pe/so 32on64 aware thing. It'll matter a lot for ARM, but might also be a performance improvement for x86 32on64. In wined3d we have a few more options in part because d3d <= 11 doesn't have coherent mappings, but wined3d uses it for its own purposes.
Somewhat related to this, I had recently been thinking about trying to split up wined3d a bit more explicitly. The DLL is huge, and I think it can be difficult to understand what's done on the client and CS side, which is a pretty important distinction. I'd recently been thinking of a somewhat controversial proposal, that we might want to try splitting it into separate DLLs representing these, so that even if we don't eventually decide to split it into PE/Unix, we could have that additional clarity. Or maybe just have a source subdirectory for the CS part?
On Fri Oct 7 15:04:44 2022 +0000, Stefan Dösinger wrote:
glMapBuffer will be very difficult. Did anything come out of the Vulkan discussion? In hangover I solved it by blocking all address space > 4GB, but that is a bad solution. Crossover solves it with a mac-specific remap syscall that creates a second mapping for arbitrary memory. Afaiu the vulkan plan was some vulkan extension to give the caller a way to use a specific address with MMAP_FIXED to force using it even if there are preexisting mappings e.g. due to Wine holding all < 4GB memory. Using the crossover way would mean going through winex11/winemac Blocking higher allocations defeats a bit the purpose of doing WoW64. Imho the Vk/GL extension, or kernel support for mirrored memory pages, is the right way. I have no idea how it should be done though.
Having one for GL would be nice too but I think it may not be completely required if we have the Vk one: there's already some extensions to share buffers between Vk and Gl, and although a bit convoluted it could perhaps be used. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1010#note_10058
On Sat Oct 8 15:38:57 2022 +0000, Rémi Bernon wrote:
No idea why the macOS build failed, maybe some shenanigans with symbol visibility, or something with the build state. I think that commit is mostly moving a function around. Must be the build state, I was able to build 07642c6fa243ef698b52fcc27dec3b6d7d44c003 successfully on Mac.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/1010#note_10066
On Sat Oct 8 16:49:13 2022 +0000, **** wrote:
Zebediah Figura replied on the mailing list: ``` On 10/7/22 10:03, Stefan Dösinger (@stefan) wrote:
In the long run I will look into making wined3d a pe/so 32on64 aware thing. It'll matter a lot for ARM, but might also be a performance improvement for x86 32on64. In wined3d we have a few more options in part because d3d <= 11 doesn't have coherent mappings, but wined3d uses it for its own purposes.
Somewhat related to this, I had recently been thinking about trying to split up wined3d a bit more explicitly. The DLL is huge, and I think it can be difficult to understand what's done on the client and CS side, which is a pretty important distinction. I'd recently been thinking of a somewhat controversial proposal, that we might want to try splitting it into separate DLLs representing these, so that even if we don't eventually decide to split it into PE/Unix, we could have that additional clarity. Or maybe just have a source subdirectory for the CS part? ``` By and large I am in favor of splitting wined3d in a cs and client part. It doesn't need to be separate DLLs though.
A difficult enough start would be splitting the object implementation structures into a client, CS and possibly shared part. It can still be in the same struct fwiw; a /* This part is accessed only by the client */ and /* This part is accessed only by the CS thread */ separation. If nothing else it would help with cacheline bouncing. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1010#note_10070
I'd recently been thinking of a somewhat controversial proposal, that we might want to try splitting it into separate DLLs representing these, so that even if we don't eventually decide to split it into PE/Unix, we could have that additional clarity.
Or maybe just have a source subdirectory for the CS part?
This discussion seems largely off-topic here, but for what it's worth: Personally I'm fairly sceptical of the benefits; it's also something that's entirely up to the maintainers though. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1010#note_10178
participants (5)
-
Brendan Shanks (＠bshanks) -
Henri Verbeet (＠hverbeet)
-
Rémi Bernon
-
Stefan Dösinger
-
Zebediah Figura