00:29robclark: imirkin, ajax: so my *guestimate* is that what became a2xx forked off the family tree a bit earlier than r600.. so a2xx is more closely related to some radeon thing that never saw the light of day (or xbox360).. but yeah, diverged quite a bit since then, starting with a3xx..
00:30robclark: iirc there is an xbox360 emulator that borrowed heavily from what we figured out for a2xx
00:37airlied: robclark: https://en.wikipedia.org/wiki/Imageon was the amd bits
00:38ajax: everything steals from everything else. sort of like how artx's thing suddenly became r300 (if i'm remembering this right)
00:38HdkR: Theft via purchasing, the best kind of theft :P
00:39robclark: yeah, imageon is the thing that was renamed adreno a2xx.. a few imx/freescale boards are using freedreno
00:39imirkin: no "imageoff" though?
00:40robclark: but yeah, there is defn some kinda family tree where r600 and the mobile line both inherited from something xbox360'ish and started diverging in different directions
00:40airlied: everyone learned that vliw was crap in their own way :-P
00:41imirkin: amd held on to it for quite a while
00:41imirkin: and powervr is still clinging, i think?
00:42airlied: oh I'm sure it's a mistake that will be made again :-P
00:45imirkin: so tempting
00:48HdkR: VLIW: "It was not by my hand that I'm once again given flesh. I was called here by humans who wish to pay me tribute"
00:49HdkR: A new VLIW CPU announced just yesterday
00:49airlied: russia trying to copy itanium still :-P
00:49HdkR: I'm sure they'll also copy the success
01:00ajax: itanium wasn't bad if you developed on x86 first and then tuned all your float math
01:01ajax: but then they came around and bolted that fpu onto the x86 like... well, not sane people, but at least reasonable people.
01:34agd5f: jekstrand, can I add someone to the uring group?
02:59robclark: agd5f, jekstrand, can you add me to the uring group? (and maybe krh if he isn't already there..)
03:00krh: There's a uring group?
03:00robclark: one uring to rule them all?
03:01airlied: last person to join has to implement it
03:02robclark: ok, just make sure to add me before krh :-P
03:03krh: If it's a uring group I can just add the first member again
03:45agd5f: robclark, I'm not sure if I can actually add anyone or if jekstrand has to do it
03:47agd5f: it would seem I can't
03:47robclark: ok.. well I can wait for jekstrand if needed.. but krh and I have been discussing a few things for a kabi v2 which I think fit in with the concept..
04:34jekstrand: agd5f, robclark, krh: I added you all at the same time. Fight amongst yourselves as to who gets to write the code. :-P
04:45robclark: hmm, that was a race condition I didn't anticipate.. well I cloned the repo if that counts for anything :-P
04:56airlied: you are in a maze of twisty passages involving debian, llvm, virgl and a grue
04:57airlied: this is going to involve me building a debug llvm in a VM isn't it, and realising I made the VM too small
08:25danvet: Lyude, [PATCH] drm/connector: notify userspace on hotplug after register complete <- maybe interesting
08:25danvet: the asymmetry in how we handle the hotplug event between register/unregister for hotplugged connector is a bit funny
08:25danvet: and apparently was buggy too
08:47daniels: anholt_: g = gitlab.Gitlab('https://gitlab.freedesktop.org', api_version=4, private_token='xxx'); g.auth(); p = g.projects.get('mesa/mesa'); for f in p.forks.get(all=True): if not f.jobs_enabled: f.jobs_enabled = True; f.save()
08:48daniels: ajax: how's github looking btw?
08:48daniels: nchery, anholt_: btw you fell into a corner case - pipelines are only created when you push commits; turning on CI/CD won't retroactively create pipelines for old commits pushed, so once you flip it on you have to push again
08:50daniels: i see jamesxio/piglit ajax/piglit danvet/piglit rantogno/piglit mvicomoya/piglit tpohjola/piglit kusma/piglit sagarghuge/piglit gerddie/piglit jekstrand/piglit
08:50daniels: and gfx-ci/tracie/mesa Mesa_CI/repos/mesa FireBurn/mesa
08:55kusma: daniels: early clones of piglit after we moved to gitlab? Probably from before pipelines were in use...
08:58daniels: kusma: exactement
09:08MrCooper: anholt_: thank you for getting my MR over the line! I dug us into that little hole in the first place :}
11:07emersion: danvet: i'm unfamiliar with email@example.com, should i just send a v2 with the Cc line added?
11:08danvet: emersion, just add it when you merge
11:08danvet: git commit --amend
11:08danvet: stable people follow upstream commits for this
11:13emersion: ah, ok, cool
11:13emersion: this goes to drm-misc-next right?
11:25daniels: shadeslayer: about iris_resource - this is for external_objects support, right? you might do better asking in #intel-3d, but you're probably looking for a mix of intel_screen.c, brw_bufmgr.c, and intel_buffer_objects.c
11:32danvet: emersion, https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#where-do-i-apply-my-patch
11:32danvet: answer should be drm-misc-next-fixes
11:35danvet: emersion, oops btw hold the press, I think my rb is wrong and vsyrjala right
11:53emersion: yup indeed
12:36shadeslayer: daniels: indeed, but I figured it out ;)
12:37shadeslayer: daniels: though now I need to figure out how to test this :D
12:42daniels: shadeslayer: heh, sorry for the slowness
12:54shadeslayer: daniels: nah, probably better that I spent some more time looking at things ;)
13:55MrCooper: danvet mlankhorst_: so, the IGT kms_cursor_legacy *atomic-transitions* tests assert that an overlay plane can be enabled while the primary plane is disabled... is that intentional?
13:55danvet: MrCooper, I have no idea, I didn't review or write any of these
14:01mlankhorst_: MrCooper: I think it was just going through primary plane visibility changes
14:06MrCooper: mlankhorst_: transition_nonblocking(..., FALSE) calls igt_plane_set_fb(primary, NULL), then igt_display_commit_atomic asserts that the commit ioctl returns 0
14:07MrCooper: and enables an overlay plane in the same commit
14:11MrCooper: mlankhorst_: or was the fallback intended to be igt_plane_set_fb(primary, prim_fb) instead?
14:22eric_engestrom: so, turns out I signed mesa 20.1.0 with an old, expired key I still had around
14:23eric_engestrom: would it be ok for me to re-sign it and replace the signature, or is that not meant to be touched?
14:23imirkin: signature should match what's in the announcement email
14:23imirkin: i'd leave it alone
14:23eric_engestrom: I don't like either options :/
14:24eric_engestrom: I could send a follow-up email rectifying this?
14:24imirkin: i'd recommend waiting a bit and getting more opinions
14:24imirkin: maybe send an email
14:24imirkin: release protocol is not my forté
14:25eric_engestrom: the hash of the tarball won't change as I'm not touching it, so that should provide enough assurance that it's not someone else trying to subversively put something in the code
14:25eric_engestrom: but yeah, definitely waiting for more opinions
14:25imirkin: hmmm ... interesting point.
14:26imirkin: so basically this is the equivalent of me coming in and sending another email signing those (same) hashes
14:27pq: sending more emails with more signatures for the same hashes can't hurt
14:27imirkin: what was the bit about replacing something?
14:27eric_engestrom: except the pgp email won't change
14:27eric_engestrom: the .sig hosted
14:27eric_engestrom: that's signed with the bad key
14:27imirkin: right ... ok.
14:28eric_engestrom: so if I re-sign the tarball with the good key, I can replace the .sig without touching the tarball
14:29eric_engestrom: actually, the email doesn't say anything about the key used, it just has a link to the signature file
14:29eric_engestrom: that link won't change
14:29kisak: I think it should be fine with a follow up email, nobody's going to stay on the first patch release of a series for long, so I think it'll be fine to leave the old signature around as errata
14:29eric_engestrom: yeah ok, I think we're good here
14:30eric_engestrom: link to the email if anyone want to double-check: https://lists.freedesktop.org/archives/mesa-dev/2020-May/224493.html
14:31eric_engestrom: ah, the git tag is also signed with the wrong key
14:31eric_engestrom: (why did I keep that old key lying around)
14:31eric_engestrom: (gpg needs an "archive" thing, where you can keep something around for safe-keeping but not accidentally use it)
14:44daniels:points to last week's discussion :P
14:45daniels: but yeah, it sounds like you did the right thing
14:45eric_engestrom: you're not wrong
14:45eric_engestrom: "did" ?
14:45eric_engestrom: I haven't done anything yet
14:45eric_engestrom: but I feel relatively confident about replacing the .sig, I'll do that and send an email
14:45daniels: oh, I thought you already re-sent the mail saying that the .sigs were changed and with a new key etc
14:45daniels: which sounds like the right thing indeed
14:57eric_engestrom: ok, sig replaced, and email sent :)
15:31ajax: daniels: got sidetracked pruning the repo list and figuring out a way to self-rate-limit
15:32ajax: daniels: i restarted the sync loop, should be done in a couple of hours assuming github cooperates
15:35ajax: (900ish repos in my source list, 10 second stall between each...)
15:43Lyude: danvet: I'll take a look when I get a chance
15:43Lyude: which should hopefully be soon as crunch time is coming to an end
16:05alyssa: "I couldn't merge this branch: Merge request was rejected by GitLab: 'Branch cannot be merged'"
16:05alyssa: Is marge ok?
16:07MrCooper: that's a GitLab issue (since 13.0?), not a Marge one
16:08MrCooper: or I guess it could be new behaviour in GitLab 13.0 which our Marge can't handle yet
16:09alyssa: Hmm, alright.
16:09alyssa: I'm only seeing it on some of my MRs, not others. Usually only the ones I need merged ;)
16:09MrCooper: it's intermittent
16:10MrCooper: seems to happen on around 50%-ish of attempts to merge an MR
16:10alyssa: Hm, alright
16:15MrCooper: hmm, interestingly I can't seem to find any instance of this from piglit in my e-mail
16:15MrCooper: so maybe it's specific to Mesa somehow
16:16daniels: alyssa, MrCooper: can you please give me some MR numbers?
16:16daniels: (even more preferably, in a new freedesktop/freedesktop issue ...)
16:18MrCooper: e.g. !5285, !5268, !5149
16:28MrCooper: mlankhorst_: changing transition_nonblocking to set prim_fb for the primary plane instead of the overlay one in the fallback case seems to do the trick; was that what you intended in a36e627b767c "kms_cursor_legacy: fallback to xrgb if argb for sprite plane is unavailable"?
17:13alyssa: daniels: !5289, !5290 are a subset of my end
17:17mslusarz: my mesa MR failed on meson-mingw32-x86_64 job with "FileNotFoundError: [Errno 2] No such file or directory: '49148.bat'"
17:18jenatali: jekstrand, karolherbst: Have either of you looked at OpenCL's async copies and event_t? Vtn doesn't support these yet, and I'm starting to think about how it should look in nir. We're not really planning to respect the async aspect of it and are just going to turn it into a dumb memcpy, so the event is a dummy and will get DCE'd for us
17:18mslusarz: am I supposed to just restart it (it's a known intermittent issue) or is it something that needs to be investigated?
17:29karolherbst: jenatali: plaese just assume I am not in any way able to clearly think about technical problems right now.. something came up and I have to deal with something I hoped I never have to deal with so..... well.. maybe next week :/ sorry
17:29jenatali: Sorry to hear that, best of luck
17:47anholt_: mslusarz: I haven't noticed that as an intermittent failure, fwiw. (and I see a lot of our intermittents, since marge tells me)
17:47anholt_: have you tried clicking retry on just that job?
17:48mslusarz: not yet, I wanted to report it first and not destroy the evidence ;)
17:50mslusarz: this is it: https://gitlab.freedesktop.org/mslusarz/mesa/-/jobs/2938333
17:51anholt_: mslusarz: when you restart a job, the old job is still reachable from your pipeline's overview
17:51mslusarz: ok, good to know
17:52anholt_: the wine version just got changed, perhaps that's related?
17:59mslusarz: it succeeded after restart
18:01jekstrand: jenatali: I've not looked into it
18:02jenatali: Mmkay, I'll try something and hopefully you don't hate it too much
18:05jekstrand: jenatali: I doubt I'll hate it. :-P
18:08jenatali: It'd be cleaner if it was on top of !5278, since it'll probably look pretty similar to images/samplers as an opaque type
18:27jenatali: Ugh, the async copy instructions are core SPIR-V opcodes rather than OpenCL opcodes so hoisting them to libclc is going to be a pain
18:30Kayden: Can anyone with a radeon confirm that 'manywin 2' from mesa-demos works there?
18:31Kayden: (using radeonsi with the amdgpu kernel that is, not r600)
18:33ajax: Kayden: i can't confirm in the sense that i can't see that display at the moment, since it's in an office i'm not allowed to enter
18:33Kayden: yeah, same
18:33ajax: but it runs and doesn't crash, and i remember it looking right last time i was in that office
18:33Kayden: doesn't crash is good enough for me, thanks!
18:34ajax: that demo is kind of pathological though
18:34ajax: like, i think it's an outright bug that it ever worked
18:35Kayden: ajax: dj-death and I are trying to untangle a bit of a mess...we tried to fix manywin, because IIRC you had some customer app that had similar sorts of issues
18:35Kayden: and now that's broken dmabufs in firefox 78 on wayland with a bunch of crazy options
18:37ajax: don't worry about keeping that fix in on my account, though
18:38ajax: like, it should get fixed, manywin should work. but it's such a rare and shitty corner case that regressing firefox is way worse.
18:39ajax: worse enough that i can't ship mesa like that, at least not in the core change stream
18:39ajax: so we
18:39ajax: 're already needing to figure out how to get them something custom until it gets fixed properly upstream, because firefox (afaik) isn't a concern for them
18:40robclark: hmm, does essl say anything about precision of yuv->rgb conversion (presumably not?).. ie. for mediump sampler, I assume it's ok to do the conversion entirely in mediump?
18:41ajax: Kayden: i guess what i'm saying is feel free to revert it until you have a fix you like
18:41Kayden: that makes sense, thanks
18:42anholt_: robclark: I'm confident you won't find any language about that, and medium should be plenty.
18:42anholt_: (until you get to the 10-bit formats, I guess)
18:42anholt_: but if you mediump sampled those, that's on you.
18:42danvet: anholt_, for hdr video maybe not
18:42danvet: yeah was about to add that
18:43robclark: ok, cool.. looks like nir_lower_tex needs a bit of work to grok bitsize..
18:43robclark: but yeah, shader asks for mediump, shader gets mediump.. seems sane to me
18:44krh: yeah, the EGLImage yuv conversion is notoriously underspec'ed
19:43Kayden: ajax: now that we've spent several hours digging through everything, I think dj-death's series is fine, and we have some future cleanups to do
19:43Kayden: so that should fix firefox and keep manywin working
19:44Kayden: pretty sure we also found a small anthill of other bugs throughout mesa
21:53mlankhorst_: MrCooper: no, just fallback for opaque overlay :)