You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
D3D9: Multithreaded Texture creation may crashΒ #4613
I was curious if i could apply dxvk on my d3d9 project and came across one issue:
I create my d3d9ex device with multithreaded flag and use it to load my assets in a separate thread.
And this is where DXVK seems to have its issue:
AV: Exception thrown at 0x67FC3BDC (d3d9.dll) in project.exe: 0xC0000005: Access violation writing location 0x00000000.
[Inline Frame] d3d9.dll!dxvk::D3D9MemoryChunk::Unmap(dxvk::D3D9Memory *) Line 157 C++
d3d9.dll!dxvk::D3D9Memory::Unmap() Line 285 C++
[Inline Frame] d3d9.dll!dxvk::D3D9CommonTexture::UnmapData() Line 238 C++
d3d9.dll!dxvk::D3D9Initializer::InitTexture(dxvk::D3D9CommonTexture * pTexture, void * pInitialData) Line 63 C++
d3d9.dll!dxvk::D3D9DeviceEx::CreateTexture(unsigned int Width, unsigned int Height, unsigned int Levels, unsigned long Usage, _D3DFORMAT Format, _D3DPOOL Pool, IDirect3DTexture9 * * ppTexture, void * * pSharedHandle) Line 663 C++
d3dx9_43.dll!_D3DXLoadVolumeFromResourceW@36() Unknown
d3dx9_43.dll!_D3DXCreateTextureFromFileInMemoryEx@60() Unknown
Looking at the assembly at the eip of the exception, it seems to out-of-bounds the m_mappingRanges vector.
In my case it seems to access index 0, but the vector is empty.
Likely a race condition as it may work at some times and other times not.
Throwing all work onto a single thread solves this and dxvk works just fine then.
Software information
AMD64 Windows 24H2 26100.2605, 32bit application
System information
GPU: RTX 4090
Driver: 566.45
Wine version: n/a
DXVK version: 32bit 2.5.3*(*)
*windows-msvc CI: dxvk-merge-69a3d78b3435c39caf561ea71778ae6be0e9f44b-msvc-output
**This bug also appears on older versions
I took a look at it again and I did find a race in the D3D9 mapped file memory code. I'll fix that over the next few days. Hopefully that will fix your crashes.
This one is odd. The internals of DxvkBuffer are only changed on the CS-Thread or in the constructor of DxvkBuffer. And the constructor calls are additionally also protected by the D3D9 device lock on top of that. Only once the constructor is done it gets handed over to the CS thread.
Activity
Blisto91 commentedon Jan 14, 2025
What is the oldest dxvk you have tested?
Edit: Is just curious if it is because of the 32bit d3d9 memory management that was implemented in 2.0 from the error (i am not a dev)
enginelesscc commentedon Jan 14, 2025
Looking at my history it were 2.0/2.1
Blisto91 commentedon Jan 14, 2025
Does it work if you make a dxvk.conf file next to the exe an insert
d3d9.textureMemory = 0?You can check in the dxvk log if it was picked up
K0bin commentedon Jan 14, 2025
I took a look at it again and I did find a race in the D3D9 mapped file memory code. I'll fix that over the next few days. Hopefully that will fix your crashes.
enginelesscc commentedon Feb 3, 2025
I may have encountered another possible race (occurred outside mainthread):
dxvk::DxvkBuffer::assignStorage ~ m_bufferInfo = m_storage->getBufferInfo();
https://github.com/doitsujin/dxvk/blob/master/src/dxvk/dxvk_buffer.h#L345
backtrace:
dxvk::DxvkBuffer::DxvkBuffer
dxvk::DxvkDevice::createBuffer
dxvk::D3D9CommonTexture::CreateBuffer
dxvk::D3D9DeviceEx::LockImage
dxvk::D3D9Surface::LockRect
dxvk::D3D9Texture2D::LockRect
Seems to be more rare, cannot easily reproduce :/
K0bin commentedon Feb 3, 2025
This one is odd. The internals of DxvkBuffer are only changed on the CS-Thread or in the constructor of DxvkBuffer. And the constructor calls are additionally also protected by the D3D9 device lock on top of that. Only once the constructor is done it gets handed over to the CS thread.