mirror of
https://github.com/baldurk/renderdoc.git
synced 2026-05-04 17:10:47 +00:00
baldurk
c38affcded
* All renderdoc code up to this point was written by me, history is available by request
119 lines
5.8 KiB
XML
119 lines
5.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 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. The only requirement is the DirectX runtime to ensure D3DCompiler.dll
|
|
is available.</para>
|
|
<para>Currently RenderDoc also requires feature level 11+ hardware for the replay app, although
|
|
it can capture lower level applications.</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>In the mesh viewer the Solid Shading option will only apply to the vertex input tab.
|
|
(or to the vertex output tab when tessellating).
|
|
</para>
|
|
<para>Similarly the options to draw "only this draw" or "since last clear" only work for the
|
|
vertex output/geometry output tabs.
|
|
</para>
|
|
|
|
<alert class="caution">
|
|
<para>The "since last clear" option is likely to be slow when there are a lot of vertices being drawn. Use with care!</para>
|
|
</alert>
|
|
|
|
</listItem>
|
|
<listItem>
|
|
<para>There is no pixel history at present. When pixel debugging you must select the
|
|
exact drawcall that you are interested in debugging.
|
|
</para>
|
|
</listItem>
|
|
<listItem>
|
|
<para>If a debugged pixel is overdrawn multiple times by the same drawcall RenderDoc will attempt
|
|
to pick the pixel that last passed the depth test, but this may not necessarily be entirely
|
|
accurate and in the case of blending there's no way currently to pick other pixels that passed
|
|
the depth test.
|
|
</para>
|
|
</listItem>
|
|
<listItem>
|
|
<para>The instruction set for shader debugging is not complete, and some instructions may be
|
|
unimplemented leading to incorrect results when debugging.
|
|
</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>
|
|
</list>
|
|
</para>
|
|
</content>
|
|
</section>
|
|
</developerConceptualDocument>
|
|
</topic>
|