[Migrated] Document best practices for debugging/profiling.
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 3.4k
- Forks
- 125
- PR merge metrics
- No merged PRs in 30d
Description
Issue automatically imported from old repo: https://github.com/EmbarkStudios/rust-gpu/issues/578
Old labels: a: documentation,t: enhancement
Originally creatd by dvc94ch on 2021-04-05T21:18:54Z 👍: 2
These are things that I keep getting hung up on. It is clear how gdb/perf work for example, by using the ptrace/open_perf_event syscalls in the linux kernel. However when it comes to gpu programming there seems to be few tools that aren't vendor specific and it is completely unclear how they work to a non-gpu expert. To open up gpu programming to a larger audience, how to perform debugging/profiling tasks should be documented better.
I presume there is some sort of synchronizing primitive in vulkan that could be used for debugging to step through the code, but how would you sample the gpu stack for example?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files, tests, or entry points are named. Start by researching vendor-neutral GPU debugging and profiling workflows, including the Vulkan synchronization and GPU stack-sampling questions raised in the issue. Done means adding documentation that explains practical debugging and profiling approaches for non-GPU experts.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- computer-graphics, documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100