05:58olivial: hmm, is the intention for how applications should handle the error from https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28153 ?
05:59olivial: I guess it's possible to observe the error and retry with a different format, but would be annoying to distinguish this from other EGL_BAD_MATCH cases
06:54AndrewR: Lynne, after some patching cinelerra-gg now can use Vulkan decoding for hevc on rx550/radv! Sadly,vulkan h264 decode crash early (on timeline thumbnail generation), may be our ffmpeg 7.0 to blame. It works as binary/cli, but I guess because cingg uses threading A LOT and this hit harder ..
06:55AndrewR: Laughable thing - I benched vaapi, vdpau, vulkan hwaccels and Vulkan was faster, then was vdpau (!) and then was vaapi ...
06:56AndrewR: so far vdpau survived all files I throw at it, vaapi crashes sometimes on some yt-dlp downloaded files.
07:09MrCooper: alyssa: why can't the .packit.yaml/.spec files live downstream?
07:12daniels: olivial: heh, are you seeing that in the wild?
07:13olivial: daniels: yeah, it prevents gfxbench from running under wayland on the rock5 vendor image lol
07:14olivial: glfw tries to use B5G5R5A1_UNORM with the opaque flag
07:33daniels: olivial: ... ?!
07:33daniels: huh
07:33daniels: yeah, ok, looks like I used --gfx egl
07:33olivial: oh, hmm, I can try that
07:34daniels: that at least wfm with the debos image (well, a derivative of) + weston on rock5b
07:34olivial: I was running it under xwayland until recently, and then patched out EGL_EXT_present_opaque to avoid the bug
07:35olivial: I'm rather confused why it's preferring the 5-bit-per-channel format when it's available...
08:01olivial: daniels: so I get an entirely different problem with --gfx egl: "WLGraphicsWindow: width and height must be greater than zero (0, 0)"
08:01olivial: haven't debugged it yet
08:09daniels: olivial: heh, don’t worry, I can fix that after breakfast - thought I had already but apparently not! itmt fullscreen should work?
08:11olivial: same thing for --fullscreen=1
08:50daniels: olivial: oh no, that one's easy, you just have to pass --width and --height
08:50daniels: the replayer is ... not amazing. I looked at fixing it but decided to do anything else with my life.
08:51olivial: hahaha reasonable
12:52alyssa: Company: there are lots of asahi gaming users who would happy to run mesa nightly's, I just can't expect them to build their own packages because it's seriously nontrivial with FEX
12:52alyssa: (you need 3 builds of mesa - arm64, x86_64, and i386 - and then some magic to bundle it together)
12:53alyssa: MrCooper: they might be able to, I'm not 100% sure on how this all fits together yet
13:07mlankhorst: airlied: I've ported your memcg patch series on xe too, I'm going to try some testing. :)
13:08linkmauve: alyssa, FEX doesn’t call into the native driver?
13:09alyssa: linkmauve: not by default :(
13:10alyssa: for linux fex, you need "thunks" to use the native driver, and thunks are currently broken on fedora for reasons I don't remember
13:10alyssa: for windows fex, this Just Works, but we can't ship windows fex yet for a pile of reasons
13:11alyssa: (for windows games "linux fex" emulates an x86 build of wine, whereas "windows fex" is itself run under an arm64 build of wine)
13:12linkmauve: Every time I’ve wanted to test FEX I failed to build it, maybe I should try again now that I have a quite performant rk3588. :)
13:13jannau: can we get rid of x86 drivers if we fix the thunks? I thought there were unsupported corner cases
13:13linkmauve: ARMv8.2 should make things much better than the eternal Cortex-A53 and A57 I had before.
13:19alyssa: jannau: we can't get rid of them because of the corners, but I'm not worried about regressing said corners
13:19alyssa: if we had "working thunks for everything except corners" + "nightly arm64" + "regular every-3-month-or-whatever x86", I'd be happy
13:19alyssa: I think
13:26neobrain: alyssa: jannau: The only corner I'm aware of is steamwebhelper, which sadly isn't exactly unimportant... otherwise you could drop x86 drivers indeed :(
13:26neobrain: https://github.com/FEX-Emu/FEX/pull/3580
13:40alyssa: neobrain: oh I forgot we merged https://github.com/FEX-Emu/FEX/pull/3487
13:40linkmauve: So since I don’t plan on using Steam ever, I can avoid building an amd64 version of Mesa?
13:45mlankhorst: Also last call for features for drm-misc-next, going to send out a pull request later today
14:28neobrain: linkmauve: in principle yes, though some debugging might be needed if you plan to use 32-bit windows apps via dxvk, since that hasn't received much testing
14:28linkmauve: So far I’ve been using wined3d for i686 games on actual amd64, and only DXVK for one amd64 game.
14:29neobrain: wined3d goes through libgl, right? That should work fine with 32-bit apps then
14:29linkmauve: Yeah.
14:36imre: abhinav__: there's been different problems related to lttpr transparent mode, ime it's unreliable in general, the Standard changed to call for setting non-transparent mode for 8b10b. The SCR's title was "DPTX and LTTPR Spec Update for 8B10B".
14:37linkmauve: neobrain, alyssa, do you have a backup of the PKGBUILD of FEX-Emu? It seems it got removed from AUR.
14:53neobrain: none on my end. afaik they removed it because FEX does not run on x86 🤔
14:53fomys: 123456789mripard: Hi, Luca and I were discussing how to address my mistake in the patch series at https://lore.kernel.org/all/20250424-drm-bridge-convert-to-alloc-api-v2-0-8f91a404d86b@bootlin.com/.
14:53fomys: The Exynos maintainer hasn't responded yet, but Luca is considering sending a v3. We're unsure about the best course of action:
14:53fomys: - Should I revert the commit myself?
14:53fomys: - Should I send a patch to revert the commit?
14:53fomys: - Should Luca send a series that includes the revert commit?
14:53fomys: - Should he send his v3 without Patch 14 and wait for the Exynos maintainer's feedback on v2?
14:53fomys: Any advice would be greatly appreciated.
15:14fomys: mripard: ^
15:28eric_engestrom: Company: flatpak is nice for apps, but for a lib like mesa, most apps use the system libs, so that's what we need to provide
15:28eric_engestrom: providing a flatpak build might also be nice for bugs in flatpak apps though
15:29eric_engestrom: (also, if we take over the "freedesktop" flatpak we might make its name no be a trademark/copyright violation anymore xD)
15:29eric_engestrom: (it always bothered me the way they took our name for their package)
15:32Company: eric_engestrom: yeah, that's why I said you need to integrate into some larger thing (like gnome nightly) that ships platform + apps
15:33Company: iirc the main reason they don't want to ship Mesa git (we argued that in their issue tracker ~a year ago) was the lack of contact person that would ensure issues got resolved quickly
15:34daniels: eric_engestrom: I tried to get freedesktop-sdk to move under fd.o but they were never really interested and tbh it's not like we really have a functional xdg org or platform definition anyway, so I'm not really sure what we'd gain
15:34Company: it came up because GTK main needed a bunch of fixes that were only in mesa git for a while
15:37alyssa: i had no idea freedesktop flatpak wasn't fd.o, oof
15:37alyssa: til
15:39daniels: https://gitlab.com/freedesktop-sdk
15:39eric_engestrom: daniels: yeah I know, and none of us would even care enough to try to get a legal definition and enforce it anyway
15:39daniels: it's primarily Codethink/BuildStream/GNOME people
15:39eric_engestrom: but it kinda bothers me anyway ^^
16:05linkmauve: Is there a machine-readable list of all DRM ioctls and their arguments somewhere in the kernel?
16:09ukleinek: ..ooOO(It's in the source files. They are machine-readable using gcc :-)
16:10linkmauve: ^^'
16:11ukleinek: linkmauve: FTR: Don't take that answer as "There is no such list", I don't know.
16:35MrCooper: linkmauve: the UAPI headers in include/uapi/drm/ ?
16:37HdkR: linkmauve: FEX's tools read the uapi headers and a bit of manual glue logic to know which ioctls to care about.
16:38HdkR: Since some legacy ioctls don't describe correctly what data structures they use or RW direction.
16:46linkmauve: What I want is to update strace to handle everything DRM does, because it hasn’t been updated in eons.
16:47linkmauve: There is a patch floating around which hasn’t been updated against modern strace, but only for i915 IIRC.
17:57zmike: austriancoder: any update ?
17:58austriancoder: zmike: my day job workday is almost over and my etnaviv hacking time starts after that - so no update yet, but my day has some hours left :)
17:59zmike: 💪
18:02HdkR: linkmauve: https://gist.github.com/Sonicadvance1/7d025ee81746b167b539e124573c947a Was the last pkgbuild for FEX
18:43DottorLeo: Hi! I'm reading https://docs.mesa3d.org/meson.html#cross-compilation-and-32-bit-builds and trying to install the 32bit packages with "sudo setarch i686 dnf builddep mesa" as written on the guide but it gives me an error about downloading metadata from fedora :/
18:43DottorLeo: something has changed? i'm on Fedora KDE 42
18:47zmike: alyssa: 🤕
19:10K900: Question: is there actually a reason _not_ to ship rusticl on radeonsi by default on 25.1?
19:11K900: Given there's no clover anymore
19:13K900: CC karolherbst
19:14alyssa: K900: i mean rocm exists, clover isn't the relevant piece here
19:14K900: ROCm is a mess and ROCm packaging on NixOS is _extremely_ a mess
19:31alyssa: not arguing :3
20:44mlankhorst: airlied: https://paste.debian.net/1373590/
20:44mlankhorst: Unsure which ctx needs account_op, so added to all
20:47airlied: mlankhorst: the latest version drops account_op once I post it
20:47airlied: https://github.com/airlied/linux/tree/ttm-memcg-nouveau
20:47airlied: just going to use a placement flag
20:48mlankhorst: That should be easy to make work
21:04mlankhorst: I'm curious, shouldn't it be both VRAM and sysmem mapped memory count as GPU, and how is swapout handled?
21:35airlied: mlankhorst: no VRAM is to be accounted with dmem not memcg
21:35airlied: yeah I have to consider next step how swapout works, first step is just to account allocations at least
21:42mlankhorst: airlied: Yeah, but you might not be able to evict in some cases then..
21:50mlankhorst: Oh well I'll send a pull request early tomorrow and then rebase, if anything it should be easier. :)
21:54airlied: mlankhorst: evicting is also not in the immediate scope, because it's really hard to work out the semantics
21:54airlied: we just don't account evictions for now, but the problem I'm facing is on an integrated platform where there is no discrete
22:21airlied: mlankhorst: I think I'll have to think through swap a bit more, discussion on the list had made me reconsider moving the accounting back into the ttm_tt layer
23:30soreau: I'm wondering why glsl mix() is not working here. I have gl_FragColor = vec4(mix(tex1.rgb, tex2.rgb, progress), 1.0); and it only shows one texture. If I replace 1.0 with progress, that works, so I know it's getting the correct 'progress' uniform value. If I change 'progress' to 0.5 in the mix function, it does not show both textures. However rendering either one or the other texture without mix works too, so I know the textures are valid pixels
23:30soreau: . What might cause mix() to fail in this way?
23:32soreau: It doesn't require blending to be enabled as far as I understand