wine-nine-standalone
wine-nine-standalone copied to clipboard
iXit
Consistent 'Out of video memory' issues
Using Wine 4.2 (Proton 4.2-2) with the latest Gallium Nine Standalone installed using winetricks. The games Borderlands 2 and Borderlands Pre-Sequel consistently crash while Gallium Nine is enabled in two specific places, depending on whether or not the 4K texture pack is enabled. If the texture pack isn't enabled both games will crash with an 'Out of video memory' error when loading into a level. If the texture pack is enabled, it will crash right as the main menu loads.
CPU: Ryzen 7 1700X GPU: Vega 64 8GB RAM: 24GB OS: Arch Linux Kernel: 5.0.6 Mesa: 19.0.1-1 LLVM: 8
Note: Using the environment variable PROTON_FORCE_LARGE_ADDRESS_AWARE=1 delays the issue for 1-3 minutes without the texture pack. Crashing still occurs.
The Out of Memory issue is an issue on which we don't have much solution to offer except: . Use large address aware . Disable Dx11 support (some games load dx11 dlls, it takes some memory) . Reduce pulseaudio usage (See https://github.com/ValveSoftware/Proton/issues/177#issuecomment-471155594)
I'm also getting this with Borderlands 2, crash when loading a save with the Ran out of video memory! Exiting... error. Using PROTON_FORCE_LARGE_ADDRESS_AWARE doesn't help for me (the error states VRAM, not system RAM), and there is no DX11 support in BL2--just DX9.
GALLIUM_HUD states that my VRAM usage is only ~1.4GB when it crashes, despite my card having 8GB of available VRAM. VRAM usage without Gallium (just wined3d) easily goes above 1.5GB as expected, though I'm wondering if this could be an engine problem rather than a Gallium one and there's somewhere in the game's configs that I can set the max allowable VRAM or something...
Uninstalling the HD texture pack resolves the issue for me, and I no longer crash even with Texture Quality set to High in game options. However, as I clearly have more than enough VRAM, I feel this isn't really a solution & I should be able to use the higher res textures.
CPU: Ryzen 2700X GPU: Vega 56 8GB RAM: 16GB OS: Arch Linux Kernel: 5.0.6.arch1-1 Mesa: 19.0.1-2 LLVM: 8.0.0-1
Happens with both Wine 4.2 and 3.16
Edit: Unfortunately, I get severe FPS drops with Gallium whenever I move my mouse (see Proton#2455). This is mitigated when using Proton/wined3d by turning my mouse polling rate to 500Hz instead of 1000Hz, however this does not work with Gallium and my FPS will drop by ~70-80 regardless of mouse polling rate any time I touch the mouse.
If you can play with recompiling mesa, you can try in state_trackers/nine/device9.c to replace
This->available_texture_limit = This->available_texture_mem * 20LL / 100LL;
with
This->available_texture_limit = This->available_texture_mem * 5LL / 100LL;
The detected available_texture_mem should be high enough (capped to 4GB), but who knows.
If you can play with recompiling mesa, you can try in state_trackers/nine/device9.c
This didn't seem to help at all, still had the game crashing at the same points, maybe limiting it more would help but I didn't get to investigate it more yet.
Can you check: https://github.com/kakra/wine-proton/blob/rebase/proton_3.16/README.md#hints-to-32-bit-users-applies-also-to-syswow64 (both the hints, and the tree, while we are at this desperate point)
I used the standard wine from archlinux, and I could play with the 4K texture pack dlc and textures set to high without issues.
I would suggest to try installing the native d3dx9_* libs with winetricks.
I used the standard wine from archlinux, and I could play with the 4K texture pack dlc and textures set to high without issues.
Just to be sure, did you try to get into Sanctuary? I some other areas also worked fine for but Sanctuary was always crashing (at least in BO2, didn't test The Pre Sequel).
I won't be able to do any testing myself before Tuesday or so.
No, I'm not very advanced in the game. But I had the 4K patch, textures set to high, and the menu was fine
I did some more testing with (CONFIG_TRANSPARENT_HUGEPAGE_MADVISE instead of CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS) and setting shm-size-bytes=1048576 and I get the error a bit later (mainly when traveling between regions).
Could you guys try if 'AMD_DEBUG=nodma' variable helps preventing going out of memory with Borderlands?
Nope, exited immediately after getting in-game.
CPU: Core i7 3770 GPU: RX 480 8GB RAM: 32GB OS: Arch Linux Kernel: 5.0.13-arch1-1-ARCH Mesa: 19.0.3-1 LLVM: 8.0.0-2
Maybe it's doing a stupid here and mapping the utilized VRAM into its address space?
Same Out of Video Memory problem with RE6.exe from Steam running all under wine-4.17 (Staging). I just played a "map" but in the other maps there are the error. I have a Radeon RX 580 with 4GB of VRAM. That game is from 2012 I have a better graphics card than required by the game. I am not using at all 4K pack or something like that, it is the "vanilla" Resident Evil 6.
Native Direct3D 9 v0.5.0.0-release is active.
I can play the game without wine nine, now I am testing it with wine nine.
When I receive the dialog of "Out of video memory" the game is using only 500 MB. I think it is not a memory problem it is something related with some allocation function or video memory limit bad translated as per bit conversion. I don't know really but does not make sense if there are a lot of video memory why the game claims out of video memory.
Here are some from console:
nine:vertexshader9:ctor: Encountered buggy shader
ok
switching to resolution -----------> 1920x1080
System page size: 4096
[1008/010216.303:INFO:crash_reporting.cc(245)] Crash reporting enabled for process: renderer
===============> start: 0
STEAMPS3 - AsyncTCPSocket created
STEAMPS3 - AsyncTCPSocket created
STEAMPS3 - AsncTCPSocket destroyed
STEAMPS3 - AsncTCPSocket destroyed
LLVM ERROR: out of memory
Setting breakpad minidump AppID = 221040
Steam_SetMinidumpSteamID: Caching Steam ID: 76561198170374622 [API loaded no]
fixme:d3d9nine:D3DPERF_SetOptions (0x1) : stub
fixme:d3d9nine:D3DPERF_GetStatus (void) : stub
Native Direct3D 9 v0.5.0.0-release is active.
For more information visit https://github.com/iXit/wine-nine-standalone
fixme:d3d9nine:DRIPresentGroup_GetMultiheadCount (0x2271418), stub!
fixme:d3d9nine:DRIPresentGroup_GetMultiheadCount (0x2271418), stub!
nine:vertexshader9:ctor: Encountered buggy shader (x 43 times)
ok
switching to resolution -----------> 1920x1080
System page size: 4096
[1008/011123.679:INFO:crash_reporting.cc(245)] Crash reporting enabled for process: renderer
As I can see it says "LLVM ERROR: out of memory" and I don't know why LLVM gets out of memory. Maybe it is limited to use only the real memory not the virtual. Or it is limited to allocate a fixed amount.
Another idea, could it have something to do with windows considering previous allocations automatically freed on their overwrite, while linux drivers usually require an explicit clear (so virtual memory always builds up)?
I have 8 GB of RAM so for me I easily end using swap specially opening a lot of tabs on Chrome plus compiling something. I know the sympthoms of that. In this case there are no evidence of using virtual memory at all. But the real memory is near full when I run the game. That is because I suspect about that. But I dont know about that Windows behaviour.
But as the logs show I suspect too about the compilation of shaders. As llvm is a low level virtual machine I suspect of that executing or compiling shaders. So, there are some bug in some place related to llvm. But I cannot found no one reference about llvm in the source code. So, where is using it?
Nine compiles to TGSI (which depending on your driver may be further compiled to NIR), that's in turn compiled by LLVM to whatever the magic hardware assembly is. That's all in mesa though.
@Anyeos : You have several times the message "Encountered buggy shader".
This is suspicious. Maybe the game says out of memory, but actually it's just a generic error path.
If I recall correctly, the buggy shader message is when we encouter something forbiden. The shader is then not compiled and we return an error code. We would need to investigate these shaders. Either by creating a trace (see wiki), or extracting the info from the log (I think it is NINE_DEBUG=shader with mesa compiled with asserts on).
@axeldavy I just think that may be the problem. A buggy shader get out of memory, I guess. But I don't know why it is so anyway. There are a lot of situations with buggy shaders in games and they are simply ignored (think about some unsopported feature of your videocard, that does not mean you cannot actually play the game, but not with full shader support). That can produce graphics artifacts or featureless but not neccesary fill the memory. I don't expect a buggy shader get out of memory anyway. I think there are a need to impose some limit compiling shaders so they don't allocate memory outside of they scope. And printing a warning and ignoring it in a harmless way is the best option I think.
So I just suspect of LLVM doing something bad with memory. But maybe the problem is how LLVM is used and not LLVM itself.
I have no time to investigate deeper for now but I will try when have the time.
These has been some leaks with nir (radeonsi switched from tgsi to nir more than a year ago). This issue might be fixed by https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4980
The mentioned leak fix is part of mesa-20.1.0 @Hammersamatom can you try with that version on your setup?
@dhewg Edit: Cannot confirm if fixed. Issue appears to have gotten worse. Game won't start with Gallium Nine enabled. Immediate Out of video memory error.
Kernel: 5.0.6 -> 5.8.5 Mesa: 19.0.1-1 -> Mesa 20.1.0 and Mesa-git 20.3.0_devel.127732.8d1d0c126fd-1 tested LLVM: 8 -> 10.0.1-2
Log is consistent across both Proton 5.0-9 and Wine-git (5.16.r53.g00a0e2cd8c-1)
Here's a snippet of the terminal.
0578:fixme:gameux:GameExplorerImpl_VerifyAccess (02DEF360, L"Z:\\home\\hammersamatom\\.wine\\drive_c\\Program Files (x86)\\Steam\\steamapps\\common\\Borderlands 2\\Binaries\\Win32\\Launcher.exe", 023EF604)
Native Direct3D 9 v0.7.0.368-release is active.
For more information visit https://github.com/iXit/wine-nine-standalone
Native Direct3D 9 v0.7.0.368-release is active.
For more information visit https://github.com/iXit/wine-nine-standalone
mmap() failed: Cannot allocate memory
Failed to create permanent mapping for memfd region with ID = 3828104276
Ignoring received block reference with non-registered memfd ID = 3828104276
0578:err:alsa:get_alsa_name_by_guid No devices found in registry?
0578:err:alsa:get_alsa_name_by_guid No devices found in registry?
0578:err:alsa:get_alsa_name_by_guid No devices found in registry?
0578:err:alsa:get_alsa_name_by_guid No devices found in registry?
mmap() failed: Cannot allocate memory
Failed to create permanent mapping for memfd region with ID = 197933763
Ignoring received block reference with non-registered memfd ID = 197933763
ALSA lib pcm_dmix.c:1090:(snd_pcm_dmix_open) unable to open slave
mmap() failed: Cannot allocate memory
Failed to create permanent mapping for memfd region with ID = 3440918507
Ignoring received block reference with non-registered memfd ID = 3440918507
mmap() failed: Cannot allocate memory
Failed to create permanent mapping for memfd region with ID = 1299250375
Ignoring received block reference with non-registered memfd ID = 1299250375
0118:fixme:file:ReplaceFileW Ignoring flags 2
0578:fixme:system:SystemParametersInfoW Unimplemented action: 59 (SPI_SETSTICKYKEYS)
0578:fixme:system:SystemParametersInfoW Unimplemented action: 53 (SPI_SETTOGGLEKEYS)
0578:fixme:system:SystemParametersInfoW Unimplemented action: 51 (SPI_SETFILTERKEYS)
fixme:d3d9nine:DRIPresentGroup_GetMultiheadCount (0xb8b47b8), stub!
fixme:d3d9nine:DRIPresentGroup_GetMultiheadCount (0xb8b47b8), stub!
mesa: for the --simplifycfg-sink-common option: may only occur zero or one times!
mesa: for the --global-isel-abort option: may only occur zero or one times!
mesa: for the --amdgpu-atomic-optimizations option: may only occur zero or one times!
0578:fixme:d3dx:D3DXLoadSurfaceFromMemory Unhandled filter 0x80004.
0578:fixme:d3dx:D3DXLoadSurfaceFromMemory Unhandled filter 0x5.
0578:fixme:d3dx:D3DXLoadSurfaceFromMemory Unhandled filter 0x5.
0578:fixme:d3dx:D3DXLoadSurfaceFromMemory Unhandled filter 0x5.
0578:fixme:d3dx:D3DXLoadSurfaceFromMemory Unhandled filter 0x5.
0578:fixme:d3dx:D3DXLoadSurfaceFromMemory Unhandled filter 0x5.
0578:fixme:d3dx:D3DXLoadSurfaceFromMemory Unhandled filter 0x5.
0578:fixme:d3dx:D3DXLoadSurfaceFromMemory Unhandled filter 0x5.
0578:fixme:d3dx:D3DXLoadSurfaceFromMemory Unhandled filter 0x5.
*Repeats*
0578:fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (023ED554 1 C) semi-stub
0578:fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (023ED454 1 C) semi-stub
fixme:d3d9nine:D3DPERF_SetOptions (0x1) : stub
0660:fixme:ntdll:EtwEventRegister ({47a9201e-73b0-42ce-9821-7e134361bc6f}, 3F006C40, 3F04C208, 3F04C200) stub.
0660:fixme:ntdll:EtwEventRegister ({58a9201e-73b0-42ce-9821-7e134361bc70}, 3F006C40, 3F04C240, 3F04C238) stub.
0660:fixme:ntdll:EtwEventRegister ({3fa9201e-73b0-43fe-9821-7e145359bc6f}, 3F006C40, 3F04C1D0, 3F04C1C8) stub.
0660:fixme:ntdll:EtwEventRegister ({1432afee-73b0-42ce-9821-7e134361b433}, 3F006C40, 3F04C278, 3F04C270) stub.
0660:fixme:ntdll:EtwEventRegister ({4372afee-73b0-42ce-9821-7e134361b519}, 3F006C40, 3F04C2B0, 3F04C2A8) stub.
0660:fixme:process:SetProcessShutdownParameters (000003ff, 00000000): partial stub.
0660:fixme:imm:ImmGetOpenStatus (00A65348): semi-stub
0198:fixme:winsock:WS_setsockopt SO_SNDBUF ignoring request to disable send buffering
0150:fixme:ntdll:NtQueryInformationToken QueryInformationToken( ..., TokenSessionId, ...) semi-stub
0150:fixme:security:CreateRestrictedToken (00000000000004D8, 0x0, 8, 000000000ABC2090, 20, 000000000AC0A9E0, 1, 000000000E926BD0, 000000000B8DEC40): stub
0150:fixme:advapi:SetEntriesInAclW unhandled access mode 4
0150:fixme:ntdll:NtSetInformationToken TokenIntegrityLevel stub!
0150:fixme:security:CreateRestrictedToken (00000000000004D8, 0x0, 0, 0000000000000000, 0, 0000000000000000, 9, 000000000ABC2090, 000000000B8DEBB0): stub
0150:fixme:advapi:SetEntriesInAclW unhandled access mode 4
0150:fixme:ntdll:NtSetInformationToken TokenIntegrityLevel stub!
0150:fixme:sync:NtSetInformationJobObject stub: 0x4d8 4 0xb8dee48 4
0150:fixme:process:CreateProcessInternalW Creating a process with a token is not yet implemented
0150:fixme:process:NtCreateUserProcess unhandled input attribute 2000b
0150:fixme:ntdll:NtQueryInformationToken QueryInformationToken( ..., TokenAppContainerSid, ...) semi-stub
0678:fixme:virtual:NtQueryVirtualMemory (process=0xffffffffffffffff,addr=0x10000000) Unimplemented information class: MemorySectionName
0678:fixme:virtual:NtQueryVirtualMemory (process=0xffffffffffffffff,addr=0x6a700000) Unimplemented information class: MemorySectionName
0678:fixme:virtual:NtQueryVirtualMemory (process=0xffffffffffffffff,addr=0x10000000) Unimplemented information class: MemorySectionName
0678:fixme:virtual:NtQueryVirtualMemory (process=0xffffffffffffffff,addr=0x61900000) Unimplemented information class:
*Repeats 20 or so more times*
0678:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION
0678:fixme:ntdll:NtQuerySystemInformation (0x00000007,0x8686bb8,0x00000018,0x21eea0) stub
0678:fixme:ntdll:NtQuerySystemInformation (0x00000050,0x8686bb8,0x000000a8,0x21eea0) stub
0678:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_CACHE_INFORMATION
0678:fixme:ntdll:NtQuerySystemInformation (0x00000021,0x8686d40,0x00000010,0x21eea0) stub
0678:fixme:ntdll:NtQuerySystemInformation (0x0000002d,0x8686d40,0x00000020,0x21eea0) stub
0678:fixme:ntdll:NtQuerySystemInformation (0x0000003d,0x8686d58,0x00000a58,0x21eea0) stub
0678:fixme:ntdll:NtQuerySystemInformation (0x00000012,0x8686d58,0x00000a58,0x21eea0) stub
0678:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_INTERRUPT_INFORMATION
0678:fixme:ntdll:NtQuerySystemInformation (0x0000002a,0x8686d70,0x00000a40,0x21eea0) stub
0678:fixme:virtual:NtQueryVirtualMemory (process=0xffffffffffffffff,addr=0x6c840000) Unimplemented information class: MemorySectionName
0678:fixme:virtual:NtQueryVirtualMemory (process=0xffffffffffffffff,addr=0x6c840000) Unimplemented information class: MemorySectionName
0678:fixme:heap:RtlSetHeapInformation 0000000000000000 1 0000000000000000 0 stub
0678:fixme:ntdll:EtwEventRegister ({d2d578d9-2936-45b6-a09f-30e32715f42d}, 000000000257BCB0, 0000000007063018, 00000000070EC4C8) stub.
0678:fixme:ntdll:NtQueryInformationToken QueryInformationToken( ..., TokenElevation, ...) semi-stub
0678:fixme:virtual:NtQueryVirtualMemory (process=0xffffffffffffffff,addr=0x6c600000) Unimplemented information class: MemorySectionName
0678:fixme:ntdll:NtSetInformationToken TokenIntegrityLevel stub!
0678:fixme:heap:RtlSetHeapInformation 0000000000000000 1 0000000000000000 0 stub
0678:fixme:thread:QueryThreadCycleTime (FFFFFFFFFFFFFFFE,000000000021ECF0): stub!
LLVM failed to upload shader
EE ../mesa/src/gallium/drivers/radeonsi/si_state_shaders.c:2040 si_build_shader_variant - Failed to build shader variant (type=1)
LLVM failed to upload shader
EE ../mesa/src/gallium/drivers/radeonsi/si_state_shaders.c:2040 si_build_shader_variant - Failed to build shader variant (type=1)
LLVM failed to upload shader
EE ../mesa/src/gallium/drivers/radeonsi/si_state_shaders.c:2040 si_build_shader_variant - Failed to build shader variant (type=1)
06f8:fixme:shell:CustomDestinationList_BeginList 0x111c58 (0xa9efbac {92ca9dcd-5622-4bba-a805-5e9f541bd8c9} 0xa9efbb8): stub
^Z[1] Killed wine .wine/drive_c/Program\ Files\ \(x86\)/Steam/steam.exe
[2]+ Stopped wine .wine/drive_c/Program\ Files\ \(x86\)/Steam/steam.exe
I do not have that version of mesa and the time to build one and test. But I think the problem is not LLVM neither Mesa, I guess there had some problem in wine-nine.
There are some discussions about LLVM taking a lot of memory but it is expected behaviour if you are compiling a lot of parallel code.
The fact shows that only wine-nine is failing. LLVM is working as expected on all other programs. The Mesa and open source radeon drivers are working as expected on my computer and I use it a lot (don't turn off but suspend, and I do it for weeks), I use Blender and it works as expected. I have no fails neither on Steam (native) or wine games. So, why we think that the problem is Mesa or the drivers but not wine-nine?
I don't know who is developing wine-nine but I think it need more testing. I think it need an application specially designed for the sole purpose of testing.
I can confirm having the same issue, I specifically tested Borderlands 2 with the HD Texture Pack installed and all the visuals cranked up to 11. I'm using an AMD RX 5700 gfx card with 8 gb of ram.
Kernel: 5.10.7 Mesa: 20.3.3 Wine/Proton: 5.13-5, 5.0-10 and 6.0.r0.g2414b1da Wine9: 0.r372.bddb53a
https://github.com/iXit/Mesa-3D experimental patches reduce issues with high RAM usage (enables to allocate more than 4GB with 32 bits apps). This might help.
EDIT: I also just added a patch that should enable to use more than 4GB of vram, and it is possible previous code had overflow issues with 4GB cards in a function a few apps use to retrieve memory availability.
Overflowing is kind-of the expected behaviour tbh as far as I can tell (in GTA 4 for example, this seems to happen already over 2GB)
But is this shared memory magic to be considered a fix, or just a workaround for the driver still leaking?
There's three memory issues: . Shaders taking too much space due to the multiple layers of cache (redundant storage) for radeonsi -> This causes issues only for a few games which compile a huge amount of shaders. . Graphic cards over 4GB of vram. One of the functions used to report available VRAM (that most games don't use) was not reporting correct value. The ixit tree has a patch which handles that more reasonably, but without specific windows tests it's hard to know exactly the real behaviour. . System memory backing of textures (SYSTEMMEM and MANAGED) causing out of memory issues. Well there is a lot going on behind this one. The magical fix that happens with wine and d9vk (at least for MANAGED) is to not have memory backing once the data is uploaded. MANAGED is supposed to have RAM + VRAM, because back to windows xp, the VRAM content could have to be recreated from the RAM content on gpu resets. Vista+ didn't have that gpu resets anymore. So Vista+ had an issue with virtual memory usage that was fixed with a windows update, but in my understanding the problem was that the VRAM backing was mapped in memory, which thus doubled the virtual memory (adress space used) usage (RAM + mapped VRAM). My understanding as well is that they solved that by unmapping when it made sense. It is also possible, but maybe not, that they also - like wine - delete the RAM backing when the content is uploaded. They would then have even less memory usage than windows xp. Now assuming they do not do that, why would nine, which has unmapping (radeonsi does it for 32 bits apps), have memory issues ? My assumption is that it is because we use more virtual memory at the start of the program due to bigger footprint of the libraries (llvm and pulseaudio for example take a lot). There are ways to check what windows is doing (allocating a lot of buffers, mapping them, remember the pointers to the mapped region, and check if they change when you allocate and map more, unmap then map again). If you feel like spending time on tests like that and you know some C, it should be a day of work and you're welcome. But well regardless wether Vista+ does like wine or not, there is a real downside to the wine behaviour: The apps expects mapping again for the texture is real fast, and... well it is not at all if the data is only on the GPU. At least Mass Effect 2, in my tests, DOES map its low res MANAGED textures to copy the content to lower levels of high res textures (initially all is low res, and when you get near, it creates a new texture with better res). Possibly more games are doing it. This is why I chose for nine a different magic fix (on the ixit tree only for now): Using shared memory files for allocating these RAM backing, and unmap them when you're done with the data. This means you can allocate more than 4GB of ram for your 32 bits app. The only problem is if the app does map all its buffers at the same time, but well it would have issues with any solution if it does that. The pointer returned can change at each mapping. Now that's the idea, but it gets more complex: number of file limit, TLB cache. I'll spare you the details, but in short it's complicated that's why it is still on the ixit tree. But I think it should be ok enough. An alternative to shared memory I considered was using another GPU buffer, but requesting it in RAM. But as RAM buffers in d3d9 have fixed alignment constraints (no space between texture levels, known in advance stride, etc), you would have to use the GPU buffer as some 1D space that the GPU will not read. In the end it's the same as shared memory except with shared memory we do not go through the GPU driver (and risk GPU placement changes or such).
Lol, this sounds like the wet dream @starkgate has been pursuing since years, exactly with that game. Also, now that you make me think to it.. while I think this could also be eventually solved properly, it seems the nvidia driver has been doing this too.
Anyhow, you can read some stuff here I collected during the years about VRAM limits. (GTA is another famous example as I was saying, but since that doesn't outright crash and it has easy workarounds it doesn't have any "technical literature")
If you try out our Ixit/Mesa-3D, it should have all three issues I mentioned in my last post fixed.
I plan to submit the patches very soon to main mesa (except for the shader cache one which deserves more work).
@axeldavy Do you have a link to a prs? I would like to test them on top of mesa-git.
EDIT: OK looking inside the commit history of nine shows your commits, thanks for your work.
@axeldavy Do you have a link to a prs? I would like to test them on top of mesa-git.
The patches are already merged in mesa-git. There is an additionnal unmerged one that will be sent in a different form that helps especially when the CPU has a lot of cores: https://github.com/iXit/Mesa-3D/commit/0a7e69ed7ccc57820eb54d8843c08b6762f44d4d