02:01edman007: Hey, question, I'm not sure if this is a mesa bug or a me/ffmpeg bug... vaQueryImageFormats() returns a list of VAAPI image formats, however, vaGetImageFormats() doesn't work with all of them (I have a radeonsi video card), is that expected behavior? is there some way I can progromatically tell what formats will actually work?
02:04edman007: specifically, mesa 22.3.0 lists 'radeonsi/vcn: enable jpeg decode of yuv444 and yuv400' as a change, and when trying to use yuv444 (presumably because I'm passing it to a SW jpeg encoder and that's the best format) ffmpeg fails to download the image
02:04edman007: before 22.3.0 yuv444 was not listed as a supported format
02:15edman007: correction, it's VA_FOURCC_Y800 that's causing the problem for me
02:15edman007: but seems to be related to some change in 22.3.0
05:27lina: fun: apparently a Wayland protocol change to handle natural scrolling properly was proposed *6* years ago, got one round of review... and then just ended up in limbo.
05:28lina: ;;
05:29lina: marcan just dug up the original patch... https://lists.freedesktop.org/archives/wayland-devel/2017-August/034711.html
10:26daniels: hmm, looks like it just fell through the cracks and v2 didn’t get applied
10:26daniels: mail ftl
10:26daniels: lina: MRs welcome!
10:35Lynne: it feels like every time you search a field in the vulkan spec you come across a large enough limitation to prevent you from using it
10:36Lynne: and then you say "okay, fine, here, I'll do it and it'll be awful", and it sort of is, but you decide to build upon your hack, back to step 1
10:49linkmauve: jenatali, do you build a libGLESv2 that Windows programs can use nowadays?
10:49linkmauve: Or is it recommended that GLES programs use GL_ARB_ES2_compatibility in opengl32.dll instead?
10:52HdkR: ooo, good idea. Finally ES on Windows
11:00MrCooper: CounterPillow: if mpv works fine with VRR, make an MR to drop it from the denylist?
11:27CounterPillow: already done
12:46jenatali: linkmauve: We can, but apps have to bundle it, there's no system GLESv2.dll, but apps can use Mesa as an alternative to ANGLE
13:00linkmauve: jenatali, what is the process for a given app to bundle it?
13:01linkmauve: Wouldn’t it make sense to ship said GLESv2.dll with the system instead?
13:08jenatali: Even if we did, it'd only be with new versions of Win11 meaning apps couldn't rely on it being there. Since it's OSS why not bundle it anyway at that point?
13:08jenatali: You just have to build or download it, link against the .lib files, and then ship the .DLL files with your app
13:10linkmauve: And assume there to be a d3d12 driver on the host right?
13:11linkmauve: This is about 0ad btw.
13:11jenatali: Yeah, which is all but guaranteed these days
13:12jenatali: Ah was about to ask, why the interest
13:12linkmauve: They still target super old Windows versions, the kind unsupported for decades, so it might not be viable just yet.
13:12linkmauve: But any decade now!
13:13jenatali: Heh
13:14jenatali: Do they use ES? I'd assume they use desktop GL
13:16linkmauve: Nowadays they can use either.
13:16jenatali: Is there a reason to prefer ES?
13:16linkmauve: They recently dropped their fixed pipeline GL 1.x, but still support ARB shaders. :D
13:16jenatali: ... wow
13:16linkmauve: And since a few days, also Vulkan.
13:17jenatali: Yeah I saw those headlines
13:22jenatali: Anyways, libGLESv2.dll support in Mesa on Windows has been there since before I started working with it, but I added libEGL.dll support a while back
13:22linkmauve: Oh, I didn’t know!
21:54alyssa: what's the deal with anv_hasvk_state_pool_free_list_only
21:54alyssa: why is it failing in ci
21:54alyssa: i didn't touch anv i swear
22:06dj-death: I think it might have been enabled recently
22:09alyssa: oh
22:09alyssa: can we disable it then
22:09dj-death: odd it doesn't fail for me
22:10dj-death: seems to be failing with clang
22:10alyssa: yes
22:14dj-death: we could disable it on clang builders for now
22:14dj-death: meson.build:21:0: ERROR: Compiler clang++-14 can not compile programs.
22:14dj-death: wtf
22:16psykose: gotta look at the log for that one
22:18alyssa: Seems legit
22:19dj-death: >>> MALLOC_PERTURB_=208 /builds/mesa/mesa/.gitlab-ci/meson/time-strace.sh /builds/mesa/mesa/_build/src/intel/vulkan_hasvk/state_pool_free_list_only
22:24zmike: yeah that's perturbing alright
22:24dj-death: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20710
22:31HdkR: I just learned about malloc perturb a couple days ago, very neat
22:33HdkR: Sadly jemalloc doesn't support it :(
22:53LaserEyess: question about HDMI 2.1, I'm well aware of the current issues with implementing it, but does amdgpu advertise HDMI 2.1 features in any way to monitors/TVs?
22:53LaserEyess: because right now, I'm using an HDMI TV to display 10bit 4k120, with VRR enabled
22:54LaserEyess: and, well, how am I doing that? VRR is confirmed working via the TV's HUD, and 10bit is confirmed via drm format
22:55HdkR: HDMI VRR doesn't need HDMI 2.1 to be exposed. It shows up as an additional EDID block that works on 2.0
22:55HdkR: I have an HDMI 2.0 television with VRR supported as an example. Playstation 5 refuses to use VRR on it because it doesn't support 2.1 :P
22:56LaserEyess: I thought explicit support was needed from the TV for AMD's freesync-on-2.0 (assuming that's what this is)
22:56LaserEyess: maybe mine has that, dunno
22:56HdkR: As for 4k120 10bit...DSC maybe?
22:57LaserEyess: chroma subsampling, as amdgpu likes to do...
22:57HdkR: I don't think you can hit that with 420 encoding according to wikipedia
22:57LaserEyess: does HDMI 2.0 have DSC even?
22:57HdkR: Not part of spec anyway
22:58HdkR: It's either DSC or hitting HDMI 2.1 speeds. Would need to check your logs how that is working :)
23:00LaserEyess: here's a drm_info dump https://0x0.st/o7DW.txt
23:00LaserEyess: connector 3
23:03LaserEyess: well, I'm not complaining I guess, I just hope this doesn't "regress" at some point
23:04HdkR: Well it's running at 4k120, as for how it is getting there, dunno
23:11LaserEyess: luck
23:19zamundaaa[m]: My TV does 4k120 over HDMI too, and I checked with some test pictures that it is using chroma subsampling to achieve that. Can't say I notice it in normal usage though
23:20zamundaaa[m]: Fyi the color depth being 10 bit on the buffer does not mean it's actually transmitting that over the wire. It's only a maximum
23:20HdkR: yea, 8-bit over the wire works with subsample
23:20HdkR: I think you only get that information in the kernel logs though?
23:23HdkR: Or I just don't know where to find it I guess :)
23:36alyssa: madvise is really hurting performance, oy vey
23:37alyssa: like 58fps -> 68fps from ripping out the madvise calls in mesa...
23:37alyssa: I have been told not to do that
23:37alyssa: but the numbers are compelling, yikes.
23:38alyssa: drawoverhead test I was looking at doubled
23:38HdkR: a bunch of DONT_NEED?
23:38alyssa: (those fps are in dolphin)
23:38alyssa: HdkR: there are two issues
23:38alyssa: well
23:38alyssa: three issues!
23:38alyssa: 1. lots of madvise ioctls, which makes the BO cache a lot more expensive than it needs to be
23:39alyssa: 2. due to a kernel bug (I don't know if this was fixed upstream...), we can't DONT_NEED a mapped BO, so we need to munmap() in the BO cache put and then mmap() again in the BO cache get, which means 2x the syscalls as madvise normally needs
23:40alyssa: 3. the constant munmap/mmap means we're thrashing the page tables terribly and spend piles of CPU time in the kernel faulting in pages
23:41HdkR: Probably also expending the zero'd physical page pool faster than the kernel can rebuild it :P
23:42alyssa: all of this is for the happy path when the shrinker isn't actually used
23:42alyssa: when the shrinker IS needed, you're in for a world of pain and users have reported bug where everything nominally works but the shrinker was so terrible they thought it was broken
23:43alyssa: (and also we've had piles of shrinker bugs but that's a different issue ..)
23:43alyssa: and jekstrand commented that madvise() isn't possible with vulkan anyway
23:46alyssa: makes me wonder if users would be better off with a courteous BO cache than with the blunt GL hammer that is madv
23:49HdkR: Still curious if the tradeoff comes from applications that orphan buffers with glBufferData versus them doing their own subrange buffer management
23:56LaserEyess: zamundaaa[m]: if you're using AMD, it's likely the long standing bug where it will default to YUV420 if that's available with HDMI
23:57LaserEyess: so yeah I guess I can't really confirm that 4k120 444 is possible
23:58TMM: I have a weird problem which involves amdgpu but I'm not entirely sure what to make of it and where to even file a bug. The problem is as follows: When I run a rocm workload (stable diffusion) on my 6950XT that has GDM running on X11 the card resets (green screen) and I see "*ERROR* Error waiting for DMUB idle" in the kernel log, then it tries to do a reset which fails because it can't pause GDM and then the box reboots. I can run that same workload on my 6900XT
23:58TMM: in the same box without an issue in this configuration. When I switch GDM to use Wayland the problem disappears. When I login to a wayland session there is no problem either. When I login to an X11 gnome session... ALSO NO PROBLEM. It appears to be only GDM and only on X11.
23:58TMM: I feel like probably this should be reported but where? Is this an X bug? GDM? amdgpu? mesa? rocm?
23:59TMM: Also in no other configuration do I even get a GPU reset
23:59TMM: It works... fine
23:59TMM: It seems I don't even get a problem with GDM running in X11 when it engages DPMS (or whatever the modern equivalent is) that turns off the screen