google
patch, add types to descriptormap
I've been working on a simple script to generate some of the boilerplate and having the types in the output makes it much simpler.
So here's a work in progress patch for adding the function argument types to the descriptormap output. I'm attaching it here for discussion & rejection or improvement.
Can you expand on why you want types added to the descriptor map? None of the integrations of clspv I'm aware of have found that to be necessary. What kind of boilerplate code are you generating?
@alan-baker This will be needed by clvk ultimately to support clGetKernelArgInfo (see https://www.khronos.org/registry/OpenCL/sdk/2.1/docs/man/xhtml/clGetKernelArgInfo.html). There is a Clang option to emit all the information required as metadata (see EmitOpenCLArgMetadata in Compiler.cpp). We need to decide how to represent it the descriptor map (or introduce another interface) and enable the behaviour with a new -cl-kernel-arg-info option. All passes that manipulate function signatures would require some work (thinking ClusterPodKernelArgumentsPass at least).
@notzed +1 with Alan's questions. I'm really curious to know why you need it.
I'm generating functions which set one or all of the arguments using near-native types. It seemed a simple utility given i need to process the files anyway.
hello.cl: kernel void hello(global char *dst, uint dsize, constant char *src, uint ssize)
generated hello-host.h: void hello_hello_setArgs(struct kernstate *state, VkDescriptorBufferInfo dst, int32_t dsize, VkDescriptorBufferInfo src, int32_t ssize)
If you have a number of simple type arguments this saves a map/umap each time, but it's mostly because it just seemed like a nice idea.
But really I was just exploring ideas and trying to understand how vulkan works.
I think we now have everything needed for clGetKernelArgInfo as we always compile with -cl-kernel-arg-info in clvk
