There is no uncached system memory type (yet; will probably get added).
When exceeding our fixed HVV budget with allocations from memory type 1, our fallback logic would only scan for DEVICE_LOCAL | HOST_VISIBLE and land on memory type 1 again instead of memory type 2, thus erroring out and causing games to crash unless no_upload_hvv is used, as seen in https://gitlab.freedesktop.org/mesa/mesa/-/issues/11177.
The proper fix here would be to have more sophisticated logic for allocating device memory, and feed back the memory type mask of failed allocations to the caller. There are more scenarios that are theoretically allowed by the spec where our current logic would brea, (e.g. two identical HVV types.
Current NVK exposes the following memory types, in this order:
There is no uncached system memory type (yet; will probably get added).
When exceeding our fixed HVV budget with allocations from memory type 1, our fallback logic would only scan for
DEVICE_LOCAL | HOST_VISIBLEand land on memory type 1 again instead of memory type 2, thus erroring out and causing games to crash unlessno_upload_hvvis used, as seen in https://gitlab.freedesktop.org/mesa/mesa/-/issues/11177.The proper fix here would be to have more sophisticated logic for allocating device memory, and feed back the memory type mask of failed allocations to the caller. There are more scenarios that are theoretically allowed by the spec where our current logic would brea, (e.g. two identical HVV types.