GPU: Better integration with GPU debugging tools #105591

New Issue

Jeroen Bakker · 2023-03-09T10:09:10+01:00

Jeroen Bakker commented

2023-03-09 10:09:10 +01:00

Frame capture debugging tools like renderdoc or Xcode can currently
used to capture a full frame. During initial debugging this is fine
but when the cause is found a developer might want to focus on a
specific part of the code.

This proposal would allow better integration with GPU capture tools
using available extensions.

GPU_debug_capture_begin() will start recording a capture.
GPU_debug_capture_end() will stop the recording.

void *GPU_debug_capture_scope_create(const char *name);
bool GPU_debug_capture_scope_begin(void *scope);
bool GPU_debug_capture_scope_end(void *scope);

Where capture scopes define a capturable range within an application
which can be exposed to external tools to define a particular range
within which commands may occur.

The difference being capture begin/end would trigger immediately and
result in capture. Whereas a scope would not trigger a capture, but
allow the user to capture a range within an external tool (e.g. Xcode),
and then the first scope to be hit of the selected type would trigger.

Scopes could be created around certain places e.g. Overlay engine,
EEVEE engine, Workbench engine etc;

Developers can add calls to the functions during debugging to
focus on a specific shader/pass or other area.

This feature should only work when --gpu-debug is enabled as it
requires backend specific features to be enabled.

Benefits

Debugging background rendering. (we might also add those calls in the draw
manager when --gpu-debug is enabled so image rendering issues can also be
researched by users.
Developer can limit the amount of information inside their GPU debugger
allowing faster debugging.

Frame capture debugging tools like renderdoc or Xcode can currently used to capture a full frame. During initial debugging this is fine but when the cause is found a developer might want to focus on a specific part of the code. This proposal would allow better integration with GPU capture tools using available extensions. `GPU_debug_capture_begin()` will start recording a capture. `GPU_debug_capture_end()` will stop the recording. ``` void *GPU_debug_capture_scope_create(const char *name); bool GPU_debug_capture_scope_begin(void *scope); bool GPU_debug_capture_scope_end(void *scope); ``` Where capture scopes define a capturable range within an application which can be exposed to external tools to define a particular range within which commands may occur. The difference being capture begin/end would trigger immediately and result in capture. Whereas a scope would not trigger a capture, but allow the user to capture a range within an external tool (e.g. Xcode), and then the first scope to be hit of the selected type would trigger. Scopes could be created around certain places e.g. Overlay engine, EEVEE engine, Workbench engine etc; Developers can add calls to the functions during debugging to focus on a specific shader/pass or other area. This feature should only work when `--gpu-debug` is enabled as it requires backend specific features to be enabled. **Benefits** - Debugging background rendering. (we might also add those calls in the draw manager when `--gpu-debug` is enabled so image rendering issues can also be researched by users. - Developer can limit the amount of information inside their GPU debugger allowing faster debugging.

❤️ 2

Jeroen Bakker added this to the 3.6 LTS milestone 2023-03-09 10:09:10 +01:00

Jeroen Bakker added the

Type

Design

label 2023-03-09 10:09:10 +01:00

Jeroen Bakker added this to the EEVEE & Viewport project 2023-03-09 10:09:11 +01:00

Jeroen Bakker changed title from ~~GPU: Better integration with frame capture tools~~ to GPU: Better integration with GPU debugging tools

2023-03-09 10:13:51 +01:00

Michael Parkin-White commented

2023-03-09 15:06:43 +01:00

Looks good, I can submit a PR with an initial implementation supporting capture in the Metal backend, with placeholders for other APIs.

I would also propose the following extension:

Capture Scopes

void *GPU_debug_capture_scope_create(const char *name);
bool GPU_debug_capture_scope_begin(void *scope);
bool GPU_debug_capture_scope_end(void *scope);

Where capture scopes define a capturable range within an application which can be exposed to external tools to define a particular range within which commands may occur.

The difference being capture begin/end would trigger immediately and result in capture. Whereas a scope would not trigger a capture, but allow the user to capture a range within an external tool (e.g. Xcode), and then the first scope to be hit of the selected type would trigger.

Scopes could be created around certain places e.g. Overlay engine, EEVEE engine, Workbench engine etc;

Looks good, I can submit a PR with an initial implementation supporting capture in the Metal backend, with placeholders for other APIs. I would also propose the following extension: ###### Capture Scopes ``` void *GPU_debug_capture_scope_create(const char *name); bool GPU_debug_capture_scope_begin(void *scope); bool GPU_debug_capture_scope_end(void *scope); ``` Where capture scopes define a capturable range within an application which can be exposed to external tools to define a particular range within which commands may occur. The difference being capture begin/end would trigger immediately and result in capture. Whereas a scope would not trigger a capture, but allow the user to capture a range within an external tool (e.g. Xcode), and then the first scope to be hit of the selected type would trigger. Scopes could be created around certain places e.g. Overlay engine, EEVEE engine, Workbench engine etc;

Jeroen Bakker commented

2023-03-09 15:22:21 +01:00

These might be similar to

void GPU_debug_group_begin(const char *name);
void GPU_debug_group_end(void);

This is used by the Blender in multiple places to organize the calls in a hierarchy.

I do like the naming of GPU_debug_capture_scope_*

These might be similar to ``` void GPU_debug_group_begin(const char *name); void GPU_debug_group_end(void); ``` This is used by the Blender in multiple places to organize the calls in a hierarchy. ![image](/attachments/77bd6d59-f558-492b-a1a2-c00d13fd9ad1) I do like the naming of `GPU_debug_capture_scope_*`

image.png

41 KiB

image.png

34 KiB

Michael Parkin-White commented

2023-03-09 15:28:11 +01:00

Debug groups are great for naming regions within a captured frame, a capture scope would likely be a temporary insertion similar to calling begin/end() Which do the same thing as capture begin/end but allow triggering and capturing of that region from the tools, rather than instantaneously in the code.

Which may be useful if for example you need to defer an EEVEE frame capture until you have loaded up a specific file, or configured the scene in a particular way for example.

Debug groups are great for naming regions within a captured frame, a capture scope would likely be a temporary insertion similar to calling begin/end() Which do the same thing as capture begin/end but allow triggering and capturing of that region from the tools, rather than instantaneously in the code. Which may be useful if for example you need to defer an EEVEE frame capture until you have loaded up a specific file, or configured the scene in a particular way for example.

👍 2

Jason Fielder referenced this issue

2023-03-13 13:37:23 +01:00

GPU: Add GPU frame capture support. #105717

Jeroen Bakker referenced this issue from a commit

2023-03-16 08:54:19 +01:00

GPU: Add GPU frame capture support.

Sign in to join this conversation.