00:20 yshui`: hey, i think the xge special event registered in dri3_setup_present_event is never unregistered.
00:47 yshui`: what's the best place to unregister it? loader_dri3_drawable_fini maybe?
08:25 MrCooper: yshui`: makes sense to me
10:21 yshui`: MrCooper, the unregister was there. it was removed but I opened a MR to put it back.
10:41 MrCooper: good catch
15:21 alyssa: Hum, why is my -Dllvm=disabled build still inexplicably linkin gLLVM
15:23 alyssa: because pebkac, nvm
15:37 ondracka: This should be a valid nir_opt_algebraic syntax, right? (('bcsel', ('flt', a, b), 1.0, 0.0), ('slt', a, b))? Because right now I get "AssertionError: The search expression bit size 0.0 and replace expression bit size b may not be the same"
15:44 jenatali: I think you'd need @16, @32, @64 variations on the flt instruction
15:45 jenatali: You might also need a b2f in the replace expression
15:46 pendingchaos: yeah, I think that pattern would incorrectly match "bcsel@32(flt(a@64, b@64), 1.0, 0.0)"
15:46 pendingchaos: there's no requirement that the flt is the same bit size as the bcsel
15:50 ondracka: Thanks, (('bcsel@32', ('flt', 'a@32', 'b@32'), 1.0, 0.0), ('slt', a, b)), works.
16:26 jenatali: I don't think that's portable, since slt will produce a bool (1bit), which is different than the result of the 32-bit bcsel
16:26 jenatali: You'd need a b2f to convert to 1.0/0.0
16:36 pendingchaos: slt produces a float
16:37 jenatali: Oh. I just assumed it was "signed less than" which would return a bool. Nevermind
16:44 ondracka: BTW it still doesn't do what I want, it looks like other op has a precedens, there is a fmul by a constant with the bcsel result in the case I'm trying to optimize and it gets moved to before of both of the bcsel sources, snippet here: https://paste.centos.org/view/1a0efa01
16:45 ondracka: What determines the precendece in nir_opt_algebraic?
16:46 jenatali: The order of optimizations in the list
16:50 ondracka: Hm, even if I put it right to top, the fmul moving still happens first :-(
16:51 ondracka: The stuff defined in nir_opt_algebraic.py is everything that happens in nir_opt_algebraic pas or is there something else also going on?
16:52 cwabbott: ugh, rb_tree_insert compare seems to have the opposite direction as qsort compare
16:53 cwabbott: also, apparently it's 4 space tabs?!
17:38 X512: That is the status of DRI framework after removing all non-Gallium OpenGL drivers from Mesa repo? DRI framework now looks like redurant wrapper over Gallium.
17:39 emersion: yes
17:39 emersion: we want to slim it down and eventually remove it
20:13 tlwoerner: hi everyone, it's GSoC time again! i've gone ahead and applied for GSoC on behalf of XOrg.
20:14 tlwoerner: please take a look at https://www.x.org/wiki/SummerOfCodeIdeas/ and let me know if you have any ideas you would like to add
20:14 tlwoerner: please get in touch if you'd like to mentor
20:15 tlwoerner: many thanks to mairacanal for her idea: "increase coe coverage of DRM code" and for agreeing to mentor this year!!
20:15 X512: kallisti5: for example Wayland use EGL only. There are no WaylandGL thing.
20:16 X512: Matrix bridge is broken here. Matrix messages are not visible on IRC.
20:22 jenatali: Not strictly true. Coming from a Matrix user here
20:26 kisak: unregistered users on Matrix can have their messages bounced on the IRC side, that's a per-user config issue
20:26 kisak: ^Matrix users who haven't registered with the IRC side
20:36 ccr: the same applies to all users, it's the channel mode +M. only users registered to NickServ are able to talk. Matrix just "circumvents" the issue for other Matrix users.
20:37 ccr: which is the cause of confusion
22:31 alyssa:still doesn't know how she's supposed to run her own mesa builds on target devices after 1026d293441 ("dri: Introduce internal Mesa DRI driver loader extension.")
22:31 alyssa: like, concretely
22:32 alyssa: and have finally hit the dreaded "libEGL fatal: DRI driver not from this Mesa build"
22:32 airlied: well you didn't know how to do it conceretely before then either
22:32 alyssa: scp over the libgallium_dri.so file and set LIBGL_DRIVERS_PATH=
22:32 alyssa: what do I do now?
22:32 airlied: that wasn't concrete though :-P
22:32 airlied: copy over the libEGL as well
22:32 alyssa: last time I asked someone said glvnd but didn't elaborate
22:32 alyssa: libEGL, ok
22:32 airlied: maybe libglapi has to go
22:32 alyssa: copy it where
22:33 airlied: do a local ninja install to a prefix and rsync the lot over?
22:33 airlied: then set LD_LIBRARY_PATH to that dir
22:33 alyssa: sure, ok
22:33 airlied: since normally I think the answer is use devenv or whatevs, but that won't work if you are just scping
22:33 alyssa: right
22:33 alyssa: I use devenv for asahi since I build on target
22:33 alyssa: but that doesn't make sense for the zillion random slow arm boards I have
22:34 airlied:assumes you'd mostly just be rsyncing the gallium driver in the end anyways
22:34 alyssa: oh, because rsync does diffs, right..
22:35 alyssa:doesn't have rsync on the zillion boards but that can be fixed
22:35 airlied:used to use tar -cf - | ssh tar -xf - ah those were the days
22:38 alyssa: oof
22:38 alyssa: ok, my target has rsync on it now
22:41 alyssa: new problem, why are all the *_dri.so files being installed as separate files and not symlinks...
22:42 anholt: they're installed as hardlinks
22:43 anholt: this was supposed to be less confusing and error prone than all being links to some_dri.so. I may have been wrong abuot that.
22:43 alyssa: *nod*
22:43 airlied: rsync -H
22:43 alyssa: airlied: yeah that did it thanks :)
22:44 alyssa: ok, let's replace my scp abomination with `rsync -avhH install/ [$ODROIDN2]:~/install/` then
22:45 airlied: then just set LD_LIBRARY_PATH instead
22:45 airlied: oh you might need LIBGL_DRIVERS_PATH if install/ and ~/install/ are different absolute paths
22:45 airlied: on either side
22:45 alyssa: :+1:
22:45 alyssa: /home/alyssa/mesa/install/ on both sides is good enough
22:45 alyssa: okay, this works
22:45 alyssa: airlied: anholt: thank you both :)
22:46 alyssa: my only outstanding concern is the disk wear and tear (on my build machine) from constantly ninja install'ing
22:47 alyssa: though, hmm, what if I install into a tmpfs actually.. I wonder if rsync will do the right thing for that
22:48 HdkR: rsync will do everything for you :)
22:48 alyssa: yeah that did it
22:48 HdkR: rsync is your friend
22:49 alyssa: admittedly installing into /dev/shm seems obnoxious but, does the trick lol
22:49 HdkR: :D
22:49 alyssa: concretely, my setup:
22:49 airlied: alyssa: I don't think the ninja install is going to be much delta over compiling
22:49 alyssa: * -Dprefix=/dev/shm/install
22:49 alyssa: * ninja -C ~/mesa/build install && rsync -avhH /dev/shm/install/ [$ODROIDN2]:~/mesa-install/
22:49 airlied: unless you have some really crappy ssd
22:49 alyssa: % LD_LIBRARY_PATH=~/mesa-install/lib/aarch64-linux-gnu/ LIBGL_DRIVERS_PATH=~/mesa-install/lib/aarch64-linux-gnu/dri
22:50 alyssa: airlied: i don't screw around with non-removable flash memory :(
22:51 airlied: if I was the paranoid I'd be buying an external ssd :-P
22:51 alyssa: ah,
22:53 HdkR: airlied: I wouldn't necessarily call the ODROID-N2 eMMC SSDs high quality but they aren't quite as bad as microsd cards :P
22:56 alyssa: HdkR: It's the m1's flash I'm worried about
22:57 HdkR: Ah, that single NAND die they stick on those is a bit small for overprovisioning
22:57 HdkR: If you're "lucky" you have two!