05:13 jophish: Hi all
17:25 jekstrand: 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:26 jekstrand: jenatali, karolherbst: All the pre-pass stuff in VTN works without a shader stage and entrypoint name.
17:27 jekstrand: So making it dump out a list of entrypoints and their arguments shouldn't be hard.
17:28 jekstrand: But then that list would have to be translated into clover classes and libclc structs
17:38 karolherbst: jekstrand: because CL demands it
17:38 karolherbst: there is a reflection API so you can query paramter types and shit
17:38 karolherbst: and... we need to know the _declared_ type
17:38 karolherbst: not the actual one
17:38 karolherbst: so if it's "uniton Whatever" in the code, we have to return that
17:38 karolherbst: *union
17:39 karolherbst: but yeah, I'd like to get rid of it for most bits, just we need at least something
17:41 jekstrand: karolherbst: How do you detect unions from the SPIR-V?
17:42 karolherbst: you don't
17:42 jekstrand: Ok, then I'm confused. :)
17:42 karolherbst: check the code, you'll see how ugly it is
17:42 karolherbst: the translator adds debug strings
17:42 karolherbst: 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:43 karolherbst: so we get the literal string, vtn has 0 chance of reproducing besides parsing the custom stuff as well
17:43 karolherbst: jekstrand: https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/gallium/frontends/clover/spirv/invocation.cpp#L167
17:45 jekstrand: karolherbst: We can make VTN parse those...
17:46 karolherbst: yeah, I guess we could
17:46 karolherbst: it just feels gross
17:47 jekstrand: Is it more or less gross than both CL front-ends havig to carry around type and decoraiton parsing?
17:47 karolherbst: that arg.info stuff is what got added with CL 1.2
17:47 karolherbst: and we kind of have to have those kind of attributes somewhere
17:47 karolherbst: mhhh
17:47 karolherbst: good question
17:48 jekstrand: 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:49 jekstrand: 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:49 karolherbst: yeah, maybe
17:50 karolherbst: not sure how far I will come with my rust CL prototype, but not that far away from actually running kernels anymore
17:50 karolherbst: so maybe I prototype something there?
17:50 karolherbst: not sure
17:50 jekstrand: Neat!
17:50 karolherbst: but if you want to do something before that, :D
17:51 karolherbst: 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:52 jekstrand: :)
17:53 karolherbst: 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:53 karolherbst: wiring up llvm will be annoying though
17:54 karolherbst: and it's static pipeloader based :p
18:26 jekstrand: :)
20:04 karolherbst: dcbaker[m]: the compiler flag stuff is also not wired up in meson, nor does ninja recompile files after I changed rust flags
20:06 dcbaker[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:06 dcbaker[m]: I know I've written patches for it, anyway
20:06 karolherbst: uhm.. wait, I think I messed up testing a bit..
20:06 karolherbst: flags are passed
20:07 karolherbst: just recompiles not happening
20:07 karolherbst: ahh, okay
20:08 dcbaker[m]: Changing flags how? In the meson.build or by command line?
21:42 karolherbst: dcbaker[m]: via meson configure
21:43 dcbaker[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:44 karolherbst: still on 0.55.3
21:45 dcbaker[m]: Okay. I think in the long run we're going to want 0.57.x for rust
21:46 karolherbst: 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:46 dcbaker[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:46 dcbaker[m]: Pip install --user :)
21:47 dcbaker[m]: 0.57 will have color support for rust :)
21:47 karolherbst: cool :)
21:48 karolherbst: seems like latest in pip is 0.56.0
21:49 karolherbst: ohh nice, now I have to write endianness specific code.. let's see how that works out
21:59 karolherbst: yeah lol... bindgen seems to generate bindings for pipe_endian :/
21:59 karolherbst: *not
22:00 karolherbst: ohhh... because nothing references it inside the API...
22:28 jenatali: jekstrand: Yeah we could put it in VTN, we wrote what we have just because it seemed like it didn't belong in VTN