03:15 airlied: mupuf: some issues with vkcts-navi21-valve?
03:16 airlied: trying to merge 21980 seems to be failing
03:16 mupuf: airlied: just woke up, hakzsam said the same thing 6h ago
03:17 mupuf: I'll look at it in15 mimutes
03:17 airlied: no hurry :-)
06:29 zzoon[m]: airlied: about cts failures, it works with aligning YOffsetforUCb of surface with 128 for both h264 and h265.
06:30 zzoon[m]: airlied: any idea about this? I'm not sure why..
06:32 zzoon[m]: I'm not sure where i can find such a thing defined.
07:40 DavidHeidelberg[m]: MrCooper: nice f38 bump. Btw. ccache 4.7.5 is in Fedora now, you can safely reenable ccache :)
07:44 MrCooper: DavidHeidelberg[m]: thanks, good to know; I probably won't bother myself though, ccache doesn't seem very effective with LTO, and even if it was, I suspect it might hurt the debian jobs more than it helps the fedora job overall :)
07:45 psykose: it is insofar as it caches everything except the link stages
07:46 psykose: the lto itself can cache itself with e.g. llvm thinlto cache dir but that is a lot of busywork and something completely different
07:46 MrCooper: and all the hard work happens at the link stages :)
07:46 DavidHeidelberg[m]: (without numbers) I think it' same effective as before. Just the linking phase takes much oonger and can be ccached :D
07:46 psykose: not quite, roughly half the cold time is pre-link
07:46 DavidHeidelberg[m]: *can't
07:46 psykose: bit more even
07:47 MrCooper: I won't stop anyone from doing it
07:48 DavidHeidelberg[m]: kk, I had to wait for F38 to enable it (not backported into older releases yet)
08:01 hakzsam: anholt: I found one bug but looks like there is another one ...
12:13 Lynne: the more I look at raytracing, the more I see applications for using it in a physics engine
14:00 sarahwalker: I'm looking at implementing timedout_job in drm_sched_backend_ops, and have hit a problem with the documentation. The suggested workflow has as step 4: "Re-submit jobs using drm_sched_resubmit_jobs()". drm_sched_resubmit_jobs() says "Deprecated, don't use in new code!"
14:00 sarahwalker: What should I be doing instead?
17:43 airlied: o.
18:27 cheako: I did try and google this, but it seems like bad signal/noise. I live streamed(obs/x11-shm) for the first time today. Is the av1 side of an arc-a770 usable, does that even exist? I tried VAAPI-h.26x and it crashed, so I switched to cpu encoding... As I'm starting just now I'd like to run bleeding edge when there are no viewers.
18:28 agd5f: Lynne, airlied: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22585
18:30 Lynne: yup, it's nice because airlied could copy it for the av1 encoding extension
18:30 Lynne: but it's not so nice because for some reason no one has submitted any of the patches for review to ffmpeg
21:48 hch12907: cheako: "Hi, this is interesting..." <- aye. As a Gen Z-er, I have always found mailing lists to be kinda unapproachable.
21:53 hch12907: Not because I hate emails, but simply because I am used to using forums/messengers for group discussions - emails are almost strictly peer-to-peer (with occasional Cc).
21:54 cheako: Yes, having a private email address is possibly an understandable barrier to entry. I could understand companies migrating away from email as well, it's not better than any of the other tools available. This project has at least 2 mailing lists and it could be evaluated if issue trackers and forums are more fitting, because both can send emails.
22:00 karolherbst: we have mailing lists?
22:01 karolherbst: :P
22:01 hch12907: yea, I think that Mesa would have an easier time moving away from mailing lists than Fedora
22:01 karolherbst: I think nobody would mind if we just move drm to gitlab entirely
22:01 hch12907: mesa-dev is super inactive compared to other mailing lists I've seen
22:02 karolherbst: yeah.. mesa ain't the problem, the kernel side is sadly
22:03 karolherbst: I think drm-misc has to move first tho
22:03 karolherbst: which is kinda the main reason it stalls
22:03 hch12907: from my perspective though, gitlab+(possibly?)discourse is infinitely more approachable than mailing lists
22:04 karolherbst: after that one moves, e.g. nouveau could just open MRs towards drm-misc to push a bunch of code upwards (or against drm for that matter)
22:04 karolherbst: nah.. don't have to bother with discourse
22:04 karolherbst: just move to gitlab and the ML dies on its own
22:05 karolherbst: you can have discussion there just as fine and then you don't need to juggle between two tools
22:05 karolherbst: and have a chat platform for casual conversations
22:05 hch12907: yeah, mentioned discourse because the fedora ML was talking about it
22:06 karolherbst: I think fedora is in a entirely different situation than we are, but yeah
22:06 hch12907: but I agree, just gitlab would already been real nice
22:06 karolherbst: I mean.. we don't need it for mesa
22:07 karolherbst: so what's the value discourse would add? having discussions in uhm.. a more forum styled website contrary to just some chat platform?
22:17 zmike: I think what we really need is to integrate CI into gitlab discussions for maximum reliability
22:20 karolherbst: maybe we move to gitlab first
22:20 karolherbst: then talk about CI
22:20 karolherbst: otherwise we'll never get there