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/gpu-printing-ops.h | |
| 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/gpu-printing-ops.h')
| -rw-r--r-- | examples/gpu-printing/gpu-printing-ops.h | 55 |
1 files changed, 55 insertions, 0 deletions
diff --git a/examples/gpu-printing/gpu-printing-ops.h b/examples/gpu-printing/gpu-printing-ops.h new file mode 100644 index 000000000..bace8bc8a --- /dev/null +++ b/examples/gpu-printing/gpu-printing-ops.h @@ -0,0 +1,55 @@ +// gpu-printing-op.h + +// This file defines the various opcodes that +// will be used for GPU printing commands. +// +// Because the CPU will be doing printing on +// behalf of the GPU, the two processors need +// to agree on the values of these opcodes. +// Therefore we have set up this file to be +// included into both the C++ `gpu-printing.cpp` +// implementation and the Slang `printing.slang` +// file. +// +// Client code should defiine the `GPU_PRINTING_OP` +// macro appropriately, before including this file. +// +#ifndef GPU_PRINTING_OP +#error "Must define 'GPU_PRINTING_OP(NAME)' before including" +#endif + +// The `Nop` opcode is used to represent a vacuous +// printing command that does nothing. +// +// It's main purpose is to allow GPU code to zero +// out parts of the printing buffer to disable +// or shorten a printing command that was started. +// +GPU_PRINTING_OP(Nop) + +// The `NewLine` command is a compact way to +// print a newline character (`\n`) +GPU_PRINTING_OP(NewLine) + +// Simple value types like `int`, `uint`, and `float` +// can have their own printing commands for when +// they will be printed directly. +// +GPU_PRINTING_OP(Int32) +GPU_PRINTING_OP(UInt32) +GPU_PRINTING_OP(Float32) + +// String values are encoded in the print buffer as +// a 32-bit hash code, and are thus similar to +// the simple value cases in practice. +// +GPU_PRINTING_OP(String) + +// The final opcode we define is a complex `printf()` +// style operation that combines a format string with +// a variable amount of argument data to be referenced +// by that format string. +// +GPU_PRINTING_OP(PrintF) + +#undef GPU_PRINTING_OP |
