[PATCH 3/4] d3d11/tests: Don't run the 32-bit tests multithreaded.

[Zebediah Figura]

On 2/4/22 09:03, Henri Verbeet wrote:
> On Thu, 3 Feb 2022 at 20:17, Zebediah Figura <zfigura at 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.