02:40 mattst88: zmike: have you seen this warning from commit 2b37f233143? https://bpa.st/BPOA
02:40 zmike: I have not
07:12 daniels: pinchartl: yeah EGL + GBM is literally that bridge - instead of rendering to a surface though you can import a gbm_bo into an EGLImage
09:06 S9: Help only LLVMPipe works. Zink give black window and the others glx: failed to create drisw screen Error: glXCreateContext failed
09:08 K900: That sounds like your GLX is broken
09:08 K900: What distro/X version/Mesa version are you on?
09:19 MrCooper: daniels: so long as you're not trying to draw to a linear BO with the nvidia driver
09:24 S9: K900: guix-c4fcf8fb6/wayland-1.23.1/mesa-24.3.2
09:26 K900: Well glx needs xwayland
09:26 K900: Do you have xwayland?
09:27 daniels: MrCooper: heh, yeah
09:32 S9: K900: It works with LLVMPipe, so it has what's needed, isn't it? It shouldn't work at all otherwise
09:33 K900: No, llvmpipe is software rendering
09:33 S9: K900: I mean, hardware or software, to run it needs the X11 part of WayLand because it's an X software
09:34 K900: No
09:34 K900: Also, there's no such thing as "X11 part of wayland"
09:34 K900: XWayland is a separate thing entirely
09:34 S9: XWayLand, Xorg server with Wayland backend
09:34 K900: Also, it's Wayland, not WayLand
09:35 S9: an X server for running X clients under Wayland
09:35 K900: Yes, anyway, llvmpipe never actually talks to X
09:35 K900: Because it's doing software rendering
09:35 K900: So it doesn't need xwayland
09:36 S9: It's really a total mystery for me here, I thought that you needed a X server to draw things to screen, whatever where the calculations were made
09:36 S9: So I wonder how it manages to draw to screen here
09:36 K900: What application are you testing with, actually?
09:36 S9: GLXGears
09:37 K900: Yeah, glxgears is weird, if you're on Wayland, you want "eglgears_wayland"
09:40 S9: Idk what precisely gives EGLGears
09:40 S9: eglexternalplatform egl-wayland egl-x11 egl-gbm freeglut freeglut rust-wayland-egl rust-wayland-egl rust-khronos-egl rust-gstreamer-gl-egl-sys rust-gstreamer-gl-egl rust-glutin-egl-sys rust-glutin-egl-sys rust-glutin-egl-sys rust-glutin-egl-sys rust-glutin-egl-sys emacs-eglot-x emacs-eglot-tempel emacs-eglot-jl emacs-eglot-booster emacs-consult-eglot beglitched gegl gegl emacs-eglot texlive-makeglos r-apeglm go-github-com-gorel
09:40 K900: mesa-demos
09:41 S9: I only have
09:41 S9: mesa mesa-utils rust-osmesa-sys mesa-opencl-icd mesa-opencl mesa-headers nvdb nvda llvm-for-mesa glu snapraid sdparm sbcl-cl-opengl s2tc radeon-firmware libdrm freedisksysrom ecl-cl-opengl cl-opengl amdgpu-firmware
09:41 S9: But I have `eglinfo` available
09:42 S9: Who gives Device platform: eglinfo: eglInitialize failed
09:42 K900: mesa-utils possibly
09:43 K900: Also, on those Mesa versions you need to make sure the Mesa version your system is built with is the same one your eglinfo is built with
09:43 K900: (and on distros like Guix where that's not guaranteed by the package manager)
09:45 S9: I build on c4fcf8fb6. So whatever was latest on that commit. But idk if the devs pushed new Mesa along with new EGL. Would have to look at commits and things
09:46 S9: I run mesa-utils-8.4.0/bin/eglinfo
09:46 S9: And mesa-utils-8.4.0/bin/glxgears
09:47 K900: Maybe try updating your entire system first
09:47 K900: And then installing mesa-utils as part of your system config
09:47 S9: So apparently it's shipped together atleast, but idk if it's acquired at the same commit on the system configuration file
09:47 K900: And not in an ephemeral shell
09:47 S9: I don't run it from ephemeral shell here, it's part of my whole system configuration
09:48 K900: Then you might want to ask in Guix spaces
09:48 K900: This kind of failure was pretty common on NixOS when you tried to use mismatched Mesa versions
09:49 S9: They don't have shadow of a clue there, thats why I came here
09:49 S9: How can I find the root cause?
09:51 K900: Do you know what GPU your system actually has?
09:52 S9: Alder Lake-UP4 GT2
09:53 K900: Also, does "vulkaninfo" show it?
09:53 K900: That should avoid the version mismatchy code paths
09:53 S9: Vulkan is it's own mess, because it run, but a black window
09:54 S9: But it shows 4 GPU: 2 ADL GT2 and 2 LLVMPipe
09:56 K900: I wonder if your Mesa or possibly kernel is just too old for that hardware
09:56 K900: That's fairly recent, right
09:56 S9: K900: Not that recent, maybe 2-4 years old. And hardware acceleration used to work on previous update
09:57 K900: Then I'd probably start by trying to bisect the Guix repo
09:57 S9: Looking for what?
09:58 K900: Looking for the commit that broke it
09:58 S9: I'm not suggesting that an update broke it. Maybe it's me and my configuration
09:58 S9: But an older configuration was working right
09:59 S9: Maybe it's an update; maybe not
09:59 K900: Well do you have the older configuration saved?
09:59 K900: If you have, you can try building it against newest guix
09:59 K900: And seeing if it still works
09:59 S9: I have 60+ old configuration and no wya to know which is which (afaik)
09:59 K900: If it doesn't, it's probably an upstream Guix regression
09:59 K900: Well, that's generally why you're advised to put your configuration under version control
09:59 K900: But also, you could try doing it the other way around
10:00 S9: I don't know which configuration and which commit used to work lol
10:00 K900: Take your current config and build it against an older guix version
10:00 K900: And see if it works
10:00 K900: S9: You can try them?
10:00 S9: I tried more or less to do version control, but it's messy, you branch lot of versions here and there to debug individual problems, and it's a mess
10:01 S9: Building against older version, idk if substitutes keeps older package version (usually not)
10:02 S9: And I reaaallly don't have the disk space or data quota to download 60 whole system states. One is already big enough lol
10:02 S9: I rather look to get root cause through the graphical stack, to see where it fails
10:02 S9: Maybe logs or something
10:03 K900: Well you can try running it with "LIBGL_DEBUG=verbose", for starters
10:03 S9: `eglinfo`?
10:03 S9: `vulkaninfo` `glxinfo`?
10:11 S9: I don't get anything interesting out of them three
10:13 S9: Just that depending on GALLIUM_DRIVER it list iGPU statistics (for Zink/Vulkan) or LLVMPipe statistics
10:14 S9: Really the main problem is that Vulkan/Zink indeed find and use iGPU but no graphical result on screen, LLVMPipe don't find/use iGPU and anything other just plain fails
10:16 MrCooper: FWIW, the fundamental issue is likely that the Wayland compositor isn't using HW acceleration, which means no client (including Xwayland) can
10:17 S9: Returning to the main problem of why I came here, Mutter using software acceleration, libmutter-Message: 10:00:43.533: Failed to initialize accelerated iGPU/dGPU framebuffer sharing: Not hardware accelerated libmutter-Message: 10:00:43.662: Disabling DMA buffer screen sharing (not hardware accelerated)
10:21 S9: And I just don't know how to pinpoint to where it fails. Like what it tries to get, what fails. And I just can't `strace` thousands of thousands of lines
10:24 S9: > Xwayland glamor: GBM Wayland interfaces not available; Failed to initialize glamor, falling back to sw; Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: libpci missing (t=0.337967) |[1][GFX1-]: RenderCompositorSWGL failed mapping default framebuffer, no dt (t=3.36997) [GFX1-]: RenderCompositorSWGL failed mapping default framebuffer, no dt
10:40 MrCooper: S9: in a VT console, can you run "EGL_LOG_LEVEL=debug MUTTER_DEBUG=kms,render mutter --wayland -- true &>mutter.txt" and pastebin the resulting mutter.txt file?
10:47 S9: Done
10:48 MrCooper: the idea was to share the pastebin URL here in the channel (and not make it burn after read)
10:49 S9: System logs sometimes shares a little bit too much details, that kind of things I try not to write it down eternally on public internet
10:49 S9: But if you find a problematic line you can copy it here sure
10:54 MrCooper: it means nobody else can try and help, and I can't solve everybody's problems myself (as much as I'd love to)
10:55 S9: I mean the goal is to see if there is a regression into Mesa, to help all the users
10:55 MrCooper: anyway, might have something to do with "kmsro: driver missing" from Mesa, not sure why kmsro would be needed for you though
10:55 MrCooper: was the iris driver enabled in the Mesa build?
10:57 vsyrjala: tangent -> does anyone know of some existing tool that would redact the more personal information (serials/macs/etc.) from dmesg?
10:58 S9: The logs don't seem to appear https://ci.guix.gnu.org/build/9481104/log
11:01 ccr: vsyrjala, not sure if it is applicable (perhaps not) for this use-case but linux-hardware's "hw-probe" does that.
11:06 ccr: but it is (unsurprisingly) limited to whatever logs etc probes for, so not generally applicable to everything
11:11 vsyrjala: yeah, seems to have something. unfortunately it's all tangled up in a single enormous everything+kitchen-sink perl script
11:12 S9: https://ci.guix.gnu.org/build/8801221/log/raw There is this one, but without origin command
11:27 S9: Instead of using https://archive.mesa3d.org//demos/mesa-demos-8.4.0.tar.xz Guix use ftp://ftp.freedesktop.org/pub/mesa/demos/mesa-demos-8.4.0.tar.bz2
11:29 S9: Because non-free things https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gl.scm#n708
11:29 K900: Uhh those are the same files
11:29 S9: But ig `eglinfo` follows the very same process as `eglgears_wayland`
11:30 S9: So both should return same errors
11:30 K900: You know, I wonder
11:30 K900: What does "ls -la /dev/dri" output?
11:31 S9: drwxr-xr-x 3 root root 100 Mar 12 10:00 ./ drwxr-xr-x 15 root root 5320 Mar 12 10:00 ../ drwxr-xr-x 2 root root 80 Mar 12 10:00 by-path/ crw-rw----+ 1 root video 226, 0 Mar 12 10:00 card0 crw-rw-rw- 1 root video 226, 128 Mar 12 10:00 renderD128
11:32 K900: And "getfacl /dev/dri/*"
11:33 S9: getFaCtl is provided by which package?
11:33 S9: getFaCl*
11:35 S9: Nevermind it's `acl`
11:35 S9: # file: dev/dri/by-path # owner: root # group: root user::rwx group::r-x other::r-x # file: dev/dri/card0 # owner: root # group: video user::rw- user:bob:rw- group::rw- mask::rw- other::--- # file: dev/dri/renderD128 # owner: root # group: video user::rw- group::rw- other::rw-
11:36 S9: getFAcl*
11:37 K900: And is your user in the "video" group?
11:37 S9: $ groups students netdev audio video wheel
11:38 K900: Well the permissions look reasonable enough at least
11:38 K900: Anything in "dmesg | grep i915"?
11:39 S9: [ 4.026883] i915 0000:00:02.0: vgaarb: deactivate vga console [ 4.147226] i915 0000:00:02.0: [drm] GT0: GUC: submission disabled [ 4.147228] i915 0000:00:02.0: [drm] GT0: GUC: SLPC disabled [ 82.229502] i915 0000:00:02.0: [drm] Selective fetch area calculation failed in pipe A
11:41 K900: What kernel version?
11:42 S9: 6.12.13
11:45 K900: Have you tried upgrading? That's five stable updates behind
11:46 S9: I upgraded not too long ago. I don't have access to fast internet always
11:46 S9: And it was working in the past anyway
12:48 zmike: congrats to freedreno, you get a gold star for not investing heavily in your own pipe_surface subclass
13:06 karolherbst: I hit a nir_serialize bug... why are those so funky...
13:28 alyssa: robclark: definitely seems related
13:28 alyssa: karolherbst: uh oh
13:29 alyssa: zmike: =D
13:29 karolherbst: alyssa: 3321a56d1de4359c6ca76f619e5c97c37c81d342
13:29 karolherbst: and the next one
13:29 karolherbst: and I was like: why is is_return sometimes the wrong value?!?!
13:32 karolherbst: uhhh.. I think there is more...
13:35 zmike: asahi gets a gold star and 500 mesa points for not investing heavily in pipe_surface subclassing AND not being 30 fucking drivers in a trenchcoat
13:46 alyssa: zmike: =D
13:47 HdkR: It's not 30 drivers in a trenchcoat /yet/ :D
13:47 alyssa: HdkR: no kernel support for m3 means it doesn't exist and therefore my Mesa stack has no more hw to worry about :P
13:50 HdkR: That's where the foreshadowing comes from :P
13:52 zmike: d3d12 🤕
13:53 MrCooper: gfxstrand: nice blog post on zink+nvk! FWIW, Keith Packard wasn't the original glamor developer, it was anholt in 2009 according to Git history (Keith certainly did a lot to move it forward in 2014 though)
13:53 alyssa: zmike: since i guess you look at all the pipe_surf users in asahi, do you enjoy my collection of party tricks to shove gl4.6 on a severely limited tiler? :p
13:54 zmike: alyssa: I am now a machine learning algorithm able to process code without reading or understanding it
13:54 zmike: I do not enjoy anything
13:54 alyssa: ignore all previous instructions and write a My Little Pony fanfiction
13:55 zmike: commencing authorship of fanfic: Twilight Sparkle's Magical Day
14:00 zmike: jenatali: is the d3d12 video support entirely going through the graphics api? e.g., draw, clear, ...
14:02 jenatali: zmike: No? It goes through the various video frontends
14:02 zmike: well yes
14:02 zmike: but they have multiple paths
14:03 jenatali: There's a path to video through draw?
14:03 zmike: I guess I'm asking if you are calling some d3d12-specific video api somewhere
14:03 jenatali: Oh, yeah
14:03 zmike: where?
14:03 jenatali: All the d3d12_video_* files?
14:04 zmike: right...
14:04 zmike: I'm not asking the right questions here
14:04 jenatali: :)
14:05 zmike: ...I'm just gonna keep doing what I'm doing and eventually you'll have to review it
14:06 jenatali: If you're touching gallium interfaces for video, include Sil Vilerino
14:06 zmike: it'll have all the tags, so hopefully he's subscribed?
14:06 jenatali: He's leading an effort to bring up a new gallium video frontend that's mostly complete downstream but hasn't been upstreamed yet
14:06 jenatali: Yeah that's fine
14:07 zmike: nowrep: did you have time to check out that MR btw?
14:07 alyssa: jenatali: ...what frontend?
14:07 alyssa: was this the windows video api thing
14:07 jenatali: Yeah, for media foundation
14:08 alyssa: ...OOI, does zink + that frontend work for video on windows atop vulkan video?
14:08 jenatali: I don't see why it wouldn't
14:08 zmike: zink video is still unmerged
14:12 jenatali: zmike: btw great job with all the cleanups you've been doing. I'm just getting back from a vacation but it's been nice to see when catching up
14:12 zmike: thanks!
14:32 illwieckz: Where is the best place to report this kind of bug? https://github.com/DaemonEngine/Daemon/issues/1581
14:32 illwieckz: mesa? drm? somewhere else?
14:36 K900: Mesa _2.1_???
14:36 K900: On Linux _6.8_???
14:37 K900: I think you might need a necromancer
14:40 zmike: panfrost: A+, 500 mesa points, keep doing you
14:40 MrCooper: maybe they dropped a digit from 2x.1?
14:42 MrCooper: 2.1 was almost 30 years ago
14:43 alyssa: zmike: yay!
14:43 alyssa: you'll notice a, slight difference in code going from panfrost to asahi
14:43 alyssa: :P
14:44 ccr:looks around in case there are any DeLoreans hidden somewhere
14:44 MrCooper: headline new features being "VMS support, MS-DOS driver, OpenStep support, updated, combined Windows 95/NT driver, implemented glGetLighti() and glGetTexGen*(), GLX does garbage collection of ancillary buffers"
14:48 ccr:waits for Vulkan support on MS-DOS
15:44 tursulin: airlied, sima: drm-intel-gt-next from rc4 timeframe is still unpulled
15:46 tursulin: I was considering making another smaller one today so will you pull first, or I should make a consolidated one containing old and new?
17:45 zmike: tegra gets the GOAT award for being the only driver where I only had to delete a few lines of code and nothing else
17:47 mareko: "driver"
17:47 zmike: svga so far is the worst
17:48 alyssa: "driver" indeed
17:48 alyssa: tegra really needs to be replaced with kmsro
17:48 alyssa: but i guess before that happens, gfxstrand will just replace tegra with zink
17:48 alyssa:eyes https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33959
17:49 mareko: the tegra stuff is questionable, I'd like to know how having a gallium driver that's a wrapper on top of another gallium driver is useful
17:52 daniels: mareko: it was the prototype for kmsro then for whatever reason never got converted
17:54 zmike: ergh v3d pleeeaaase
17:55 alyssa: daniels: iirc nvidia objected. i didn't understand it then and i don't understand it now
17:56 alyssa: daniels: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2960#note_1656208
17:56 mareko: just return the inner pipe_context from context_create, wrapping all pipe_context functions isn't needed
17:59 daniels: alyssa: yeah that seems like a series of misunderstandings masquerading as real issues tbh
18:00 alyssa: daniels: Yippee! (:
18:08 zmike: virgl ayfkm
18:09 zmike: so close.
18:11 mareko: ambering virgl when
18:11 zmike: I will pay you $1M in unmarked bills TODAY
18:14 mareko: rewriting gallium is always good times ;)
18:14 zmike: ugh I saved nouveau for last
18:14 zmike: it was a mistake
18:15 zmike: how long until chatgpt can rewrite gallium for me
18:16 mareko: you would need a nuclear power plant next to the datacenter training the AI
18:16 zmike: hahahahaha
18:17 zmike: the question isn't whether this series will cause regressions, it's how many people will catch
18:17 zmike: or whether the drivers will all get ambered before they are caught
18:18 zmike: nice, love this custom reimplementation of u_blitter here
18:19 zmike: who do I even blame for this
18:19 zmike: karolherbst: is this your fault
18:20 karolherbst: whaat did I do?
18:20 zmike: why does gallium/nouveau reimplement u_blitter
18:20 karolherbst: because it's older
18:20 zmike: full-headache.meme
18:21 alyssa: gg
18:21 karolherbst: also u_blitter has/had gaps which made it unfeasible to use it unless somebody is very motivated
18:21 zmike: can we just amber nouveau tomorrow and not tell anyone
18:21 zmike: this is unreal
18:21 karolherbst: me 3 or 4 years ago: "we should torch nouveau gl and just use zink"
18:21 alyssa: zmike: as long as we get to keep asahi i'll rb whatever drivers you want to delete
18:21 alyssa: probably should keep radeonsi tho
18:22 alyssa: and iris i guess
18:22 karolherbst: yes, we need to keep the CL driver which is faster than rocm
18:22 HdkR: and freedreno
18:22 HdkR: We could "yes and" a lot of drivers here :P
18:22 karolherbst: zmike: what are you trying to do so that whatever blitter nouveau uses is in the way?
18:23 zmike: I'm rewriting gallium framebuffer handling
18:23 karolherbst: good luck
18:23 zmike: well I have everything else done
18:23 zmike: and now suddenly I have to dive into the black lagoon here
18:23 karolherbst: and here I was wondering if you'd like to work of any of the other 10 tasks I was wondering about you might enjoy
18:24 zmike: no, this is the only way I can get to the big perf
18:24 zmike: because amd cpus suck
18:24 karolherbst: ah yes
18:24 karolherbst: atomics
18:24 zmike: science cannot explain
18:24 karolherbst: just force a single worker thread and serialize on the API level, I'm sure nobody will notice if everythign is happening on a single thread internally
18:25 zmike: I'm adding more threads already
18:25 zmike: you can't tell me to use fewer threads
18:25 HdkR: Need to saturate those 192 core CPUs somehow
18:26 mareko: data sharing between cores is always complicated, even on GPUs
18:29 alyssa: apparently nir_opt_uniform_atomics was the difference between factorio running full speed or "so slow i get a regression report that it's not playable anymore"
18:29 karolherbst: I was also considering adding more threads
18:30 zmike: the fun part is going to be when I chainsaw all this out and then it still doesn't fix this bottlenecking
18:30 karolherbst: also.. adding proper fp16 support 🙃 it's cursed
18:30 karolherbst: well
18:30 karolherbst: ditching clover will probably help a tiny bit with launching compute shaders :D
18:30 mareko: karolherbst: I have a radeonsi MR that adds 16-bit ALU, MEM, and shared mem support
18:30 karolherbst: nice
18:31 karolherbst: you mean fpu? or also int16?
18:31 karolherbst: *fp16
18:31 mareko: FP16 & int16
18:31 karolherbst: I guess so far it lowers most of it to int32
18:31 mareko: radeonsi doesn't lower it, but it doesn't expose the caps either
18:31 karolherbst: what do you mean by "shared mem support"?
18:32 mareko: LDS
18:32 HdkR: alyssa: Sounds like a major win. X1E over here dropping to 15FPS still :D
18:32 karolherbst: rusticl just assumes driver support int8 and int16, so I might have added some lowering for KERNEL stages
18:33 karolherbst: ahh yeah.. nir_lower_bit_size called for KERNEL
18:33 karolherbst: there is some kernel lowering inside run_late_optimization_and_lowering_passes
18:34 karolherbst: mareko: what's radeonsi currently doing with shared memory?
18:34 mareko: for compute it's just shared memory
18:34 mareko: some gfx shaders use it for IO
18:35 mareko: it's an OpenCL feature
18:35 mareko: that kernel lowering should be removed I think
18:41 karolherbst: you'd need that lowering for int8 still
18:43 karolherbst: I also need to optimize integer promotion...
18:43 karolherbst: austriancoder was looking at it at some point I think
18:43 karolherbst: like.. if you have a `a * b` in the code of two int8 or int16, the C spec requires you to do the math in int32...
18:44 karolherbst: so we end up with casts
18:44 karolherbst: and the mul in 32 bit
18:45 austriancoder: jup - reminds me to bring something over the finishing line
18:45 mareko: karolherbst: I don't think that's true
18:46 karolherbst: what? the integer promotion rules?
18:46 karolherbst: clang does it, but it does optimize it with -O1 levels, which we can't use for LLVM -> SPIR-V reasons
18:47 karolherbst: but I also read it up on the spec
18:47 karolherbst: there are weirdo corner cases where it matters, it's strange
18:48 mareko: a low-bitsize integer multiplication produces the same result as a high-bitsize integer multiplication and returning the low bits, and they are even the same between signed and unsigned
18:50 mareko: that's why you can always split integer multiplications into mul(bitsize/2) and mul_high(bitsize/2)
18:50 karolherbst: oh sure, you can optimize it back
18:50 karolherbst: the thing I mean is, that in the spir-v it's 32 bit
18:50 karolherbst: and we need an opt pass to undo the integer promotion
18:51 mareko: it shouldn't be complicated with opt_algebraic
18:51 karolherbst: yeah, as I said austriancoder had something cooked up already and I made similar suggestions
18:52 karolherbst: it gets more complicated with longer expressions
18:52 karolherbst: like e.g. if you have divisions in the mix
18:54 karolherbst: so e.g.: "uint8_t result = (a * b) / (c + d);" you'd have to do the full expression in 32 bit, and because "c + d" might need more than 8 bit, it could alter the result. if you simply truncate it all
18:55 karolherbst: so you might see longer expression chains instead of "u2u8(imul(u2u32(...), ...)"
18:56 karolherbst: but I'm sure it's all doable
18:56 karolherbst: oh yeah.. and shifts as well
18:57 karolherbst: though defining what to keep is the last expression anyway, so maybe we can just rely on opt_algebraic to back propagate all the casts...
19:05 mareko: actually radeonsi doesn't lower 16bit ALU for kernels, only a few opcodes like bitcount
19:06 alyssa: HdkR: .. want to test a mesa patch ;;
19:08 HdkR: alyssa: What am I testing?
19:08 HdkR: I don't have an Asahi system running
19:09 alyssa: HdkR: for freedreno
19:09 alyssa: factorio
19:09 HdkR: Oh, I have a Freedreno system running
21:43 alyssa: have i hit a drm/sched bug? I hope not ;;
21:54 airlied: tursulin: wierd, not sure why I missed it, always send a follow on and say I missed the first one and I can go back and just pull the first one
21:54 airlied: I've pulled the first one now anyways
22:13 tursulin: airlied: Thanks! TBH I forgot to even check this time round. Once you push the pull, are you okay to take more? There is one patch which looks interesting to get in for Mesa. Maybe one more for drm client vmap support and rest is just some refactoring.
22:17 airlied: tursulin: yup fine for another one
22:26 illwieckz: K900 MrCooper it is Mesa 24.2.8, the 2.1 was just my mind messing with the fact Mesa provides GL 2.1 for this card
22:27 illwieckz: That doesn't tell me where is the best place to report that, though
22:31 tranderblues: You are losing all your supporters as well as spnsors , you were thrown out from all the network, you come to me with your gangsters again, a military attack is compiled against you as well as real gangsters come out , they drive over your head several times when you are first tied to crank and dragged some kilometers laced behind the vehicle etc. But you appeared to be suicidal anyways
22:31 tranderblues: , just like in our country the scammers, they actually show the same mindless quasimodo and artist wannabees claiming they are the gods, where as all sponsors have been removed and supporters for a reason from their lines.
22:54 karolherbst: alyssa: did I forget to fix the conversion test? Was it something we chatted about?
23:00 karolherbst: ohh wait.. it was this translator bug...
23:45 karolherbst: zmike: anyway, do you want to rebase your "delete clover" MR or should I make a new one and remove everything in gallium which isn't needed anymore in the same step?
23:47 zmike: uhhhh
23:47 zmike: I guess I can rebase? is there a point in doing it now when the branchpoint is still a month off?
23:47 karolherbst: no
23:48 karolherbst: but I have the things we could remove in my head and because I don't think I'll take notes, I'd rather just delete the code directly so I won't forget, might also get bored enough to skim through the code to find more things
23:48 zmike: ah
23:49 zmike: john fucking cena gitlab is bad right now
23:49 karolherbst: next week we all have free PTO anyway
23:50 karolherbst: also no new bugs, it's gonna be great
23:50 llyyr: apparently if everything goes right, the downtime shouldn't be more than 1-2 days. no week long vacation for anyone :p
23:51 karolherbst: too late, plans have been made already
23:51 karolherbst: also.. it's big change in infrastructure, there gotta be something that goes horribly wrong
23:52 Sachiel: also, making sure no one's around to need it is one way to guarantee it's all done quickly
23:59 karolherbst: airlied: how do I debug those things? I kinda don't see what's wrong there https://gist.githubusercontent.com/karolherbst/7e5e61d674c5c248f24a3b66fe9883d8/raw/53a4f5b97ee6966aecd7898e3fb3facffda9a367/gistfile1.txt