-
Notifications
You must be signed in to change notification settings - Fork 355
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat(gpu)!: GPU/OptiX support of ReParameter (#1686)
BREAKING CHANGE: to RendererServices ABI (including for CPU) and to the renderer-side setup when using OptiX. This overhauls the implementation of how interactively-editable parameters work, where they live in memory, and get it all working on GPU/OptiX so that renderers can support interactive adjustment of those params without recompiling shaders. The basic gist is as follows: * We continue work to finish making a clean separation between "interpolated" parameters and "interactive" (editable) parameters. * Interpolated params are collected and put into a separate memory area -- a separate per-group allocation on both the CPU and GPU (where applicable). It needs to remember the offset into this arena where each of the interpolated parameters resides. These allocations and eventual release are taken care of by the OSL shading system, they live in the ShaderGroup. When the group is set up, this block of memory is initialized with the correct initial values of the params and are ready to go. * The implementation of ReParameter writes to this special memory area also, that's how it works now (both CPU and GPU). * How does the OSL library know how to allocate, free, and copy to the device memory? It doesn't! Instead, we add new RendererServices methods `device_alloc()`, `device_free()`, and `copy_to_device()`. It's up to the renderer to provide those, so that the OSL library doesn't itself need to know about the Cuda runtime. These are trivial, there's really only one implementation that makes sense, and you can copy it from the ones in testshade and testrender. * Interactive parameters are NOT constant folded during runtime optimization. * The shader entry points themselves now take an extra parameter in the main call -- this will be the pointer to the beginning of the shader group's interactive parameter arena. * When JITing, references to interactive parameters know to retrieve them from their designated offset into the interactive parameter area. * This means that the renderer-side OptiX/Cuda code is responsible for adding this extra pointer parameter to the call to the shader entry points. You can see how this is done in the testshade and testrender Cuda code. * It's up to the renderer to figure out how to make the OptiX hit program aware of the interactive parameter pointer for that particular material, in order to pass it to the osl shader entry point. The way I did it in testshade and testrender is using a field in the struct that's given to each entry of the shader binding table and can be retrieved on the OptiX side via optixGetSbtDataPointer(). In testshade/testrender, a data pointer already existed which wasn't used. In a real renderer, you may need to add a field or come up with whatever other way you want to somehow get this pointer, which can be retrieved via shadingsys->getattribute(shadergroupptr, "device_interactive_params", TypeDesc::PTR, &myptr); you can see how I do that in optixraytracer.cpp (testrender) and in optixgridrender.cpp (testshade). A number of other things you will see that's worth calling out: I added a device_ptr utility template that is just a wrapper around a device side pointer that makes it hard to accidentally dereference it on the host side. Since I was changing RendererServices anyway, I also remove unused register_global, fetch_global, global_map which were unused. They were leftovers from the way we handled strings in OptiX 6.x. Encapsulate cuda global symbol name mangling into BackendLLVM::global_unique_symname(). I did this early on, turns out it wasn't necessary, but I still like that encapsulation, so I'm keeping it. I bumped the 3rd set of digits in the version to reflect that the changes in RendererServices break ABI. This is only in main, it obviously cannot be backported to a release branch. All tests pass for scalar and batch and optix. I added a new simple reparam test, and renamed the old reparem to reparam-array. Oddly, the reparam-array test doesn't work properly on optix (it had never been tried before), but it also failed in optix at main -- so it's not related to this patch! Putting that on my list of other oddities to investigate later. It may just be a quirk of testshade, I'm not really sure yet. Added to BackendLLVM (and batched) a llvm_ptr_type(TypeSpec) method that returns the LLVM type of a pointer to the specified type. Note: This patch doesn't account for the face that a parameter marked "interactive" could prevent a shader from correctly building for the GPU because it used the kind of construct that is fine in shader source code but only will work on GPU if it can be resolved to be a constant by the time we get done with the runtime optimization (as pointed out by Stephen Friedman. We'll come back to the problem later with a more robust and automatic fix -- and if we are lucky, Stephen will have the opportunity to upstream the approach he already has. Signed-off-by: Larry Gritz <[email protected]>
- Loading branch information
Showing
49 changed files
with
807 additions
and
324 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,72 @@ | ||
// Copyright Contributors to the Open Shading Language project. | ||
// SPDX-License-Identifier: BSD-3-Clause | ||
// https://github.com/AcademySoftwareFoundation/OpenShadingLanguage | ||
|
||
#pragma once | ||
|
||
#include <OSL/oslconfig.h> | ||
|
||
|
||
|
||
OSL_NAMESPACE_ENTER | ||
|
||
|
||
/// Wrapper class for holding a "device" pointer -- GPU or whatnot. It | ||
/// provides protections so that the pointer cannot easily be accessed on the | ||
/// host side, where presumably it would not be valid memory. | ||
template<class T> class device_ptr { | ||
public: | ||
device_ptr() = default; | ||
|
||
// Copy ctr from another device_ptr of the same type | ||
device_ptr(const device_ptr& other) = default; | ||
|
||
/// On device, device_ptr can construct from a pointer. | ||
/// On host, it must be explicitly constructed -- use with caution. | ||
#ifdef __CUDA_ARCH__ | ||
device_ptr(T* ptr) : m_ptr(ptr) {} | ||
#else | ||
explicit device_ptr(T* ptr) : m_ptr(ptr) {} | ||
#endif | ||
|
||
#ifdef __CUDA_ARCH__ | ||
/// On device, act as a pointer. None of these things are allowed on the | ||
/// host. | ||
T* operator->() const | ||
{ | ||
return m_ptr; | ||
} | ||
T& operator*() const | ||
{ | ||
return *m_ptr; | ||
} | ||
#endif | ||
|
||
/// Extract the raw device-side pointer. Use with caution! On the host, | ||
/// this will not point to valid memory. | ||
T* d_get() const | ||
{ | ||
return m_ptr; | ||
} | ||
|
||
/// Evaluate as bool is a null pointer check. | ||
operator bool() const noexcept | ||
{ | ||
return m_ptr != nullptr; | ||
} | ||
|
||
/// Reset the pointer to `dptr`, which must be a device-side raw pointer, | ||
/// or null. Since this device_ptr is non-owning, any previous value is | ||
/// simply overwritten. | ||
void reset(T* dptr = nullptr) | ||
{ | ||
m_ptr = dptr; | ||
} | ||
|
||
private: | ||
T* m_ptr = nullptr; // underlying pointer, initializes to null | ||
}; | ||
|
||
|
||
|
||
OSL_NAMESPACE_EXIT |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.