00:00 robclark: hmm, well same thing happens in the end, I guess it just depends on who inserts the CSC into the shader
00:01 Company: afaiu some embedded gpus have hardware for yuv
00:01 robclark: otherwise, it's only when you start getting into tiled/modifiered formats that driver needs to understand it is yuv
00:02 robclark: some do w/ various quirks.. depends on how old you are trying to target
00:03 robclark: mostly folks figured out it was better to give the transitors to having more shader cores than spend them on special case magic yuv csc
00:03 Company: I have no idea what I'm trying to target
00:04 robclark: I know some sgx5 stuff had magic-yuv samplers, and maybe vivante? On more recent things qc has yuv formats samplers, but that is just for slurping in ubwc/tiled data into shader, not for the csc itself
00:05 robclark: even like 10+yrs ago, xbmc was doing conversion in the frag shader and it was fine
00:06 Company: yeah, for desktop stuff it won't matter
00:06 Company: other than having to write all that code
00:06 robclark: naw, I mean on mobile stuff running linux.. I guess that was back in a2xx/a3xx days
00:07 Company: I suppose video doesn't need shader cores for anything important
00:09 robclark: well, it sounded like you are doing sw decode.. and if sw decode gpu should have no problem keeping up with yuv conversion.. on little mobile things the hw video decode is completely separate from gpu (and on x86 for silly legacy reasons it is part of the gpu but I guess not using many of the same resources that gpu rendering is)
00:10 robclark: if you are doing hw decode, stick with dmabuf and modifiers because there can be special layouts in memory and that sort of thing... if sw decode then gpu is likely not being pushed too hard compared to cpu
00:14 Company: I'm doing API design for GTK atm
00:15 Company: and the question here is how many features I want to provide for people doing video things
00:16 Company: the people who write serious apps are probably going to use hardware stuff anyway - via GStreamer or so - but some people do small projects with ffmpeg
00:16 Company: also, raw buffers are neat for testsuites
00:17 Company: I could test the YUV part of out code with them, but I can't with dmabufs, because I can't create dmabufs in CI I think
00:19 robclark: for testing, can you get something w/ real hw decode and real dmabuf's in CI to test that path? Otherwise I think there are too many sharp edges
00:19 robclark: fake dmabufs might be fine for (although maybe slow) for llvmpipe..
00:22 Company: I think the software decoders don't even do dmabufs
00:23 Company: *software renderers
00:24 robclark: there are various ways like abusing dumb buffers or vgem.. vgem might be an ok option for sw decode + sw rast (like llvmpipe).. but any of those approaches could have sharp edges when you start involving real hw (ie. vgem won't really be cache coherent w/ real gpu on lot of hw, etc)
00:25 robclark: and for CI you probably want to be testing something that more closely approximates real life
00:27 Company: yeah
08:45 pq: dj-death, DemiMarie, Weston's gl_renderer_attach_shm() does indeed handle some YUV wl_shm formats with color conversion in shaders, and it does not use any gbm or dmabuf for that.
09:22 swick[m]: I have a mutter branch that does the same
09:23 swick[m]: and the tests in CI run either without any GPU and via shm or with VKMS and llvm using dmabuf
09:25 swick[m]: but yeah, testing dmabuf code paths is always annoying
10:02 hakzsam: any ideas what happend to 23.2.xxx releases? last release is 23.2.1 from September 28
10:03 pq: I wonder if compositors would refuse to use new KMS features that cannot be tested with VKMS...
10:04 emersion: that's the wrong way to think about it
10:04 emersion: imho
10:04 emersion: compositors should _add_ the missing VKMS features
10:06 emersion: (positive policy, instead of negative policy)
10:06 pq: different wording, same result?
10:07 emersion: the negative wording makes it sound like compositors will not step up
10:08 emersion: btw, "compositors" should not be interpreted as "all compositors"
10:08 emersion: i dislike VKMS requirements
10:08 pq: yes, I did mean some compositors, not all compositors
10:08 pq: Ok. I'm sure I won't step up.
10:08 emersion: (i dislike requiring VKMS impls, because it's already so much work to do a tiny new uAPI)
10:09 emersion: i'd rather not "complain and do nothing" about missing VKMS features
10:10 pq: am I complaining?
10:10 emersion: i said *i* :P
10:10 pq: me too
10:11 emersion: i don't think you're complaining, but i don't think blocking support and doing nothing about it would help a lot
10:11 pq: I'm just wondering how things will turn out in practice, I'm not trying to set up a policy or doc or anything.
10:12 pq: everyone makes their own policy anyway
10:12 emersion: sure
10:14 pq: Just to be clear, the reason I won't step up is that I have enough to do without even hooking up KMS in a compositor to begin with anyway.
10:17 emersion: yeah, ENOTIME, and we all have our priorities
10:41 sima: I think just continuing to sell vkms as an improvement to the kms feature testing/compositor implementations is the best we can do
10:41 sima: do a bunch of gsoc/outreachy maybe
10:42 sima: maybe could try to sell google on this idea for their cros compositor (ozone iirc?) eventually
10:43 emersion: yea
10:55 mathr: hi! mesa gitlab suggests asking here to find the right channel; I have an issue with some OpenCL where it works fine with PoCL on CPU (AMD 2700X, ARM Cortex A53), but I'm getting bad output with Clover on GPU (AMD RX 580)
10:56 MrCooper: try rusticl, clover is on the way out
11:13 mathr: MrCooper: it reports 0 devices, have tried with some environment variables but either i'm doing it wrong or rusticl doesn't support my hardware yet (I'm using Debian Bookworm, don't have the chops to backport all the rust stuff needed for newer rusticl, did try newer Mesa/Clover without rusticl but my issue persisted)
11:14 MrCooper: mathr: you need to set the environment variable RUSTICL_ENABLE=radeonsi
11:18 mathr: MrCooper: then clinfo -l prints "radeonsi: driver missing
11:18 mathr: and rusticl lists no devices
11:21 mathr: this is probably because my mesa is too old (mesa-opencl-icd 22.3.6-1+deb12u1)
11:43 karolherbst: ohh yeah.. you want 23.2 or something
11:44 karolherbst: 23.1 in theory should work, but I think there are some issues still
11:51 DavidHeidelberg: mathr: if you're on testing or unstable, you can use https://gitlab.freedesktop.org/gfx-ci/ci-deb-repo/-/tree/trixie
11:53 DavidHeidelberg: oh, I see, you're on Debian 12, so far you'll need to compile mesa yourself I guess :) in future I'll try make nightlies, but cannot promise how soon
11:54 cmichael: enunes, I haven't forgotten you ;) Was on vacation last week, and playing catchup yesterday & today. I'll get an email out today to the "powers that be" and get back to you when I hear something
11:55 cmichael: (wrt the software rendering patches)
11:57 mathr: DavidHeidelberg: yeah i managed to backport Mesa deb from testing to stable, but patched to omit rusticl because i would have needed to backport too many rust deps...
11:58 mathr: it's only a small part of my opencl stuff that is broken in Clover (using 4 floats in a trenchcoat for higher precision using compensated arithmetic / "double-double" techniques)
12:07 DavidHeidelberg: mathr: btw. since I didn't even tried yet, can you point me how your change looks? I would just stole them so I could prepare package (missing rusticl isn't problem)
12:11 mathr: DavidHeidelberg: in debian/rules, "RUSTICL_ARCHS = ", in debian/control.in delete dependencies mentioning @RUSTICL_ARCHS@, make corresponding changes in debian/control
12:12 mathr: DavidHeidelberg: then to get llvm-16 with spirv support, i had to go via llvm-16 without spirv support (i used apt.llvm.org for binaries, then used that to build the spirv tools, then backported the llvm-16 debs)
12:12 mathr: mathr: (have to do that before building mesa)
12:14 mathr: ah found my more detailed notes:
12:14 mathr: - install llvm-16 etc from apt.llvm.org (to be able to build spirv)
12:14 mathr: - backport spirv-headers-1.6.1+1.3.261.1
12:14 mathr: - backport spirv-llvm-translator-16-16.0.0 (editing deps to remove version 13 of gcc, seems 12 is fine...)
12:14 mathr: - backport directx-headers-1.610.2
12:14 mathr: - backport llvm-toolchain-16-16.0.6 (this version will use spirv)
12:20 enunes: cmichael: thanks for the heads up and welcome back :) I contacted earlier mostly to drop my contact info
12:20 cmichael: enunes, no worries :) I did get your email
12:22 DavidHeidelberg: mathr: when you describe it like this... I can't use it, at least because of llvm-16 from non-debian sources. Rest of backports, can you help with them?
12:22 DavidHeidelberg: mathr: I would welcome someone pushing these packages (spirv-* directx-headers, llvm) into https://gitlab.freedesktop.org/gfx-ci/ci-deb-repo/
12:23 mathr: DavidHeidelberg: there is some kind of dependency loop in Debian testing, where spirv-llvm-translator depends on llvm-16, and llvm-16 depends on spirv-llvm-translator
12:23 DavidHeidelberg: :D
12:23 DavidHeidelberg: we all love LLVM
12:23 DavidHeidelberg:is aware that sarcasm in face expression isn't visible over IRC, but guess the sentence is self-explanatory
12:28 karolherbst: mathr: yeah... so "some" packagers build libclc together with llvm
12:28 karolherbst: but to get the spirv version of libclc you need the translator
12:29 karolherbst: go figure
14:29 DemiMarie: mathr: You can use `cargo vendor` to bundle all of the rust deps, but another option might be to see if you can reduce the number needed.
14:49 hakzsam: anholt_: can you take a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25953 please?
17:27 anholt: there's interesting new testing for dmabuf usage in gl in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25449 and many drivers fail. if you're a GL driver maintainer, you probably want to take a look at these new dma buf modifiers tests, it's coverage that has been really missing in mesa testing.
17:31 emersion: nice to see this tested
18:54 DavidHeidelberg: anholt: sorry about the a618-tu I thought I dropped the commit :/ Anyway in two hours I'll get home and revert the commit. At least the important reduction of container size and other stuff got in. Thanks for catching the commit which shouldn't sneak in :)
21:29 jenatali: Hm, looks like some rules changes made the second-level Windows container jobs manual where the used to be automatic. That's somewhat annoying
21:33 airlied: you have to use the script
21:34 airlied: ./bin/ci/ci_run_n_monitor.sh
21:36 jenatali: I've said it before, it's not very Windows-friendly...
21:37 karolherbst: there is a python version
21:37 jenatali: Where normally, one UI click runs only the jobs I care about anyway
21:37 jenatali: karolherbst: Still not Windows-friendly. It assumes Linux filesystems for token storage
21:37 karolherbst: ahh yeah.. pain
21:37 jenatali: I guess I could try to contribute patches to it, but so far everything I want I got from one UI click
21:38 jenatali: Now it's 3, still fine, just slightly more annoying
23:08 Company: ndufresne: do you have a setup on some of your weird hardware that'd be good for testing dmabuf passthrough?
23:08 Company: making it work on desktop isn't really noticeable...
23:26 DavidHeidelberg: If you testing your branch with "ci_run_n_monitor" or run pipeline testing by hand, please rebase on top of "main" from YESTERDAY (if you didn't already). If you don't the caching proxies keep ~ 2G base images instead of new one 1G, so this should eventually speedup your runs and relief a network transfers and container unpacking a bit.
23:28 DavidHeidelberg: *at least from yesterday, it needs to include the new containers
23:46 DavidHeidelberg: anholt_: would you be ok if I'd keep the zink-tu-a618 reduced to two jobs since now we run 10 jobs on max. avail 9 devices
23:47 DavidHeidelberg: without deqp fraction ofc, so full test
23:48 DavidHeidelberg: (accounting for sometimes one or two devices goes to bad state, sometimes someone runs manual jobs to test something etc etc.)