08:48 nowrep: can the dri target (libgallium shared library) be built on windows?
10:47 Ristovski: nowrep: Check out https://github.com/pal1000/mesa-dist-win
10:53 nowrep: i don't see the lib in release archive, so i assume no. thanks
11:11 ishitatsuyuki: nowrep, libgallium has a separate target for win32, so no
13:33 dolphin: airlied: Going to pull the drm-intel-gt-next and drm-intel-next?
13:39 daniels: rg3igalia, cwabbott: any idea which tests were added in 1.3.9.0 which would make stoney very OOM-happy?
13:40 daniels: is reconvergence.maximal new?
13:53 rg3igalia: daniels: yes, reconvergence tests are relatively new
13:54 rg3igalia: and there have been complaints in the past about the amount of memory they require, so they may still be memory-heavy
13:58 daniels: ah, 85b965dbb675d1fdb4ff367a342b9ee189394e95
14:00 daniels: rg3igalia: would backporting that have your ack?
14:01 rg3igalia: backport officially or just for dri/mesa?
14:02 daniels: rg3igalia: just for our mesa build
14:02 rg3igalia: asking because the change appears to be in vulkan-cts-1.3.9.2 according to github: https://github.com/KhronosGroup/VK-GL-CTS/commit/85b965dbb675d1fdb4ff367a342b9ee189394e95
14:02 daniels: it's already in 1.3.9.2
14:02 rg3igalia: daniels: sure then, ack! :)
14:03 daniels: rg3igalia: thanks!
14:14 rg3igalia: np!
15:48 shadeslayer: Hi
15:51 shadeslayer: I'm starting to implement bfloat16 support in mesa for opencl, and I wanted some input on the NIR side of things, I was wondering if it would be better to introduce a new bf16 nir type, or just add a encoding field to the vtn_type and then emit the relevant conversion ops by passing the src/dst encoding parameters to nir_type_conversion_op
15:52 shadeslayer: that way we can reuse nir_type_float16 for bf16
16:03 karolherbst: shadeslayer: inherently NIR is a typeless IR, so for alu instructions the instruction itself defines the type. I don't know what operation are all defined over bfloat16, but maybe it's good enough to just add bf* nir opcodes where needed?
16:04 cwabbott: on intel and AMD, do GPU resets reset the GPU timestamp?
16:06 cwabbott: I'm trying to figure out whether I need to make the timestamp stable across reset/DEVICE_LOST for VK_KHR_calibrated_timestamps
16:09 cwabbott: I would assume it doesn't have to be, because you would only ever notice the discontinuity when reading the device timestamp on the CPU and the non-monotonic value you'd get wouldn't be useful for anything
16:12 cmarcelo: shadeslayer: we want have it represented in glsl_type, so encoding field won't be needed. for NIR I tend to agree with what karol suggested.
16:13 cmarcelo: karolherbst: that said, we might want to expand the NIR inferred type enum to include those as well.
16:13 karolherbst: yeah.. probably
16:14 karolherbst: could be it's own bit_size
16:14 karolherbst: though nir_alu_type is already cursed enough tbh
16:14 cmarcelo: karolherbst: in LNL we have a BFLOAT16 and a BFLOAT8
16:15 karolherbst: somebody might also get the idea adding 4 bit floats...
16:16 karolherbst: could have `nir_type_bfloat = 256`
16:16 karolherbst: but uhhh
16:17 karolherbst: that might require some bitfields to get expanded to 16 bits
16:17 karolherbst: not sure if it's ever stored anywhere
16:18 karolherbst: mhh or bfloat is 130 or so
16:29 cmarcelo: karolherbst: what you mean by 130?
16:29 karolherbst: the enums value
16:30 cmarcelo: which enum?
16:30 karolherbst: nir_alu_type
16:31 cmarcelo: I'm not much worried about the encoding in alu_type, we can fix/expand things if needed.
16:32 JEEB: so what was the correct venue to report issues with DRM modules such as `vmw_gfx`? I noticed their rewrite under the moniker of fixing something that was merged in 6.10.4 broke graphics for me, and now I've done enough analysis that I know that the issue is due to the DRM client requesting A8R8G8B8 and the scanout surface being X8R8G8B8, and there being a strict check that thus fails.
16:35 DemiMarie: How bad is forcing the use of rusticl and blocking the use of preemptable queues on AMD GPUs?
16:35 karolherbst: rusticl should probably use preemptable queues or whatever rocm is doing
16:36 karolherbst: it's just a bit annoying to do afaik
16:37 DemiMarie: The problem is that preemptable queues seem to cause AMD firmware crashes, and I have to assume those are exploitable.
16:39 karolherbst: fun
16:40 DemiMarie: TinyGrad resorted to disabling preemption to work around the issue.
17:35 DemiMarie: When doing media processing with a GPU, how much parsing happens in the GPU firmware? I'm trying to assess the risk.
17:36 agd5f: DemiMarie, The problem was that some of the user queue parameters weren't properly validated (e.g., if you specified a bogus GPU address for one of the user queue parameters, the hardware would segfault). That has since been fixed in the driver.
17:37 DemiMarie: agd5f: I see. Was the fix backported to stable?
17:37 agd5f: not yet
17:59 Ermine: Something is wrong with eglgears_wayland client decorations. When you hover over it, gears stop rotating, and in general it's sluggish and sometimes one can't even move the window
18:00 DemiMarie: Thanks for the fix agd5f.
18:08 soreau: Ermine: where did you happen upon the source?
18:09 Ermine: sorry, I don't understand what you mean
18:18 llyyr: Ermine: it seems very broken on the tagged release in general
18:18 llyyr: and on master, nothing renders at all
18:18 llyyr: main* sorry
18:23 soreau: Ermine: I was asking from what source file this binary is generated
18:24 soreau: here, when I build demos, there is no eglgears_wayland in the build directory
18:25 soreau: and the eglgears_wayland I have in the source tree from the last build system is from 2021
18:26 Ermine: Well, arch has packaged it somehow: https://gitlab.archlinux.org/archlinux/packaging/packages/mesa-demos/-/blob/main/PKGBUILD?ref_type=heads
18:26 soreau: running build/src/egl/opengl/eglgears gives a wayland gears client with SSD..
18:28 Ermine: I've tried on weston which doesn't have SSD, and on tinywl, which is wlroots but it doens't have SSD enabled
18:29 soreau: what's your goal?
18:30 mattst88: FWIW, eglgears_wayland went away in https://gitlab.freedesktop.org/mesa/demos/-/commit/2196e39d8c412e086548ef3bff6a8ca60ca01efa
18:30 soreau: yea I thought something was weird here
18:31 Ermine: Firstly I thought that this is a bug in move requests handling in a wlroots-based thing I'm trying to write
18:32 Ermine: anyway, rest in peace then
18:33 soreau: Ermine: there is an xdg-decoration demo in wlr-examples or whatever it was..
18:33 soreau: but not sure what you're wanting/needing
18:34 Ermine: it's unrelated
20:22 tjmercier: Hi Folks, https://cgit.freedesktop.org/drm/drm-misc/ is giving me 504s, and git fetches from anongit.freedesktop.org/drm/drm-misc are also failing for me. Looks like a server is down; anyone here have powers to fix?
20:24 airlied: tjmercier: drm-misc is no longer hosted there btw
20:25 tjmercier: Ah shoot, where do I go now?
20:25 airlied: https://gitlab.freedesktop.org/drm/misc/kernel
20:26 tjmercier: Awesome, thanks much!
22:43 DemiMarie: How bad is it to send the results of hardware decoding back to the CPU instead of keeping them in a dmabuf? Is it sufficiently bad that Qubes OS just needs good cross-VM dmabuf support?
23:36 ishitatsuyuki: Depends on how much headroom you have. On low end laptops, definitely can make it feel more laggy under load. On desktops, nobody cares even if you used all SW decoding