baldurk commented 6 years ago

tl;dr

v1.0 is coming soon and nightly builds are converging as it stabilises. I'm asking for testing and any general feedback to improve the v1.0 release. RenderDoc_2018_02_26_d130b965: Windows x64 & Linux x64 is the latest at the time of writing.

v1.0 Release candidate

The features and overall scope for v1.0 is now locked down, but there have been significant internal and external changes since the last stable build v0.91.

I'd like to ask people who have the time to please test the current v1.x nightly builds. Please give me feedback or bug reports no matter how small they may seem. You can either file new issues, or comment here for general feedback, or contact me directly.

There's still some work to do before v1.0 stable ships and I will be doing my own testing and polishing of course, but the more feedback I get now the better the v1.0 release can be.

Changes

A full changelog and release notes will follow when v1.0 ships, but the high-level summary of the most changed areas:

The internal serialisation has been revamped, so if nothing else simply capturing your program and then replaying it back to ensure there are no crashes or corruption in the replay would be very useful.
This also enabled several features, including the resource inspector. Any time you see a name with a link icon you can click it to jump to the resource inspector, listing all the calls associated with that resource, parent/child objects, and letting you rename it at runtime.
RenderDoc now supports Vulkan and GLES3 on Android. More information is available in the wiki but it uses the same workflow as you're familiar with on desktop. The same restrictions as desktop GL apply with regard to minimum feature support and multiple context use.
For windows, the UI program has changed. The previous .NET-based renderdocui has been removed and the Qt qrenderdoc originally developed on/for linux has now been rolled out to all platforms. This should work identically, but has a number of benefits e.g. proper high-DPI support for those unfortunates who need it.

The biggest thing you can help me with is simply giving wider coverage - I only have a limited set of applications I can capture and replay to test with, and no matter how much I try to cover everything there's no substitute for a dozen people all trying it in their own way! :smile:

Known issues

Old captures are not compatible. This is deliberate, and a best-effort converter may be provided for the final release, but for now you need to make new captures.
Using GLES on Android some images won't have proper contents if they are frequently updated in app.
~~The texture overlays are not yet supported when using GLES on Android~~.
~~In some cases on vulkan particularly with complex vertex inputs, the mesh output will be incorrect~~.
MSAA textures will not display on Android.
~~Several small things around the Qt UI need polish or fixing~~.
~~Issues overwriting files while saving captures~~.
~~Save texture dialog doesn't handle file types well~~.
~~Vulkan mesh output doesn't support primitive restart~~.
~~Shader window titles always use vertex shader name~~.
~~Scintilla controls don't properly follow the dark theme~~.

I'll keep this issue updated as new issues are found or existing ones are addressed.

Any and all help is much appreciated! Thank you.

zeux commented 6 years ago

Minor regression: double-clicking process name in the Inject Into Process list doesn't attach (https://github.com/baldurk/renderdoc/pull/448)

baldurk commented 6 years ago

Damn, I thought I'd ported that across to the Qt UI. Fixed now :smile:.

Srekel commented 6 years ago

First impression on Windows 10: It's very... gray? Like the theme feels like something for Windows XP, if even that. It kind of has that "disabled" (as in "I can't interact with these elements") color?

Here's a comparison with some other applications I'm currently running:

Edit: Maybe it's not old Windows I'm comparing to but old Unix applications, like how things looked when I was at university 15 years ago.

Srekel commented 6 years ago

I've got a crash when clicking around in the tree view with the texture tab open. Got it twice now so seems reproducible.

baldurk commented 6 years ago

Regarding the theme this will always be subjective I think, it's not possible to please everyone. It doesn't seem very different to the other windows to me - I'm not sure if you are referring to he buttons on the event browser, but they are disabled/greyed out because there's no capture loaded. It will be somewhat different in the end just because I personally find the flat design of windows 10 quite ugly :smile:.

If you prefer it you can change to a dark theme in the settings window, or else change to Qt's native platform theme (which still may or may not match what you expect). In theory you can use a custom Qt theme, although I haven't tried that.

For the crash can you give me the reproduction steps you ran into, so I can investigate and fix the bug?

redorav commented 6 years ago

@Srekel I agree the default theme on Windows looks dated (interesting that you shpuld compare it to 7-zip which is quite unappealing ;p), but changing it in the settings window makes it look much more Windows-like. Maybe this could be the default, at least on Windows?

TheMartynBliss commented 6 years ago

There is no text content in the right hand pane of the help notextinhelp

TheMartynBliss commented 6 years ago

If you have multiple captures, and save one of the frames as a specific file name. And then try and save another frame to the same filename, you get the message below rather than a 'do you really want to overwrite this file' message cantsave

TheMartynBliss commented 6 years ago

