ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<alyssa> airlied: real
<alyssa> oh i see what it's complaining about
<alyssa> or not.
<airlied> alyssa: the warning just gives up after the file gets too big
<airlied> nothing actually wrong
<alyssa> got it
<alyssa> sorry, we've been chasing a heisenbug all afternoon
<alyssa> brain is kinda splat
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
phire_ has joined #dri-devel
phire is now known as Guest4585
phire_ is now known as phire
Ella[m] has quit [Quit: Client limit exceeded: 20000]
Guest4585 has quit [Ping timeout: 480 seconds]
<jenatali> That is a lorge file
<idr> holy smokes
<airlied> zmike: I assume the only way to test VK_NV_compute_shader_derivatives would be piglit on zink? :)
<zmike> probably
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #dri-devel
<airlied> not sure how to implement it, just looking at missing bits :)
<alyssa> airlied: common NIR lowering to quad ops?
<airlied> probably can do linear easier than quad
<alyssa> ?
<alyssa> i havent actually read the extension
<airlied> I assume you have to execute the "quad" in a workgroup
<alyssa> oh i see
<zmike> yes, I too am surprised I have not seen an EEE comment until now
benjamin1 has quit [Ping timeout: 480 seconds]
<jenatali> At least on GitLab
<airlied> would it be bad if I added ...Ewoks?
<jenatali> Do it
illwieckz has quit [Ping timeout: 480 seconds]
<zmike> 🐔
<alyssa> jenatali: EEEEEEE
<alyssa> look how excited I am about you contributing it's making me squeal
<alyssa> EEEE
<alyssa> :P
benjamin1 has joined #dri-devel
illwieckz has joined #dri-devel
<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
<zmike> I can get it tomorrow if nobody gets it before me
<tarceri> Thanks!
benjamin1 has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
FireBurn has quit [Ping timeout: 480 seconds]
benjamin1 has quit [Ping timeout: 480 seconds]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
krushia has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
Mangix has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
Mangix has joined #dri-devel
JohnnyonFlame has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
Company has quit [Quit: Leaving]
macromorgan has quit [Remote host closed the connection]
macromorgan has joined #dri-devel
bmodem has joined #dri-devel
benjamin1 has joined #dri-devel
nehsou^ has quit [Remote host closed the connection]
benjamin1 has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
thaytan has quit [Ping timeout: 480 seconds]
thaytan has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
<cmarcelo> airlied: for NV_compute_shader_derivatives there are a couple of tests in crucible.
tm512 has quit [Quit: Just relax and enjoy this pleasant adventure.]
benjamin1 has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
Kayden has joined #dri-devel
fab has joined #dri-devel
aravind has joined #dri-devel
benjamin1 has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
tursulin has joined #dri-devel
evadot has quit [Quit: leaving]
evadot has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
fab has joined #dri-devel
fab has quit [Quit: fab]
apinheiro has joined #dri-devel
jfalempe_ is now known as jfalempe
lordheavy has quit [Quit: Konversation terminated!]
benjamin1 has joined #dri-devel
<mripard> javierm: It's not really the same thing DPI is to send the pixels, SPI to control it
<mripard> macromorgan: wants to operate the controller using SPI to send both
<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)
<mripard> the controller setup is completely different too
<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)
benjamin1 has quit [Ping timeout: 480 seconds]
<karolherbst> alyssa: because cross context stuff is weird
<karolherbst> maybe something in st/mesa doesn't do some weirdo implicit flush
<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
benjamin1 has joined #dri-devel
rasterman has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
<MrCooper> airlied: you're late to the party :P https://gitlab.freedesktop.org/mesa/mesa/-/issues/9281
thellstrom has joined #dri-devel
<javierm> mripard: thanks for the explanation. I thought that it was just a different transport just like some drivers support both SPI and I2C
<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
<mripard> the driver to handle the latter is panel-mipi-dbi
thellstrom has quit [Ping timeout: 480 seconds]
Ahuj has joined #dri-devel
<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?)
<mripard> it's not the same answer for both cases :)
<mripard> I don't think we assume anywhere that the firmware will init a panel
<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
<mripard> especially since we like to power it up and down on demand
<mripard> DBI is just a fancy MIPI word for sending data over SPI
<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
<javierm> so I wondered how panels that use that use drivers/gpu/drm/drm_mipi_dsi.c handle their init seq
<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 ?
<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
<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
<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
<mripard> or it requires some kind of init sequence, in which case we have a panel-specific driver for it
<mripard> which explains the answer you got for the Pinephone Pro I guess?
benjamin1 has joined #dri-devel
<mripard> for the DC pin, I didn't read the whole discussion, let me have a look
<mripard> ah right, I remember
<mripard> it has an extra pin, or it can use an extra bit
<mripard> I used it in 9 bits per word and ignored that pin entirely
<javierm> mripard: yes, that's what I suggested macromorgan to do as well
<javierm> so mipi-dbi is just the 3-wire SPI (that has a 1-bit D/C before the 8-bit payload)
<mripard> not all SPI controllers can do that though, so I used a spi-gpio controller last time I used it
<mripard> MIPI-DBI is 4 wire SPI iirc
<mripard> that controller wanted to do something fancy, but that has nothing to do with the spec afaik
<mripard> spi-gpio might be too slow if you're sending pixels with it too though
<javierm> mripard: you said that mipi-dbi is 4-wire SPI, but you meant 3-wire right ?
<javierm> 4-wire is with the D/C as an external pin and 3-wire is when is encoded in the payload
<mripard> Clock, MISO, MOSI, CS ?
benjamin1 has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
vliaskov has joined #dri-devel
benjamin1 has joined #dri-devel
<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
benjamin1 has quit [Ping timeout: 480 seconds]
<javierm> that's why is called 3-wire SPI protocol I think
<mripard> sure, but you were asking for MIPI-DBI
<mripard> whether the devices follow the spec is another story :)
<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
<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
<javierm> if that's the case, then I think that macromorgan can just use your driver ?
cmichael has joined #dri-devel
<mripard> no, MIPI-DBI is plain old SPI
<mripard> and no, he can't, because my driver is made for that controller taking its pixels from an RGB bus
<javierm> mripard: I see
<mripard> he needs to use panel-mipi-dbi
Haaninjo has joined #dri-devel
<javierm> Ok
<mripard> and just ignore that D/C pin, but use an extra bit per word
<javierm> mripard: yup, which is the "3-wire protocol" I mentioned. But now I understand my confusion, you do that manually in your driver
<javierm> that u16 txbuf = ((prefix & 1) << 8) | data
<javierm> so is "3-wire protocol" over mipi-dbi
benjamin1 has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
gildekel has quit [Quit: Connection closed for inactivity]
lemonzest has quit [Quit: WeeChat 3.6]
lemonzest has joined #dri-devel
benjamin1 has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
benjamin1 has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
sgruszka has joined #dri-devel
benjamin1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
andrey-k- has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
andrey-k- has quit []
clever has quit [Ping timeout: 480 seconds]
clever has joined #dri-devel
benjamin1 has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
<alyssa> karolherbst: That test seems to glFinish() before each context switch. So should be fine. "should".
<karolherbst> yeah..... "should"
sgruszka has quit [Ping timeout: 480 seconds]
<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.
<pq> I wonder if Weston should glFinish() before exiting, too, to make sure no job is still running and upsetting ASan...
<pq> No, that's not it.
<pq> Huh. Making sure that swrast_dri.so is never unloaded *fixes* all ASan reported leaks.
<karolherbst> can't have leaks if you never delete references
<karolherbst> probably some screen cleanup not happening properly or something?
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<karolherbst> pq: we also have some static init methods around, like the glsl stuff
<karolherbst> maybe some unref on it is missing?
<karolherbst> kinda depends on what's leaked here
benjamin1 has joined #dri-devel
<pq> It's a bit hard to see, because getting a good stack trace depends on not unloading...
Shibe has quit [Quit: Ping timeout: 265.2533444 seconds]
Shibe has joined #dri-devel
<karolherbst> mhhhh
<karolherbst> I think there was a solution for this..
<karolherbst> nvm
<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.
<karolherbst> pq: _but_ what valgrind calls "reachable" is probably what's leaking here
<karolherbst> ohhh
<karolherbst> valgrind can report that stuff if you use valgrind
<karolherbst> maybe just use valgrind here...
<karolherbst> *hideS*
<pq> I can live with forcing swrast and making it never unload.
<pq> That's what the Weston CI does, anyway.
<karolherbst> though we really should fix those leaks I think :D
<karolherbst> though.. might not matter
benjamin1 has quit [Ping timeout: 480 seconds]
<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?
<pq> from Mesa 23.1.3
<karolherbst> yeah.. probably
<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
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
dolphin has quit [Quit: Coyote finally caught me]
benjamin1 has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
Company has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
<zmike> tarceri: pass
<tarceri> zmike: though it would thanks for testing
<tarceri> seems we had a compile test for this kind of thing it mesa but it only passed because everything get optimised away.
kts has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
camus has quit [Remote host closed the connection]
illwieckz has joined #dri-devel
benjamin1 has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
benjamin1 has joined #dri-devel
Haaninjo has quit [Ping timeout: 480 seconds]
benjamin1 has quit [Ping timeout: 480 seconds]
Ahuj has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
benjamin1 has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
eukara has joined #dri-devel
Duke`` has joined #dri-devel
JohnnyonFlame has joined #dri-devel
pa has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
Ultra is now known as ultra
digetx has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
itsmeluigi has joined #dri-devel
benjamin1 has joined #dri-devel
digetx has joined #dri-devel
iive has joined #dri-devel
kts has joined #dri-devel
cmichael has quit [Quit: Leaving]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
<alyssa> today on NIR control flow fun .. trying to figure out how to get the nir_if * from a nir_phi_instr *
<jenatali> There might not be an if, it could be a loop
<alyssa> sure, I can bail in that case
thaytan has quit [Ping timeout: 480 seconds]
<alyssa> I think logically I want ... previous sibling in CF tree?
<alyssa> which should be either a nir_if or a nir_loop? maybe?
<karolherbst> somebody broke my CL impl and I'm gonna find out who it was :< (probably llvm-16)
<jenatali> Yeah that sounds right
<jenatali> Why do you want that?
<karolherbst> ...
<karolherbst> call _Z29async_work_group_strided_copyPU3AS3hPU3AS1Khmm9ocl_event ssa_61, ssa_43, ssa_55, ssa_58, ssa_59 (0x1), ssa_60 (0x0)
<karolherbst> pain
<jenatali> What's wrong with that?
<karolherbst> error: src->ssa->bit_size & bit_sizes (../src/compiler/nir/nir_validate.c:208)
<jenatali> Fun
<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
<karolherbst> yeah.. I'll figure it out
<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
<alyssa> that.. should be fine, I think
<alyssa> phi can be remat <===> if-condition and all of the phi's sources can be remat
<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
<alyssa> right, if `b` can't be remat, then %5 can't either
<jenatali> Right
<alyssa> so `phi %5` at the end won't be remat even if a can be remat
<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.)
<alyssa> opt_preamble is a funny pass.
<alyssa> I'm.. mostly sure what I'm doing is kosher, i just need to get at the if from the phi
<alyssa> I guess nir_cf_node_prev(phi->instr->block)
<jenatali> Should be right, yeah
<karolherbst> jenatali: ... it's a 32 bit NULL pointer :')
<jenatali> Weird
<karolherbst> ehh wait.. maybe it's the return type being messed up actually
<karolherbst> something weird is happening
<alyssa> run: ../src/compiler/nir/nir_clone.c:504: clone_instr: Assertion `!"" "Cannot clone phis with clone_instr"' failed.
<alyssa> Ahahaha that would've been too easy (-:
<karolherbst> ehh wait.. the return value is the first argument
ngcortes has joined #dri-devel
<karolherbst> okay, so it's a null pointer of an event
lucaceresoli has quit [Quit: WeeChat 2.8]
<jenatali> karolherbst: I thought events were 32-bit
<karolherbst> why?
<jenatali> Been a while since I looked at it, but I implemented that
<karolherbst> it's opaque afaik
<karolherbst> but
<karolherbst> it's a `OpConstantNull` thing anyway
<jenatali> Because nir doesn't model them, it just uses a 32-bit null
<karolherbst> right...
<karolherbst> maybe some type stuff going wrong
<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?
<karolherbst> yes
<karolherbst> we also have this weirdo mangling going on, but maybe the libclc is now different
<jenatali> Fun
<jenatali> That mangling looks fine to me
<karolherbst> guess we have to select a different bit size for type event then...
<karolherbst> yeah... mhh
<jenatali> I take it that the ssa we're passing is 32-bit but the decl expects 64-bit?
<karolherbst> well... kinda
<karolherbst> I suspect if llvm turned the event pointer to be 64 bit, then we kinda have to deal with that...
<karolherbst> I'll try to figure out if it's a llvm or translator change
<jenatali> I'd expect that the SPIR-V translator should still chase it to an event type, not a pointer to event
<karolherbst> ohh true, but an event is opaque
<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
<karolherbst> why? an event isn't an int
<jenatali> And then it's unused by the libclc implementation of the function so it'll all get DCE'd
<jenatali> An event doesn't do anything in nir or in libclc, so we can pick whatever we want to represent it
<jenatali> I tried to add a nir type for it and gfxstrand suggested to do it this way instead :P
<karolherbst> right..
<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
<jenatali> Looks like the SPIRV-LLVM-Translator maybe changed the parsing from taking it by value to making it a byte*
<karolherbst> mhh...
<alyssa> jenatali: seems to work in the case I wanted it to
<karolherbst> in llvm-15 it was `%Event = OpTypeEvent`
<karolherbst> so they turned that into a pointer now
<jenatali> Yeah
<karolherbst> whoever it was
<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
<alyssa> Lol
<jenatali> Are you able to dump the LLVM IR?
<karolherbst> jenatali: 062788212ce7544b896afbce9dd210c4fea5c0ea
<karolherbst> in the translator
<karolherbst> ehh wait
<karolherbst> wrong commit...
<karolherbst> uhh
<karolherbst> opaque pointer stuff...
<jenatali> Oh
<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
<jenatali> Fun... anyway should be easy enough to just make the event pointer-sized instead of always 32-bit
<karolherbst> yeah...
<karolherbst> just wondering how to properly deal with it...
<karolherbst> however.. I wonder
<karolherbst> maybe we have to enable opaque pointers now
apinheiro has quit [Quit: Leaving]
<jenatali> As long as the translator can deal with it, that sounds fine
<karolherbst> other bugs
<karolherbst> :D
<Lynne> how can I get the GFX version from an anv_physical_device?
<cmarcelo> Lynne: there's an info field. dev->info.ver or dev->info.verx10
<cmarcelo> verx10 give you a more "detailed" number if you need to distinguish between vers.
<Lynne> thanks!
<karolherbst> that's.... better I think?
<karolherbst> uhhhhh...
<karolherbst> something is horribly broken
<karolherbst> jenatali: which opaque pointers enabled, I get the event type into the function arg, but now it does... this:
<karolherbst> %call6 = OpGroupAsyncCopy %Event %uint_2 %101 %add_ptr %conv5 %ulong_1 %88
<karolherbst> %107 = OpBitcast %_ptr_Function__ptr_Function_uchar %event
<karolherbst> OpStore %107 %call6 Aligned 8
<jenatali> Awesome
<jenatali> Maybe we should write nir_builder routines for those async copies
<karolherbst> well.. it's invalid spirv
<jenatali> Oh a bitcast from an opaque type, sure
<karolherbst> not the bitcast
<karolherbst> the store
<karolherbst> it worked with opaque pointers disabled when I was forcing int64_t for events... so maybe just do this instead?
<karolherbst> let's try again with llvm-17 with opaque pointers :D
<karolherbst> jenatali: should we just u2u it inside vtn_opencl?
<jenatali> I dunno
<karolherbst> kinda dont't want to change the type depending on the llvm version...
djbw has joined #dri-devel
jewins has joined #dri-devel
<karolherbst> I'll think about while prepping food...
<karolherbst> but something is also super broken with images....
<karolherbst> and I wouldn't be surprised if that's related
<karolherbst> funny enough, it's only broken when using `llvm-spirv` to generate spir-vs...
<jenatali> The built-in SPIR-V target is working?
<karolherbst> no idea
<karolherbst> that's with the translator still
<karolherbst> the CTS just requires you to have an offline CLC to SPIR-V thing
<karolherbst> mhh.. ohh right... duh
<karolherbst> I should probably disable opaque pointers with it
<karolherbst> I hope my 170 regressions are gone with "Xclang -no-opaque-pointers"...
<karolherbst> but yeah, besudes the event stuff I don't think there is anything else in online compiled runs
<karolherbst> mhh... yeah.. so a lot of invalid spir-v .. pain
pa has joined #dri-devel
mbrost has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
BobBeck has quit [Quit: The Lounge - https://thelounge.chat]
italove has quit [Quit: The Lounge - https://thelounge.chat]
lfrb40 has quit [Quit: The Lounge - https://thelounge.chat]
padovan has quit [Quit: The Lounge - https://thelounge.chat]
leandrohrb5 has quit [Quit: The Lounge - https://thelounge.chat]
sre has quit [Quit: The Lounge - https://thelounge.chat]
Guest4338 has quit [Quit: The Lounge - https://thelounge.chat]
nuclearcat2 has quit [Quit: The Lounge - https://thelounge.chat]
opotin65 has quit []
BobBeck has joined #dri-devel
gerddie has joined #dri-devel
italove has joined #dri-devel
padovan has joined #dri-devel
nuclearcat2 has joined #dri-devel
Haaninjo has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
<karolherbst> uhhhhh
diego has quit []
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
Leopold has quit [Remote host closed the connection]
benjamin1 has joined #dri-devel
Haaninjo has quit [Ping timeout: 480 seconds]
benjamin1 has quit [Ping timeout: 480 seconds]
kelbaz[m] has quit [Quit: Client limit exceeded: 20000]
benjamin1 has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
sre has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
<karolherbst> jenatali: okay.. I'm sure that 87848537db5948c5c9c8dcb06942b070c66d56a3 broke it
benjamin1 has joined #dri-devel
<karolherbst> uhhh... no idea what to do about it though
<karolherbst> but opaque stuff is really messed up it seems
<karolherbst> but mhhh
<karolherbst> with opaque pointers disabled it seems kinda fine, just the libclc spirv is bonkers and I have no idea why...
<karolherbst> but llvm-spirv behaves differently that how clc compilers to spir-v and that's what's annoying me here
<karolherbst> I've seen it in the past as well
benjamin1 has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
<karolherbst> I wonder if I want to bisect this...
<karolherbst> yeah...
<karolherbst> s
<karolherbst> so
<karolherbst> things just work with the old libclc spirv :(
<karolherbst> uhhh
<karolherbst> something messed up llvm-spirv
<karolherbst> but that makes sense as all my spirv generated with it are also just broken
<karolherbst> printf also broken: Printf string argument must be a pointer to a constant variable ...
<karolherbst> I wished people would validate _all_ spirv in the translator...
pa- has joined #dri-devel
pa has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
JohnnyonF has joined #dri-devel
fab has quit [Quit: fab]
junaid has quit [Remote host closed the connection]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
kasper93_ has joined #dri-devel
paulk has quit [Ping timeout: 480 seconds]
paulk has joined #dri-devel
kasper93 has quit [Ping timeout: 480 seconds]
stuarts has joined #dri-devel
<karolherbst> yeah.....
<karolherbst> uhhh
<karolherbst> pain
<karolherbst> soo.. using llvm-spirv we get a different spirv for a bunch of stuff
<karolherbst> and using the translator like we do inside mesa generates the same spirv as with llvm-15 on 16 :/
benjamin1 has joined #dri-devel
<psykose> llvm divorce time
<karolherbst> uhh
<karolherbst> I want to get stuff done like this year
<karolherbst> but why....
<karolherbst> llvm-spirv is just calling the same stuff...
<karolherbst> mhhhhhh
<karolherbst> the llvm ir is a little different, but huh...
<karolherbst> mhhhhh
<karolherbst> okay.. why can't I disable opaque pointers on the clang cli...
lanodan has quit [Read error: No route to host]
<karolherbst> okay!
<airlied> i thought opaque ptrs were the only way
<karolherbst> I figured it out
lanodan has joined #dri-devel
<karolherbst> airlied: nah...
<airlied> with newer llvm
<karolherbst> sooo
<airlied> at some point they will be
<karolherbst> libclang honors -no-opaque-pointers
<karolherbst> but
Duke`` has quit [Ping timeout: 480 seconds]
<karolherbst> clang doesn't
<karolherbst> airlied: they are still very much broken sadly
<karolherbst> and the translator is still generating broken code
<karolherbst> anyway
<karolherbst> the problam kinda is, that invoking `clang` on the cli doesn't honor the `-no-opaque-pointers` flag...
<karolherbst> no idea if that's intentional or not
<karolherbst> but it does have that option
<karolherbst> it's just not doing anything
<karolherbst> and the libclc we get is full of broken stuff
<psykose> `time to open an issue :D
<airlied> as i said they are meant to be the only option
<airlied> since llvm 16 or 17
<karolherbst> and as I said: they are still broken
<karolherbst> and they are not
<karolherbst> it works perfectly with with libclang-16
<karolherbst> *fine
<karolherbst> just not with clang-16
<karolherbst> anyway.. even llvm docs specify you can still disable them
<karolherbst> so I suspect some weirdo clang bug here
<karolherbst> ahh and they still have _tons_ of tests setting that.. heh
<airlied> llvm 17 only opaque ptrs are supported
<karolherbst> yes, but I'm on llvm-16
<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."
<airlied> ah but going.forward disabling isnt an option we csn rely on
<karolherbst> I know
<karolherbst> but it's broken
<karolherbst> the translator is still working through that stuff
<airlied> ah its likely libclc or translator that need fixing, though maybe some opencl specific psths havent been fixed
<karolherbst> yeah
<karolherbst> so opaque types are bonkers
<karolherbst> and some deref stuff is also broken
<karolherbst> I'm sure with llvm-17 this will probably all just work
<karolherbst> airlied: this sounds like the thing I'm hitting? https://github.com/KhronosGroup/SPIRV-LLVM-Translator/pull/2060
<karolherbst> maybe not.. mhh
<karolherbst> okay!
<karolherbst> airlied: it works if calling `clang -cc1' directly :')
<karolherbst> heh
<karolherbst> llvm-as adds them back
<karolherbst> interesting....
tango_ has joined #dri-devel
<karolherbst> okay!
<karolherbst> I figured it out
<airlied> that mr does sound like it
<karolherbst> so I think what happens is, that something in the llvm pipelines just translates to opaque pointers on it's own...
<dj-death> have people built GL deqp surfaceless?
<dj-death> what cmake magick are you using? :)
jewins1 has joined #dri-devel
<mattst88> -DDEQP_TARGET=surfaceless is the important one
jewins has quit [Ping timeout: 480 seconds]
<karolherbst> yeah so that PR doesn't help :)
<dj-death> mattst88: thanks, then I don't wtf is going on
<dj-death> mattst88: angle appears to be using the system GL driver
<dj-death> I thought angle was a GL implementation :)
itsmeluigi has quit [Quit: Konversation terminated!]
jewins1 has quit [Ping timeout: 480 seconds]
<jenatali> ANGLE is a GLES implementation
<jenatali> It can run on a desktop GL driver
<dj-death> ah got it
<dj-death> I guess I need to build it for vulkan then
orbea has quit [Quit: You defeated orbea! 2383232 XP gained!]
Haaninjo has joined #dri-devel
orbea has joined #dri-devel
<karolherbst> airlied: yeah soo.. the problem is that various tools are implicitly upgrading to opaque pointers and that bites us heavily :/
<karolherbst> maybe we should just skip llvm-16, but uhhh....
<karolherbst> though I think it would be okay to just use the llvm-15 libclc for now as that should just make everything work
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
ngcortes_ has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
<karolherbst> anyway, the problem with printf looks like this:
<karolherbst> %_str = OpVariable %_ptr_UniformConstant__arr_uchar_ulong_5 UniformConstant %11
<karolherbst> %19 = OpBitcast %_ptr_UniformConstant_uchar %_str
<karolherbst> %22 = OpExtInst %uint %1 printf %19 %uint_10
<karolherbst> gfxstrand: ^^ a potential deref optimization we might want to support, where we bring back the array lengths back
jfalempe has quit [Quit: Leaving]
<karolherbst> though I think we might also have to stop relying on printf giving us a pointer to a sized array :')
<karolherbst> anyway.. I'll deal with all of this later
Haaninjo has quit [Quit: Ex-Chat]
iive has quit [Quit: They came for me...]
vliaskov has quit []
shashanks__ has joined #dri-devel
shashanks_ has quit [Ping timeout: 480 seconds]
ngcortes_ has quit []
ngcortes_ has joined #dri-devel
ngcortes_ has quit []
ngcortes has joined #dri-devel
thaytan has joined #dri-devel
Piraty has quit []
stuarts has quit []
rasterman has quit [Quit: Gettin' stinky!]