07:40 kusma: jenatali: Did something regress on Windows recently? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/59481473
07:41 kusma: In particular: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/59481473#L44
07:52 sumits: tzimmermann, mripard: I'm trying to push to drm-misc-next, but get an error 'You are not allowed to push code to this project'. Has something changed?
08:10 wens: it seems someone pushed a commit to drm-misc-next-fixes when it likely should have been to drm-misc-fixes
09:36 lumag: mripard, dumb question. Whose acks do I need to collect to land https://lore.kernel.org/dri-devel/20240528-panel-sw43408-fix-v4-3-330b42445bcc@linaro.org/ ? And should it go through the drm-misc or through the drm tree?
09:37 mripard: lumag: you can land them through drm-misc, but ideally you'd need an ack from i915 and amd maintainers
09:38 lumag: mripard, thanks!
09:39 lumag: jani, rodrigovivi, gracious ping for the patch ^^ (I don't see AMD maintainers on the channel).
09:40 mripard: agd5f: ^
10:04 jani: so, uh, is this depends on what we want, or should it be select then?
10:04 jani: +config DRM_DISPLAY_DSC_HELPER
10:04 jani: + bool
10:04 jani: + depends on DRM_DISPLAY_HELPER
10:05 jani: I'm no longer certain about anything :(
10:39 stsquad: can virglrenderer do something better than exit(-1) when it fails to fork the render server, it leaves everything else hanging
10:40 HdkR: exit_group(-1)
12:17 jenatali: kusma: 🤔 we stood up a new runner, but it's passed those jobs before so it shouldn't be that
12:19 jenatali: I've seen those assertions before. I think mareko hit them a little while ago? I don't remember exactly
12:21 kusma: jenatali: BTW, it also seems like the d3d12 tests don't run in the nightly schedule, which makes it a bit hard to check what's *supposed* to happen...
12:22 jenatali: Feel free to fix that 😊
12:23 kusma: It passed here: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/59500609
12:24 kusma: Seems the runner is different
12:26 jenatali: That would be unfortunate and confusing if that was the problem...
12:31 jenatali: kusma: it looks like the quick_shader job ran on one of the gstreamer runners and still failed... Seems like a code problem
12:31 jenatali: But given the change I don't see how that's possible
12:54 kusma: Yeah, that doesn't seem very likely to me either...
12:54 kusma: I think there's ghosts in the computers here.
12:55 sravn: mripard: Have you seen patches for sun4i implemeting support for DRM_BRIDGE_ATTACH_NO_CONNECTOR?
12:56 mripard: sravn: no, do you have a link?
12:57 sravn: mripard: I think sun4i is the only driver using dw-hdmi that do not support DRM_BRIDGE_ATTACH_NO_CONNECTOR.
12:59 sravn: I may take a look at it and see if I can type the patches. It was brought up here: https://lore.kernel.org/dri-devel/d17341c2-3f97-41d6-8125-bff838149798@collabora.com/T/#md0cf12abd625fa6c816f67865d34eab3b91341db
13:02 mripard: sravn: the dw-hdmi layer has mostly been done by jernej, so make sure he's in Cc if you send any patches
13:02 mripard: but yeah, it looks like something we should address
13:48 stsquad: Why does mesa's meson complain about wanting to build GLX if I'm doing "meson setup -Dbuildtype=release -Dplatforms=wayland -Dvulkan-drivers=virtio" - or does OpenGL default on?
13:50 stsquad:tries with -Dglx=disables for now
13:53 zmike: -Dgallium-drivers=
13:55 stsquad: zmike ahh thanks - actually I went for -Dgallium-drivers=virgl - I guess GLX is for older GPU drivers?
13:55 zmike: glx is for all gl drivers
14:07 Company: on 24.1 (and Intel), do Vulkan and GL use different Wayland protocols?
14:07 Company: like, one using drm_syncobj and the other not?
14:09 dj-death: the wayland stuff is shared across drivers
14:09 dj-death: on vulkan
14:09 dj-death: and actually on GL too
14:09 dj-death: but yeah different code paths, different rules
14:10 dj-death: I remember explicit sync was added to vulkan
14:10 Company: I'm trying to figure out https://gitlab.gnome.org/GNOME/gtk/-/issues/6730
14:10 dj-death: not sure if that's the case in GL
14:10 Company: I guess I can just run WAYLAND_DEBUG and grep for it
14:11 Company: yup, Vulkan creates a sycobj, GL does not
14:12 dj-death: could be that the surface is out of sync and it's not updating it again, just doing a blit?
14:13 Company: then everyone would have that issue, but that just happens for one person with an external monitor
14:13 Company: so I'm tempted to blame mutter
14:15 Company: could also be that the Vulkan code is busted and fails to update the buffer - though I'd say that's unlikely because GTK recreates the swapchain so it's independent of the syncobj
14:18 Company:assigns bug to Mutter so swick[m] and MrCooper can have a look
14:48 linkmauve: alyssa: Citra uses a GS for everything because that’s what the hardware does, it has vertex shaders and geometry shaders, but no fragment shaders as that is replaced with a fixed pipeline.
14:49 alyssa: linkmauve: amazing (:
15:01 neobrain: Couldn't quickly find the context of the discussion, but IIRC there is a software fallback for the 3DS geo shaders
15:04 neobrain: That fallback is actually needed for accurate emulation, since 3DS GS doesn't trivially map to host GS. Specifically certain types of vertex attributes have different interpolation rules
15:27 alyssa: neobrain: context was "I spent a week making GS fast on M1 in January when I found out how hard Citra hammered them"
15:38 FL4SHK[m]: is writing a Mesa based driver difficult?
15:38 FL4SHK[m]: for a fully programmable GPU
15:38 Ermine: I guess so
15:38 FL4SHK[m]: hm
15:40 Ermine: GPUs are hard. I'm pursuing to become contributor to linux graphics stack, but so far I haven't figured it out
15:40 FL4SHK[m]: I'm a hardware dev
15:41 FL4SHK[m]: And a software dev
15:41 FL4SHK[m]: and I have this project that I may be working on for the rest of my life
15:41 FL4SHK[m]: FPGA-based "PC" things
15:42 FL4SHK[m]: I have this FPGA dev board with a large FPGA (~500k logic cells)
15:42 zmike: kusma: for your mipmap question it would probably be good if you could be on the next call (2 weeks from today)
15:42 FL4SHK[m]: I've been working on the fixed function part of the GPU so far
15:42 FL4SHK[m]: ... though I'm still learning
15:42 FL4SHK[m]: I can do the programmable part just fine, but the actual 3D rendering part is new to me
15:43 FL4SHK[m]: so I'm writing a software based 3D renderer to learn the fixed function aspects of GPUs
15:43 FL4SHK[m]: ... basically I plan to translate my software rasterizer into FPGA code
15:44 FL4SHK[m]: Should be a fun time
15:44 FL4SHK[m]:uploaded an image: (9KiB) < https://matrix.org/_matrix/media/v3/download/matrix.org/fsvHjGFlDtFowqAquxnoJOAn/1000006484.png >
15:45 FL4SHK[m]: Got texture mapping working over the when
15:45 FL4SHK[m]: the weekend*
16:07 Company: reading the code, it seems there's no way to turn off explicit sync via an env var
16:07 Company: or am I missing a way?
16:08 Company:wishes there was a WAYLAND_DISABLE=protocol env var
16:16 daniels: no, there's no way
16:16 alyssa: FL4SHK[m]: I don't think 500k is big enough for nontrivial performant 3D at modern resolutions, tbh..
16:26 pac85: Comformant vk1.3 in 1 month...this is witchcraft
16:30 alyssa: pac85: https://cdn.masto.host/floss/media_attachments/files/111/249/828/481/678/700/original/7180b314a9660e07.jpg
16:32 pac85: alyssa: right I should have figured... Anyway seriously congrats!
16:32 Company: and then another month for writing a blog post - life of a coder
16:33 alyssa: pac85: thanks!!
16:33 alyssa: Company: if I can write the driver in 26 days I can write the blog post in 26 hours
16:33 alyssa: :P
16:33 alyssa:started writing on Monday night... :p
16:34 Company: the other 25 days are for thinking "I should write a blog post" :p
16:34 alyssa: Yup
16:35 Ermine: alyssa: magnificent work!
16:36 Company: alyssa: was it on purpose that the zink screenshot has 1/3rd the fps of the Vulkan screenshot?
16:36 alyssa: Ermine: thanks!
16:37 alyssa: Company: stk's vulkan renderer doesn't implement any of the expensive lighting passes their gl does
16:37 alyssa: but also zink on honeykrisp is like 1/3 the speed of our native gl
16:38 Company: why is that?
16:38 zmike: I'd assume because it's a tiler and the vendor id hasn't been added to the tiler paths in zink
16:38 Company: because Vulkan isn't optimized yet? Or because Vulkan can't be as optimized?
16:39 Company: zmike: what do tiler paths do differently?
16:40 zmike: everything
16:40 Company: hehe
16:40 Agent_00Ming: Hi, I have encountered an issue concerning GL_INVALID_VALUE error being thrown by the nvidia proprietary driver when the same parameters work without trouble on AMD and Intel
16:41 Company: I should learn about what's important to do different on tilers at some point
16:41 alyssa: that's probably some of it, also honeykrisp is slow right now because it was written in a month, etc
16:41 Agent_00Ming: Does anyone have a clue as to why GL_INVALID_VALUE is thrown even when the texture has level:0, x:0, y:0, width:24, height:24?
16:41 zmike: alyssa: a simple copy/paste of most TURNIP vendor id checks for whatever you're using will probably see sizable improvements
16:42 FL4SHK[m]: <alyssa> "FL4SHK: I don't think 500k is..." <- really? 500k is a ton for an FPGA
16:42 zmike: good pick of holocure for a demo though
16:42 FL4SHK[m]: it's not the same as 500k transistors
16:42 alyssa: zmike: probably. i'm more interested in dxvk :)
16:43 zmike: you do you
16:43 FL4SHK[m]: That and I don't expect to reach performant 3D at modern resolutions
16:43 FL4SHK[m]: I could buy a bigger FPGA
16:43 alyssa: FL4SHK[m]: fair enough. I just remember looking at this and seeing that geezus gpus are area intensive because 1000s of FPUs
16:45 FL4SHK[m]: an FPU for a GPU doesn't have to be fully IEEE 754 compliant
16:45 FL4SHK[m]: what's a geezus GPU?
16:45 FL4SHK[m]: a modern one?
16:45 FL4SHK[m]: Modern GPUs aren't in the same class as what you can do with an FPGA
16:46 FL4SHK[m]: even a really high end FPGA
16:46 stsquad: haven't there been a number of open source projects that attempted to do 3D with an FPGA?
16:46 FL4SHK[m]: Maybe, but I'm mostly doing this for me anyway
16:47 FL4SHK[m]: I can open source the project though
16:47 stsquad:seems to remember there have been re-occuring attempts mainly driven by the poor state of open drivers in the past
16:47 FL4SHK[m]: ah
16:48 FL4SHK[m]: FPGAs don't reach the clock rates of modern COTS GPUs
16:49 FL4SHK[m]: I'd be pretty happy with a 300-400 MHz GPU for my own project
16:49 FL4SHK[m]: might go higher, but likely not as high
16:49 FL4SHK[m]: likely not much higher*
16:50 stsquad: https://en.wikipedia.org/wiki/Open_Graphics_Project was the one I was thinking of
16:50 FL4SHK[m]: ah
16:53 FL4SHK[m]: I have been told that Mesa can support an OpenGL 2 GPU with translating the more modern graphics standards into OpenGL 2
16:53 FL4SHK[m]: is this true?
16:54 karolherbst: if the emulation was written for it
16:54 FL4SHK[m]: ... maybe I'll have to do that
16:55 FL4SHK[m]: This is going to be a long term project for sure
17:21 mareko: is it just me or is gitlab loading faster?
17:48 alyssa: mareko: update helped I guess? :)
17:49 karolherbst: still sad about the split db stuff not working
18:09 clever: ive got a problem that has been plauging my desktop for months now, anybody know how i could debug it further? [74306.977576] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled seq=33463961, emitted seq=33463963
20:02 marex: eric_engestrom: Hi, I think the mesa tag mesa-24.1.1 should again be in branch 24.1 instead of staging/24.1 ?
20:03 marex: it seems like only 24.1.0 is in 24.1 branch , not 24.1.1
20:12 mattst88: marex: it looks like he just forgot to push to 24.1
20:13 marex: could be
20:14 dwfreed: tags aren't branch specific
20:40 gfxstrand: Why doesn't nir_lower_idiv support int64?!?
20:41 gfxstrand: I know it would probably want fp64 but still...
20:43 gfxstrand: The integer divide lowering in lower_int64 sucks so bad....
20:45 alyssa: gfxstrand: because we already had the lowering in int64
20:45 alyssa: i think
20:45 alyssa: you could move it to idiv but then we'd ask why doesn't nir_lower_int64 support idiv?!?!
20:45 alyssa: ;)
20:46 gfxstrand: Well, they're fundamentally different approaches.
20:47 gfxstrand: I'd be happy to have something in lower_idiv which gets invoked by lower_int64 so you can access it from either pass.
20:47 gfxstrand: But generating a division algorithm if-ladder is just absurd
20:49 gfxstrand: Seems to be a good stress-test for NAK, though. :joy:
20:59 alyssa: gfxstrand: fair enough
21:03 gfxstrand: Reading the AMD LLVM code makes me sad
21:03 gfxstrand: They do the same thing except on some platforms they emit a different thing that's still like 50 instructions or more
21:09 airlied: gfxstrand: the amd code in llvm? or the amd llvm code in mesa?
21:09 gfxstrand: AMD code in LLVM
21:19 karolherbst: I thought the solution to 64bit idiv is to not bother, because people hitting real 64bit idiv obivously don't care about performance :P
21:20 mareko: in this market, if you are slow at something, the competition will use it against you
21:22 HdkR: Someone might implement the slowest/smallest radix divider and beat the lowered version :P
21:39 eric_engestrom: marex, mattst88: I didn't forget, I purposefully didn't push yet because each of these push triggers a CI pipeline and the CI is overwhelmed with everyone doing everything they couldn't do for the last couple of days (mostly trying to merge stuff), so I'm going to push the missing bits tomorrow morning once everything has died down
21:40 mattst88: ah, cool. thanks
21:40 eric_engestrom: I also only did the 24.1.x release and not the 24.0.x, for the same reason
21:41 marex: eric_engestrom: ahh, thanks
21:42 marex: eric_engestrom: no rush from my side, I just noticed it while bumping the mesa version locally so I reported it
21:42 eric_engestrom: yeah no worries, I have forgotten to do the final push a few times in the past so it could well have been the case today as well ^^
21:44 eric_engestrom: also, I'm going to post an MR disabling most of the CI in the release pipelines, it's not very useful to run everything again, it's too late anyway and everything will have been run in the staging pipelines
21:45 eric_engestrom: but not tonight, I need to sleep now :P
22:11 jrelvas: i just had a shower thought... if a gpu has a good enough display controller, then it could be possible to offload the entire window opening/closing effect in a desktop environment to KMS
22:12 jrelvas: make sure the target window has its surface/buffer being scanned out by a hardware plane
22:13 jrelvas: for "opening", transition the alpha from 1 to 0 and transition the scale from 0x0y to the buffer's actual size
22:13 jrelvas: for "closing", transition the alpha from 0 to 1 and transition the scale from the buffer's actual size to 0x0y
23:19 zmike: eric_engestrom: 💪 💪 💪
23:41 Ermine: What does "blorp" mean?