Re: Discussing paths forward for OpenGL mappings on Wow64

Stefan Dösinger <[email protected]> Tue, 15 Oct 2024 22:09:50 +0300
Newsgroups	gmane.comp.emulators.wine.devel
Message-ID	<[email protected]>

> Am 14.10.2024 um 22:38 schrieb Derek Lesho <[email protected]>:
> 
>> The dosemu2 dev pointed out a way to achieve something similar to macos' mach_vm_remap on Linux. I have to find my email in the archive and will forward his suggestion. It does sound somewhat hacky to me, I am not sure if we want to use it.
>> 
> Oh interesting, yeah that be cool to see. Regardless, even if we have that path, we would probably want to also have a proper long term solution, like how we have the host external memory backup hack in winevulkan.

I found the old emails (or part of them). I doubt the idea is workable, but here we go:

The trick is essentially to replace the high address mapping behind the external library's back. In pseudo code

void *wine_glMapBuffer(int bo)
{
    struct buffer *buf = some_lookup(bo)
    int fd = shmmem_alloc(buf->size);

    void *high_addr = host_glMapBuffer(buf->host_bo);
    void *low_addr = wine_find_some_4g_space(size);

    mmap(high_addr, buf->size, PROT_RW, MAP_FIXED, fd, 0);
    mmap(low_addr, buf->size, PROT_RW, MAP_FIXED, fd, 0);

    return low_addr;
}

This has a non-zero chance of working if the GL library just reads/writes to its own allocation via the CPU. Replacing the mapping will probably destroy any magic properties (like memory mapped video memory) the driver put in place. And it will break if the pointer returned isn't page aligned and maybe comes from a larger allocation. and and and. So I doubt it is going to fly.

In the dosemu2 code there's some sweet looking code here: https://github.com/dosemu2/dosemu2/blob/92705ab35e136bfef2e0206af7c05518ae27cec9/src/base/lib/mapping/mapashm.c#L38 . It looks like it maps void *source to void *target. I tried to follow it through the rest of the code a bit to see if the callers expect *source to remain valid, but couldn't easily figure out how this is all used.

---

>> Fwiw as far as wined3d-gl is concerned, it can play nice with slow bounce buffers too. It should do the right thing if GL_ARB_buffer_storage is not available. d3d isn't as badly affected by the performance penalty, although there are games that profit from persistent maps.
> I think Aida mentioned this path was prohibitively slow for WineD3D, not sure which games they were referring to.


There are certainly games that are either slow (d3d10/11) or outright broken (d3d8/9) without coherent buffers. d3d8/9 games can break without coherent maps if they pass incorrect map lengths. Coherent maps allow us to ignore the length and let the driver figure out what was actually written.

I did come across a reverse side of this though [0]: A game that experienced a big regression on ARM hardware *with* coherent buffers. The background was that x86 and that particular ARM chip had entirely different ideas how slow reading from write-combined buffers is.

0: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8301
signature.asc (application/pgp-signature, 833 B)