[Overcooked All You Can Eat] Frame Drop and too much CPU heat starting from version 2.5
Using 2.6 instead of 2.7 is because the GPU Requirement doesn't met.
Your GPU can run 2.7 just fine, but you need to upgrade your mesa stack, see: https://github.com/doitsujin/dxvk/wiki/Driver-support
Please try 25.1 and see if that is a problem.
@WinterSnowfall test with 2.7, issue still exist.
Since you mention CPU heat in the title. Does 2.5 always have lower performance, as in right from the start, or is that only because your CPU starts to throttle after a little while?
Since you mention CPU heat in the title. Does 2.5 always have lower performance, as in right from the start, or is that only because your CPU starts to throttle after a little while?
always have lower performance, just select dlc "the ever peckish rises" and drop to ~20fps with 100% cpu usage, the gpu usage is also just ~40%
and if i use the 2.4.1, i found the dlc used 5g vram, which is too much high
I've played the game a bit with all its DLCs (Gourmet Edition) and it seems fine with latest master. Are you on a system with more than 16 cores threads or something like that? There are Unity games which don't behave properly if that's the case.
I've played the game a bit with all its DLCs (Gourmet Edition) and it seems fine with latest master. Are you on a system with more than 16
coresthreads or something like that? There are Unity games which don't behave properly if that's the case.
The Overcooked All you can eat doesn't have Gourmet Edition, i think ur playing the Overcooked 2 instead of AYCE edition, which is different game.
Could you check it the game is correct again?
and i also catch a apitrace on the Windows, it may also help to reproduce this issue.
Could you check it the game is correct again?
Heh, no, I actually the played the first game. Didn't imagine there's an entire series here, sorry 😆.
and i also catch a apitrace on the Windows, it may also help to reproduce this issue.
Tried to get the trace in the original post, but it's not publicly accessible. Can you make it public, please?
Tried to get the trace in the original post, but it's not publicly accessible. Can you make it public, please?
ah, Sorry i forgot this. i have made it public just now. Hope you can find something useful.
i'm very happy to collect if you need more info.
it may caused by the new memory management introduced in 2.5, the 2.4.1 has higher vRAM usage and cost 3.2G vRAM, but the usage is stable.
in the latest version, the memory chunk increased and decreased frequently with VRAM usage up to 2.9 and down to 2.6 frequently. maybe the dxvk is doing memory chunk moving most every frame?
ah, Sorry i forgot this. i have made it public just now. Hope you can find something useful.
Thank you for the trace, but unfortunately it crashes on playback. Seems it's trying to use some D3D11 video endpoints which dxvk doesn't implement. I assume this works during normal use with dxvk, but it will throw the trace off its intended path and crash.
4022 @b ID3D11VideoDevice::GetVideoDecoderConfigCount(this = 0x2c17ea61640, pDes
c = &{Guid = D3D11_DECODER_PROFILE_H264_VLD_NOFGT, SampleWidth = 1920, SampleHei
ght = 1088, OutputFormat = DXGI_FORMAT_NV12}, pCount = &9) = S_OK
4022: warning: failed with 0x80004001 (E_NOTIMPL): Not implemented.
@doitsujin On a side note, would it make sense to return 0 on pCount above? Not entirely sure how these cursed things work, but I'd imagine stubbing these with some minimal returns might be beneficial at times. In D3D9 land at least, very few applications handle E_NOTIMPL correctly.
it may caused by the new memory management introduced in 2.5, the 2.4.1 has higher vRAM usage and cost 3.2G vRAM, but the usage is stable.
If that's true, there's not much we can do here, I'd imagine. Some Unity games are known to simply load assets up front in a very sub-optimal way.
Resolution: 1920x1080
Graphics Preset: High
I'm guessing the queue sync is hurting performance
2.4.1 - ~200 FPS
2.5+ - ~70 FPS
System Information
- GPU : AMD Radeon 780M Graphics (RADV PHOENIX)
- Driver : Mesa 25.2.0
- Wine : proton-experimental-10.0-20250805
- DXVK : 2.4.1, 2.5 and 2.7-9-g3265e4aa
- Kernel : 6.16.0-arch1-1
- CPU : AMD Ryzen 7 7840U w/ Radeon 780M Graphics
- RAM : 27 GB
- VRAM : 4096 MB
2.4.1
2.5
2.7-9-g3265e4aa
https://github.com/doitsujin/dxvk/commit/14990dbb496c73d9310097159a8e2f737aea60ed
Is the offending commit but it doesn't introduce the queue sync
While it's unfortunate that it's slower now, this is a problem with the game more than anything else.
DXVK 2.5 adds a memory limit for D3D11_MAP_WRITE_DISCARD buffer updates. As far as I know, D3D11 drivers on Windows have such a limit as well.
Unfortunately, the game uses a MASSIVE almost 200 MB vertex buffer and updates that with DISCARD every frame.
This causes the game to exceed the limit for DISCARD buffer updates, which in turn makes DXVK wait for previously submitted work to finish so earlier memory can be reused. That's the queue sync you're seeing in the DXVK HUD in newer versions.
1439802 @1 ID3D11Device5::CreateBuffer(this = 0x65ebcac8, pDesc = [{ByteWidth = 188924896, Usage = D3D11_USAGE_DYNAMIC, BindFlags = D3D11_BIND_VERTEX_BUFFER, CPUAccessFlags = D3D11_CPU_ACCESS_WRITE, MiscFlags = 0x0, StructureByteStride = 0}], pInitialData = NULL, ppBuffer = [0x737ec0a0]) = S_OK
1566910 @1 ID3D11DeviceContext4::Map(this = 0x65ec4540, pResource = 0x737ec0a0, Subresource = 0, MapType = D3D11_MAP_WRITE_DISCARD, MapFlags = 0x0, pMappedResource = [{pData = 0x7efb0b913000, RowPitch = 188924896, DepthPitch = 188924896}]) = S_OK
1448923 @1 ID3D11DeviceContext4::IASetVertexBuffers(this = 0x65ec4540, StartSlot = 0, NumBuffers = 8, ppVertexBuffers = [0x737ec0a0, NULL, NULL, NULL, NULL, NULL, NULL, NULL], pStrides = [36, 0, 0, 0, 0, 0, 0, 0], pOffsets = [0, 0, 0, 0, 0, 0, 0, 0])
As far as I can tell, there's no good reason for why the game uses such a massive buffer. It doesn't draw a lot of geometry using that buffer, so it should either update the buffer with D3D11_MAP_WRITE_NO_OVERWRITE and treat it like a ring buffer or simply use a smaller buffer.
Overcooked All You Can Eat includes many of DLCs. and some of DLC meet frame drop from 90 to ~20 and we can see the "UnityGFXWorker" thread keeps in the running state 33ms per frame, CPU 100% busy.
the ever peckish risesis one of the abnormal status DLC.Software information
Overcooked All You Can Eat
1080P / Super Low Graphics Profile
System information
Apitrace file(s)
(https://drive.google.com/file/d/1gjAqVHWw0hC94Hi3dCZ_QtzlJZ4ZmOXE/view?usp=drive_link)
Log files
log-dxvk2.6.log
NOTE: dxvk 2.4.1 running normally and can get 100% GPU usage / 25% CPU usage
Using 2.6 instead of 2.7 is because the GPU Requirement doesn't met.