mirror of
https://github.com/baldurk/renderdoc.git
synced 2026-05-04 17:10:47 +00:00
baldurk
94 lines
4.8 KiB
XML
94 lines
4.8 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
|
<topic id="a56958b2-bf9e-411a-8354-56284e713f09" revisionNumber="1">
|
|
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
|
|
<introduction>
|
|
<para>
|
|
<autoOutline />
|
|
This page (hopefully) keeps up to date with any known issues, bugs, unimplemented
|
|
or partially unimplemented features.
|
|
</para>
|
|
</introduction>
|
|
<section address="Notes">
|
|
<title>Things to Note</title>
|
|
<content>
|
|
<para>
|
|
<list class="bullet">
|
|
<listItem>
|
|
<para>RenderDoc doesn't serialise out the initial contents of large graphics resources when it believes
|
|
that they will not be used in replay. e.g. a G-Buffer render target will not be saved out as it
|
|
is initialised and written to in-frame. This detection will go wrong if a render target is partially
|
|
written to but partially re-used, as RenderDoc will count this as initialised in-frame. This could
|
|
happen e.g. with an accumulating texture that is written to in the frame over the top of previous
|
|
results.
|
|
</para>
|
|
<para>You can override this behaviour by selecting 'Save All Initials' in the <link xlink:href="0dd6fe0d-4130-46f4-b2ea-9565de13111d">capture options</link> before
|
|
capturing, as this will force RenderDoc to serialise out all initial contents regardless, at the cost
|
|
of larger logfiles and slightly slower replay app analysis.
|
|
</para>
|
|
</listItem>
|
|
<listItem>
|
|
<para>When capturing, only one swapchain is captured at any given time.
|
|
The in-app overlay renders to all swapchains but only one is considered "active" at
|
|
any given time - this can be cycled with the F11 key. The capture key will trigger
|
|
a capture at the next swap of the currently active swapchain.</para>
|
|
</listItem>
|
|
<listItem>
|
|
<para>RenderDoc relies on saving out the graphics command stream and replaying it
|
|
back at inspection time. This means if a bug is timing, machine or driver specific it is
|
|
in no way guaranteed to reproduce the bug on a different machine or driver.</para>
|
|
<para>RenderDoc has no runtime dependencies on Visual Studio or the DirectX or Windows SDK,
|
|
and should run anywhere that a normal DirectX application will run - i.e. on
|
|
Artist or QA machines.</para>
|
|
<para>Currently RenderDoc also assumes feature level 11+ hardware for the replay app. It can
|
|
capture applications running at a lower feature level, but when replaying if 11+ hardware
|
|
isn't available, RenderDoc will fall back to WARP software emulation and will run slowly.</para>
|
|
</listItem>
|
|
<listItem>
|
|
<para>If capturing callstacks from the app, ensure that dbghelp.dll is not loaded or
|
|
used by the application as this can easily interfere with RenderDoc's use and cause
|
|
undefined or empty results. More information on this can be found in
|
|
<link xlink:href="14048aef-0053-4e38-98cd-541f4d15d12e" />.
|
|
</para>
|
|
</listItem>
|
|
<listItem>
|
|
<para>RenderDoc can have a significant memory overhead, especially when a lot of resources are allocated
|
|
as shadow copies in main memory are created.
|
|
</para>
|
|
<para>If running in 32bit, it's possible that an application can run out of memory - particularly when
|
|
capturing, as this causes a significant spike in memory use. Improvements in memory management are planned
|
|
but for now it's recommended to use 64bit, or to limit captures to simple scenes wherever possible.
|
|
</para>
|
|
</listItem>
|
|
</list>
|
|
</para>
|
|
</content>
|
|
</section>
|
|
<section address="PartialImpl">
|
|
<title>Partially Implemented Features</title>
|
|
<content>
|
|
<para>
|
|
<list class="bullet">
|
|
<listItem>
|
|
<para>Deferred context & command list support will probably run into problems with non-trivial
|
|
use-cases. Let me know if you find a use-case that breaks, as I don't have many test programs!
|
|
</para>
|
|
</listItem>
|
|
<listItem>
|
|
<para>The API Inspector shows essentially the raw serialised form of the commands in the log
|
|
file and so is not always very useful beyond showing which functions were called. There isn't
|
|
a way yet to see what views a particular ID corresponds to, and some of the parameters are
|
|
a little different from their official function signature.
|
|
</para>
|
|
</listItem>
|
|
<listItem>
|
|
<para>There are several such notes for OpenGL, which are noted on <link xlink:href="11ea4311-b9ea-450a-8c80-b510ffc8b1a6">its own page</link>,
|
|
as well as for Vulkan on <link xlink:href="b08af848-7c58-4ff4-9a2a-6bb5cfb0b037">its own page</link>.
|
|
</para>
|
|
</listItem>
|
|
</list>
|
|
</para>
|
|
</content>
|
|
</section>
|
|
</developerConceptualDocument>
|
|
</topic>
|