Open ghost opened 3 years ago
Sounds like the same issue reported in https://github.com/libcg/grvk/issues/5#issuecomment-776173424
This is a game bug caused by the Nvidia driver exposing a bunch of memory types. It does this because not every type supports every image format, which doesn't map well with Mantle unfortunately, that will need to be handled too.
I'm not sure what's the best way to fix this yet. In the meantime, I could hide the memory types that don't expose all formats. It might work, but the performance will tank on Nvidia.
What bugs me most is the fact that the device pointer goes crazy. Can this - by any chance - be a bug in Star Swam? I mean, why would the device pointer chance at all? Maybe it was not designed for so many heaps? I don't understand why Vulkan differentiates between types and heaps. My naive guess would be that Star Swam expected like 3 instead of 10.
Regarding what to do, my priority would be: Get it running first and care about performance later. Also due to the limited number of games supporting Mantle, a simple list with quirks might work just fine. (Similar to mesa)
@sehraf Yes, the invalid pointer is caused by the excessive amount of memory heaps. After thinking about this more, I might not be able to just hide certain heaps. GRVK will need to expose less heaps to the Mantle app and route allocations to the right types behind the scenes.
So, it turns out Mantle only supports up to 8 heaps (GR_MAX_MEMORY_HEAPS=8), which means it's not a game bug but an API limitation. I also found out that the apps will allocate from the correct heap as indicated by grGetObjectInfo
before calling grAllocateMemory
. It's just a matter of hiding the right heaps and reindexing correctly.
There are 2 good candidates to eliminate out of 11 types:
memoryTypes[3] exposes D24 types that are unused in Mantle
Where do you get that information from? Looking at VulkanCapsViewer memory type 0 to 6 look identical on a RTX 2060.
Here's a vulkaninfo dump with the relevant info: nvidia_mem_types.txt
memoryProperties.memoryTypeCount returns 11 heaps, but on the 10th heap the device handle changes abruptly and causes a memory access violation, it only works if I limit it to 9 heaps, below 9 heaps GR_GPU_MEMORY becomes null in grMapMemory()
System information
Log files
grvk-8-heaps.log grvk-11-heaps.log