> It may be worth including a call to GetVertexBufferDesc() in the tests. As Matteo mentioned in an earlier comment, the docs seem to suggest that omitting D3DVBCAPS_SYSTEMMEMORY allows the driver/runtime to place the buffer as it sees fit.
I mentioned earlier that GetVertexBufferDesc() never returns anything other than the flags used to create the buffer. That holds for both cards. I'll add a test the the suite.
> I guess it should perform better with a vidmem buffer if the buffer is holding static data and not locked after the initial upload.
Maybe, yeah. Though I'd be surprised if a ddraw application did that...
> Can you check D3DDEVICEDESC.dwMaxVertexCount on these cards? Regardless of what we do with these two patches I think we should reduce it to whatever Windows reports. (1024 in my case on Windows 11)
For both cards, the RGB device has 0 in the HAL caps, and 2021 in the HEL caps.
The NVidia card has 32768 (both HAL and HEL), and the ATI card has 2048 (both HAL and HEL).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2404#note_68208
Overriding the SDL_VIDEODRIVER variable (for Wayland support as an example)
on the Linux side can lead to some games under Wine failing to load (so treat
that variable as special).
--
v3: ntdll: Add SDL_AUDIO*/SDL_VIDEO* to the special variables list.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5231
> At the same time, I haven't seen any evidence that a modern GPU will ever perform better with a vertex buffer not in sysmem unless it's using the streaming pattern
I guess it should perform better with a vidmem buffer if the buffer is holding static data and not locked after the initial upload.
Can you check D3DDEVICEDESC.dwMaxVertexCount on these cards? Regardless of what we do with these two patches I think we should reduce it to whatever Windows reports. (1024 in my case on Windows 11)
Conceptually the two patches have my blessing though, regardless of specifics of what PoP3D is doing.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2404#note_68141