summaryrefslogtreecommitdiffstats
path: root/examples/gpu-printing/gpu-printing-ops.h
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/gpu-printing-ops.h
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/gpu-printing-ops.h')
-rw-r--r--examples/gpu-printing/gpu-printing-ops.h55
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