• Advertisement


GDNet+ Basic
  • Content count

  • Joined

  • Last visited

Community Reputation

1028 Excellent

About baldurk

  • Rank

Personal Information


  • Twitter
  • Github
  1. Oh I see. Is there any reason that a dummy interface has to be returned instead of the actual one? Or do you mean in cases where that flag isn't set? It isn't like it's a big deal (to me anyway) in any case; I usually use RenderDoc for more specific debugging purposes where the debug layer won't give any (meaningful to the problem at hand) output anyway. Checking the "Create debug device" box apparently makes it work like you say as well, that I didn't think to try that... I assumed it would just create the device if my application didn't by itself. In any case, all good.   Right this is the issue - when the debug checkbox is enabled in renderdoc, it will force on the debug flag even if the application didn't request it. If that checkbox isn't enabled, then renderdoc will remove the flag even if the application requested it. The idea being what you're talking about - generally when you're running through renderdoc you're not in a position to look at the debug output anyway, so if renderdoc isn't set up to save it then why pay the cost of the overhead? In this case I should return a dummy interface so that the application isn't any wiser.
  2. Ah, upon checking the docs it seems like it's only valid when D3D11_CREATE_DEVICE_DEBUG is enabled, but RenderDoc 'takes control' of that flag and will remove it if you didn't check 'create debug device' when capturing. I'll do the same as I do for ID3D11InfoQueue and return a dummy interface that does nothing.   Yeh mostly I haven't done it because I haven't given it too much thought. I want to make sure I do it right rather than confusing people a lot, and so far there's been higher priority stuff to implement.
  3. Fixed and I've snuck that into the new v0.29 I was in the middle of preparing. Long story short, I recently moved InputLayouts so they were reference-tracked for inclusion into captures rather than just all being included. When I did that, I failed to mark that initial-state layout as referenced, so it got trimmed from the log. This actually also exposed a bug where any executable with 'renderdoc' in the filename wouldn't capture due to an overly aggressive filter on which modules to hook. I'll fix that at some stage but it's unlikely to trip many people up.   Which debug interface is that? Querying for ID3D11Debug should work just fine, is there another one?   Hmm, could be a few things I guess. If you do manage to spot a pattern file an issue on github and I'll look into it   Yes editing states and resource contents is a common request and one that I have on my roadmap. The implementation isn't too bad actually, but it's a question of how to display it in the UI - and with D3D11 when you edit a state does it just apply at that drawcall? or until the next time the state changes? or is it retroactive further back elsewhere in the frame, where the same state object is used. At different times you might want all three options, so it's a complex UX task to solve.
  4. This case should be handled, although I imagine there can be edge cases that are buggy. RenderDoc keeps track of the current state at any point on the immediate context, and serialises that out at the start of the frame, when replaying it restores it again. Do you have an example that reproduces the missing tracking?   "Save All Initials" just overrides an optimisation heuristic that makes RenderDoc skip the initial frame contents of render targets that look like they're entirely overwritten in the frame.       This is mostly there so that I can catch any cases where objects have QueryInterface called for some GUID I'm not handling. This can lead to non-wrapped D3D handles leaking out that can lead to crashes or just bad behaviour. In this case it's some internal secret GUID that's queried inside D3D, so it's harmless.   Yep, I'm aware of that, thanks for pointing it out though.     I'm not aware!  :). Do you notice this happening consistently in some situations? or is it just every now and then something seems overly cached and needs a repaint.   I'm glad it's useful, hopefully I can make it a little more bug-free :wink:.
  5.   If there's reasonable doubt that it's a bug in RenderDoc I don't mind taking a look at it - oftentimes even when it ends up not being a RenderDoc bug I can point you in the right direction.   Sharing an executable is better than sending a capture because it gives me more ability to investigate - I might look at the capture, see the problem is 'oh, X is missing', but then need to go back to the executable to add logging or debug it to figure out where X got to during capture. Not everyone is comfortable sharing executables all the time though, so I help with whatever they can share.
  6. Likewise, reporting RenderDoc bugs will get the swiftest response if you report them directly to me on github :). Do you have an example capture or runnable executable you can share to demonstrate the problem?
  7. Depth Problem In Release Mode

    Do you have another repro project to share that still runs out of memory with smaller images? It's expected to see higher memory usage while using RenderDoc since it is storing shadow (CPU-side) copies of graphics resources. The memory for those graphics resources for the GPU is not counted in task manager, so it's 'invisible'.   Also just in case there is some confusion you mention that you reduce the image size to "2.5MB" which doesn't quite make sense. Even though your image is stored as a .jpg, the disk size makes no difference and compressing it further will not change the memory usage in D3D11. The memory usage is entirely determined by the resolution, format and number of mip levels - in this case the .jpg in the example project you uploaded is 5184x3456 and it is created as uncompressed R8G8B8A8 with a full set of mipmaps. That's where the memory use comes from not the file size on disk.   btw, this might be more appropriate to move to a github issue.
  8. Depth Problem In Release Mode

    Thanks, I repro'd the crash. It's actually simply running out of memory - the program is creating a ~90MB texture every second or so. By default renderdoc saves a copy of this data on the CPU in case the texture is modified (so it can track changes in-place rather than needing to save every delta), eventually the allocation fails. I guess since it's a 32-bit process. I'm surprised how soon it fails actually as it only hits ~1.3GB for me, but maybe memory has fragmented enough that there isn't a large enough contiguous block. That's a complete guess.   I'll maybe see if I can add a heuristic so that large textures aren't shadowed unless absolutely necessary, but that still might not help depending on how many of the images are referenced in a frame. If they're all referenced, renderdoc will still allocate memory to readback their contents, and will be back to square one. I'd suggest either switching to 64-bit or using smaller textures if possible :).
  9. Depth Problem In Release Mode

    Do you have any repro details you can share for the RenderDoc crash? e.g. is your application available online anywhere to test?   I found some source project that was using D3DX11CreateShaderResourceViewFromFile(), but it works OK - so I guess it's something particular that's crashing. If you download one of the latest nightly builds it comes with pdbs too, so getting the callstack with file:line information would be helpful.
  10. RenderDoc, Viewing .DDS Files

    Send me an email (baldurk@baldurk.org) and I can help debug it. v0.25 has broken DDS loading (whoops...) but for earlier versions there shouldn't be any dependency on VS2012 since I make the builds from VS2010.
  11. FYI - If you don't specify a working directory, RenderDoc defaults to setting the working directory to the directory the exe is in. For visual studio that might not be the same as when you hit F5 to run, as the exe often lives in a Debug/ directory.   But if it's only GL functions that are failing, and your own code to load your shaders from disk is fine, then that sounds like a bug in RenderDoc. If you can give me the program that triggers it I can probably fix it.
  12. Wow that's crazy, I didn't realise it had a different meaning on output signatures. I've fixed it so that it's not so confusing :).
  13. The shader seems fine to me, the only part of it that will actually have any effect is the position calculation, as the pixel shader isn't using any of the other inputs.   If you say that the grid of vertices seems fine, what exactly is showing as 'unshaded' in the mesh view? By default it's just a wireframe view of the triangles, so the only thing I can think you mean is you have 'flat shaded' selected on the output and one face is showing up black - that would imply the winding order is incorrect on that face (meaning the normal is calculated backwards).
  14. On the mesh view, if the input vertices are all identical that means something is likely wrong with your index buffer set up. The first column shows the vertex ID, ie. linearly increasing from 0. The second column shows the index from the index buffer, which should be different (e.g. for a triangle list it might be 0, 1, 2, 1, 2, 3, 4, 5, 1 or whatever). Double check your indices are as you expect them to be. If the output vertices are all the same but the input vertices are OK, it's something in your vertex shader, so you could try right clicking -> debug selected vertex and step through two different vertices side by side to see what's wrong.   The raw "buffer contents" view is for when you have just a chunk of memory that you'd like to view in an arbitrary format, and the text box near the bottom lets you enter the format - by default it is probably showing the data as int4s (possibly in hex depending on the version you're using). You could always manually enter your input layout, e.g. "float3 pos; float2 texcoord;" and see it that way to verify that the vertex buffer is correct, but if you're just looking at mesh data the mesh view should show you everything you need as it interprets the vertex buffers and input layouts as D3D11 will.   If clicking Go next to the index slot in the InputAssembler doesn't do anything that suggests perhaps there isn't an index buffer bound somehow. It should open up the "buffer contents" for the index buffer itself. Is it highlighted in red? If so then there isn't an index buffer set. I've noticed it's not as clear as it could be (it says 'buffer 0' and suggests it's 1 byte long), I'll fix that.   The numbered slots are your vertex buffers, vertex shader data is on the vertex shader tab, under constant buffers. The vertex inputs come from the elements in your input layout, each element can point to a vertex buffer with a given offset. The concept is fairly analogous to modern opengl's vertex attributes and vertex buffers (where attributes have an offset, format, and binding to a vertex buffer slot, and vertex buffer slots bind the actual buffer as well as its stride).
  15. If you're willing to share it or email to me, I'd be interested to run the program myself or look at a capture. I don't mind assembly shaders :). Getting the wrong inputs in the pixel shader means a bug in renderdoc and I'd like to fix it if I can!
  • Advertisement