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
As noted in this PR, there are a number of extras that are being stored into the capture to describe the traced device capabilities. These extras are then used to decide how to generate the replay.
This is all a bit backwards - we should no assumptions that the replay device is the same as the one used for tracing. If we need to dynamically generate replay logic based on the replay device capabilities, then we should be storing this information in the VulkanDriver structure of the device. By doing this, you'll get this information in the capture header as well as for the replay device.
As noted in this PR, there are a number of extras that are being stored into the capture to describe the traced device capabilities. These extras are then used to decide how to generate the replay.
This is all a bit backwards - we should no assumptions that the replay device is the same as the one used for tracing. If we need to dynamically generate replay logic based on the replay device capabilities, then we should be storing this information in the
VulkanDriver
structure of the device. By doing this, you'll get this information in the capture header as well as for the replay device.There are already examples of this for GLES.
The text was updated successfully, but these errors were encountered: