05:13jophish: Hi all
17:25jekstrand: jenatali, karolherbst: Is there any fundamental reason why clover and the new libclc thing need to have their own hand-rolled SPIR-V parser?
17:26jekstrand: jenatali, karolherbst: All the pre-pass stuff in VTN works without a shader stage and entrypoint name.
17:27jekstrand: So making it dump out a list of entrypoints and their arguments shouldn't be hard.
17:28jekstrand: But then that list would have to be translated into clover classes and libclc structs
17:38karolherbst: jekstrand: because CL demands it
17:38karolherbst: there is a reflection API so you can query paramter types and shit
17:38karolherbst: and... we need to know the _declared_ type
17:38karolherbst: not the actual one
17:38karolherbst: so if it's "uniton Whatever" in the code, we have to return that
17:39karolherbst: but yeah, I'd like to get rid of it for most bits, just we need at least something
17:41jekstrand: karolherbst: How do you detect unions from the SPIR-V?
17:42karolherbst: you don't
17:42jekstrand: Ok, then I'm confused. :)
17:42karolherbst: check the code, you'll see how ugly it is
17:42karolherbst: the translator adds debug strings
17:42karolherbst: so we can parse it out of the spir-v, but there is no spec of ext or whatever saying how to do it
17:43karolherbst: so we get the literal string, vtn has 0 chance of reproducing besides parsing the custom stuff as well
17:43karolherbst: jekstrand: https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/gallium/frontends/clover/spirv/invocation.cpp#L167
17:45jekstrand: karolherbst: We can make VTN parse those...
17:46karolherbst: yeah, I guess we could
17:46karolherbst: it just feels gross
17:47jekstrand: Is it more or less gross than both CL front-ends havig to carry around type and decoraiton parsing?
17:47karolherbst: that arg.info stuff is what got added with CL 1.2
17:47karolherbst: and we kind of have to have those kind of attributes somewhere
17:47karolherbst: good question
17:48jekstrand: I'm not saying that doing it in VTN is necessarily a good idea but it seems odd to me to have extra SPIR-V parsing kicking around.
17:49jekstrand: And if we can make it all a VTN prepass with a new "get_cl_function_args_for_spirv" entrypoint, maybe we should do that?
17:49karolherbst: yeah, maybe
17:50karolherbst: not sure how far I will come with my rust CL prototype, but not that far away from actually running kernels anymore
17:50karolherbst: so maybe I prototype something there?
17:50karolherbst: not sure
17:50karolherbst: but if you want to do something before that, :D
17:51karolherbst: jekstrand: yeah. device enumeration and using the gallium callbacks is alraedy wired up. The biggest thing in the middle is this command queue thing I want to pay around with
17:53karolherbst: and I will probably ignore the llvm/clang bits for now and go straight for spir-v kernels.. oh well, once I find time for it
17:53karolherbst: wiring up llvm will be annoying though
17:54karolherbst: and it's static pipeloader based :p
20:04karolherbst: dcbaker[m]: the compiler flag stuff is also not wired up in meson, nor does ninja recompile files after I changed rust flags
20:06dcbaker[m]: karolherbst: i need to check when that landed. Im pretty sure it's fixed in master,i need to see if it's in 0.56.1 and if not get it queued for backport
20:06dcbaker[m]: I know I've written patches for it, anyway
20:06karolherbst: uhm.. wait, I think I messed up testing a bit..
20:06karolherbst: flags are passed
20:07karolherbst: just recompiles not happening
20:07karolherbst: ahh, okay
20:08dcbaker[m]: Changing flags how? In the meson.build or by command line?
21:42karolherbst: dcbaker[m]: via meson configure
21:43dcbaker[m]: Okay, I'll add that to my list to look at on Monday.. Are you using 0.56.1, or something else? karolherbst
21:44karolherbst: still on 0.55.3
21:45dcbaker[m]: Okay. I think in the long run we're going to want 0.57.x for rust
21:46karolherbst: yeah, I guess. Just not in the mood of messing with system packages atm :D although I guess I could update it to rawhide once 0.57 is packaged
21:46dcbaker[m]: I've just been doing so much work that's in 0.56 and even more that won't be in till 0.57
21:46dcbaker[m]: Pip install --user :)
21:47dcbaker[m]: 0.57 will have color support for rust :)
21:47karolherbst: cool :)
21:48karolherbst: seems like latest in pip is 0.56.0
21:49karolherbst: ohh nice, now I have to write endianness specific code.. let's see how that works out
21:59karolherbst: yeah lol... bindgen seems to generate bindings for pipe_endian :/
22:00karolherbst: ohhh... because nothing references it inside the API...
22:28jenatali: jekstrand: Yeah we could put it in VTN, we wrote what we have just because it seemed like it didn't belong in VTN