On 2/4/22 09:03, Henri Verbeet wrote:
On Thu, 3 Feb 2022 at 20:17, Zebediah Figura zfigura@codeweavers.com wrote:
- if (!use_mt)
- /* Running the tests multithreaded on 32-bit maps too much memory in Wine,
* even with only 2 threads. */That didn't seem quite right, so I looked a bit more into this. It seems the issue is slightly more subtle; when maps start failing with GL_OUT_OF_MEMORY, the total number of chunks mapped across devices is typically either 0 or 1. On the other hand, the total number of allocated chunks tends to be fairly high (about 24, which would amount to about 1.5GiB). It seems the radeonsi driver doesn't actually (ever?) unmap buffers when we request that. That's probably reasonable enough for 64-bit applications, but less so for 32-bit applications. This doesn't happen on my Intel SKL system. A contributing factor is probably that because there's currently no slab allocator, we allocate blocks of WINED3D_ALLOCATOR_MIN_BLOCK_SIZE size for small constant buffers, which is going to inflate VRAM usage somewhat.
Ugh, of course.
That leaves the question of what to do about it, of course. I could live with this series, although it seems a rather unsatisfying solution. We probably want to adjust the comment a little though, and I think we only want to do this on Wine, not on Windows (where running the tests in parallel always helped a bit more than on Wine anyway).
I guess I could also look into using multiple processes anyway. VRAM is still a theoretical concern, but maybe it won't really end up being important enough in practice.
It does feel like a nontrivial amount of work for something that's easy enough to solve with a sledgehammer, so I'm more than a little inclined just to disable multithreading on 32 bits, and then perhaps revisit this later.