00:10 robclark: airlied: 23.1.x in f38 would be nice (for purely selfish reasons.. I have an x13s showing up tomorrow and a690 support landed after 23.0.x ;-))
00:17 alyssa: q:P
06:56 tomeu: if khronos had its own police, I would call them on verisilicon's butchering of the openvx spec
06:57 tomeu: so much crazyness...
08:13 tjaalton: MrCooper: I've tested with brave-browser now, and it does in fact work after the version string changed. chrome itself craps itself and just segfaults no matter what, even after a downgrade
08:13 MrCooper: heh
09:30 cwabbott: alyssa: yeah, just don't use the helpers for ir3, it's pointless, just handle the intrinsics directly and rip out the register handling
09:32 cwabbott: that should be equivalent to what we're doing currently
11:52 kode54: by the way
11:52 kode54: how are people running the Xe KMD out of tree?
12:02 kode54: tpalli: could you perhaps describe how you're running the Xe KMD, if you're running it out of tree?
12:40 dolphin: airlied, sima: Trending to be no drm-intel-fixes PR this week as no bugs remain
12:42 dolphin: so no new Fixes: picked up until now
12:49 tpalli: kode54 sorry I haven't been running it, I'm planning to but other things to settle first
12:49 kode54: gotcha
12:49 kode54: I did something different anyway
12:49 kode54: I'm running the entire linux-drm-xe-next
12:49 kode54: and I just swapped out the driver through brutal trickery
12:50 kode54: logged out of Plasma, shut down SDDM, logged into SSH, unbound the driver from the device, rmmod'd it, then modprobed the new driver, then rescanned the parent device, then restarted SDDM and logged back into desktop
12:51 kode54: I hear i915 isn't really easy to unload
12:51 tpalli: I think you can have both but then force i915 to not load at boot with some parameter
12:51 kode54: I have both modules enabled at build time
12:51 tpalli: or something along those lines
12:51 kode54: and modprobe.blacklist=i915 for just this kernel
12:52 kode54: would love to know how I can just rip out the source code to the entire KMD and DKMS it into a different 6.3.x kernel
12:52 kode54: but I'm already using a modified gpusched
12:52 kode54: so there's that out the window
12:54 kode54: I also have that issue you mentioned about flaking
12:55 kode54: specifically, CCS looking flakes happening on anything rapidly altering the picture around the top of the screen
12:55 kode54: it looks like holes in the compositor surface that's being drawn there, and the holes look like CCS-like glitches
12:56 kode54: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8923
12:56 kode54: if it looks familiar, if you're even capable of running on a display
12:56 kode54: I'd apply that Mesa change you described, if it would help the issue
13:44 alyssa: cwabbott: sounds good
13:45 alyssa: tomeu: khronos police sounds terrifying
13:46 mlankhorst: kode54: I think we don't sync fb correctly with explicit sync
13:51 tomeu: alyssa: these headers have surely been subjected to terrible suffering
13:58 kode54: mlankhorst: oops
14:03 mlankhorst: although seems to be there now?
14:15 mlankhorst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22544
14:19 kode54: I already have 20418 applied
14:20 mlankhorst: with i915 is ccs used on the primary fb? I think I saw some w/a where it disabled ccs support on some versions of wayland
14:28 kode54: Xe doesn't support frontbuffer directly anyway
14:28 kode54: in fact, there's a MR to restore i915 frontbuffer support, and implement Xe frontbuffer
14:32 mlankhorst: It's just frontbuffer tracking, don't need it. :-)
14:36 kode54: oh
14:55 mlankhorst: there was a patch for mutter that disabled modifiers, it doesn't disable it on xe
15:21 jenatali: alyssa: Is your ack on !23173 just for the null_constant bit, or for all the nir bits?
15:23 kode54: mlankhorst: ah, I'm using Plasma
15:24 mlankhorst: can check i915_fbc_status in debugfs
15:25 mlankhorst: Yeah, didn't bother renaming it and break all tests
15:25 mlankhorst: or i915_display_info might be better
15:28 kode54: FBC disabled: pixel format not supported
15:28 kode54: [PLANE:31:plane 1A]: pixel format not supported
15:29 mlankhorst: hmm
15:29 mlankhorst: and i915_display_info?
15:30 kode54: https://www.irccloud.com/pastebin/e6bsfAeI/
15:32 kode54: huh, I should test if the artifacts happen on the secondary display too
15:33 kode54: gee
15:33 kode54: opening Telegram Desktop popout video player on secondary display causes it to slow my entire compositor down to one frame per 5 seconds until I close the player
15:34 kode54: moving it back to primary display, it stays that slow
15:34 kode54: then it crashes
15:34 kode54: good program
15:43 kode54: ok, lovely
15:43 kode54: it's calling into jemalloc from iris
15:43 kode54: yes, they just replaced the app heap with jemalloc
15:43 mlankhorst: Da!
15:48 kode54: sort of happens on secondary monitor with Parsec client
15:48 kode54: but not really as much as primary
15:49 karolherbst: maybe broken hidpi stuff?
15:50 kode54: https://www.irccloud.com/pastebin/IpU42eJu/
15:51 kode54: this may be relevant
15:59 DottorLeo: hi! I'm curious the GPL implementation works also on older cards like GFX6-7-8? Everything that is supported by radv?
16:01 kode54: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2641/diffs
16:01 kode54: they don't disable modifiers for my GPU on i915 anyway
16:02 kode54: no 56a0 in that list
16:43 kode54: quick question
16:43 kode54: how does one ordinarily cause xe to be replaced by i915?
16:48 Sachiel: I think i915.force_probe=!* xe.force_probe=* should work
16:48 kode54: true
16:48 kode54: I meant after booting, without rebooting
16:48 kode54: I replaced xe from an older kernel build to be replaced by one reloaded, by logging out of Plasma, systemctl stop sddm, then opening a shell with ssh client on my tablet to do the rest: echo 1 | sudo tee /sys/devices/pci0000:00/0000:00:03.1/0000:26:00.0/0000:27:01.0/0000:28:00.0/remove, rmmod xe, installed the full kernel rebuild package here, modprobe xe, echo 1 | sudo tee
16:48 kode54: /sys/devices/pci0000:00/0000:00:03.1/0000:26:00.0/0000:27:01.0/rescan
16:48 kode54: at the point of triggering the parent device rescan, the TTY reappears
16:49 kode54: then I can restart sddm and log out of the TTY and the SSH sessions
16:50 Sachiel: I'm not sure i915 handles that very well, but I haven't tried it
16:51 kode54: i915 might not handle terminating the TTYs
16:51 kode54: let's find out, just for curiosity's sake
17:03 kode54: okay
17:03 kode54: I switched to i915 post boot
17:03 kode54: I did screw up once though
17:03 kode54: I accidentally forgot to terminate sddm first
17:03 kode54: so it dangled on 7 handles, and got permanently wedged
17:04 kode54: let me see what the fbc status is
17:06 kode54: fbc_status is identical
17:06 kode54: let's check the other one you asked about
17:06 kode54: i915_display_info
17:07 kode54: https://www.irccloud.com/pastebin/gyrTosTw/
17:07 kode54: hmm, and framebuffer
17:08 kode54: never mind
17:08 kode54: the modifiers are the same
17:11 kode54: successfully switched from i915 to xe
17:12 kode54: so from one to the other and back again
17:12 kode54: requires fully terminating all desktop sessions and the login manager
17:12 kode54: dropping to a TTY
17:12 kode54: xe has one remaining refcount per display, while i915 has two
18:10 anholt: yeah, I also dislike the MR template.
18:25 glehmann: why does NIR have unpack split_x opcodes, isn't that redundant with u2u/i2i?
18:31 zmike: DavidHeidelberg[m]: in the future if you need to uprev vvl do NOT use "main" as a ref since it's impossible to know what is actually being pulled
18:31 DavidHeidelberg[m]: zmike: don't worry, I have eye on it
18:31 anholt: yeah, what? how did that get merged?
18:31 DavidHeidelberg[m]: I plan to change it to the release tag as soon it gets out 😉
18:32 zmike: apparently too slow since I'm already creating a MR to do that
18:32 anholt: you must always use a ref of some sort, never a branch.
18:32 DavidHeidelberg[m]: it was one of the last blockers of bookworm uprev
18:32 DavidHeidelberg[m]: I'm keeping it mind and when new version gets out, I'll fix it again..
18:34 anholt: glehmann: yeah, seems redundant but also the orthogonality for split_x/y seems reasonable. not sure if we should collapse them.
19:38 isoriano: Hola, sorry to disturb you but we are currently evaluating of bringing Mesa back to the AMIGA, where it all started. I know, completely stupid but with some recent developments Emu68 that have enabled us to use a Pi3/4 as emulator for the 68040 cpu and maybe access to the Videcore unit we would like to take a new run on this.
19:39 isoriano: Development would be done on Linux as we have a gcc 13.1.1 cross-compiler for m68k.
19:42 isoriano: While looking into the Mesa components and build system our initial approach would be to get to a cross compilation on the bare minimum requirements of mesa. So, if possible any dependency on x11, wayland etc which do not exist on AMIGA (we would try to build an RTG GLA (GL for AMIGA instead of GLX) system dependant layer to interact with Mesa)
19:47 isoriano: My idea was building mesa with really a bare minimum egl, swrast and no x11 to first tackle libs and compilation, 64/32 topics before we dig into DRI, gallium etc
19:48 isoriano: my question and sorry for the long text: I was thinking of using: meson -cross-file m68k.ini -cross-file cross.ini -Dosmesa=true -Dglx=disabled -Dgallium-drivers=swrast -Dvulkan-drivers=[]
19:49 isoriano: as a starting point.
19:50 isoriano: Would you suggest or have recommendations on how to even limit further dependencies?
19:52 airlied: isoriano: -Dplatforms
19:57 isoriano: Where the AMIGA is not part of?
19:58 isoriano: so just leave it empty, or?
20:07 anholt: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/815
20:13 airlied: isoriano: whatever you can minimise it too
20:15 isoriano: ... then I would consider *Windows* ... ugh
20:52 airlied:added a bunch of driver commits to the task/mesh additions, should be fairly trivial
22:23 DavidHeidelberg[m]: anholt: look good, just #dri-devel is no longer on Freenode 😉
22:44 benjaminl: anybody know the reasoning for rusticl passing inputs by binding a constant buffer explicitly instead of with pipe_grid_info.inputs?
22:51 benjaminl: I'm looking at this for rusticl/crocus, since crocus needs to handle global bindings being relocated by the kernel, which is the kind of thing that pipe_grid_info.inputs seems to be designed for
23:00 benjaminl: hmm, looks like nir_lower_uniforms_to_ubo always puts the kernel inputs in UBO binding 0, so I can probably still get this to work