lee/renderdoc
1
0
Fork 0
mirror of https://github.com/baldurk/renderdoc.git synced 2026-05-05 01:20:42 +00:00
Code Issues Packages Projects Releases Wiki Activity

Initial commit of existing code.

Browse Source 
* All renderdoc code up to this point was written by me, history is available by request
This commit is contained in:
baldurk
2014-05-02 08:14:55 +01:00
parent 04b1549c0f
commit c38affcded
695 changed files with 230316 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/Credits.aml
+135
View File
@@ -0,0 +1,135 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="ddeda389-3bd8-460d-b420-20e563003da4" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<para>RenderDoc wouldn't have been possible without both the tools and libraries that were
used in its construction, as well as the many people who helped and contributed to make it
the program it is today.</para>
</introduction>
<section address="Credits">
<title>3rd Party Credits</title>
<content>
<para>The following libraries and components are incorporated into RenderDoc, listed here in
no particular order. Thanks go out to the developers and contributors behind each of these
libraries who generously donated their work to other free projects!</para>
<list class="bullet">
<listItem><para>
<externalLink>
<linkText>mhook</linkText>
<linkAlternateText>mhook DLL hooking library, used to inject RenderDoc into applications.</linkAlternateText>
<linkUri>http://codefromthe70s.org/mhook23.aspx</linkUri>
</externalLink>
</para></listItem>
<listItem><para>
<externalLink>
<linkText>TreeView with Columns</linkText>
<linkAlternateText>TreeView with Columns, an invaluable control filling a much needed niche in .NET winforms.</linkAlternateText>
<linkUri>http://www.codeproject.com/Articles/23746/TreeView-with-Columns</linkUri>
</externalLink>
</para></listItem>
<listItem><para>
<externalLink>
<linkText>Dock Panel Suite</linkText>
<linkAlternateText>Dock Panel Suite, a mature and stable library that adds the docking and flexibility of RenderDoc's UI.</linkAlternateText>
<linkUri>http://dockpanelsuite.com/</linkUri>
</externalLink>
</para></listItem>
<listItem><para>
<externalLink>
<linkText>famfamfam Silk Icon set</linkText>
<linkAlternateText>Lending an air of professionalism and artistic quality to the UI, the Silk icon set is used throughout RenderDoc.</linkAlternateText>
<linkUri>http://www.famfamfam.com/lab/icons/silk/</linkUri>
</externalLink>
</para></listItem>
<listItem><para>
<externalLink>
<linkText>ScintillaNET</linkText>
<linkAlternateText>ScintillaNET and by extension Scintilla provide a powerful text editor for the shader viewers.</linkAlternateText>
<linkUri>http://scintillanet.codeplex.com/</linkUri>
</externalLink>
</para></listItem>
<listItem><para>
<externalLink>
<linkText>Google Breakpad</linkText>
<linkAlternateText>Google Breakpad provides a rock-solid crash handling and reporting base that help keep RenderDoc stable.</linkAlternateText>
<linkUri>https://code.google.com/p/google-breakpad/</linkUri>
</externalLink>
</para></listItem>
<listItem><para>
<externalLink>
<linkText>miniz</linkText>
<linkAlternateText>miniz public domain zip library is used to compress the crash reports for sending.</linkAlternateText>
<linkUri>https://code.google.com/p/miniz/</linkUri>
</externalLink>
</para></listItem>
<listItem><para>
<externalLink>
<linkText>ILM's half implementation</linkText>
<linkAlternateText>Used for decoding half data for display.</linkAlternateText>
<linkUri>https://github.com/openexr/openexr/tree/master/IlmBase/Half</linkUri>
</externalLink>
</para></listItem>
<listItem><para>
<externalLink>
<linkText>jpeg-compressor</linkText>
<linkAlternateText>Used to compress screenshots into jpg format for thumbnail previews.</linkAlternateText>
<linkUri>https://code.google.com/p/jpeg-compressor/</linkUri>
</externalLink>
</para></listItem>
<listItem><para>
<externalLink>
<linkText>lz4</linkText>
<linkAlternateText>lz4 compresses large data transfers (textures and buffers) when going across network connections.</linkAlternateText>
<linkUri>https://code.google.com/p/lz4/</linkUri>
</externalLink>
</para></listItem>
<listItem><para>
<externalLink>
<linkText>Sandcastle Help File Builder</linkText>
<linkAlternateText>Sandcastle Help File Builder for creating this documentation that you're reading!</linkAlternateText>
<linkUri>http://shfb.codeplex.com/</linkUri>
</externalLink>
</para></listItem>
</list>
</content>
</section>
<section address="Thanks">
<title>Thanks</title>
<content>
<para>There have been many people who have helped in the creation of RenderDoc. Whether
testing, feedback or contributing artwork and design critique everyone listed here and
many more besides have been invaluable in taking RenderDoc from an idea on paper to its
current state. Greets fly out to the following people, listed in no particular order.</para>
<list class="bullet">
<listItem><para>Chris Bunner, Charlie Cole, James Chilvers, Andrew Khan, Benjamin Hill, Jake Turner, Alex Weighell and the rest
of the Crytek UK R&amp;D team.</para></listItem>
<listItem><para>Colin Bonstead, Marco Corbetta, Pascal Eggert, Marcel Hatam, Sascha Hoba, Theodor Mader, Mathieu Pinard, Chris Raine, Nicolas Schulz, Tiago Sousa, Sean Tracy, Carsten Wenzel,
and everyone else at the rest of the Crytek Studios.</para></listItem>
<listItem><para>Daniel Sexton</para></listItem>
<listItem><para>Jason Mendel</para></listItem>
<listItem><para>Jacob Kapostins</para></listItem>
<listItem><para>Iain Cantlay</para></listItem>
<listItem><para>Luke Lambert</para></listItem>
<listItem><para>Gareth Thomas</para></listItem>
<listItem><para>George Ilenei</para></listItem>
</list>
</content>
</section>
</developerConceptualDocument>
</topic>
docs/FAQ.aml
+224
View File
@@ -0,0 +1,224 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="b97b19f8-2b97-4dca-8a7a-ed7026eb43fe" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<autoOutline />
<para>
Here is a list of commonly asked questions about RenderDoc.
Feel free to contact me if you have another question that isn't covered here
or in this document.
</para>
</introduction>
<section address="FAQ1">
<title>How do I do some particular task?</title>
<content>
<para>
Many specific tasks or functions are detailed in the "How Do I... ?" sections.
These sections each take a feature or element of a workflow and explain how it
fits into the program as a whole as well as any details of how it works.
</para>
<para>
If the task you have in mind isn't listed there you might find something similar,
or you might find a related feature which can be used to do what you want. If
the feature you want doesn't seem to exist at all you might want to check the
<link xlink:href="632271c3-3d72-4360-b4a0-dc570fcd541e" />
to see if it's coming soon - if it's not on that list please feel free to contact
me and request it! <token>Baldur Contact</token>. It has often been that simple features
are very quick to implement and the prioritisation and scheduling of features is fairly
fluid at this stage in development.
</para>
</content>
</section>
<section address="FAQ2">
<title>Why did you make RenderDoc?</title>
<content>
<para>
Although several tools do already exist for graphics debugging, none of them quite
suited the functionality I desired and I would often find myself wishing for a feature of
one in another and vice versa.
</para>
<para>
In addition to this, although the functionality overlaps to some degree many of these
tools were primarily designed around the profiling of applications rather than debugging.
While being able to inspect the state and contents of resources does often suffice for
debugging, it's not necessarily the ideal workflow and often it can become cumbersome.
</para>
<para>
In principle I didn't see any reason why I couldn't write a home-brew graphics debugger
with some fairly simple operating principles. While there were a whole lot of caveats
and little stumbling blocks along the way, the original design has pretty much stayed
consistent since the project was started back in July 2012. If you're interested you might
want to read about <link xlink:href="f351fea6-d0ac-426b-9631-feec2408a7e2" />.
</para>
</content>
</section>
<section address="FAQ3">
<title>Where did the name come from?</title>
<content>
<para>
All of the good names were taken :-(.
</para>
</content>
</section>
<section address="FAQ4">
<title>Who can I contact about bugs, feature requests, other queries?</title>
<content>
<para>
At the moment there's just me at the wheel - feel free to contact me at
<token>Baldur Contact</token> if you have anything you'd like to ask or suggest.
I use a <externalLink>
<linkText>github repository</linkText>
<linkAlternateText>Issues on github</linkAlternateText>
<linkUri>https://github.com/baldurk/renderdoc/issues</linkUri>
</externalLink> for tracking bugs and feature requests so that's the best place to
file an issue.
</para>
<para>
I work on RenderDoc in my spare time but I will do my best to get back to you and
work with you if you have any issues that need attention. If you
have a question or something to discuss you can also post on the <externalLink>
<linkText>forums</linkText>
<linkAlternateText>Forums on CryDev.net</linkAlternateText>
<linkUri>http://www.crydev.net/viewforum.php?f=379</linkUri>
</externalLink>.
</para>
</content>
</section>
<section address="FAQ5">
<title>How can I associate RenderDoc's file extensions with the program?</title>
<content>
<para>
If you installed RenderDoc via the installer package rather than the zip folder, the option
is available there to associate RenderDoc's file extensions with the program. Otherwise you
can set them up from the <link xlink:href="B1826EEE-2ED1-44E4-8202-37CD8B3FEEB5" />.
</para>
<alert class="note">
<para>RenderDoc will elevate itself to set up these file associations, but otherwise will not hold
on to administrator permissions.</para>
</alert>
<para>
RenderDoc associates .rdc and .cap with itself when desired. The .rdc files are the logfiles
output when you capture inside an application. .cap files describe the set up of a
particular capture, and can be used to quickly re-launch a capture preset.
</para>
<para>
If .rdc files are associated with RenderDoc a thumbnail handler is set up, so that in explorer
you'll get thumbnail previews for your captures.
</para>
<alert class="caution">
<para>
Note that if you move the directory that RenderDoc is you will need to re-configure the
file associations as the registry entries contain absolute paths.
</para>
</alert>
</content>
</section>
<section address="FAQ6">
<title>What APIs does RenderDoc support?</title>
<content>
<para>
Currently RenderDoc only supports D3D11 (including the D3D11.1 extensions where available).
</para>
<para>
In future API support is planned for at least OpenGL and D3D9 as soon as time and scheduling
allows - OpenGL support is under development. Support for Mantle would be nice but I can't
promise it just yet until the API is
public.
</para>
<para>Other APIs could be supported once the source is open as I've tried to structure
things such that different back-ends can be slotted in without significant code changes.
</para>
</content>
</section>
<section address="FAQ7">
<title>How can I backup or restore my settings?</title>
<content>
<para>
Everything RenderDoc relies upon is stored in %APPDATA%\RenderDoc. You can back up and restore
this directory at will as nothing stored in there is machine specific aside from things like
recent file lists.
</para>
<para>
Deleting this folder will also reset RenderDoc to the defaults - if you uninstall RenderDoc this
folder will <legacyItalic>not</legacyItalic> be deleted.
</para>
<para>RenderDoc doesn't install any registry keys aside from those to set up file associations.
</para>
</content>
</section>
<section address="FAQ8">
<title>Which network ports does RenderDoc use?</title>
<content>
<para>
RenderDoc uses TCP and UDP ports 38920-38927 consecutively for remote access and control (ie.
capturing remotely) for each new program that is opened on a machine. Note that even if you
initiate a capture locally these ports are still opened for listening. These are the ports
that are probed on a remote host to see if a connection exists.
</para>
<para>
RenderDoc also uses TCP and UDP ports 39920 for remote replay connections, for when a remote
host is used to replay and analyse the log.
</para>
</content>
</section>
<section address="FAQ9">
<title>When will RenderDoc be open-sourced?</title>
<content>
<para>
RenderDoc is licensed under the MIT license so that it can very naturally be open-sourced at
a later date.
</para>
<para>
Currently the precise timescale is not defined, but if you'd like more information you can
always get in contact to find out how things are looking. In general the source will be
opened up once the codebase has stabilised and is more feature complete. Currently it's
not in final shape and still changing a lot on a day-to-day basis so it isn't really in a
condition where patches could practically be accepted.
</para>
</content>
</section>
<section address="FAQ10">
<title>What are the requirements for RenderDoc?</title>
<content>
<para>
Currently RenderDoc only supports Feature Level 11.0 and above for D3D11. Lower levels
may capture successfully but if uou can't create a FL11.0 device they will not replay.
</para>
</content>
</section>
<section address="FAQ10">
<title>Why does my capture say "Failed to capture frame: Uncapped command list"?</title>
<content>
<para>
At the moment RenderDoc only begins capturing deferred command lists at the point that you
trigger a capture. If you replay command lists from before this, RenderDoc will fail to capture
the frame and try again next frame (and eventually give up after a few retries).
</para>
<para>
To change this behaviour, enable the <link xlink:href="D1612D25-C8BA-4349-9CE2-1E57D60F98C5">Capture
all cmd lists</link> option - see that page for more details. This will capture all command lists
from the start of the program, ready for when you decide to capture a frame. This currently has a
fair overhead but it's something I want to improve in future
</para>
</content>
</section>
<section address="FAQ11">
<title>Why does my capture say "Failed to capture frame: Uncapped Map()/Unmap()"?</title>
<content>
<para>
If you start a Map() before a Present() call then call Unmap() after the Present() during the frame
RenderDoc wants to capture, RenderDoc won't have intercepted this call and so will fail to capture
this frame and try again next time. This usually only invalidates the first frame you try to capture,
but if you Map() many resources, and Unmap() them one by one in subsequent frames, you could hit this
failed capture scenario many times in a row.
</para>
<para>
Currently the only solution to this is to change the pattern of Map()/Unmap() such that they are
contained within a frame.
</para>
</content>
</section>
</developerConceptualDocument>
</topic>
docs/Features.aml
+88
View File
@@ -0,0 +1,88 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="86b8bce7-b7cd-4b10-aa61-706463d14fe0" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<para>
This page documents the current feature set of RenderDoc. This gives an overview of
what RenderDoc is capable of, and where it is in its development. You might also
be interested in the <link xlink:href="632271c3-3d72-4360-b4a0-dc570fcd541e" />.
</para>
<para>
Currently RenderDoc is limited to Windows and D3D11 only. The plan is to increase this scope
as soon as possible, to include OpenGL and D3D9 and possibly other platforms.
</para>
</introduction>
<section address="Features">
<title>Current Windows+D3D11 Feature set</title>
<content>
<para>
<list class="bullet">
<listItem><para>Support for D3D11 and D3D11.1, Windows Vista and above.</para></listItem>
<listItem><para>Trimming capture - capture file only contains data necessary
for replaying the frame in question, not all textures &amp; buffers ever created
in the lifetime of the app.</para></listItem>
<listItem><para>Optional network support. The main use case is capture &amp; replay on
the same machine, but you can also attach over the network, and replay on a remote host.</para></listItem>
<listItem><para>Multiple frame capture with ability to open side-by-side to compare.</para></listItem>
<listItem><para>Event browsing, with standard perfmarker style tree.</para></listItem>
<listItem><para>Full D3D11 Pipeline display.</para>
<list class="bullet">
<listItem><para>Resources bound to the pipeline are trimmed to what is actually in use,
e.g. if a shader only references SRV slot 0, only SRV slot 0 will be displayed, even if
something is bound to slot 1.</para></listItem>
<listItem><para>Where available D3D11 debug names are displayed, along with reflection
data with the shader to clarify usage.</para></listItem>
<listItem><para>Structured buffers have their total element count displayed, and UAVs
also show the current structure count.</para></listItem>
</list>
</listItem>
<listItem><para>Shader source display (where possible - i.e. debug info available).</para></listItem>
<listItem><para>Timeline bar of the scene hierarchy.</para>
<list class="bullet">
<listItem><para>Displays scene left-to-right in time, event hierarchy top-to-bottom.</para></listItem>
<listItem><para><legacyItalic>Not</legacyItalic> scaled based on time of each drawcall</para></listItem>
<listItem><para>Individual draw events are shown as dots when the tree is full expanded.</para></listItem>
<listItem><para>The currently selected resource in the texture viewer is highlighted below
individual drawcalls visible that use it - e.g. purple for 'used for write', green for 'used for read'</para></listItem>
</list>
</listItem>
<listItem><para>For each drawcall, a list of all API calls (state/resource setting) is available, with
each call optionally having a complete callstack to locate where it came from in-app.</para></listItem>
<listItem><para>Mesh buffer inspection and visualisation before/after vertex shader and at the end of the geometry
pipeline (after GS or DS, whichever is later). All views have arcball
and flycam controls, Projected data is not limited to the 2D viewport, RenderDoc attempts to unproject to allow viewing in
world-space.</para></listItem>
<listItem><para>'Raw' buffer inspection, e.g. for UAVs, VBs or other buffers. Custom format can be set with
HLSL-lite syntax.</para></listItem>
<listItem><para>Buffer export to CSV or raw binary blob and texture saving to DDS.</para></listItem>
<listItem><para>Texture/render target viewer.</para>
<list class="bullet">
<listItem><para>List of textures/RTs in the frame, and filtering system.</para></listItem>
<listItem><para>Standard visualisation controls - zoom/fit to window, mip/face/slice selection.</para></listItem>
<listItem><para>RGBA channels or depth/stencil selection as appropriate for the type of resource.</para></listItem>
<listItem><para>Flexible 'range' selection tool, to set custom black/white points (default to 0 and 1).</para></listItem>
<listItem><para>Currently set RT/textures thumbnail strip - updates as you move through the frame. Follows the
currently selected pipeline slot as it changes, rather than remaining on the given texture.</para></listItem>
<listItem><para>Tabbed view for locking a view of a particular resource over time.</para></listItem>
<listItem><para>Pixel value picking.</para></listItem>
<listItem><para>Several debug overlays for render targets - Wireframe, Depth pass/fail, Stencil pass/fail,
Clipping (below black/above white points), NaN/-ve/INF highlight.</para></listItem>
</list>
</listItem>
<listItem><para>Custom visualisation shader support - e.g. decode custom packed formats or gbuffers.</para></listItem>
<listItem><para>Vertex, Pixel and Compute shader debugging.</para></listItem>
<listItem><para>Hot shader editing and replacement.</para></listItem>
<listItem><para>Auto-range fitting to min/max values in texture data, and histogram display.</para></listItem>
<listItem><para>Simple per-drawcall timings.</para></listItem>
</list>
</para>
<para>
Most of these should be intuitive if you've used a graphics debugger before.
</para>
</content>
</section>
<relatedTopics>
<link xlink:href="632271c3-3d72-4360-b4a0-dc570fcd541e" />
</relatedTopics>
</developerConceptualDocument>
</topic>
docs/Gotchas.aml
+118
View File
@@ -0,0 +1,118 @@
<?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 &amp; 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>
docs/HowRenderDocWorks.aml
+104
View File
@@ -0,0 +1,104 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="f351fea6-d0ac-426b-9631-feec2408a7e2" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<para>RenderDoc works on very simple operating principles. This page outlines the basic
idea behind its functioning to give people a better idea of what's going on.</para>
</introduction>
<section address="Capture">
<title>Capturing Logs</title>
<content>
<para>Leaving aside the relatively uninteresting matter of injecting the RenderDoc DLL
and calling functions to configure it in the target process, we begin by looking at
how RenderDoc captures a logfile.</para>
<para>We will use D3D11 as an example of a driver for RenderDoc - the driver layer is
responsible both for faithfully capturing the logfile's API usage, as well as then
replaying and analysing it later. Essentially anything built on top of a driver layer
can be used agnostically of the API the application in question is using.</para>
<para>When the driver initialises it will hook into every entry point into the API
such that when application uses the API it passes through the driver wrapper.
In the case of D3D11 this is the D3D11CreateDevice and CreateDXGIFactory functions.</para>
<para>After this point all accesses to the API remain wrapped and the driver essentially
"man-in-the-middle"s between the application and the real API.</para>
<para>The driver initialises in an idle logging state. In this state it's up to the specific
implementation about what it serialises. As a general rule, creation and deletion type actions
are always serialised, and data-upload calls can sometimes be serialised. In some cases
the driver might choose to optimise out some of the data-upload calls and lazy initialise
the contents of some resources to save on idle overhead.</para>
<para>This serialised data is stored in-memory in a chunk-based representation.
Although it's up to the driver implementation it is generally refcounted such that
resources which end up becoming unbound and destroyed will have their memory overhead
deleted.</para>
<para>When the capture button is hit the driver will enter active logging upon the beginning
of the next frame. In this state every API call is serialised out in order and any initial
contents and states are saved.</para>
<para>Once the frame completes this frame capture is serialised to disk along with the in-memory
data for any resources that are referenced - by default resources which are not referenced are
not included in the log.</para>
</content>
</section>
<section address="Replay">
<title>Replaying &amp; Analysing Logs</title>
<content>
<para>The replay process is ostensibly simple, but as with the capturing the devil is in the
details.</para>
<para>When replaying, the initial section of the log (up to the beginning of the frame) is read
and executed verbatim. Each resource created is mapped to the live version and vice versa so
later parts of the log can obtain the replayed representation of the original resource.</para>
<para>RenderDoc then does an initial pass over the captured frame. This allows us to build up a
list of all the 'drawcall' events, analyse dependencies and check which resources are used
at each drawcall for read, write, and so on. An internal tree is built up similar to what you
see in the Event Browser &amp; API Viewer, as well as a linked list with the linear sequence
of drawcalls, since both representations are useful for iterating over the frame.</para>
<para>After this point most work is done in response to user actions. The basic building block
is replaying a partial frame. Most analysis tools are built out of either replaying up to the
current event, replaying up to the event - not including the current drawcall - and replaying
<legacyItalic>only</legacyItalic> the current drawcall.</para>
<para>Care is taken to minimise this as much as possible as this tends to be the slowest operation
given the overheads of serialisation and decoding the command stream.</para>
<para>When replaying from the beginning of a frame (and not a partial subset of the frame) the
initial states of all resources are applied, and the initial pipeline state is restored. Resources
which did not have a serialised initial state (e.g. gbuffer textures) have an initial state saved
before the first replay of the frame, and this is restored. That way you don't get effects 'leaking'
from later in a frame into an earlier point.</para>
<para>For example, let's assume the user has the 'depth test' overlay enabled, and selects a
new event. This is the order of events that occur for the Texture Viewer - other viewers follow
similar patterns, with a certain degree of sharing to reduce redundant replays:</para>
<list class="ordered">
<listItem>
<para>The log is replayed up to, but not including, the selected drawcall. After doing this
the current pipeline state and contents of all resources exactly match the state at the point
of this drawcall.</para>
</listItem>
<listItem>
<para>We then save a copy of the pristine depth buffer, save the current pipeline state, and
set the reversed depth test. Replacing the pixel shader with one that just writes red, we repeat
the drawcall to draw all the areas that fail the depth test.</para>
</listItem>
<listItem>
<para>Restoring the depth buffer and
repeating this with a pixel shader which writes green, we fill in the overlay. Both of these
renders happen to an off-screen buffer.</para>
</listItem>
<listItem>
<para>After restoring the pipeline state we finally replay the original drawcall to get the final
image.</para>
</listItem>
<listItem>
<para>When we want to re-paint the viewed texture (either regular painting, or if the user changed
a visualisation option which is just a constant buffer value) we bind the current render target as
a resource and render it to the texture viewer control, then render the overlay texture on top of
that.</para>
</listItem>
</list>
<para>It's also worth mentioning that there is a bit of special handling for deferred contexts.
When you select an event in a command list, RenderDoc will replay as normal up to just before the
Execute() call, then it will replay all of the commands in the command list up to the currently
selected event on the immediate context.</para>
</content>
</section>
</developerConceptualDocument>
</topic>
docs/HowTo/HowToCallstacks.aml
+80
View File
@@ -0,0 +1,80 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="14048aef-0053-4e38-98cd-541f4d15d12e" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<para>This page gives an overview of the callstack-capturing capability in RenderDoc,
with details and important information about how to enable this.</para>
</introduction>
<section address="Overview">
<title>Overview</title>
<content>
<para>It can be useful when tracking down problems to have an idea of where each
API call came from. In any non-trivial program it's not necessarily obvious where
every single call was made, and giving a code-side callstack up to the API entry
point can pinpoint errant calls that are causing problems.</para>
<alert class="caution">
<para>The callstack gathering uses dbghelp.dll. If you're using this
dll for some other debugging functionality in your app it is highly recommended that
you disable it, otherwise it can conflict and break RenderDoc's callstack capture.</para>
</alert>
<alert class="note">
<para>Callstack gathering has a reasonable overhead during capture and can slow things
down as well as cause more memory overhead. This can be mitigated with the 'only drawcall
callstacks' option that only lists callstacks for each drawcall event.</para>
</alert>
</content>
</section>
<section address="Capture">
<title>Launching Capture</title>
<content>
<para>When launching a capture (as in <link xlink:href="0dd6fe0d-4130-46f4-b2ea-9565de13111d" />)
you should enable 'collect callstacks'. This will set RenderDoc to collect callstacks at every
API entry point that will be serialised into the log.</para>
<mediaLink>
<caption placement="after" lead="Collect Callstacks">Option enabled on the capture dialog.</caption>
<image xlink:href="Callstacks"/>
</mediaLink>
<para>If you wish to save some time &amp; overhead you can then enable 'Only drawcall stacks'.
This will only collect callstacks when a drawcall-type API call is made. This can be a good-enough
trade off that still gets you the information you need, at a lower cost. After this point you can
run the program and capture as usual.</para>
</content>
</section>
<section address="Replay">
<title>Replaying the capture</title>
<content>
<para>When the capture is loaded in RenderDoc the callstacks will be available in the API
inspector. The bottom section of the dialog is a panel that can be expanded to show the
callstack. Initially this section will indicate that symbols need to be resolved.</para>
<mediaLink>
<caption placement="after" lead="Callstack section">The callstack section expanded in API inspector.</caption>
<image xlink:href="NeedResolve"/>
</mediaLink>
<para>To resolve the symbols referenced in the capture, go to the <ui>Tools</ui> menu and
select <action>Resolve Symbols</action>. If this menu option isn't available the callstacks
did not successfully capture in the logfile.</para>
<para>The resolving symbols process may take some time the first few instances you use it,
as it may have to download symbols from the Microsoft symbol server. Each module that is loaded
in the application at the time of capture will be saved and its symbols searched for.</para>
<para>By default a symbol server will be used, as well as a few default locations such as the
location indicated in the PE metadata (i.e. the original build location). If a pdb cannot be found
you will be prompted for the location of the pdb, and this new location will then be remembered
for subsequent pdbs.</para>
<mediaLink>
<caption placement="after" lead="PDB locate prompt">Prompt to locate a PDB that cannot be found.</caption>
<image xlink:href="NeedPDB"/>
</mediaLink>
<para>If a PDB cannot be located then you have the option of permanently ignoring that PDB.
This can be useful for third party libraries for which no PDB will ever be available. If
you don't ignore the PDB you will be prompted to locate it the next time you open a log
that references it.</para>
<para>Once the symbols have been successfully resolved the callstack section of the API
inspector will contain any callstack that was collected for the given drawcall or API
call. You can select and copy any levels and paste them elsewhere if you wish.</para>
</content>
</section>
</developerConceptualDocument>
</topic>
docs/HowTo/HowToCaptureLog.aml
+88
View File
@@ -0,0 +1,88 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="0dd6fe0d-4130-46f4-b2ea-9565de13111d" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<para>Capturing logfiles is the starting point to using RenderDoc. Although the
basic use is very simple, there are various customisations and more advanced uses.
More information on these can be found in the details of the
<link xlink:href="D1612D25-C8BA-4349-9CE2-1E57D60F98C5" /> window.</para>
</introduction>
<section address="capturing">
<title>Capturing logs</title>
<content>
<para>The basic process of capturing logs is fairly straightforward.</para>
<para>Opening the capture window from the menus via File -&gt; Capture Log, the
typical capture setup simply requires you to enter the executable location.</para>
<para>By default the working directory remains empty and defaults to the directory
that contains the executable location.</para>
<mediaLink>
<caption placement="after" lead="Capturing">Capturing a logfile specifying its executable path and command line.</caption>
<image xlink:href="CapturePathCmdline"/>
</mediaLink>
<para>Likewise, the default options generally work well for most situations, however
there are a few common options to customise:</para>
<list class="bullet">
<listItem><para>Allow Fullscreen/Allow VSync aid in debugging by preventing the app from switching
into fullscreen (or vsynced) display modes, which makes them easier to attach to from a debugger
on the same computer.</para></listItem>
<listItem><para>Seconds attach delay causes RenderDoc to pause for a certain number of seconds after
launching the process to allow you to attach in the debugger - so that the debugger can be present
to catch any problems from the beginning of the application, in case there is an issue very early
in initialisation.</para></listItem>
<listItem><para>Collect callstacks allows you to get callstacks at the site of each API. There are
more details available in <link xlink:href="14048aef-0053-4e38-98cd-541f4d15d12e" />.</para></listItem>
</list>
</content>
</section>
<section address="attaching">
<title>Attaching to a Process</title>
<content>
<para>It is possible to attach to an already running process. By selecting the "Attach to Process"
entry in the File menu, the capture dialog will modify to list the running processes rather than
asking for an executable and command line parameters.</para>
<para>This can be useful if launching your application from a single exe is non-trivial and it's
easier to attach to the process after it has been launched.</para>
<mediaLink>
<caption placement="after" lead="Attaching">Attaching to a selected existing process.</caption>
<image xlink:href="Attaching"/>
</mediaLink>
<alert class="caution">
<para>The important thing to note about attaching is that RenderDoc can only attach to processes that
<legacyBold>have not initialised or used the target API</legacyBold>. If this is the case RenderDoc can
insert its hooks before any use of the API and work as normal. If the API has been used or initialised
the results are undefined and likely RenderDoc will simply not function as it's too late to hook in.</para>
</alert>
<alert class="note">
<para>If RenderDoc is not running as administrator, it cannot attach to processes that are running with
elevated permissions. In this case you can either run RenderDoc as administrator (not recommended unless
necessary), or re-run the process as the normal user running RenderDoc.</para>
</alert>
</content>
</section>
<section address="capfiles">
<title>Capture setting files</title>
<content>
<para>Commonly in development, the capture parameters don't change. In fact most likely the
same application or couple of applications are launched in exactly the same way repeatedly
as development iterates.</para>
<para>To make this process easier RenderDoc supports saving and loading configuration sets to a
file. While on the capture dialog, click 'Save' to save to a .cap file which contains both the
executable, working directory and command line - as well as the options that are selected.</para>
<para>This .cap file can be executed when RenderDoc's file associations are set up, and RenderDoc will
load this file and present you with the capture dialog on startup.</para>
<para>You can also use the "Auto start" option - when this option is enabled then a .cap file
will immediately launch the program when it is loaded. This can allow you to configure a .cap
which will open RenderDoc and launch the target application with the pre-configured settings
in one click. If you wish to disable this, just uncheck the option and re-save to the same .cap file.</para>
</content>
</section>
<relatedTopics>
<link xlink:href="D1612D25-C8BA-4349-9CE2-1E57D60F98C5" />
</relatedTopics>
</developerConceptualDocument>
</topic>
docs/HowTo/HowToCustomShader.aml
+169
View File
@@ -0,0 +1,169 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="a00964a1-733f-4288-a79e-c28238bc6018" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<para>This page details how to set up a custom shader for visualisation. This can be used
in the <link xlink:href="2c540574-0b81-4a40-8119-ba0283fddf41" /> to unpack or decode complex
formats, or simply apply a custom complex transformation to the image beyond the default controls.</para>
</introduction>
<section address="intro">
<title>Introduction</title>
<content>
<para>The basic process of setting up the custom shader involves writing a .hlsl file that
will be compiled and used by RenderDoc.</para>
<para>There are several special global variables that can be specified and will
be filled in with values by RenderDoc.</para>
<para>Your pixel shader defines an operation that transforms the raw value from the input
texture into a value that will then be displayed by the texture viewer. The usual texture
viewer controls for range adaption and channels will still be available on the resulting
texture.</para>
<para>Multisampled textures will be resolved before being passed to your function.
Depth and stencil textures will be bound separately and passed as multisampled resources.</para>
<para>To set up your shader, it's recommended that you use the UI defined in the documentation for the
<link xlink:href="2c540574-0b81-4a40-8119-ba0283fddf41" />, but you can manually create a .hlsl file in
<codeInline>%APPDATA%\RenderDoc\</codeInline>. The file must contain an hlsl function main() that
returns float4, and uses any of the below inputs. These shaders are loaded when RenderDoc
loads a logfile, and RenderDoc watches for any changes to the files (either externally or in
the shader editor in RenderDoc) and automatically reloads them.</para>
</content>
</section>
<section address="inputs">
<title>Predefined inputs</title>
<content>
<para>There are several pre-defined inputs that can either be taken as parameters to
the shader entry point, or defined as global variables with a particular name that will
then be filled in. There are also definitions for the different type of input textures.</para>
<alert class="caution">
<para>Type and capitalisation is important for these variables, so ensure you use the right
declaration!</para>
</alert>
<table>
<tableHeader>
<row>
<entry><para>Input</para></entry>
<entry><para>Explanation</para></entry>
</row>
</tableHeader>
<row>
<entry><para>UV co-ordinates</para></entry>
<entry>
<code language="hlsl">
float4 main(<markup><u>float4 pos : SV_Position</u></markup>, <markup><u>float4 uv : TEXCOORD0</u></markup>) : SV_Target0
{
return 1;
}
</code>
<para>This input is defined as two parameters to the shader entry point. The first defines the usual
SV_Position system semantic, and the first two components of the second TEXCOORD0 parameter gives UV
co-ordinates from 0 to 1 in each dimension over the size of the texture (or texture slice).</para>
<alert class="note">
<para>You must bind these parameters like this in this order to ensure the linkage with the
vertex shader matches.</para>
</alert>
</entry>
</row>
<row>
<entry><para>Texture dimensions</para></entry>
<entry>
<code language="hlsl">
uint4 RENDERDOC_TexDim;
</code>
<para>This variable will be filled out with the following values:</para>
<list class="bullet">
<listItem><para><codeInline>.x = </codeInline> Width</para></listItem>
<listItem><para><codeInline>.y = </codeInline> Height (if 2D or 3D)</para></listItem>
<listItem><para><codeInline>.z = </codeInline> Depth if 3D or array size if an array</para></listItem>
<listItem><para><codeInline>.w = </codeInline> Number of mip levels</para></listItem>
</list>
</entry>
</row>
<row>
<entry><para>Selected Mip level</para></entry>
<entry>
<code language="hlsl">
uint RENDERDOC_SelectedMip;
</code>
<para>This variable will be filled out with the selected mip level in the UI.</para></entry>
</row>
<row>
<entry><para>Current texture type</para></entry>
<entry>
<code language="hlsl">
uint RENDERDOC_TextureType;
</code>
<para>This variable will be set to a given integer value, depending on the type of
the current texture being displayed. This can be used to sample from the correct resource.</para>
<list class="ordered">
<listItem><para>1D texture</para></listItem>
<listItem><para>2D texture</para></listItem>
<listItem><para>3D texture</para></listItem>
<listItem><para>Depth</para></listItem>
<listItem><para>Depth + Stencil</para></listItem>
<listItem><para>Depth (Multisampled)</para></listItem>
<listItem><para>Depth + Stencil (Multisampled)</para></listItem>
</list>
</entry>
</row>
<row>
<entry><para>Samplers</para></entry>
<entry>
<code language="hlsl">
SamplerState pointSampler : register(s0);
SamplerState linearSampler : register(s1);
</code>
<para>These samplers are provided to allow you to sample from the resource
as opposed to doing straight loads. They are bound by slot and not by variable name -
so this means you can name them as you wish but you must specify the register binding
explicitly.</para></entry>
</row>
<row>
<entry><para>Resources</para></entry>
<entry>
<code language="hlsl">
Texture1DArray&lt;float4&gt; texDisplayTex1DArray : register(t1);
Texture2DArray&lt;float4&gt; texDisplayTex2DArray : register(t2);
Texture3D&lt;float4&gt; texDisplayTex3D : register(t3);
Texture2DArray&lt;float2&gt; texDisplayTexDepthArray : register(t4);
Texture2DArray&lt;uint2&gt; texDisplayTexStencilArray : register(t5);
Texture2DMSArray&lt;float2&gt; texDisplayTexDepthMSArray : register(t6);
Texture2DMSArray&lt;uint2&gt; texDisplayTexStencilMSArray : register(t7);
Texture2DArray&lt;float4&gt; texDisplayTexCubeArray : register(t8);
Texture1DArray&lt;uint4&gt; texDisplayUIntTex1DArray : register(t11);
Texture2DArray&lt;uint4&gt; texDisplayUIntTex2DArray : register(t12);
Texture3D&lt;uint4&gt; texDisplayUIntTex3D : register(t13);
Texture1DArray&lt;int4&gt; texDisplayIntTex1DArray : register(t21);
Texture2DArray&lt;int4&gt; texDisplayIntTex2DArray : register(t22);
Texture3D&lt;int4&gt; texDisplayIntTex3D : register(t23);
</code>
<para>These resources are bound sparsely with the appropriate type for the
current texture. With a couple of exceptions there will only be one texture bound
at any one time.</para>
<para>When a cubemap texture is bound, it is bound both to the 2D Array as well
as the Cube Array. If a depth-stencil texture has both components, the relevant depth and
stencil resources will both be bound at once.</para>
<para>To determine which resource to sample from you can use the RENDERDOC_TexType variable
above.</para>
<para>Usually the float textures are used, but for unsigned and signed integer formats,
the relevant integer resources are used.</para>
<para>As with the samplers, these textures are bound by slot and not by name, so while
you are free to name the variables as you wish, you must bind them explicitly to the
slots listed here.</para></entry>
</row>
</table>
</content>
</section>
<relatedTopics>
<link xlink:href="2c540574-0b81-4a40-8119-ba0283fddf41" />
</relatedTopics>
</developerConceptualDocument>
</topic>
docs/HowTo/HowToDebugShader.aml
+157
View File
@@ -0,0 +1,157 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="8a7568ca-6b2c-4873-b8eb-d1ad2aff9629" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<para>This page goes into detail about how to set up your captures for debugging
shaders, as well as how to debug a shader and what controls are available.</para>
</introduction>
<section address="DebugInfo">
<title>Including debug info in shaders</title>
<content>
<para>For the most part at least some debug information is included with shaders unless
it is being explicitly stripped out at some point. There is usually an option to also
include additional debug information - such as original source code in a high-level language.
The exact process varies by API, but for D3D11 the flag /Zi to fxc or the equivalent
flag to D3DCompile() will include additional debugging information, and /Qstrip_debug
and /Qstrip_reflection will remove reflection information that can be useful - such as
the names of variables in constant buffers.</para>
</content>
</section>
<section address="vertex">
<title>Debugging a vertex</title>
<content>
<para>Vertex debugging is invoked from the mesh viewer. With the mesh viewer open you can
select the input vertex you wish to debug.</para>
<para>When a vertex is selected in the mesh data for the vertex input it will be highlighted
along with the primitive it is part of in the mesh display, provided the display is in
vertex input mode.</para>
<para>Either right click and choose debug vertex
from the context menu, or click on the debug icon in the toolbar.</para>
<mediaLink>
<caption placement="after" lead="Vertex Debugging">Launching vertex debugging from the mesh viewer.</caption>
<image xlink:href="VertexDebug"/>
</mediaLink>
<para>From here the debugger will open with the vertex shader in the shader debugger.
The inputs are automatically filled in from the mesh data.</para>
<alert class="note">
<para>Geometry and tessellation shaders are not yet debuggable.</para>
</alert>
</content>
</section>
<section address="pixel">
<title>Debugging a Pixel</title>
<content>
<para>Pixel debugging is launched from the texture viewer. For more details on selecting
the pixel to debug see <link xlink:href="F1C1E449-55ED-46FE-BBFD-11D1A0511501" />.</para>
<para>When a given pixel is selected you can either choose the debug icon on the
toolbar, <mediaLinkInline><image xlink:href="wrench"/></mediaLinkInline>
or click the debug button underneath the pixel context. Each of these will
launch the shader viewer with the selected pixel being debugged. The
inputs to the pixel will be automatically filled in.</para>
<para>There are currently several things to note while pixel debugging:</para>
<list class="bullet">
<listItem><para>There is no pixel history at the moment, so the drawcall that you wish to debug
must be selected as the current even when you attempt to debug the pixel.</para></listItem>
<listItem><para>If a drawcall overdraws the same pixel several times then the results of debugging
may not be accurate - RenderDoc attempts to pick the fragment that last passed the depth test but this
isn't guaranteed and may not be perfect. There's also no way to choose a different fragment in the case
of blending being used, or sample-frequency rendering.</para></listItem>
</list>
</content>
</section>
<section address="compute">
<title>Debugging a Compute thread</title>
<content>
<para>To debug a compute thread simply go to the compute shader section of the pipeline state
viewer and enter the group and thread ID of the thread you would like to debug. This thread
will be debugged in isolation as with any other shader invocation.</para>
<para>This means there can be no synchronisation with any other compute thread running and
the debugging will run from start to finish as if no other thread had run.</para>
<alert class="caution">
<para>This feature is <legacyBold>highly</legacyBold> experimental and is provided with no guarantees
yet! It may work on simple shaders which is why it is available.</para>
</alert>
</content>
</section>
<section address="debugging">
<title>Debugging Controls</title>
<content>
<para>When debugging, at the moment the controls are fairly basic.</para>
<mediaLink>
<caption placement="after" lead="Shader controls">Controls for stepping through shaders.</caption>
<image xlink:href="ShaderControls"/>
</mediaLink>
<para>The toolbar at the top gives controls for the program flow through the
shader. <mediaLinkInline><image xlink:href="runfwd"/></mediaLinkInline> Run and
<mediaLinkInline><image xlink:href="runback"/></mediaLinkInline> Run Backward simply
run from the current position all the way
through to the end or start of the program respectively.</para>
<para>The keyboard shortcuts for these controls are <command>F5</command> and
<command>Shift-F5</command> respectively.</para>
<para>You can set a breakpoint by pressing F9 (this will also remove a breakpoint that is
already there). When running in each direction or to cursor (see below) if execution hits
a breakpoint it will stop.</para>
<para>The other controls allow for single stepping and limited running.
<mediaLinkInline><image xlink:href="stepnext"/></mediaLinkInline> Step forward
will execute the current instruction and continue to the next - this includes following
any flow control statements such as jumps, loops, etc.</para>
<para><mediaLinkInline><image xlink:href="stepprev"/></mediaLinkInline> Step backwards
will jump back to whichever instruction lead to the current instruction.
This does not necessarily mean the previous instruction in the program as it could be
the destination of a jump. Stepping forwards and stepping backwards will always reverse
each other. The shortcuts for these commands are <command>F10</command> and <command>Shift-F10</command></para>
<para>The final control is to
<mediaLinkInline><image xlink:href="runcursor"/></mediaLinkInline> Run to the cursor.
This will perform in a similar fashion
to the "Run" command, but when it reaches the line that the cursor highlights it will stop
and pause execution. It will also stop if it reaches the end of the shader.</para>
<alert class="note">
<para>The highlighted instruction at any given point indicates the <legacyItalic>next</legacyItalic>
instruction to be executed - not the instruction that was just executed.</para>
</alert>
<para>There is also a toggle available to control the 'default' interpretation of temporary
register values - float or int. Since registers are typeless typically they are interpreted as
float values, but with this toggle you can toggle them to be interpreted as integers.</para>
</content>
</section>
<section address="debugging">
<title>Debugging Displays</title>
<content>
<para>Currently there is only a very basic display when debugging shaders.</para>
<para>There are two windows that display different types of registers. The constants window
will display input and constant buffer registers that are immutable throughout execution.
This will also list registers for resources and samplers (with basic format information).</para>
<mediaLink>
<caption placement="after" lead="Constants window">Constant, input and resource registers.</caption>
<image xlink:href="ShaderConsts"/>
</mediaLink>
<para>The other window will contain variable/mutable registers. These contain temporaries that
are typically allocated up front and will update as you step through the execution of the shader.
This window also contains the output registers.</para>
<mediaLink>
<caption placement="after" lead="Variable window">Variable registers - temporaries and outputs.</caption>
<image xlink:href="ShaderRegs"/>
</mediaLink>
<para>The final window is initially empty but can be filled out as needed. This shows custom watch
expressions and their values. Here you can write any expression involving an input, temporary or
output register along with a swizzle and typecast.</para>
<para>Swizzles follow the standard hlsl rules - .[xyzw] or .[rgba] in any permutation or repetition
will show those channels.</para>
<para>The custom typecast can be any of ,x ,i ,d ,f ,u to display the register as hex, signed integer,
double, float or unsigned respectively.</para>
<mediaLink>
<caption placement="after" lead="Watch window">Watch window - custom register expressions evaluated.</caption>
<image xlink:href="ShaderWatch"/>
</mediaLink>
</content>
</section>
</developerConceptualDocument>
</topic>
docs/HowTo/HowToEditShader.aml
+73
View File
@@ -0,0 +1,73 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="6d0b6532-6da2-485d-85cd-e83e8c9e0183" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<para>This page details how to edit shaders. This applies both to
<link xlink:href="a00964a1-733f-4288-a79e-c28238bc6018">custom visualisation shaders</link> for the
<link xlink:href="2c540574-0b81-4a40-8119-ba0283fddf41" />, but can also be used to temporarily replace or
edit a shader used in the actual scene.</para>
</introduction>
<section address="EditCustom">
<title>How to edit a custom shader</title>
<content>
<para><link xlink:href="a00964a1-733f-4288-a79e-c28238bc6018">Custom visualisation shaders</link> allow you to define
your own transformation on any texture you're viewing before it is displayed. Mostly this is useful for decoding
packed or custom-format data, or displaying some data in a more visually intuitive fashion.</para>
<para>These shaders live as .hlsl files in <codeInline>%APPDATA%\RenderDoc\</codeInline>, and can be edited in your
editor of choice, any changes saved will be reloaded. Note however that there is currently no way to see the
compile warnings or errors produced. This is probably best for when you have an existing shader to drop-in.</para>
<para>To edit a shader inside RenderDoc simply click the edit button
<mediaLinkInline><image xlink:href="page_white_edit"/></mediaLinkInline> when you have selected your custom shader
for use. This will launch a new window with the custom shader and any changes you make to this shader will be
saved to the .hlsl file and compiled and reflected in the texture viewer as long as you have that custom shader
selected.</para>
</content>
</section>
<section address="EditLive">
<title>How to edit a scene shader</title>
<content>
<para>RenderDoc allows you to edit a shader used in the capture and make changes to it and see the effects in real-time.</para>
<para>To launch the shader editor, go to the pipeline stage you wish to change in the <link xlink:href="A44E2304-6C11-451D-89C4-0A7397F5D1C6" />
windows, and click on the edit button <mediaLinkInline><image xlink:href="page_white_edit"/></mediaLinkInline>
next to the shader.</para>
<para>Note: this feature is intended to be used when shader debug info is available and the hlsl source can be used.
If the hlsl isn't available, RenderDoc will generate a stub function with the input and output signatures available from
the reflection data that you can fill in if you wish.</para>
<para>Any changes to the shader will affect any drawcall using this shader, not just the currently-selected drawcall.
The changes will persist until the edit window is closed.</para>
<alert class="caution">
<para>One unfortunate artifact of how the shader debug info works, not all #included hlsl files will come along with the debug info,
only those files that contain compiled code. RenderDoc automatically replaces any #includes
to missing files with just an empty comment, but unfortunately this can lead to compile errors in unused code.</para>
<para>This can also interact badly with another artifact - macro definitions passed directly to the compiler are not
included in the debug info and so RenderDoc can't include them when recompiling. If you rely on any defines, you
will need to add them manually to the top of your root hlsl file.</para>
</alert>
</content>
</section>
<section address="ShaderEditor">
<title>Using the built-in shader editor</title>
<content>
<para>When you have launched the shader editor, the main window will be filled with the hlsl of your shader.
In here you can make edits and changes with the basic controls and syntax highlighting available with the
Scintilla editor.</para>
<para>To compile the shader and apply your changes, either click the save button in the toolbar or press
Ctrl-S. This will compile the shader and apply it, any warnings and errors will be added to the box below
the main source.</para>
<para>Custom shaders are built with a simple set of flags, any shaders from the scene will be compiled with
the flags that were originally passed to the compiler.</para>
<alert class="caution">
<para>If there are errors compiling a visualisation shader, it will be removed from the texture viewer and normal RGB display
will be used until you fix the error.</para>
</alert>
<para>In addition, when editing visualisation shaders a button will be available to insert several useful snippets
for custom shaders with the pre-defined variables that can be bound. For more detail, see
<link xlink:href="a00964a1-733f-4288-a79e-c28238bc6018" /></para>
</content>
</section>
</developerConceptualDocument>
</topic>
docs/HowTo/HowToFindTexture.aml
+85
View File
@@ -0,0 +1,85 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="32C47E20-0FA2-4F52-B33A-4440EBCCBCE4" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<para>This page documents how to annotate your resources with user-friendly names
to make it easier to follow use of them throughout the frame, as well as the functions
for finding and following textures by name rather than by usage.</para>
</introduction>
<section address="Annotation">
<title>Annotating resources with names</title>
<content>
<para>It is much easier to browse and debug frames when the resources are
given meaningful names - along with including
<link xlink:href="8a7568ca-6b2c-4873-b8eb-d1ad2aff9629">debugging information in shaders</link> and
marking up the frame with
<link xlink:href="16D2B42E-65B0-40D1-AB91-AD2B156F5DA0">hierarchical user-defined regions</link>.</para>
<para>The way this is done varies by API. In D3D11 the resource is named in this way:</para>
<code language="cpp">
// Creating an example resource - a 2D Texture.
ID3D11Texture2D *tex2d = NULL;
d3dDevice->CreateTexture2D(&amp;descriptor, NULL, &amp;tex2d);
// Give the buffer a useful name
tex2d->SetPrivateData(WKPDID_D3DDebugObjectName, "Example Texture", sizeof("Example Texture"));
</code>
<para>When this texture is bound to the pipeline it will be listed like so:</para>
<mediaLink>
<caption placement="after" lead="Named Texture">The example texture bound with name displayed.</caption>
<image xlink:href="NamedTex"/>
</mediaLink>
<para>In a similar way any other resource can be named and this will be useful throughout
the rest of the analysis.</para>
</content>
</section>
<section address="TextureList">
<title>Texture list in Texture Viewer</title>
<content>
<para>In the texture viewer you can open a filterable list of all textures in the capture.
This can be opened with the texture list icon
<mediaLinkInline><image xlink:href="page_white_link"/></mediaLinkInline>. When clicked on
this will open a sidebar on the texture viewer that lists all textures.</para>
<mediaLink>
<caption placement="after" lead="Texture list">The sidebar showing the list of textures</caption>
<image xlink:href="TexList"/>
</mediaLink>
<para>This list of textures can be filtered by a custom string which will narrow the list
of textures displayed, or simply by their creation flags as either a render target or
a texture.</para>
<para>When selecting and opening one of the textures from here, a new tab is opened in
the texture viewer that follows that texture.</para>
</content>
</section>
<section address="LockedTexture">
<title>Locked tab of a Texture</title>
<content>
<para>By default the tab open in the texture viewer follows whichever pipeline slot is currently
selected. When a new event is selected this tab can display a new texture if the contents of that
slot has changed.</para>
<para>If you want to follow a particular texture even as it becomes unbound or moves from output
to input and vice versa, you can open a new locked tab that will stay consistently on this texture.</para>
<mediaLink>
<caption placement="after" lead="Texture Tabs">Default tab following pipeline slot vs Locked tab.</caption>
<image xlink:href="CurrentVsLockedTab"/>
</mediaLink>
<para>This can be done by locating the texture by name as above, then clicking on the entry
in the list. This will open up a new tab for this texture which will not change regardless of
the current pipeline state, or current event.</para>
<para>Opening a texture from the pipeline state viewer
(<link xlink:href="7A620DF5-332E-44CA-8FD5-9E47A9C4CC3E" />)
will also open a new locked tab for the texture in question. You can also open a new locked tab by
right clicking on the texture thumbnail while it is currently bound.</para>
<mediaLink>
<caption placement="after" lead="Opening new Tab">Opening a new locked tab for a texture.</caption>
<image xlink:href="OpenLockedTab"/>
</mediaLink>
</content>
</section>
<relatedTopics>
<link xlink:href="2c540574-0b81-4a40-8119-ba0283fddf41" />
</relatedTopics>
</developerConceptualDocument>
</topic>
docs/HowTo/HowToInspectPixel.aml
+67
View File
@@ -0,0 +1,67 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="F1C1E449-55ED-46FE-BBFD-11D1A0511501" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<para>When in the texture viewer you can inspect the pixel values to obtain the exact
contents of any pixel in the texture.</para>
</introduction>
<section address="Subresource">
<title>Selecting appropriate subresource</title>
<content>
<para>More details can be found in the <link xlink:href="2c540574-0b81-4a40-8119-ba0283fddf41" />
page, but the first step is to select the appropriate subresource - array element, cubemap face
or mip slice.</para>
<para>The values that are picked out of the texture are always exact values, and will not be
affected by the currently selected channels or range adaption control.</para>
</content>
</section>
<section address="PickPixel">
<title>Picking a Pixel Value</title>
<content>
<para>At any point while hovering over the texture the status bar contains the current
pixel location that the cursor is hovering over, as well as a basic colour swatch to give
some indication of where you are.</para>
<mediaLink>
<caption placement="after" lead="Hover Status Bar">The status bar showing position and colour</caption>
<image xlink:href="HoverStatus"/>
</mediaLink>
<para>When the right mouse button is pressed, the currently hovered pixel value will be displayed
with the current float precision settings - for more information on how to tune these look at
the window reference for the <link xlink:href="B1826EEE-2ED1-44E4-8202-37CD8B3FEEB5" />.</para>
<para>For depth textures the depth and stencil values will be displayed separately. The stencil
value (as with any integer formatted texture) will be displayed as an integer.</para>
<mediaLink>
<caption placement="after" lead="Picked Pixel">The value of a pixel that has been picked</caption>
<image xlink:href="RMBStatus"/>
</mediaLink>
<para>If the right mouse button is just clicked, the picked pixel value will remain with the same
value as the mouse moves. If you hold the right mouse button and drag, it will update as the mouse
moves to allow some amount of refinement.</para>
<para>To make fine adjustments by a single pixel at a time, it's easiest to use the arrow keys
on the keyboard. Pressing these will shift the picked location by a single pixel in each
direction.</para>
</content>
</section>
<section address="PixelContext">
<title>Pixel Context Display</title>
<content>
<para>Whenever a pixel is picked, the pixel context display is updated to surround the currently
selected pixel. This dialog is by default docked in the bottom right of the texture viewer, adjacent
to the thumbnail strip.</para>
<mediaLink>
<caption placement="after" lead="Pixel Context">The zoomed in context around the pixel currently selected</caption>
<image xlink:href="PixelContext"/>
</mediaLink>
<para>This context display shows a zoomed in view of the texture around the area that you've selected
so that it's easier to make small adjustments without zooming in and losing a sense of the whole
texture.</para>
<para>The pixel context viewer can also allow you to launch pixel debugging. Once a pixel is picked
the button below the context is activated which will launch the shader debugger. More information
about this is available: <link xlink:href="8a7568ca-6b2c-4873-b8eb-d1ad2aff9629" />.</para>
</content>
</section>
<relatedTopics>
<link xlink:href="2c540574-0b81-4a40-8119-ba0283fddf41" />
</relatedTopics>
</developerConceptualDocument>
</topic>
docs/HowTo/HowToViewDetails.aml
+95
View File
@@ -0,0 +1,95 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="7A620DF5-332E-44CA-8FD5-9E47A9C4CC3E" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<autoOutline />
<para>The pipeline state viewer allows you to view more details of given resources
that are bound to the pipeline. The go arrow
<mediaLinkInline><image xlink:href="GoArrow"/></mediaLinkInline> is a sign that more
details for this resource are available.</para>
</introduction>
<section address="shaders">
<title>Viewing Shaders</title>
<content>
<para>Each shader stage that is active on the pipeline can be expanded to see both the
high-level shader language and the low-level disassembly. At the top of the pipeline
stage there is a box showing the currently bound shader - by its entry point if known.</para>
<mediaLink>
<caption placement="after" lead="Bound Shader">Box showing the currently used shader.</caption>
<image xlink:href="CurrentShader"/>
</mediaLink>
<para>Much of the information that is available from the shader is only available
when debugging information is made available.
<link xlink:href="8a7568ca-6b2c-4873-b8eb-d1ad2aff9629">More details are available</link>
</para>
<para>Each file passed to the compiler for this the shader is shown with simple syntax
highlighting, as well as the disassembly generated from the bytecode itself.</para>
<para>If available, the reflection data from the shader debugging information will be used
in other areas of the pipeline state viewer. It will be used for naming texture slots,
showing which resources that are bound are to be used in the shader, as well as showing
the names of any constants that are used in the shader.</para>
<para>When this shader reflection information is available it will be integrated into
the disassembly to make it easier to read.</para>
<para>Note from here you can also <link xlink:href="6d0b6532-6da2-485d-85cd-e83e8c9e0183">live-edit a shader</link> by clicking the edit button
<mediaLinkInline><image xlink:href="page_white_edit"/></mediaLinkInline>. If debug info
isn't available to provide HLSL, a basic stub function with the input &amp; output
signatures but no body will be created.</para>
</content>
</section>
<section address="textures">
<title>Viewing Textures</title>
<content>
<para>The <link xlink:href="2c540574-0b81-4a40-8119-ba0283fddf41" /> is the primary way of
viewing details of textures, so this section concerns itself with how textures are displayed
in other parts of the UI, and how to open a texture in the texture viewer. More details can
be found in <link xlink:href="32C47E20-0FA2-4F52-B33A-4440EBCCBCE4" />.</para>
<para>A texture that is bound to the pipeline as a resource or output the relevant section
of the pipeline will display their dimensions and format. In each place the go arrow
<mediaLinkInline><image xlink:href="GoArrow"/></mediaLinkInline> will indicate that a new
locked tab can be opened up in the texture viewer.</para>
<para>In addition to opening a new view of the texture, the timeline bar will also show
the usage of this texture - a green triangle will indicate a place where the texture is
read from, and a purple triangle indicates a writing operation. These triangles don't necessarily
correspond 1:1 with the event - more details are available on the
<link xlink:href="745E3EB5-EB29-4010-BBAB-B11282F4380C" /> page.</para>
</content>
</section>
<section address="buffers">
<title>Viewing Buffers</title>
<content>
<para>More details on this section are available on the <link xlink:href="C48DED3E-3303-4A82-8F58-3D39766C48E7" />
page.</para>
<para>When opened either from the input layouts or from the 'Window' menu, the buffer viewer
opens up in the mesh viewer mode. This is a specialisation of the buffer viewer which will
show a 3D display of the mesh represented, as well as viewing the mesh buffers at different
points in the pipeline.</para>
<para>In the general case, buffers bound to the pipeline can be opened as a raw buffer viewer.</para>
<para>This will open up a view of the buffer similar to the mesh viewer, but with a completely
customisable buffer layout.</para>
<para>By default if the buffer is bound to the pipeline with a pre-existing structure that can
be reflected from the shader then this will be the default, otherwise the default layout will be
4 32bit unsigned integers per element.</para>
<para>This layout can be customised by entering a format in a simple style that mimics defining
a structure that outlines a single element in the buffer.</para>
<mediaLink>
<caption placement="after" lead="Custom Buffer Layout">Customising the layout of the buffer by defining a structure.</caption>
<image xlink:href="RawBuffer"/>
</mediaLink>
</content>
</section>
<section address="constants">
<title>Viewing Constant Buffers</title>
<content>
<para>Constant buffers can be viewed by clicking on their Go Arrow
<mediaLinkInline><image xlink:href="GoArrow"/></mediaLinkInline>. This will open up a new docked section
to the right of the pipeline state viewer that tracks that constant buffer slot.</para>
<para>Whenever this shader slot has a constant buffer in it,
both the constant names and types as well as values will be displayed.</para>
<mediaLink>
<caption placement="after" lead="Constant Buffer">An updating preview of the contents of this constant buffer.</caption>
<image xlink:href="CBuffer"/>
</mediaLink>
</content>
</section>
</developerConceptualDocument>
</topic>
docs/Introduction.aml
+126
View File
@@ -0,0 +1,126 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="da00c42d-49ad-4a0a-b7e3-972dd6800960" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<summary>
<para>
<mediaLinkInline><image xlink:href="logo"/></mediaLinkInline>
Welcome to RenderDoc - a graphics debugger, currently available for
D3D11 development on windows.
</para>
</summary>
<introduction>
<para>
This document serves primarily as reference guide, introductory document
and explanation of which features are available in RenderDoc and how to
best use them.
</para>
</introduction>
<section address="guide">
<title>License</title>
<content>
<para>
RenderDoc is released under the MIT license, so there are no restrictions on your use of it either
commercial or non-commercial.
</para>
<para>
This license will also not change when the source is released, so any source modifications will be
equally unrestricted.
</para>
<para>
Details of the licenses of third party software used in RenderDoc are included in the LICENSE file
in the RenderDoc directory as well as in the <link xlink:href="ddeda389-3bd8-460d-b420-20e563003da4" />.
</para>
</content>
</section>
<section address="guide">
<title>How to browse this documentation</title>
<content>
<para>
If you just want to dive straight in and learn how to get started using
RenderDoc consider looking at the <link xlink:href="f2f4fbfa-6127-4831-84e7-07309bd85908" />
section which gives a simple introduction on how to get started. Afterwards
there are reference pages on each of the windows available in RenderDoc which
can be referred to as you use the program, or skimmed to get a feel for the functionality
available.
</para>
<para>
Those of you familiar with other graphics debuggers will likely find much
of RenderDoc recognisable, you might want to check out the
<link xlink:href="b97b19f8-2b97-4dca-8a7a-ed7026eb43fe" />,
<link xlink:href="86b8bce7-b7cd-4b10-aa61-706463d14fe0" />,
<link xlink:href="e2878f27-34d3-458a-9077-d0fb32c16829" />
or browse the How Do I... ? sections which detail how
some common tasks are accomplished.
</para>
<para>
Regardless of your experience or patience for documentation it's recommended
that you read the <link xlink:href="a56958b2-bf9e-411a-8354-56284e713f09" />
as this details known bugs and current limitations of the program.
</para>
</content>
</section>
<section address="important">
<title>Important notes</title>
<content>
<list class="bullet">
<listItem><para>RenderDoc is not yet bug free! It is pretty stable but you will still likely encounter
bugs depending on your use case. I am <legacyItalic>always</legacyItalic> happy to spend time
to fix them and I can work with you even if you cannot share any details about your project. Get
in touch (see below) and I will actively fix your bug!</para></listItem>
<listItem><para>On the other side of the coin, please do give feedback when RenderDoc works for you and
request features that would make your life easier or improve your workflow.</para></listItem>
<listItem><para>There are a few common issues you might run into, so if you have any problems check the
<link xlink:href="b97b19f8-2b97-4dca-8a7a-ed7026eb43fe" />, or the <externalLink>
<linkText>issues page on github</linkText>
<linkAlternateText>Issues on github</linkAlternateText>
<linkUri>https://github.com/baldurk/renderdoc/issues</linkUri>
</externalLink> to see if it's been reported.</para></listItem>
</list>
</content>
</section>
<section address="contact">
<title>Contact info, Feedback, Bug reports</title>
<content>
<para>
If you want to get in touch with any feature requests, suggestions, comments etc
then feel free to contact me: <token>Baldur Contact</token>.
</para>
<para>
Bug reports can be submitted directly via email, or also on the <externalLink>
<linkText>github repository</linkText>
<linkAlternateText>Issues on github</linkAlternateText>
<linkUri>https://github.com/baldurk/renderdoc/issues</linkUri>
</externalLink>
</para>
<para>
There are also <externalLink>
<linkText>forums</linkText>
<linkAlternateText>Forums on CryDev.net</linkAlternateText>
<linkUri>http://www.crydev.net/viewforum.php?f=379</linkUri>
</externalLink>
where you can post on and get help from others who are using
RenderDoc.
</para>
</content>
</section>
<relatedTopics>
<externalLink>
<linkText>RenderDoc Homepage</linkText>
<linkAlternateText>Go to the RenderDoc Homepage</linkAlternateText>
<linkUri>http://renderdoc.org/</linkUri>
</externalLink>
<externalLink>
<linkText>Forums on CryDev.net</linkText>
<linkAlternateText>Go to the forums on CryDev.net</linkAlternateText>
<linkUri>http://www.crydev.net/viewforum.php?f=379</linkUri>
</externalLink>
<!--
<link xlink:href="Other Topic's ID"/>
<link xlink:href="Other Topic's ID">Link inner text</link>
-->
</relatedTopics>
</developerConceptualDocument>
</topic>
docs/Layout.content
+182
View File
@@ -0,0 +1,182 @@
<?xml version="1.0" encoding="utf-8"?>
<Topics>
<Topic id="da00c42d-49ad-4a0a-b7e3-972dd6800960" visible="True" isDefault="true">
<HelpKeywords>
<HelpKeyword index="K" term="Introduction" />
<HelpKeyword index="K" term="Welcome" />
<HelpKeyword index="K" term="Contact" />
<HelpKeyword index="K" term="License" />
</HelpKeywords>
</Topic>
<Topic id="a198a6de-5f05-4c63-a41c-21960ab68e21" visible="True" noFile="true" isExpanded="true" title="Getting Started">
<Topic id="b97b19f8-2b97-4dca-8a7a-ed7026eb43fe" visible="True" linkText="FAQ">
<HelpKeywords>
<HelpKeyword index="K" term="FAQ" />
</HelpKeywords>
</Topic>
<Topic id="a56958b2-bf9e-411a-8354-56284e713f09" visible="True" title="Gotchas &amp; Known Issues">
<HelpKeywords>
<HelpKeyword index="K" term="Known Bugs" />
</HelpKeywords>
</Topic>
<Topic id="f2f4fbfa-6127-4831-84e7-07309bd85908" visible="True" title="Quick Start">
<HelpKeywords>
<HelpKeyword index="K" term="Quick Start" />
</HelpKeywords>
</Topic>
<Topic id="86b8bce7-b7cd-4b10-aa61-706463d14fe0" visible="True">
<HelpKeywords>
<HelpKeyword index="K" term="Features" />
</HelpKeywords>
</Topic>
<Topic id="e2878f27-34d3-458a-9077-d0fb32c16829" visible="True" isSelected="true" title="Tips &amp; Tricks">
<HelpKeywords>
<HelpKeyword index="K" term="Tips &amp; Tricks" />
<HelpKeyword index="K" term="Code Integration, Manually triggered log capture" />
<HelpKeyword index="K" term="How To, Manually trigger a capture" />
</HelpKeywords>
</Topic>
</Topic>
<Topic id="5c7ad9b1-1fcb-4880-a7f2-5cf6e7b874c1" visible="True" noFile="true" isExpanded="true" title="Behind the Scenes">
<Topic id="632271c3-3d72-4360-b4a0-dc570fcd541e" visible="True" title="Planned Future Features">
<HelpKeywords>
<HelpKeyword index="K" term="Planned Features" />
</HelpKeywords>
</Topic>
<Topic id="f351fea6-d0ac-426b-9631-feec2408a7e2" visible="True" title="How RenderDoc works">
<HelpKeywords>
<HelpKeyword index="K" term="RenderDoc Internals" />
</HelpKeywords>
</Topic>
</Topic>
<Topic id="708163f7-01b1-4d92-919d-f79a0bf8a365" visible="True" noFile="true" isExpanded="true" title="How do I... ?">
<Topic id="8a7568ca-6b2c-4873-b8eb-d1ad2aff9629" visible="True" title="How do I debug a shader?">
<HelpKeywords>
<HelpKeyword index="K" term="How To, Debug a Shader" />
<HelpKeyword index="K" term="Debugging, Shader Debugging" />
</HelpKeywords>
</Topic>
<Topic id="0dd6fe0d-4130-46f4-b2ea-9565de13111d" visible="True" title="How do I capture a log?">
<HelpKeywords>
<HelpKeyword index="K" term="How To, Capture Log" />
<HelpKeyword index="K" term="Capture Options" />
</HelpKeywords>
</Topic>
<Topic id="F1C1E449-55ED-46FE-BBFD-11D1A0511501" visible="True" title="How do I inspect a pixel value?">
<HelpKeywords>
<HelpKeyword index="K" term="How To, Inspect pixel value" />
<HelpKeyword index="K" term="Pixel Picking" />
</HelpKeywords>
</Topic>
<Topic id="32C47E20-0FA2-4F52-B33A-4440EBCCBCE4" visible="True" title="How do I view a specific texture?">
<HelpKeywords>
<HelpKeyword index="K" term="How To, Find texture by name" />
<HelpKeyword index="K" term="Texture List" />
<HelpKeyword index="K" term="Code Integration, Annotating textures" />
<HelpKeyword index="K" term="How To, Show a specific texture" />
<HelpKeyword index="K" term="Locking a view of a texture" />
</HelpKeywords>
</Topic>
<Topic id="7A620DF5-332E-44CA-8FD5-9E47A9C4CC3E" visible="True" title="How do I view details of an object?">
<HelpKeywords>
<HelpKeyword index="K" term="How To, View object details" />
<HelpKeyword index="K" term="How To, View shader source" />
<HelpKeyword index="K" term="How To, View constant buffer" />
<HelpKeyword index="K" term="Constant Buffer Contents" />
<HelpKeyword index="K" term="Raw Buffer View" />
</HelpKeywords>
</Topic>
<Topic id="14048aef-0053-4e38-98cd-541f4d15d12e" visible="True" title="How do I capture callstacks?" />
<Topic id="a00964a1-733f-4288-a79e-c28238bc6018" visible="True" title="How do I use a custom visualisation shader?">
<HelpKeywords>
<HelpKeyword index="K" term="How To, Use custom visualisation" />
<HelpKeyword index="K" term="Custom Shader Display" />
</HelpKeywords>
</Topic>
<Topic id="6d0b6532-6da2-485d-85cd-e83e8c9e0183" visible="True" title="How do I edit a shader?">
<HelpKeywords>
<HelpKeyword index="K" term="Shader Editing" />
<HelpKeyword index="K" term="How To, Edit custom shader" />
<HelpKeyword index="K" term="Hot-reload Shaders" />
</HelpKeywords>
</Topic>
</Topic>
<Topic id="91c367a9-b523-40a9-b81d-fe69797c0e2d" visible="True" noFile="true" isExpanded="true" title="Window Reference">
<Topic id="2c540574-0b81-4a40-8119-ba0283fddf41" visible="True" title="Texture Viewer">
<HelpKeywords>
<HelpKeyword index="K" term="Window, Texture Viewer" />
</HelpKeywords>
</Topic>
<Topic id="D78CE10E-0206-4DFC-B5CA-29F98D448235" visible="True" title="API Inspector">
<HelpKeywords>
<HelpKeyword index="K" term="API Calls" />
<HelpKeyword index="K" term="Window, API Inspector" />
</HelpKeywords>
</Topic>
<Topic id="C48DED3E-3303-4A82-8F58-3D39766C48E7" visible="True" title="Buffer Viewer/Mesh Output">
<HelpKeywords>
<HelpKeyword index="K" term="UAV Contents" />
<HelpKeyword index="K" term="Buffer Contents" />
<HelpKeyword index="K" term="Window, Buffer Viewer" />
<HelpKeyword index="K" term="Window, Mesh Output" />
</HelpKeywords>
</Topic>
<Topic id="D1612D25-C8BA-4349-9CE2-1E57D60F98C5" visible="True" title="Capture Log &amp; Attach">
<HelpKeywords>
<HelpKeyword index="K" term="Window, Capture Window" />
<HelpKeyword index="K" term="Window, Attach to Process" />
</HelpKeywords>
</Topic>
<Topic id="16D2B42E-65B0-40D1-AB91-AD2B156F5DA0" visible="True" title="Event Browser">
<HelpKeywords>
<HelpKeyword index="K" term="Window, Event Browser" />
<HelpKeyword index="K" term="Event Heirarchy" />
<HelpKeyword index="K" term="Code Integration, Creating Event Heirarchy" />
<HelpKeyword index="K" term="Timings" />
<HelpKeyword index="K" term="Drawcall Timings" />
<HelpKeyword index="K" term="Find Event" />
</HelpKeywords>
</Topic>
<Topic id="B1826EEE-2ED1-44E4-8202-37CD8B3FEEB5" visible="True" title="Options Window">
<HelpKeywords>
<HelpKeyword index="K" term="Window, Options" />
<HelpKeyword index="K" term="Settings" />
<HelpKeyword index="K" term="Preferences" />
<HelpKeyword index="K" term="How To, Set up file associations" />
</HelpKeywords>
</Topic>
<Topic id="A44E2304-6C11-451D-89C4-0A7397F5D1C6" visible="True" title="Pipeline State">
<HelpKeywords>
<HelpKeyword index="K" term="Window, Pipeline State" />
<HelpKeyword index="K" term="Current API State" />
<HelpKeyword index="K" term="Bound Resources" />
</HelpKeywords>
</Topic>
<Topic id="745E3EB5-EB29-4010-BBAB-B11282F4380C" visible="True" title="Timeline Bar">
<HelpKeywords>
<HelpKeyword index="K" term="Window, Timeline Bar" />
<HelpKeyword index="K" term="Resource Dependencies" />
</HelpKeywords>
</Topic>
<Topic id="6f4dad92-3db3-448f-9f1a-79af65f74492" visible="True" title="Capture Connection">
<HelpKeywords>
<HelpKeyword index="K" term="Window, Capture Connection" />
<HelpKeyword index="K" term="How To, Capture across a network" />
<HelpKeyword index="K" term="How To, Take multiple captures" />
</HelpKeywords>
</Topic>
<Topic id="1f098896-0e60-485a-b879-900a4a320b80" visible="True" title="Debug Messages">
<HelpKeywords>
<HelpKeyword index="K" term="Window, Debug Messages" />
<HelpKeyword index="K" term="How To, View API errors and messages" />
<HelpKeyword index="K" term="API Errors" />
<HelpKeyword index="K" term="API Messages" />
</HelpKeywords>
</Topic>
</Topic>
<Topic id="ddeda389-3bd8-460d-b420-20e563003da4" visible="True" title="Credits &amp; Acknowledgements">
<HelpKeywords>
<HelpKeyword index="K" term="Thanks" />
</HelpKeywords>
</Topic>
</Topics>
docs/QuickStart.aml
+254
View File
@@ -0,0 +1,254 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="f2f4fbfa-6127-4831-84e7-07309bd85908" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<autoOutline />
<para>
This document serves as a brief introduction to how to use RenderDoc to capture and
analyse your application. It doesn't go into much detail about exactly what functionality
is available for digging into things, as this can be found elsewhere. Instead it focuses
on just the workflow from start to finish and roughly where to look for different things.
</para>
<para>
For this tutorial we will be using a slightly modified version of the CascadedShadowMaps
sample from the Microsoft DirectX SDK (June 2010).
</para>
</introduction>
<section address="Capture">
<title>Capturing a log</title>
<content>
<para>To capture a log, begin by opening the File menu and selecting Capture Log. By default
this will open a new docked window where you can configure different settings that will be
used when capturing.</para>
<mediaLink><image xlink:href="QuickStart1"/></mediaLink>
<para>The defaults work pretty well in most situations, so you can just either
browse to or drag in your exe into the Executable box. If the working directory box is
empty then the Executable's directory will be used. Enter any command line you may need
and click 'Capture' to launch the application with RenderDoc.</para>
<para>More details of the specific options and their functionality can be found in
the details page for the <link xlink:href="D1612D25-C8BA-4349-9CE2-1E57D60F98C5">Capture Window</link>.</para>
<alert class="note">
<para>It's best to choose the edition of RenderDoc to match your OS - 64-bit for Windows x64 and vice-versa</para>
<para>You can only capture a 64-bit process with a 64-bit
build of RenderDoc. A 32-bit process can be captured by any build of RenderDoc.</para>
</alert>
</content>
</section>
<section address="Overlay">
<title>RenderDoc in-app</title>
<content>
<para>
RenderDoc has a fairly minimal in-app overlay, just to indicate that RenderDoc has successfully
loaded and is ready to capture a frame.
</para>
<para>
When ready, press the Capture Key (<command>F12</command> or <command>Print Screen</command>)
and the next frame after the keypress will be captured, and this will show up on the overlay
to let you know that a frame has been successfully saved.
</para>
<para><mediaLink><image xlink:href="QuickStart2"/></mediaLink></para>
<para>
When the application exits, if you captured a log it will automatically start to open in
the RenderDoc UI. If you didn't capture a log then nothing will happen and the RenderDoc UI will be
back as it was when you clicked Capture.
</para>
<para>
If you made multiple captures you will see a thumbnail list that allows you to open (in the current
instance or a new instance to compare side-by-side), save and delete them as you wish. You can
also access this view while the program is still running, see <link xlink:href="6f4dad92-3db3-448f-9f1a-79af65f74492" /> for more information on taking
multiple frame captures. Note however that for the simple use-case, you don't need to worry about this!
</para>
</content>
</section>
<section address="Layout">
<title>RenderDoc layout</title>
<content>
<para>
RenderDoc's layout can be customised fairly heavily so this section will only cover the default layout.
We'll go over the windows that are open by default and how each can be used in analysing your
program.
</para>
<para>
Each of these windows has a section that is much more in depth and gives details about every
function and feature, for the more complex windows such as the texture viewer you may well wish to
skim these to get an idea of what is available and use them as reference in the future.
</para>
<sections>
<section address="TextureViewer">
<title>Texture Viewer</title>
<content>
<mediaLink><image xlink:href="QuickStart3"/></mediaLink>
<para>More details can be found on the <link xlink:href="2c540574-0b81-4a40-8119-ba0283fddf41" /> page.</para>
<para>The texture viewer does pretty much what you'd expect - it allows you to inspect textures
and render targets in your application.</para>
<para>There are various visualisation controls that allow you to select different channels, mip levels
or other aspects of the texture, and more detail is available in the above page. Here we'll just
touch on the highlights:</para>
<list class="bullet">
<listItem><para>The thumbnail strip (by default to the right) lists either the output targets, or
shader inputs bound and used at present. Selecting each of these (the red outline on the thumbnail indicating
which is selected) will follow whatever resource is bound to that slot as you browse through the scene.</para>
<para>E.g. if you select render target 0 then the texture display will update to show the currently bound render
target 0 regardless of which texture that is. If the slot you are following becomes unbound or unused, the previous
texture will still be displayed up until you select a different pipeline slot, or the slot is bound again.
Unbound texture slots show up with <legacyItalic>Unbound</legacyItalic> listed under their thumbnail.</para>
<para>To open a specific texture and watch it even as it changes slots or becomes unbound, you can open it in a new
locked tab. Right click on the thumbnail and 'open in new locked tab', or
<link xlink:href="32C47E20-0FA2-4F52-B33A-4440EBCCBCE4">open it by name</link></para></listItem>
<listItem><para>The format and dimensions of the texture are displayed on the status bar just below the texture
display itself.</para>
<para>Also on this status bar you can see the current pixel co-ordinate that you are hovering over, as well as
the 'picked' pixel value which can be inspected by right clicking anywhere on the texture display.</para></listItem>
<listItem><para>Further to this, there is a small zoomed section of context around the last picked pixel available
in the bottom right of the texture viewer window. From here you can also launch the pixel debugger, with the provisos
detailed in <link xlink:href="8a7568ca-6b2c-4873-b8eb-d1ad2aff9629" />.</para></listItem>
<listItem><para>The last thing we will highlight is the range control. This is a fairly flexible tool that allows
you to adjust the visible range in the image. This is particular useful when viewing HDR images with a range outside
of <math>[0, 1]</math>.</para>
<para>To use the range control you can drag the white and black points to make fine adjustments or type values to change the values
of the white and black points (by default 0 and 1 respectively). There are also some useful controls to the right of
the range control itself, which are detailed again in the <link xlink:href="2c540574-0b81-4a40-8119-ba0283fddf41" /> page.</para>
<mediaLink>
<image xlink:href="QuickStart9"/>
</mediaLink></listItem>
</list>
</content>
</section>
<section address="EventBrowser">
<title>Event Browser</title>
<content>
<mediaLink><image xlink:href="QuickStart4"/></mediaLink>
<para>More details can be found on the <link xlink:href="16D2B42E-65B0-40D1-AB91-AD2B156F5DA0" /> page.</para>
<para>The Event Browser is the primary method of stepping through the frame and browsing
the events that occurred within. The first column EID (Event ID) indicates which event or API call this was
in the frame, chronologically. Events which are listed here are generally output/draw type events, including
Clears. Copy and Map type calls are not included and are available in the API Calls view (see below).</para>
<para>The columns can be customised and reordered, the
<mediaLinkInline><image xlink:href="timeline_marker"/></mediaLinkInline> select columns button (or right-click)
will allow you to choose which columns are displayed.</para>
<para>Standard performance markers are available and create the hierarchy/labels as you would expect.
These can be expanded or collapsed and keyboard browsing is available through normal controls -
left and right go higher or lower in the hierarchy, and up and down goes up and down through siblings.</para>
<para>The 'current' event - i.e. the event at which we are inspecting the graphics state - is highlighted
with a green Flag <mediaLinkInline><image xlink:href="GreenFlag"/></mediaLinkInline> and the row is highlighted.
As any row is selected it immediately becomes the new current event.</para>
<para>While the Event Browser is selected, you can press the shortcut keys <command>CTRL-F</command> or
<command>CTRL-G</command> to find <mediaLinkInline><image xlink:href="find"/></mediaLinkInline>
or jump to a given EID <mediaLinkInline><image xlink:href="GreenFlag"/></mediaLinkInline>
respectively.</para>
</content>
</section>
<section address="APIInspector">
<title>API Inspector</title>
<content>
<mediaLink><image xlink:href="QuickStart5"/></mediaLink>
<para>More details can be found on the <link xlink:href="D78CE10E-0206-4DFC-B5CA-29F98D448235" /> page.</para>
<para>The API Calls window updates as a new event is selected. It shows the individual API calls
and their parameters (in some fashion) between the previous and current event. The bottom entry
in this list always corresponds to the event that is currently selected, and each row can be expanded
to show the parameters that were passed to that API call.</para>
<para>At the bottom of the window is an optional expandable section which shows the callstack (if
available and recorded) from the application code into the API function.</para>
<para>In order to view these callstacks you must first resolve the symbols recorded with the log.
To do this click on <command>Resolve Symbols</command> under the <command>Tools</command> menu. More
details on this process can be found in the guide: <link xlink:href="14048aef-0053-4e38-98cd-541f4d15d12e" /></para>
</content>
</section>
<section address="TimelineBar">
<title>Timeline Bar</title>
<content>
<mediaLink><image xlink:href="QuickStart6"/></mediaLink>
<para>More details can be found on the <link xlink:href="745E3EB5-EB29-4010-BBAB-B11282F4380C" /> page.</para>
<para>The timeline bar is essentially an alternate view of the frame, with the horizontal axis
being time in the frame. The scale however is non-linear and is weighted to try and show each
section of the frame equally and visibly, rather than scaling by duration.</para>
<para>The frame marker hierarchy is top-down in this case, and can be expanded or collapsed by
clicking on each section. In this image, Cascades and Cascade 1 are both expanded, but the other
sections remain collapsed. Each drawcall is rendered as a blue circle underneath the section of
the hierarchy that it is a child of. The current drawcall (if visible) is rendered as a green
circle and there are two vertical bars - red for the current mouse highlight, and light grey for
the current drawcall, so it is visible regardless of the hierarchy expansion.</para>
<para>When the currently selected texture is used in the frame, each drawcall that references
it draws a marker below the bar. A purple marker indicates that the drawcall at that point is
writing to the texture, and a green marker indicates that it is reading. If the markers are
too close together they will space themselves to be readable and will not necessarily line up
to a particular drawcall unless you zoom in.</para>
<para>This can be a very useful tool to trace data through a frame, as well as highlighting potential
redundancy or errors if a target is being written to where it should not.</para>
</content>
</section>
<section address="PipelineState">
<title>Pipeline State</title>
<content>
<mediaLink><image xlink:href="QuickStart7"/></mediaLink>
<para>More details can be found on the <link xlink:href="A44E2304-6C11-451D-89C4-0A7397F5D1C6" /> page.</para>
<para>The Pipeline State window is perhaps the most detailed but also the simplest to understand.
This window simply lists every stateful aspect of the graphics pipeline and what value or object
is present at the current event.</para>
<para>By default the pipeline will not contain empty or unused entries - i.e. if a shader only reads
from resources 0 and 1, even if something is bound to slot 2 it will not be displayed. Likewise say
slots 3-128 are empty - they will also not
be displayed. This behaviour can be modified by the <command>Show Disabled Items</command> and
<command>Show Empty Items</command> toggles on the toolbar. Show Disabled will show slot 2 even if
the shader does not read from it. Show Empty will show slots 3-128.</para>
<para>The most important thing to note is that most things in the sections for each pipeline stage
can be expanded to view in more detail. Look for the Go Icon
<mediaLinkInline><image xlink:href="GoArrow"/></mediaLinkInline> to indicate that a more detailed
view is available. Typically this will mean for shaders the shader source/disassembly will be opened, for
texture-type resources the texture viewer will open a new tab for that resource, and for buffers it will
open either the Mesh Output window, a raw view of that buffer, or a popup with the constant contents -
depending on where the buffer is bound.
</para>
<para>For more details, check out the how-to: <link xlink:href="7A620DF5-332E-44CA-8FD5-9E47A9C4CC3E" /></para>
</content>
</section>
<section address="MeshOutput">
<title>Mesh Output</title>
<content>
<mediaLink><image xlink:href="QuickStart8"/></mediaLink>
<para>More details can be found on the <link xlink:href="C48DED3E-3303-4A82-8F58-3D39766C48E7" /> page.</para>
<para>Mesh Output allows you to inspect the geometry data as it passes through the pipeline.
Both raw data in a grid view and 3D inspection is possible. The tabs in the preview window allow you to
choose at which part of the pipeline you'd like to visualise the data.</para>
<para>When in the VS Input tab (or VS Output if tessellating), you can select to solid shader the object with
either flat shading or a UV Co-ordinate/Colour shading, which can be useful for visually inspecting
the geometry data.</para>
<para>When in the VS/GS/DS Output tabs there is the option to show the context leading up to this
drawcall by showing everything since the last clear. The default view (which you can reset to with the
reset button <mediaLinkInline><image xlink:href="UndoArrow"/></mediaLinkInline>) shows the camera at the
view origin looking out through the viewport. By default the output attempts to guess a perspective matrix
from the output data, but this can be refined or changed to an orthographic view by opening up the options
<mediaLinkInline><image xlink:href="cog"/></mediaLinkInline> and entering more accurate or corrected values.</para>
</content>
</section>
</sections>
</content>
</section>
<section address="Closing">
<title>Closing Notes</title>
<content>
<para>
Obviously what you accomplish in the program will vary a lot by what you need to investigate, but
hopefully this gives you an overview of the functionality available. There are many more detailed
features that are available, and the rest of this help will aid you in finding those.
</para>
<para>
It is probably a good idea to check out the <link xlink:href="e2878f27-34d3-458a-9077-d0fb32c16829" />
page which lists several useful notes that aren't obvious but might save you a lot of time.
</para>
</content>
</section>
</developerConceptualDocument>
</topic>
docs/Resources.items
+12
View File
@@ -0,0 +1,12 @@
<?xml version="1.0" encoding="utf-8"?>
<content xml:space="preserve">
<item id="fb_alias" />
<item id="fb_body" />
<item id="fb_footer_text" />
<item id="fb_footer_text_to" />
<item id="fb_footer_to" />
<item id="fb_headerFeedBack" />
<item id="fb_product" />
<item id="fb_text" />
<item id="fb_topic" />
</content>
docs/TheFuture.aml
+61
View File
@@ -0,0 +1,61 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="632271c3-3d72-4360-b4a0-dc570fcd541e" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<para>
This is a list of all features that are planned to be added at some point.
Probably none of them have timelines or estimates yet, and they are in no particular order.
I just would like to add them eventually. It's mostly here for interest,
and for reference if you have a new feature request - it might be on here already!
</para>
<para>
Also note that none of these features are guaranteed. In an ideal world they would all
happen but since work hasn't started on any of them some may turn out to be impractical
or delayed indefinitely.
</para>
</introduction>
<section address="Source">
<title>Source Code Release</title>
<content>
<para>
At current the source is not available, but the plan is to release the code onto github
at some point in the future, hopefully soon. Primarily it will be once RenderDoc has stabilised
and there is a good feature set available, as opposed to the very basic features currently
available.
</para>
</content>
</section>
<section address="Features">
<title>Planned Features</title>
<content>
<para>
<list class="bullet">
<listItem><para>Debugging of all shader stages.</para></listItem>
<listItem><para>HLSL Debugging.</para></listItem>
<listItem><para>Mesh display after HS stage.</para></listItem>
<listItem><para>Perfkit/PerfHUD integration for vendor-specific detailed
performance timers.</para></listItem>
<listItem><para>Multiple frames in a single capture/logfile.</para></listItem>
<listItem><para>D3D9 support.</para></listItem>
<listItem><para>OpenGL support.</para></listItem>
<listItem><para>Linux/OS X support.</para></listItem>
<listItem><para>Diffing events in a given frame.</para></listItem>
<listItem><para>Modifying the pipeline on the fly to change state.</para></listItem>
<listItem><para>Highlighting redundant state-setting.</para></listItem>
<listItem><para>Tracking the dependencies or dependants of a given drawcall.</para></listItem>
<listItem><para>Exposing an API to applications so they can give more details or annotation,
more tightly integrating with the app itself.</para></listItem>
<listItem><para>A low-resource mode so RenderDoc can be left on by default whenever running
an app, so it's always available if a bug appears.</para></listItem>
<listItem><para>Attaching to an already-running application.</para></listItem>
</list>
</para>
</content>
</section>
<relatedTopics>
<link xlink:href="86b8bce7-b7cd-4b10-aa61-706463d14fe0" />
</relatedTopics>
</developerConceptualDocument>
</topic>
docs/TipsNTricks.aml
+70
View File
@@ -0,0 +1,70 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="e2878f27-34d3-458a-9077-d0fb32c16829" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<para>
This page is a random hodge-podge of different tips and tricks that might not be obvious
and aren't practical to make clear in the UI - e.g. keyboard shortcuts, edge cases
and suchlike.
</para>
</introduction>
<section address="Section1">
<title>Tips &amp; Tricks</title>
<content>
<para>
<list class="ordered">
<listItem><para>File associations for .rdc and .cap files can be set up in the installer or in the
<link xlink:href="B1826EEE-2ED1-44E4-8202-37CD8B3FEEB5" />. These allow automatic
opening of capture logs or capture settings files directly from files.</para>
<alert class="note">
<para>These associations must be re-created if RenderDoc is moved to another folder.</para>
</alert>
</listItem>
<listItem><para>If a .cap file is saved with the "auto-start" option enabled, launching RenderDoc
by opening this file will cause RenderDoc to automatically trigger a capture with the given options.
This is useful for saving a common path &amp; set of options that you regularly re-run.</para>
<para>For more information check out the <link xlink:href="D1612D25-C8BA-4349-9CE2-1E57D60F98C5" />
page.</para></listItem>
<listItem><para>If you'd like to see the geometry data with each component separated out and formatted,
either open "Mesh Output" under the window menu, or click the Go Arrow <mediaLinkInline><image xlink:href="GoArrow"/></mediaLinkInline>
on the input layouts in the <link xlink:href="A44E2304-6C11-451D-89C4-0A7397F5D1C6" />.</para></listItem>
<listItem><para>Right clicking on one of the channel buttons in the texture viewer
(R, G, B, A) will either select only that channel, or if it's already the only one
selected it will select all of the others. This is useful e.g. to toggle between viewing
RGB and alpha, or for looking at individual channels in a packed texture or render target.</para></listItem>
<listItem><para>Similarly, right-clicking on the 'auto-fit' button
<mediaLinkInline><image xlink:href="wand"/></mediaLinkInline> will auto-fit whenever the texture
or event changes, so that the visible range is maintained as you move through the frame. This can be useful
if jumping between places where the visible range is very different.</para></listItem>
<listItem><para>You can double click on a thumbnail in the texture viewer to open a
<link xlink:href="32C47E20-0FA2-4F52-B33A-4440EBCCBCE4">locked texture</link> tab</para></listItem>
<listItem><para>You can close tabs by middle clicking on them.</para></listItem>
<listItem><para>You can trigger a capture from code. renderdoc.dll exports a function for this
purpose:
<code language="cpp">
typedef void (__cdecl *pRENDERDOC_TriggerCapture)();
// At init
HMODULE renderdoc = GetModuleHandle(_T("renderdoc.dll"));
pRENDERDOC_TriggerCapture triggerFunc =
(pRENDERDOC_TriggerCapture)GetProcAddress(renderdoc, "RENDERDOC_TriggerCapture");
// When you wish to trigger the capture
triggerFunc();
</code>
</para>
<para>The next <codeInline>Swap()</codeInline> after this call will begin the captured frame,
and the <codeInline>Swap()</codeInline> after that will end it (barring complications)</para>
</listItem>
<listItem><para>When you have right clicked to select a pixel in the texture viewer, you can
perform precise refinements with the arrow keys to nudge the selection in each direction.</para></listItem>
<listItem><para>To get API debug or error messages, enable "Create Debug Device" when capturing
then check out the <link xlink:href="1f098896-0e60-485a-b879-900a4a320b80" /> window.</para></listItem>
<listItem><para>More coming soon hopefully :).</para></listItem>
</list>
</para>
</content>
</section>
</developerConceptualDocument>
</topic>
docs/Tokens.tokens
+8
View File
@@ -0,0 +1,8 @@
<?xml version="1.0" encoding="utf-8"?>
<content xml:space="preserve" xmlns:ddue="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<item id="Baldur Contact"><ddue:externalLink xmlns:ddue="http://ddue.schemas.microsoft.com/authoring/2003/5">
<ddue:linkText>RenderDoc Contact</ddue:linkText>
<ddue:linkAlternateText>RenderDoc @ Crytek</ddue:linkAlternateText>
<ddue:linkUri>mailto:renderdoc@crytek.com?subject=RenderDoc%20feedback</ddue:linkUri>
</ddue:externalLink></item>
</content>
docs/Windows/APIInspector.aml
+55
View File
@@ -0,0 +1,55 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="D78CE10E-0206-4DFC-B5CA-29F98D448235" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<autoOutline />
<para>Although not the most complex part of the RenderDoc's UI, this page details
the features and functionality of the API Inspector.</para>
</introduction>
<section address="elems">
<title>UI Elements</title>
<content>
<para>The API Inspector is divided into two sections - the top section is the most common,
detailing all of the API calls leading up to and including the current drawcall.
The special case for this is the end of the frame where there may not be a final drawcall
but the API Inspector lists the API calls that preceded the final flip of the backbuffer
that marks the end of RenderDoc's captured frame.</para>
<para>The bottom section is less common but shows the callstack from user code into the
API entry point, if such a callstack is available and the symbols are resolved. For more
information check out the page on <link xlink:href="14048aef-0053-4e38-98cd-541f4d15d12e" />.</para>
</content>
</section>
<section address="api">
<title>API Calls</title>
<content>
<para>This section lists the series of API calls made between the preceding drawcall
and the currently selected drawcall. The current drawcall is always the last element
in this list and is highlighted in bold. By default it is also the selected element.</para>
<para>Each API call can be expanded to see the parameters that were passed to it, in the
form that they were serialised out to the log file.</para>
<mediaLink>
<caption placement="after" lead="API Calls">A list of API calls made up to the current draw.</caption>
<image xlink:href="APIList"/>
</mediaLink>
</content>
</section>
<section address="callstack">
<title>Callstack</title>
<content>
<para>The callstack section can be expanded by double clicking on the separator and
collapsed in the same way. Once open its size can be adjusted by clicking and dragging
on the separator.</para>
<para>This section will either show "No callstack available" or "Need to resolve symbols"
as appropriate when the callstacks aren't ready for display.</para>
<para>The callstack follows the currently selected API call in the other section, and will
update both as that selected call change and as the current event changes (as this implicitly
changes the API call selected to whichever the current drawcall is).</para>
<para>For more information see <link xlink:href="14048aef-0053-4e38-98cd-541f4d15d12e" /></para>
<mediaLink>
<caption placement="after" lead="Callstack">The callstack in user code where this API call was made.</caption>
<image xlink:href="CallstackPanel"/>
</mediaLink>
</content>
</section>
</developerConceptualDocument>
</topic>
docs/Windows/BufferViewer.aml
+122
View File
@@ -0,0 +1,122 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="C48DED3E-3303-4A82-8F58-3D39766C48E7" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<para>The buffer viewer has two reasonably distinct modes - the first rather
specialised to show meshes and mesh data as it passes through the pipeline.
The other shows a raw arbitrary buffer with a custom (and arbitrary) formatting.</para>
</introduction>
<section address="mesh">
<title>Mesh Viewer</title>
<content>
<para>The Mesh Viewer shows both the mesh data as well as a visual representation
of the mesh at different stages - pre VS, post VS, etc.</para>
<para>Each distinct point has a display that shows the mesh data, the format of which
is pulled from the relevant stage of the pipeline - shader input or output, or input
layout. You can choose to sync these views <mediaLinkInline><image xlink:href="arrow_join"/></mediaLinkInline>
as well as specify an offset which will stay consistent, so that you can see the same
row as you move between different events.</para>
<para>Below this is a 3D view which will show one stage at any given time, and can be
switched with the tabs above it. There are two control schemes for viewing the 3D mesh -
Arcball which is the default for pre-transform (VS in), and WASD controls which is the
default for post-transform (VS out). You can switch between these at any time with
the dropdown on the toolbar above the mesh view.</para>
<alert class="note">
<para>When tessellation is active, VS out behaves similarly to VS in as they are both
considered input data (rather than post-transform data).</para>
</alert>
<para>You can reset the camera to its default location with the reset button
<mediaLinkInline><image xlink:href="arrow_undo"/></mediaLinkInline>. For VS Input this
resets to an arcball at some radius from the object. For VS Output this resets to a view
from the projected eye.</para>
<para>You can also auto-fit the camera to the mesh for the VS Input mesh. The auto-fit
button <mediaLinkInline><image xlink:href="wand"/></mediaLinkInline> will fit the
camera to the axis-aligned bounding box of the mesh.</para>
<para>To be able to view the post-transform mesh in view-space, RenderDoc attempts to
guess the projection matrix and unprojects the output data.</para>
<para>By default the projection matrix is guessed as a standard perspective matrix.
Using the post-projection w and z values and the aspect ratio of the output targets
a reasonable approximation can be estimated. The FOV must be specified though - the
default is 90 but this can be refined by opening the options.</para>
<para>Opening the options <mediaLinkInline><image xlink:href="cog"/></mediaLinkInline>
you can specify the FOV used in the projection matrix. If you used an orthographic
matrix instead you can specify this - although this requires manual tuning of the
matrix parameters.</para>
<mediaLink>
<caption placement="after" lead="Options">The options pop-out of the buffer viewer.</caption>
<image xlink:href="BufferOptions"/>
</mediaLink>
<para>Also available in the options is a simple speed multiplier for the WASD controls,
to fine-tune how fast it moves to the dimensions of the mesh.</para>
<para>In the vertex input preview, you have the option to display the mesh with some solid
shading modes, not just as a wireframe mesh. When solid shading you can toggle the wireframe
on and off.</para>
<list class="bullet">
<listItem><para>Solid Colour simply displays a solid colour for each triangle.</para></listItem>
<listItem><para>Flat Shaded will perform basic flat lighting calculations based on triangle normals to give a better idea of the topology of the mesh.</para></listItem>
<listItem><para>TEXCOORD0 and COLOR0 will display the relevant input element, if detected in the mesh.</para></listItem>
</list>
<mediaLink>
<caption placement="after" lead="Preview">Previewing the uv co-ordinates as colour on the mesh.</caption>
<image xlink:href="SolidPreview"/>
</mediaLink>
</content>
</section>
<section address="buff">
<title>Raw Buffer Viewer</title>
<content>
<para>When opening a buffer as a raw display, sometimes a default layout will be specified
e.g. if available from shader reflection data. If not, the layout will default to 4
32bit unsigned integers.</para>
<para>This format can be refined and customised by entering a structure-like definition
into the text box at the bottom of the window. The given types are listed below, and
can be combined in hlsl-like fashion specifying n-wide vector elements.</para>
<para>In addition to this, you can specify a row offset which is useful in remaining
at the same row while watching the change in a buffer between different events, as well
as a byte offset to shift the data along from the start of the buffer (e.g. if what you
are interested in starts only part-way through the buffer but is not aligned along the
data stride you enter).</para>
<mediaLink>
<caption placement="after" lead="Buffer specification">Specifying a custom buffer format.</caption>
<image xlink:href="RawBuffer"/>
</mediaLink>
<para>Below are listed the basic types. You can append a number to each of these to make an N-wide
vector (e.g. ushort4 or float3). You can also specify matrices as float3x4. By default matrices
are column major, but you can change this by prepending row_major as you would in hlsl.</para>
<list class="bullet">
<listItem><para>uint - unsigned 32bit integer</para></listItem>
<listItem><para>bool - unsigned 32bit integer (this is the format for hlsl bools)</para></listItem>
<listItem><para>int - signed 32bit integer</para></listItem>
<listItem><para>ushort - unsigned 16bit integer</para></listItem>
<listItem><para>short - signed 16bit integer</para></listItem>
<listItem><para>ubyte - unsigned 8bit integer</para></listItem>
<listItem><para>byte - signed 8bit integer</para></listItem>
<listItem><para>double - 64bit floating point</para></listItem>
<listItem><para>float - 32bit floating point</para></listItem>
<listItem><para>half - 16bit floating point</para></listItem>
</list>
<para>There are also some non-hlsl types for displaying other formats which don't have a corresponding native
hlsl type</para>
<list class="bullet">
<listItem><para>unormb - 8bit unsigned normalised value</para></listItem>
<listItem><para>unormh - 16bit unsigned normalised value</para></listItem>
<listItem><para>unormf - 32bit unsigned normalised value</para></listItem>
<listItem><para>snormb - 8bit signed normalised value</para></listItem>
<listItem><para>snormh - 16bit signed normalised value</para></listItem>
<listItem><para>snormf - 32bit signed normalised value</para></listItem>
<listItem><para>uintten - 4 component unsigned integer format, packed as 10:10:10:2</para></listItem>
<listItem><para>unormten - 4 component unsigned normalised format, packed as 10:10:10:2</para></listItem>
</list>
</content>
</section>
</developerConceptualDocument>
</topic>
docs/Windows/CaptureDialog.aml
+219
View File
@@ -0,0 +1,219 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="D1612D25-C8BA-4349-9CE2-1E57D60F98C5" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<autoOutline />
<para>The Capture Dialog (which doubles as the attach-to-process dialog) is the
single point where programs are launched and logfiles are captured to disk.</para>
<para>After launching a capture a connection dialog will open to allow you to manage
and open any captures you take. See <link xlink:href="6f4dad92-3db3-448f-9f1a-79af65f74492" /> for more details.</para>
<alert class="note">
<para>NOTE: The Load Settings and Save Settings buttons on this dialog refer to loading and saving the set
of settings and options configured on this dialog. They do <legacyItalic>not</legacyItalic> refer to loading
and saving the logs produced from capturing - that is done from the File menu.</para>
</alert>
</introduction>
<section address="capturing">
<title>Capturing</title>
<content>
<para>To capture a program you simply need to provide the details of the application
to be launched.</para>
<para>The Program section of the dialog prompts for the executable to be launched,
the working directory, and any command-line arguments to be passed to the program.</para>
<mediaLink>
<caption placement="after" lead="Program Capture">Configuring and launching an exe directly from RenderDoc.</caption>
<image xlink:href="CapturePathCmdline"/>
</mediaLink>
<para>The "..." buttons next to the executable path and working directory can be used to
browse through the file system. By default if the working directory box is left empty
then the directory containing the executable will be used as the working directory.</para>
<para>When you are ready to capture simply click the <command>Capture</command> button in the bottom right.</para>
<para>If you wish to save these particular settings you can click <command>Save</command> to save them to a .cap file.
This .cap file can either be loaded in manually, accessed through the <command>Recent Captures</command> menu.
The .cap file can be associated with RenderDoc, and if so launching RenderDoc from this file will automatically load
the capture settings. If "Auto start" is checked then double clicking on the .cap file will immediately trigger
a capture with the given settings.</para>
<alert class="note">
<para>The process will be launched with the same permissions and by the same user as RenderDoc was launched.
If your process requires specific permissions (such as administrator permissions) you will need to
launch RenderDoc with these permissions.</para>
</alert>
</content>
</section>
<section address="attaching">
<title>Inject into Process</title>
<content>
<para>When invoked through <command>Inject into Process</command> the capture dialog modifies itself
to give a list of processes running on the target system.</para>
<para>A list of processes is fetched once when the dialog is opened, but this can be refreshed
by clicking on the refresh button below the list. Select the process you would like to attach to
and click Attach.</para>
<mediaLink>
<caption placement="after" lead="Attaching">Attaching to an already-running process via RenderDoc.</caption>
<image xlink:href="Attaching"/>
</mediaLink>
<alert class="caution">
<para>The process <legacyBold>must not</legacyBold> have invoked or initialised the API to be used,
as this will be too late for RenderDoc to hook and capture it. At best RenderDoc will not capture, at worst
it may cause crashes or undefined behaviour. Only attach to processes you can guarantee are early
enough in their initialisation that they have not used the graphics API.</para>
</alert>
</content>
</section>
<section address="options">
<title>Capture Options</title>
<content>
<para>Several capture options are available to configure how RenderDoc works while injected into
the target application, as well as affecting the resultant captures. Most of these will work
fine with the defaults, but some may need to be configured to your tastes.</para>
<para>Some of these options are API-specific and will not apply when using other APIs than
they are intended, although most are generic in some fashion - the exact implementation may
vary by API.</para>
<table>
<tableHeader>
<row>
<entry><para>Name</para></entry>
<entry><para>Explanation</para></entry>
<entry><para>Default Setting</para></entry>
</row>
</tableHeader>
<row>
<entry><para>Allow Fullscreen</para></entry>
<entry><para>Allow Fullscreen simply means that RenderDoc will not interfere with any attempt
by the application to switch into an exclusive fullscreen video mode. While debugging sometimes
this can be awkward as you may wish to quickly switch to your debugger or another program.</para>
<para>If this option is unchecked, RenderDoc will attempt to modify any such attempt to an equivalent
windowed mode.</para></entry>
<entry><para>Enabled</para></entry>
</row>
<row>
<entry><para>Allow VSync</para></entry>
<entry><para>Allow VSync functions very similarly to Allow Fullscreen. When disabled, RenderDoc
will prevent any attempt to VSync by the application. This can be useful given that there is a
certain degree of inevitable overhead from running with RenderDoc and VSync can amplify that.</para></entry>
<entry><para>Enabled</para></entry>
</row>
<row>
<entry><para>Seconds Delay</para></entry>
<entry><para>This option causes RenderDoc to stall for a defined number of seconds immediately after
launching the process. Most commonly this is used so that you can launch a program in RenderDoc
and immediately attach a traditional debugger before any significant code is executed.</para>
<para>This can be useful e.g. when early initialisation needs to be debugged.</para></entry>
<entry><para>0 Seconds (Disabled)</para></entry>
</row>
<row>
<entry><para>Collect Callstacks</para></entry>
<entry><para>This option will cause RenderDoc to save a callstack from user code into the API at every
API call during the frame being captured. This can then be resolved later and used to determine where
the application is calling each API call. More details can be found in:
<link xlink:href="14048aef-0053-4e38-98cd-541f4d15d12e" />.</para></entry>
<entry><para>Disabled</para></entry>
</row>
<row>
<entry><para>Only Drawcall Callstacks</para></entry>
<entry><para>This option modifies the above capturing of callstacks to only be saved for drawcall-type
API calls. This can reduce the CPU load, as well as file-size and memory overhead of capturing callstacks
for every API call which may not be desired. Only valid if Collect Callstacks is enabled.</para></entry>
<entry><para>Disabled</para></entry>
</row>
<row>
<entry><para>Create Debug Device</para></entry>
<entry><para>Create Debug Device causes RenderDoc to enable the API's built-in debugging, and where
possible serialise this out and include it in the logfile for later inspection. e.g. on D3D11 this will
activate the D3D debug layer and save out any messages, which can later be viewed in the
<link xlink:href="1f098896-0e60-485a-b879-900a4a320b80" /> window.
The overhead from enabling this option is largely the same as the overhead of enabling the
debug device without RenderDoc involved.</para></entry>
<entry><para>Disabled</para></entry>
</row>
<row>
<entry><para>Cache State Objects</para></entry>
<entry><para>In D3D11 creating a state object with the same descriptor as one that already exists
will simply return a pointer to the existing state object, with a reference count added. Given that
creation and destruction in RenderDoc has a certain overhead, when this option is enabled RenderDoc will
hold onto a reference to freed state objects in case they are likely to be re-allocated soon after.</para>
<para>This will reduce churn and overhead with minimal impact to the application, and it's recommended to
leave this enabled unless you have specific problems or want to remove this optimisation.</para></entry>
<entry><para>Enabled</para></entry>
</row>
<row>
<entry><para>Hook into Children</para></entry>
<entry><para>This option causes RenderDoc to hook into CreateProcess and intercept any calls to it from
the target application. When this option is enabled those child processes will be injected with RenderDoc
in the same way as the parent - which can be useful if you must launch your program through a launcher
or level of indirection and still wish to use RenderDoc with one of the child processes.</para></entry>
<entry><para>Disabled</para></entry>
</row>
<row>
<entry><para>Save All Initials</para></entry>
<entry><para>RenderDoc will attempt to save overhead and particularly logfile size by omitting the initial
contents of 2D textures that it believes will be unnecessary. Typically these textures are render targets
or depth buffers that will be written to and fully covered in the course of the frame before they are
ever read, and so saving their initial contents is unnecessary.</para>
<para>In some cases this detection will be wrong, such as targets that are partially written such as pools,
or if a target is accumulated to via blend modes. When this is the case, enabling Save All Initials will
force RenderDoc to save these textures regardless of any auto-detection.</para>
<alert class="note">
<para>Multisampled textures will not have their initial contents saved regardless of the value of
this option.</para>
</alert>
</entry>
<entry><para>Disabled</para></entry>
</row>
<row>
<entry><para>Ref All Resources</para></entry>
<entry><para>One method RenderDoc uses to keep logfile sizes down is to only include the referenced
dependencies of a frame within a capture. This means that even if 100 textures are allocated and present,
if 50 of them are never bound to the pipeline or otherwise referenced then they will not be included
in the logfile. Enabling this option will cause RenderDoc to include all live resources at the time of
capture regardless of whether they are used or not.</para></entry>
<entry><para>Disabled</para></entry>
</row>
<row>
<entry><para>Capture All Cmd Lists</para></entry>
<entry><para>By default RenderDoc only begins capturing when you hit the capture key - any commands issued
before this point are not available and so if a deferred command list was created before you hit capture
and replayed after, it would not be available and RenderDoc would have to fall back and capture again in the
hopes that next frame everything will be available.</para>
<para>If the application creates a command list early and replays it indefinitely without recreating it,
RenderDoc will essentially have missed its chance to capture it by the time you hit the capture key. Enabling
this option will cause RenderDoc to pre-emptively capture all command lists just in case they are used.</para>
<alert class="caution">
<para>This may have a significant performance hit.</para>
</alert>
</entry>
<entry><para>Disabled</para></entry>
</row>
<row>
<entry><para>Auto start</para></entry>
<entry><para>This option is slightly different from the others in that it doesn't change anything for an
immediate capture. When a .cap settings file is saved with the details of a particular capture, if this
option is enabled then loading a .cap file from the command line (i.e. most commonly from a file association)
will trigger a capture as soon as RenderDoc loads. This is useful for saving a common capture setting and
running it with just one click.</para></entry>
<entry><para>Disabled</para></entry>
</row>
<row>
<entry><para>Queue Capture of Frame</para></entry>
<entry><para>This option allows you to queue up a precise capture of a given frame number after the program has started.</para></entry>
<entry><para>Disabled</para></entry>
</row>
</table>
</content>
</section>
<relatedTopics>
<link xlink:href="f2f4fbfa-6127-4831-84e7-07309bd85908" />
<link xlink:href="14048aef-0053-4e38-98cd-541f4d15d12e" />
</relatedTopics>
</developerConceptualDocument>
</topic>
docs/Windows/DebugMessages.aml
+28
View File
@@ -0,0 +1,28 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="1f098896-0e60-485a-b879-900a4a320b80" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<para>The Debug Messages window shows messages from the API including warnings about performance
issues or concerns about potential hazards, as well as errors on invalid use of the API.</para>
</introduction>
<section address="capture">
<title>Capturing with debug messages included</title>
<content>
<para>To include these debug messages in a log, check on the "Create Debug Device" option in
the capture options. For more information see <link xlink:href="D1612D25-C8BA-4349-9CE2-1E57D60F98C5" />.</para>
</content>
</section>
<section address="window">
<title>Debug Messages</title>
<content>
<para>This window is fairly simple. Each message retrieved from the api will be listed on
its own row showing the event ID that triggered the message, along with a severity and category.</para>
<para>Double clicking on any row will take you to the corresponding event ID in the event browser.</para>
<mediaLink>
<caption placement="after" lead="Debug Messages">The Debug Messages window showing some API messages.</caption>
<image xlink:href="DebugMessages"/>
</mediaLink>
</content>
</section>
</developerConceptualDocument>
</topic>
docs/Windows/EventBrowser.aml
+129
View File
@@ -0,0 +1,129 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="16D2B42E-65B0-40D1-AB91-AD2B156F5DA0" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<para>The Event Browser is the primary method of browsing the frame and selecting
different drawcalls. It displays the user-annotated hierarchical display of
sections.</para>
</introduction>
<section address="annotation">
<title>Annotating your frame</title>
<content>
<para>The Event Browser becomes most useful when the application has user-defined
annotations of sections and subsections of the frames, to allow for a more logical
and ordered browsing of the frame.</para>
<para>Doing this is API and platform specific. Example code for D3D11 is included
below, using the D3DPERF library that is defined in d3d9.lib, which can still be used
in D3D11. (The newer ID3DUserDefinedAnnotation API is also supported).</para>
<code language="cpp">
D3DPERF_BeginEvent(0xffffffff, L"Start of example");
D3DPERF_BeginEvent(0xff00ff00, L"Sub section");
// events inside the subsection
D3DPERF_EndEvent();
// events outside the subsection
D3DPERF_EndEvent();
</code>
<para>This will generate a section of the frame with a subsection that includes some events,
and then some further events that are siblings of the subsection.</para>
</content>
</section>
<section address="columns">
<title>Selecting available columns</title>
<content>
<para>By default, the columns in the event browser are EID and Name. Name cannot be removed as
it contains the tree, but otherwise the columns can be customised both to hide/display or
reorder and resize.</para>
<para>To select which columns should be visible, right click the header or click the
<mediaLinkInline><image xlink:href="timeline_marker"/></mediaLinkInline> select columns button.</para>
<para>To rearrange the columns simply click and drag on the header.</para>
<alert class="note">
<para>Note that when timing drawcalls the duration column will automatically be added to display the data.</para>
</alert>
</content>
</section>
<section address="columns">
<title>Timing drawcalls</title>
<content>
<para>To time the GPU duration of each drawcall, click the timer button <mediaLinkInline><image xlink:href="time"/></mediaLinkInline></para>
<para>This will automatically run a process to get the time of each drawcall and display it in the duration column,
which will be added if necessary.</para>
<para>You can configure which time unit is used for the duration column on the fly in the
<link xlink:href="B1826EEE-2ED1-44E4-8202-37CD8B3FEEB5" /></para>
</content>
</section>
<section address="browsing">
<title>Browsing the frame</title>
<content>
<para>The event browser is primarily intended as a tool to browse through the frame. Events
are listed as entries in the browser and the hierarchical labels mentioned above become
tree nodes.</para>
<para>The currently selected event is highlighted and indicated with a green flag
<mediaLinkInline><image xlink:href="GreenFlag"/></mediaLinkInline>. This is the event
that RenderDoc is inspecting and is reflected in all the other windows of the UI.</para>
<mediaLink>
<caption placement="after" lead="Current Event">The Event browser showing several sections and the current event.</caption>
<image xlink:href="QuickStart4"/>
</mediaLink>
<para>The EID column indicates the event ID of the drawcall listed. Event IDs are
assigned starting from 1 and increase every time an API call is made - for this
reason drawcall EIDs are not necessarily contiguous.</para>
<para>Simply clicking on a different event will select it as current, and selecting
a parent node with some child events will act as if the final child is selected -
in other words selecting a node with several children will show the results of all
children having happened.</para>
<para>You can also use keyboard shortcuts to browse through the frame. Pressing up or
down arrow key will move up and down through the visible elements, skipping over any
sections which are collapsed. These keys will move into and out of a sub-section into
the next sibling afterwards - essentially going straight up and down as if there is
not a tree and it is a straight list.</para>
<para>The left and right arrows go into and out of hierarchy levels. When within a level
pressing left will jump to the parent node of the current level. Pressing left again
will collapse that node, and so on. Pressing right will (if on a node with children)
expand that node.</para>
</content>
</section>
<section address="searching">
<title>Searching and Jumping</title>
<content>
<para>There are two other controls available in the Event Browser to aid in navigating
the frame.</para>
<para>Pressing <command>Ctrl-F</command> will open the find-event toolbar
<mediaLinkInline><image xlink:href="find"/></mediaLinkInline>. This toolbar
allows you to type in a partial text filter that will be matched against both labels
and drawcall events. The find will be executed when you press enter, although you can then
adjust the text and re-search if you wish.</para>
<para>If the event found lies inside an unexpanded section, the sections will be
expanded until the matching event is visible.</para>
<para>Matching events will be highlighted with a find icon
<mediaLinkInline><image xlink:href="find"/></mediaLinkInline>, and pressing
enter repeatedly will jump between matching events.</para>
<para>The find toolbar isn't dismissed until you press escape in the text box, or click the close button
<mediaLinkInline><image xlink:href="cross"/></mediaLinkInline>.</para>
<para>You can also jump up and down between find results with the
previous <mediaLinkInline><image xlink:href="stepprev"/></mediaLinkInline>
and next <mediaLinkInline><image xlink:href="stepnext"/></mediaLinkInline>
buttons.</para>
<mediaLink>
<caption placement="after" lead="Highlighted Results">The results of a find are highlighted with an icon.</caption>
<image xlink:href="FindResults"/>
</mediaLink>
<para>Pressing <command>Ctrl-G</command> will open the jump to EID toolbar. This allows
you to type in an EID and jump straight there, expanding nodes as necessary. If the EID
typed doesn't exist in the list of drawcalls, the closest matching EID will be jumped
to.</para>
<para>When you hit enter to jump to an EID, the toolbar closes and if you wish to jump again
you must press <command>Ctrl-G</command> again</para>
<mediaLink>
<caption placement="after" lead="Jumping around">The jump-to-EID toolbar prompting for an event.</caption>
<image xlink:href="JumpEID"/>
</mediaLink>
</content>
</section>
</developerConceptualDocument>
</topic>
docs/Windows/LiveCapture.aml
+108
View File
@@ -0,0 +1,108 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="6f4dad92-3db3-448f-9f1a-79af65f74492" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<autoOutline />
<para>The Live capture window opens up when you launch a capture of a program, as well as when
you attach to an existing program.</para>
</introduction>
<section address="attaching">
<title>Attaching to an existing instance</title>
<content>
<para>
After you've launched a program through RenderDoc and its hooks are added you can freely disconnect
(by closing the live capture window) or close the main UI. You can then connect to this again later,
either from the same computer or another computer connecting over the network.
</para>
<para>
To connect to an existing hooked program, select Attach to Running Instance from the File menu. This opens up
the attach window that allows you to select a remote host to connect to. By default localhost is already
in the list, but you can add and remove other hosts.
</para>
<alert class="caution">
<para>Please note that none of the connections RenderDoc makes or uses are encrypted or protected, so if this is a
concern you should look into securing the connections by hand.</para>
</alert>
<mediaLink>
<caption placement="after" lead="Remote Hosts">Attaching to a running instance either locally or remotely.</caption>
<image xlink:href="AttachInstance"/>
</mediaLink>
<para>
When the window opens, when you add a new host or when you click refresh then the hosts will be queried
across the network to see if a connection exists. While this is in progress the host will be listed in
italics and with a busy icon.
</para>
<para>
Once a host has been scanned, if any instances are found then that host can be expanded to see the list, and
details are listed about each instance. The name is OS-dependent but is usually the executable name. The API
name is listed, as well as the username of any user that is already connected.
</para>
<para>
When you click connect, a live capture window will be opened up - just the same as the window that is automatically
opened when you start a program. Any captures that have already been made before you connect will then populate.
</para>
<alert class="note">
<para>If you connect to a running instance, any existing user will be kicked off. Just seeing the instances running on
a host will not.</para>
</alert>
</content>
</section>
<section address="multicap">
<title>Capture Connection window</title>
<content>
<para>
When a capture is launched (or attached to) the connection window is opened in the main UI. If you
end up only taking one capture and closing the program afterwards the connection window will automatically
close - likewise if you take no captures at all. These cases don't need the management options the connection
window provides.
</para>
<para>
In addition to managing captures that have been taken, you can also trigger a capture (optionally with a
countdown timer).
</para>
<mediaLink>
<caption placement="after" lead="Connection Window">Viewing multiple captures taken in a program.</caption>
<image xlink:href="MultipleCaptures"/>
</mediaLink>
<para>
In this example we have a connection window open to the CascadedShadowMaps11 sample from the DirectX SDK.
Two captures have been made and we can see their thumbnails to help distinguish between them. This is visible
at any point, regardless of whether you have close the program or not - you can simply switch back to RenderDoc
while it's running.
</para>
<alert class="note">
<para>Note, if you have remotely connected you will need to wait while the captures copy across the network
to your PC, after which point everything behaves the same as a local capture.</para>
</alert>
<para>
From here you can save these captures out - as currently they are only temporary copies that will be
cleaned up on close. You can also manually delete any capture you wish to discard.
</para>
<para>
Double clicking on any capture will close any current open capture in the RenderDoc UI, and open up that
capture for inspection. You may also right click or use the drop-down menu on the open button to
launch a new instance of RenderDoc for viewing the log. This is mostly useful if you want to compare two
captures side-by-side easily.
</para>
<mediaLink>
<caption placement="after" lead="New instance">Launch new RenderDoc instance to open this capture.</caption>
<image xlink:href="OpenCapNewInstance"/>
</mediaLink>
</content>
</section>
</developerConceptualDocument>
</topic>
docs/Windows/Options.aml
+173
View File
@@ -0,0 +1,173 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="B1826EEE-2ED1-44E4-8202-37CD8B3FEEB5" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<autoOutline />
<para>The options window contains various advanced or niche settings that configure
the analysis UI.</para>
</introduction>
<section address="options">
<title>Options</title>
<content>
<para>Below each tab of the options window is detailed with explanations of the
given settings.</para>
<para>Some settings may not be saved until the application is closed, although
most will come into immediate effect.</para>
<para>The settings are contained in <codeInline>%APPDATA%\RenderDoc\UI.config</codeInline> if you wish to
back up or reset these settings.</para>
</content>
</section>
<section address="general">
<title>General options</title>
<content>
<table>
<tableHeader>
<row>
<entry><para>Name</para></entry>
<entry><para>Explanation</para></entry>
<entry><para>Default Setting</para></entry>
</row>
</tableHeader>
<row>
<entry><para>Associate .rdc with RenderDoc</para></entry>
<entry><para>This button will elevate RenderDoc to administrator privileges temporarily, and
associate the .rdc file extension with RenderDoc. After doing this double clicking any .rdc file
will open it in a new instance of RenderDoc.</para></entry>
<entry><para></para></entry>
</row>
<row>
<entry><para>Associate .cap with RenderDoc</para></entry>
<entry><para>This button will elevate RenderDoc to administrator privileges temporarily, and
associate the .cap file extension with RenderDoc. After doing this double clicking any .cap file
will open a new instance of RenderDoc and show the capture dialog with the settings contained inside.</para>
<para>If the setting "Auto Start" is enabled, RenderDoc will then immediately trigger a capture of
the target executable.</para></entry>
<entry><para></para></entry>
</row>
<row>
<entry><para>Minimum decimal places on float values</para></entry>
<entry><para>Defines the smallest number of decimal places to display on a float, padding with
0s.</para>
<para>Examples:</para>
<para>With a value of 2, <codeInline>0.1234f</codeInline> will be displayed as <math>0.1234</math></para>
<para>With a value of 2, <codeInline>1.0f</codeInline> will be displayed as <math>1.00</math></para>
<para>With a value of 6, <codeInline>0.1234f</codeInline> will be displayed as <math>0.123400</math></para>
<para>With a value of 6, <codeInline>1.0f</codeInline> will be displayed as <math>1.000000</math></para></entry>
<entry><para>2</para></entry>
</row>
<row>
<entry><para>Maximum significant figures on decimals</para></entry>
<entry><para>Defines the most significant figures to display after the decimal place on
floating point numbers.</para>
<para>Examples:</para>
<para>With a value of 5, <codeInline>0.123456789f</codeInline> will be displayed as <math>0.12345</math></para>
<para>With a value of 5, <codeInline>1.0f</codeInline> will be displayed as <math>1.00</math></para>
<para>With a value of 10, <codeInline>0.123456789f</codeInline> will be displayed as <math>0.123456789</math></para>
<para>With a value of 10, <codeInline>1.0f</codeInline> will be displayed as <math>1.00</math></para></entry>
<entry><para>5</para></entry>
</row>
<row>
<entry><para>Negative exponential cutoff value</para></entry>
<entry><para>Any floating point numbers that are below <math>E-v</math> for this value <math>v</math>
will be displayed in scientific notation rather than as a fixed point decimal.</para>
<para>Examples:</para>
<para>With a value of 5, <codeInline>0.1234f</codeInline> will be displayed as <math>0.1234</math></para>
<para>With a value of 5, <codeInline>0.000001f</codeInline> will be displayed as <math>1.0E-6</math></para>
<para>With a value of 10, <codeInline>0.1234f</codeInline> will be displayed as <math>0.1234</math></para>
<para>With a value of 10, <codeInline>0.000001f</codeInline> will be displayed as <math>0.000001</math></para></entry>
<entry><para>5</para></entry>
</row>
<row>
<entry><para>Positive exponential cutoff value</para></entry>
<entry><para>Any floating point numbers that are larger than <math>E+v</math> for this value <math>v</math>
will be displayed in scientific notation rather than as a fixed point decimal.</para>
<para>Examples:</para>
<para>With a value of 7, <codeInline>8000.5f</codeInline> will be displayed as <math>8005.5</math></para>
<para>With a value of 7, <codeInline>123456789.0f</codeInline> will be displayed as <math>1.2345E8</math></para>
<para>With a value of 2, <codeInline>8000.5f</codeInline> will be displayed as <math>8.0055E3</math></para>
<para>With a value of 2, <codeInline>123456789.0f</codeInline> will be displayed as <math>1.2345E8</math></para></entry>
<entry><para>7</para></entry>
</row>
<row>
<entry><para>Allow periodic anonymous update checks</para></entry>
<entry><para>Every couple of days RenderDoc will send a single web request to a server to see if a new version
is available and let you know about it. The only information transmitted is the version of RenderDoc that is running.</para>
<para>If you would prefer RenderDoc does not ever contact an external server, disable this checkbox. If you do this it's
recommended that you manually check for updates as new versions will be made available regularly with bugfixes.</para></entry>
<entry><para>Enabled</para></entry>
</row>
</table>
</content>
</section>
<section address="texture">
<title>Texture Viewer options</title>
<content>
<table>
<tableHeader>
<row>
<entry><para>Name</para></entry>
<entry><para>Explanation</para></entry>
<entry><para>Default Setting</para></entry>
</row>
</tableHeader>
<row>
<entry><para>Reset Range on changing selection</para></entry>
<entry><para>When changing texture from one to another, when this option is enabled the range
control will reset itself to [0, 1]. This will happen between any two textures, and going back
and forth between two textures will also reset the range.</para></entry>
<entry><para>Disabled</para></entry>
</row>
</table>
</content>
</section>
<section address="shader">
<title>Shader Viewer options</title>
<content>
<table>
<tableHeader>
<row>
<entry><para>Name</para></entry>
<entry><para>Explanation</para></entry>
<entry><para>Default Setting</para></entry>
</row>
</tableHeader>
<row>
<entry><para>Rename disassembly registers</para></entry>
<entry><para>This option tries to make the disassembly of shaders easier to read by substituting
variable names where available in for constant register names.</para></entry>
<entry><para>Enabled</para></entry>
</row>
</table>
</content>
</section>
<section address="shader">
<title>Event Browser options</title>
<content>
<table>
<tableHeader>
<row>
<entry><para>Name</para></entry>
<entry><para>Explanation</para></entry>
<entry><para>Default Setting</para></entry>
</row>
</tableHeader>
<row>
<entry><para>Time unit used for event browser timings</para></entry>
<entry><para>This option allows you to select the unit that will be shown in the duration column
in the event browser when you time individual drawcalls.</para>
<para>Seconds through to nanoseconds are supported.</para></entry>
<entry><para>Enabled</para></entry>
</row>
<row>
<entry><para>Hide empty marker sections</para></entry>
<entry><para>Marker sections that contain no API calls or drawcalls will be completely removed.
This also applies to the Timeline Bar.</para>
<para>This option only applies itself the next time you load a log.</para></entry>
<entry><para>Disabled</para></entry>
</row>
</table>
</content>
</section>
</developerConceptualDocument>
</topic>
docs/Windows/PipelineState.aml
+55
View File
@@ -0,0 +1,55 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="A44E2304-6C11-451D-89C4-0A7397F5D1C6" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<para>The Pipeline Viewer is an information dense but simple window
in RenderDoc. It shows all of the stateful settings of the graphics pipeline, including
bound resources, rasterizer settings, etc.</para>
</introduction>
<section address="pipeline">
<title>Pipeline flowchart</title>
<content>
<para>At the top of the Pipeline Viewer is the pipeline flowchart - this shows the
high-level block level diagram of the graphics pipeline.</para>
<para>Each block is a separate page which contains the relevant state and contents
for that piece of the graphics pipeline, with specific details varying by API
and the type of data to be displayed.</para>
<para>The currently selected block is outlined with red, and the page in view reflects
the contents of that section of the pipeline. Light grey parts of the pipeline are
those which are currently active and participating in this drawcall. Dark grey parts
of the pipeline are not present and can be considered pass-through/do-nothing.</para>
<mediaLink>
<caption placement="after" lead="Pipeline">Pictured here, the high-level parts of the D3D11 Pipeline.</caption>
<image xlink:href="PipelineBar"/>
</mediaLink>
<alert class="note">
<para>In D3D11, the Stream-Out stage is available under the Geometry Shader block, with the buffers
being used for stream-out shown.</para>
</alert>
</content>
</section>
<section address="display">
<title>Pipeline Section Display</title>
<content>
<para>The pipeline state viewer always displays the state of the pipeline after the execution of the
drawcall, as with the other viewers in RenderDoc.</para>
<para>Any resources that are bound to the pipeline can be opened in more detailed viewers, such as
vertex buffers, constant buffers and textures. More details of this process can be found in the page
<link xlink:href="7A620DF5-332E-44CA-8FD5-9E47A9C4CC3E" />.</para>
<para>The pipeline view attempts to only show what is relevant, and not all possible stateful data.
To do this (when available) it uses shader reflection data to only display slots which are actually
in use by the shaders, and omit any that are unused. This can be overridden with the Show Disabled
Items <mediaLinkInline><image xlink:href="page_white_delete"/></mediaLinkInline> button.</para>
<para>Likewise it will omit any slots which are completely empty (and also unused), and this behaviour
can be overridden with the Show Empty Items <mediaLinkInline><image xlink:href="page_white_database"/></mediaLinkInline> button.</para>
<para>When showing disabled or empty entries, they will either be in <legacyItalic>italics</legacyItalic>
or on a dark red background respectively.</para>
</content>
</section>
<relatedTopics>
<link xlink:href="7A620DF5-332E-44CA-8FD5-9E47A9C4CC3E" />
</relatedTopics>
</developerConceptualDocument>
</topic>
docs/Windows/TextureViewer.aml
+337
View File
@@ -0,0 +1,337 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="2c540574-0b81-4a40-8119-ba0283fddf41" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<autoOutline />
<para>The texture viewer is likely the most intuitive window in RenderDoc and commonly
the most regularly used. It displays the contents of any texture in its current state
at the given event, as well as providing controls to adjust and inspect it in different
ways.</para>
</introduction>
<section address="overview">
<title>Overview</title>
<content>
<para>The texture viewer consists of a couple of different sections, which will be
outlined here.</para>
<para>Several specific techniques or features used within the texture viewer have their
own separate pages that go into more detail. You might find more useful information there
if they cover what you are looking for:
<link xlink:href="32C47E20-0FA2-4F52-B33A-4440EBCCBCE4" />,
<link xlink:href="F1C1E449-55ED-46FE-BBFD-11D1A0511501" />,
<link xlink:href="a00964a1-733f-4288-a79e-c28238bc6018" />
</para>
<mediaLink>
<caption placement="after" lead="Texture Viewer">A labelled diagram showing the different parts of the texture viewer.</caption>
<image xlink:href="LabelledTexViewer"/>
</mediaLink>
</content>
</section>
<section address="main">
<title>Main Texture Display</title>
<content>
<para>The main texture display takes up the largest portion of the window, and is simply a container for the
textures to display.</para>
<para>It is a tabbed control and although one tab is always present showing the currently followed texture
bound to the pipeline, other locked tabs can be opened up showing a single resource. More details are available
on the page <link xlink:href="32C47E20-0FA2-4F52-B33A-4440EBCCBCE4" />.</para>
<para>The mouse wheel can be used to zoom in and out of the texture. When zoomed in, holding the left mouse
button and dragging will pan the image from side to side.</para>
<para>While over the image the status bar will show the current pixel that the mouse
is over. Clicking or holding the right mouse button will pick this pixel and show its information in the status
bar. More information is available on the page <link xlink:href="F1C1E449-55ED-46FE-BBFD-11D1A0511501" />.</para>
</content>
</section>
<section address="status">
<title>Information Status Bar</title>
<content>
<para>The status bar below the main texture display contains information on the currently visible texture.</para>
<list class="bullet">
<listItem><para>The name (if available - if not a default name will be used).</para></listItem>
<listItem><para>Dimensions - Width, height, depth and array size as applicable.</para></listItem>
<listItem><para>Mip Count.</para></listItem>
<listItem><para>MSAA sample count and quality, if applicable.</para></listItem>
<listItem><para>Format - e.g. RGB8. The exact phrasing of this will vary by API.</para></listItem>
</list>
<para>After this information there are a few displays that are pixel-based. The pixel that is under the cursor
is displayed as a colour swatch, followed by its co-ordinates. Then any
<link xlink:href="F1C1E449-55ED-46FE-BBFD-11D1A0511501">picked pixel</link> is displayed afterwards with its
numeric value displayed.</para>
<mediaLink>
<caption placement="after" lead="Picked Pixels">Detailed information about the current pixel.</caption>
<image xlink:href="RMBStatus"/>
</mediaLink>
</content>
</section>
<section address="thumbs">
<title>Thumbnail Strips</title>
<content>
<para>There are several thumbnail strip panels available, by default they are docked in the same
location such that they are tabbed together, but they can be displayed side by side.</para>
<para>These strips display thumbnails of the resources bound to their respective parts of the
pipeline, to give some context and allow quick preview without having to switch the main
display between these textures.</para>
<para>The texture that the following tab is currently displaying is highlighted in red, and
each thumbnail shows both the slot number and the name of the texture bound at that point.
To follow a given slot simply left click on it.
If the currently followed texture slot is empty (i.e. it was following a texture and then
that slot was unbound) it will show up simply named "Unbound" and with no name or slot number.</para>
<para>Each thumbnail has a context menu available via right click. This menu allows you to open
a locked tab (<link xlink:href="32C47E20-0FA2-4F52-B33A-4440EBCCBCE4">More information</link>),
as well as containing a list of all the uses of this texture - as read-only resource and writable
output. This is similar to the resource display strip on the <link xlink:href="745E3EB5-EB29-4010-BBAB-B11282F4380C" />.
Clicking on any of these entries will jump to the first of the events in the event range listed.</para>
<mediaLink>
<caption placement="after" lead="Thumbnail Menu">Thumbnail context menu with several options.</caption>
<image xlink:href="OpenLockedTab"/>
</mediaLink>
<para>There are also two general options - show disabled and show empty. These behave the same as the
options in the <link xlink:href="A44E2304-6C11-451D-89C4-0A7397F5D1C6" /> window - temporarily overriding
the default behaviour in RenderDoc to only show texture slots that are referenced in the shader.</para>
</content>
</section>
<section address="context">
<title>Pixel Context Display</title>
<content>
<para>The Pixel context display is a small panel by default in the bottom right of the texture viewer.</para>
<para>Whenever a pixel is picked small area of the texture around it is rendered at maximum zoom to this
panel. This gives you some context for the pixels nearby to the one you're picking and allows fine refinement
without needing to zoom in and lose your place in the overall image.</para>
<mediaLink>
<caption placement="after" lead="Pixel context">Pixel context displaying the surrounds of the picked pixel.</caption>
<image xlink:href="PixelContext"/>
</mediaLink>
</content>
</section>
<section address="range">
<title>Visible Range Control</title>
<content>
<para>The visible range or range adaption control is very useful in easing display and inspection of
images with a very narrow range of values, and is necessary for viewing any HDR images as it can be
used to map a larger range down to LDR for display.</para>
<mediaLink>
<caption placement="after" lead="Range control">The range control narrowing the visible range mapped to [0,1] on output.</caption>
<image xlink:href="RangeControl"/>
</mediaLink>
<para>The primary controls are the black point and white point. These are shown in two text boxes at
either side of the main range control. These are the current absolute black and white values - these values
in the input texture are mapped to 0 and 1 respectively on output.</para>
<para>The range control itself has a black point and a white point that can be adjusted simply by clicking and
dragging. These allow finer and more interactive adjustments. These handle only allow you to adjust the extremes
within the range defined by the absolute black and white points in the text box.</para>
<para>There are four other buttons available for control of the range:</para>
<list class="bullet">
<listItem><para><mediaLinkInline><image xlink:href="zoom"/></mediaLinkInline> <ui>Zoom in</ui> -
This button will zoom the extreme values in to whichever fine values have been selected by the draggable handles.</para>
<para>This is primarily useful when starting from some large range and using the handles to drag down to a more reasonable
range, you can click zoom to then reduce the range down to just the one selected, so you can again get fine control.</para>
<mediaLink>
<caption placement="after" lead="Before">The range control before zooming.</caption>
<image xlink:href="BeforeRangeZoom"/>
</mediaLink>
<mediaLink>
<caption placement="after" lead="After">The range control after zooming.</caption>
<image xlink:href="AfterRangeZoom"/>
</mediaLink>
</listItem>
<listItem><para><mediaLinkInline><image xlink:href="wand"/></mediaLinkInline> <ui>Autofit</ui> -
This button automatically fits the range control to the min and max values in any visible channels in the texture.
Oftentimes this is a good starting point for a range, although with some extreme textures it may adjust badly.</para>
<para>Right clicking on this button will cause it to always auto-fit until you disable this. ie. when you move
to another event or another texture, the range will be auto-fit again. This is useful if jumping between events
or textures where the visible ranges are very different.</para></listItem>
<listItem><para><mediaLinkInline><image xlink:href="UndoArrow"/></mediaLinkInline> <ui>Reset</ui> -
Simply resets the range back to the default of [0, 1] - useful for resetting after changing to a new texture where the
range settings aren't applicable.</para></listItem>
<listItem><para><mediaLinkInline><image xlink:href="chart_curve"/></mediaLinkInline> <ui>Histogram</ui> -
This is a toggle switch. When enabled it will change the thin bar of the range control into a thicker bar
that contains a range-value histogram, showing the distribution of values.</para>
<para>The histogram is based on the straight numerical mean of all visible channels, and will update as the
white and black points move.</para>
<mediaLink>
<caption placement="after" lead="Values Histogram">A histogram showing the range distribution of values in the image.</caption>
<image xlink:href="RangeHistogram"/>
</mediaLink></listItem>
</list>
</content>
</section>
<section address="toolbar">
<title>Toolbar</title>
<content>
<para>The toolbar contains most of the tools for selecting which mip, slice, face of
a texture to view as well as how to display it and if any transformations or overlays
should be applied.</para>
<alert class="note">
<para>The visible range/range adaption control is detailed in the section above and will not be covered here.</para>
</alert>
<table>
<tableHeader>
<row>
<entry><para>Control</para></entry>
<entry><para>Explanation</para></entry>
</row>
</tableHeader>
<row>
<entry>
<para><mediaLinkInline><image xlink:href="RGBAChannels"/></mediaLinkInline> Channels selector</para>
<para><mediaLinkInline><image xlink:href="RGBMChannels"/></mediaLinkInline> RGBM mode</para>
<para>
<mediaLinkInline><image xlink:href="CustomDisplay"/></mediaLinkInline>
<mediaLinkInline><image xlink:href="add"/></mediaLinkInline>
<mediaLinkInline><image xlink:href="page_white_edit"/></mediaLinkInline>
<mediaLinkInline><image xlink:href="delete"/></mediaLinkInline>
<link xlink:href="a00964a1-733f-4288-a79e-c28238bc6018">Custom Shader</link></para>
</entry>
<entry><para>This selector switches between displaying standard RGBA channels, RGBM encoding with a custom
multiplier and using a custom visualiser shader.</para>
<para>When in <ui>RGBA</ui> mode, by default only the RGB channels are displayed and alpha is forced to fully opaque.
Each of the channels can be toggled off independently and any combination can be used. Any RGB channel which
is disabled is forced to fully black in the output. When Alpha is enabled, the background will be rendered
with a solid colour or checkerboard pattern to indicate semi-transparent areas.</para>
<para>Also note that when a single channel is displayed solo, the image is rendered as grayscale in that channel
rather than displaying a monochromatic coloured image.</para>
<alert class="tip">
<para>Right clicking on one of the channel buttons in the texture viewer
(R, G, B, A) will either select only that channel, or if it's already the only one
selected it will select all of the others. This is useful e.g. to toggle between viewing
RGB and alpha, or for looking at individual channels in a packed texture or render target.</para>
</alert>
<para>When <ui>RGBM</ui> is selected, the RGB value will be multiplied by the specified multiplier and then by
the alpha value. This is a common encoding used to pack a larger range into an 8-bit RGB image.</para>
<para>With <ui>Custom</ui> selected a dropdown will be populated with any .hlsl files in the
<codeInline>%APPDATA%\renderdoc</codeInline> folder. When choosing a custom shader the raw image will be
passed through this shader before being displayed with the usual controls on the main display.</para>
<para>You can create a new custom shader with the <mediaLinkInline><image xlink:href="add"/></mediaLinkInline> button,
edit a shader with the <mediaLinkInline><image xlink:href="page_white_edit"/></mediaLinkInline> button,
and delete an one with the <mediaLinkInline><image xlink:href="delete"/></mediaLinkInline> button.</para>
</entry>
</row>
<row>
<entry>
<para><mediaLinkInline><image xlink:href="color_wheel"/></mediaLinkInline>
<mediaLinkInline><image xlink:href="crosshatch"/></mediaLinkInline>
Alpha Background
</para>
</entry>
<entry><para>When displaying a texture with alpha channel, the background of the main display changes to make
the semi-transparent sections more obvious. With these two controls you can either choose a checkerboard pattern
<mediaLinkInline><image xlink:href="crosshatch"/></mediaLinkInline> or open a colour picker to choose a solid
colour <mediaLinkInline><image xlink:href="color_wheel"/></mediaLinkInline>.</para>
</entry>
<para>The currently enabled mode will be highlighted.</para>
</row>
<row>
<entry>
<para>Subresource selection <mediaLinkInline><image xlink:href="SubresourceSelect"/></mediaLinkInline></para>
</entry>
<entry><para>The main display of the texture viewer can only display at most a single 2D image at once.</para>
<para>For textures with mip-maps this control allows you to select the mip level to display - the overall size
of the image will remain the same but will be point sampled from the given mip level.</para>
<para>For 3D textures and 2D arrays you can select the slice to display here from the drop-down, and for cubemaps
you can select the face. For cubemap arrays these two controls are combined to show a list of the faces for the first
cubemap, then the second, etc.</para>
</entry>
</row>
<row>
<entry>
<para><mediaLinkInline><image xlink:href="save"/></mediaLinkInline> Save Texture</para>
</entry>
<entry><para>This allows you to save the currently visible texture. Currently only .dds format is supported, and
there are some limitations in the formats that can be saved - e.g. there is no standard way to support multisampled
dds files, so this will fail. Most common formats can be saved to disk in this way.</para>
</entry>
</row>
<row>
<entry>
<para><mediaLinkInline><image xlink:href="wrench"/></mediaLinkInline> Debug a Pixel</para>
</entry>
<entry><para>This button is only enabled after a
<link xlink:href="8a7568ca-6b2c-4873-b8eb-d1ad2aff9629">pixel has been picked</link>.</para>
<para>This will do exactly the same as the button underneath the pixel context display - it will
launch a pixel debugger for the currently picked pixel.</para>
</entry>
</row>
<row>
<entry>
<para><mediaLinkInline><image xlink:href="page_white_link"/></mediaLinkInline> Open Texture List</para>
</entry>
<entry><para>This button opens the texture list of all textures present in the capture. More details can
be seen in <link xlink:href="32C47E20-0FA2-4F52-B33A-4440EBCCBCE4" /></para>
</entry>
</row>
<row>
<entry>
<para>Zoom controls <mediaLinkInline><image xlink:href="ZoomControls"/></mediaLinkInline></para>
</entry>
<entry><para>The zoom controls are fairly self explanatory - a pre-existing zoom value can be chosen
from the drop down or a custom value (clamped to the minimum and maximum zoom) can be entered as a
percentage.</para>
<para>To automatically fit the texture to the space available in the window, regardless of its
dimensions, you can click the <mediaLinkInline><image xlink:href="fit_window"/></mediaLinkInline> Fit
button.</para>
<alert class="note">
<para>As noted above, the mouse scroll wheel in the main display also changes the zoom level.</para>
</alert>
</entry>
</row>
<row>
<entry>
<para>Render Overlay <mediaLinkInline><image xlink:href="OverlaySelect"/></mediaLinkInline></para>
</entry>
<entry><para>This is a powerful tool for quickly diagnosing issues and can be very useful for locating
what you're looking for. Several overlays are available that can be rendered over any texture, although
most of them are only meaningful for currently bound render targets.</para>
<list class="bullet">
<listItem><para><command>Highlight Drawcall</command> will do pretty much as it says. It darkens everything except
the current drawcall which is highlighted in flat colour. This makes whatever is being drawn stand out and can be useful
for seeing where the current object is on screen, especially if rapidly browsing through the frame.</para></listItem>
<listItem><para><command>Wireframe Mesh</command> will render a wireframe mesh of the current drawcall
over the top of the image.</para></listItem>
<listItem><para><command>Depth Test</command> will render an overlay over the drawcall, with red sections covering
any part of the drawcall that never passed the depth test, and green sections covering areas that did pass the
depth test. Note that if the drawcall overdraws itself then as long as at least one pass over a pixel passes the depth test
then that pixel will be green.</para></listItem>
<listItem><para><command>Stencil Test</command> performs similarly to the depth test, but for the stencil test.</para></listItem>
<listItem><para><command>Viewport/Scissor</command> shows a coloured overlay on the image that corresponds to the viewport
and scissor regions.</para></listItem>
<listItem><para><command>NaN/Inf/-ve display</command> will render the image in grayscale (using the typical luminance
calculation - <codeInline>dot(col.xyz, float3(0.2126, 0.7152, 0.0722)).xxx</codeInline>) with red pixels highlighting any
NaNs found, green pixels highlighting any infinities, and blue pixels for any negative values. Note that in any case
where only one or some channels in a multi-channel texture pass, that pixel will still be highlighted (so
<codeInline>{0.5, -1.0, 0.0}</codeInline> would highlight blue).</para></listItem>
<listItem><para><command>Clipping</command> will simply highlight in red any values that are below the current
black point (as defined by the range control - see above), and in green any values above the white point. This can
be useful in identifying invalid ranges if the range control is adjusted correctly, or in combination with a custom
shader visualiser.</para></listItem>
</list>
<alert class="note">
<para>These overlays are all rendered after most image controls are applied. For this reason the range control,
channel controls and custom shaders do not affect the overlays.</para>
</alert>
</entry>
</row>
</table>
</content>
</section>
<relatedTopics>
<link xlink:href="32C47E20-0FA2-4F52-B33A-4440EBCCBCE4" />
<link xlink:href="F1C1E449-55ED-46FE-BBFD-11D1A0511501" />
<link xlink:href="a00964a1-733f-4288-a79e-c28238bc6018" />
</relatedTopics>
</developerConceptualDocument>
</topic>
docs/Windows/TimelineBar.aml
+81
View File
@@ -0,0 +1,81 @@
<?xml version="1.0" encoding="utf-8"?>
<topic id="745E3EB5-EB29-4010-BBAB-B11282F4380C" revisionNumber="1">
<developerConceptualDocument xmlns="http://ddue.schemas.microsoft.com/authoring/2003/5" xmlns:xlink="http://www.w3.org/1999/xlink">
<introduction>
<autoOutline />
<para>The timeline bar shows an alternate view of the scene to the
<link xlink:href="16D2B42E-65B0-40D1-AB91-AD2B156F5DA0" />. Displaying the scene with
time running as the horizontal axis, although it does not show each section in size
relative to its timing.</para>
</introduction>
<section address="intro">
<title>Introduction</title>
<content>
<para>The timeline bar shows the scene horizontally with the hierarchical frame
markers being expandable from top to bottom.</para>
<para>This alternate view can be a useful way to get an overview of the whole frame,
allowing you to jump around very different parts of the frame.</para>
<para>Given that the timeline bar shows the whole frame it also provides a secondary
function of showing dependencies in a global way. For whichever texture is currently
selected in the texture viewer, the timeline bar shows reads and writes to that texture
throughout the frame. This can be especially useful for render targets that are used
in both ways, as well as simply to see where a given texture is used in a frame
without laboriously searching.</para>
<mediaLink>
<caption placement="after" lead="Timeline Bar">The timeline bar showing a birds-eye view of a typical application.</caption>
<image xlink:href="TimelineBar"/>
</mediaLink>
</content>
</section>
<section address="display">
<title>Timeline Display</title>
<content>
<para>By default the timeline bar views the whole frame, but with the mouse wheel
you can zoom in and out. When zoomed in, you can scroll through the frame with
the horizontal scroll bar.</para>
<para>The timeline bar sizes the sections that it contains to try and make the
frame markers as visible as possible. This attempts to keep the frame browsable
for as long as possible, such that small sections (in time or number of events)
are still visible rather than being crushed to tiny bars.</para>
<para>For this reason the timeline can resize itself when bars are expanded,
as this can reveal new sections which must be allocated enough room. When there
is slack space to be allocated it is given to the sections which have more events
than others.</para>
<para>Underneath expanded sections, a blue pip is rendered for each drawcall-type
event. The currently selected event is shown as a green pip, as well as there being
a light grey vertical line to indicate the current position, such that this is visible
even when the relevant section is not expanded.</para>
<para>Clicking on any section will toggle it between expanded and unexpanded, and
any sections underneath a section which is collapsed will remain in their previous state
but will not be visible.</para>
<para>Left clicking on the timeline will jump to the event underneath that point
on the horizontal display.</para>
</content>
</section>
<section address="usage">
<title>Resource usage Display</title>
<content>
<para>The timeline bar also shows the usage of the currently displayed texture.</para>
<para>Whichever texture is currently displayed in the <link xlink:href="2c540574-0b81-4a40-8119-ba0283fddf41" />
(whether that be a currently bound texture, or a locked tab) will have its usage
laid out across the frame on the timeline bar.</para>
<para>If your textures have their names annotated you will see which texture is being
inspected in the label for the usage bar.</para>
<para>A green arrow will be drawn under each pip that reads from the texture. If the pips
are too close together to resolve the arrow, the arrows will stay distinct and lose the
1:1 association with event pips.</para>
<para>Similarly, a purple arrow will be drawn under pips where the event writes to the
texture. In the case that a resource is bound such that it can be read or written,
the arrow will be half-green, half-purple.</para>
<para>Clear calls will be shown with a light grey.</para>
<para>In cases where the arrows are too close together to show distinctly, they
will not all draw. To see exactly what usage is happening you can zoom into the context
around that area of the frame.</para>
<mediaLink>
<caption placement="after" lead="Resource Usage">The usage bar showing reads and writes to a texture.</caption>
<image xlink:href="ResourceUsage"/>
</mediaLink>
</content>
</section>
</developerConceptualDocument>
</topic>
docs/dummy/IgnoreMe.csproj
+80
View File
@@ -0,0 +1,80 @@
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">x86</Platform>
<ProductVersion>8.0.30703</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{8FB56D2F-58D9-425D-A46E-E3EA111A2F68}</ProjectGuid>
<OutputType>WinExe</OutputType>
<AppDesignerFolder>Properties</AppDesignerFolder>
<RootNamespace>IgnoreMe</RootNamespace>
<AssemblyName>IgnoreMe</AssemblyName>
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
<TargetFrameworkProfile>Client</TargetFrameworkProfile>
<FileAlignment>512</FileAlignment>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<PlatformTarget>x86</PlatformTarget>
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<DocumentationFile>bin\Debug\IgnoreMe.xml</DocumentationFile>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
<PlatformTarget>x86</PlatformTarget>
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<ItemGroup>
<Reference Include="System" />
<Reference Include="System.Core" />
<Reference Include="System.Xml.Linq" />
<Reference Include="System.Data.DataSetExtensions" />
<Reference Include="Microsoft.CSharp" />
<Reference Include="System.Data" />
<Reference Include="System.Deployment" />
<Reference Include="System.Drawing" />
<Reference Include="System.Windows.Forms" />
<Reference Include="System.Xml" />
</ItemGroup>
<ItemGroup>
<Compile Include="Program.cs" />
<Compile Include="Properties\AssemblyInfo.cs" />
<EmbeddedResource Include="Properties\Resources.resx">
<Generator>ResXFileCodeGenerator</Generator>
<LastGenOutput>Resources.Designer.cs</LastGenOutput>
<SubType>Designer</SubType>
</EmbeddedResource>
<Compile Include="Properties\Resources.Designer.cs">
<AutoGen>True</AutoGen>
<DependentUpon>Resources.resx</DependentUpon>
<DesignTime>True</DesignTime>
</Compile>
<None Include="Properties\Settings.settings">
<Generator>SettingsSingleFileGenerator</Generator>
<LastGenOutput>Settings.Designer.cs</LastGenOutput>
</None>
<Compile Include="Properties\Settings.Designer.cs">
<AutoGen>True</AutoGen>
<DependentUpon>Settings.settings</DependentUpon>
<DesignTimeSharedInput>True</DesignTimeSharedInput>
</Compile>
</ItemGroup>
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<!-- To modify your build process, add your task inside one of the targets below and uncomment it.
Other similar extension points exist, see Microsoft.Common.targets.
<Target Name="BeforeBuild">
</Target>
<Target Name="AfterBuild">
</Target>
-->
</Project>
docs/dummy/IgnoreMe.sln
+20
View File
@@ -0,0 +1,20 @@
Microsoft Visual Studio Solution File, Format Version 11.00
# Visual Studio 2010
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "IgnoreMe", "IgnoreMe.csproj", "{8FB56D2F-58D9-425D-A46E-E3EA111A2F68}"
EndProject
Global
GlobalSection(SolutionConfigurationPlatforms) = preSolution
Debug|x86 = Debug|x86
Release|x86 = Release|x86
EndGlobalSection
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{8FB56D2F-58D9-425D-A46E-E3EA111A2F68}.Debug|x86.ActiveCfg = Debug|x86
{8FB56D2F-58D9-425D-A46E-E3EA111A2F68}.Debug|x86.Build.0 = Debug|x86
{8FB56D2F-58D9-425D-A46E-E3EA111A2F68}.Release|x86.ActiveCfg = Release|x86
{8FB56D2F-58D9-425D-A46E-E3EA111A2F68}.Release|x86.Build.0 = Release|x86
EndGlobalSection
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
EndGlobalSection
EndGlobal
docs/dummy/Program.cs
+21
View File
@@ -0,0 +1,21 @@
using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows.Forms;
namespace IgnoreMe
{
/// <summary>
/// Ignore me! This is a dummy section of documentation to satisfy Sandcastle :).
/// </summary>
public class IgnoreMe
{
/// <summary>
/// Ignore me! This is a dummy section of documentation to satisfy Sandcastle :).
/// </summary>
[STAThread]
static void Main()
{
}
}
}
docs/dummy/Properties/AssemblyInfo.cs
+36
View File
@@ -0,0 +1,36 @@
using System.Reflection;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
// General Information about an assembly is controlled through the following
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.
[assembly: AssemblyTitle("dummydocs")]
[assembly: AssemblyDescription("")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("")]
[assembly: AssemblyProduct("dummydocs")]
[assembly: AssemblyCopyright("Copyright © 2014")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]
// Setting ComVisible to false makes the types in this assembly not visible
// to COM components. If you need to access a type in this assembly from
// COM, set the ComVisible attribute to true on that type.
[assembly: ComVisible(false)]
// The following GUID is for the ID of the typelib if this project is exposed to COM
[assembly: Guid("e27b8253-434f-4a51-8ea8-a19bc79e0d45")]
// Version information for an assembly consists of the following four values:
//
// Major Version
// Minor Version
// Build Number
// Revision
//
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]
docs/dummy/Properties/Resources.Designer.cs
Generated
+63
View File
@@ -0,0 +1,63 @@
//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:4.0.30319.18052
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
namespace IgnoreMe.Properties {
using System;
/// <summary>
/// A strongly-typed resource class, for looking up localized strings, etc.
/// </summary>
// This class was auto-generated by the StronglyTypedResourceBuilder
// class via a tool like ResGen or Visual Studio.
// To add or remove a member, edit your .ResX file then rerun ResGen
// with the /str option, or rebuild your VS project.
[global::System.CodeDom.Compiler.GeneratedCodeAttribute("System.Resources.Tools.StronglyTypedResourceBuilder", "4.0.0.0")]
[global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
[global::System.Runtime.CompilerServices.CompilerGeneratedAttribute()]
internal class Resources {
private static global::System.Resources.ResourceManager resourceMan;
private static global::System.Globalization.CultureInfo resourceCulture;
[global::System.Diagnostics.CodeAnalysis.SuppressMessageAttribute("Microsoft.Performance", "CA1811:AvoidUncalledPrivateCode")]
internal Resources() {
}
/// <summary>
/// Returns the cached ResourceManager instance used by this class.
/// </summary>
[global::System.ComponentModel.EditorBrowsableAttribute(global::System.ComponentModel.EditorBrowsableState.Advanced)]
internal static global::System.Resources.ResourceManager ResourceManager {
get {
if (object.ReferenceEquals(resourceMan, null)) {
global::System.Resources.ResourceManager temp = new global::System.Resources.ResourceManager("IgnoreMe.Properties.Resources", typeof(Resources).Assembly);
resourceMan = temp;
}
return resourceMan;
}
}
/// <summary>
/// Overrides the current thread's CurrentUICulture property for all
/// resource lookups using this strongly typed resource class.
/// </summary>
[global::System.ComponentModel.EditorBrowsableAttribute(global::System.ComponentModel.EditorBrowsableState.Advanced)]
internal static global::System.Globalization.CultureInfo Culture {
get {
return resourceCulture;
}
set {
resourceCulture = value;
}
}
}
}
docs/dummy/Properties/Resources.resx
+117
View File
@@ -0,0 +1,117 @@
<?xml version="1.0" encoding="utf-8"?>
<root>
<!--
Microsoft ResX Schema
Version 2.0
The primary goals of this format is to allow a simple XML format
that is mostly human readable. The generation and parsing of the
various data types are done through the TypeConverter classes
associated with the data types.
Example:
... ado.net/XML headers & schema ...
<resheader name="resmimetype">text/microsoft-resx</resheader>
<resheader name="version">2.0</resheader>
<resheader name="reader">System.Resources.ResXResourceReader, System.Windows.Forms, ...</resheader>
<resheader name="writer">System.Resources.ResXResourceWriter, System.Windows.Forms, ...</resheader>
<data name="Name1"><value>this is my long string</value><comment>this is a comment</comment></data>
<data name="Color1" type="System.Drawing.Color, System.Drawing">Blue</data>
<data name="Bitmap1" mimetype="application/x-microsoft.net.object.binary.base64">
<value>[base64 mime encoded serialized .NET Framework object]</value>
</data>
<data name="Icon1" type="System.Drawing.Icon, System.Drawing" mimetype="application/x-microsoft.net.object.bytearray.base64">
<value>[base64 mime encoded string representing a byte array form of the .NET Framework object]</value>
<comment>This is a comment</comment>
</data>
There are any number of "resheader" rows that contain simple
name/value pairs.
Each data row contains a name, and value. The row also contains a
type or mimetype. Type corresponds to a .NET class that support
text/value conversion through the TypeConverter architecture.
Classes that don't support this are serialized and stored with the
mimetype set.
The mimetype is used for serialized objects, and tells the
ResXResourceReader how to depersist the object. This is currently not
extensible. For a given mimetype the value must be set accordingly:
Note - application/x-microsoft.net.object.binary.base64 is the format
that the ResXResourceWriter will generate, however the reader can
read any of the formats listed below.
mimetype: application/x-microsoft.net.object.binary.base64
value : The object must be serialized with
: System.Serialization.Formatters.Binary.BinaryFormatter
: and then encoded with base64 encoding.
mimetype: application/x-microsoft.net.object.soap.base64
value : The object must be serialized with
: System.Runtime.Serialization.Formatters.Soap.SoapFormatter
: and then encoded with base64 encoding.
mimetype: application/x-microsoft.net.object.bytearray.base64
value : The object must be serialized into a byte array
: using a System.ComponentModel.TypeConverter
: and then encoded with base64 encoding.
-->
<xsd:schema id="root" xmlns="" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
<xsd:element name="root" msdata:IsDataSet="true">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded">
<xsd:element name="metadata">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="value" type="xsd:string" minOccurs="0" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" />
<xsd:attribute name="type" type="xsd:string" />
<xsd:attribute name="mimetype" type="xsd:string" />
</xsd:complexType>
</xsd:element>
<xsd:element name="assembly">
<xsd:complexType>
<xsd:attribute name="alias" type="xsd:string" />
<xsd:attribute name="name" type="xsd:string" />
</xsd:complexType>
</xsd:element>
<xsd:element name="data">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="value" type="xsd:string" minOccurs="0" msdata:Ordinal="1" />
<xsd:element name="comment" type="xsd:string" minOccurs="0" msdata:Ordinal="2" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" msdata:Ordinal="1" />
<xsd:attribute name="type" type="xsd:string" msdata:Ordinal="3" />
<xsd:attribute name="mimetype" type="xsd:string" msdata:Ordinal="4" />
</xsd:complexType>
</xsd:element>
<xsd:element name="resheader">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="value" type="xsd:string" minOccurs="0" msdata:Ordinal="1" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
</xsd:complexType>
</xsd:element>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:schema>
<resheader name="resmimetype">
<value>text/microsoft-resx</value>
</resheader>
<resheader name="version">
<value>2.0</value>
</resheader>
<resheader name="reader">
<value>System.Resources.ResXResourceReader, System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
</resheader>
<resheader name="writer">
<value>System.Resources.ResXResourceWriter, System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value>
</resheader>
</root>
docs/dummy/Properties/Settings.Designer.cs
Generated
+26
View File
@@ -0,0 +1,26 @@
//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:4.0.30319.18052
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
namespace IgnoreMe.Properties {
[global::System.Runtime.CompilerServices.CompilerGeneratedAttribute()]
[global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.VisualStudio.Editors.SettingsDesigner.SettingsSingleFileGenerator", "10.0.0.0")]
internal sealed partial class Settings : global::System.Configuration.ApplicationSettingsBase {
private static Settings defaultInstance = ((Settings)(global::System.Configuration.ApplicationSettingsBase.Synchronized(new Settings())));
public static Settings Default {
get {
return defaultInstance;
}
}
}
}
docs/dummy/Properties/Settings.settings
+7
View File
@@ -0,0 +1,7 @@
<?xml version='1.0' encoding='utf-8'?>
<SettingsFile xmlns="http://schemas.microsoft.com/VisualStudio/2004/01/settings" CurrentProfile="(Default)">
<Profiles>
<Profile Name="(Default)" />
</Profiles>
<Settings />
</SettingsFile>
docs/imgs/QuickStart/QuickStart1.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 82 KiB

docs/imgs/QuickStart/QuickStart2.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 630 KiB

docs/imgs/QuickStart/QuickStart3.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 488 KiB

docs/imgs/QuickStart/QuickStart4.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 14 KiB

docs/imgs/QuickStart/QuickStart5.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 19 KiB

docs/imgs/QuickStart/QuickStart6.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.4 KiB

docs/imgs/QuickStart/QuickStart7.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 26 KiB

docs/imgs/QuickStart/QuickStart8.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 53 KiB

docs/imgs/Screenshots/APIList.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.5 KiB

docs/imgs/Screenshots/AfterRangeZoom.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.2 KiB

docs/imgs/Screenshots/AttachInstance.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 23 KiB

docs/imgs/Screenshots/Attaching.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.2 KiB

docs/imgs/Screenshots/BeforeRangeZoom.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.3 KiB

docs/imgs/Screenshots/BufferOptions.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 4.0 KiB

docs/imgs/Screenshots/CBuffer.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 29 KiB

docs/imgs/Screenshots/CallstackPanel.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 5.4 KiB

docs/imgs/Screenshots/Callstacks.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.5 KiB

docs/imgs/Screenshots/CapturePathCmdline.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 4.5 KiB

docs/imgs/Screenshots/CurrentShader.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.2 KiB

docs/imgs/Screenshots/CurrentVsLockedTab.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 24 KiB

docs/imgs/Screenshots/CustomDisplay.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.4 KiB

docs/imgs/Screenshots/DebugMessages.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 17 KiB

docs/imgs/Screenshots/FindResults.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 15 KiB

docs/imgs/Screenshots/HoverStatus.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.0 KiB

docs/imgs/Screenshots/JumpEID.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 14 KiB

docs/imgs/Screenshots/LabelledTexViewer.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 525 KiB

docs/imgs/Screenshots/MultipleCaptures.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 133 KiB

docs/imgs/Screenshots/NamedTex.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.2 KiB

docs/imgs/Screenshots/NeedPDB.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 86 KiB

docs/imgs/Screenshots/NeedResolve.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 11 KiB

docs/imgs/Screenshots/OpenCapNewInstance.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 46 KiB

docs/imgs/Screenshots/OpenLockedTab.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 33 KiB

docs/imgs/Screenshots/OverlaySelect.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.1 KiB

docs/imgs/Screenshots/PipelineBar.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 4.2 KiB

docs/imgs/Screenshots/PixelContext.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.8 KiB

docs/imgs/Screenshots/RGBAChannels.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.5 KiB

docs/imgs/Screenshots/RGBMChannels.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.9 KiB

docs/imgs/Screenshots/RMBStatus.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.8 KiB

docs/imgs/Screenshots/RangeControl.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 59 KiB

docs/imgs/Screenshots/RangeHistogram.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 44 KiB

docs/imgs/Screenshots/RawBuffer.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 34 KiB

docs/imgs/Screenshots/ResourceUsage.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 4.0 KiB

docs/imgs/Screenshots/ShaderConsts.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 12 KiB

docs/imgs/Screenshots/ShaderControls.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 20 KiB

docs/imgs/Screenshots/ShaderRegs.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.2 KiB

docs/imgs/Screenshots/ShaderWatch.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 4.3 KiB

docs/imgs/Screenshots/SolidPreview.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 51 KiB

docs/imgs/Screenshots/SubresourceSelect.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.8 KiB

docs/imgs/Screenshots/TexList.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.0 KiB

docs/imgs/Screenshots/TimelineBar.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.3 KiB

docs/imgs/Screenshots/VertexDebug.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 35 KiB

docs/imgs/Screenshots/ZoomControls.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.5 KiB

docs/imgs/icons/GoArrow.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 686 B

docs/imgs/icons/UndoArrow.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 631 B

docs/imgs/icons/add.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 733 B

docs/imgs/icons/arrow_join.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 626 B

docs/imgs/icons/arrow_undo.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 631 B

docs/imgs/icons/chart_curve.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 710 B

docs/imgs/icons/cog.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 512 B

docs/imgs/icons/color_wheel.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 892 B

docs/imgs/icons/cross.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 655 B

docs/imgs/icons/crosshatch.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 225 B

Some files were not shown because too many files have changed in this diff Show More