mirror of
https://github.com/baldurk/renderdoc.git
synced 2026-05-12 13:00:32 +00:00
Fix various internal links.
This commit is contained in:
Matthäus G. Chajdas
committed by
baldurk
baldurk
parent
f04f016a99
commit
6557cec9ea
@@ -124,7 +124,7 @@ The two primary causes of differences between the captured program and the repla
|
||||
|
||||
#. RenderDoc as an optimisation will not save or restore the contents of render targets at the start of the frame if it believes they will be entirely overwritten in the frame. This detection is typically accurate but means targets are cleared to black or full depth rather than accumulating, even if that accumulation is not intentional it may be the cause of the bug.
|
||||
|
||||
This behaviour can be overridden by enabling 'Save all initials' in the :doc:`capture options <capture_options>`.
|
||||
This behaviour can be overridden by enabling 'Save all initials' in the :doc:`capture options <../how/how_capture_log>`.
|
||||
|
||||
I can't launch my program for capture directly. Can I capture it anyway?
|
||||
------------------------------------------------------------------------
|
||||
@@ -149,7 +149,7 @@ I think I might be overwriting Map() boundaries, can I check this?
|
||||
|
||||
Yes RenderDoc can be configured to insert a boundary marker at the end of the memory returned from a Map() call. If this marker gets overwritten during a captured frame then a message box will pop up alerting you, and clicking Yes will break into the program in the debugger so that you can investigate the callstack.
|
||||
|
||||
To enable this behaviour, select the 'Verify Map() Writes' option when :doc:`capturing <capture>`.
|
||||
To enable this behaviour, select the 'Verify Map() Writes' option when :doc:`capturing <../window/capture_log_attach>`.
|
||||
|
||||
RenderDoc is complaining about my OpenGL app in the overlay - what gives?
|
||||
-------------------------------------------------------------------------
|
||||
|
||||
@@ -10,7 +10,7 @@ Things to Note
|
||||
|
||||
* 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.
|
||||
|
||||
You can override this behaviour by selecting 'Save All Initials' in the :doc:`capture options <capture_options>` 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.
|
||||
You can override this behaviour by selecting 'Save All Initials' in the :doc:`capture options <../how/capture_log>` 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.
|
||||
|
||||
* 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.
|
||||
|
||||
@@ -19,7 +19,7 @@ Things to Note
|
||||
RenderDoc has no runtime dependencies on Visual Studio or the DirectX or Windows SDK, and should run anywhere that a normal DirectX application will run - i.e. on Artist or QA machines.
|
||||
|
||||
Currently RenderDoc also assumes feature level 11+ hardware for the replay app. It can capture applications running at a lower feature level, but when replaying if 11+ hardware isn't available, RenderDoc will fall back to WARP software emulation and will run slowly.
|
||||
* 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 :doc:`how_to_capture_callstack`.
|
||||
* 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 :doc:`../how/how_capture_callstack`.
|
||||
* RenderDoc can have a significant memory overhead, especially when a lot of resources are allocated as shadow copies in main memory are created.
|
||||
|
||||
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.
|
||||
|
||||
@@ -69,7 +69,7 @@ There are various visualisation controls that allow you to select different chan
|
||||
|
||||
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 _Unbound_ listed under their thumbnail.
|
||||
|
||||
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 :doc:`open it by name <how_view_texture>`.
|
||||
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 :doc:`open it by name <../how/how_view_texture>`.
|
||||
|
||||
* The format and dimensions of the texture are displayed on the status bar just below the texture display itself.
|
||||
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.
|
||||
@@ -124,7 +124,7 @@ The API Calls window updates as a new event is selected. It shows the individual
|
||||
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.
|
||||
|
||||
|
||||
In order to view these callstacks you must first resolve the symbols recorded with the log. To do this click on :kbd:`Resolve Symbols` under the :kbd:`Tools` menu. More details on this process can be found in the guide: :doc:`how_capture_callstack`.
|
||||
In order to view these callstacks you must first resolve the symbols recorded with the log. To do this click on :kbd:`Resolve Symbols` under the :kbd:`Tools` menu. More details on this process can be found in the guide: :doc:`../how/how_capture_callstack`.
|
||||
|
||||
Timeline Bar
|
||||
````````````
|
||||
@@ -161,7 +161,7 @@ By default the pipeline will not contain empty or unused entries - i.e. if a sha
|
||||
|
||||
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 (|go_arrow|) 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.
|
||||
|
||||
For more details, check out the how-to: :doc:`how_view_object`.
|
||||
For more details, check out the how-to: :doc:`../how/how_object_details`.
|
||||
|
||||
Mesh Output
|
||||
```````````
|
||||
|
||||
@@ -20,7 +20,7 @@ This page is a random hodge-podge of different tips and tricks that might not be
|
||||
#. 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 |go_arrow| on the input layouts in the :doc:`pipeline_state`.
|
||||
#. 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.
|
||||
#. Similarly, right-clicking on the 'auto-fit' button |wand| 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.
|
||||
#. You can double click on a thumbnail in the texture viewer to open a :doc:`locked texture <how_view_texture>` tab
|
||||
#. You can double click on a thumbnail in the texture viewer to open a :doc:`locked texture <../how/how_view_texture>` tab
|
||||
#. You can close tabs by middle clicking on them.
|
||||
#. You can trigger a capture from code. renderdoc.dll exports an :doc:`in_application_api` for this purpose, defined in ``renderdoc_app.h`` in the distributions:
|
||||
|
||||
@@ -65,7 +65,7 @@ This page is a random hodge-podge of different tips and tricks that might not be
|
||||
#define GL_DEBUG_TOOL_EXT 0x6789
|
||||
#define GL_DEBUG_TOOL_NAME_EXT 0x678A
|
||||
#define GL_DEBUG_TOOL_PURPOSE_EXT 0x678B
|
||||
|
||||
|
||||
#. RenderDoc can be informed about separated debug shader blobs through API specific ways:
|
||||
|
||||
.. code:: c++
|
||||
|
||||
@@ -21,19 +21,19 @@ Details of the licenses of third party software used in RenderDoc are included i
|
||||
How to browse this documentation
|
||||
--------------------------------
|
||||
|
||||
If you just want to dive straight in and learn how to get started using RenderDoc consider looking at the :doc:`quick_start` 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.
|
||||
If you just want to dive straight in and learn how to get started using RenderDoc consider looking at the :doc:`getting_started/quick_start` 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.
|
||||
|
||||
|
||||
Those of you familiar with other graphics debuggers will likely find much of RenderDoc recognisable, you might want to check out the :doc:`FAQ`, :doc:`Features`, :doc:`tips_tricks` or browse the How Do I... ? sections which detail how some common tasks are accomplished.
|
||||
Those of you familiar with other graphics debuggers will likely find much of RenderDoc recognisable, you might want to check out the :doc:`getting_started/faq`, :doc:`getting_started/features`, :doc:`getting_started/tips_tricks` or browse the How Do I... ? sections which detail how some common tasks are accomplished.
|
||||
|
||||
Regardless of your experience or patience for documentation it's recommended that you read the :doc:`gotchas_known_issues` as this details known bugs and current limitations of the program.
|
||||
Regardless of your experience or patience for documentation it's recommended that you read the :doc:`getting_started/gotchas_known_issues` as this details known bugs and current limitations of the program.
|
||||
|
||||
Important notes
|
||||
---------------
|
||||
|
||||
* RenderDoc is not yet bug free! It is pretty stable but you will still likely encounter bugs depending on your use case. I am *always* 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!
|
||||
* 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.
|
||||
* There are a few common issues you might run into, so if you have any problems check the :doc:`FAQ`, or the `issues page on github <https://github.com/baldurk/renderdoc/issues>`_ to see if it's been reported.
|
||||
* There are a few common issues you might run into, so if you have any problems check the :doc:`getting_started/faq`, or the `issues page on github <https://github.com/baldurk/renderdoc/issues>`_ to see if it's been reported.
|
||||
|
||||
Documentation and Tutorials
|
||||
---------------------------
|
||||
|
||||
Reference in New Issue
Block a user