07:36 airlied: jekstrand: if you have a chance 20389 could do with a once over to make vulkan video move
08:02 airlied: Lynne: hey, back around this week hopefully, I've lost the command to dump/verify the headers, please reenlighten me :)
08:26 Lynne: ffmpeg -i <in> -c:v copy -bsf:v trace_headers -vframes 1 -f null -
08:26 Lynne: too early, I wasn't expecting you until tonight!
08:29 Lynne: you'll have to wait a little more for your new year resolution, I did figure out how to comfortably expose tile groups
08:37 javierm: sravn: are you happy with https://patchwork.kernel.org/project/dri-devel/patch/20230107191822.3787147-14-javierm@redhat.com/ now?
08:39 javierm: sravn: asking because on a second thought, maybe you wanted a preparatory patch to change those generic_write calls to dcs_write instead
09:15 airlied: Lynne: ill be still a bit flaky this week, kids at home with me!
09:30 airlied: Lynne: amd gave a hint about skipping sps/pps headers but it seems to corrupt slice header, will dig a bit more
09:54 danvet: jani, good enough reply on the drm_minor doc patch for an ack?
10:06 jani: danvet: none of that addresses debugfs files that are not just about displaying information, right?
10:07 jani: danvet: see i915_debugfs_register() and everything in i915_debugfs_files[]
10:07 jani: danvet: ditto for display side
10:08 jani: so there's all this new infrastructure we can convert to, yet can't get rid of any of those, leaving us with the separate register step anyway. unless I'm missing something
10:09 danvet: yeah it's still rather aspirational, hence should and all that
10:09 danvet: it's about as much should as using devm/drmm
10:10 danvet: jani, should I add that in the text? i.e. making it clear it's more about new users and filling the gaps
10:12 danvet: jani, the main justification really was that drivers shouldn't add random sysfs interfaces to the kdev
10:15 jani: danvet: ack
10:15 jani: I mean with this, and I get the motivation about sysfs, and it's way more important
10:15 danvet: let me try to word-smith something
10:15 danvet: brain is very much in monday morning mood
10:16 jani: just be careful, piling on text about debugfs might be counterproductive regarding sysfs
10:17 Lynne: airlied: I'm impressed that it's even possible and they didn't bake it in
10:18 danvet: jani, so just current text and let people discover the todo situation about the debugfs side themselves?
10:18 danvet: since that is also already documented there
10:19 danvet: or just in the commit message?
10:23 danvet: jani, https://paste.debian.net/hidden/b089c803/ ack on this?
10:27 jani: danvet: "hardwire struct device @dev" - should it be hardwired or what?
10:27 jani: danvet: anyway, ack
10:27 danvet: hardware
10:27 jani: :)
10:27 danvet: "hardware" for virtual devices ofc
10:29 danvet: jani, https://paste.debian.net/hidden/8f6ba405/ extra clarified because they're both struct device
10:54 jani: danvet: ack
11:15 melissawen: Does anyone know when LPC 2023 will happen?
11:17 Nyaa: Probably in 2023
11:19 psykose: given videogame naming schemes, it already happened in 2022
11:19 melissawen: LOL
11:20 Nyaa: Does look like they generally aim for October-November, so until they announce otherwise, probably around then
11:23 Nyaa: psykose, given car model years, they announced it in 2021
11:23 psykose: ;)
11:32 Nyaa: I am kind of tempted to attempt making a shader-based h264 decoder, probably would be too slow to bother with though.
11:34 Lynne: decoding cabac will be like decoding on a pentium mmx
11:36 Nyaa: Lynne, even just having baseline would be better than no implementation
11:36 Lynne: not when everything that matters uses Main
11:38 Nyaa: yeah but does that same most stuff use CABAC
11:40 Nyaa: support for a feature does not necessarily mean use of it
11:41 Lynne: pretty much everything has used cabac in the last 10+ years
11:49 Nyaa: hmm, youtube still serves at least one format on all videos using baseline still
11:52 Nyaa: oh nice, at some point google started putting the encoding date into videos
15:54 rodrigovivi: airlied: danvet: what's your views on the future of gitlab flow with the drm drivers? mailing list for a time is kind of unavoidable anyway on the cross dependencies, but do you see drm drivers attempting to move forward with some hybrid model like mesa had for a while accepting PR and patches?
15:55 rodrigovivi: I'm asking more for the xe perspective since our flow is on gitlab atm, but I believe that we should align with all the other drm drivers instead of having a different flow... i.e. moving towards mailing list asap and having it active on the cgit, like other drivers... or do you see something different? what would be your open recommendation to us?
16:32 sravn: javierm: "sravn: are you happy with https://patchwork.kernel.org/project/dri-devel/patch/20230107191822.3787147-14-javierm@redhat.com/"
16:33 sravn: javierm: Yes, r-b
16:33 javierm: sravn: perfect, thanks! I'll wait a few days in case I collect more tags and then will push the patches then
16:43 danvet: rodrigovivi, airlied there was just this w/e a bit of a discussion on mastodon https://chaos.social/@sima/109648994079552229
16:43 danvet: see also jani's question on whether fd.o can support the load
16:45 danvet: jani, thx, I hit sent (after some nice workout and even better sauna this afternoon)
16:49 javierm: danvet: I wonder if a good compromise could be to keep using ML but then instead of pushing directly to drm-misc, to open MRs
16:50 javierm: that way the load won't be that much initially and patches could be properly tested through CI before landing
16:50 javierm: this all could be done transparently by dim, so from drm developers POV, the workflow won't change that much
16:51 danvet: javierm, I think concern was more when phoronix links to some mr and everyone picks that up
16:52 danvet: since the load is substanstially more to serve a gitlab mr than a mail archive
16:52 javierm: danvet: ahhh, I see
16:52 danvet: but yeah still posting to m-l for review and doing the gitlab mr for CI only at first sounds like one of the intermediate steps that makes some sense
16:52 danvet: maybe
16:54 javierm: danvet: yup, I was thinking something like `dim push-branch drm-misc-next` to open a MR under the hood, kind of how gerrit works IIRC
16:54 danvet: yeah
16:54 danvet: maybe combine with b4 for sending the entire pile out or something
16:54 danvet: for one stop shop
16:54 danvet: bonus if the cover letter has the link to the m-l submission
16:54 danvet: *gitlab mr I mean
16:55 javierm: danvet: yeah
16:55 javierm: danvet: we do something like that in the fedora kernel package, we open MR in gitlab but there's a bridge that posts to the fedora kernel ML
16:56 javierm: i.e: https://www.spinics.net/linux/fedora/fedora-kernel/msg16553.html
16:57 danvet: imo gitlab->mr bridge is a bit hopeless
16:57 danvet: because then people have that idea that somehow magically m-l comments will land back on gitlab
16:57 danvet: which just isn't going to happen in a meaningful way
16:57 danvet: pls fd.o admins really don't want to be in the mail amplifier business with gitlab :-)
16:57 javierm: danvet: indeed. What I see that happens with this workflow at the end is that fedora kernel developers just comment on gitlab and most people just ignore the ML :)
16:58 danvet: yeah
16:59 danvet: and if we go that way, we need something where gitlab mr are clearly much better than m-l, because if that's not the case, we'll never get a substantial critical mass over there
16:59 danvet: and I think the best way to sell this is with really good CI, where developers can check results and fairly easily add more (sw-only at least) testcases and stuff
16:59 danvet: that seems to have been the catnip to move the heard in other projects at least, like mesa
16:59 danvet: without that all we'll probably achieve is nice fragmentation
17:01 javierm: danvet: agreed, that's why I think that keep the current ML workflow for easy collaboration with the rest of the kernel but introducing MR and CI pipeline runs before landing is a good compromise
17:02 javierm: danvet: because we still rely on drm-misc committers to properly test before pushing to drm-misc, and could still introduce build issues and whatnot
17:04 danvet: javierm, yeah mr for pushing would be really good and 100% an improvement
17:05 danvet: and yeah kernel also has a higher barrier because at best we can only move all of dri-devel
17:05 danvet: and we do have some substantial interactions
17:05 danvet: at least medium term I don't think the kernel will move
17:05 javierm: danvet: agreed
17:06 javierm:dreams of better times where the kernel is all rewritten in rust by using MRs :)
17:07 javierm: maybe it will happen before I retire...
17:07 rodrigovivi: danvet: yeap, I agree... the fragmentation is what I'm mostly afraid... and that having a better CI would be the zero ground....
17:08 rodrigovivi: worst scenario of the fragmentation that I can think of is the new folks just learning github and gitlab flow not having git-email and email clients setup to quick cross collaboration with other subcomponents...
17:09 rodrigovivi: but also even with old folks... having to alternate the environment is not that trivial and more prune to dummy mistakes
17:10 danvet: yeah I mean that's the other one
17:10 danvet: once we have this for maintainer mr and drm-misc pushing
17:10 danvet: I do think that you probably want to switch both xe and i915
17:10 danvet: otherwise good luck
17:14 rodrigovivi: yeap, I fully agree! thanks for confirming it ;)
18:33 airlied:would love to trial drm next MRs if we had CI integrated
18:54 airlied: Lynne: not sure it isnt hardcoded, trying to find workarounds, older fw had a disable bit but its gone in newer
18:55 DemiMarie: Is the Xe driver smaller than the i915 driver? If so, why? Is it because tasks that used to be part of the driver are now handled by GuC firmware?
18:56 mlankhorst: It doesn't support gen11-, so even that makes it smaller
18:56 kisak: keep in mind that i915 covers 9 generations of hardware
18:58 airlied: i915 also semi-actively avoided sharing code with other drivers
19:03 mlankhorst: plus some features are likely missing :)
19:15 alyssa: jenatali: any idea why MR label bot missed !20578 ?
19:16 alyssa: the bot source seems to know about src/asahi/
19:17 jenatali: Has someone picked up those changes in the last 2 months?
19:17 jenatali: Not sure why you pinged me about it
19:18 alyssa:thought the bot was your doing
19:18 alyssa: does *anyone* know where this bot came from?
19:18 alyssa: oh god the singularity is upon us
19:19 zmike: it wasn't me
19:19 zmike: I'm certain of that much
19:19 alyssa: oh no
19:20 jenatali: alyssa: https://gitlab.freedesktop.org/freedesktop/mr-label-maker/-/commits/main/mr_label_maker would say dcbaker
19:21 jenatali: And then I think daniels is the one who set it up to actually run?
19:25 dcbaker: I took some work that mslusarz(? can't remember, it wasn't me) did and polished it, and wrote a dockerfile for it
19:28 dcbaker: alyssa: the bot will only look at MRs that have no tags
19:28 karolherbst: alyssa: I do know it
19:28 dcbaker: not sure if that helps
19:28 daniels: https://gitlab.freedesktop.org/freedesktop/mr-label-maker/-/commit/b28243b6c385c156c21ead36daa2c25381b2d9f0
19:29 glehmann: when is the mesa 23.0 branch point? it looks like the release calendar wasn't updated
19:29 zmike: I think it's weds?
19:29 dcbaker: wednesday
19:29 anholt: skipping drafts is not what I would expect of the bot
19:30 karolherbst: alyssa: yeah.. put it out of draft and then it labels it once, but it never fixes labels later on
19:30 karolherbst: also
19:30 karolherbst: notifying people on every draft is a tad too verbose
19:30 dcbaker: oh poo, I was supposed to send out that update friday
19:35 glehmann: zmike: dcbaker: ah that's what I thought too, I was just trying to find an official source
19:35 zmike: <dcbaker> I AM THE SOURCE
19:36 dcbaker: lol
19:36 dcbaker:will build your source!
19:52 Lynne: airlied: btw do you think it's possible to reduce the alignment needed for the bitstream buffer?
19:52 Lynne: having to pad to 256 bytes is around 100kbps, you can comfortably fit an audio stream in there :)
19:54 jekstrand: airlied: Yeah... I'll try to look. Been reading through Xe stuff.
19:55 airlied: Lynne: for encode maybe?
19:56 airlied:isn't sure what the encode value should be though
19:57 Lynne: assuming the driver always generates aligned base values for vkbuffers, you can just keep decreasing it until it breaks
19:57 airlied: Lynne: what does nvidia report?
20:00 airlied: Lynne: pushed a change to 16 for encode
20:00 airlied: 4 seems to give decode error on SEI type 5 size
20:03 airlied: Lynne: okay hacky disables for sps/pps don't seem to work, so we might have to await a new fw release for those
20:04 jekstrand: airlied: Actually, let me knock out video first. That should be fast. Then I can go read ANV Xe code.
20:04 Lynne: airlied: 256 -_-
20:05 Lynne: you're out of tricks already?
20:05 airlied: yup actually emitting 0 data size has the same crash as not emitting the packets at all
20:06 airlied: the slice header emit seems to be going bad without the sps/pps
20:15 Lynne: really weird
20:15 Lynne: because with d3d12 video, there isn't an option for the driver to generate SPS/PPS values, everything must be done by the user
20:17 Lynne: d3d12 encode even offers AQ adjustments, how did khronos plan to compete with that?
20:22 airlied: Lynne: oh I wonder how the fw does it then
20:45 alyssa: dcbaker: wait so nobody knows where this bot came from
20:45 alyssa: is this chatgpt's doing
20:45 alyssa: are we all doomed
20:46 alyssa: karolherbst: "notifying people on every draft is a tad too verbose"
20:46 alyssa: Hmm, okay
20:46 dcbaker: alyssa: lol, I got it fromone of the other Intel Mesa people, I think Marcin, did some work to finish it, and gave it to Daniel
20:50 jekstrand: alyssa: It's not ChatGPT or the GitHub thing, either. It was written by an actual person. :-P
20:50 alyssa: jekstrand: allegedly
20:50 karolherbst: lol
20:51 karolherbst: I mean, what the bot is doing is really simple
20:51 alyssa: karolherbst: allegedly
20:52 karolherbst: anyway, the bot is on me and daniels 🙃 I was thinking something like that is a nice way of getting MRs of new contributors or ones without access to being labeld automatically so things don't fall through the cracks
20:52 alyssa: karolherbst: yeah, I'm 100% for it
20:53 alyssa: What I'm more wondering now is whether I can lean on it (vs using it as a last resort or for new contributors)
20:53 karolherbst: anyway, rules are defined here: https://gitlab.freedesktop.org/freedesktop/mr-label-maker/-/blob/main/mr_label_maker/mesa.py
20:53 karolherbst: alyssa: it's really simple and it uses paths and/or driver names in titles to label. _sometimes_ if you do 1 loc change in all drivers it's doing the stupid thing and adds labels for everything
20:53 karolherbst: but generally I think we can rely on it
20:54 alyssa: I mean. I've definitely done that stupid thing manually :-p
20:54 karolherbst: and if something doesn't get labeled correctly, we just fix the rules
20:54 karolherbst: yeah... sometimes it's okay, sometimes it's not.. I think it doens't matter in any case
20:54 karolherbst: having pinged the wrong people once is worth the benefits here
20:55 alyssa: agreed
20:55 karolherbst: we might want to enable it for issues as well, but that's alot harder to do
20:55 alyssa: yeah
20:58 karolherbst: maybe title only would be okay, but I suspect we still need to label a lot of things manually.. oh well.. worth checking how badly the bot would label issues
20:59 karolherbst: everybody can run the bot locally with an gitlab API key, it has a dry-run mode so it doesn't change anything
22:36 dcbaker: karolherbst: I can take some blame too, we wanted it at Intel so we can more easily track issues that apply to us
23:01 jekstrand: airlied: Ok, dropped a couple minor things and then I think we're good.
23:01 jekstrand: airlied: One of them is a "did I read the spec right or did you?" so no conditional RB yet.
23:06 airlied: jekstrand: I'll reread, I just found that bit for the first time when I updated the code recently
23:34 DavidHeidelberg[m]: jenatali: canceled your pipeline, already multiple failed jobs, hope you don't mind, there is too many waiting MRs :(
23:34 jenatali: Yep that's fine, should've run it myself first
23:35 DavidHeidelberg[m]: jenatali: np, that's what Marge bot is for, but I never seen queue of 12 jobs waiting for merge :D
23:54 zmike: oh you sweet summer child
23:58 DavidHeidelberg[m]: 2 of them are yours... soooo :D