Linking dynamic pipeline shader libraries on Linux doesn't work as-is
I had to make the below changes to rps_rpsl_host_dll.c to get dynamic libraries to work on Linux. Not sure how portable these changes are back to windows but I'm sure it's possible to work out something more platform-independent.
- Branch: https://github.com/GPUOpen-LibrariesAndSDKs/RenderPipelineShaders/compare/main...expenses:RenderPipelineShaders:linux-dynamic-libraries
- Shader compilation script: https://github.com/expenses/rust-rps/blob/1306c542a55c1c699374e7ee6c4bb09574380c98/compile_dynamic.sh
diff --git a/src/runtime/common/rps_rpsl_host_dll.c b/src/runtime/common/rps_rpsl_host_dll.c
index 50a79e4..d408677 100644
--- a/src/runtime/common/rps_rpsl_host_dll.c
+++ b/src/runtime/common/rps_rpsl_host_dll.c
@@ -98,9 +98,9 @@ void ___rpsl_abort(uint32_t result)
}
uint32_t ___rpsl_node_call(
- uint32_t nodeDeclId, uint32_t numArgs, void** ppArgs, uint32_t nodeCallFlags, uint32_t nodeId)
+ uint32_t nodeDeclId, uint32_t numArgs, uint8_t** ppArgs, uint32_t nodeCallFlags, uint32_t nodeId)
{
- return (*s_rpslRuntimeProcs.pfn_rpsl_node_call)(nodeDeclId, numArgs, ppArgs, nodeCallFlags, nodeId);
+ return (*s_rpslRuntimeProcs.pfn_rpsl_node_call)(nodeDeclId, numArgs, (void**)ppArgs, nodeCallFlags, nodeId);
}
void ___rpsl_node_dependencies(uint32_t numDeps, const uint32_t* pDeps, uint32_t dstNodeId)
@@ -124,9 +124,9 @@ void ___rpsl_scheduler_marker(uint32_t opCode, uint32_t flags, const char* name,
(*s_rpslRuntimeProcs.pfn_rpsl_scheduler_marker)(opCode, flags, name, nameLength);
}
-void ___rpsl_describe_handle(void* pOutData, uint32_t dataSize, uint32_t* inHandle, uint32_t describeOp)
+void ___rpsl_describe_handle(uint8_t* pOutData, uint32_t dataSize, uint32_t* inHandle, uint32_t describeOp)
{
- (*s_rpslRuntimeProcs.pfn_rpsl_describe_handle)( pOutData, dataSize, inHandle, describeOp);
+ (*s_rpslRuntimeProcs.pfn_rpsl_describe_handle)( (void*)pOutData, dataSize, inHandle, describeOp);
}
uint32_t ___rpsl_create_resource(uint32_t type,
@@ -145,7 +145,7 @@ uint32_t ___rpsl_create_resource(uint32_t type,
type, flags, format, width, height, depthOrArraySize, mipLevels, sampleCount, sampleQuality, temporalLayers, id);
}
-void ___rpsl_name_resource(uint32_t resourceHdl, const char* name, uint32_t nameLength)
+void ___rpsl_name_resource(uint32_t resourceHdl, unsigned char* name, uint32_t nameLength)
{
(*s_rpslRuntimeProcs.pfn_rpsl_name_resource)(resourceHdl, name, nameLength);
}
@@ -190,7 +190,7 @@ uint8_t ___rpsl_dxop_isSpecialFloat_f32(uint32_t op, float a)
return (*s_rpslRuntimeProcs.pfn_rpsl_dxop_isSpecialFloat_f32)(op, a);
}
-int __declspec(dllexport) ___rps_dyn_lib_init(const ___rpsl_runtime_procs* pProcs, uint32_t sizeofProcs)
+int ___rps_dyn_lib_init(const ___rpsl_runtime_procs* pProcs, uint32_t sizeofProcs)
{
if (sizeof(___rpsl_runtime_procs) != sizeofProcs)
{
Thank you for reporting this. We will address this either as part of a small maintenance update or the next version.
Finding a platform-independent solution for the export declaration is definitely possible but your other changes leave me a little curious.
I do not see an obvious requirement for the usage of uint8_t pointers instead of void pointers and unsigned char strings instead of const char ones that is linux specific. Would you mind elaborating on these changes?
@FlorianHerickAMD
Without that I get these errors:
3d.rpsl.g.c:588:10: error: conflicting types for ‘___rpsl_node_call’; have ‘uint32_t(uint32_t, uint32_t, uint8_t **, uint32_t, uint32_t)’ {aka ‘unsigned int(unsigned int, unsigned int, unsigned char **, unsigned int, unsigned int)’}
588 | uint32_t ___rpsl_node_call(uint32_t, uint32_t, uint8_t**, uint32_t, uint32_t);
| ^~~~~~~~~~~~~~~~~
In file included from <command-line>:
./RenderPipelineShaders/src/runtime/common/rps_rpsl_host_dll.c:100:10: note: previous definition of ‘___rpsl_node_call’ with type ‘uint32_t(uint32_t, uint32_t, void **, uint32_t, uint32_t)’ {aka ‘unsigned int(unsigned int, unsigned int, void **, unsigned int, unsigned int)’}
100 | uint32_t ___rpsl_node_call(
| ^~~~~~~~~~~~~~~~~
3d.rpsl.g.c:590:6: error: conflicting types for ‘___rpsl_describe_handle’; have ‘void(uint8_t *, uint32_t, uint32_t *, uint32_t)’ {aka ‘void(unsigned char *, unsigned int, unsigned int *, unsigned int)’}
590 | void ___rpsl_describe_handle(uint8_t*, uint32_t, uint32_t*, uint32_t);
The output C file from rps-hlslc contains different functions declarations from what's in RenderPipelineShaders/src/runtime/common/rps_rpsl_host_dll.c:
/* Function Declarations */
static struct texture _BA__PD_make_default_texture_view_from_desc_AE__AE_YA_PD_AUtexture_AE__AE_IUResourceDesc_AE__AE__AE_Z(uint32_t, struct ResourceDesc*) __ATTRIBUTELIST__((nothrow)) __asm__ ("?make_default_texture_view_from_desc@@YA?AUtexture@@IUResourceDesc@@@Z");
uint32_t _BA__PD_bloom_mips_for_dimensions_AE__AE_YAIII_AE_Z(uint32_t, uint32_t) __ATTRIBUTELIST__((always_inline, nothrow)) __asm__ ("?bloom_mips_for_dimensions@@YAIII@Z");
void _BA__PD_compute_bloom_from_hdr_AE__AE_YAXUtexture_AE__AE_UFilterConstants_AE__AE__AE_Z(struct texture*, struct FilterConstants*) __ATTRIBUTELIST__((always_inline, nothrow)) __asm__ ("?compute_bloom_from_hdr@@YAXUtexture@@UFilterConstants@@@Z");
void rpsl_M_3d_Fn_hello_rpsl(struct texture*, struct FilterConstants*) __ATTRIBUTELIST__((nothrow));
void ___rpsl_abort(uint32_t);
uint32_t ___rpsl_node_call(uint32_t, uint32_t, uint8_t**, uint32_t, uint32_t);
void ___rpsl_block_marker(uint32_t, uint32_t, uint32_t, uint32_t, uint32_t, uint32_t, uint32_t);
void ___rpsl_describe_handle(uint8_t*, uint32_t, uint32_t*, uint32_t);
uint32_t ___rpsl_create_resource(uint32_t, uint32_t, uint32_t, uint32_t, uint32_t, uint32_t, uint32_t, uint32_t, uint32_t, uint32_t, uint32_t);
void ___rpsl_name_resource(uint32_t, uint8_t*, uint32_t);
uint32_t ___rpsl_dxop_binary_i32(uint32_t, uint32_t, uint32_t);
void rpsl_M_3d_Fn_hello_rpsl_wrapper(uint32_t, uint8_t**, uint32_t) __ATTRIBUTELIST__((noinline, nothrow));
Could you share with us your specific OS information, e.g. the output of cat /etc/os-release and the rpsl file used as source for the compiler? We are currently diagnosing an issue with the compiler that may be the cause of this.