If you save a capture and then double click on it to load (it will not load the release candidate but the last installed version). it then hangs trying to load the file

Srekel commented 6 years ago

Aha, yes the native and dark themes look better (subjectively, of course :) ). Maybe use Native by default?

As for the repro steps:

I launch our app (it uses Vulkan) through renderdoc.
Press Trigger After Delay
Load the capture
Switch to texture viewer (not sure if necessary)
I can click around on many things in the Event browser, but (at least) one specific entry causes it to crash if I click it.

Is it possible to get a debug build, or does it generate logs or a minidump I could attach?

TheMartynBliss commented 6 years ago

Not sure if this is an issue or just my lack of experience with the tool. I loaded a previously save capture and did looping replay. I then wanted to sample the performance counters but clicking the button did nothing?

marco-we commented 6 years ago

It would be nice if it made the selected file format the default in the "Save Texture As" window. Bonus points for remembering the last selected file format ;)

baldurk commented 6 years ago

OK these replies are coming too fast all of a sudden for me! Batched response to hopefully catch up:

@redorav @Srekel Like I say I think this will always be subjective. I don't personally think it looks dated, although it doesn't look like modern windows (after Win 7) which I think is a very good thing. The default will stay as it is since I think Qt's native theme looks particularly bad sometimes:

So I'd rather have my own consistent theme cross-platform. Having a custom theme also allows me to define light/dark modes which was requested. I'm surprised you think the dark theme is better - it's precisely the same design just with an inverted colour palette.

In the end the option to switch to Qt's native platform theme is there for those who want it.

There is no text content in the right hand pane of the help

@TheMartynBliss I think I've seen this before where the downloaded zip is marked as 'untrustworthy' by windows, and it refuses to load the pages without displaying any error message.

Can you try closing the program, going to the file properties on the .chm file from explorer and seeing if there's an "unblock" button? Or just open the .chm directly from explorer and it might prompt you. I'm not sure there's much I can do about this myself. More info on MS's site here.

If you have multiple captures, and save one of the frames as a specific file name. And then try and save another frame to the same filename, you get the message below rather than a 'do you really want to overwrite this file' message

@TheMartynBliss I'll look into this, thanks!

If you save a capture and then double click on it to load (it will not load the release candidate but the last installed version). it then hangs trying to load the file

@TheMartynBliss Yes the zip doesn't change any file associations, and the existing renderdoc can't open the file. For me it seems unfortunately because the version error message pops up quickly it seems that there's a bug in the .NET UI which hides it behind the progress bar or something, so it looks unresponsive/hung. Normally a popup during loading would happen later and appear normally, I think. If I alt-tab then I can get to the "Error opening log" popup. Do you get that?

Is it possible to get a debug build, or does it generate logs or a minidump I could attach?

@Srekel The easiest way to get a debug build is simply to sync and build from github - just download the source from the v1.x branch and build the VS solution, no other steps should be necessary.

My suspicion is that when you select that particular event it fetches the mesh output, and this is what's crashing. Can you try closing the mesh output window before selecting it to see if that avoids the crash? If that's it, I'll need some more repro info - ideally the capture itself, but at least the shader which is bound at that point so I can see why it might be failing to fetch.

Not sure if this is an issue or just my lack of experience with the tool. I loaded a previously save capture and did looping replay. I then wanted to sample the performance counters but clicking the button did nothing?

@TheMartynBliss I'm not quite sure what steps you're taking here.

The 'replay loop' in the tools menu is designed specifically so that you can capture renderdoc in an external tool like AMD's RGP - it has no purpose or function in renderdoc. While the replay loop is open you cannot use the rest of the UI. I could perhaps add a progress dialog to make this clearer.

When you say you tried to sample the performance counters, did you click the timing button in the event browser to get per-draw times, or did you open the performance counter view? The latter is still work in progress and is not really useful right now. If you click 'capture counters' it should open a dialog to let you select which counters you want to collect, then clicking "sample counters" will fetch all of those counters for each draw. Let me know if that's what you were trying or which button did nothing when pressed.

It would be nice if it made the selected file format the default in the "Save Texture As" window. Bonus points for remembering the last selected file format ;)

@marco-we good point, I've been meaning to look at this dialog again because it can get a bit fiddly selecting the different options.

EBatut-ALG commented 6 years ago

Hi Baldur

Looking at a D3D11 capture, opening the pipeline state view, then the Pixel Shader box, then the "View" button near the "Pixel Shader 95" name box opens a tab titled "Vertex Shader 72", while I would expect "Pixel Shader 95" instead.

Viewing the Vertex Shader rightfully opens a tab titled "Vertex Shader 72".

Also, not sure it's a bug or not, but it looks like the dark theme is not obeyed in the shader disassembly view (text is still "black on white BG").

