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

Implement Portability Mode: Memory Type Translation #276

Closed
dustin-lunarg opened this issue Sep 5, 2019 · 4 comments
Closed

Implement Portability Mode: Memory Type Translation #276

dustin-lunarg opened this issue Sep 5, 2019 · 4 comments
Assignees
Labels
task Work to be performed

Comments

@dustin-lunarg
Copy link
Contributor

Map memory types/heaps from the capture device to the types available on the replay device based on memory properties.

@dustin-lunarg dustin-lunarg added the task Work to be performed label Sep 5, 2019
@per-mathisen-arm
Copy link
Contributor

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.

@dustin-lunarg
Copy link
Contributor Author

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.

@per-mathisen-arm
Copy link
Contributor

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.

@dustin-lunarg dustin-lunarg self-assigned this Nov 20, 2019
@dustin-lunarg
Copy link
Contributor Author

Closed with #339

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

No branches or pull requests

2 participants