summaryrefslogtreecommitdiffstats
path: root/examples/gpu-printing/README.md
diff options
context:
space:
mode:
authorTim Foley <tfoleyNV@users.noreply.github.com>2020-02-03 17:36:32 -0800
committerGitHub <noreply@github.com>2020-02-03 17:36:32 -0800
commitb415760d7f166eaad7fa27daa09edc9a8964c37e (patch)
tree1d9035d18dc6767ed4c4100a289365bd08a02514 /examples/gpu-printing/README.md
parent2c1fbf8330efc34b85e09ee9b101c6a55327778a (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.md47
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.