00:04 alyssa: airlied: real
00:05 alyssa: oh i see what it's complaining about
00:06 alyssa: or not.
00:07 airlied: alyssa: the warning just gives up after the file gets too big
00:08 airlied: nothing actually wrong
00:08 alyssa: got it
00:08 alyssa: sorry, we've been chasing a heisenbug all afternoon
00:08 alyssa: brain is kinda splat
00:53 jenatali: That is a lorge file
00:57 idr: holy smokes
00:58 airlied: zmike: I assume the only way to test VK_NV_compute_shader_derivatives would be piglit on zink? :)
00:58 zmike: probably
01:01 airlied: not sure how to implement it, just looking at missing bits :)
01:01 alyssa: airlied: common NIR lowering to quad ops?
01:01 airlied: probably can do linear easier than quad
01:01 alyssa: ?
01:01 alyssa: i havent actually read the extension
01:02 airlied: I assume you have to execute the "quad" in a workgroup
01:02 alyssa: oh i see
01:14 jenatali: I'm surprised it took this long: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23811#note_1982471
01:23 zmike: yes, I too am surprised I have not seen an EEE comment until now
01:30 jenatali: At least on GitLab
01:33 airlied: would it be bad if I added ...Ewoks?
01:35 jenatali: Do it
01:39 zmike: 🐔
01:42 alyssa: jenatali: EEEEEEE
01:43 alyssa: look how excited I am about you contributing it's making me squeal
01:43 alyssa: EEEE
01:43 alyssa: :P
01:54 tarceri: Anyone able to run this piglit test on the close nvidia driver for me? https://pastebin.com/r73KTYge I think the hdd is dead in the laptop I normally use for testing
01:58 zmike: I can get it tomorrow if nobody gets it before me
01:59 tarceri: Thanks!
05:08 cmarcelo: airlied: for NV_compute_shader_derivatives there are a couple of tests in crucible.
07:43 mripard: javierm: It's not really the same thing DPI is to send the pixels, SPI to control it
07:43 mripard: macromorgan: wants to operate the controller using SPI to send both
07:44 mripard: so it requires a massive undertaking, because then you don't need to connect to a CRTC, etc. You are the CRTC (and plane, and so on)
07:44 mripard: the controller setup is completely different too
07:45 mripard: so I don't think it's worth it to handle both cases in the same driver, we wouldn't be able to share much (if at all)
08:12 karolherbst: alyssa: because cross context stuff is weird
08:13 karolherbst: maybe something in st/mesa doesn't do some weirdo implicit flush
08:14 karolherbst: the programming model of gl doesn't really allow any kind of sanity here, so it's all implicit, and I guess if another context needs a resource we have to flush stuff out or _something_ didn't take a good look at those flakes, but .... something something
08:24 MrCooper: airlied: you're late to the party :P https://gitlab.freedesktop.org/mesa/mesa/-/issues/9281
08:31 javierm: mripard: thanks for the explanation. I thought that it was just a different transport just like some drivers support both SPI and I2C
08:32 mripard: yeah, those controllers are usually fairly flexible, and can indeed be controlled by I2C or SPI, but also take their pixels directly from these buses
08:33 mripard: the driver to handle the latter is panel-mipi-dbi
08:41 javierm: mripard: right, I know that there are some generic drivers dor mipi-dbi and mipi-dsi for controllers that don't have a custom init sequence (or that the init is handled by firmware?)
08:42 mripard: it's not the same answer for both cases :)
08:42 mripard: I don't think we assume anywhere that the firmware will init a panel
08:42 javierm: I've to admit that I'm not that familiar with dbi and dsi. But if you think that is not worth to share then a new tiny driver makes sense
08:42 mripard: especially since we like to power it up and down on demand
08:43 mripard: DBI is just a fancy MIPI word for sending data over SPI
08:44 javierm: mripard: because when I upstreamed the drivers/gpu/drm/panel/panel-himax-hx8394.c for the PinePhonePro, I was told that couldn't use the MIPI-DSI generic driver because it needed a custom init seq
08:45 javierm: so I wondered how panels that use that use drivers/gpu/drm/drm_mipi_dsi.c handle their init seq
08:45 javierm: mripard: how different is mipi-dbi with 4-wire SPI ? I wonder if the handling of D/C pin that macromorgan mentioned is just dbi ?
08:45 mripard: Those controllers are likely to need some kind of panel-specific initialization (which is usually quite obscure, and can't be made generic because it also depends on the panel tied to the controller). This is handled by the linux firmware interface and we will just request a firmware that contains the init sequence and send that to the controller
08:46 javierm: mripard: got it. That was my guess indeed, and for controllers that don't have a linux driver, then you need to do those mipi_dsi_dcs_write_seq() calls
08:47 mripard: DSI can handle pixels and control sequences over the bus, so then you have two cases: either the DSI panel doesn't require any initialization (instead of the dumb stuff everyone does like a reset GPIO or a regulator), in which case we should use panel-mipi-dsi
08:47 mripard: or it requires some kind of init sequence, in which case we have a panel-specific driver for it
08:47 mripard: which explains the answer you got for the Pinephone Pro I guess?
08:48 mripard: for the DC pin, I didn't read the whole discussion, let me have a look
08:49 mripard: ah right, I remember
08:49 mripard: it has an extra pin, or it can use an extra bit
08:49 mripard: I used it in 9 bits per word and ignored that pin entirely
08:50 javierm: mripard: yes, that's what I suggested macromorgan to do as well
08:51 javierm: so mipi-dbi is just the 3-wire SPI (that has a 1-bit D/C before the 8-bit payload)
08:51 mripard: not all SPI controllers can do that though, so I used a spi-gpio controller last time I used it
08:51 mripard: MIPI-DBI is 4 wire SPI iirc
08:51 mripard: that controller wanted to do something fancy, but that has nothing to do with the spec afaik
08:52 mripard: spi-gpio might be too slow if you're sending pixels with it too though
08:53 javierm: mripard: you said that mipi-dbi is 4-wire SPI, but you meant 3-wire right ?
08:53 javierm: 4-wire is with the D/C as an external pin and 3-wire is when is encoded in the payload
08:54 mripard: Clock, MISO, MOSI, CS ?
09:30 javierm: mripard: usually in the datasheets for these panels only clock, MOSI and CS are considered since you just write to the peripheral, not read from it
09:31 javierm: that's why is called 3-wire SPI protocol I think
09:31 mripard: sure, but you were asking for MIPI-DBI
09:31 mripard: whether the devices follow the spec is another story :)
09:32 javierm: mripard: right, but in panel lingo (at least in the datasheets I read) 3-wire is what I mentioned and 4-wire is with the additional D/C (data/command) external pin
09:33 javierm: mripard: so I wondered whether MIPI-DBI was the "3-wire protocol" that sends 9-bit SPI messages with the D/C bit encoded before the 8-bit payload
09:33 javierm: if that's the case, then I think that macromorgan can just use your driver ?
09:34 mripard: no, MIPI-DBI is plain old SPI
09:35 mripard: and no, he can't, because my driver is made for that controller taking its pixels from an RGB bus
09:35 javierm: mripard: I see
09:36 mripard: he needs to use panel-mipi-dbi
09:37 javierm: Ok
09:38 mripard: and just ignore that D/C pin, but use an extra bit per word
09:38 javierm: mripard: yup, which is the "3-wire protocol" I mentioned. But now I understand my confusion, you do that manually in your driver
09:38 javierm: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/panel/panel-sitronix-st7789v.c#L131
09:39 javierm: that u16 txbuf = ((prefix & 1) << 8) | data
09:39 javierm: so is "3-wire protocol" over mipi-dbi
12:00 alyssa: karolherbst: That test seems to glFinish() before each context switch. So should be fine. "should".
12:00 karolherbst: yeah..... "should"
12:02 karolherbst: alyssa: what I noticed while figuring out multithreading for nouveau is, that a lot of state tracking assumptions just don't hold anymore if you have a second context involved. But that also depends on how hardware vs context state is tracked.
12:02 pq: I wonder if Weston should glFinish() before exiting, too, to make sure no job is still running and upsetting ASan...
12:06 pq: No, that's not it.
12:12 pq: Huh. Making sure that swrast_dri.so is never unloaded *fixes* all ASan reported leaks.
12:13 karolherbst: can't have leaks if you never delete references
12:13 karolherbst: probably some screen cleanup not happening properly or something?
12:13 karolherbst: pq: we also have some static init methods around, like the glsl stuff
12:13 karolherbst: maybe some unref on it is missing?
12:14 karolherbst: kinda depends on what's leaked here
12:16 pq: It's a bit hard to see, because getting a good stack trace depends on not unloading...
12:17 karolherbst: mhhhh
12:17 karolherbst: I think there was a solution for this..
12:18 karolherbst: nvm
12:19 karolherbst: pq: https://github.com/google/sanitizers/issues/89#issuecomment-394822953 🙃
12:19 pq: building Mesa with ASan does something differently, but previously swrast always deadlocked inside ASan's own code. Maybe I need to try again, since I was actually able to run swrast with weston+ASan without deadlocking and no idea why.
12:19 karolherbst: pq: _but_ what valgrind calls "reachable" is probably what's leaking here
12:19 karolherbst: ohhh
12:19 karolherbst: valgrind can report that stuff if you use valgrind
12:20 karolherbst: pq: https://bugs.kde.org/show_bug.cgi?id=79362
12:20 karolherbst: maybe just use valgrind here...
12:20 karolherbst: *hideS*
12:22 pq: I can live with forcing swrast and making it never unload.
12:22 pq: That's what the Weston CI does, anyway.
12:23 karolherbst: though we really should fix those leaks I think :D
12:23 karolherbst: though.. might not matter
12:25 pq: this is something I gathered with radeonsi yesterday, ignoring the Mesa created threads: https://gitlab.freedesktop.org/-/snippets/7648 Does that look worthwhile to report?
12:26 pq: from Mesa 23.1.3
12:35 karolherbst: yeah.. probably
12:35 javierm: tzimmermann: hope that the motivation for the split makes more sense now after my explanation of how we manage the kernel package config options
13:00 zmike: tarceri: pass
13:01 tarceri: zmike: though it would thanks for testing
13:04 tarceri: seems we had a compile test for this kind of thing it mesa but it only passed because everything get optimised away.
16:14 alyssa: today on NIR control flow fun .. trying to figure out how to get the nir_if * from a nir_phi_instr *
16:15 jenatali: There might not be an if, it could be a loop
16:16 alyssa: sure, I can bail in that case
16:16 alyssa: I think logically I want ... previous sibling in CF tree?
16:16 alyssa: which should be either a nir_if or a nir_loop? maybe?
16:16 karolherbst: somebody broke my CL impl and I'm gonna find out who it was :< (probably llvm-16)
16:16 jenatali: Yeah that sounds right
16:17 jenatali: Why do you want that?
16:17 karolherbst: ...
16:17 karolherbst: call _Z29async_work_group_strided_copyPU3AS3hPU3AS1Khmm9ocl_event ssa_61, ssa_43, ssa_55, ssa_58, ssa_59 (0x1), ssa_60 (0x0)
16:17 karolherbst: pain
16:18 jenatali: What's wrong with that?
16:18 karolherbst: error: src->ssa->bit_size & bit_sizes (../src/compiler/nir/nir_validate.c:208)
16:18 jenatali: Fun
16:18 alyssa: jenatali: nir_opt_preamble, I want to (more or less) remat phis, which is only safe if I can remat the if-statement, which I can figure out based on the nir_if->condition
16:18 karolherbst: yeah.. I'll figure it out
16:19 jenatali: alyssa: It's not just one if condition though, you'd need to be able to remat all values leading up to the branches that the phi depends on
16:19 alyssa: that.. should be fine, I think
16:20 alyssa: phi can be remat <===> if-condition and all of the phi's sources can be remat
16:20 jenatali: e.g. if (a) { if (b) { %5 = 1; } else { %6 = 2; } } else { % 7 = 3; } could have a phi selecting any of those, so you'd need to be able to capture a and b
16:20 alyssa: right, if `b` can't be remat, then %5 can't either
16:20 jenatali: Right
16:20 alyssa: so `phi %5` at the end won't be remat even if a can be remat
16:21 alyssa: (Actually, it's more complicated than that. If %5 can be speculated, we can pull it out of the if when rematerializing so it wouldn't matter if b can be remat.)
16:22 alyssa: opt_preamble is a funny pass.
16:22 alyssa: I'm.. mostly sure what I'm doing is kosher, i just need to get at the if from the phi
16:22 alyssa: I guess nir_cf_node_prev(phi->instr->block)
16:24 jenatali: Should be right, yeah
16:25 karolherbst: jenatali: ... it's a 32 bit NULL pointer :')
16:25 jenatali: Weird
16:26 karolherbst: ehh wait.. maybe it's the return type being messed up actually
16:26 karolherbst: something weird is happening
16:26 alyssa: run: ../src/compiler/nir/nir_clone.c:504: clone_instr: Assertion `!"" "Cannot clone phis with clone_instr"' failed.
16:26 alyssa: Ahahaha that would've been too easy (-:
16:29 karolherbst: ehh wait.. the return value is the first argument
16:29 karolherbst: okay, so it's a null pointer of an event
16:33 jenatali: karolherbst: I thought events were 32-bit
16:33 karolherbst: why?
16:33 jenatali: Been a while since I looked at it, but I implemented that
16:33 karolherbst: it's opaque afaik
16:33 karolherbst: but
16:33 karolherbst: it's a `OpConstantNull` thing anyway
16:33 jenatali: Because nir doesn't model them, it just uses a 32-bit null
16:34 karolherbst: right...
16:34 karolherbst: maybe some type stuff going wrong
16:34 jenatali: So somehow you have the function decl saying that it should take a differently-sized thing than the function call site is giving it?
16:34 karolherbst: yes
16:35 karolherbst: we also have this weirdo mangling going on, but maybe the libclc is now different
16:35 jenatali: Fun
16:35 jenatali: That mangling looks fine to me
16:36 karolherbst: guess we have to select a different bit size for type event then...
16:36 karolherbst: yeah... mhh
16:37 jenatali: I take it that the ssa we're passing is 32-bit but the decl expects 64-bit?
16:37 karolherbst: well... kinda
16:38 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/compiler/spirv/spirv_to_nir.c#L1945
16:38 karolherbst: I suspect if llvm turned the event pointer to be 64 bit, then we kinda have to deal with that...
16:38 karolherbst: I'll try to figure out if it's a llvm or translator change
16:38 jenatali: I'd expect that the SPIR-V translator should still chase it to an event type, not a pointer to event
16:38 karolherbst: ohh true, but an event is opaque
16:39 jenatali: Right, so it should be passed by value, i.e. showing up in the function signature as a value type, and when vtn parses the decl it should put an int in the signature
16:39 karolherbst: why? an event isn't an int
16:39 jenatali: And then it's unused by the libclc implementation of the function so it'll all get DCE'd
16:40 jenatali: An event doesn't do anything in nir or in libclc, so we can pick whatever we want to represent it
16:40 jenatali: I tried to add a nir type for it and gfxstrand suggested to do it this way instead :P
16:40 karolherbst: right..
16:42 karolherbst: so the signature in the libclc spirv is: %6312 = OpTypeFunction %_ptr_Function_uchar %_ptr_Workgroup_uchar %_ptr_CrossWorkgroup_uchar %ulong %ulong %_ptr_Function_uchar
16:43 jenatali: Looks like the SPIRV-LLVM-Translator maybe changed the parsing from taking it by value to making it a byte*
16:44 karolherbst: mhh...
16:44 alyssa: jenatali: seems to work in the case I wanted it to
16:44 karolherbst: in llvm-15 it was `%Event = OpTypeEvent`
16:44 karolherbst: so they turned that into a pointer now
16:44 jenatali: Yeah
16:44 karolherbst: whoever it was
16:44 alyssa: which incidentally means entire CTS cases just get optimized away to absolutely nothing other than `gl_FragColor = <uniform>` and the whole case is in the preamble
16:44 alyssa: Lol
16:44 jenatali: Are you able to dump the LLVM IR?
16:45 karolherbst: jenatali: 062788212ce7544b896afbce9dd210c4fea5c0ea
16:45 karolherbst: in the translator
16:45 karolherbst: ehh wait
16:45 karolherbst: wrong commit...
16:46 karolherbst: uhh
16:46 karolherbst: opaque pointer stuff...
16:47 jenatali: Oh
16:47 jenatali: That makes sense, it was passed as a pointer-to-event in the LLVM IR probably and now the pointer loses its type info so the translator can't chase it anymore
16:47 jenatali: Fun... anyway should be easy enough to just make the event pointer-sized instead of always 32-bit
16:48 karolherbst: yeah...
16:48 karolherbst: just wondering how to properly deal with it...
16:49 karolherbst: however.. I wonder
16:49 karolherbst: maybe we have to enable opaque pointers now
16:50 jenatali: As long as the translator can deal with it, that sounds fine
16:51 karolherbst: other bugs
16:51 karolherbst: :D
16:54 Lynne: how can I get the GFX version from an anv_physical_device?
16:56 cmarcelo: Lynne: there's an info field. dev->info.ver or dev->info.verx10
16:58 cmarcelo: verx10 give you a more "detailed" number if you need to distinguish between vers.
17:00 Lynne: thanks!
17:00 karolherbst: that's.... better I think?
17:02 karolherbst: uhhhhh...
17:02 karolherbst: something is horribly broken
17:03 karolherbst: jenatali: which opaque pointers enabled, I get the event type into the function arg, but now it does... this:
17:03 karolherbst: %call6 = OpGroupAsyncCopy %Event %uint_2 %101 %add_ptr %conv5 %ulong_1 %88
17:03 karolherbst: %107 = OpBitcast %_ptr_Function__ptr_Function_uchar %event
17:03 karolherbst: OpStore %107 %call6 Aligned 8
17:04 jenatali: Awesome
17:04 jenatali: Maybe we should write nir_builder routines for those async copies
17:04 karolherbst: well.. it's invalid spirv
17:04 jenatali: Oh a bitcast from an opaque type, sure
17:04 karolherbst: not the bitcast
17:04 karolherbst: the store
17:05 karolherbst: it worked with opaque pointers disabled when I was forcing int64_t for events... so maybe just do this instead?
17:05 karolherbst: let's try again with llvm-17 with opaque pointers :D
17:06 karolherbst: jenatali: should we just u2u it inside vtn_opencl?
17:06 jenatali: I dunno
17:07 karolherbst: kinda dont't want to change the type depending on the llvm version...
17:16 karolherbst: I'll think about while prepping food...
17:16 karolherbst: but something is also super broken with images....
17:16 karolherbst: and I wouldn't be surprised if that's related
17:16 karolherbst: funny enough, it's only broken when using `llvm-spirv` to generate spir-vs...
17:17 jenatali: The built-in SPIR-V target is working?
17:17 karolherbst: no idea
17:17 karolherbst: that's with the translator still
17:18 karolherbst: the CTS just requires you to have an offline CLC to SPIR-V thing
17:18 karolherbst: mhh.. ohh right... duh
17:18 karolherbst: I should probably disable opaque pointers with it
17:21 karolherbst: I hope my 170 regressions are gone with "Xclang -no-opaque-pointers"...
17:21 karolherbst: but yeah, besudes the event stuff I don't think there is anything else in online compiled runs
17:25 karolherbst: mhh... yeah.. so a lot of invalid spir-v .. pain
18:50 karolherbst: uhhhhh
20:04 karolherbst: jenatali: okay.. I'm sure that 87848537db5948c5c9c8dcb06942b070c66d56a3 broke it
20:06 karolherbst: uhhh... no idea what to do about it though
20:06 karolherbst: but opaque stuff is really messed up it seems
20:09 karolherbst: but mhhh
20:10 karolherbst: with opaque pointers disabled it seems kinda fine, just the libclc spirv is bonkers and I have no idea why...
20:10 karolherbst: but llvm-spirv behaves differently that how clc compilers to spir-v and that's what's annoying me here
20:10 karolherbst: I've seen it in the past as well
20:25 karolherbst: I wonder if I want to bisect this...
20:27 karolherbst: yeah...
20:27 karolherbst: s
20:27 karolherbst: so
20:27 karolherbst: things just work with the old libclc spirv :(
20:27 karolherbst: uhhh
20:27 karolherbst: something messed up llvm-spirv
20:28 karolherbst: but that makes sense as all my spirv generated with it are also just broken
20:32 karolherbst: printf also broken: Printf string argument must be a pointer to a constant variable ...
20:32 karolherbst: I wished people would validate _all_ spirv in the translator...
21:03 karolherbst: yeah.....
21:03 karolherbst: uhhh
21:03 karolherbst: pain
21:04 karolherbst: soo.. using llvm-spirv we get a different spirv for a bunch of stuff
21:04 karolherbst: and using the translator like we do inside mesa generates the same spirv as with llvm-15 on 16 :/
21:05 psykose: llvm divorce time
21:06 karolherbst: uhh
21:06 karolherbst: I want to get stuff done like this year
21:06 karolherbst: but why....
21:07 karolherbst: llvm-spirv is just calling the same stuff...
21:09 karolherbst: mhhhhhh
21:10 karolherbst: the llvm ir is a little different, but huh...
21:12 karolherbst: mhhhhh
21:12 karolherbst: okay.. why can't I disable opaque pointers on the clang cli...
21:16 karolherbst: okay!
21:16 airlied: i thought opaque ptrs were the only way
21:16 karolherbst: I figured it out
21:17 karolherbst: airlied: nah...
21:17 airlied: with newer llvm
21:17 karolherbst: sooo
21:17 airlied: at some point they will be
21:17 karolherbst: libclang honors -no-opaque-pointers
21:17 karolherbst: but
21:17 karolherbst: clang doesn't
21:17 karolherbst: airlied: they are still very much broken sadly
21:17 karolherbst: and the translator is still generating broken code
21:17 karolherbst: anyway
21:18 karolherbst: the problam kinda is, that invoking `clang` on the cli doesn't honor the `-no-opaque-pointers` flag...
21:18 karolherbst: no idea if that's intentional or not
21:18 karolherbst: but it does have that option
21:18 karolherbst: it's just not doing anything
21:18 karolherbst: and the libclc we get is full of broken stuff
21:18 psykose: `time to open an issue :D
21:18 airlied: as i said they are meant to be the only option
21:19 airlied: since llvm 16 or 17
21:19 karolherbst: and as I said: they are still broken
21:19 karolherbst: and they are not
21:19 karolherbst: it works perfectly with with libclang-16
21:19 karolherbst: *fine
21:19 karolherbst: just not with clang-16
21:20 karolherbst: anyway.. even llvm docs specify you can still disable them
21:20 karolherbst: so I suspect some weirdo clang bug here
21:21 karolherbst: ahh and they still have _tons_ of tests setting that.. heh
21:22 airlied: https://llvm.org/docs/OpaquePointers.html
21:22 airlied: llvm 17 only opaque ptrs are supported
21:22 karolherbst: yes, but I'm on llvm-16
21:22 karolherbst: Also, "The opaque pointer mode can be disabled using -opaque-pointers=0 in LLVM tools like opt, or -Xclang -no-opaque-pointers in clang."
21:23 airlied: ah but going.forward disabling isnt an option we csn rely on
21:23 karolherbst: I know
21:23 karolherbst: but it's broken
21:23 karolherbst: the translator is still working through that stuff
21:24 airlied: ah its likely libclc or translator that need fixing, though maybe some opencl specific psths havent been fixed
21:24 karolherbst: yeah
21:24 karolherbst: so opaque types are bonkers
21:24 karolherbst: and some deref stuff is also broken
21:26 karolherbst: I'm sure with llvm-17 this will probably all just work
21:26 karolherbst: airlied: this sounds like the thing I'm hitting? https://github.com/KhronosGroup/SPIRV-LLVM-Translator/pull/2060
21:27 karolherbst: maybe not.. mhh
21:35 karolherbst: okay!
21:35 karolherbst: airlied: it works if calling `clang -cc1' directly :')
21:40 karolherbst: heh
21:40 karolherbst: llvm-as adds them back
21:40 karolherbst: interesting....
21:42 karolherbst: okay!
21:42 karolherbst: I figured it out
21:43 airlied: that mr does sound like it
21:46 karolherbst: so I think what happens is, that something in the llvm pipelines just translates to opaque pointers on it's own...
21:46 dj-death: have people built GL deqp surfaceless?
21:46 dj-death: what cmake magick are you using? :)
21:55 mattst88: dj-death: here are the cmake args we use in chromeos: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/main/media-gfx/deqp/deqp-2023.05.18-r4.ebuild#102
21:55 mattst88: -DDEQP_TARGET=surfaceless is the important one
22:02 karolherbst: yeah so that PR doesn't help :)
22:11 dj-death: mattst88: thanks, then I don't wtf is going on
22:11 dj-death: mattst88: angle appears to be using the system GL driver
22:12 dj-death: I thought angle was a GL implementation :)
22:20 jenatali: ANGLE is a GLES implementation
22:20 jenatali: It can run on a desktop GL driver
22:21 dj-death: ah got it
22:22 dj-death: I guess I need to build it for vulkan then
22:28 karolherbst: airlied: yeah soo.. the problem is that various tools are implicitly upgrading to opaque pointers and that bites us heavily :/
22:28 karolherbst: maybe we should just skip llvm-16, but uhhh....
22:29 karolherbst: though I think it would be okay to just use the llvm-15 libclc for now as that should just make everything work
22:50 karolherbst: anyway, the problem with printf looks like this:
22:50 karolherbst: %_str = OpVariable %_ptr_UniformConstant__arr_uchar_ulong_5 UniformConstant %11
22:50 karolherbst: %19 = OpBitcast %_ptr_UniformConstant_uchar %_str
22:50 karolherbst: %22 = OpExtInst %uint %1 printf %19 %uint_10
22:51 karolherbst: gfxstrand: ^^ a potential deref optimization we might want to support, where we bring back the array lengths back
22:52 karolherbst: though I think we might also have to stop relying on printf giving us a pointer to a sized array :')
22:57 karolherbst: anyway.. I'll deal with all of this later