08:28 tzimmermann: jfalempe, thanks for reviewing the ast series
08:28 tzimmermann: jfalempe, i have ~10 more patches for ast. they clean up the selection+validation of the display modes. do you prefer a long series or shall i split it into two smaller ones?
09:11 karolherbst: jenatali: any plans for program scope global variables? My current plan is to simply specify the address of the variable at compile time as we need it for spec constant ops. I wonder if that solution also works for you? Can you do allocation where you can rely on the address or even assign the address yourself? Then me adding a
09:11 karolherbst: ".global_var_base_addr" field to spirv_to_nir_options would be all that's needed to properly suppot this feature. I'm interested in it, because the CTS relies on it while testing for the generic address space, and I don't want to bother to fix the tests, because I need this feature for other things 🙃
09:12 jfalempe: tzimmermann: you're welcome, I'm fine with a long series.
09:13 tzimmermann: jfalempe, great, thanks a lot! it needs some more testing before i send it out
11:08 sima: tzimmermann, I guess you'll push the build fix from arnd to make sure it's in this week's pr train?
11:51 tzimmermann: sima, done now
11:54 sima: thx
12:35 jenatali: karolherbst: sure sounds like that should work
12:55 zmike: mareko: I'm trying to trace your glapi thing through libGL/waffle
12:55 zmike: any tips?
12:59 jenatali: zmike: maybe start with seeing which commit breaks it?
13:00 zmike: well that's the easy part since it's the first commit
13:01 jenatali: Huh. Interesting
13:01 zmike: yeah
13:02 zmike: somehow I just get noop functions once that's applied
13:05 mareko: zmike: seergdb?
13:05 zmike: hm _glapi_tls_Dispatch is pointing to table_noop_array
13:05 mareko: or gdbgui
13:05 zmike: how does that help me over regular gdb?
13:06 mareko: stepping through asm instructions instead of C code is nicer
13:06 mareko: and breakpoints
13:06 mareko: though printf probably beats most debuggers
13:10 mareko: there are at least 2 reasons why the dispatch would be noop: either there is no current context or _glapi_set_dispatch is called from a wrong thread
13:11 mareko: or there is more than one _glapi_tls_Dispatch
13:12 zmike: seems like it's all being called from the same thread
13:12 zmike: and as near as I can tell there is a current context
13:23 zmike: hm there's a glGetError call before glGetString and that hits noopGetError too
13:27 youareillpeople: <youareillpeople> it’s that the formula is in the most capable conditionless format for your old gpus, its the smallest military grade linear algebra cause conditionals will bust the gpu instruction limits on r300. you can do that on 8bit controller too, by using intrinsics to execute arbitrary precision adds its cheaper than the conditionals on of single delta based method. its cause
13:27 youareillpeople: hashmaps would <youareillpeople> require calling much of the conditional sets which is itself the only way to do it using one delta per value.
13:29 youareillpeople: so good luck in doing detonation of bombs and super cañculations with pocket calculator
13:29 youareillpeople: you are entirely toxic and idiotic people
13:36 zmike: mareko: it looks like the dispatch table is being set correctly? or at least with/without the first commit I'm seeing ctx->GLApi=ctx->MarshalExec in glthread and then that pointer is set in _glapi_set_dispatch
14:25 mareko: zmike: yes, the only change is that libglapi is moved to libgallium
14:28 zmike: mareko: okay, I think I've got it: it looks like my distro waffle is dynamically linked to the distro mesa's libglapi
14:28 zmike: which explains why my git waffle build doesn't have this issue: it doesn't link to glapi
14:29 mareko: that's worrisome
14:31 mareko: I wonder how that happened
14:31 zmike: dunno
14:31 zmike: this is on fedora 41
14:32 zmike: yeah so it's a waffle bug
14:33 zmike: not dynamically linked, sorry
14:33 zmike: waffle dlopens glapi
14:33 mareko: yes
14:33 zmike: in 1.7.0
14:34 zmike: but this is fixed in waffle c83212649b656bd66f57afe27d9ddf5a60a1405d from 2021
14:34 zmike: I don't know how it's possible that a fedora release from last year is using such an ancient waffle version but that's definitely the problem
14:36 mareko: zmike: assuming this is a symbol name conflict, what happens if you rename the exported libglapi symbols (identifiers) in Mesa?
14:36 zmike: uhh can you give me a patch to test for that?
14:36 zmike: or suggest changes
14:36 mareko: yes
14:38 MrCooper: is there a point in working around waffle like that? Just use fixed waffle?
14:39 zmike: unfortunately that would break mesa for anyone using an affected version of waffle, though I'm not sure how many people/apps that is in practice
14:39 zmike: fwiw it looks like the fix for this wasn't shipped in any of the 1.7.x releases
14:40 zmike: only 1.8.x
14:41 MrCooper: FWIW, the only reverse dependencies of libwaffle-1-0 in Debian are apitrace & piglit
14:41 zmike: that's consistent with my knowledge
14:41 zmike: so maybe it's fine after all?
14:41 zmike: though CI will have to update
14:42 zmike: cc daniels mupuf
14:45 mupuf: Should be an easyfix
14:46 mareko: that explains why there is even a conflict - the problem isn't dlopen(libglapi), but RTLD_GLOBAL
14:51 MrCooper: it's a bit surprising this only affects one CI job though
14:52 zmike: I think most ci jobs use debian, so maybe this is the only one using fedora
14:53 DemiMarie: jenatali: Windows GPU virtualization question: Would it be possible to create a WDDM 2.0 driver that wraps Vulkan?
14:53 mareko: zmike: I've added a commit into the MR that renames glapi symbols exported from libgallium
14:54 zmike: testing
14:54 zmike: works \o/
14:54 jenatali: Demi: what does that mean?
14:54 zmike: symbols no longer clobbered
14:56 mareko: zmike: amazing, thanks a lot
14:56 daniels: hrm, old glapi really shouldn't be present anywhere in CI
14:56 DemiMarie: jenatali: I want to support virtio-GPU native contexts with Windows guests, which means two things: the shader compiler runs in the guest, and the GPU is a paravirtualized one.
14:56 zmike: mareko: teamwork 🤝
14:56 MrCooper: zmike: Debian stable has waffle 1.7.0
14:56 zmike: cool so that's broken too
14:57 MrCooper: daniels has a point, system libglapi isn't supposed to be there in CI
14:58 jenatali: Demi: so you're asking, can you write a Windows WDDM2 kernel driver + Vulkan (and probably D3D) usermode drivers that translate to DRM virtio-GPU native contexts? Technically that's probably doable but sounds really hard
14:59 DemiMarie: jenatali: the goal is to use Mesa for the usermode part
15:00 DemiMarie: Mesa already implements Vulkan.
15:01 mareko: DemiMarie: the difficulty of supporting anything that is not Linux host on top of Linux guess is 100x at least
15:01 mareko: *guest
15:02 jenatali: You'll need to replace a lot of things. Mesa talks DRM, not WDDM (generally). If you want to use virtio-Gpu you either need a WDDM-to-DRM converter in a WDDM KMD which might be impossible, or you need to change the user mode stack of Windows to not require a WDDM driver, e.g. the Vulkan loader
15:03 jenatali: If you want things like the desktop compositor to be accelerated in that scheme, you need to replace D3D with something that can work with non-WDDM driver too, like vkd3d/dxvk. But then it's not out-of-the-box Windows anymore
15:03 jenatali: So you need a custom ISO or something for your VM
15:03 jenatali: So, good luck
15:04 jenatali: Or you would need to replace DxgKrnl so that can translate *all* of WDDM instead of just the KMD portions of it, which again makes it a custom ISO situation
15:05 DemiMarie: jenatali: There’s no way to avoid the custom installer in my case.
15:08 jenatali: That's not just a custom installer in the guest, you need to replace core OS components
15:11 DemiMarie: jenatali: Is a WDDM-to-DRM converter possible?
15:12 jenatali: Maybe?
15:14 DemiMarie: mareko: BSD guests should be fairly straightforward.
15:37 youareillpeople: <youareillpeople> we capture all the terrorists from finland,estonia,sweden tell me trash Lynne do you want to get death penalty? cause thats what they all get who conspired with terror against me, theres all the info what they arranged with court orders in the net, we execute them all by force.
15:43 mareko: DemiMarie: not at all, the linux kernel GPU subsystem with virtio is required
16:08 DemiMarie: mareko: All of the BSDs include a part of that subsystem.
16:08 DemiMarie: jenatali: How bad would replacing all of D3D be?
16:09 DemiMarie: Given that VKD3D and DXVK do work.
16:14 jenatali: Good luck
16:31 DemiMarie: The problem is that they are closed-source and proprietary.
16:31 DemiMarie: jenatali: Is the protocol used by GPU-PV on Hyper-V documented?
16:33 pac85: DemiMarie: but maybe that wouldn't be strictly necessary? I'm talking about reimplemeting the kenel side so as to make it indistinguishable from userspace
16:34 DemiMarie: pac85: That is not possible without reverse engineering. See gfxstrand’s talk for details on why (tl;dr: the Windows interface is neither fully documented nor guaranteed stable).
16:34 jenatali: Demi: I thought so but I'm not sure
16:34 jenatali: The Windows interface is absolutely stable
16:34 DemiMarie: jenatali: `pPrivateData`
16:34 jenatali: Oh, yeah fair
16:35 DemiMarie: If you could deprecate non-NULL pPrivateData that would be awesome :)
16:35 pac85: DemiMarie: I'm familiar with the uapi for AMD to some extent and tbh I don't think it would be a problem to RE, nor that it is that unstable
16:36 pac85: like, sounds much to me like much less work thatn rewriting the whole userspace stack
16:36 DemiMarie: pac85: so one problem is that it might change in a security fix
16:36 pac85: and in fact I think the RE would be the least of your problems
16:36 DemiMarie: Where security fix = fix for remote code execution via WebGPU.
16:36 pac85: I don't think so?
16:36 pac85: I mean it can change in theory
16:37 pac85: but it kinda tends to just be stable in practice
16:37 DemiMarie:wishes that Vulkan was not only the standard but also its implementation in Mesa, thus requiring everyone who wanted to implement Vulkan to do so in upstream Mesa
16:39 pac85: Windows actually has a way more uniform uapi than drm. Like buffer management is fully standard and docoumented afaik?
16:39 DemiMarie: pac85: The problem is the `pPrivateData` fields.
16:39 pac85: I think that's mainly for command subission though
16:39 DemiMarie: That said, gfxstrand was able to make Mesa use the AMD KMD.
16:40 DemiMarie: So it should be possible to reimplement a KMD that AMD can use, and rely on conformance to make sure it is correct.
16:40 DemiMarie: Then Red Hat could get some sort of contractual agreement with AMD to not break it.
18:05 eric_engestrom: dcbaker: sure, I'll make a release with the current state of the 24.3 branch :)
18:05 eric_engestrom: (and sorry for the delay, I'm not online often these days; I'll be fully back Feb 24, and before that pretty much only when dealing with 25.0 releases)
18:11 dcbaker: eric_engestrom: no worries, and that would be great on 24.3. I appreciate the help, the flu that’s going around here this year is brutal
18:13 eric_engestrom: (release.sh running right now)
18:14 eric_engestrom: I'm not quite sure what's different in your flow compared to mine, I see that you use MRs to sync staging/X.Y with X.Y, so maybe I'll mess up something and you'll have rebase conflicts or something 🙃
18:17 eric_engestrom: btw I'm not sure what to think of that MR flow, it removes the information of which MR the commit actually comes from, which can be useful eg. if there are regressions in a stable release... but also, I guess the real information is one "cherry-picked from $sha" indirection away, so it's not a big deal
18:18 dcbaker: I just use those when I have manually back ported patches to ensure that the full ci gets run
18:18 dcbaker: I’m sure I could trigger the full ci another way, but the Mesa ci is really complex
18:23 eric_engestrom: dcbaker: release done, doing the docs update on main; do you want to post the release email or do you want me to do it?
18:24 dcbaker: Could you do the email? My client got broke by python 3.13 removing mailcap…
18:25 eric_engestrom: sure
18:34 eric_engestrom: dcbaker: all done; for the calendar, I'll push back the next release one week so that it's 2 weeks from now, ok?
18:36 eric_engestrom: (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33171/diffs?commit_id=9be3a3b9e594412ae068939ccb26403c7cfabb66)
18:46 zmike: how do I find the history data for a job?
18:47 zmike: I want to find out when zink-anv-tgl-traces-restricted started failing
18:47 zmike: I guess I'll file a ticket
18:58 daniels: eric_engestrom: do you mean pushing the 25.0 branchpoint back another week to Feb 4th, or a 24.3.x?
19:00 eric_engestrom: daniels: see the commit I linked (I don't understand the second part of your question ^^)
19:01 eric_engestrom: zmike: that's not a thing, unfortunately; we (ci people) have been discussing developing a database for gitlab ci results so that we can do that sort of query, but it doesn't exist yet
19:01 zmike: I think it is a thing
19:01 zmike: and you are mistaken
19:02 eric_engestrom: I mean, you can manually look at any job you want
19:02 eric_engestrom: but I don't know how you would ask "when did this job flip from pass to fail"
19:02 eric_engestrom: but I would be very happy to be wrong :D
19:04 zmike: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12503#note_2747899
19:04 eric_engestrom: ah right, I keep forgetting grafana has some info like that
19:05 zmike: I knew there was something but I couldn't remember where/how
19:06 eric_engestrom: thanks daniels :)
19:08 eric_engestrom: I have to go now; dcbaker let me know on the MR if the calendar change (last commit) is not ok, and unassign Marge so it doesn't get published
19:16 Venemo: does anyone have any idea why vkcube disrespects DRI_PRIME?
19:41 glehmann: maybe it does its own device selection instead of picking the first one`?
21:23 daniels: eric_engestrom: InfluxDB is a database that can be queried; Grafana is just one frontend to it