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

Vulkan captures are not portable cross-vendor #814

Open
hrydgard opened this issue Dec 4, 2017 · 7 comments
Open

Vulkan captures are not portable cross-vendor #814

hrydgard opened this issue Dec 4, 2017 · 7 comments
Labels
Feature An improvement or feature Unresolved Waiting for a fix or implementation

Comments

@hrydgard
Copy link

hrydgard commented Dec 4, 2017

Here's a straightforward dump, taken on Windows:

http://www.ppsspp.org/unofficial/burnout.rdc

I've sent it to someone using RenderDoc on Linux, and it crashes trying to load it.

Is cross platform dump compatibility expected?

@baldurk
Copy link
Owner

baldurk commented Dec 4, 2017

Vulkan captures are generally not portable between even different hardware on the same platform. Things like memory type index selection and allocation offset/requirements are baked into the capture, so it won't replay correctly on a different driver that reports different memory types or requirements for resources.

You might be lucky if you capture and replay on similar nvidia GPUs, since it's the same driver on both windows and linux.

In future I'm hoping I can add some system to remap memory types, and report worst-case requirements (regardless of what the implementation reports) for resources, so that captures made on one system can be replayed on a different system. It's not a trivial issue to solve though, and until then vulkan captures are generally not portable.

@baldurk baldurk changed the title Crash when opening a Vulkan dump on another platform. Vulkan captures are not portable cross-vendor Dec 4, 2017
@baldurk baldurk added Unresolved Waiting for a fix or implementation Feature An improvement or feature labels Dec 4, 2017
@hrydgard
Copy link
Author

hrydgard commented Dec 4, 2017

Noted, makes sense.

It could be nice to bake the driver name and version into the file, and check it on load, warning the user to expect failures if they don't match the local GPU. Just UX sugar though.

@baldurk
Copy link
Owner

baldurk commented Dec 4, 2017

The physical device params are stored, but that doesn't always mean the capture is incompatible. E.g. nv's drivers seem to be largely compatible up and down several GPU families.

Latest code on v1.x branch should at least check to see if any memory requirements are violated on replay and will gracefully fail instead of crashing - that is by far the most common cause of problems at least.

@hrydgard
Copy link
Author

hrydgard commented Dec 4, 2017

Ah, that sounds good. Thanks!

@devshgraphicsprogramming

Maybe it should be possible to have some "restricted mode" when no replay is available, at least viewing the API call list and buffer states is helpful for remote debug.

@baldurk
Copy link
Owner

baldurk commented Nov 14, 2018

I don't know what you mean by 'buffer states', but you can export the capture to XML on any machine even if you can't replay, though it's not the most user friendly way to list all the API calls.

Viewing the calls in the normal UI won't be possible as the core replay code that populates the view of the capture is intrinsically linked to being able to replay the API calls, it's not feasible to separate the two.

@devshgraphicsprogramming
Copy link

devshgraphicsprogramming commented Nov 14, 2018

I see, at least there is XML

But can one export to XML without having to open the normal UI and capture on a compatible machine?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature An improvement or feature Unresolved Waiting for a fix or implementation
Projects
None yet
Development

No branches or pull requests

3 participants