From a0416216ffaf3bd3b0533d967a6d62c477b22d09 Mon Sep 17 00:00:00 2001 From: jsmall-nvidia Date: Fri, 9 Aug 2019 14:14:56 -0400 Subject: Small improvements to CPU target docs (#1012) * Small fixes to CPU documentation. * Small typo fixes. --- docs/cpu-target.md | 30 ++++++++++++++---------------- 1 file changed, 14 insertions(+), 16 deletions(-) (limited to 'docs/cpu-target.md') diff --git a/docs/cpu-target.md b/docs/cpu-target.md index cc1e15b08..dc2319b6f 100644 --- a/docs/cpu-target.md +++ b/docs/cpu-target.md @@ -56,7 +56,7 @@ These can also be specified on the slang command line as `-target exe` and `-tar In order to be able to use the slang code on CPU, there needs to be binding via values passed to a function that the C/C++ code will produce and export. How this works is described in the ABI section. -That if a binary target is requested, the binary contents will be returned in a ISlangBlob just like for other targets. To use the CPU binary typically it must be saved as file and then potentially marked for execution by the OS before executing. It may be possible to load shared libraries or dlls from memory - but is a non standard feature, that requires unusual work arounds. +If a binary target is requested, the binary contents will be returned in a ISlangBlob just like for other targets. To use the CPU binary typically it must be saved as file and then potentially marked for execution by the OS before executing. It may be possible to load shared libraries or dlls from memory - but is a non standard feature, that requires unusual work arounds. Under the covers when slang is used to generate a binary via a C/C++ compiler, it must do so through the file system. Currently this means that the source (say generated by slang) and the binary (produced by the C/C++ compiler) must all be files. To make this work slang uses temporary files. That the reasoning for hiding this mechanism - and not return say filenames, is so that in the future when binaries are produced directly (for example with LLVM), nothing will need to change. @@ -90,17 +90,23 @@ void computeMain(ComputeVaryingInput* varyingInput, UniformState* uniformState); The UniformState struct typically varies by shader, and it holds all of the bindings. Where these are located can be determined by reflection. For example ``` +struct _S1 +{ + Thing_0 thing_0; + Thing_0 thing2_0; +}; + struct UniformState { - Thing_0* thing3_0; - RWStructuredBuffer outputBuffer_0; - Texture2D tex_0; - SamplerState sampler_0; + Thing* thing3; + RWStructuredBuffer outputBuffer; + Texture2D tex; + SamplerState sampler; _S1* _S2; }; ``` -That for C++ targets, the templated types are defined in the slang-cpp-prelude.h that is included. Note that `slang-cpp-prelude.h` *MUST* currently be within the search path passed to the compiler. By default with the CPU path, the path to the slang file is included as a 'system' include path, such that placing the slang-cpp-prelude.h file in the same directory as the slang source file should mean that it is found. +For C++ targets, the templated types are defined in the slang-cpp-prelude.h that is included. Note that `slang-cpp-prelude.h` *MUST* currently be within the search path passed to the compiler. By default with CPU code-generation, the file path to the slang file is included as a 'system' include path, such that placing the `slang-cpp-prelude.h` file in the same directory as the slang source file should mean that it is found. ConstantBuffers will become pointers to the type they hold (as thing3_0 is in the above structure). @@ -115,14 +121,6 @@ Resource types become pointers to interfaces that implement their features. For The `_S1` struct in the example above (which may have different names) is actually a struct that holds all of the entry point uniforms if there are any, in this case -``` -struct _S1 -{ - Thing_0 thing_0; - Thing_0 thing2_0; -}; -``` - Note that the this pointer is not directly reflected (although layout of uniform paramters in the struct are). Currently this pointer is just placed after all the other reflected bindings. @@ -178,11 +176,11 @@ struct RWStructuredBuffer RWStructuredBuffer values; // ... -Vector defValue = {}; // Zero initialize such that access +Vector defValue = {}; // Zero initialize such that read access returns default values values.at(3).x = 10; ``` -Note that [] would be turned into the `at` function, which takes the default value as a paramter provided by the caller. If this is then written to then only the defValue is corrupted. Even this mechanism not be quite right, because if we write and then read again from the out of bounds reference in HLSL we may expect that 0 is returned, whereas here we get the value that was written. +Note that [] would be turned into the `at` function, which takes the default value as a paramter provided by the caller. If this is then written to then only the defValue is corrupted. Even this mechanism not be quite right, because if we write and then read again from the out of bounds reference in HLSL we may expect that 0 is returned, whereas here we get the value that was last written. TODO ==== -- cgit v1.2.3