diff --git a/docs/behind_scenes/opengl_support.rst b/docs/behind_scenes/opengl_support.rst index 127ebdbae..a7f513357 100644 --- a/docs/behind_scenes/opengl_support.rst +++ b/docs/behind_scenes/opengl_support.rst @@ -51,7 +51,7 @@ OpenGL ES capture and replay on Android is natively supported. For more informat OS X ---- -OS X is not yet officially supported for OpenGL capture, however work is in progress on development builds. +OS X is not supported. See Also -------- diff --git a/docs/getting_started/faq.rst b/docs/getting_started/faq.rst index 895c8ab03..6f8d04f64 100644 --- a/docs/getting_started/faq.rst +++ b/docs/getting_started/faq.rst @@ -92,7 +92,7 @@ RenderDoc is licensed under the MIT license and the source is available on `GitH What are the requirements for RenderDoc? ---------------------------------------- -Currently RenderDoc expects Feature Level 11.0 hardware and above for D3D11. Lower levels will capture successfully, but on replay RenderDoc will fall back to WARP software emulation which will run quite slowly. +Currently RenderDoc expects Feature Level 11.0 hardware and above for D3D11 and D3D12. Lower levels will capture successfully, but on replay RenderDoc will fall back to WARP software emulation which will run quite slowly. For OpenGL RenderDoc will only capture core profile applications, in general, and expects at minimum to be able to create a core 3.2 context which includes a few key extensions. For more details see :doc:`../behind_scenes/opengl_support`. @@ -171,9 +171,9 @@ Note this is only supported on D3D11 and OpenGL currently, since Vulkan and D3D1 RenderDoc is complaining about my OpenGL app in the overlay - what gives? ------------------------------------------------------------------------- -The first thing to remember is that **RenderDoc only supports Core 3.2 and above OpenGL**. If your app is using features from before 3.2 it almost certainly won't work as most functionality is not supported. A couple of things like not creating a VAO (which is required in core profile) and using luminance textures (which don't exist in core profile) are allowed, but none of the fixed function pipeline will work, etc etc. +The first thing to remember is that **RenderDoc only supports Core Profile 3.2 and above OpenGL**. If your app is using deprecated compatibility profile features from before 3.2 it almost certainly won't work as most functionality is not supported. A couple of things like not creating a VAO (which is required in core profile) and using luminance textures (which don't exist in core profile) are allowed, but none of the fixed function pipeline will work, etc. -If your app is not using the ``CreateContextAttribs`` API then RenderDoc will completely refuse to capture, and will display overlay text to this effect using the simplest fixed-function pipeline code, so it will run on any OpenGL app, even on a 1.4 context or similar. +If your app is not using the ``CreateContextAttribs`` API then RenderDoc will assume your program uses legacy functionality and it will completely refuse to capture. The overlay will display text to this effect using the simplest fixed-function pipeline code, so it will run on any OpenGL app, even on a 1.4 context or similar. If your app did use the ``CreateContextAttribs`` API, RenderDoc will allow you to capture, but compatibility profiles will have a warning displayed in the overlay - this is because you could easily use old functionality which is still available in the context. @@ -182,9 +182,9 @@ Can I tell via the graphics APIs if RenderDoc is present at runtime? Yes indeed. Some APIs offer ways to do this already - ``D3DPERF_GetStatus()``, ``ID3DUserDefinedAnnotation::GetStatus()`` and ``ID3D11DeviceContext2::IsAnnotationEnabled()``. -In addition to those: +In addition to those the simplest way is to see if the RenderDoc module is loaded, using ``GetModuleHandleA("renderdoc.dll") != NULL`` or ``dlopen("librenderdoc.so, RTLD_NOW | RTLD_NOLOAD) != NULL``. There are also API specific ways to query: -Querying an ``ID3D11Device`` for UUID ``{A7AA6116-9C8D-4BBA-9083-B4D816B71B78}`` will return an ``IUnknown*`` and ``S_OK`` when RenderDoc is present. +Querying an ``ID3D11Device`` or ``ID3D12Device`` for UUID ``{A7AA6116-9C8D-4BBA-9083-B4D816B71B78}`` will return an ``IUnknown*`` and ``S_OK`` when RenderDoc is present. `GL_EXT_debug_tool `_ is implemented on RenderDoc, which is an extension I've proposed for this purpose (identifying when and which tool is injected in your program). It allows you to query for the presence name and type of a debug tool that's currently hooked. At the time of writing only RenderDoc implements this as I've only just proposed the extension publicly, but in future you can use the queries described in that spec. @@ -199,6 +199,8 @@ Querying an ``ID3D11Device`` for UUID ``{A7AA6116-9C8D-4BBA-9083-B4D816B71B78}`` #define GL_DEBUG_TOOL_NAME_EXT 0x678A #define GL_DEBUG_TOOL_PURPOSE_EXT 0x678B +On Vulkan `VK_EXT_tooling_info` will return an entry for RenderDoc. This extension will always be available when running under RenderDoc. + .. _unstripped-shader-info: My shaders have 'cbuffer0' and unnamed variables, how do I get proper debug info? diff --git a/docs/getting_started/features.rst b/docs/getting_started/features.rst index ecd00762e..638b3912e 100644 --- a/docs/getting_started/features.rst +++ b/docs/getting_started/features.rst @@ -13,7 +13,7 @@ Current Common Feature set * Trimming capture - capture file only contains data necessary for replaying the frame in question, not all textures & buffers ever created in the lifetime of the app. * Optional network support. The main way RenderDoc is used is capture & replay on the same machine, but you can also attach over the network, and replay on a remote host. * Multiple frame capture with ability to open side-by-side to compare. -* Event browsing, with standard perfmarker style tree. +* Event browsing, with API standard tree of markers. * Full graphics pipeline state display. * Resources bound to the pipeline are trimmed to what is actually in use, e.g. if a shader only references a texture in the first binding slot, textures in other binding slots will not be displayed by default. @@ -26,7 +26,7 @@ Current Common Feature set * Displays scene left-to-right in time, event hierarchy top-to-bottom. * *Not* scaled based on time of each drawcall * Individual draw events are shown as dots when the tree is full expanded. - * The currently selected resource in the texture viewer is highlighted below individual drawcalls visible that use it - e.g. red for 'used for read', green for 'used for write' + * The currently selected resource in the texture viewer is highlighted below individual drawcalls visible that use it - e.g. orange for 'used for read', pale blue for 'used for write' * Flexible resource inspector. @@ -80,8 +80,8 @@ D3D12 ----- * Support for D3D12 up to D3D12.3, Windows 10 only. -* Debug marker uses the PIXSetMarker macros that go through SetMarker/BeginEvent/EndEvent on the command list -* Vertex, Pixel and Compute shader debugging. +* Debug marker uses the SetMarker/BeginEvent/EndEvent functions on the command list or queue. +* Vertex, Pixel and Compute shader debugging for DXBC/fxc shaders. Vulkan ------ @@ -89,6 +89,8 @@ Vulkan * Support for Vulkan 1.2 on Windows, Linux, Android, and Stadia. * Event markers and object naming both come from ``VK_EXT_debug_utils`` or deprecated ``VK_EXT_debug_marker``. +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. + OpenGL & OpenGL ES ------------------ @@ -96,8 +98,6 @@ OpenGL & OpenGL ES * Support for OpenGL ES 2.0 - 3.2 on Linux, Windows, 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 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 9b9a496fd..f243f74a5 100644 --- a/docs/getting_started/gotchas_known_issues.rst +++ b/docs/getting_started/gotchas_known_issues.rst @@ -1,7 +1,7 @@ Gotchas & Known Issues ====================== -This page (hopefully) keeps up to date with any known issues, bugs, unimplemented or partially unimplemented features. +Here are some things to note, with known limitations of RenderDoc or uncommon gotchas that may cause problems. Things to Note -------------- diff --git a/docs/getting_started/quick_start.rst b/docs/getting_started/quick_start.rst index 330d13c29..758080847 100644 --- a/docs/getting_started/quick_start.rst +++ b/docs/getting_started/quick_start.rst @@ -93,7 +93,7 @@ The Event Browser is the primary method of stepping through the frame and browsi The columns can be customised and reordered, the |timeline_marker| select columns button (or right-click) will allow you to choose which columns are displayed. -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. +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. For more information on these markers, see :doc:`../how/how_annotate_capture`. .. |flag_green| image:: ../imgs/icons/flag_green.png .. |find| image:: ../imgs/icons/find.png @@ -123,7 +123,6 @@ 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 capture. To do this click on :guilabel:`Resolve Symbols` under the :guilabel:`Tools` menu. More details on this process can be found in the guide: :doc:`../how/how_capture_callstack`. Timeline Bar diff --git a/docs/introduction.rst b/docs/introduction.rst index cbcde275c..82e5d31db 100644 --- a/docs/introduction.rst +++ b/docs/introduction.rst @@ -18,19 +18,19 @@ If you just want to dive straight in and learn how to get started using RenderDo 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 :doc:`how/index` 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:`getting_started/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 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! +* RenderDoc is generally stable but you will still likely encounter bugs depending on your use case, especially as with graphics there is a lot of potential surface area and interactions. I am *always* happy to spend time to fix bugs, but bear in mind that I need information about how to reproduce your specific situation. If you're able to provide public reproducible steps please file an issue on GitHub, or if you need to share information privately please `email me `_. * 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:`getting_started/faq`, or the `GitHub issues list `_ to see if it's been reported. Documentation and Tutorials --------------------------- -Aside from the documentation that you are reading, I have recorded some `YouTube video tutorials `_ showing the use of some basic features and an introduction/overview. +Aside from the documentation that you are reading, I have recorded some `YouTube video tutorials `_ showing the use of some basic features and an introduction/overview. Note that these are quite old, from the first release of RenderDoc, but the basic workflows and operation is still similar. There is also a great presentation by `@Icetigris `_ which goes into some details of how RenderDoc can be used in real world situations: `Slides are available here `_ @@ -41,7 +41,7 @@ If you want to get in touch with any feature requests, suggestions, comments etc Bug reports can be submitted directly `via email `_, or also on the `GitHub issues list `_ where you can also find the full source code. -The `Builds page `_ always has the latest stable build downloads, as well as builds made from the source code each night for the bleeding edge. Stable releases update every month or so and are the typical releases to stick to for the most reliable experience. +The `Builds page `_ always has the latest stable build downloads, as well as builds made from the source code each night for the bleeding edge. Stable releases update every two months or so and are the typical releases to stick to for the most reliable experience. See Also --------