Great news re: RenderDoc 1.0 and congrats for the upcoming release !

baldurk commented 6 years ago

@EBatut-ALG I think I've repro'd this. Can you just confirm that the shader itself is the correct one, it's just the window title that's wrong? It looks like I'm updating the window title before I set the right shader stage, so it picks the vertex shader by default.

Yes I think it's probably a bug that scintilla controls anywhere aren't dark themed. I don't use dark themes so I'm not sure what people expect exactly, but it seems like it would fit better.

EBatut-ALG commented 6 years ago

I can confirm the shader is the correct one, it's just the tab title that is wrong.

Re: the dark theme and the disassembly, this feels weird when the entire application is dark (I personally find it easier on the eyes) and the text view still has a white BG, but I don't know if the Qt theme can correctly propagate to the Scintilla text view :( It's certainly not a release blocker though, more a matter of personal preference...

baldurk commented 6 years ago

I believe it doesn't propagate by default because the Qt wrapper around scintilla is pretty thin to expose commands and propagate events, and then scintilla does all its own custom painting. However it should be possible to set the style to a dark theme - it just means going the long way around and setting every colour that scintilla uses to the appropriate dark alternative.

tafuri commented 6 years ago

It seems to me that the mesh preview does not correctly handle primitive restart with the vulkan backend. The vertex data is showing the "Restart" marker and it looks correct when running through DX11. But when using Vulkan it seems to include the restart index in a single long strip. The mesh looks correct in the original application. I can not 100% rule out that I have not made another mistake yet though.

baldurk commented 6 years ago

@tafuri that sounds quite possible, I had to rewrite the mesh fetching code to work with mobile GPU limitations. I'll check this out, thanks!

baldurk commented 6 years ago

@TheMartynBliss @marco-we @EBatut-ALG these issues should be fixed on v1.x in the next nightly build:

@Srekel I don't know if it will fix your case - I'm not sure if you verified it was the mesh output or not - but I did also fix a few potential crashes in the mesh output fetch on Vulkan. If you can try with the next nightly build that would be great, and give more info so I can diagnose the problem if it's still broken.

EBatut-ALG commented 6 years ago

Great news, thanks!

jansol commented 6 years ago

Scintilla controls don't properly follow the dark theme.

This is still a problem when using a natively dark theme (Breeze Dark) on linux (rev 2300a94).

jansol commented 6 years ago

I'm also still seeing VK_ERROR_OUT_OF_DEVICE_MEMORY when skipping around indexed indirect drawcalls in the mesh viewer in Sasha Willem's indirectdraw demo.

EDIT: discussed this on IRC, concluded that it's an inevitable situation as renderdoc stores every output vertex of every instance, which would not happen during normal rendering. The main question is how this should be handled. See #870

baldurk commented 6 years ago

@tafuri I believe I've fixed the issues with primitive restart indices in vulkan mesh viewer, please check it out on the next nightly build when you get a chance.

@Srekel I've also fixed some more mesh output bugs on Vulkan, but without any repro/further information from you I'm not sure if it fixes the crash you had or not.

EDIT: Note until v1.0 I am still breaking backwards compatibility of v1.x captures, so if you made some a few days ago they might not open now. I'm not promising backwards compatibility until v1.0 actually ships, to avoid needless legacy code.

Srekel commented 6 years ago

Sorry, I've forgotten to test again. I'll try and do it during the weekend. :)

tafuri commented 6 years ago

@baldurk Yes, now it looks as expected. Thanks!

EBatut-ALG commented 6 years ago

Hello @baldurk (force-pinging you because I don't know if new replies just pop up on your radar otherwise, I apologize if that's not needed)

It looks like during a D3D11 capture, even if the scissor values are captured correctly, it is not applied during capture replay, which produces incorrect textures. This is on build https://github.com/baldurk/renderdoc/commit/b7c69bd82393ee6013f1fbf3dcf285c6c96c8735.

On the attached capture, it happens at EID 35. The end result of the capture should be the DDS included in the attached zip. out_0000_2E1FB2AF.zip sbsextract_capture_frame0.zip

Is this enough info for you to have a look or do you want me to send you a test exe?

Cheers, Eric

baldurk commented 6 years ago

Thanks for reporting this! FYI I do indeed get pinged for all replies on this repository, I think so do any people who 'watch' it.

The bug here seems to be that the rasterizer state that's supposed to be bound at the start of the frame wasn't referenced and included into the capture, so you end up with "No Resource link " on the pipeline state - and the default rasterizer state has scissor disabled.

If I export to xml, add a create chunk for the needed rasterizer state, and import, it works fine:

