Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Memory allocation on Intel Atom chips #947
Intel Celeron N2840
For quite a time the DXVK wrapper have been completely unusable for me because of alot DxvkMemoryAllocator: Memory allocation failed errors. Most games renderings are pitch black, with rare exceptions. I put some efforts to investigate into this showstopper and now i think has found the clue.
According to Mesa sources (intel/vulkan/anv_device.c):
So, when got unlucky GPU you cannot have HOST_COHERENT_BIT and HOST_CACHED_BIT flags both set! Having this in mind i made a proof of the concept code insertion in DxvkMemoryAllocator::tryAlloc
Perhaps, i did it ugly way but it indeed fixed the problem, or at least, sweep it under the carpet. No more errors of THAT kind, backgrounds and models are fine, textures in place. There are still some known BayTrail-vulkan related visual glitches and issues in games because of unfinished drivers but that's irrelevant to DXVK.
The essential from DXVK logs seem to proof the findings:
Yes, those property flags in logs again. I hope the above will help to get Intel Atoms in line.
Unfortunately, supporting non-coherent memory is also very hard, especially when we don't want it to tank performance for the vast majority of hardware where readback memory is coherent. For D3D11, mapping and unmapping buffers (which is where we'd have to implement this) is performance-critical.
I don't have an Atom setup to test with anyway, although I could potentially simulate similar behaviour through a Vulkan layer.
For BayTrail, as for any build-in graphics with shared memory APU there is no great solutions really. And it seems there is no much choice but to hurt its performance for now. If it will just work, then it would be good enough already. Later on it could be fixed with a more strict flag management (if it is possible so) or some clever finding.
Just as i see it.