Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

1029 Excellent

About baldurk

  • Rank

Personal Information


  • Twitter
  • Github

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. baldurk

    RenderDoc and D2D/DirectWrite

    Are you able to share your program with me, or do you know of another open sample that reproduces the same problem? If you want to get in touch off the board, my contact info is on the renderdoc github. I have tested with D2D in the past and fixed issues that have come up, but it could easily be that something new has cropped up which I'll need to fix. To fix it though I need to reproduce the problem somehow.
  2. baldurk

    RenderDoc and D2D/DirectWrite

    For bugs in the program itself it's better to file them on the renderdoc github rather than posting here - I only saw this topic by chance because a twitter bot posted it. As it happens I fixed a bug recently since v1.0 was released related to D2D, so you could try a recent nightly build and see if it works now.
  3. I'm genuinely sorry about this, looking at it now I can see how it reads and that's entirely my fault. It's definitely not the attitude I want to convey. To explain (but not excuse), this was specifically a response to that person's question, who had both contacted me directly and opened a lot of other bugs all asking for help with a) an unofficial years-old fork of renderdoc's source with many code changes which I could not support, and b) capturing a commercial game (GTA 5) which I also do not support/condone. After trying to explain that I could not help with this several times I got frustrated and snapped. It's not OK and I want to do better, but I hope you can understand that I didn't mean that everyone should investigate their own problems with the tool. To be clear (and I'll edit my response there in case someone else comes across it), please don't be worried about reporting bugs on RenderDoc if you're having trouble with the program. Even if it's just a misunderstanding or something I'm happy to help. I'm just not able to help with someone else's code loosely based on mine, or if you're having trouble capturing a commercial product that may have copy protection or something else causing the problem. Again, I am really sorry for this response, it was unacceptable even when made in frustration. So my understanding is that I can just use the UI, capture a log by setting up the path to my .exe, and launch the application. Yes you understand correctly. That page is talking about specifically using RenderDoc's API which allows you some control over when captures happen, and things like that. In this context the passive integration is talking about just trying to use the API if it's available, but doing nothing if it's missing. That way the API is used when your program is launched through the UI, and does nothing otherwise. If you don't want or need to make any code changes you don't need to worry about any kind of integration, you just need to launch your exe through the renderdoc UI. If it says "no API detected" while you're presenting to a swapchain then the most likely case is that some of the hooking is going wrong, either the swapchain or the D3D device is not being intercepted. To diagnose it further I'd need more information. I found your project on github, is this the one that's having trouble? I tried to run it but I can't right now as it doesn't work on windows 7, but I can try it later today on a windows 10 computer to investigate. If you can send me the log from help -> view diagnostic log that would be helpful.
  4. This is a very specific to RenderDoc question, so I think the best thing to do is file an issue on github with more information about what you're trying to do (I'm not entirely sure what you mean by passive integration) and I can help you there.
  5. 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.
  6. 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.
  7. 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.
  8. 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:.
  9.   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.
  10. 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?
  11. baldurk

    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.
  12. baldurk

    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 :).
  13. baldurk

    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.
  14. baldurk

    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.
  15. 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.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!