<chunk id="1024" name="ID3D11Device::CreateRasterizerState" length="33" threadID="11724" timestamp="180123" duration="10">
  <struct name="Descriptor" typename="D3D11_RASTERIZER_DESC">
    <enum name="FillMode" typename="D3D11_FILL_MODE" string="D3D11_FILL_SOLID">3</enum>
    <enum name="CullMode" typename="D3D11_CULL_MODE" string="D3D11_CULL_BACK">3</enum>
    <bool name="FrontCounterClockwise" typename="bool">false</bool>
    <int name="DepthBias" typename="int32_t" width="4">0</int>
    <float name="DepthBiasClamp" typename="float" width="4">0</float>
    <float name="SlopeScaledDepthBias" typename="float" width="4">0</float>
    <bool name="DepthClipEnable" typename="bool">true</bool>
    <bool name="ScissorEnable" typename="bool">true</bool>
    <bool name="MultisampleEnable" typename="bool">false</bool>
    <bool name="AntialiasedLineEnable" typename="bool">false</bool>
  </struct>
  <ResourceId name="pState" typename="ID3D11RasterizerState *" width="8" string="ResourceId::31">31</ResourceId>
</chunk>

(also, hooray that is pretty cool to be able to do! :smile:).

The bug is that I started tracking state objects on their own instead of just including them all in the capture because I ran into a bug where a program allocated more state objects over its lifetime (releasing many of them along the way) than were legal to exist at anyone time. Whenever they were bound to the pipeline I referenced them, but I forgot to mark referenced the initially bound resources at the start of the frame.

Should be fixed with that commit up there, but you'll have to recapture.

EBatut-ALG commented 6 years ago

Great, thanks a lot!

The weird thing is that in the Pipeline State viewer, the Rasterizer correctly lists the right values for the Scissor regions, so they're included in the capture somewhere but not fed to the Replay subsystem. Is that consistent with your investigation?

baldurk commented 6 years ago

Yep that makes sense. In D3D11 the scissor rects are set independently of whether scissor is enabled or disabled, unlike e.g. Vulkan where scissor is always implicitly enabled and you just have to set scissor rects that cover the whole viewport to 'disable' it.

In your capture there wasn't an explicit call to RSSetState anywhere - if there had been it would have worked. Instead at the start of the capture there was a little reference saying "Hey, bind rasterizer state 31 please at the start of the frame", except rasterizer state 31 hadn't ever been created. So you ended up with the default NULL state that has scissor disabled:

With the fix, state 31 will be included into the capture and created. If I manually add it into the capture you can see things looking better:

There's also the viewport/scissor overlay in the texture viewer which shows a dashed line around the scissor rect if it's enabled, which is a little less direct but when scissor is disabled the dashed line disappears entirely so that's another indication.

EBatut-ALG commented 6 years ago

Ah, I see now.

Many thanks for the detailed explanations and for the ultra-quick fix !

baldurk commented 6 years ago

Open question for anyone still paying attention to this bug: I've built a simple converter utility to convert from v0.x compatible captures to v1.x compatible captures. You just run rdcconvert mycapture.rdc and it will spit out converted_<date>_<time>.rdc. It's not perfect but it works reliably on my testing with a variety of captures and is another option for people to have - the older builds aren't going away so it's always possible to get a zip of v0.91 and saving it next to your captures for use.

I'll push the source to it up as a branch off v0.x, but I wonder what the best way to distribute a binary build is. It doesn't really fit on the downloads page which is automatically generated, so I was thinking of just linking the download from the v1.0 release notes. Does anyone have any different ideas?

General note - I plan to release at the start of next week so if you have any bugs to report, now's the time :smile:. I'm hoping the silence means the build is solid.

baldurk commented 6 years ago

Thanks for the testing and feedback everyone! v1.0 has now shipped.

Onwards and upwards!

TheMartynBliss commented 6 years ago

Congratulations Baldur!

From: Baldur Karlsson [mailto:notifications@github.com] Sent: Tuesday, March 6, 2018 3:25 PM To: baldurk/renderdoc renderdoc@noreply.github.com Cc: TheMartynBliss martyn.bliss@samsung.com; Mention mention@noreply.github.com Subject: Re: [baldurk/renderdoc] [Announcement] RenderDoc v1.0 release candidate for testing (#862)

Thanks for the testing and feedback everyone! v1.0 has now shipped.

Onwards and upwards!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/baldurk/renderdoc/issues/862#issuecomment-370817562 , or mute the thread https://github.com/notifications/unsubscribe-auth/AVtivBKFlMtw96hvQMtLMysGpSiSCs0Lks5tbqpFgaJpZM4R7lfz .

baldurk / renderdoc

[Announcement] RenderDoc v1.0 release candidate for testing #862

tl;dr

v1.0 Release candidate

Changes

Known issues