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

Usability: Highlight changed values in Resource views #3496

Open
djeedai opened this issue Dec 7, 2024 · 4 comments
Open

Usability: Highlight changed values in Resource views #3496

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

Comments

@djeedai
Copy link

djeedai commented Dec 7, 2024

Thanks for RenderDoc. This is an amazing tool!

Description of Feature

While debugging some GPU particle system, I often find myself having to compare data between various points in the pipeline. This is made difficult by the fact several pieces of UI do not remember which items are selected or expanded.

In particular, for this specific item: RenderDoc has this amazing feature where you can select an event in the Event Browser and immediately see an updated view of a resource, without having to close/reopen that resource view. I've used other GPU tools from manufacturers which didn't have that and it was quite annoying. So this is a great usability feature.

Going one step further, it would be fantastic for the resource view when it refreshes to highlight which values changed. This would allow quickly identifying in a large-ish buffer what was written by an event. For example, the Visual Studio debugger does that when stepping through some C++ code: it will highlight in red in the Watch window values which just changed.

Here's an example where highlighting would really help:

Before (event N-1):
image

After (event N):
image

You can see on rows 86 and 87 that rgi.instance is still 0, while all other rows where overwritten with 3. When the table is large, spotting those in debugging can be a waste of time.

Environment

  • RenderDoc version: 1.35
  • Operating System: Win11
  • Graphics API: Vulkan (not relevant)
@baldurk
Copy link
Owner

baldurk commented Dec 7, 2024

Can you please explain what you're asking for more clearly? your description talks about expanding and collapsing things and then describes how RenderDoc works, but then you then talk about an unrelated change wanting to highlight differences as "one step further" but I'm not sure what that is one step further compared to. Is this a copy-paste error from the other issue you filed minutes ago?

@baldurk baldurk added Feature An improvement or feature Need More Info More information is needed from a user to work on this issue labels Dec 7, 2024
@djeedai
Copy link
Author

djeedai commented Dec 7, 2024

Sorry for the lack of clarity. I was trying to put some context on the request and my workflow with the first 2 paragraphs of the request.

In the two screenshots, I'm comparing the same GPU buffer before and after an event writes to it (a compute dispatch). Unfortunately that event only mutates few columns, and does so in a rather uniform way which makes the rows look almost all identical. So spotting what changed and what didn't is hard; I had to scroll slowly through the entire buffer. If differences were highlighted between the previous and current event, I could immediately see that rows 86 and 87 didn't change, while all others did.

The "one step further" refers to further improving usability of this workflow (comparing data before and after a command ran).

@baldurk
Copy link
Owner

baldurk commented Dec 7, 2024

OK so it sounds like the only request here is to identify changed values in a buffer whenever the contents update.

Doing that at the scale of a buffer is different from doing it for a few watch variables (which RenderDoc also does when debugging a shader) so this is not a trivial feature to implement. It's also likely extremely low priority so it's unlikely to be implemented for a long time.

Since you're using vulkan you might also consider adding printfs if that would help for your situation, to get more useful semantic information than digging through the end results.

@baldurk baldurk added Unresolved Waiting for a fix or implementation and removed Need More Info More information is needed from a user to work on this issue labels Dec 7, 2024
@djeedai
Copy link
Author

djeedai commented Dec 7, 2024

Yes thanks, I agree this is a low priority quality of life change, and there are other ways to handle this. I'm not sure why this is complex though, as you'd only need to update the visible portion of the active view of the resource, but I trust you probably see issues I'm not seeing. Thanks!

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

2 participants