07:05 mupuf: At least they had the decency of not sticking around...
07:06 mupuf: Jeez, some people really are unhinged
07:49 pixelcluster: was probably our estonian friend? think they have a history of harassing random people for literally no reason
08:02 daniels: yes, it was
08:12 bbrezillon: mripard_: thanks!
09:19 mripard: sima: it looks like drm-tip is only used by drm, misc, xe and intel, I thought it had all trees, am I missing something?
09:19 mripard: jani: I've replied to your mail. Thanks for the report and sorry for missing that one
09:20 jani: mripard: dim has sharp edges and no tests :/
09:22 jani: mripard: anyway, I think we have so many dim users nowadays that we need to figure this out before updating drm-misc or drm-intel repos
09:22 mripard: yeah, totally
09:23 jani: I was just pinged about issues privately too
09:23 mripard: issues? you mean something going wrong with the transition, or the issues hosted on the gitlab repo you have?
09:24 jani: oh just the "no remote found" thing
09:24 mripard: ok :)
09:24 mripard: I've sent a mail to the ML that should get people unstuck
09:24 mripard: and I'm working on the auto-transition code in parallel
09:25 jani: but hitting that when pushing patches, and getting the remote updates at that point
09:25 jani: mripard: thanks for that
09:27 jani: imo make it easy for the user to get it all fixed just by hitting y or ret, but don't modify a user's config behind their back. reasonable?
09:27 javierm: mripard, jani: I wonder if could just do https://paste.centos.org/view/raw/5c71b093
09:27 javierm: or maybe not worth it for a one time transition ?
09:29 jani: there'll be more "one time" transitions ;D
09:30 jani: and I think you'll need to also reload the integration config (search for "Reloading $dim_integration_config... ")
09:33 pq: hey, people are saying that 'modetest' is a good tool to configure DRM KMS in production.
09:34 pq: I'm kinda speechless.
09:35 pq: https://lists.freedesktop.org/archives/dri-devel/2024-February/443465.html
09:36 pq: I'm done my part now.
09:39 emersion: oh my…
10:00 Ermine: Are there any computers with composite outputs?
10:03 pq: of course
11:10 rgallaispou: pq: Wait until you see our internal CI tests... I've struggled to instaure IGT, which is currently being integrated
11:10 pq: sorry?
11:14 pq: emersion, did you just send an email encrypted to me to dri-devel@?
11:15 emersion: maybe
11:15 rgallaispou: I meant that part of the internal CI tests in my company were based on modetest. I've talked internally about how IGT is the way to test, and struggled to make it into the CI
11:15 emersion: ProtonMail doing ProtonMail things probably
11:15 emersion: encrypted to you because it noticed you have a usable PGP key, and unencrypted to dri-devel
11:16 pq: aaah
11:16 pq: I thought everyone else would have had a hard time reading it.
11:16 emersion: i've disabled encryption for you
11:17 pq: no worries, I just thought no-one received it plain text
11:17 pq: thanks
11:18 emersion: right, it fetched the PGP key from keys.openpgp.org automatically
11:24 pq: emersion, have you changed your pgp key for email?
11:24 emersion: hrm, right, i use a different key for email and for the rest…
11:25 emersion: i should try to improve my setup…
11:25 pq: gpg: key 16E23940A7E8E335: new key but contains no user ID - skipped
11:40 mripard: pq: I understand your PoV, but composite output is in a super bad place, because no relevant upstream cares about it. So, yes, of course, it should be the compositors job or whatever to do that, but none will and we have to resort to workarounds.
11:42 pq: mripard, the commit message could have explained so.
11:43 pq: I just saw new UAPI being added in relative silence, since nothing said "UAPI" and no-one had commented on the patch.
11:43 pq: meaning someone will probably just merge that patch after a while of no-one saying anything
11:44 sima: pq, rpi has a pretty good track record of creative solutions :-/
11:45 pq: I was just about to say "probably like the Broadcast RGB affecting YCbCr in vc"...
11:45 pq: (I'd love to get paid to make interlaced and composite work well in Weston.)
11:46 pq: with an actual CRT too, taking into account the non-rectangular shape without black margins
11:47 daniels: mripard: yeah, it’s a shame that no-one has really tried to figure out properly what ‘composite’ means in terms of uAPI - I’ve seen every different combination so far I think :\
11:47 daniels: pq: I’ve been trying to find someone with upstream-useful hardware to do that …
11:48 mripard: pq: sure, that's totally reasonable for you to ask for a better commit log
11:48 pq: daniels, oooh! I lack the CRT. I have an original RPi.
11:48 mripard: I was just saying that the modetest solution wasn't totally a bad one :)
11:48 pq: no, it is a totally bad one
11:48 mripard: or rather, all of the solutions we have are bad ones
11:48 sima: well xrandr at least went through the compositor, so it was aware and could restore
11:48 sima: modetest is a bit much hopes&prayers
11:49 sima: like the moment compositors restore everything on vt-switch it'll break
11:49 daniels: pq: does this mean that you’re nearly finished CM so will have time on your hands? :P
11:49 pq: daniels, not at all, unfortunately.
11:49 sima: and yeah for a few properties the userspace was indeed "user screams at xrandr"
11:50 sima: but "user screams at modetest" feels a bit much a stretch, since with xrandr you _could_ put the right values into Xorg.conf and it would work automatically
11:51 sima: I'll reply and then start cooking lunch, somehow that's very late
11:51 sima: mripard, so moving drm.git also on hold until dim is sorted?
11:52 mripard: sima: I have done some code to update automatically the remote url in dim
11:52 mripard: I'm writing the commit log at the moment
11:52 mripard: so I don't think we need to roll anything back at the moment
11:56 sima: mripard, hm I can still push to legacy drm.git, so I guess that wasn't changed yet?
11:56 sima: or I'm unclear what you don't want to roll back ...
11:57 sima: jani, uh I got a conflict between drm-intel-fixes and drm-intel-next and I'm pretty sure it's not me?
11:58 sima: and I'm rusty on the "just pick -next" git merge incantation ...
11:59 jani: sima: this is probably on dolphin having picked up a few fixes
12:01 mripard: sima, jani: https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/39
12:02 mripard: sima: we pushed the nightly.conf change this morning
12:02 dolphin: yeah, I picked fixes, but did not get conflict
12:05 dolphin: well, now there is a conflict
12:05 mripard: sima: once we agree on the dim MR, I think we can make the cgit repo ro
12:07 dolphin: maybe the conflict was hidden because the remote was missing
12:07 dolphin: resolving it now, anyway
12:07 sima: dolphin, thx
12:23 dolphin: sima: It is fixed now
12:26 sima: mripard, oh that might explain some conflicts, because the gitlab drm is slightly outdated ...
12:27 mripard: drm-next is up-to-date afaik
12:27 sima: daniels, mripard can you pls make the drm.git on legacy ssh ro asap so there's no mess with diverging trees
12:27 sima: airlied_, ^^ fyi
12:28 mripard: it looks like you just pushed -rc6 to fixes?
12:28 sima: yeah
12:28 mripard: I'll make sure drm-fixes is in sync too then
12:28 sima: can you push to gitlab?
12:28 mripard: yep
12:29 mripard: daniels granted me temp rights to do the transition
12:30 sima: aye
12:31 mripard: done
12:40 sima: mripard, oh you pushed the MAINTAINERS directly? figured should have at least some ack from airlied or me :-)
12:40 sima: oh it has lol
12:41 mripard: I had your ack yesterday, and I understood you instructed me to do so?
12:41 mripard: if I misunderstood, sorry :/
12:41 sima: oh I meant I push it, I didn't realize you have full repo access
12:42 mripard: I'm sorry
12:42 sima: airlied_, need to update the drm repo url with git remote set-url or something like that
12:43 sima: mripard, eh no worries
12:46 sima: mripard, hm so reconsidering, ok if I snatch up git committer and add my sob? shouldn't cause issue, and airlied&me are supposed to be the only ones who can push to that one directly
12:46 sima: just so we don't look too much like access rights yolo to linus by accident
12:46 mripard: makes sense to me
12:51 sima: mripard, the ssh url you've used in nightly.conf doesn't match what the gitlab web ui gives you, resulting in some very good entertainment
12:51 sima: I fixed ngihtly.conf so that both ssh url formats are now there
12:52 sima: but probably good to do the same for the other transitions too
12:52 mripard: sima: yeah, it's basically due to whether you're using it with or without the protocol
12:52 mripard: gitlab gives it without the protocol, which works
12:52 mripard: you can use an ssh URL which also works
12:52 sima: hm xe should probably have both too to avoid confusion
12:52 sima: demarchi, ^^
12:52 mripard: but they have different syntaxes
12:53 sima: mripard, yeah but it meant that I had two remotes pointing at the same thing, and for silly reasons git didn't auto-grok the right username for the one with the ssh:// proto prefix
12:53 sima: and so I went on a detour screaming at my ssh_config :-)
12:53 sima: until I realized there's two remotes
12:54 sima: and only one works
12:54 sima: the one I set up and tested yesterday, so was a bit puzzled
12:55 sima: airlied_, maybe want to cherry-pick the MAINTAINERS patch from drm-next to drm-fixes too when you do that, so there's no confusion for linus for the pr this week
13:00 mripard: demarchi: I've updated the MR according to your feedback
13:06 daniels: I’ll sort the mirror later this afternoon
13:33 mripard: sima: otherwise, do you agree with https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/39#note_2300752 ?
13:35 sima: mripard, personally I would have tried the "keep the old urls and mirror there" approach first
13:35 sima: and then maybe add a dedicated check to dim push-branch
13:35 sima: maybe even suggest to run the correct git remote set-url with the first url or so
13:36 mripard: So you would only do so when someone push? I guess I can do that
13:39 sima: mripard, yeah if the more general solutions are tricky, that's what I'd try
13:39 sima: and then maybe we can figure out a better way if we try to sunset the mirrors
13:40 mripard: I think the current solution demarchi suggested work fine, but we have to keep the mirrors for a while
13:40 mripard: which seems to be aligned with what you want
13:41 sima: mripard, I'm also agree with jani, this should be part of the "the remote isn't there, do you want me to create it" logic
13:42 jani: sima: just mentioned on the MR, this also shouldn't be specific to any repo
13:42 sima: mripard, so somewhere in url_to_remote
13:42 sima: jani, yeah
13:43 sima: mripard, so the issue is that if you don't run the separate setup step (like I never run update-branch, I just git pull the branch I use since I have them all)
13:43 sima: then url_to_remote will create a _new_ remote
13:43 sima: which absolutely wreaks it all
13:43 sima: this was my confusion today
13:43 sima: so I think that's the part we need to fix
13:44 sima: probably need to keep a list of old urls in nightly.conf to be able to do that
13:44 mripard: so something like, if the remote isn't there, we add it, otherwise we change its URL?
13:44 sima: mripard, well need to first look whether it's there with the old urls, and if yes, then offer to update the url of that existing remote
13:45 sima: if there's no old url, then the current code that offers to create it
13:45 sima: mripard, which probably means we should asap add all the old drm.git urls so that people don't hit that surprise of "hey here's a new remote you didn't ask for" gotcha?
13:48 mripard: so, that would be pretty much the current logic but it url_to_remote and taking the first repo in nightly.conf instead of hardcoding it?
13:48 sima: https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/38 demarchi I think we need that one for drm too?
13:50 sima: mripard, well url_to_remote only gets the new url
13:50 sima: so if it can't find, you probably need to do url_to_repo
13:51 sima: and then have a old_url_list[$repo] in night.conf or something like that to see whether there's a remote for one of these old urls
13:52 mripard: ok, I'll try
13:53 mripard: not entirely sure how much time it's going to take me, but we'll see
13:55 jani: mripard: once you're done, you're ready to become a new maintainter-tools maintainer ;)
13:55 sima: https://paste.debian.net/hidden/8b0b31ba/
13:55 mripard: jani: once I'm done, I never want to have to deal with maintainers-tools ever again :)
13:56 jani: mripard: resistance is futile!
13:56 jani: sima: do we really want to keep track of old urls?
13:57 sima: I don't think there's another way to upgrade
14:01 sima: mripard, https://paste.debian.net/hidden/c9579363/ extremely untested
14:05 jani: sima: right so you want to ensure the old remote gets removed if it's not named the same as what dim would give it?
14:06 sima: jani, this should keep the name the user has chosen, just update the url
14:06 sima: so it doesn't remove any old remote
14:06 sima: if you do that, all the branches point at the wrong thing
14:06 sima: which is why dim creating new remotes for drm.git is somewhat bad
14:07 dolphin: I created new as drm-new and seemed to work fine
14:07 sima: dolphin, yeah but I guess you don't have any local branches that track drm.git ones?
14:07 dolphin: then I renamed old to drm-old and drm-new to drm, it seems it's discovering the right remote via the url
14:07 dolphin: oh, that is true, only drm-tip and drm-intel stuff
14:07 sima: yeah so for repos where you are committers this doesn't work well
14:08 dolphin: so I believe drm.git will break for you and airlied_ then
14:08 sima: yeah it broke for me :-)
14:18 daniels: I’m going to set up RO mirroring to the old URL this afternoon
14:31 mripard: sima: I think we still need to add the old URLs to nightly.conf, because that prevents people from pulling the latest rerere cache and maintainer-tools
14:32 mripard: once we have that and the old repo setup as mirrors, then I think we're no longer in a rush
14:33 mripard: things might break when pushing to the old repo that would be read-only, but at least we can distribute nightly.conf and maintainer-tools updates
14:34 mripard: ... but then your solution probably deals with that nicely too
14:34 mripard: sorry
14:34 mripard: I'll give it a try
15:02 demarchi: sima: yeah... let's merge mr 38
15:12 mripard: sima: pushed a new version with drm_old_repos
15:12 mripard: it was mostly working :)
15:13 sima: it pains me to admit that I know how to script bash
15:14 mripard: I added you SoB and co-developed-by, I assume that's ok?
15:14 sima: mripard, ack
15:15 sima: mripard, so for migration, we need to make sure everyone updates dim, then we need to update nightly.conf (both old and new place at least) and then everyone needs to try twice and it should work?
15:15 sima: since first try needs the new nightly.conf and then 2nd will fix up remote urls?
15:17 sima: demarchi, I guess you'll rebase !38 one and push?
15:18 sima: mripard, why the for remote loop?
15:19 mripard: sima: yeah, if we push the new nightly.conf with drm_old_repos and the new dim changes, we need people to still being able to fetch that, so the first run should succeed
15:19 mripard: which it will if they *don't* update the URL like we told them to
15:19 mripard: and the second run will update and work just fine
15:19 mripard: so maybe we should just tell them to run dim ub twice without doing anything
15:19 sima: remote=$(url_to_repo "$url") <- this line a bit later will get you the right nightly.conf repo name
15:20 sima: I forgot to move that when I moved the for loop a bit higher above the error message, sry about that
15:20 mripard: sima: there was an syntax error for an out of bounds access if I didn't
15:20 mripard: and definitely don't know how to script bash :-D
15:21 sima: oh if there's no repo name for that I guess?
15:21 mripard: I *think* it's because it's a 2d array: first index in the remote name, second is the URL index
15:22 sima: https://paste.debian.net/hidden/70daab48/ so this instead of your open-coded outermost loop doesn't work?
15:23 mripard: it might, let me try
15:24 mripard: should it be after the -z remote test?
15:24 sima: https://paste.debian.net/hidden/d7a3e08c/ less hilarious variable abuse
15:28 mripard: yeah, that one almost works, there's a sed 's/$url/$old_url/' to do in the git remote invocation but it works fine otherwise
15:28 mripard: I pushed it to the MR
15:28 sima: oops
15:29 sima: maybe a function for that little trickery since we do it twice
15:29 DemiMarie: Is the KMD involved in setting up video core queues?
15:30 DemiMarie: Can I block the video cores from being used at the kernel driver or native contexts level?
15:30 mripard: sima: url_to_remote_for_real ? :)
15:31 mripard: or more seriously url_to_remote_from_git ?
15:32 DemiMarie: The context is that the firmware seems to be involved in header parsing and that is a potential security risk.
15:32 DemiMarie: robclark: do you have any thoughts?
15:35 demarchi: sima: I was trying to test it... anyway, added a commit on top to make dry-run for pull requests a little bit more useful
15:35 robclark: yeah, I think it should not be too hard to block specific queues at the nctx level
15:35 demarchi: sima: ok with that commit on top?
15:35 robclark: DemiMarie: ^^^
15:36 DemiMarie: robclark: that would be awesome, thanks!
15:37 DemiMarie: ChromeOS might use that too, since they do video virtualization a different way.
15:39 robclark: right
15:40 mripard: sima: sent with the function
15:42 dj-death: gfxstrand: can I bother you with a quick ack on !27822 ?
15:43 sima: demarchi, I think your dry-run breaks the "oops I screwed up the tagging, let's try again" logic of function tag_name? where we add a suffix
15:43 sima: so you can have multiple tags for a given sha1, and we need to pick the tag name for the current run
15:43 sima: or am I confused?
15:44 demarchi: isn't that when we decide the tag name, done earlier? tag_branch receives the tag name as arg
15:44 sima: maybe just update the comment that this probably wouldn't work for a non-dry run due to re-tagging
15:44 sima: demarchi, yeah I think only your comment that this would also work for non-dry runs is confusing
15:45 demarchi: * [new tag] b2121f2bd2232cd0556b2182078d159d81497885 -> drm-xe-next-2024-02-27
15:46 demarchi: if I already had such a local tag, it should also show as:
15:46 demarchi: * [new tag] b2121f2bd2232cd0556b2182078d159d81497885 -> drm-xe-next-2024-02-27-1
15:46 sima: yeah but which one does it pick if it's multiple local tags
15:46 demarchi: unless I'm missing something
15:47 sima: since we need to push that specific tag with the tag message and signature and all that for non-dry run
15:48 demarchi: ok... just remove the comment or reword to something else?
15:48 sima: just remove
15:48 sima: put that in a gitlab comment too
15:48 sima: and I thought git rev-parse is the one that does symbolic lookup, not the one that spits out a sha1
15:49 demarchi: after doing my first pull request, what I don't really like in that function is the strict use of branch@{upstream}... would it be acceptable to allow it to be overriden?
15:50 demarchi: I don't feel like creating a pull request containing a commit pushed 1min ago by someone else and would rather create the pull request with something that already soaked some testing after being merged
15:51 sima: demarchi, I think for that it would be better to have a pull-request-for-tag function
15:51 sima: so just bottom part
15:51 sima: since the "make a tag part" is already split out into dim tag-branch
15:51 sima: then you can tag something, let it soak for a day, then make the pr
15:52 sima: that would also be useful for when the mail setup is wrong and the tail of the dim pull-request function dies
15:52 sima: or maybe make dim pull-request smarter so you can pass it a tag instead of a branch
15:52 sima: and then it skips the tag creation
15:53 demarchi: yeah... I will take a look at it later this week before my next pull
15:56 demarchi: sima: about rev-parse.... it will spit the sha1
15:57 demarchi: there's a --symbolic and --symbolic-full-name to change the behavior, but by default it's sha1
15:59 sima: ah yes
16:34 DemiMarie: robclark: is this something that a malicious guest would not be able to bypass, unlike kernel-mode validation of queue contents?
16:36 robclark: yeah, it could just not pass it on to the kernel.. OTOH there might be valid cases to restrict in kernel (ie. to tie it in to cgroups or something like that)
16:40 DemiMarie: robclark: how concerned are you about someone using a firmware vulnerability for RCE over the air?
16:41 mripard: if there's some drm-misc committers that haven't changed their drm URL yet, could you give a try to: https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/39 ?
16:41 mripard: sima: I guess I should commit the nightly.conf file with drm_old_urls too?
16:43 bl4ckb0ne: is it possible for glFramebufferTexture2D to give GL_INVALID_VALUE about a texture format?
16:44 bl4ckb0ne: it happens with nvidia proprietary driver, but i cant find it generated anywhere in mesa nor in the spec
16:44 DemiMarie: bl4ckb0ne: Nvidia proprietary driver bug?
16:44 sima: mripard, well for now only the one for drm.git?
16:44 bl4ckb0ne: not sure yet
16:45 sima: or do you want to push them all early, so that people are prepared?
16:45 robclark: DemiMarie: I'm not too much involved in video side of things but AFAIU there is a separate sandbox process in chrome for doing video decode.. it defn would make sense to want to limit what processes can do video dec
16:45 sima: that way they'd have the upgrade proof nightly.conf already ...
16:45 sima: mripard, but maybe wait for a tested-by from demarchi or someone, before we make things worse by accident
16:45 DemiMarie: robclark: I agree. I’d also want to make sure that the VCN/HuC firmware isn’t trusted by the kernel or the rest of the GPU.
16:51 mripard: sima: I meant only the drm one indeed :)
16:52 mripard: demarchi, jani: did you update your drm repos in dim already?
16:53 demarchi: mripard: I did, but I can undo it and test
16:53 demarchi: give me a few minutes... just need to finish pushing something
17:13 mripard: demarchi: I have to go, feel free to merge it (and the nightly.conf bits here: https://paste.debian.net/hidden/8b0b31ba/) if it works for you
17:13 demarchi: mripard: one hiccup is that it's not update drm-rerere before attempting
17:13 demarchi: I had to manually fetch it
17:13 demarchi: oops, manually reset drm-rerere to what was fetched
17:14 demarchi: after that I get:
17:14 demarchi: [ldmartin@ldmartin-desk2 src]$ ../maintainer-tools/dim ub
17:14 demarchi: dim: No git remote for any of the URLs git@gitlab.freedesktop.org:drm/kernel.git https://gitlab.freedesktop.org/drm/kernel.git ssh://git@gitlab.freedesktop.org/drm/kernel.git found in /home/ldmartin/p/linux-dim/src
17:14 demarchi: Enter a name to auto-add this remote, leave blank to abort: drm
17:14 demarchi: error: remote drm already exists.
17:15 demarchi: then it continues and no url changes
17:16 mripard: but if you were to have a dim tree that hasn't been updated today, you would have an older rerere tree too
17:16 mripard: at 044940a15536
17:17 mripard: (anyway, I really have to go now, I'll look later)
17:25 demarchi: mripard: oh... I forgot to apply the changes to drm-rerere
17:30 demarchi: ok, retrying with the additional rerere changes and it worked
17:31 demarchi: ( good thing that today I found a neat script tmpoverlay.sh to overlay a tmpfs on top of a dir, so I can rewind to what I had before and try multiple times :) )
18:10 mripard: demarchi: \o/
18:13 mripard: thanks for testing
18:13 mripard: so, should we merge this?
18:17 abhinav__: mripard Hi, as requested y'day, for msm for one of the features for 6.9, we had some changes merged on drm-misc on 02-24 , after the last cutoff tag on 02-22, by any chance is another tag creation possible for 6.9
18:20 mripard: abhinav__: we normally don't: Linus wants everything in -next by -rc6. What is that feature about?
18:22 bl4ckb0ne: seems like my issue was a leftover data from glGetError, so the issue was sitting between the chair and the keyboard
18:24 abhinav__: mripard the feature adds support for YUV over DP for MSM chipsets. https://patchwork.freedesktop.org/series/129180/ ... from drm-misc, we need 3 small changes https://cgit.freedesktop.org/drm/drm-misc/commit/?id=47f419e07111acecab3b529d4ae31a28985f5b61, https://cgit.freedesktop.org/drm/drm-misc/commit/?id=b55b88d86fec1d3edf60489b25ed998a3f0848cb
18:24 abhinav__: and https://cgit.freedesktop.org/drm/drm-misc/commit/?id=0d024974014f39207c5f52e770059b5bac35ea6d
18:25 abhinav__: and one more fix https://cgit.freedesktop.org/drm/drm-misc/commit/?id=de8de2c8acb931ce6197a04376a7078ccf50e821
18:26 demarchi: mripard: ack on merging
18:26 abhinav__: changes should be less intrusive for non-msm
18:36 mripard: demarchi: done, thanks
18:40 mripard: abhinav__: I'm sorry, but it's a general rule we've had for everyone :/
18:41 abhinav__: mripard okay ..... understood ... robclark lumag any other alternatives ?
18:43 airlied: is there much other stuff in misc?
18:43 airlied: misc-next
18:51 mripard: there's 18 commits that don't look super harmful except maybe the built-in EDID removal
19:06 robclark: abhinav__, airlied: I could send a 2nd msm-next pull req if the drm-misc dependency is picked up.. idk if that helps
21:15 Lynne: "We're a real Vulkan driver now" <- not until descriptor buffers :)
21:16 dj-death: don't say that
21:17 dj-death: otherwise gfxstrand will block my runtime patch until she gets it working on nvk...
21:18 Lynne: surely that patch is mature enough to drink now
21:18 dj-death: just got a facelift
21:19 dj-death: might get ID-ed
22:05 DemiMarie: robclark: would it be possible to promote virtio-GPU native contexts to a generic part of Mesa supported by all drivers?
22:07 DemiMarie: robclark: also I noticed that Cloudflare is using Dawn in a multi-tenant context (Workers), so hopefully they will put effort into DoS prevention. For them, crashing the GPU _is_ a security vulnerability!
22:08 robclark: DemiMarie: I don't think you could (or even should) make it fully transparent... one early idea I investigated was so called "rendernode forwarding" (basically a proxy rendernode device in the guest).. but the latency was too high, compared to linux syscalls which are pretty fast.. my conclusion is that it is better to lean into async, ie. come up with ways to avoid synchronous calls to the host.. whether that be userspace
22:08 robclark: fences, userspace allocated gpu buffer addresses, etc
22:09 gfxstrand: This is only slightly terrifying: https://stackoverflow.com/questions/308364/c-bitfield-packing-with-bools
22:09 jenatali: Our WDDM forwarding mixes a bunch of synchronous calls with async, but yes we're also heading in the direction of direct usermode -> GPU interactions to avoid the remoting overhead
22:10 mattst88: gfxstrand: heh, yep. even a 1-bit int has to be 4-byte aligned /o\
22:10 DemiMarie: robclark: was a synchronous hypercall API considered? “Synchronous” meaning “force a VMExit and immediately switch to the userspace VMM”.
22:10 mattst88: pretty silly
22:11 DemiMarie: jenatali: what about allocation? Moving allocation into firmware seems like a very bad idea.
22:11 jenatali: No that's still a synchronous call
22:11 robclark: vmexit would be faster, but plumbing that thru kvm (at least on arm64) looked unfun
22:12 DemiMarie: robclark: Unfun?
22:12 jenatali: Allocation is low-frequency though
22:12 vsyrjala: i wonder if modern compilers still emit terrible code for c bitfields
22:12 robclark: for us, allocation is async but if you need to mmap (or dmabuf export or some other cases) that is a barrier
22:12 jenatali: At least... it should be
22:12 robclark: DemiMarie: I didn't see a way to implement it that would be acceptable upstream
22:12 DemiMarie: robclark: why?
22:12 DemiMarie: Why would upstream say no.
22:13 DemiMarie: Low latency hypercalls are needed for other cases too.
22:13 robclark: but not things that exit back to vmm, iirc
22:14 robclark: anyways, vmexit is still expensive.. and if you can keep things async then you don't need vmexit
22:14 gfxstrand: mattst88: Oh, it's not that that's bugging me. It's that MSVC actually does re-start the alignment when you switch types so if you have `unsigned i : 4; bool i : 1`, that's 8 bytes.
22:14 DemiMarie: robclark: they are likely needed for some future stuff in Wine I think.
22:15 gfxstrand: mattst88: GCC/clang don't. so that's 4 bytes.
22:15 jenatali: gfxstrand: Yeah MSVC bitfield packing is very strict. It only packs actual identical types
22:16 DemiMarie: jenatali: I would be tempted to use a static assertion that the layout is right and tell Windows users to use clang.
22:16 jenatali: Static assertions are great. But for this particular issue, accommodating MSVC isn't really difficult...
22:18 DemiMarie: robclark: how common is allocation failure?
22:18 robclark: rare.. and generally unrecoverable anyways
22:18 gfxstrand: Yeah, for this fix, I just made my booleans unsigned. I don't really like that because it means you loose automatic `x != 0` semantics on assignment but it's safe enough in this case.
22:19 DemiMarie: robclark: even for vram?
22:19 mattst88: gfxstrand: oh, lol wtf. that's bizarre
22:19 DemiMarie: robclark: my PoV is that one should try to recover, but only if one will be testing that code, and that is often not the case.
22:20 robclark: there are still cases (for gl) where driver will be reallocating behind the scenes where there isn't really a way to return an error
22:20 DemiMarie: Ah, what about Vulkan?
22:21 DemiMarie: Also, I thought there were very latency-critical paths in compute somewhere.
22:21 robclark: it might be more reasonable to make allocation synchronous for vk, assuming a well behaved vk app (but I've seen enough app/engines do vk badly, so idk)
22:22 robclark: compute you can have ping/pong between gpu/cpu if app doesn't try to pipeline things... but that is pretty much going to suck regardless
22:22 DemiMarie: Generally context switches seem to be getting more and more expensive compared to straight line throughput.
22:22 robclark: eventually people doing wizz-bang things with compute will learn how to use a gpu
22:24 DemiMarie: I think there might be cases where parts of an algorithm do well on a CPU and parts do well on a GPU and these parts are tightly interleaved. I haven’t seen any examples in practice, though.
22:25 DemiMarie: Anyway, high performance APIs like io_uring are async nowadays.
22:26 DemiMarie: And IIUC virtio-user often busy spins for performance, though it is not required to.
22:27 robclark: yeah.. a uring type uabi for drm would be interesting for other reasons.. but a virtqueue is basically like a uring
22:27 robclark: yeah, venus does busy loops a fair bit.. for nctx I tried to avoid needing to do busy loops
23:31 cambrian_invader: are there any userspace helpers for /dev/drm_dp_aux or has everyone been getting by with dd?
23:35 vsyrjala: i think there's something in igt. no idea what it does. i just use dd+xxd/hexdump
23:36 vsyrjala: quick glance at the igt tool suggest it doesn't work with offline dpcd dumps. so not useful for me in its current form
23:37 vsyrjala: it also doesn't decode anything, so not really any better than hexdump
23:37 vsyrjala: a tool that would fully decode the dpcd would be nice
23:38 cambrian_invader: yeah, that's the kind of thing I was looking for
23:38 cambrian_invader: I guess I will just memorize everything :)
23:38 vsyrjala: also some monitors are borked an return errors for certain dpcd ranges, which is illegal according to the spec
23:38 vsyrjala: so may have to rescue-dd/etc.
23:39 cambrian_invader: my monitor/displayport does not work at all (or rather more than 10% of the time), so I am already sorted in that department
23:39 vsyrjala: nice
23:41 vsyrjala: somehow i still haven't managed to memorize much of dpcd. i guess my brain has too many i915 register decoders so no more room for anything else