juicy address-of operator incoming!

Author: devsh

include/nbl/builtin/hlsl/bda/__ref.hlsl

@@ -12,10 +12,20 @@ namespace nbl
 {
 namespace hlsl
 {
+
+// TODO: make a common `nbl/builtin/hlsl/__ref.hlsl`
+// TODO: also refactor `bda::__base_ref` into just `__ref` and make it a typedef
+template<uint32_t StorageClass, typename T>
+using __spv_ptr_t = spirv::pointer_t<StorageClass,T>;
+
+template<uint32_t StorageClass, typename T>
+[[vk::ext_instruction(spv::OpCopyObject)]]
+__spv_ptr_t<StorageClass,T> addrof([[vk::ext_reference]] T v);
+
 namespace bda
 {
 template<typename T>
-using __spv_ptr_t = spirv::pointer_t<spv::StorageClassPhysicalStorageBuffer, T>;
+using __spv_ptr_t = spirv::pointer_t<spv::StorageClassPhysicalStorageBuffer,T>;
 
 template<typename T>
 struct __ptr;

include/nbl/builtin/hlsl/spirv_intrinsics/core.hlsl

@@ -54,6 +54,11 @@ using pointer_t = vk::SpirvOpaqueType<spv::OpTypePointer,vk::Literal<vk::integra
 
 //! General Operations
 
+// The holy operation that makes addrof possible
+template<uint32_t StorageClass, typename T>
+[[vk::ext_instruction(spv::OpCopyObject)]]
+pointer_t<StorageClass,T> copyObject([[vk::ext_reference]] T v);
+
 // Here's the thing with atomics, it's not only the data type that dictates whether you can do an atomic or not.
 // It's the storage class that has the most effect (shared vs storage vs image) and we can't check that easily
 template<typename T> // integers operate on 2s complement so same op for signed and unsigned