diff --git a/docs/behind_scenes/d3d12_support.rst b/docs/behind_scenes/d3d12_support.rst index b969cc446..3dd512a06 100644 --- a/docs/behind_scenes/d3d12_support.rst +++ b/docs/behind_scenes/d3d12_support.rst @@ -10,7 +10,7 @@ D3D12 is intended as to have low CPU overhead and be fully threadable, and Rende Some patterns of access are more or less conducive to good performance on RenderDoc, so if you are having trouble with slow capture, large memory/disk overhead or slow replay you might want to try eliminating use of persistent maps of resources. If you do have persistent maps, ensure that either the memory allocation is small or that you have only a few queue submits during the frame - since RenderDoc must compare the whole allocation at every submit to determine what might have changed and save out the delta. -Likewise try to avoid making very large memory allocations in the range of 1GB and above. By its nature RenderDoc must save one or more copies of memory allocations to enable proper capture, so having allocations limited to only a few 100s of MBs can help gain granularity of management and limit the memory overhead RenderDoc adds. There may be optimisation of this in future on RenderDoc's side but there are no easy guarantees. +Likewise try to avoid making very large memory allocations in the range of 1GB and above. By its nature RenderDoc must save one or more copies of memory allocations to enable proper capture, so having allocations limited to only a few 100s of megabytes can help gain granularity of management and limit the memory overhead RenderDoc adds. There may be optimisation of this in future on RenderDoc's side but there are no easy guarantees. Current support --------------- diff --git a/docs/behind_scenes/planned_features.rst b/docs/behind_scenes/planned_features.rst index 1501e57da..e59529fa6 100644 --- a/docs/behind_scenes/planned_features.rst +++ b/docs/behind_scenes/planned_features.rst @@ -13,7 +13,6 @@ Planned features * Debugging of all shader stages. * HLSL Debugging. * Mesh display after hull shader stage. -* Perfkit/PerfHUD integration for vendor-specific detailed performance timers. * Diffing events in a given frame. * Modifying the pipeline on the fly to change state. * Highlighting redundant state-setting. diff --git a/docs/behind_scenes/vulkan_support.rst b/docs/behind_scenes/vulkan_support.rst index c08be876c..a563eb31a 100644 --- a/docs/behind_scenes/vulkan_support.rst +++ b/docs/behind_scenes/vulkan_support.rst @@ -26,7 +26,7 @@ Vulkan is intended as a high-performance low CPU overhead API, and RenderDoc str Some patterns of access are more or less conducive to good performance on RenderDoc, so if you are having trouble with slow capture, large memory/disk overhead or slow replay you might want to try eliminating use of persistent maps of memory from coherent heaps - you can use ``vkFlushMappedMemoryRanges`` to emulate non-coherent heaps and RenderDoc will take advantage of that, or you can use non-persistent maps. -Likewise try to avoid making very large memory allocations in the range of 1GB and above. By its nature RenderDoc must save one or mor copies of memory allocations to enable proper capture, so having allocations limited to only a few 100s of MBs can help gain granularity of management and limit the memory overhead RenderDoc adds. There may be optimisation of this in future on RenderDoc's side but there are no easy guarantees. +Likewise try to avoid making very large memory allocations in the range of 1GB and above. By its nature RenderDoc must save one or more copies of memory allocations to enable proper capture, so having allocations limited to only a few 100s of megabytes can help gain granularity of management and limit the memory overhead RenderDoc adds. There may be optimisation of this in future on RenderDoc's side but there are no easy guarantees. Current support --------------- diff --git a/docs/getting_started/faq.rst b/docs/getting_started/faq.rst index 09cab0956..c2c498647 100644 --- a/docs/getting_started/faq.rst +++ b/docs/getting_started/faq.rst @@ -10,7 +10,7 @@ RenderDoc has some very light anonymous analytics to allow analysis of which fea The complete details of the analytics can be found in the page about :doc:`../behind_scenes/analytics`, but the brief outline is that RenderDoc records data **only in the replay program** and does not record any data that is specific to any captured programs. The data recorded is primarily boolean flags indicating whether or not a given feature, API, or platform is used or not. You can see the precise list of data gathered on your current RenderDoc build in the settings menu under the :guilabel:`Anonymous Analytics` section. -The analytics data is summarised and transmitted securely and anonymously to RenderDoc's server. The aggeregated statistics are available for anyone to see at `the analytics homepage `_. +The analytics data is summarised and transmitted securely and anonymously to RenderDoc's server. The aggregated statistics are available for anyone to see at `the analytics homepage `_. Enabling the analytics is greatly appreciated, if you have any concerns about the data gathered you can choose to manually verify each report before it's submitted. @@ -62,7 +62,7 @@ Currently RenderDoc supports Vulkan 1.0, D3D11 (up to D3D11.3), D3D12, OpenGL 3. Vulkan support has :doc:`a few notes <../behind_scenes/vulkan_support>`, as does :doc:`D3D12 <../behind_scenes/d3d12_support>`. -Future API support is at this point not clear; Metal, WebGL, and perhaps D3D9/D3D10 all being possible. Support for new APIs will be balanced against all other work such as features for existing APIs, bugfixes. So if you care strongly about support for a new API make sure to `file an issue on github `_ or comment on an existing issue to register your interest. +Future API support is at this point not clear; Metal, WebGL, and perhaps D3D9/D3D10 all being possible. Support for new APIs will be balanced against all other work such as features for existing APIs, bugfixes. So if you care strongly about support for a new API make sure to `file an issue on GitHub `_ or comment on an existing issue to register your interest. How can I backup or restore my settings? ---------------------------------------- @@ -80,7 +80,7 @@ RenderDoc doesn't install any registry keys on windows aside from those required Which network ports does RenderDoc use? --------------------------------------- -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. +RenderDoc uses TCP and UDP ports ``38920-38927`` consecutively for remote access and control (i.e. 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. RenderDoc also uses TCP and UDP ports ``39920`` for remote replay connections, for when a remote host is used to replay and analyse the capture. @@ -123,9 +123,9 @@ For texture formats that explicitly specify that they contain sRGB data this isn For other textures it's more difficult - for starters they may actually contain sRGB data but the correction is handled by shaders so there's no markup. Or indeed the application may not be gamma-correct so the data is sRGB but uncorrected. If we display these textures in a technically correct way, such that the data is not over or under gamma-corrected, the result often looks 'wrong' or unintuitively different from expected. -Nothing is actually wrong here except perhaps that when visualising linear data it is often more convenient to "overcorrect" such that the data is perceptually linear. A good example to use is a normal map: The classic deep blue of (127,127,255) flat normals is technically incorrect as everyone is used to visualising these textures in programs that display the data as if it were sRGB (which is the convention for normal images that do not represent vectors). +Nothing is actually wrong here except perhaps that when visualising linear data it is often more convenient to "over-correct" such that the data is perceptually linear. A good example to use is a normal map: The classic deep blue of (127,127,255) flat normals is technically incorrect as everyone is used to visualising these textures in programs that display the data as if it were sRGB (which is the convention for normal images that do not represent vectors). -You can override this behaviour on any texture that isn't listed as explicitly sRGB with the gamma (γ) button - toggle this off and the overcorrection will be disabled. +You can override this behaviour on any texture that isn't listed as explicitly sRGB with the gamma (γ) button - toggle this off and the over-correction will be disabled. RenderDoc makes my bug go away! Or causes new artifacts that weren't there -------------------------------------------------------------------------- diff --git a/docs/getting_started/features.rst b/docs/getting_started/features.rst index 8270066de..a028df672 100644 --- a/docs/getting_started/features.rst +++ b/docs/getting_started/features.rst @@ -60,7 +60,7 @@ Current Common Feature set * Python scripting console with full documented API, giving complete access to RenderDoc internals, core data structures, and the Qt UI itself. * Import and Export of captures - * Captures have an internal in-memory representation containing the full serialised data of all function calls, as well as associated metadat. + * Captures have an internal in-memory representation containing the full serialised data of all function calls, as well as associated metadata. * This capture representation can be used to export an ``.rdc`` file to another form that's easier for external tools to work with such as ``.xml``. * If the external format contains full expression of data, it can then be imported again back into an ``.rdc`` after modification. * This also allows generation of RenderDoc captures from arbitrary data into a standard format. @@ -95,7 +95,7 @@ OpenGL & OpenGL ES * Support for OpenGL ES 2.0 - 3.2 on Linux and Android. * Tree hierarchy of events defined by any of the standard or vendor-specific extensions, and ``KHR_debug`` object labels used for object naming. -Captures have a very limited amount of portability between machines. Many hardware-specific feature uses are baked into captures, and portability depends on how similar the captuer and replay hardware are, whether these feature uses can map the same in both cases. Captures are however completely portable between different OSes with sufficiently comparable hardware. +Captures have a very limited amount of portability between machines. Many hardware-specific feature uses are baked into captures, and portability depends on how similar the capture and replay hardware are, whether these feature uses can map the same in both cases. Captures are however completely portable between different OSes with sufficiently comparable hardware. See Also -------- diff --git a/docs/getting_started/gotchas_known_issues.rst b/docs/getting_started/gotchas_known_issues.rst index 399f2404b..2a2cbf913 100644 --- a/docs/getting_started/gotchas_known_issues.rst +++ b/docs/getting_started/gotchas_known_issues.rst @@ -12,7 +12,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 <../how/how_capture_frame>` 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/how_capture_frame>` before capturing, as this will force RenderDoc to serialise out all initial contents regardless, at the cost of larger capture files 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. diff --git a/docs/getting_started/quick_start.rst b/docs/getting_started/quick_start.rst index de7aec7fa..e980aa4ae 100644 --- a/docs/getting_started/quick_start.rst +++ b/docs/getting_started/quick_start.rst @@ -14,7 +14,7 @@ To capture a frame, begin by selecting :guilabel:`File` → :guilabel:`Launch Ap Launching an executable -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 Launch to launch the application with RenderDoc. +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 Launch to launch the application with RenderDoc. More details of the specific options and their functionality can be found in the details page for the :doc:`../window/capture_attach`. @@ -37,7 +37,7 @@ When ready, press the Capture Key (:kbd:`F12` or :kbd:`Print Screen`) and the ne The in-application RenderDoc Overlay -When the application exits, if you captured a frame it will automatically start to open in the RenderDoc UI. If you didn't capture a frame then nothing will happen and the RenderDoc UI will be back as it was when you clicked Lanuch. +When the application exits, if you captured a frame it will automatically start to open in the RenderDoc UI. If you didn't capture a frame then nothing will happen and the RenderDoc UI will be back as it was when you clicked Launch. 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 :doc:`../window/capture_connection` for more information on taking multiple frame captures. Note however that for the simple use-case, you don't need to worry about this! @@ -139,7 +139,7 @@ The timeline bar is essentially an alternate view of the frame, with the horizon The frame marker hierarchy is top-down in this case, and can be expanded or collapsed by clicking on each section. In this image, "Render Scene" and "Toon shading draw" are both expanded, but the other sections remain collapsed. Each drawcall is rendered as a blue pip underneath the section of the hierarchy that it is a child of. The current drawcall (if visible) is rendered as a green circle. -There is a vertical line around the current drawcall, as well as a |flag_green| above, and a grey outline around the event where the mouse is hovering. +There is a vertical line around the current drawcall, as well as a |flag_green| above, and a gray outline around the event where the mouse is hovering. 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. diff --git a/docs/how/how_android_capture.rst b/docs/how/how_android_capture.rst index 52df86582..61746df64 100644 --- a/docs/how/how_android_capture.rst +++ b/docs/how/how_android_capture.rst @@ -3,7 +3,7 @@ How do I use RenderDoc on Android? RenderDoc contains support for Android for both Vulkan and OpenGL ES. It requires a couple of extra steps more than capturing on a desktop computer, but generally the workflow is very similar. -Android support is still quite new, so if you run into any rough spots please `open an issue on github `_ or `email me `_. +Android support is still quite new, so if you run into any rough spots please `open an issue on GitHub `_ or `email me `_. .. caution:: @@ -56,6 +56,6 @@ If you have Android Studio open, it will interfere with RenderDoc's debugging by RenderDoc does its best to locate or provide necessary android tools. On windows, these tools are shipped with the distributions and all that's required is java - either in your ``PATH`` or via the ``JAVA_HOME`` environment variable. If these tools aren't present then RenderDoc searches through ``PATH`` and other variables like ``ANDROID_HOME`` or ``ANDROID_SDK_ROOT`` to find the SDK. If you don't have those variables set, you can browse to the SDK and JDK folders in the :doc:`settings window <../window/settings_window>` under the :guilabel:`Android` section. -If something goes wrong with these steps, please `open an issue on github `__! The process should be as smooth as possible given Android's platform limitations, so if you encounter problems then it may well be fixable. +If something goes wrong with these steps, please `open an issue on GitHub `__! The process should be as smooth as possible given Android's platform limitations, so if you encounter problems then it may well be fixable. Often when an operation fails, more information is available via :guilabel:`Help` → :guilabel:`View Diagnostic Log`. diff --git a/docs/how/how_inspect_pixel.rst b/docs/how/how_inspect_pixel.rst index 403ccb79c..52aa81057 100644 --- a/docs/how/how_inspect_pixel.rst +++ b/docs/how/how_inspect_pixel.rst @@ -54,7 +54,7 @@ Pixel History When you have a pixel selected, you can click 'History' to open up a pixel history view showing every modification to the selected texture from the start of the frame to the currently selected event. -This display shows each modifying event as its own row, colored as to whether any modifications happened from this event or not - green for fragments that passed all pipeline tests, red for where fragments failed some test, and light grey for arbitrary shader writable resources where it's unknown if there was a write. +This display shows each modifying event as its own row, colored as to whether any modifications happened from this event or not - green for fragments that passed all pipeline tests, red for where fragments failed some test, and light gray for arbitrary shader writable resources where it's unknown if there was a write. You can expand each event to see if there were multiple fragments, and see the shader output value from each fragment. diff --git a/docs/in_application_api.rst b/docs/in_application_api.rst index 2cbcea7a6..1b9011be4 100644 --- a/docs/in_application_api.rst +++ b/docs/in_application_api.rst @@ -318,7 +318,7 @@ The other way is a closer integration, where your code will explicitly load Rend It is advised to call this function twice - first to obtain ``pathlength`` so that sufficient space can be allocated. Then again to actually retrieve the path. -The path follows the template set in :cpp:func:`SetLogFilePathTemplate` so it may not be an absolute path. +The path follows the template set in :cpp:func:`SetCaptureFilePathTemplate` so it may not be an absolute path. .. cpp:function:: void TriggerCapture() diff --git a/docs/window/buffer_viewer.rst b/docs/window/buffer_viewer.rst index 3f8d6d12e..82cf4a0fe 100644 --- a/docs/window/buffer_viewer.rst +++ b/docs/window/buffer_viewer.rst @@ -49,7 +49,7 @@ In the 3D Mesh preview, you have the option to display the mesh with some solid * Flat Shaded will perform basic flat lighting calculations based on triangle normals to give a better idea of the topology of the mesh. * Secondary will display the selected secondary mesh element. -To select which element will be displayed as secondary, simply right click on the column you would like to use. This can be done on the input and output separately, and 4-component columns have the option to either show RGB as color, or alpha as greyscale. +To select which element will be displayed as secondary, simply right click on the column you would like to use. This can be done on the input and output separately, and 4-component columns have the option to either show RGB as color, or alpha as grayscale. The selection will be remembered as long as the mesh format stays consistent between draws. @@ -65,7 +65,7 @@ The dropdown above the mesh view will let you choose to show :guilabel:`this dra These let you narrow or expand the mesh outputs displayed. At minimum you will see the current draw - a specific instance, if the drawcall is an instanced draw. You can also display other instances in the same drawcall (either up to the selected instance, or all instances before or after the selected instance). Finally you can opt to display all other meshes up to the current draw in the same notional render pass. -The current draw is always dark tinted, instances within the same draw have a lighter red color, and other drawcalls in the pass will be light grey. +The current draw is always dark tinted, instances within the same draw have a lighter red color, and other drawcalls in the pass will be light gray. Raw Buffer Viewer ----------------- diff --git a/docs/window/capture_attach.rst b/docs/window/capture_attach.rst index b56471c48..4b3fc7770 100644 --- a/docs/window/capture_attach.rst +++ b/docs/window/capture_attach.rst @@ -95,7 +95,7 @@ This option modifies the above capturing of callstacks to only be saved for draw | :guilabel:`Enable API validation` Default: ``Disabled`` -Enable API validation 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 in the :doc:`debug_messages` window. +Enable API validation causes RenderDoc to enable the API's built-in debugging, and where possible serialise this out and include it in the capture for later inspection in the :doc:`debug_messages` window. * On D3D11 & D3D12 this will activate the D3D debug layer and save out any messages. * For OpenGL this means ``ARB_debug_output`` is automatically enabled. @@ -116,7 +116,7 @@ This option causes RenderDoc to hook into process creation calls from the target | :guilabel:`Save All Initials` Default: ``Disabled`` -RenderDoc will attempt to save overhead and particularly capture filesize 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. +RenderDoc will attempt to save overhead and particularly capture file 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. 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. @@ -124,7 +124,7 @@ In some cases this detection will be wrong, such as targets that are partially w | :guilabel:`Ref All Resources` Default: ``Disabled`` -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. +One method RenderDoc uses to keep capture file 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 capture file. Enabling this option will cause RenderDoc to include all live resources at the time of capture regardless of whether they are used or not. ---------- @@ -191,7 +191,7 @@ RenderDoc implements this behaviour by modifying the `AppInit_DLLs `. In short, linear data is 'overcorrected' to look as expected, but this behaviour can be overridden by toggling off this option. +A proper explanation of this is available in the :ref:`FAQ `. In short, linear data is 'over-corrected' to look as expected, but this behaviour can be overridden by toggling off this option. Alpha background ~~~~~~~~~~~~~~~~ diff --git a/docs/window/timeline_bar.rst b/docs/window/timeline_bar.rst index c32863119..5bf56aab8 100644 --- a/docs/window/timeline_bar.rst +++ b/docs/window/timeline_bar.rst @@ -21,7 +21,7 @@ Timeline Display 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. -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. +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 gray vertical line to indicate the current position, such that this is visible even when the relevant section is not expanded. 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. @@ -45,7 +45,7 @@ A colored triangle will be drawn under each pip that reads from the texture. If Pixel history event Display --------------------------- -When a pixel history window is focussed, the timeline bar will show the results over each EID with a red triangle to show rejected pixels and green triangles to show passed pixels. +When a pixel history window is focused, the timeline bar will show the results over each EID with a red triangle to show rejected pixels and green triangles to show passed pixels. .. figure:: ../imgs/Screenshots/PixelHistoryTimeline.png