diff options
| author | Tim Foley <tfoleyNV@users.noreply.github.com> | 2020-02-03 17:36:32 -0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2020-02-03 17:36:32 -0800 |
| commit | b415760d7f166eaad7fa27daa09edc9a8964c37e (patch) | |
| tree | 1d9035d18dc6767ed4c4100a289365bd08a02514 /examples/gpu-printing/README.md | |
| parent | 2c1fbf8330efc34b85e09ee9b101c6a55327778a (diff) | |
Initial steps on GPU printing example (#1197)
* Initial steps on GPU printing example
This change is checkpointing work on a new Slang example that shows how a "GPU `printf()`" can be implemented almost entirely in user space thanks to a combination of Slang language and API features.
The example is not perfect as it stands today due to limitations in our current handling of hashed string literals:
* At call sites where a string literal is passed, we currently have to explicitly invoke `getStringHash()` to get the hash code, because we don't currently support `String` as a function argument/parameter type.
* On the implementation side, because strings are passed as their `int` hash codes, we can't tell them apart from ordinary `int` arguments. The current code handles this by assuming an `int` is *always* a hashed string, which obviously isn't appropriate.
There are plenty of other limitations in the implementation presented, but the above are the two main things I'd like to address in follow-up work.
I would like to checkpoint this work on the application first, in order to keep work on the Slang implementation and the example as separate as possible.
* typo
Diffstat (limited to 'examples/gpu-printing/README.md')
| -rw-r--r-- | examples/gpu-printing/README.md | 47 |
1 files changed, 47 insertions, 0 deletions
diff --git a/examples/gpu-printing/README.md b/examples/gpu-printing/README.md new file mode 100644 index 000000000..826f4e316 --- /dev/null +++ b/examples/gpu-printing/README.md @@ -0,0 +1,47 @@ +GPU Printing +============ + +This example demonstrates how supporting for printing formatted messages from GPU shader code can be implemented in application code, using language and API features provided by Slang. + +Overview +-------- + +If you want to read the code here, start with `kernels.slang`, which contains a compute shader entry point showing how simple printing operations in shader code can be made. +Once you see the client code, you will probably want to understand the implementation, so that you can add these features to your own codebase. + +The GPU/shader part of the implementation resides in `printing.slang`, which provides a stand-alone Slang module intended to be brought into your code with `import`. +The comments in that file explain how the low-level implementaiton encoding of print data into buffers is performed, and then also shows how Slang language mechanisms can be used to wrap that low-level implementation in usable and extensible syntax. + +The CPU part of the implementation resides in `gpu-printing.{h,cpp}`, which are responsible for taking GPU-generated buffers encoded by the code above, and translating it into host-side calls to C `printf()` and other console printing operations. +The CPU code also shows how to use the Slang reflection API to extract information from a compiled program to enable printing of strings by their hash codes. + +The `main.cpp` file implements a small host application that loads the compute shader and executes it using the D3D11 API. +The code in this file is not especially relevant to the printing system. + +Adding printing support to your own codebase +-------------------------------------------- + +The code in this example is meant to provide a starting point for applications/frameworks/engines that want to allow shader code to print messages, for debugging logging, etc. +You can start by copying the `gpu-printing.{h,cpp}`, `gpu-printing-ops.h`, and `printing.slang` files into your codebase, and then modifying them to meet your needs. + +The implementation presented here is not feature-complete, so you may want to extend and customize it by: + +* Adapting it to use the graphics API or wrapper layer appropriate to your codebase + +* Making more GPU data types printable (including types specific to your application) + +* Adding overloads of `println()` and `printf()` to support more arguments + +* Customizing the encoding of print commands to make better use of space based on application-specific constraints + +* Handling extended `printf()` formatting (width, precision, etc.) in the CPU code + +Caveats +------- + +This code is not battle-tested, and it makes no promises about security. +It is probable that a malformed or malicious GPU shader could write data into the "print buffer" that causes the CPU code to invoke `printf()` or other C standard library functions with invalid arguments. + +In this implementation, GPU printing commands are only "flushed" by the CPU on draw/dispatch boundaries. +This means that the printing approach here cannot easily be used to diagnose deadlocks, infinite loops, or hardware/driver crashes. +Extending the implementation to better support such cases would likely depend on using platform- or hardware-specific knowledge or functionality. |
