-
Notifications
You must be signed in to change notification settings - Fork 123
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
Implement Portability Mode: Memory Type Translation #276
Comments
Is the plan to do this differently than what is currently implemented in vktrace? My biggest concern is that when going from a system with a few memory types with many flags to systems with many memory types with a few flags each, then you may not have sufficient information about which flags matter unless you split the memory types while tracing. Also, at least in theory, a tracer may have to create its own memory handling of buffers similar to how optimal images are handled in vktrace, since an implementation where you want to replay may require some kinds of buffers to go into a particular kind of memory type, while the trace host might only use one memory type for all types of buffers. And the vktrace way of putting each optimal image into their own VkDeviceMemory may not scale, as there is only a limited number of VkDeviceMemory that are available to use in total. |
The plan for the memory type translation would be to defer memory allocation until image or buffer memory bind. At bind we would determine the appropriate memory type based on the usage flags specified at resource creation. This should allow us to select the appropriate memory type for cases such as an iGPU capture where all memory types have a combination of the DEVICE_LOCAL and HOST_VISIBLE flags and a dGPU replay where the DEVICE_LOCAL and HOST_VISIBLE memory types are separate. This will be a replay option that can be enabled or disabled explicitly. This will also result in cases where resources sharing the same memory allocation at capture will be split into separate allocations on replay. When splitting into separate allocations, we would like to avoid creating a single allocation per resource. The plan for the initial implementation is to use AMD's Vulkan Memory Allocator to handle memory allocation and manage resource sub-allocation. |
Sounds like a good plan. Another way to solve the first problem of replaying traces from architectures where memory types have combined DEVICE_LOCAL and HOST_VISIBLE is to split them in the tracer, so that the traced program only sees separate DEVICE_LOCAL and HOST_VISIBLE memory types. |
Closed with #339 |
Map memory types/heaps from the capture device to the types available on the replay device based on memory properties.
The text was updated successfully, but these errors were encountered: