Mesh output preview pane not properly displaying

SaschaWillems commented 5 years ago

Description

Trying to debug a complex scene in my Vulkan glTF PBR sample I noticed that the mesh output does not actually display the mesh preview anymore, but instead i get random contents from other views. I had a similar problem like that long time ago with the texture viewer, but this one is reproducible and only seems to happen with larger captures:

I have tested this with the latest 1.2 release and the nightly from 2019-02-22 and both exhibit this problem, though I noticed that the nightly is slower on selecting the draw calls from the tree and sometimes crashes without any warnings.

Repro steps

~~I have uploaded a capture from the latest nightly that exhibits this problem here Small warning: that file is 390 MBytes large, even though it's zipped.~~

If you want to manually test this:

Download the Littlest Tokyo model from https://sketchfab.com/3d-models/littlest-tokyo-94b24a60dc1b48248de50bf087c0f042
Fire up my Vulkan glTF PBR example from https://github.com/SaschaWillems/Vulkan-glTF-PBR
Use "open glTF file" from the UI of my sample

Environment

RenderDoc build: Tested with v1.2 and the nightly from 2019-02-22
Operating System: Windows 10
API: Vulkan
GPU: NVidia GTX 980
Driver: NDA (but recent)

SaschaWillems commented 5 years ago

Small update: This may be caused by undefined application behavior, even though the sample runs fine by itself. Will do some additional testing :/

Edit: It actually was an application bug that caused this behavior, so closing this.

SaschaWillems commented 5 years ago

One thing I noticed though: I can barely work with this capture using the latest nightly. Selecting draw calls is extremely laggy and puts a high load on my system. So if you want to check that out, I have uploaded an updated nightly capture here.

baldurk commented 5 years ago

What is 'extremely laggy' for you? When I open the capture it's certainly not lightning fast, it takes 0.25 - 0.5 seconds or so, but it's not slow either. How long does it take on your system?

SaschaWillems commented 5 years ago

On the latest nightly with that capture, my whole system is lagging for up to 10 seconds when selecting a draw call from the event list, and sometimes up to a point where RenderDoc stops responding at all. With the 1.2 build this works fine. My CPU is an AMD FX-6350 and a bit outdated, but the nightly seems to be much slower then the latest release build for me. I also noticed that the nightly trace for the same since is almost twice this size.

baldurk commented 5 years ago

That's definitely an extreme case. Can you record a ETW trace with UIForETW of what's taking the time?

Also I'd be interested to know when this changed, if you could bisect the builds since v1.2 that would be very helpful. The file size in itself isn't necessary a problem but I don't think anything should have changed.

mwilkason commented 7 months ago

Small update: This may be caused by undefined application behavior, even though the sample runs fine by itself. Will do some additional testing :/

Edit: It actually was an application bug that caused this behavior, so closing this.

Hello, sorry for tagging you on an old issue, but I think I'm currently experiencing the same issue as you, and just out of curiosity I would like to know what the application bug was that caused this. I'm having a very difficult time tracking it down.

baldurk commented 7 months ago

Please do not comment on old issues that have been closed.

If you are encountering a bug or are requesting a feature please open a new issue. You can reference this issue if you wish, but opening a new issue prevents any confusion of accidentally linking two unrelated issues and means that each issue can be handled in a clean process.

baldurk / renderdoc