<jenatali>
jekstrand: btw ping on that WSI change whenever you get a chance
<jenatali>
I don't need something thorough yet, it's not fully done, but a "this seems okay" vs "omg start over" would be appreciated
<jekstrand>
jenatali: Yeah. I've still got the tab open.
<jenatali>
Thanks!
OftenTimeConsuming is now known as Guest4246
OftenTimeConsuming has joined #dri-devel
Guest4246 has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
* karolherbst
wonders if iris should stop caring about clover once it's officially conformant with rusticl...
mbrost has quit [Ping timeout: 480 seconds]
kem has quit [Ping timeout: 480 seconds]
khfeng_ has joined #dri-devel
<HdkR>
karolherbst: Sounds reasonable to me
kem has joined #dri-devel
mbrost has joined #dri-devel
bmodem has joined #dri-devel
<jenatali>
"PASSED 35 of 35 tests." \o/
<karolherbst>
maybe I want to wire it up as well now
<jenatali>
karolherbst: What's there should be enough for basic cl_khr_gl_sharing, to get cl_khr_gl_event's implicit CL -> GL sync to work I had to rely on some driver-private details
khfeng_ has quit [Ping timeout: 480 seconds]
mbrost has quit [Read error: Connection reset by peer]
pendingchaos has quit [Ping timeout: 480 seconds]
khfeng_ has joined #dri-devel
mhenning has quit [Quit: mhenning]
khfeng_ has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
lanodan_ has quit [Ping timeout: 480 seconds]
bbrezillon has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Ping timeout: 480 seconds]
lanodan_ has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
paulk has joined #dri-devel
reductum has quit [Remote host closed the connection]
reductum has joined #dri-devel
Company has quit [Quit: Leaving]
Duke`` has joined #dri-devel
bgs has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
itoral has joined #dri-devel
fab has joined #dri-devel
rahul_janga has joined #dri-devel
bgs has quit [Remote host closed the connection]
kts has joined #dri-devel
danvet has joined #dri-devel
<Lynne>
karolherbst: I'm trying to test !19232 (rusticl on radeonsi) on navi21, but I'm not seeing any devices under the platform, regardless of envvars
<Lynne>
is that intended or is my hardware not supported yet?
mszyprow has joined #dri-devel
Akari has quit [Ping timeout: 480 seconds]
jlawryno has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
jewins1 has joined #dri-devel
<illwieckz>
Lynne, maybe you have to set RUSTICL_ENABLE=radeonsi
<dolphin>
airlied, danvet: super busy week, will send the initial drm-intel-gt-next early next week, if you folks are able to pull it, I'll then need to backmerge drm-next to bring in some dependencies
mvlad has joined #dri-devel
rahul_janga has quit [Read error: Connection reset by peer]
mszyprow has joined #dri-devel
tzimmermann has joined #dri-devel
bbrezillon has joined #dri-devel
srslypascal has quit [Read error: No route to host]
srslypascal has joined #dri-devel
tursulin has joined #dri-devel
khfeng_ has joined #dri-devel
<Lynne>
illwieckz: thanks, it was RUSTICL_ENABLE, not RUSTICL_DEVICE_ENABLE
<illwieckz>
👍️
fab has joined #dri-devel
<illwieckz>
note that since functions are inlined for now, some large kernels may take so much time to compile it's like it never ends
<illwieckz>
so make sure to have a proper way to kill an app you test
jewins1 has quit [Ping timeout: 480 seconds]
<danvet>
dolphin, ok
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<Lynne>
why is rusticl implemented on top of opengl drivers though, doesn't it make more sense to implement on top of vulkan?
<illwieckz>
it's not on top of opengl
<illwieckz>
both opengl and rusticl are implemented on top of gallium
<illwieckz>
and vulkan and gallium are basically side to side
rasterman has joined #dri-devel
<illwieckz>
there are some wip patches by karolherbst that are also making rusticl works over vulkan, but vulkan doesn't expose every feature a gpu has, so for example rusticl over gallium may one day implement the extensions required by CHIP-SPV to do HIP over OpenCL, but rusticl over vulkan has no way to be compatible with CHIP-SPV because of vulkan not providing required features
<Lynne>
right, I forgot radeonis is gallium
<Lynne>
*radeonsi
<Lynne>
hip on top of opencl -_-
<Lynne>
I think all vulkan needs to be a good general purpose compute platform is a good set of libraries and a good glsl->spv compiler
<Lynne>
glslang is bad enough that me and haasn considered ripping out the glsl -> nir -> spirv path mesa uses for zink into a separate library
khfeng_ has quit [Read error: Connection reset by peer]
khfeng_ has joined #dri-devel
<Lynne>
yup, I actually tried running the rusticl zink branch first a week ago but ran into a different issue (no platforms available at all)
pcercuei has joined #dri-devel
lynxeye has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
tlwoerner_ has joined #dri-devel
flto_ has joined #dri-devel
warpme____ has joined #dri-devel
Moe_Icenowy has joined #dri-devel
mmx_in_orbit__ has joined #dri-devel
kathleen_ has joined #dri-devel
cheako_ has joined #dri-devel
dschuermann_ has joined #dri-devel
ezequielg_ has joined #dri-devel
steev_ has joined #dri-devel
gouchi has joined #dri-devel
arnd_ has joined #dri-devel
gouchi has quit []
ernstp___ has joined #dri-devel
Eschik_ has joined #dri-devel
reduz___ has joined #dri-devel
rib____ has joined #dri-devel
rodrigovivi_ has joined #dri-devel
seanpaul_ has joined #dri-devel
krushia_ has joined #dri-devel
krh_ has joined #dri-devel
dianders_ has joined #dri-devel
zf_ has joined #dri-devel
flibit has joined #dri-devel
reductum_ has joined #dri-devel
everfree_ has joined #dri-devel
djbw_ has joined #dri-devel
orbea1 has joined #dri-devel
reductum has quit [synthon.oftc.net larich.oftc.net]
djbw has quit [synthon.oftc.net larich.oftc.net]
dviola has quit [synthon.oftc.net larich.oftc.net]
flto has quit [synthon.oftc.net larich.oftc.net]
genpaku has quit [synthon.oftc.net larich.oftc.net]
warpme___ has quit [synthon.oftc.net larich.oftc.net]
orbea has quit [synthon.oftc.net larich.oftc.net]
zehortigoza has quit [synthon.oftc.net larich.oftc.net]
flibitijibibo has quit [synthon.oftc.net larich.oftc.net]
Lyude has quit [synthon.oftc.net larich.oftc.net]
zf has quit [synthon.oftc.net larich.oftc.net]
andrey-konovalov has quit [synthon.oftc.net larich.oftc.net]
krushia has quit [synthon.oftc.net larich.oftc.net]
mareko has quit [synthon.oftc.net larich.oftc.net]
jolan has quit [synthon.oftc.net larich.oftc.net]
cheako has quit [synthon.oftc.net larich.oftc.net]
technopoirot has quit [synthon.oftc.net larich.oftc.net]
clever has quit [synthon.oftc.net larich.oftc.net]
Eschik has quit [synthon.oftc.net larich.oftc.net]
dianders has quit [synthon.oftc.net larich.oftc.net]
arnd has quit [synthon.oftc.net larich.oftc.net]
steev has quit [synthon.oftc.net larich.oftc.net]
ernstp__ has quit [synthon.oftc.net larich.oftc.net]
dschuermann has quit [synthon.oftc.net larich.oftc.net]
reduz__ has quit [synthon.oftc.net larich.oftc.net]
seanpaul has quit [synthon.oftc.net larich.oftc.net]
mmx_in_orbit_ has quit [synthon.oftc.net larich.oftc.net]
olv has quit [synthon.oftc.net larich.oftc.net]
ezequielg has quit [synthon.oftc.net larich.oftc.net]
kathleen has quit [synthon.oftc.net larich.oftc.net]
MoeIcenowy has quit [synthon.oftc.net larich.oftc.net]
everfree has quit [synthon.oftc.net larich.oftc.net]
tlwoerner has quit [synthon.oftc.net larich.oftc.net]
rib___ has quit [synthon.oftc.net larich.oftc.net]
rodrigovivi has quit [synthon.oftc.net larich.oftc.net]
krh has quit [synthon.oftc.net larich.oftc.net]
steev_ is now known as steev
olv_ has joined #dri-devel
jolan has joined #dri-devel
dviola has joined #dri-devel
kem has joined #dri-devel
zehortigoza has joined #dri-devel
genpaku has joined #dri-devel
mareko has joined #dri-devel
clever has joined #dri-devel
andrey-konovalov has joined #dri-devel
ZeZu has quit [Read error: Connection reset by peer]
technopoirot has joined #dri-devel
ZeZu has joined #dri-devel
Lyude has joined #dri-devel
sarahwalker has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest4330
bmodem has quit [Ping timeout: 480 seconds]
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
sarahwalker has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
Akari has joined #dri-devel
kts has quit [Quit: Leaving]
pendingchaos has joined #dri-devel
apinheiro has joined #dri-devel
devilhorns has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
oneforall2 has joined #dri-devel
dviola has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
mrkajetanp has joined #dri-devel
<haasn>
Lynne: what it needs is dynamic dispatch
<haasn>
You currently cannot do everything OpenCL kernels can do in Vulkan
<haasn>
And the restriction seems sort of artificial to me
jkrzyszt has quit [Remote host closed the connection]
<haasn>
like literally that's the only relevant difference between the Kernel and Compute classes in SPIR-V or w/e they're called
<Lynne>
wasn't there a spir-v extension for that?
<Lynne>
or am I confusing it with the pointer extension
mrkajetanp has quit [Remote host closed the connection]
<haasn>
there's an nvidia-specific extension to construct arbitrary command buffers
<haasn>
but it's not really usable
<haasn>
for one, too overengineered, for two, nvidia-only
itoral has quit [Remote host closed the connection]
<Lynne>
VK_NV_device_generated_commands?
<haasn>
that's the one
<Lynne>
couldn't you somewhat make up for it with pipeline libraries extension?
<Lynne>
you could precompile all combinations you think you might encounter and just bind a pipeline when you render
<Lynne>
it's not proper arbitrary construction, but a compiled pipeline is what, a megabyte tops?
<haasn>
you could do it with conditional execution and a fixed upper limit on the number of loops
<Lynne>
probably the same overhead as the extension itself, but I do agree a proper extension would allow libraries to target a command buffer passed to them without needing multiple dispatches
<Lynne>
didn't take that long for mesh shaders to go from nvidia only to a generic extension, for all we know, they're probably already working on a generic version
<Lynne>
...under top secrecy, very public
<airlied>
haasn: structured vs unstructued flow control is also a big difference
kts has joined #dri-devel
dviola has joined #dri-devel
fab has quit [Quit: fab]
<haasn>
airlied: what does that mean in this context? arbitrary goto?
<haasn>
seems like it yeah
<haasn>
> We found that the requirement for structured control flow can increase the number of registers allocated by 20 registers and impact performance as much as 2x.
<haasn>
heh
vliaskov has quit [Remote host closed the connection]
fab has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
<jenatali>
That sounds wrong but I don't know enough to dispute it
mbrost has joined #dri-devel
kts has quit [Quit: Leaving]
orbea1 has quit []
orbea has joined #dri-devel
kts has joined #dri-devel
heat has joined #dri-devel
pochu has quit [Quit: leaving]
mbrost has quit [Read error: Connection reset by peer]
<jenatali>
Oh sure, structurizing what was unstructured code can slow down performance, but if the content was authored structured I don't see why it would have to be worse
Akari has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
rgallaispou has joined #dri-devel
kkawg has joined #dri-devel
devilhorns has quit []
kts has quit [Quit: Leaving]
camus has quit []
flto_ has quit []
flto has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
jlawryno has quit [Ping timeout: 480 seconds]
yuq825 has left #dri-devel [#dri-devel]
gbelgurr has quit [Ping timeout: 480 seconds]
mszyprow has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
EricCurtin[m] has joined #dri-devel
kts has joined #dri-devel
jlawryno has joined #dri-devel
gbelgurr has joined #dri-devel
fxkamd has joined #dri-devel
jkrzyszt has joined #dri-devel
JohnnyonFlame has joined #dri-devel
rodrigovivi_ is now known as rodrigovivi
tzimmermann has quit [Quit: Leaving]
rodrigovivi has quit []
rodrigovivi has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
flibit has quit []
flibitijibibo has joined #dri-devel
mszyprow has joined #dri-devel
stuart has joined #dri-devel
<jenatali>
Hm, we should probably turn off the Windows runners for Amber CI
<jenatali>
Nobody's going to use Amber for anything on Windows...
kem has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
kem has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
swalker_ has joined #dri-devel
djbw_ has quit [Read error: Connection reset by peer]
swalker_ is now known as Guest4357
Guest4330 has quit [Remote host closed the connection]
jlawryno has quit [Ping timeout: 480 seconds]
kem has quit [Ping timeout: 480 seconds]
Guest4357 has quit [Ping timeout: 480 seconds]
kem has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
<bbrezillon>
danvet: I've been playing with dma_fence today, and I noticed something weird. Unlike dma_buf objects, dma_fences don't take an owner (struct module), so I wonder what happens if a fence created by a driver lasts longer than the driver itself (for instance, when some other driver still has a reference to this fence).
jkrzyszt has quit [Remote host closed the connection]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<FLHerne>
that Clover MR won't be controversial at all O.o
<karolherbst>
it won't why would it be?
<FLHerne>
there are at least maybe two people who actually use Clover for...something
<karolherbst>
yes 1. for benchmark against rusticl and 2. for....?
warpme____ has quit []
<karolherbst>
I am actually not aware of any application which seriously runs with clover. It might be fine for some data crunching stuff on r600, maybe radeonsi, but....
<FLHerne>
whatever that direct LLVM IR guy was doing, I guess
<karolherbst>
ahhh, that one. mhhh
<karolherbst>
guess they can use rusticl once the radeonsi stuff lands?
<FLHerne>
probably
<karolherbst>
though they might want to try getting in some patches to ship llvm bitcodes through the il interface and I'll tell them it's a terrible again once more
mszyprow has joined #dri-devel
srslypascal is now known as Guest4394
srslypascal has joined #dri-devel
<jenatali>
karolherbst: It's pretty easy to support though
<jenatali>
I don't disagree that it's terrible though
<karolherbst>
In rusticl it would be terribly problematic to add tho
<karolherbst>
though I sometimes think if we want to compile to the hw ISA before creating cl_kernel objects, but on the other hand....
<jenatali>
You can tell if the passed in binary is an LLVM blob by looking at the magic bits at the beginning
<jenatali>
If so, import it to LLVM and go through the SPIR-V -> NIR path
<karolherbst>
sure, but I'd convert that into spir-v and if that fails I'd return an error
<karolherbst>
but
<karolherbst>
the idea was to pass in hw specific LLVM bitcode
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
<jenatali>
eric_engestrom: Third time's the charm :)
<eric_engestrom>
almost
<eric_engestrom>
can you cherry-pick ee9c3d2625428ac4cf4e? that should fix the docs failure
<jenatali>
Yeah. Dunno what's going on with that docs job. I don't think that's my fault?
<jenatali>
Ah yeah
coreforge has joined #dri-devel
<eric_engestrom>
pfff
<eric_engestrom>
parse error in one of the rst files
<jenatali>
:(
<jenatali>
Getting to close to wanting to just hit the merge button on this one so my part is done, fixing/disabling the docs job can be done afterwards
<eric_engestrom>
I'd suggest diffing against main since it builds there
<eric_engestrom>
you can't merge unless the ci passes though
<jenatali>
Oh, you're right. That's fun
apinheiro has quit [Quit: Leaving]
<jenatali>
I guess this was an upgraded sphinx on the CI runner or something that required changes to the doc files?
<eric_engestrom>
this gives you the diff to fix that file: diff -up <(git show fdo/staging/21.3:docs/relnotes/21.3.0.rst) <(git show fdo:docs/relnotes/21.3.0.rst)
<bnieuwenhuizen>
unlikely with containers?
<eric_engestrom>
(replacing `fdo` with the name of your remote)
<jenatali>
If I was using bash
<eric_engestrom>
ah, I can't help in powershell xD
<eric_engestrom>
(and yeah sphinx is not pinned, and a new version got stricter with syntax errors)
<jenatali>
Uh... that relnotes file hasn't changed
<jenatali>
Ah, yep, your first attempt at merging !13848 failed
<eric_engestrom>
indeed, good catch
djbw_ has quit [Read error: Connection reset by peer]
<eric_engestrom>
I don't know why I didn't backport the fix right away
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<jenatali>
Ugh
<jenatali>
Want to fix the docs for me? :P I don't really know what I'm doing other than playing whack-a-mole with errors as they pop up
<eric_engestrom>
I'm so sorry, I did a really bad job with the docs back then D:
djbw_ has joined #dri-devel
<jenatali>
I'm not in any rush to merge this MR, just wanted it so that I'm not on the hook for Windows CI in amber, but looks like docs are a bigger problem atm
<jenatali>
Once they're clean the Windows change can go in
<eric_engestrom>
I don't have time now, but I can have a look next week
<eric_engestrom>
(ping me if I forget)
<jenatali>
Sounds good
<eric_engestrom>
btw you can build the docs locally to avoid the round-trip to the ci:
<eric_engestrom>
sphinx-build -W -b html docs public
anholt has joined #dri-devel
<jenatali>
Chances of that working on Windows... slim. I guess I could set up WSL to do it, but I suspect round-tripping to the CI would be faster overall
<eric_engestrom>
haha
<eric_engestrom>
fair
<eric_engestrom>
anyway, I'll go now, but I'll try to fix that next week :)
<jenatali>
Thanks!
<daniels>
jenatali: if only Windows could run Linux containers … !
<jenatali>
Heh
<eric_engestrom>
perhaps using a Linux Subsystem for Windows... you could call it LSW!
<eric_engestrom>
(that WSL name is so backwards)
<karolherbst>
don't worry, MS will use linux in a few years anyway :P
<jenatali>
Eh, it's a Windows Subsystem, it makes some sense
<bnieuwenhuizen>
what gets me is the "for" as I wouldn't say it is "for Linux", while "for Windows" would fit IMO
<jenatali>
I guess. It's a Windows subsystem for [running] Linux
* jenatali
shrugs
<coreforge>
I've got the problem that on arm64, EngineBuilder.create() in lp_build_create_jit_compiler_for_module returns a null pointer, error is something about no available targets being compatible with the triplet aarch64-unknown-linux-gnu.
<coreforge>
This isn't checked for and results in a segfault
<airlied>
sounds like a fatal error anywayd
<airlied>
bad llvm build likely
<coreforge>
it's the llvm-11 package from the debian repository, but I can try building it. clang works with the same triple on the same machine
<karolherbst>
jenatali: soooooo..... somebody told me that there is this beauty of a CL ext called "cl_ext_cxx_for_opencl". You don't have any plans of supporting that one, do you?
mszyprow has quit [Ping timeout: 480 seconds]
<jenatali>
Uh... where you can pass C++ to the API?
<karolherbst>
yep
<jenatali>
No, I had no plans of supporting that
<airlied>
coreforge: seems strange then
<karolherbst>
okay, good. I'd have nacked the patches anyway :)
<airlied>
whats erong eith c++ for cl :-p
<jenatali>
Clang doesn't support it, so we'd need an alternate way of converting it to SPIR-V
<karolherbst>
clang doesn't?
<jenatali>
I... don't think it does
<airlied>
i thought they were.uostreaming it
<karolherbst>
how do you compile OpenCL C++ code atm then?
<airlied>
intel or arm had forks
<jenatali>
Oh nevermind, godbot says it does
* karolherbst
runs
<Sachiel>
rust for opencl when
<karolherbst>
jenatali: btw.. when I tried to wire up spirv I ran into funky CTS fails, wondering if you encountered the same
<karolherbst>
Sachiel: through spir-v any time
<jenatali>
karolherbst: Hm, I feel like I had a similar problem but it was so long ago I don't remember...
<karolherbst>
honestly, people can go nuts on the frontend language as long as they give me valid spir-v
<karolherbst>
I'll discuss this on tuesday on the cl working group meeting
<karolherbst>
probbaly
<jenatali>
No, it doesn't
<karolherbst>
mhh
<jenatali>
I might not have gotten around to running the CTS tests for SPIR-V
<karolherbst>
ahh
mbrost has quit [Ping timeout: 480 seconds]
<karolherbst>
in case you are mildly interested, if you get something done and tested by tuesday, we could check if it's the same issue or not
<karolherbst>
doesn't even need spec constants supported
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<jenatali>
I have spec constants supported :P
<karolherbst>
all the better
<jenatali>
But yeah I'll see if I can find time to do that
<karolherbst>
just run the spirv_new thing and if fmod/frem fails, it's the same issue :P
<karolherbst>
but apparently they compare the spirv fmod/frem thing to OpenCL C fmod builtin, and I am sure that's not valid
<karolherbst>
like the env spec doesn't define ulps on frem/fmod
<karolherbst>
so the CTS can't expect them to match in precision
<karolherbst>
unless I missed something
<jenatali>
Then I assume I'd hit the same thing
<karolherbst>
yeah.. I would be surprised if you'd hit any other bug
<jenatali>
Since the SPIR-V op would get mapped to the nir op instead of libclc, which I'd just wire up natively to DIXL
<karolherbst>
correct
<karolherbst>
cl c doesn't have fmod anyway, so spirv fmod maps to nextafter(fmod) and frem to CL fmod, because it makes all sense
<jenatali>
I was just cleaning out the issue backlog for clon12, but I hit one that's going to be hell to debug... Geekbench 5 has a failing benchmark :(
<karolherbst>
heh...
<karolherbst>
I tried running it and got into a runtime issue
<karolherbst>
reported it to the geekbench folks, because it's impossible to debug
<karolherbst>
they said "can't reproduce" and then spam bots took over the ticket ¯\_(ツ)_/¯
<jenatali>
A runtime issue?
<karolherbst>
yeah
<karolherbst>
some exception about something
<karolherbst>
dunno
<karolherbst>
jenatali: "Internal error message: vector::_M_range_check: __n (which is 0) >= this->size() (which is 0)."
<karolherbst>
yeah dunno.. I might not implement all APIs 100% correctly
<jenatali>
Mostly works, just one of the tests is getting wrong data
<karolherbst>
yeah.. a few of those did run for me as well
<karolherbst>
not sure which one it crashed on
<jenatali>
Also if you were curious, clang apparently does have clc++ support, but it doesn't fully work when going to SPIR-V: https://godbolt.org/z/W34v13ne1
<karolherbst>
*sigh*
<jenatali>
The LLVM IR looks good but the SPIR-V makes the global constructor the only kernel in the output
<jenatali>
%56 is a function that calls the constructor and returns
<karolherbst>
duh
<karolherbst>
yeah..
<jenatali>
No other entrypoints in that file
<karolherbst>
seeing that now
<karolherbst>
though there is _Z10do_add_subPU3AS1Dv4_sS1_S1_S1_ ...
<karolherbst>
but no entrypoint decl for that one
<jenatali>
Yeah it's there, it's linkage-exported, but not a kernel in this SPIR-V
<karolherbst>
though you should be able to do that with a normal clang
<jenatali>
karolherbst: Anybody in particular that you think should review/ack that interop MR? Otherwise I'll probably merge it on Monday with your ack
<jenatali>
Eh should probably wait longer than that I guess