diff --git a/docs/FAQ.aml b/docs/FAQ.aml index dae403bf0..7cda58fc6 100644 --- a/docs/FAQ.aml +++ b/docs/FAQ.aml @@ -118,11 +118,10 @@ 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. + allows - OpenGL support is under development. Support for Mantle is currently under development + also. - Other APIs could be supported once the source is open as I've tried to structure + Other APIs could be supported as I've tried to structure things such that different back-ends can be slotted in without significant code changes. @@ -246,5 +245,49 @@ +
+ RenderDoc makes my bug go away! Or causes new artifacts that weren't there + + + For various tedious reasons RenderDoc's replay isn't (and in most cases can't be) a + perfect reproduction of what your code was executing in the application when captured, and it + can change the circumstances while running. + + + During capture the main impact of having RenderDoc enabled is that timings will change, and + more memory (sometimes much more) will be allocated. There are also slight differences to the + interception of Map() calls as they go through an intermediate buffer to be captured. Generally + the only problem this can expose is that when capturing a frame, if something is timing dependent + RenderDoc causes one or two very slow frames, and can cause the bug to disappear. + + + The two primary causes of differences between the captured program and the replayed log (for + better or for worse) are: + + + + + + Map()s that use DISCARD are filled with a marker value, so any values that aren't written + to the buffer will be different - in application you can get lucky and they can be previous + values that were uploaded, but in replay they will be 0xCCCCCCCC. + + + + + 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 + capture options. + + + + + +
diff --git a/docs/Features.aml b/docs/Features.aml index 5682b238b..9f6c5e84e 100644 --- a/docs/Features.aml +++ b/docs/Features.aml @@ -65,10 +65,12 @@ currently selected pipeline slot as it changes, rather than remaining on the given texture. Tabbed view for locking a view of a particular resource over time. Pixel value picking. + Save (in theory) any type of texture and format to various formats, dds as well as regular png/jpg. Several debug overlays for render targets - Wireframe, Depth pass/fail, Stencil pass/fail, - Clipping (below black/above white points), NaN/-ve/INF highlight. + Clipping (below black/above white points), NaN/-ve/INF highlight, quad overdraw. + Pixel history view. Custom visualisation shader support - e.g. decode custom packed formats or gbuffers. Vertex, Pixel and Compute shader debugging. Hot shader editing and replacement. diff --git a/docs/Gotchas.aml b/docs/Gotchas.aml index e70ded81c..7df76daa0 100644 --- a/docs/Gotchas.aml +++ b/docs/Gotchas.aml @@ -86,11 +86,6 @@ - - There is no pixel history at present. When pixel debugging you must select the - exact drawcall that you are interested in debugging. - - 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 @@ -98,11 +93,6 @@ the depth test. - - The instruction set for shader debugging is not complete, and some instructions may be - unimplemented leading to incorrect results when debugging. - - 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 diff --git a/docs/HowTo/HowToCustomShader.aml b/docs/HowTo/HowToCustomShader.aml index 34c359283..a7b0c6a49 100644 --- a/docs/HowTo/HowToCustomShader.aml +++ b/docs/HowTo/HowToCustomShader.aml @@ -107,6 +107,8 @@ uint RENDERDOC_TextureType; Depth + Stencil Depth (Multisampled) Depth + Stencil (Multisampled) + Cubemap + 2D texture (Multisampled) @@ -135,14 +137,17 @@ Texture2DArray<uint2> texDisplayTexStencilArray : register(t5); Texture2DMSArray<float2> texDisplayTexDepthMSArray : register(t6); Texture2DMSArray<uint2> texDisplayTexStencilMSArray : register(t7); Texture2DArray<float4> texDisplayTexCubeArray : register(t8); +Texture2DMSArray<float4> texDisplayTex2DMSArray : register(t9); Texture1DArray<uint4> texDisplayUIntTex1DArray : register(t11); Texture2DArray<uint4> texDisplayUIntTex2DArray : register(t12); Texture3D<uint4> texDisplayUIntTex3D : register(t13); +Texture2DMSArray<uint4> texDisplayUIntTex2DMSArray : register(t19); Texture1DArray<int4> texDisplayIntTex1DArray : register(t21); Texture2DArray<int4> texDisplayIntTex2DArray : register(t22); Texture3D<int4> texDisplayIntTex3D : register(t23); +Texture2DMSArray<int4> texDisplayIntTex2DMSArray : register(t29); 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 diff --git a/docs/HowTo/HowToDebugShader.aml b/docs/HowTo/HowToDebugShader.aml index a13ead830..d32ff79f2 100644 --- a/docs/HowTo/HowToDebugShader.aml +++ b/docs/HowTo/HowToDebugShader.aml @@ -144,8 +144,8 @@ output register along with a swizzle and typecast. Swizzles follow the standard hlsl rules - .[xyzw] or .[rgba] in any permutation or repetition will show those channels. - 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. + The custom typecast can be any of ,x ,i ,d ,f ,u ,b to display the register as hex, signed integer, + double, float, unsigned, or bitwise respectively. Watch window - custom register expressions evaluated. diff --git a/docs/HowTo/HowToInspectPixel.aml b/docs/HowTo/HowToInspectPixel.aml index 709fa9592..6eeee0245 100644 --- a/docs/HowTo/HowToInspectPixel.aml +++ b/docs/HowTo/HowToInspectPixel.aml @@ -60,6 +60,22 @@ about this is available: . +
+ 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, coloured 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 UAV writes 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. + Right clicking will allow you to launch the shader debugger at the given event for the selected + pixel. Currently this does not debug the specific fragment you selected, only the default behaviour + for debugging that event. + +
diff --git a/docs/Introduction.aml b/docs/Introduction.aml index 4f787df89..242bca301 100644 --- a/docs/Introduction.aml +++ b/docs/Introduction.aml @@ -14,17 +14,26 @@ and explanation of which features are available in RenderDoc and how to best use them. + + The latest information and discussion is always available on the + +GitHub wiki +wiki on GitHub +https://github.com/baldurk/renderdoc/wiki +. +
License RenderDoc is released under the MIT license, so there are no restrictions on your use of it either - commercial or non-commercial. - - - This license will also not change when the source is released, so any source modifications will be - equally unrestricted. + commercial or non-commercial. This includes the source release available on the + +GitHub repository +Source on GitHub +https://github.com/baldurk/renderdoc/issues +. Details of the licenses of third party software used in RenderDoc are included in the LICENSE file diff --git a/docs/Layout.content b/docs/Layout.content index 81bf97750..05ede5f0d 100644 --- a/docs/Layout.content +++ b/docs/Layout.content @@ -29,7 +29,7 @@ - + @@ -62,10 +62,11 @@ - + + diff --git a/docs/TheFuture.aml b/docs/TheFuture.aml index d8de49f47..05d32bfba 100644 --- a/docs/TheFuture.aml +++ b/docs/TheFuture.aml @@ -14,17 +14,6 @@ or delayed indefinitely. -
- Source Code Release - - - 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. - - -
Planned Features diff --git a/docs/TipsNTricks.aml b/docs/TipsNTricks.aml index b8781c1fd..56b7b290b 100644 --- a/docs/TipsNTricks.aml +++ b/docs/TipsNTricks.aml @@ -56,6 +56,9 @@ triggerFunc(); The next Swap() after this call will begin the captured frame, and the Swap() after that will end it (barring complications) + You can also use the RENDERDOC_StartFrameCapture and RENDERDOC_EndFrameCapture functions + to precisely define the period to be captured. For more information look at the renderdoc_app.h + header in the source code. 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. diff --git a/docs/Tokens.tokens b/docs/Tokens.tokens index f341c0dca..4fe87603f 100644 --- a/docs/Tokens.tokens +++ b/docs/Tokens.tokens @@ -1,8 +1,8 @@  - RenderDoc Contact - RenderDoc @ Crytek + Contact me + RenderDoc developer - Baldur Karlsson mailto:baldurk@baldurk.org?subject=RenderDoc%20feedback - + \ No newline at end of file diff --git a/docs/Windows/BufferViewer.aml b/docs/Windows/BufferViewer.aml index 0acf51dc7..d49727763 100644 --- a/docs/Windows/BufferViewer.aml +++ b/docs/Windows/BufferViewer.aml @@ -114,6 +114,9 @@ snormf - 32bit signed normalised value uintten - 4 component unsigned integer format, packed as 10:10:10:2 unormten - 4 component unsigned normalised format, packed as 10:10:10:2 + xuint - hex-formatted 32bit integer + xshort - hex-formatted 16bit integer + xbyte - hex-formatted 8bit integer diff --git a/docs/Windows/TextureViewer.aml b/docs/Windows/TextureViewer.aml index dc81b1d9e..a544882da 100644 --- a/docs/Windows/TextureViewer.aml +++ b/docs/Windows/TextureViewer.aml @@ -103,6 +103,12 @@ Pixel context displaying the surrounds of the picked pixel. + From here, once you have selected a pixel, you can also launch the + pixel debugger if you have + the drawcall that yo uwant to debug selected. You can also launch the + pixel history view which shows all + modifications that have happened to the texture since the start of the frame to the currently selected + event.
@@ -250,25 +256,17 @@ 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. + For Multisampled textures, this will allow you to select either a single sample to view across the image, + or to see a default-resolved image. Save Texture - 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. - - - - - Debug a Pixel - - This button is only enabled after a - pixel has been picked. - 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. + This allows you to save the currently visible texture. Several formats are supported and options are + available for mapping down complex formats (such as multisampled or 3D textures) to formats that don't support them + such as .png or .jpg. @@ -334,6 +332,10 @@ 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. + Quad Overdraw (Pass) will show a visualisation of the level of 2x2 quad overdraw + in the 'pass' - defined as all the drawcalls up to current with the same set of render targets. + Quad Overdraw (Draw) will show a similar visualisation to the above option, but + limited only to the current drawcall.