00:11 zzoon: Lynne: https://gitlab.freedesktop.org/zzoon/mesa/-/commits/av1_dec_anv I was looking into it but film grain support hasn't been done yet.
00:12 airlied: fg is optional, and afaik on intel isn't done in special hw
00:44 Lynne: yeah, we decided to let users handle tat
00:44 Lynne: *that
00:45 Lynne: we've got very fast aom/dav1d-exact shaders for that already, but without any intel support, there hasn't really been a reason to implement that
00:45 Lynne: how complete is the implementation?
02:21 zzoon: iirc it fails on some cts tests. I'll try again a bit later.
03:48 DemiMarie: Lynne: Would this allow replacing `intel-media-driver`, which is a complete nightmare to package?
03:49 Lynne: yeah, there's already a patch to support av1 vaapi in zink on top of vulkan
03:50 Lynne: probably not vaapi filters yet, though, so no deinterlacing or scaling, but in general if you're using them you're asking for trouble
03:50 Lynne: ofc if you stay in vulkan land, we already have much better filters to handle these use cases
04:52 DemiMarie: Lynne: what do you mean by "asking for trouble?
04:52 Lynne: very low quality
04:55 DemiMarie: Would it be possible to replace all uses of VAAPI on Intel?
04:56 DemiMarie: intel-media-driver is a total nightmare to package because so many parts of it require proprietary closed-source shaders, and rebuilding the open-source shaders from source is broken and unsupported.
04:57 airlied: do you have an enumerated list of uses for it?
04:57 DemiMarie: I mean providing a drop-in ABI compatible library
04:57 airlied: if you start writing it now
04:58 DemiMarie: I'll take that to mean "it is possible, but not currently planned."
04:58 airlied: vaapi afaik is an API provided by libva, the driver backends can provide different things
04:58 DemiMarie: Ah, I see
04:59 airlied: intel-media-driver is one backend, whether someone can duplicate that backend, depends on how much effort you put in
04:59 DemiMarie: Does Vulkan Video use intel-media-driver?
04:59 DemiMarie:wonders why intel-media-driver was kept out of Mesa, unlike AMD VAAPI which is in Mesa
04:59 airlied: Vulkan Video and an API provided by Khronos, the driver backends are not
05:00 airlied: some of your questions don't sound like you think them all the way through :-)
05:00 airlied: it's like saying does VULKAN use NVIDIA?\
05:01 airlied: there are lots of implementations of vulkan video from lots of sources and they all provide different feature sets that are expressed through the vulkan api
05:01 DemiMarie: I botched the phrasing on this one
05:02 DemiMarie: What I meant is: Does the ANV implementation of vulkan-video drive the hardware directly, or does it use a library such as intel-media-driver?
05:02 airlied: currently it drivers the hw directly
05:02 airlied: because I wrote it like that
05:02 DemiMarie: makes sense
05:02 DemiMarie: Are my other questions generally better?
05:03 airlied: the thing is intel-media-driver could still provide a vulkan video API alongside anv's
05:03 airlied: with more features
05:03 airlied: there is nothing stopping you from having two vulkan drivers for the same hw providing different queues
05:04 airlied: if I was to speculate wildly on what Intel's windows vulkan drivers does, it would probably involve media-driver linkages
05:05 airlied: whether they feel bold enough to propose that for Linux, not sure yet :-)
05:06 DemiMarie: Considering that intel-media-driver is an unmediated trainwreck for distro packaging (or anyone else who isn't okay with prebuilt media kernel binaries), I hope not :-)
05:07 DemiMarie: Also, this explains why my attempts to search for various Vulkan symbols in the Mesa codebase failed. If there are two Vulkan drivers (for the same or different hardware) in the same process, then the Vulkan entrypoints must actually be in a completely different library that dispatches the function call.
05:13 airlied: all vulkan stuff goes through the vulkan loader
05:15 airlied: all vaapi goes via libva
05:15 HdkR: Does Vulkan allow a video decode/encode only device without rendering/compute capabilities?
05:16 airlied: HdkR: yes
05:16 HdkR: Nice
05:20 soreau: Is it possible to create a cuda-on-compute implementation or so?
05:21 airlied: a what now?
05:21 soreau: like implement cuda API without nvidia
05:22 soreau: or does nvidia have special hw instructions for it
05:22 airlied: that's what ZLUDA is
05:22 airlied: and yes
05:22 soreau: oh
05:22 soreau:never heard of zluda before
05:23 soreau: nice, thanks
05:27 mupuf: airlied is on fire today :D
05:27 mupuf: My turn! Can I get free candy?
05:28 soreau: heh
06:08 airlied: mupuf: now I want free candy :-P
06:27 mupuf: airlied: hehe
08:17 dolphin: airlied, sima: Do you rather have drm-intel-gt-next PR this week or -rc6 week after holidays? It's currently 11 patches.
08:20 airlied: dolphin: drop one this week if you have a chance, might as well get it merged
08:20 sima: dolphin, I guess send it out if you're bored now and then another for -rc6
08:21 sima: yeah same :-)
08:21 dolphin: Ok, I shall send it this week, then will be off over holidays
08:22 dolphin: I'll send it on Wed so that if something goes belly up, there is time to deal with it before being gone in the snow
14:40 jfalempe: javierm: I think I found another bug with simpledrm. In libdrm, the function drmAvailable(), only checks for the card0. But when you boot with simpledrm, the card0 is gone and your gpu driver is usually the card1.
14:41 jfalempe: https://github.com/robclark/libdrm/blob/master/xf86drm.c#L470
14:42 jfalempe: javierm: sorry wrong link, here is the current version: https://gitlab.freedesktop.org/mesa/drm/-/blob/main/xf86drm.c?ref_type=heads#L986
14:54 tzimmermann: jfalempe, that's is a behaving userspace (libdrm). it should test a range of minor devices. simpledrm simply exposes it. and as with all code tha tuses access(), when you get the result, the system might have changed and your information is obsolete
14:55 tzimmermann: IIRC we've heard about similar issues wrt SDL's drm code
14:55 tzimmermann: years ago
14:56 jfalempe: tzimmermann: I was debugging kmscon on a laptop, and this is why it gives a black screen, as drmAvailble() returns 0, it thinks it can't draw.
14:56 tzimmermann: yeah
14:57 tzimmermann: but hotplug-able devices come and go. kmscon needs to deal with that
14:58 jfalempe: yes, I can just remove the drmAvailable() check, because it is then able to use the card anyway. (it uses udev/seats to get the right minor).
14:59 tzimmermann: kmscon is outdated AFAIK. i'd just remove that call for now (if it's only for testing)
14:59 tzimmermann: with udev it appears to do the right thing already
15:00 jfalempe: tzimmermann: yes, but sadly there are not much alternatives to kmscon.
15:17 sima: tzimmermann, jfalempe I guess in the absolute worst case we could do a hack so that simpledrm gets only minor >= 1
15:17 sima: but it's a bit a terrible one
15:23 jannau: not really a solution as that would then break if simpledrm is the only kms device
15:24 jannau: non-kms drm devices would need to avoid minor == 0 too
15:27 sima: uh yeah
15:30 robclark: sima: I guess w/ eGPUs you could manage to get yourself into a situation where card0 is unplugged
15:31 robclark: so I think just call this a userspace bug and fix it there
15:40 tzimmermann: sima, no one has really complained so far. let's keep quiet about it :)
15:41 tzimmermann: and it could happen in any combination of hotplugged display cards/drivers
16:03 jfalempe: I think the drmAvailble() API is a bit useless anyway, that's probably why no one complained yet.
16:03 lucaceresoli: mlankhorst mripard tzimmermann airlied sima: I'm afraid I don't understand the meaning of "New, archived" in patchwork for this small series: https://patchwork.kernel.org/project/dri-devel/patch/20241111-drm-small-improvements-v3-1-a9f576111b41@bootlin.com/ -- it is 75% acked by Dmitry, no changes requested -- should I resend? wait?
16:04 tzimmermann: jfalempe :D
16:04 sima: lucaceresoli, patchwork tries to guess status, it's not accurate in any way
16:08 lucaceresoli: sima: thanks, I'm going to ignore the patchwork status then
16:11 lucaceresoli: sima: but even disregarding the patchwork status the question stands: what to do with a "someone acked, nobody objected, nothing happened in a month" kind of patch series? Resending after a while is what is suggested by other subsystem mantainers, I'll assume it's valid for DRM too unless there are other hints.
16:12 sima: yeah resending after a month is fine
16:12 lucaceresoli: sima: thanks
16:12 sima: and then trying to find someone with commit rights to get things landed
16:12 javierm: jfalempe: what tzimmermann said, that's a user-space bug. Since device numbering is not really deterministic in Linux
16:13 javierm: jfalempe: that's true in general, not only about DRM
16:27 jfalempe: javierm: yes it's a libdrm bug, I will see if I can fix it, or otherwise deprecate it.
16:45 javierm: jfalempe: great, thanks!
20:57 TheJanzap: Hello! I've encountered a performance regression when playing Counter-Strike 2 with Steam Flatpak on the 6.12 kernel compared to 6.11. I have been asked by the developers to report this to my GPU driver repo, but I'm unsure where exactly to post this. Since I'm on Flatpak with an AMD card, this would be the Mesa/Mesa flatpak, right?
21:13 iive: TheJanzap, interesting...
21:13 iive: there is also #radeon channel here, specifically for amd video cards.
21:14 iive: I guess you are using distro kernel and not compiling your own.
21:15 TheJanzap: Yeah, I'm on Arch and had issues on 6.12.4-arch1-1 so I'm back on 6.11.9-arch1-1 for now where performance is normal. Haven't changed anything else
21:17 iive: can you compare the kernel config files, just to make sure that the problem is not a new CPU exploit mitigations?
21:20 iive: btw, is the performance regression a dramatic one?
21:20 iive: I'm thinking some change that might have disabled the hw acceleration entirely.
21:20 TheJanzap: which config files are you talking about specifically? I haven't really changed much, so unless the default Arch kernel or upstream changed something I probably don't think so
21:21 TheJanzap: Yeah, I went from 300 FPS with ~5ms frame time to 50-80 FPS with 10-25ms frame time with max sometimes around 50ms in-game and in the menus
21:21 iive: TheJanzap, the config for building the kernel. Some kernels are built with copy of the file in /proc/config.gz
21:23 soreau: vblank_mode=0?
21:24 soreau: sounds like maybe before, you had no vsync and now, you do :)
21:26 iive: that's good idea, but the game should have it as option... and it shouldn't change with the kernel
21:27 soreau: right, but it might have changed with steam flatpak or something
21:27 airlied: or maybe some VRR
21:27 iive: flatpak means it runs in its own namespace, with its own libraries, and that makes simple checks harder.
21:30 TheJanzap: huh, yeah just changing the kernel shouldn't change the in game settings, but I can give it a shot
21:33 iive: TheJanzap, is the game using OpenGL or Vulkan? Do you have a way to check what is the rendering driver?
21:35 iive: Like, does it mention AMDGPU or LLVM softpipe.
21:40 TheJanzap: afaik vsync is off by default. I've reset the graphic config multiple times, so even if it was on, it shoud have been reset
21:41 TheJanzap: Counter-Strike 2 only has Vulkan support on Linux, MangoHud also says so
21:44 iive: oh. I had no idea. I apparently have it (f2p?) but I've never tried it. 45GB is a bit much.
21:46 TheJanzap: well, since i'm now on 6.11 further testing doesn't make sense and I don't feel like switching back to 6.12 now cause I'm going to bed soon. any way I can follow up on this in a few days? should I create an issue in the Mesa repo?
21:47 TheJanzap: but what I can say is that the game currently runs on XWayland, the game can run under wayland but has some quirks right now
21:48 iive: You can create one, but it would be helpful to locate the problem. Developers can't do much if they can't reproduce it.
21:48 iive: what is your video card?
21:49 iive: phoronix does regular benchmarks, so such regression are found quickly.
21:50 soreau: could it be that the card is in a lower power state than high?
21:50 TheJanzap: Radeon RX 7900 XTX
21:52 TheJanzap: yeah, I'd like to give as much info as I can to make it reproducable and fix this. I was also unsure if I could even file an issue with mesa directly because of Flatpak
21:52 iive: TheJanzap, btw, there is native CS2 and that's what you are running? Not windows CS2 under proton?
21:53 TheJanzap: nope, native. running under proton is unsupported and doing so may or may not cause trouble with the anti-cheat
21:54 iive: fair enough
21:56 TheJanzap: if you're interested, here is the shell script cs2 uses to launch itself. not that it has a lot to do with my issue, but interesting regardless https://github.com/SteamDatabase/GameTracking-CS2/blob/master/game/cs2.sh
22:02 iive: that's good, you can put some env vars to debug stuff... eventually.
22:03 iive: I would love seeing some GALLIUM_HUD stuff, but afaik, vulkan doesn't use gallium. I can't find vulkan_hud...
22:05 iive: there might be some vulkan overlay, but no idea how it plays with the flatpak
22:06 lstrano: iive: he is using mangohud (which is a vulkan layer that overlays information on top of)
22:07 iive: oh, yes. he did mention it.
22:07 lstrano: (mesa also has a simple vulkan layer that shows fps information if you choose to build and install it)
22:09 TheJanzap: I've also removed MangoHud from the launch options, but this didn't have any noticable impact. The only things I've tried that did were ruinning the game under X11 (slight perf improvement) and switching back to 6.11, which seems to have fixed it entirely
22:10 iive: TheJanzap, while you were with the mangohud, when you had perf regression (6.12) was the CPU maxed out, and was there any load on the GPU?
22:12 TheJanzap: CPU was normal around 30-50%. The GPU was at a constant 100%, even in the menus. Which was wierd because usually the fans spin up loud enough for me to hear them, but here I didn't.
22:14 TheJanzap: seen both in MangoHud and the KDE system monitor
22:15 iive: interesting. is your CPU with hyper-threading?
22:16 iive: (SMT on amd)
22:16 TheJanzap: It's an 7800X3D so it should, right?
22:17 iive: games usually avoid running two threads on same core.
22:20 iive: the sw render would probably use everything it could.
22:20 iive: anyway, good luck.
22:24 TheJanzap: I don't even think that the Source 2 engine has a software renderer anymore. I know goldsource has, but I don't know about source 1
22:25 TheJanzap: anyway, i've filed a issue on the mesa repo now. hope we can get some information on what happens https://gitlab.freedesktop.org/mesa/mesa/-/issues/12322
22:25 iive: mesa does have a number of them. I think vulkan also has sw one.
22:28 iive: e.g. `vulkaninfo` gives me GPU 1 "llvmpipe" that's sw render
22:28 HdkR: 4
22:31 TheJanzap: wouldn't using the software renderer entirely avoid the GPU? so a 100% GPU usage wouldn't even be possible?
22:33 iive: yes, that's the idea.
22:34 iive: i also guess that vsync/vblank would block rendering, so the GPU would be <100%
22:34 TheJanzap: so even if for some reason CS2 or vulkan or whatever was using llvmpipe, this would not be the cause of my issue, since the GPU is constantly at 100%
22:34 iive: there might be env var that forces always_software rendering.
22:36 TheJanzap: well, whatever it may be, I'll catch some sleep now. thanks for your support guys, I hope we can get to the cause of this
22:36 iive: `export LIBGL_ALWAYS_SOFTWARE=1` works for OpenGL and most of gallium. no idea about vulkan/radv
22:37 iive: good luck. you'll need it :)