Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HVV -> Sysmem fallback logic is flawed #2258

Open
doitsujin opened this issue Dec 20, 2024 · 1 comment
Open

HVV -> Sysmem fallback logic is flawed #2258

doitsujin opened this issue Dec 20, 2024 · 1 comment
Assignees

Comments

@doitsujin
Copy link
Collaborator

doitsujin commented Dec 20, 2024

Current NVK exposes the following memory types, in this order:

[0] DEVICE_LOCAL
[1] DEVICE_LOCAL | HOST_VISIBLE | HOST_COHERENT
[2] HOST_VISIBLE | HOST_COHERENT | HOST_CACHED

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.

@doitsujin doitsujin self-assigned this Dec 20, 2024
@Sid127
Copy link

Sid127 commented Dec 20, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants