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
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.
The text was updated successfully, but these errors were encountered:
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_VISIBLE
and land on memory type 1 again instead of memory type 2, thus erroring out and causing games to crash unlessno_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.
The text was updated successfully, but these errors were encountered: