00:08 accelshark: Hey, is this the discussion group for OpenCL hang support on Mesa? I have Linux 5.10.12 and a Vega 56 and it seems to be locking up in a Mesa Clover clEnqueueReadBuffer of sorts on OpenCL. Help would be appreciated.
00:08 accelshark: I can debug it, just curious what to do
00:08 accelshark: The program's locking up that is, my OpenCL test program.
00:09 imirkin: accelshark: there's been a bunch of work on clover lately
00:09 imirkin: what version of mesa are you using?
00:09 accelshark: Thanks for the work on it :) let me see what version of Mesa I am using
00:09 imirkin: should be apparent in 'clinfo'
00:10 accelshark: Mesa 20.3.3
00:10 imirkin: you could give mesa 21.0-rc3 a shot
00:11 imirkin: not sure if that issue in particular was addressed
00:13 raster: wow...
00:13 raster: i regularly get large frame gaps
00:13 raster: like i should get like 0.01667 or so ...
00:14 raster: but sometimes its 0.03865, 0.03861, 0.02208, 0.02207, 0.03864, 0.02224 etc. ....
00:16 raster: thats when i only have 1 frame gap
00:17 raster: so something truly nasty ishappening to vblank timestamps which then sometimes go negative in delta_t
00:22 raster: yeah. the next frame after going backwards it doesnt have an extra long gap so it jumps back but then maybe over time slowly shuffles forward
00:26 vsyrjala: psr or drrs could be things that affect vblank stuff. i915.enable_psr=0 would make sure the first one is not an issue
00:26 vsyrjala: for drrs we don't seem to have a modparam for whatever reason
00:27 vsyrjala: cat /sys/kernel/debug/dri/0/i915_drrs_status
00:27 vsyrjala: should at least tell us if it's on
00:28 raster: vsyrjala: ok - enabled drm debug
00:28 raster: lets see
00:30 raster: waiting for it to appear again
00:30 raster: but right now it seems like a hisenbug...
00:30 raster: at least now debug is on
00:44 raster: vsyrjala: yeah. enable drm debug and .. bug stops happening... :|
00:46 raster: vsyrjala: DRRS os a No fyi
00:46 raster: DRRS Supported : No
00:54 accelshark: okay, got Mesa 21 installed, let's debug
00:58 raster: *sigh*. yup. hiesenbug. debug on... it goes away. debug off... it comes back.
00:58 raster: well too late today.
00:59 raster: :|
00:59 anholt: -4569 test failures in CI makes for a good day.
01:22 accelshark: Still hanging the program on enqueue read
01:38 accelshark: ok, it is something wrong with enqueueing a copy, just added tracers and not relying on PyOpenCL's tracing. let me see if I can just wiggle around this "Copy" thing :)
04:52 airlied: j4ni: I resolved an intel drm-tip today, but not sure I got it right, maybe you can check to make sur
06:38 hifi: I submitted a patch last night to dri-devel but it doesn't show up in the archives and I didn't get a bounce, is that expected?
06:48 HdkR: hifi: It probably fell in to moderation queue
07:03 hifi: HdkR: ah, okay, thanks
07:05 HdkR: Good to mentino it here though, since I believe it's less agressively looked at these days
07:05 HdkR: mention*
08:54 MrCooper: HdkR: still processing it every workday; more volunteers always welcome
08:55 HdkR: Ah cool. I'll let other people do that, I don't like ML development
08:55 HdkR: :)
08:56 hifi: haven't used mailing lists for so long I was really skeptical about using gmail, wasn't too wrong apparently about it because the patch ended up as binary and gmail forced a html version of the text in as well
08:57 emersion: use git-send-email
08:57 emersion: https://git-send-email.io/
08:57 emersion: MrCooper: maybe i can help you, if you're interested
08:57 hifi: yeah, I don't use mailing lists that often to really get much benefit in getting this working perfectly, thanks for the tip, though
08:58 karolherbst: we should just use gitlab :p
08:58 hifi: that would've been much easier for a dummy like me :)
08:58 karolherbst: yeah
08:59 emersion: git-send-email isn't really more complicated than GitLab
08:59 emersion: it's just different
08:59 karolherbst: it is
08:59 hifi: I don't really mind mailing lists, they are kind of low barrier for entry but these days they put me off unless I really badly want something done
08:59 karolherbst: it totally is
08:59 karolherbst: gitlab you sign it with github, and push
08:59 karolherbst: with send-mail you have to figure out your silly smtp settings and make it not suck
09:00 hifi: that would've actually been somewhat painful to configure the smtp settings to send a single email
09:00 karolherbst: and "oh you made a mistake? Resend everything again!"
09:00 emersion: https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-29a0854bd759
09:00 emersion: ^ PR versus email
09:00 karolherbst: if you need a video, it's too complicated :p
09:00 karolherbst: no, PRs are easier...
09:00 emersion: well, someone else proved my point, so why bother
09:01 karolherbst: ehh...
09:01 karolherbst: I can say from experience, that PRs are simplier
09:01 hifi: it's not really worth debating over it, PRs on websites are easier for a modern developer while mailing lists when you are accustomed to them are straightforward
09:02 emersion: you need to (1) create an account (2) fork the project (3) setup remotes properly (4) open a PR
09:02 karolherbst: yeah, if you have the insights you can make that argument
09:02 karolherbst: emersion: (1) you don't have to (2) one click (3) one line (4) copy paste the URL from git push
09:02 karolherbst: just use your twitter/github account to login
09:02 emersion: with email, the git-send-email setup is one-off for *all* projects
09:02 karolherbst: mailing lists you have to subscribe anyway
09:03 emersion: and then you just need to run one command
09:03 karolherbst: or have to wait for moderation
09:03 karolherbst: emersion: if you set it up correctly, yes
09:03 karolherbst: but sending patches with send-mail is so much pain
09:03 karolherbst: the process alone is annoying
09:03 emersion: running a command is annoying? i don't know how you do kernel development then
09:04 karolherbst: it's more about getting everythign into shape and figure out what to do
09:04 karolherbst: we are not talking about experienced devs here
09:04 karolherbst: but about inexperienced ones as well
09:04 emersion: PRs are simpler for users because GitHub requires them, so users had to learn them
09:04 karolherbst: if you assume everytbody knows every commend and flag, sure
09:04 ccr: :D
09:04 karolherbst: but most don't
09:04 karolherbst: ehh.. if you say so
09:05 karolherbst: I prefer PR/MRs over emails even though I know both
09:05 hifi: emersion: your argument is valid, people had to learn them so in number _more_ people know how to work with PRs than with mailing lists :)
09:05 emersion: i was in that boat before
09:05 karolherbst: alone this "you have to subscribe otherwise your submission will only be seen in one month, because mods are lazy" is a huge turn of for new contributors
09:06 emersion: this can be improved
09:06 karolherbst: it still sucks
09:06 emersion: and again, PRs require an account anyways
09:06 hifi: technically your PR can be completely ignored on any platform so it depends on the maintainers in either case
09:06 karolherbst: just use your github account :p
09:06 emersion: so put everything on github?
09:06 karolherbst: ehh..?
09:06 karolherbst: no?!?
09:06 hifi: SSO through github is a valid use case for many if it's optional
09:06 karolherbst: you can use your github account to login into gitlab...
09:06 emersion: or you mean sign in with github on fdo?
09:07 karolherbst: yes
09:07 karolherbst: so it's one click for a lot of people being first time contributor
09:07 hifi: or google account or whatever
09:07 karolherbst: you can also use twitter
09:07 karolherbst: most people have one of the options
09:07 hifi: it's not too anti-floss to have options even when they are on proprietary platforms if people are already on them
09:08 karolherbst: yeah, that's fine
09:08 emersion: relying on centralization, great
09:08 hifi: no, options
09:08 karolherbst: you can also create an account if you dislike it
09:08 hifi: you can attach multiple accounts to gitlab to login with
09:08 emersion: nothing stops you from doing it for MLs, although i won't be the one to type the code
09:09 hifi: or use that local account
09:09 karolherbst: but this is about "making it easy to contribute"
09:09 karolherbst: and MRs make that easy for a bunch of people
09:09 karolherbst: and honestly, I don't know which counterargument is strong enough here
09:09 karolherbst: because I can't come up with any
09:09 hifi: I think I have done that on gitlab.com that I first logged in with google and then I converted it to a local account later when I started actively using it
09:10 karolherbst: hifi: well techncially you have a full account, you just login with something else anyway
09:10 hifi: technicalities :p
09:10 karolherbst: right
09:10 hifi: but sure, my experience with dri-devel is a good example
09:10 karolherbst: anyway, nobody was able to say what counter argument is stronger than "making it easy for new contributors" and without that it's mood to discuss this anyway as usually nothing comes out of it
09:11 karolherbst: just "but email...1.1!!11" yeah but emails uck
09:11 hifi: I was extremely motiated to send the patch and it wasn't easy to even find a good checklist how to do it
09:11 hifi: motivated*
09:11 karolherbst: yeah
09:11 karolherbst: it's a huge issue in a lot pf projects
09:11 karolherbst: if the code is on gitlab/github you know what to do
09:11 hifi: the only thing I found was a wiki page that said "send a patch as an attachment to dri-devel" and that still went somewhat wrong
09:12 karolherbst: no need to read some stupid "CONTRIBUTING" file or whatever
09:12 emersion: there are people trying to make ML easy for new contributors, karolherbst
09:12 jadahl: email vs merger requests debate feels a bit like systemd vs sysv. one works fine and has for ages, but when you try to add complicated features on top (e.g. CI, state tracking), things fall apart with the good old system
09:12 karolherbst: emersion: ehh... I want to see results first
09:12 emersion: see e.g. sr.ht (shameless plug)
09:12 karolherbst: jadahl: yeah, that as well
09:12 karolherbst: but this comes down to the "email suck" point
09:13 hifi: would having _both_ be hard to maintain, though?
09:13 hifi: you need less moderation on gitlab than on the mailing lists
09:13 emersion: jadahl: CI on mailing lists https://sourcehut.org/blog/2020-07-14-setting-up-ci-for-mailing-lists/
09:13 karolherbst: emersion: sorry.. but that doesn't improve the situation...
09:13 emersion: karolherbst: ???
09:14 hifi: though I'm still waiting for the patch to be shot down with a comment "you're an idiot" :)
09:14 karolherbst: yeah... I just openeed the site and my first thought was "ehhh.. close it immediately"
09:14 jadahl: emersion: I'm sure its possible to make CI on mailing lists work just as well as patchwork :P
09:14 karolherbst: jadahl: maybe
09:14 emersion: karolherbst: can you elaborate?
09:15 karolherbst: emersion: oh, that was just my initial reaction, just a "feeling" so to say
09:15 jadahl: karolherbst: that was not meant as a "it would probably work great" :P
09:15 karolherbst: I know
09:16 karolherbst: emersion: also, it requires me to create an account ;)
09:16 emersion: well, i don't know what to reply to that. maybe "gitlab's so slow i have already finished writing the next MR when the page for the rpevious one has finished loaded"?
09:16 karolherbst: yeah.. gitlab is slow, that's true
09:16 jadahl: hehe
09:16 emersion: karolherbst: no it doesn't. you can post to MLs without an account, and you can create tickets without an account
09:16 karolherbst: and I'd wish that complex software wouldn't need many CPU cycles, but mhhh
09:17 karolherbst: but I'd assume that gitlab could also be optimized just that nobody really cared as much so far
09:17 emersion: so, you can do most things a newcomer would do without an account
09:17 MrCooper: anyone else bothered by GitLab accepting credentials from GitHub and many other services, while GitHub seems to accept credentials from nothing else? Talk about quid pro quo
09:17 karolherbst: emersion: then you are stuck in moderation
09:17 karolherbst: and you need admins approving emails
09:17 emersion: karolherbst: we haven't had issues with that so far, and DKIM helps
09:18 karolherbst: MrCooper: I think it was different in the past though, but yeah
09:18 karolherbst: emersion: I didn't mean because it's recognized as spam or whatever
09:19 karolherbst: if you are not subscribed you have to get approved
09:19 ccr: MrCooper, somewhat. but mostly because github becoming the sole single-sign-on login for everywhere feels .. dangerous. but then again, my pet peeve has been to have kazillion accounts on different bugtrackers and whatnots, which nowadays mostly accept github login.
09:19 karolherbst: or at least some MLs are configured this way
09:19 MrCooper: to be clear, it's the "GitHub accepts nothing else" part that bothers me :)
09:19 karolherbst: ccr: better than facebook :p
09:19 emersion: karolherbst: also, fwiw, sr.ht lets you contribute to the linux kernel via a GitHub-like UI, sending emails under the hood
09:19 hifi: they are the market leader and they are a business so
09:19 ccr: karolherbst, that much is true .. for now, at least. :D
09:19 jadahl: speaking of spam, the majority of emails in my gmail spam folder are valid LKMS patches
09:19 emersion: jadahl: yeah, because LKML breaks DKIM
09:20 karolherbst: jadahl: for me as well
09:20 pq: emersion, how did you solve the problem "which base commit does this email patch apply to?"?
09:20 emersion: karolherbst: you don't need approval on sr.ht.
09:20 MrCooper:holding out creating a GitHub account as long as possible
09:20 Sumera[m]: What's the best way to build igt-gpu-tools docs? `ninja -C build igt-gpu-tools-docs` is giving me an unknown target error :/
09:20 karolherbst: MrCooper: just use twitter :p
09:20 emersion: pq: not solved yet, sadly
09:20 karolherbst: ehh wait
09:21 ccr:remembers the time when OAuth2 was becoming a thing and you could set up your own provider .. then everybody forgot about such possibility :P
09:22 karolherbst: emersion: but you have to login into sr.ht and you have to put in your smtp settings or how would that all work out? Or is just sr.ht sending all the emails in other names?
09:22 karolherbst: ccr: yep
09:22 karolherbst: well
09:22 karolherbst: technically all the stuff is oauth2
09:22 ccr: yep
09:22 ccr: except nobody accepts random providers
09:22 karolherbst: oauth2 was just never.. you know, built in a way that you can support everything at once
09:22 karolherbst: ccr: because the URL scheme is not specified
09:23 ccr: sadly so
09:23 karolherbst: it's annoying
09:23 karolherbst: openidconnect is I think the proper thing which could solve this mess.. oh well
09:23 karolherbst: but that's also more about information sharing
09:24 emersion: karolherbst: sr.ht sends an email for you, no smtp settings required
09:25 emersion: karolherbst: it just uses its own email, but says that the patch belongs to you, and says that replies should go to your inbox
09:27 karolherbst: I am still not convinced that mail based contributing has any advantages over a git based system where CI and other integration stuff is way easier than wit email
09:27 karolherbst: but yeah, good that some people are trying to make it nicier for people stuck in the old days
09:28 karolherbst: but honestly, if a project requires me to send emails I immediately get less interested
09:28 karolherbst: kind of like saying "nah, we only want contribution from elite hardcore hackers from the 90s"
09:29 ccr: probably someone has done it already, but a commandline thing for doing the PR submission would be good
09:30 emersion: there's lab, but it doesn't work great
09:30 emersion: needs you to select a single one true gitlab instance iirc
09:31 emersion: and ofc to see/reply to comments you'll need to open the MR page
09:31 emersion: it just saves you from clicking the "open a MR" link, which isn't the most annoying part
09:32 emersion: also, it requires some local setup, just like git-send-email…
09:32 ccr: :|
09:32 jadahl: you can reply to gitlab emails and it'll end up in the issue/merge request
09:32 karolherbst: I honestly think that this CI integration stuff github and gitlab did are a huge benefit to the overall open source community and that's something we would have never gotten without them. Question is, does anybody want to go through the pain and do it based on email?
09:32 karolherbst: I super highly doubt it
09:33 jadahl: to actually review you need to open and select commits etc
09:33 karolherbst: especially because the overlap of "we don't need CI, that's for modern bs development" and "I use emails" is quite huge :p
09:33 emersion: we'll prove you wrong, karolherbst :P
09:34 karolherbst: emersion: ehh... we can talk about it in 10 years :p
09:34 emersion: we're not too far off, watch your back
09:34 karolherbst: but sure, you can try if you want to
09:34 karolherbst: okay, maybe I get surprised
09:34 ccr: :D
09:34 karolherbst: not that it ends up like this intel-ci thing on the kernel where you get the email a month later
09:35 karolherbst: and thought everything is alright until then
09:35 pq: emersion, will be interesting to see your solution to the "which base commit" problem, given patches can be based on other unrelated patch emails not merged yet. It's a prerequisite for anything like CI.
09:35 emersion: karolherbst: specifically CI, it looks like this: https://lists.sr.ht/~emersion/mrsh-dev/patches/11599
09:35 ccr:watches emersion shaking his fist at karolherbst "we'll prove you wrong .. one day"
09:36 karolherbst: emersion: okay, so you did 2% of the stuff
09:36 karolherbst: great
09:36 emersion: the main missing thing is a web form ala-github to comment patches
09:37 karolherbst: interesting would be to see how can do actual integration stuff
09:37 karolherbst: not just "testing"
09:38 emersion: what do you mean by "actual integration"?
09:38 karolherbst: this entire "deploy, verify, rollback" cycle
09:38 karolherbst: CI is not just about testing
09:38 emersion: yeah, you can do that
09:38 karolherbst: I mean verify on production servers
09:38 emersion: the CI uses itself to deploy new images on itself, karolherbst
09:38 karolherbst: ahh
09:40 emersion: in other words: the builds.sr.ht git repo has a CI manifest that starts a builds.sr.ht alpine/arch/ubuntu/debian/etc job to update the builds.sr.ht image for that OS
09:40 emersion: and ofc it also has a job to deploy the web app itself
09:41 karolherbst: yeah, okay, seems like it's better than I assumed it is
09:44 karolherbst: anyway, I am convinced that even in 50 years, we will have 5 kind of people prefering it in their faveourite way and every other solution sucks because of $reasons. oh well
09:44 karolherbst: and in 20 years gitlab will be the new "ewww, you are using gitlab over $fancy_new_thing? You really don't want new contributors, do you" :p
09:45 emersion: in 50 years, gitlab will be long gone too ;)
09:45 emersion: yeah
09:45 emersion: it scares me a little to rely so much on gitlab for discussions about patches
09:46 karolherbst: yeah...
09:46 emersion: there's just so much information that's not easily archivable in the gitlab DB
09:46 emersion: and that's pretty important
09:46 karolherbst: I was playing around with having a bot subscribing to a label and send it out to MLs
09:46 karolherbst: but there is one huge annoying issue with that: the unsubscribe buttong works without authentication
09:47 emersion: ahah! we actually have a bot opening gitlab merge requests from ML patches
09:47 karolherbst: imirkin would love it
09:47 karolherbst: but honestly? the comments should also be their own git repo :D
09:47 karolherbst: happy race fest, but whatever
09:48 karolherbst: I liked that the wiki on github is just a git itself
09:48 karolherbst: well, on gitlab as well
09:48 emersion: yeah, that's nice
09:49 emersion: lore.kernel.org exposes Git repos for ML archives, fwiw
09:49 emersion: also nmtp :o
09:49 emersion: nntp*
09:52 pq: did you notice that you debating this in... IRC? :-p
09:53 karolherbst: pq: if I wanted this kind of comments I would have discussed this on twitter :p
09:53 emersion: IRC is so annoying, can we move to discord?
09:53 karolherbst: rocket chat is actually a viable alternative
09:54 karolherbst: you can have social login via your own gitlab instance :p
09:54 jadahl: rocket chat hah
09:54 emersion:has also managed to get himself into the "modernize IRC" effort
09:54 karolherbst: but yeah.. I think the time will come where even IRC is dieing
09:55 pq: if you're worried about review discussions disappearing, then you can summarize the outcome in your commit messages. It helps even if the discussion history doesn't disappear.
09:55 karolherbst: ey.. modernizing IRC isn't that of an issue, there are just tons of clients around with 0 motiviation to do "out of spec" stuff
09:55 emersion: pq: yeah, but almost nobody does it…
09:55 karolherbst: pq: too much work
09:55 karolherbst: but yeah.. I really have no good idea what to do with IRC, especially because the protocoll is annoying afiak
09:55 karolherbst: especially for mobile clients
09:55 emersion: karolherbst: something something ircv3
09:55 karolherbst: or all mobile clients suck
09:56 emersion: yes.
09:56 karolherbst: or both
09:56 emersion: also part of that effort :x
09:56 karolherbst: emersion: yeah, but then someone could just use rocket chat :p
09:56 karolherbst: instead of doing ircv3
09:56 karolherbst: the super painful part is for mobile, that you need some notification server thingy
09:56 karolherbst: and that makes the overall architecture quite annoying
09:57 karolherbst: or has implications you can't do with IRC really
09:57 jadahl: karolherbst: annoying? super useful! no other IM protocol is feasable to use via telnet
09:57 karolherbst: jadahl: ehh...
09:57 karolherbst: I know people using their phones to do SSH shit
09:57 jadahl: karolherbst: I mean telnet to the IRC server
09:57 jadahl: clients are just in the way
09:57 karolherbst: ahh, sure
09:57 jadahl: /s
09:57 karolherbst: :p
09:57 ccr: jadahl, manual ping/pong ftw?
09:58 jadahl: ccr: if one cares enough it's little to ask to be a bit responsive sometimes
09:58 ccr: :]
09:59 karolherbst: :D
09:59 karolherbst: but honestly, I think the biggest issue about IRC is this "ahh your connection is gone? tough, no messages for you"
09:59 karolherbst: "your computer crashed and fs didn't sync? just ask people about what they just wrote to you!"
10:00 jadahl: imo the biggest issue with IRC is that you *have* to either use a bouncer or an irssi in a screen somewhere
10:00 jadahl: which is a bit of a barrier
10:00 jadahl: but when set up, it's lovely
10:01 jadahl: and I will stick to it until I'm all alone in the left over IRC channels :P
10:01 emersion: i wonder if fdo could provide bouncer accounts
10:05 daniels: emersion: which information can't you easily archive? the API is quite well-documented and comprehensive - you can reconstruct the entire discussion, including context, threading, relation to sections of commits, etc, from the API
10:05 daniels: and no we're never ever ever going to provide bouncer accounts
10:06 daniels: doing IRC hosting at scale is the only way to make yourself even less popular on the internet than running an SMTP amplifier which launders identities
10:07 emersion: yeah, there's an API, but converting this into something that can easily be read is… not done yet
10:07 emersion: could be restricted to freenode
10:09 daniels: define 'easily read'
10:10 daniels: do you want a flat-text dump?
10:10 hifi: I have a weird mix of quassel-core connected to irssi proxy that I can open on my phone to the same session that's open in my irssi
10:10 hifi: can have both without losing the other :)
10:10 emersion: i want something where i can actually read the discussion. for MLs i can import the mbox files whereever
10:11 daniels: I just use IRCCloud because it has some really wild features like 'notifications' and 'shared history' and 'logging I can access without SSH' and 'doesn't randomly break on me'
10:11 emersion: and 'closed source'
10:11 daniels: absolutely
10:11 emersion: doesn't work for me
10:11 daniels: sure, but then Freenode is a centralised non-reproducible service so ... shrug
10:12 emersion: i'm not sure what this means…
10:12 pq: a gitlab browser that looks like a MUA and caches locally like IMAP...
10:12 pq: ..like an IMAP client
10:13 emersion: or just a gitlab-to-ML converter? :P
10:13 daniels: sure, just figure out what the conversion to text should look like
10:13 jadahl: hifi: I have a dumb screen + irssi and have declared my phone IRC free since HTC Desire Z. quite liberating
10:14 daniels: and don't pin your hopes on that as an archival protocol, because you'll never be able to parse that flat text back into something semantically meaningful in such a way that you could replicate that on another service
10:14 pq: emersion, the ML converter won't help when you want to access things that happened before you joined the ML.
10:14 emersion: pq: ML archives are what this is for
10:14 emersion: daniels: mbox is standard
10:15 emersion: i don't think the conversion would be involved
10:15 pq: emersion, I have tried to reply to emails from ML archives few times... it doesn't work.
10:16 jadahl: pq: don't you need the actual headers and copy paste message-ids and what not to make it reply to the right one?
10:16 pq: also, emailed patches or review comments do not allow you to expand the diff context, which for me maker reviewing very much harder
10:16 emersion: (1) it should, maybe bad email client not handling in-reply-to in mailto? (2) workaround is to download the raw message and import it (3) if it's to archive content, you're not supposed to be able to reply
10:17 pq: jadahl, yes, it's so difficult to get right it cannot be bothered with.
10:17 emersion: the ML archive can expand the diff context, if it wants to
10:18 hifi: jadahl: once you add all the fancy new services to your phone irc is the least of your worries
10:18 pq: emersion, how can ML archive expand diff context, if the email does not even tell which base commit it applies to?
10:19 pq: emersion, sounds very painful, that ML archives usage - corresponds with my experience
10:20 emersion: it doesn't help that most ML archives are bad
10:20 emersion: all ML archives you've used, presumably
10:21 pq: I might say the same about all Gitlab-like web services you have used.
10:22 emersion: do you have a particularily good gitlab-like service in mind?
10:22 pq: gitlba.fd.o works very well for me
10:23 emersion: i've used that
10:23 emersion: i'm just implying that if you've only used mailman, of course you're going to argue that MLs are bad
10:24 karolherbst: the issue is just, that emails suck
10:24 emersion: lore.kernel.org is already an upgrade
10:24 emersion: karolherbst: the web sucks, too
10:24 karolherbst: that might be, but mainly because of emails
10:25 emersion: lol
10:25 daniels: https://lore.kernel.org/linux-arm-msm/ is ... not amazing tbh
10:25 emersion: i've said "an upgrade"
10:25 emersion: not "good" :P
10:25 karolherbst: daniels: how long do I have to wait?
10:25 karolherbst: ahh, now it's open
10:25 karolherbst: just took 20 seconds, that speed
10:25 karolherbst: uff
10:25 karolherbst: that's one of those "insta close" pages
10:26 karolherbst: emersion: honestly, most of the IM services we have is, because email suck and they improved messaging a lot
10:26 emersion: IM is orthogonal to emails
10:26 pq: Patches by email is fundamentally a lost cause, you have to deliver complete git branches to give the full code context of a patch.
10:26 karolherbst: the issue is just, that good ol 90s hackers are against centralized systems and because they were, they said "but emails!!!"
10:26 karolherbst: and everything went along the wrong path
10:26 karolherbst: but email sucked
10:27 karolherbst: so this is the cause of the entire mess
10:27 pq: emersion, I've had really hard time trying to review e.g. your KMS doc patches, because the email does not have enough diff context.
10:27 karolherbst: luckily we do have something like rocket chat, but that isn't perfect either. We have other things, but they also come with caveats like "no business model"
10:27 daniels: anyway, if you find the web UI so slow to click through that it's the limiting factor in how fast you can open MRs (that's impressive, given it only takes a second or two for me), then you can either take https://gitlab.freedesktop.org/-/snippets/637 or adapt it into the obvious curl one-liner
10:27 karolherbst: emersion: why does it have to?
10:28 karolherbst: IM is better at sending files...
10:28 karolherbst: sad truth
10:28 emersion: daniels: have you noticed how long this takes to load, just to look up a comment? https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/8
10:28 karolherbst: send a bigger file via email
10:28 karolherbst: good luck
10:28 patrik: danvet, Hi, I managed to create a conflict in gma500 with the drivers-x86 tree. How do I go about solving such a conflict?
10:29 karolherbst: daniels: a gitlab git plugin :p
10:29 emersion: daniels: i'm not complaining about the "new MR" page, but about the "MR comments" page itself
10:29 karolherbst: it's all a json API
10:29 karolherbst: just write your awesome client
10:29 daniels: emersion: yeah, 6sec from initiating page load to all comments rendered, which is less than ideal
10:29 karolherbst: git gitlab mr 5325 comments
10:29 karolherbst: or wahtever
10:29 MrCooper: pq: were you referring to https://gitlab.com/bichon-project/bichon ?
10:30 daniels: but I also can't scroll through emails in 6 seconds, so
10:30 emersion: it took lik 20s for me
10:30 emersion: like*
10:30 daniels: are you on dial-up, or is your browser a Raspberry Pi?
10:30 hifi: that's a *long* thread
10:30 daniels: (I thought it was more like 5 seconds, so I used the Chrome web tools to time it)
10:30 karolherbst: hifi: nope
10:30 emersion: yup, 20.48s
10:30 karolherbst: 180 comments, I've seenw orse :p
10:31 emersion: i have fiber connection, and it's my feefiest computer
10:31 patrik: danvet, It's fairly trivial. Is it enought to give a heads-up to Linus?
10:31 emersion: beefiest
10:31 karolherbst: but we don't have to argument that gitlab is slow, there is room for improvement
10:31 karolherbst: like loading first comments first
10:31 karolherbst: or the one you linked to
10:31 hifi: I doubt you can do that in-depth reviews with less amount of effort in mail
10:31 karolherbst: that stuff is totally possible
10:31 karolherbst: just somebody would have to implement that
10:31 emersion: another shameless plug while i'm at it… https://forgeperf.org/
10:32 karolherbst: "I choose my own metrics which show my product is the best" :p
10:32 emersion: it's not "my own metrics", it's "google metrics"
10:33 emersion: also reproducible locally
10:33 karolherbst: that wasn't my point
10:33 karolherbst: and anyhow
10:34 karolherbst: the focus should be on making stuff better
10:34 emersion: yes
10:34 karolherbst: gitlab is slower, and there is no point in denying that
10:34 karolherbst: the question is: does it matter
10:34 karolherbst: and are there other things more important to improve
10:34 karolherbst: and sure, it's annoying that sometimes it takes like 10 seconds to load comments
10:34 daniels: emersion: something is desperately, horribly, wrong if it's taking 3.5x the time for your fibre + workhorse desktop to load it, compared to my couple-year-old XPS on a very average consumer HFC link
10:34 emersion: other things more important to improve: gitlab competitor :P
10:34 MrCooper: it got noticeably faster over the course of last year though FWIW
10:34 danvet: patrik, the commits that sfr pointed out arent even in my linux-next
10:35 hifi: it wouldn't be a bad effort for _someone_ so create a viable gitlab competitor
10:35 karolherbst: daniels: sometimes the used browser matters
10:35 hifi: gitlab is slow and their business model is anti-floss
10:35 karolherbst: and caching and stuff
10:35 daniels: Chrome 88.0.x stable
10:36 emersion: firefox here
10:36 daniels:also notes that the Lighthouse stats are horribly skewed if they don't include caching, which is realistically something that people have available on their browser
10:36 emersion: ofc everybody optimizes for chrome, no wonder…
10:36 hifi: (I don't blame gitlab here, it's their product and free to do whatever they want)
10:36 karolherbst: emersion: yeah, because mozillas business model is to use google
10:36 karolherbst: :p
10:36 emersion: daniels: there's the cold and warm cases in here
10:36 danvet: patrik, anyway I replied
10:36 karolherbst: can just use the better browser
10:36 daniels: in which case the fair correlation would be pulling the entire lkml git archive from lore before you looked at a single patch
10:37 danvet: patrik, might also be that the patches wont make it into 5.12, and then we can just backmerge
10:37 patrik: danvet, thanks
10:38 daniels: emersion: 5.1s here using Firefox with a completely fresh profile (no cache), from whatever the Flatpak build is
10:38 daniels: (I don't entirely blame Chrome for being slower as it's currently burdened with about a thousand tabs)
10:38 emersion: well i don't know what the deal is
10:39 daniels: Ctrl+Shift+I, look at network trace?
10:39 emersion: i've done that to measure the load time, with cache enabled
10:41 patrik: danvet, what should I have done to avoid this? I assume I shouldn't pull the immutable branch from Andy and push it through drm-misc. Or can I?
10:41 karolherbst: daniels: well, ar eyou waiting until all comments are loaded?
10:41 karolherbst: I've got around 8s here
10:42 karolherbst: but yeah... loading comments in gitlab is slow
10:43 daniels: karolherbst: yep, viewport max down and waiting till the last note is visible
10:44 karolherbst: mhh
10:44 emersion: also keep in mind we're pretty lucky to have beefy computers and good connectivity, that might not be the case of anyone
10:44 emersion: everyone*
10:45 hifi: I've seen a bug report where the reporter complained a gui program took too much space on a 4:3 1280x1024 monitor, and this was last year
10:45 daniels: emersion: totally, it's no excuse for not continuing to push frontend optimisation
10:46 hifi: or is that 5:4, hatever
10:46 daniels: I know they spent a lot of time last year cutting down on unnecessary JS transfer & execution both
10:46 emersion: yeah, it's been improved
10:46 hifi: I don't know how well anything runs anymore on a monitor smaller than 1080p
10:56 daniels:looks at why Marge has such a sensationally high failure rate
10:57 danvet: patrik, imo immutable branch is overrated, conflicts occasionally happen
10:58 danvet: but if you do have an immutable branch you want to get pulled, pls ping drm-misc maintainers
10:58 danvet: handling branches is their thing
10:58 patrik: right, I'll do that next time
10:59 MrCooper: emersion: BTW, are you aware of the -isystem compiler option (is_system in meson)?
10:59 emersion: ah, yes
10:59 emersion: indeed
10:59 emersion: that's a good point
11:00 MrCooper: I'm not sure it fully addresses your concern, but seems like it might
11:00 emersion: (meson doesn't set it up correctly on BSDs for the widely used /usr/local prefix, but that's a meson bug)
11:01 emersion: (e.g. libdrm gets installed to /usr/local on FreeBSD and doesn't get -isystem)
11:01 emersion: yeah, it might indeed
11:01 pq: MrCooper, no, I didn't know such thing existed!
11:02 emersion: duplicating the typdefs is not great, but acceptable imho
11:02 emersion: pq: thoughts about xexaxo1's patch, btw?
11:03 xexaxo1: emersion: if you have a hatred toward something, please mention it early. this way we can look into it.
11:04 MrCooper: pq: I happen to know of it because a Red Hatter created it and advertised it internally :)
11:04 xexaxo1: emersion: also, found a way to so that people can have their cake (define the standalone) and eat it, w/o doing any work
11:07 emersion: xexaxo1: sorry, i didn't mean to be aggressive or anything. i just meant that i find it very annoying when an include causes a build error
11:08 emersion: i apologize for the harsh phrasing
11:09 pq: emersion, I don't want to touch the header bikeshed.
11:09 emersion: ok
11:09 xexaxo1: emersion: I don't mind, but w/o such info I cannot really help
11:09 xexaxo1: give me 10 to double-check my assumption and you'll see an v2 in your inbox.
11:10 emersion: thanks, but with -isystem i'd R-b your first approach too
11:57 xexaxo1: emersion: hmm the -isystem thing is client side right? so checking each user doesn't sound like it will scale well.
11:58 emersion: what do you mean by "client side"?
11:58 xexaxo1: the projects using the UAPI. unless there's a way to enforce -isystem within the header itself?
12:08 FLHerne: daniels: KDE has bouncer accounts for registered members, it doesn't seem to suffer much abuse
12:15 karolherbst: FLHerne: and how to you solve this "save password in cleartext" for authenticated nicks issue?
12:18 FLHerne: karolherbst: I think it just stores the password in cleartext :p
12:18 karolherbst: :p
12:19 karolherbst: would be cool if IRC would allow social logins :D
12:19 FLHerne: karolherbst: But znc and freenode both support SASL EXTERNAL, so in principle you could give it a cert instead
12:19 karolherbst: mhhh
12:19 karolherbst: right
12:19 karolherbst: but it's still a mess
12:20 daniels: karolherbst: would be cool if IRC had any concept of identity, or reliable delivery, or history, or abuse controls, or or or or ...
12:21 danvet: emersion, if you figure out the archive-to-mbox bikeshed, that might be useful for lore.kernel.org
12:21 danvet: if only to keep up appearance
12:22 danvet: since I don't think it's going to be very useful
12:22 danvet: might also be the lore folks have something already
12:23 emersion: hm, what do you mean danvet?
12:23 emersion: mailman already has a way to export to mbox
12:23 emersion: it's not great, but it's there
12:23 danvet: emersion, for gitlab
12:23 emersion: ah, i see
12:24 danvet: I think lore is currently simply subscribed to fd.o lists it archives
12:42 karolherbst: daniels: you mean like rocket chat? :p
12:42 daniels: sure, Rocket's entirely valid
12:42 karolherbst: it's a bit buggy, and the clients are annoying, but at least it works and has what a normal user epxects there to be
12:42 daniels: we use Mattermost internally at Collabora, but Rocket was reasonably similar when we looked at it, and none of the reasons for choosing Mattermost would apply to an open community
12:43 daniels: (plus Mattermost's dev model is ... not great)
12:43 karolherbst: yeah.. if we ever come to the point where ditching IRC is the topic, I'd vote for rocket
12:43 FLHerne: No Matrix?
12:44 karolherbst: please not matrix
12:44 ddevault: email bad, yes. gitlab bad, also yes. email > gitlab, definitely yes
12:45 karolherbst: rocket has this huge advantage, that you deploy it and people can just start using it
12:46 karolherbst: although I guess it also has improved, so maybe it would be a viable alternative atm
12:46 karolherbst: dunno..
12:46 karolherbst: if we discuss this in 10 years, we can see what is available then :p
12:51 ddevault: also, the idea that gitlab is easier for noobs becasue they already know how to use it is a circular argument
12:52 ddevault: any seasons project maintainer will tell you that actual noobs bugger up gitlab MRs all. the. time.
12:52 ddevault: learning to use email and learning to use gitlab for the first time are comparible in learning curve.
12:55 ddevault: oh, and one less new account to worry about when you're using email. So often it's less work
12:58 pq: As a reviewer, I find the Gitlab workflow much MUCH better than the email workflow. I had been using the email workflow for less than ten (but more than five) years, so I never automated it far enough, even then automating the "where does this patch apply to" is very fragile.
12:58 ddevault: there's ongoing work to replicate the git{hub,lab}-style code review experience in the browser, but for emailed patches
12:59 ddevault: but personally, I really prefer to use my mail client
12:59 ddevault: I review 10-30 patches per day over email and it works very well for my needs
13:00 pq: My pain point is not the UI so much but the "emailed patches" which you can't tell where they should apply.
13:00 ddevault: one easy answer is to use filters on the list-id header
13:01 ddevault: I've been advocating on the git mailing list for some time now that upstream repos should be able to set the formatPatch.subjectPrefix after git clone, to automatically use [PATCH projectname]
13:01 ddevault: and the upstream mailing list, too
13:01 ddevault: it's hard going, they don't like it when remotes influence config options
13:01 pq: I mean the base commit, not the project.
13:01 ddevault: is there often more than one obvious base commit?
13:02 pq: often there is *no* obvious base commit
13:02 ddevault: I just use git am -3 to apply to master
13:02 ddevault: and do a 3-way merge
13:02 ddevault: which isn't substantially different from what gitlab is doing
13:10 karolherbst: with gitlab I don't have to bother
13:10 ddevault: pressing the merge button == git am -3
13:10 karolherbst: so what?
13:11 ddevault: so, that's the same thing. bothering.
13:11 karolherbst: no
13:11 karolherbst: it isn't
13:11 ddevault: ¯\_(ツ)_/¯
13:11 karolherbst: what if I want to try it out myself?
13:11 karolherbst: usually I just pull the remote and switch to the branch
13:11 ddevault: git am -3
13:11 karolherbst: then I need to download the patches
13:11 ddevault: applies it locally, not upstream
13:11 ddevault: technically the second step is git push
13:11 ddevault: no, just apply them right from your inbox
13:11 karolherbst: but I don't want to push
13:11 karolherbst: I want to try it out
13:12 ddevault: aye, that's what git am does
13:12 karolherbst: ....
13:12 ddevault: like I said, git push is a second step. So don't do that step if you don't want to push
13:12 karolherbst: I don't need to use git am
13:12 karolherbst: and don't want to
13:12 karolherbst: I just fetch from the remote directly
13:12 ddevault: it's just the tool you use for the job with email
13:12 karolherbst: then it's all in git
13:12 ddevault: it's not substantially different from using git fetch
13:12 ddevault: different tools are not boogeymen
13:13 ddevault: the same things are possible
13:13 karolherbst: you claim it's the same, which it is really not
13:13 karolherbst: from a workflow perspective
13:13 ddevault: yes, email is a different workflow
13:13 ddevault: news at 11
13:13 karolherbst: you were the one claiming it's the same...
13:13 ddevault: no, that it can do the same things
13:14 karolherbst: but what do you do if git am -3 fails?
13:14 ddevault: resolve the merge conflicts, or tell the user to rebase their patch
13:14 karolherbst: but I want to test right now
13:14 karolherbst: :p
13:15 ddevault: why? not like you can merge the patch even if the tests work
13:15 karolherbst: in my flow I just switch to the branch and be done with it
13:15 karolherbst: maybe I don't want to merge
13:15 karolherbst: maybe I just want to review or test or wahtever
13:15 ddevault: also, the CI would have told them their patch doesn't apply
13:15 ddevault: so you might not even be involved before they've fixed it for a v2
13:15 karolherbst: yes
13:15 karolherbst: but not on the ML
13:15 ddevault: not on *your* ML
13:16 karolherbst: fair
13:16 karolherbst: but that's not feasible for a project like mesa
13:16 karolherbst: sometimes you push out an MR and it stays there for months
13:16 karolherbst: and in the meantime it conflicts
13:16 ddevault: I have a patch in my inbox which was written in august
13:16 karolherbst: ...
13:16 ddevault: when it's time to apply it I'll just ping the maintainer for a rebase, or just address the conflicts myself
13:16 ddevault: happens in email, too, and we deal with it
13:17 karolherbst: sure
13:17 karolherbst: but that wasn't my point
13:17 ddevault: also, email can use git fetch, if it's worth it, like for large changes or integrating workstreams
13:17 ddevault: see git-request-pull(1)
13:17 karolherbst: of course you can twist everything in a way it fits your view on things should be, but sometimes you just want to test something right now
13:17 karolherbst: without having to wait for others
13:17 karolherbst: or want to resolve stupid conflicts
13:17 karolherbst: with git based workflows, you don't have any of those issues
13:18 karolherbst: sure, it needs to be resovled when you want to merge it
13:18 karolherbst: but sometimes things just take a long time
13:18 ddevault: git checkout 'HEAD@{August 8th}' probably ought to get you closer to whenever the patch is supposed to apply
13:18 karolherbst: also annoying
13:18 ddevault:shrugs
13:18 ddevault: I don't find this annoying. There are tradeoffs and they sum differently for everyone. For me it sums to a preference for email
13:19 ddevault: the main advantage is the throughput for typical patches, outliers are outliers on any workflow
13:19 karolherbst: sure
13:19 ddevault: I can fire off a patch via email to the projects I contribute to in like half a second
13:19 ddevault: takes me at least a minute to do a gitlab MR
13:19 ddevault: brb
13:20 karolherbst: but that's a tooling issue. There are git integrated things to make that easier from cli as well (at least I think, and I would be surprised if not)
13:25 daniels: ddevault: git push -o merge_request.create
13:26 ddevault: karolherbst: tools based on open standards, however
13:26 ddevault: daniels: neat, that helps. But only when I've already set up for that project
13:27 hifi: ddevault: because you have this ML workflow already well established but most people don't and they really don't want to either
13:27 karolherbst: daniels: we kind of need this gitlab git alias stuff where everything like that is easy to use
13:27 ddevault: hifi: we like it. What's it to you?
13:28 karolherbst: the main point is still "how to get new contributors"
13:28 karolherbst: especially young ones
13:28 hifi: ddevault: I'm just saying if the original discussion spawned off from it being quite complicated to submit a patch without having that workflow already set up
13:28 karolherbst: and email simply can't deliver that
13:28 karolherbst: becuase email just sucks :D
13:28 ddevault: it's not quite complicated to submit a patch without having it set up
13:28 karolherbst: email cleints suck
13:28 ddevault: https://git-send-email.io
13:28 karolherbst: email frontend suck
13:28 daniels: ddevault: sure, as a starting point you have to either go fork the repo (literally one click), vs. go subscribe to the mailing list or at least copy down its address, etc
13:28 karolherbst: everything with email sucks
13:29 ddevault: spending 15 seconds waiting around for every gitlab page to load sucks, karolherbst
13:29 karolherbst: sure
13:29 hifi: ddevault: no one has smtp configuration available in 2021 except people who already use MLs
13:29 karolherbst: but talk with young people
13:29 karolherbst: they don't use email
13:29 karolherbst: and now?
13:29 ddevault: daniels: you have to fork the repo and update your remotes, and that skips the sign up step too
13:29 vsyrjala: karolherbst: but if gitlab will alienate the experienced devs, you've lost more than just new controbutors
13:29 ddevault: hifi: nonsense.
13:29 karolherbst: vsyrjala: don't care
13:29 ddevault: anyway, we're working to bridge the gap
13:29 vsyrjala: lol
13:29 daniels: ddevault: again I'm seeing <6s for fully cold start-to-finish load on one of the longer MR discussions, so if every single page is taking 15 seconds for you, something is deeply wrong
13:29 ddevault: we're building web tools which are functionally identical to gitlab, but which use email under the hood
13:30 karolherbst: vsyrjala: also, experienced devs are not alienated by gitlab
13:30 ddevault: I don't see what you've got to complain about here
13:30 karolherbst: a few are
13:30 karolherbst: but the most are not
13:30 ddevault: daniels: 6 seconds is deeply wrong
13:30 vsyrjala: karolherbst: i am. it's awful
13:30 ddevault: daniels: most sr.ht pages load in like 100ms
13:30 karolherbst: vsyrjala: then you are one of the few
13:30 hifi: ddevault: I don't remember needing smtp configuration for like 5 to 10 years after I switched to gmail like most other people in the world (and equivalent), it's just not something people need to think anymore
13:30 ddevault: I'm not going to give you any credit for switching to gmail like everyone else
13:30 ddevault: gmail has SMTP, and there are instructions on git-send-email.io for configuring it
13:30 karolherbst: gmail is one of the best email providers
13:30 daniels: ddevault: I'm not arguing that it shouldn't continue to get quicker, just that the claims that every single page load always take 15-20+ seconds and this is some kind of universal inviolate constant are ... not at all true
13:31 karolherbst: from a user expeirence pov
13:31 ddevault: your hand is being sufficiently held
13:31 ddevault: daniels: what is true is that it's 10x slower than sr.ht
13:31 hifi: ddevault: that doesn't mean people want to spend time configuring it, it's a high barrier
13:31 ddevault: and sr.ht is 100x slower than not opening your browser in the first place
13:31 vsyrjala: we need usable command line tools for gitlab. otherwise it's just going to be suck
13:31 karolherbst: what annoys me most is this "high and might" opinion "old school hackers" have of them selves
13:31 zmike: but it's 2021 so my browser starts when my computer does
13:31 karolherbst: "just learn it"
13:31 hifi: you can always scoff that off by saying "we don't need contributions from lazy and stupid people"
13:31 daniels: vsyrjala: did you try any of the ones I pointed you at last time?
13:31 karolherbst: "just do those 2 cli commands"
13:31 ddevault: hifi: yeah, they just configure their gitlab account, generate and add their SSH key, then fork the repo and update their remotes, remember to push to the right one and update your branch's upstream...
13:31 karolherbst: this sucks
13:32 karolherbst: some people don't want to do cli shit
13:32 daniels: ddevault: mutt takes 15+ seconds to open most of my large mailboxes
13:32 karolherbst: some people don't want to have to read through man pages
13:32 ddevault: I suspect that people who don't want to do CLI shit and mesa contributors are mutually exclusive groups
13:32 vsyrjala: daniels: i've used something that was written in go. allowed to semi-manage mrs at least
13:32 karolherbst: or wahtever other random argumetns people bring up
13:32 ddevault: daniels: I use aerc, it works much better
13:32 rbarraud: lazy and contributor are disjoint sets...
13:32 hifi: ddevault: you're making an assumption people don't have SSH keys already which I believe most developers "who use github" already do so that's a moot point, you can also use https to push so it's not a strict requirement
13:32 daniels: so in order to contribute effectively I have to find a new mail provider, and a new mail client, and and ...
13:32 ddevault: hifi: you're making another assumption yourself
13:32 karolherbst: ddevault: what is your answer to people not wanting to use cli based email clients then?
13:33 ddevault: can we knock it off with these baseless assumptions
13:33 karolherbst: or peoplenot wanting to use email
13:33 ddevault: karolherbst: we have the web UI for them
13:33 emersion: hifi: GitHub will disallow HTTPS pushing soon
13:33 hifi: ddevault: the https option doesn't require a SSH key so it's valid enough
13:33 ddevault: we're meeting them at their needs
13:33 vsyrjala: but no solution to "doing review/working with bug reports is just bad on the web ui"
13:33 ddevault: gitlab does not meet us at ours
13:33 emersion: hifi: they have a blog post about it
13:33 hifi: emersion: then it means most people will have an SSH key ;)
13:33 emersion: and will need to fiddle with gitlab UI to add it
13:34 rbarraud: github meets M$' needs... ;-/
13:34 daniels: vsyrjala: well that's predicated on the assumption that 'just bad' is a) actually defined, and b) true
13:34 ddevault: setting up gitlab or email are both time-consuming, error-prone processes, which vary from trivial to annoying depending on the person
13:34 ddevault: can we leave it at that?
13:34 vsyrjala: worse than email/bugzilla is my defintion of bad
13:34 karolherbst: vsyrjala: your bar is very low
13:34 hifi: github can be considered the largest user base of open source developers so I bet that overlaps greatly with people who want to work on things that are not on github, hence, ssh keys and the workflow is already established
13:34 ddevault: at least with email, you're set up once and ready to go for every project. I have to re-configure every gitlab instance
13:34 daniels: vsyrjala: well it's 100% untrue, so problem solved then!
13:35 vsyrjala: karolherbst: and yet gitlab can't deliver even that
13:35 karolherbst: yeah, I guess that's fair to say
13:35 rbarraud: Is there a recommended FAQ or similar for ppl trying to get their head around mesa, dri and drm and kms?
13:35 rbarraud: [not lazy, just confused :-/ ]
13:35 rbarraud: ;-)
13:36 pq: ddevault, I have had several cases where git am -3 does not work, but if I find the actual base commit and apply there, then rebase is able to resolve it automatically. I can also see what the patch did when it was written, and what it does now when it is rebased.
13:36 rbarraud: My mesa is defo not sane at present - either it's just b0rked more than usual or I misconfid something.
13:36 rbarraud: FreeBSD 12.1
13:37 ddevault: pq: fair. An unusual edge case, though
13:37 rbarraud: Intel HD4000 (i7-3770 Ivy Bridge)
13:37 ddevault: actual frequency varying from project to project
13:37 karolherbst: rbarraud: normally it should just work. re you trying to build it yourself or what?
13:37 rbarraud: Nope
13:38 rbarraud: Although I might have mixed pkg and port at some stage...
13:38 karolherbst: mhh.. dunno how much in depth testing freebsd gets as almost all testing is done on linux
13:38 rbarraud: Been trying to get OpenGL, SDL2 etc playing nice on and off for moons..
13:38 karolherbst: maybe just file a bug if you think it's a bug?
13:39 rbarraud: So I probably built something from ports and misconfig'd it...
13:39 karolherbst: maybe
13:39 karolherbst: do you know what fails?
13:39 rbarraud: Yeah - i915 mesa stuff
13:39 rbarraud: and swrast
13:40 rbarraud: I'm not even entirely sure whether i915 is the correct driver to use for HD4000/Ivy Bridge graphics :-/
13:40 rbarraud: Unfortunately there is a dearth of man pages / info on mesa on FreeBSD
13:41 rbarraud: And I am confused between dri and drm ...
13:41 rbarraud: If I run pretty much any OpenGL (e.g. GLXGears) I get a frozen UI, then black screen and I can't even get to a VT
13:42 rbarraud: I think even ssh into the box fails... so I suspect it's driver-relatred :/-
13:42 rbarraud: :-/
13:43 rbarraud: typical report (from Octave GUI in this case):
13:43 rbarraud: "libGL error: MESA-LOADER: failed to retrieve device information
13:43 rbarraud: libGL error: MESA-LOADER: failed to open i915: Cannot open "/usr/local/lib/dri-devel//lib/dri-devel)
13:43 rbarraud: libGL error: failed to load driver: i915
13:43 rbarraud: libGL error: MESA-LOADER: failed to open swrast: Cannot open "/usr/local/lib/dri-deveocal/lib/dri-devel)
13:43 rbarraud: libGL error: failed to load driver: swrast"
13:44 karolherbst: rbarraud: the paths seem quite odd
13:44 karolherbst: I assume those do not exist?
13:45 rbarraud: Double-slash is a bit suss, admittedly... but should resovle to single
13:45 karolherbst: oh, that's not what I meant
13:45 pq: ddevault, will your email-based web tools be able to reconstruct the git branch from which a patch was originally sent?
13:45 karolherbst: but anyway, do those path exist and have files in them?
13:45 ddevault: pq: could be possible in theory
13:45 ddevault: we have to do some related work
13:46 rbarraud: Ach - didn't even notice the double-up there
13:46 rbarraud: Not sure where it's set ; I'll greo in /etc (etc.)...
13:47 karolherbst: rbarraud: the paths are usually hardcoded when compiling
13:47 rbarraud: the first one exists in not-doubled-up form and has a i915 driver, yep
13:47 karolherbst: mhh
13:47 ccr: @__@
13:47 rbarraud: and the second is obviously munted.
13:48 karolherbst: rbarraud: maybe check if something goes wrong on the ld level?
13:48 karolherbst: uhm
13:48 karolherbst: not sure how that works on freebsd
13:48 karolherbst: but maybe some symbols missing, or mix and match of old mesa
13:48 karolherbst: etc...
13:48 rbarraud: I think they're both *trying* to be /usr/local/lib/dri-devel/, which definitely exists and has i965_dri.so among others in it.
13:49 rbarraud: drwxr-xr-x 2 root wheel 8 31 Jan 19:16 .
13:49 rbarraud: ...
13:49 rbarraud: -rwxr-xr-x 1 root wheel 14226656 27 Jan 17:44 i965_dri.so
13:49 rbarraud: Permissions look sane too.
13:49 karolherbst: mhhh
13:50 karolherbst: rbarraud: I think something is wrong though... the message looks odd..
13:50 karolherbst: normally it wouldn't print "/usr/local/lib/dri-devel//lib/dri-devel)
13:51 karolherbst: rbarraud: if I mess around I get "libGL error: MESA-LOADER: failed to open iris: /tmp/iris_dri.so: cannot open shared object file: No such file or directory (search paths /tmp)"
13:51 karolherbst: or "libGL error: MESA-LOADER: failed to open iris: /dasd/iris_dri.so: cannot open shared object file: No such file or directory (search paths /dasd)"
13:52 karolherbst: rbarraudI think this " is hardcoded somewhere
13:52 karolherbst: and it tries to use it for resolving the path as well
13:52 karolherbst: or something
13:52 karolherbst: anyway.. it looks very strange
13:53 karolherbst: rbarraud: maybe use something like strace to see what the runtime actually does?
13:54 rbarraud: Ach - I probably shouldn't be trying this at 2 am :-/
13:54 rbarraud: I was wrong - there's an i965 in there, not an i915...
13:55 karolherbst: ahh
13:55 karolherbst: right.. you need i965 or iris :D
13:55 karolherbst: wait...
13:55 rbarraud: I think the munted path was actually a weird pasting artefact...
13:55 karolherbst: why is it searching for i915?!?
13:55 rbarraud: full messages show failure report with correct path, then the search path.
13:55 rbarraud: Good question...
13:56 rbarraud: I have i915_kms loaded...
13:56 karolherbst: rbarraud: try with MESA_LOADER_DRIVER_OVERRIDE=i965
13:56 rbarraud: Should I not?
13:56 karolherbst: the kernel driver is called i915, yes
13:56 imirkin: rbarraud: what GPU do you have?
13:56 rbarraud: In the envorinment, or as part of compilation?
13:56 karolherbst: rbarraud: environment, yes
13:56 imirkin: oh, you mentioned above, ivb. yeah, i965 or iris are the mesa drivers
13:56 rbarraud: Intel HD4000 ... integrated GPU in i7-3770
13:56 imirkin: er, just i965
13:57 rbarraud: Ivy Bridge (yes, it's getting old :-/ )
13:57 imirkin: iris is gen8+
13:57 karolherbst: ahh, right
13:57 karolherbst: my mistake
13:57 rbarraud: And mine :-/
13:57 imirkin: (and ivb is gen7)
13:57 karolherbst: rbarraud: does it work with the env var?
13:57 rbarraud: I'll try...
13:57 karolherbst: dunno if that's debug only, but worth a try
13:58 imirkin: normally the loader works it out based on the pci id
13:58 rbarraud: "MESA_LOADER_DRIVER_OVERRIDE=i965 glxgears ==>
13:58 rbarraud: MESA_LOADER_DRIVER_OVERRIDE=i965 glxgears
13:58 rbarraud: [intel_init_bufmgr: 1957] Kernel 3.9 required.
13:58 rbarraud: libGL error: failed to create dri screen
13:58 rbarraud: libGL error: failed to load driver: i965
13:58 rbarraud: libGL error: MESA-LOADER: failed to open swrast: Cannot open "/usr/local/lib/dri-devel/swrast_dri.so" (search paths /usr/local/lib/dri-devel)
13:58 rbarraud: libGL error: failed to load driver: swrast
13:58 rbarraud: Error: glXCreateContext failed
13:58 rbarraud: ➜ "
13:58 imirkin: but if you (a) have a wildly weird device or (b) freebsd hooks for determining pci id aren't properly hooked up, then you'll get this problem.
13:59 karolherbst: rbarraud: that sounds like progress
13:59 imirkin: rbarraud: [intel_init_bufmgr: 1957] Kernel 3.9 required.
13:59 karolherbst: but now your kernel annoys you
13:59 imirkin: that's the key.
13:59 karolherbst: yeah.. and I guess X also does something weirdo and defaults to i915 or something
13:59 rbarraud: Yup
13:59 karolherbst: and reports that
13:59 imirkin: it wants some api introduced in linux kernel 3.9. if freebsd is from "older than that", then you're in trouble
13:59 imirkin: if it's from newer than that, then you need to figure out why it's deciding that your kernel doesn't have the requisite api
13:59 rbarraud: There may be a port ...?
14:00 karolherbst: dunno...
14:00 imirkin: well, all the freebsd kms drivers are basically copies of the linux stuff
14:00 karolherbst: the drm drivers on freebsd are.. well
14:00 imirkin: but the question is from what kernel are they copies
14:00 rbarraud: It's near-latest... one point release behind the latest 12.2 release.
14:00 imirkin: 3.9 is fairly old ...
14:00 rbarraud: I keep it updated fairly often
14:00 imirkin: no, which linux kernel
14:00 rbarraud: Not Linux...
14:00 imirkin: the freebsd kernel can be as new as you want, if they last copied the driver 100 years ago
14:00 rbarraud: FreeBSD.
14:00 imirkin: then you're going to be in for a bad time
14:00 imirkin: re-read what i wrote carefully.
14:00 karolherbst: rbarraud: the drm drivers in FreeBSD are just copied out from Linux
14:01 karolherbst: but imirkin wants to know from which linux those copies are
14:01 karolherbst: but yeah.. drm on FreeBSD is not fun
14:01 karolherbst: there are occasionally people trying to update stuff
14:01 rbarraud: imirkin: Sorry, I see what you mean.
14:01 karolherbst: never know if they succeed or don't bother after failing
14:01 rbarraud: 3am... :-/
14:01 imirkin: no worries
14:01 imirkin: i'm not personally familiar with the state of things on freebsd
14:02 imirkin: i believe they do update stuff every so often
14:02 rbarraud: I should prob come back to this when I've had some more sleep.
14:02 rbarraud: Thanks for at least some clarification...
14:02 imirkin: note that latest linux kernel version is like 5.10
14:02 rbarraud: And I've cut thru some confusion here even if by way of embarassing myself :-/
14:02 rbarraud: I'm in NZ BTW
14:02 rbarraud: Hence the crazeh hour
14:02 imirkin: v3.9 was released ... in 2013
14:03 imirkin: so the requirement that you have a kms newer than that doesn't seem _too_ crazy :)
14:03 karolherbst: rbarraud: no worries. At least we figured out it is probably a kernel issue
14:03 imirkin: but it could well be that the copy was made, but some ioctl wasn't hooked up
14:03 imirkin: or something else silly
14:03 rbarraud: So what is the diff/relationship between drm and dri?
14:03 imirkin: there's a good pdf that explains a lot of this stuff
14:03 imirkin: let me see if i can find it
14:04 rbarraud: Is there a good chart of how they fit together and what the driver stack should actually look lik?
14:04 imirkin: rbarraud: https://keyj.emphy.de/files/linuxgraphics_en.pdf
14:04 imirkin: this is a bit old, but still like 99% accurate
14:04 imirkin: at least at the level that you care about
14:04 rbarraud: I think most of the dirty stuff is taken care of by the kms ... e.g. CRT controller for mode(line) switching etc...
14:05 karolherbst:wished somebody would correct the wrong charts in wikipedia
14:05 rbarraud: Presumably if the appropriate memory regions are given to the drivers by the kernel they should be somewhat portable - modulo things like vsync / hsync and scheduling ... :-/
14:05 imirkin: yes ... if only it was so simple as "CRT controller for mode switching" :)
14:05 imirkin: unfortunately it's not 1990 anymore
14:06 imirkin: very sad.
14:06 rbarraud: Yeah I know right...
14:06 rbarraud: I mean the manipulation of the GPU's guts etc should be essentially portable
14:06 imirkin: so like nowadays, video cards have more memory than just enough for 2 framebuffers
14:06 imirkin: so this stuff works a bit differently
14:06 rbarraud: perhaps with some timing issues...
14:06 rbarraud: ?
14:06 imirkin: sure
14:07 imirkin: that's why freebsd can easily copy the linux stuff
14:07 karolherbst: imirkin: depends on the size of the framebuffer :p
14:07 rbarraud: I'm talking thru my hat as I haven't [wanted to] taken a deep dive into the driver code...
14:07 imirkin: 90% of the code is manipulating the gpu. 10% of the code is operating system glue.
14:07 imirkin: (probably)
14:07 karolherbst:wondering if 8x SSAA on a 8K screen is a thing already
14:07 imirkin: karolherbst: why only 8x?
14:07 karolherbst: :D
14:07 karolherbst: fair enough
14:07 rbarraud: Probably given enuf megabucks?
14:08 imirkin: thinking small here!
14:08 karolherbst: games usually only allow 4x SSAA
14:08 imirkin: with SSAA, the sky's the limit
14:08 rbarraud: imirkin: exactly.
14:08 imirkin: rbarraud: i strongly encourage you to read that presentation
14:08 imirkin: it's not long
14:08 karolherbst: I am sure on a 8k display even 2x SSAA could be considered pointless :p
14:08 rbarraud: Everything's just memory mapped, INT
14:08 imirkin: and i think covers a lot of these concepts succinctly
14:08 rbarraud: s and DMA ;-)
14:08 rbarraud: Sounds easy if you say it fast enuf eh :-/
14:09 imirkin: karolherbst: yea, just do YUV 4:2:0 for 8k screens. dunno that YUV444 / RGB even makes sense
14:09 karolherbst: well, I still want HDR400!
14:09 imirkin: YUV420 isn't mutually exclusive with HDR
14:09 rbarraud: imirkin: Thanks, I definitely will. Thanks for thelink :-)
14:09 karolherbst: mhh, right
14:10 rbarraud: I'll also try some zzz's :-)
14:10 rbarraud: Thanks!
14:10 imirkin: rbarraud: perhaps you can combine them, and learn through osmosis!
14:11 rbarraud: Got the pdf after minor SSL key glitch
14:12 rbarraud: I've done a fair amount of embedded video stuff over the years...
14:12 rbarraud: I even have some ARM machine ID's in the kernel...
14:12 imirkin: yeah, so like ... i dunno which level of embedded you're talking about, but if it's "quite" embedded, then a lot of thsee concepts just don't apply to big desktop GPUs
14:12 rbarraud: pity the companies I worked for were too lame to follow thru and there weren't much in the way of upstream platform pathces... :-/
14:13 rbarraud: [More embarassment :-/ ]
14:13 rbarraud: I'm aware of that.
14:13 rbarraud: TFT panels, ARM SoC's etc...
14:13 imirkin: basically on desktop GPUs you have infinite memory
14:13 imirkin: and infinite compute power
14:13 imirkin: and infinite inside-the-gpu bandwidth
14:13 imirkin: so you want to make use of these to your advantage
14:14 rbarraud: Everything's infinite until it's not ;-)
14:14 imirkin: well. a lot more infinite than in embedded
14:14 rbarraud: :-)
14:14 imirkin: where you're counting every byte
14:14 rbarraud: That is true, I can assure you :-)
14:14 rbarraud: 64MB RAM and less...
14:14 rbarraud: 16MB FLASH...
14:14 imirkin: last time nvidia put out a GPU with 64MB was in ... maybe 2005?
14:15 rbarraud: It's surprising what you can do with that still...
14:15 imirkin: and that's VRAM, not total system memmory
14:15 rbarraud: Probably.
14:15 rbarraud: Pity I can;t afford a 3090 with 24GB VRAM
14:15 rbarraud: :-/
14:15 rbarraud: GDDR6*
14:15 imirkin: but you can afford a GT1030
14:15 imirkin: which will still have like 2-4GB of VRAM
14:15 rbarraud: Probably
14:15 rbarraud: or a low end Quadro
14:15 rbarraud: or a 1650
14:16 rbarraud: I'm kinda thinking about a 5600 machine with a decent Radeon or something in it...
14:16 rbarraud: Gotta get an income stream going though
14:17 rbarraud: I do want to futz with ML etc ... just completed watching MIUT 18.065 Linear Algebra with Gil Strang.
14:17 rbarraud: and EE263 Stanford with Stephen Boyd.
14:18 rbarraud: I want me some CFD, FEM and nice graphics to go with them :-)
14:18 rbarraud: But first, some zzzz...
14:18 rbarraud: Thanks again, catch U l8r when I am a bit saner ;-)
14:20 imirkin: heh. in my memory 18.065 was discrete math. perhaps my memory's going though.
14:21 imirkin: oh nevermind. i was thinking of 6.065 or something.
14:21 imirkin: and it was 6.042. wow. yeah, memory's gone.
14:22 imirkin: (woohoo, finally unloaded some of that useless info in my head apparently)
14:23 vsyrjala: and it's the one thing you really supposed to learn from those courses: the course number!
14:23 imirkin: hehe
14:23 rbarraud: imirkin: I definitely agree with the "WTF BBQ" bit ;-)
14:23 imirkin: that's definitely how it felt with some of 'em
14:23 rbarraud: 'nite :-)
14:24 rbarraud: 6.001?? SICP
14:24 rbarraud: The Best! (IMO)
14:25 rbarraud: 6.042 or '43 is good too - is that the Algorithms one with Erik D?
14:25 imirkin: 6.046 is algorithms
14:25 rbarraud: zzz... muuust take eyes of scrreennn
14:25 rbarraud: yeah thats the one
14:42 rbarraud: Thru bleary eyes rbarraud says:
14:43 rbarraud: TO add to the mystery, apparently I have both xorg-drivers-7.7_6 and xf86-video-intel-2.99.917.914,1 installed... so potential for conflict perhaps.
14:43 rbarraud: Admitting defeat now - thanks again, zzzzzz
14:44 rbarraud: Oh, and also both dri and dri-devel...
14:44 rbarraud: <snooore/>
14:59 xexaxo1: imirkin: fwiw the /usr/local/lib/dri-devel//lib/dri-devel is an old mesa/meson bug which got fixed with f6556ec7d126b31da37c08d7cb657250505e01a0
15:02 xexaxo1: based on the lack of ^^ one could suspect that mesa is too old and lacks the correct PCI ID in the table, hence the detection fallout
15:07 xexaxo1: another interesting point is that newer (could be released I don't recall) FreeBSD's have sort of external DRM module (due to licensing) packaged.
15:07 xexaxo1: the the older/internal one is pretty ancient and might as well be before 3.9
15:09 xexaxo1: pardon for poking you like that, you seem to be the fastest person around helping people o/
15:10 jekstrand: bnieuwenhuizen: Did you have any further thoughts on icd JSON versions?
15:10 bnieuwenhuizen: oh if you replied I totally missed it
15:11 jekstrand: bnieuwenhuizen: I'd like to close on that and get !8792 landed
15:15 bnieuwenhuizen: jekstrand: replied
15:19 jekstrand: bnieuwenhuizen: Where is it in meson.build?
15:20 bnieuwenhuizen: that is the bit I commented on no?
15:20 jekstrand: bnieuwenhuizen: Ah. I se now
15:21 bnieuwenhuizen: jekstrand: sounds like it doesn't really need to change but just seeing that in the build file my reaction is "do I need to update that?" :P
15:21 imirkin: xexaxo1: aha ok, will try to remember.
15:26 jekstrand: bnieuwenhuizen: Yeah. I thought about that. It's just the major version number.
15:26 jekstrand: It'll change once every couple of years.
15:27 jekstrand: And I don't have any hot ideas that don't involve stuffing it in python.
15:27 jekstrand: I guess we could add a `-DANV_VULKAN_MAJOR_VERSION` or something
15:32 jekstrand: Or, I guess, `-DANV_VULKAN_MINOR_VERSION`
16:47 jenatali: Is there some kind of metric for what should be considered a release blocker? I'm wondering about https://gitlab.freedesktop.org/mesa/mesa/-/issues/4022#note_789785
16:47 jenatali: Not sure if releases really have meaning for Windows...
16:50 kisak: jenatali: does WSL follow point releases of mesa or is it some arbitrary git commit?
16:50 kisak: if not, then I think it's safe to ignore that.
16:52 jenatali: kisak: WSL uses stock distros, which follow releases. But that's not about WSL, it's about Win32, where I don't think the releases really matter
16:52 jekstrand: cwabbott: Do you know if we have any optimizations to clean up u2u8(iadd(i2i16(u2u8(x)), i2i16(u2u8(x)))?
16:53 imirkin: jenatali: the metric is one of self-preservation. if you're a driver maintainer, you want to make sure that end users don't get buggy stuff that they'll then bother you about.
16:54 jekstrand: cwabbott: I'm tempted to write python to codegen a bunch of opt_algebraic rules but it's going to be a LOT of rules. On the other hand, if I write something by hand it's guaranteed to get swizzles wrong.
16:54 imirkin: codegen for the codegen
16:55 jekstrand: imirkin: nir_opt_algebraic rules have a lot of that sort of thing.
16:55 imirkin: :)
16:55 jekstrand: Having them defined in python means there are lots of loops generating rules.
16:55 jekstrand: It's quite effective
16:55 jenatali: imirkin: That sounds like something we have in our DXIL backend
16:55 imirkin: yeah, we took a somewhat diff approach for nouveau
16:55 jenatali: Oops, meant jekstrand
16:55 imirkin: each rule is "smart"
16:55 imirkin: which has its own problems, of cours.e
16:55 jekstrand: It also means we have about 1500 rules today. :)
16:56 jekstrand: But, thanks to cwabbott's automaton magic, it still runs fast.
16:56 jekstrand: :)
16:56 imirkin: but you have some clever thing for applying them right?
16:56 ccr: "yo dawg, I heard you like code, so we put codegen in your codegen codegen."
16:56 imirkin: yea
16:57 imirkin: the downside of clever rules is that the selection of what to even try is broader
16:57 bnieuwenhuizen: jekstrand: would love to do something about the compile time of the file though :) (also IIRC it is also the biggest entry in .data.rel.ro which has relocations, but may be wrong there)
16:57 jekstrand: bnieuwenhuizen: Yeah....
16:57 jenatali: Yeah, was looking at disk footprint and that file alone contributes 1MB
16:58 jekstrand: I've got a branch somewhere that makes it smaller
16:58 jekstrand: And maybe fewer relocations.
16:58 cwabbott: eons ago, I had a branch to compress some of the automaton data too
16:58 cwabbott: 99% of it is the filter tables which are mostly 0
16:58 jenatali: Yeah
16:58 cwabbott: but iirc it made compile time slightly (but just measurably) slower
16:58 jekstrand: We should just zstd compress it. :)
16:58 imirkin: cwabbott: which compression did you do?
16:59 imirkin: there are some very cpu-friendly compressors
16:59 imirkin: which aren't as good at compressing, but still good at reducing the everyhting-is-0's case
16:59 cwabbott: imirkin: it was very cpu-friendly
16:59 imirkin: cool
17:00 jekstrand:generates opt_algebraic rules...
17:00 cwabbott: it was just a mask of which N entries were zero
17:00 imirkin: oh, so you made a custom thing which was purpose-driven, ok
17:00 cwabbott: yeah
17:01 imirkin: just making sure you weren't doing xz -9 ;)
17:01 imirkin: and then wondering where the days went
17:01 cwabbott: i was doing decompression on the fly though
17:01 cwabbott: although "decompression" was just a single bitscan instruction iirc
17:02 cwabbott: and that had a measurable impact
17:02 cwabbott: that loop is really, really hot...
17:02 cwabbott: *bitcount instruction
17:02 imirkin: and bitcount op isn't super-fast i suspect...
17:03 imirkin: when you get to that level, it's crazy what things are faster/slower. often not what you expect.
17:03 bnieuwenhuizen: might be better with memory access hopefully :)
17:03 bnieuwenhuizen: (smaller cache footprint)
17:04 cwabbott: that's what i was hoping for, but the compile times didn't bear that out iirc
17:04 bnieuwenhuizen: :(
17:04 cwabbott: the strategy was to divide the array into roughly 32 pieces, and have a bitmask of which pieces were 0
17:05 cwabbott: and throwaway pieces that were all 0
17:06 cwabbott: this was a long time ago though
17:17 imirkin: how does one refer to a gitlab issue in a commit (without closing it)?
17:17 imirkin: looking for like a "See: issue 1234" sort of a thing
17:17 emersion: i use the full URL
17:17 emersion: References: <url>
17:17 imirkin: ok thanks
17:17 emersion: that way it's clickable
17:18 imirkin: will do
17:18 emersion: note that marge uses the format Part-of: <url>
17:19 emersion: but i have no idea whether mesa specifically has a different preference for this
17:20 imirkin: meh
17:20 imirkin: mesa is not a single person
17:20 emersion: i guess also common is
17:20 emersion: [1]: <url>
17:20 imirkin: i like the references thing
17:20 emersion: and then use [1] in the commit message
17:20 emersion: i also use
17:20 emersion: Closes: <url>
17:20 emersion: quite often
17:20 imirkin: right. but i don't want closes.
17:20 imirkin: i knew about that one
17:51 xexaxo1: jenatali: from prior experience (re release blockers) adding one is fine, as long as one is actively working on it to resolve ASAP
17:52 xexaxo1: eons ago, we had cases where blockers were added where nobody was looking at addressing them :-\
17:53 jenatali: Makes sense - I've got a patch out for that one now, but I'm still not convinced it needs to the release blocker tag
17:54 jenatali: Maybe I'm just holding myself to too high of a bar though, used to the policies we use for Windows :P
17:59 xexaxo1: Another note, release notes explicitly mention - people concerned with stability - stick with previous (non .0 release) or wait for .1
18:01 xexaxo1: Aka don't stress/kill yourself trying to fix everything for .0 << has always been my interpretation.
18:13 ddevault: re: email skeptics: here's an account from another skeptic who eventually came around: https://blog.brixit.nl/git-email-flow-versus-github-flow/
18:13 imirkin:likes email
18:15 dcbaker: Yeah, we know there will still be some corner cases with .0
18:16 dcbaker: That's why the previous stable branch has overlapping releases
18:16 xexaxo1: Precisely. That's why I love the explicit mention at the top of the release notes.
18:17 imirkin: don't want to have anything TOO bad in the .0 though
18:17 HdkR: "It gets slightly more annoying after the first pull request because you actually have to keep your own local branch up to date." Who says you need to keep your local branch up to date? I never do that =o
18:17 dcbaker: gitlab has a feature github doesn't which is "click here to rebase"
18:17 dcbaker: that's a huge pain in the butt on github
18:18 hifi: also to be fair the "github way" could be improved a lot by being able to push your local branch to github without forking directly as a pull request
18:18 ddevault: the words of someone who often annoys maintainers with unmergable MRs
18:18 hifi: it really is slightly stupid you are forced to create a fork
18:18 ddevault: github's workflow is mainly designed to keep you on github
18:18 ddevault: and gitlab's workflow is designed to cargo cult github
18:18 imirkin: i dislike the walled gardens =/
18:18 imirkin: email is the great equalizer
18:19 hifi: git inside a walled garden doesn't take much away from git itself, though
18:19 imirkin: this isn't about git
18:19 ddevault: code review is a thing which contains information and information exchange
18:19 ddevault: which can be stored in and transmitted with open standards, or not
18:20 ddevault: projects which move from mailman to sr.ht can bring with them their entire history of discussions, patches, and code review
18:20 ddevault: anyone who moved from lists.fd.o to gitlab.fd.o lost that
18:21 tango_: obviously the correct solution to the mail vs gh/gl workflow is to provide an smtp backend in gh/gl that allows the email workflow
18:21 hifi: you could say the same in reverse
18:21 hifi: and no one is happy because there will be things lost in translation
18:21 ddevault: no, you can't really say the reverse
18:22 ddevault: projects pushing proprietary, non-standard protocols should be expected to interop with those which use standard, open protocols
18:22 ddevault: not the reverse. definitely not the reverse.
18:22 tango_: and also mail to gh is lossless
18:22 dcbaker: Did you just suggest that email is standard? hahahahahahahahahahahahahahahahahahahahahahahahahahaha
18:22 hifi: you are comparing a workflow to a proprietary platform
18:22 dcbaker: email is apile of hacks on hacks on hacks on hacks on hacks
18:22 ddevault: standard hacks
18:22 dcbaker: I'm not saying github/gitlab is perfect
18:23 dcbaker: have you ever worked on email software? I have
18:23 ddevault: standard hacks implemented by a huge collection of free software
18:23 ddevault: yes. yes I have.
18:24 hifi: I don't think anyone here is suggesting that github itself is a solution to all problems or that the workflow it implies is the best workflow
18:25 hifi: it just defined *a* workflow that works for more people than the mailing list workflow
18:25 ddevault: *that more people are familiar with
18:25 dcbaker: as a concept
18:27 hifi: it took years to get people even grasp the concept of git even remotely with a centralized workflow
18:27 imirkin: it's one of these unfortunate situations where people end up being split on it being a really good idea vs a really bad idea. few people are in the middle.
18:27 dcbaker: I'm not saying github and gitlab are perrfect, they're cretinaly not
18:27 dcbaker: but email itself is a dumpster fire
18:27 hifi: well put
18:28 emersion: email can be sane. most email software isn't, but that can be fixed.
18:28 hifi: it should be conceptually possible to create an alternative workflow using open standards that doesn't rely on email
18:28 imirkin: i hate walled gardens. i like email. but i also can't negate the fact that lots of people use facebook, the definition of walled gardens.
18:28 imirkin: and github/gitlab/etc are just an extension of that
18:29 dcbaker: No, sorry, no. I wasted enough of my life working on email software to realize the best thing we could do is start over. email is not salvagable
18:29 emersion:maintains quite a few email-related libraries
18:30 dcbaker: you simply cant solve the problems that "be liberal in what you accept" did to email
18:30 ddevault:maintains quite a few email-related softwares
18:30 ddevault: I have good news for you, dcbaker: you don't have to write any email code to use email in your workflow
18:31 dcbaker: well, unless I move to linux kernel I can't imagine going back
18:32 dcbaker: I know you love email based work flows and I'm not going to change your mind
18:32 dcbaker: but I also remember wasting countless hours trying to explain why you can't use html email
18:32 dcbaker: why you don't top post
18:32 dcbaker: how to set up git-send-email
18:32 vsyrjala: personally i wouldn't mind losing the bad parts the about email workflow (rotting smtp infrastructure, issues with parsing mails, etc.). but i would like to keep the good parts (command line workflow, real text editors for code review, etc.) instead of being force fed this horribly designed and bloated web ui
18:33 dcbaker: this
18:33 xexaxo1: vsyrjala: perfectly said, imho
18:33 dcbaker: though I don't mind the web ui
18:33 dcbaker: but it's email not command line workflow I hate
18:34 vsyrjala: half the time i can't even find the right button to click on gitlab to see what i want
18:34 ddevault: dcbaker: https://git-send-email.io
18:34 ddevault: also, even if you write off users not grokking email conventions
18:34 ddevault: we can write web UIs which *do* grok email conventions, and which translates the gitlab-style web workflow into emails on mailing lists
18:35 ddevault: and, believe it or not, new contributors make mistakes with gitlab *all the time*
18:35 ddevault: mentoring them is part of our job as maintainers
18:35 raster: vsyrjala: btw - on vblank timestamp. i5-4200U -> no time going backwards problems. i7-8xxxu though... (can't remember exactly) ... it has issues. i'm chasing the drm code now for where intel is getting timestamps from. i'm down to drm_crtc_vblank_helper_get_vblank_timestamp_internal().
18:38 dcbaker: ddevault: I think we're at an impasse, I think git over email is part of the past, you clearly love it. I think we're just going to have to agree to disagree on this one
18:38 ddevault: that's just "old == bad" in more words
18:38 ddevault: suit yourself.
18:38 emersion: here's the thing: if someone can offer you something as good as gitlab but backed by email, would you still reject it?
18:42 dcbaker: vsyrjala summed up my opinion well. the problem isn't command line, real text editors, etc. It's email. Write something *like* git-send-email that's super easy to set up and work with, sure I'd use that
18:42 dcbaker: but I also dont' like gerrit
18:42 FLHerne: vsyrjala: gitlab has a nice API, it just needs someone™ to write a good CLI client
18:42 dcbaker: because the UI is so terrible
18:42 ddevault: ugh. email is fine.
18:42 dcbaker: that's where we disgreee I guess
18:42 ddevault: if you simply cannot stand the idea that you may have to write your SMTP credentials into a config file
18:43 ddevault: then we're never going to comprimise
18:43 dcbaker: that's not the limits of it
18:43 vsyrjala: FLHerne: i tried to use it to at least give me a way to get a full list of the bugs for i915, without having to load 20 at a time via the web ui. but the api still limited me to 100 at a time, and it was still glacial
18:43 vsyrjala: i wonder if the backend db is based on punch cards
18:43 dcbaker: it's that email doesn't have standard encodings, or even how to tell someone what your encoding is
18:43 dcbaker: how messages are formatted, and how you pack the payload is non-standard
18:44 dcbaker: etc
18:44 emersion: have you really worked with email standards?
18:44 dcbaker: working on an email client really changed my views about email
18:44 emersion: or do you mean, email doesn't have one and only encoding/charset?
18:45 emersion: because you *can* tell someone what your encoding is
18:45 dcbaker: the number of emails I've sent with utf-8 in them that I get back "your email doesn't load" or people sending me emails in the windows encoding (I can never rmember the name) that don't render correctly is non-zero
18:45 dcbaker: that's a huge problem
18:45 dcbaker: since outlook insists on using the windows encoding
18:45 dcbaker: and I'd really like to send utf-8
18:45 imirkin: emersion: but the client indicates one encoding, but secretly uses another. very annoying.
18:45 emersion: so the problem with email is outlook?
18:45 imirkin: like it'll say latin-1 but actually use latin-15
18:46 imirkin: or gb<something> but actually gb<something newer>
18:46 imirkin: to try to be compatible with clients that don't know about the newer encoding
18:46 dcbaker: or it says nothing and assumes windows-1251 instead of acii
18:46 imirkin: that was a fun debugging session :)
18:46 dcbaker: which is what outlook does
18:47 emersion: "outlook bad" isn't news to me
18:47 ddevault: contributors to mesa and users of outlook are mutually exclusive groups
18:47 ddevault: anyway, the existence of bad clients for a standard does not make the standard bad
18:47 vsyrjala: raster: all hsw+ should use the same code there, so a bit surprising there would a difference. unless you're dealing with crazy broken stuff like dsi displays
18:47 imirkin: ddevault: not anymore! microsoft is pitching in now, for reasons which are still not 100% clear to me
18:47 ddevault: well whadya know
18:48 ddevault: anyway, point stands: @microsoft.com doesn't excuse you for using broken clients
18:48 ddevault: not email's fault
18:48 raster: vsyrjala: yeah. i'm reading it now. i see how it takes a a guess on the timestamp with delta_ns = div_s64(1000000LL * (vpos * mode->crtc_htotal + hpos),mode->crtc_clock);
18:49 raster: it's shared code at any rate. i'm kind of at the point of "time to printk some of these things including etime passed into *vblank_time = ktime_sub_ns(etime, delta_ns); and see what is going on"
18:52 raster: but given what i read i can only imagine somehow get_scanout_position() reads in some junk for something or well something that jitters? like the vpos/hpos coming from hw regs?
18:52 imirkin: something about opencl on top of dx12? something like that.
18:52 imirkin: (for all i know those folk don't actually use outlook, who knows what all has changed internally)
18:53 daniels: ddevault: 'contributors to mesa and users of outlook are mutually exclusive groups' is objectively untrue
18:53 ddevault: so we discovered, daniels
18:53 daniels: but not just that
18:54 daniels: last I looked, before gitlab.fd.o was really a thing, >70% of fd.o's outbound SMTP delivery was to either Google or Microsoft MXes
18:54 bnieuwenhuizen: (side note, gmail web interface is pretty common probably and just as bad in practice for sending patches if you don't use git-send-email)
18:54 daniels: so like we can say that email is perfect but everyone just needs to change our software, but then we're also setting fire to the vast majority of our community in doing so
18:54 vsyrjala: raster: i guess wouldn't hurt to confirm the stuff coming from clock_monotonic is sane in the first place
18:55 daniels: and that's a community which is already hugely weird and tilted _away_ from GMail / G Suite / Office365
18:56 imirkin: fwiw i think gmail is like the only correct email client to use
18:56 imirkin: the threading strategy it uses is superior to everything else i've seen
18:57 imirkin: and auto-collapsing
18:57 ddevault: I don't like the answer that "google and microsoft are popular bullies so we shall quietly succumb to their rule"
18:57 imirkin: i realize there's plenty of personal choice in that though
18:57 raster: vsyrjala: i'll get a custom built kernel on that laptop and see but it seems to be related to particular generations or revisions of hardware - it's not "all intel gpus do this".
18:57 ddevault: in fact, rejecting that answer is kind of the point of FOSS
18:58 vsyrjala: raster: do you have a simple test case i could try? just ran a few kms_flip ts tests on my cfl and at least that isn't complaining
18:58 imirkin: ddevault: mesa is largely a commercial project these days
18:59 raster: vsyrjala: not a simple one unfortunately... like a whole wm/compositor + toolkit :)
18:59 raster: (though if you are on arch linux it's a trivial AUR build...)
19:00 karolherbst: ddevault: "contributors to mesa and users of outlook are mutually exclusive groups" ehh.. no?
19:00 raster: it may also be your hw just doesn't exhibit the issue.
19:00 ddevault: it was a joke, forget it
19:01 karolherbst: :p
19:03 FLHerne: You can't really have it both ways -- email is ubiquitous and everyone knows how to use it and has it set up, but "email without Gmail, Outlook and every other client or server that does something wrong" isn't at all
19:03 ddevault: >email is ubiquitous and everyone knows how to use it and has it set up
19:03 ddevault: strawman
19:03 ddevault: never said that
19:04 karolherbst: also, not everyone knows how to set up emails :p
19:06 jenatali: imirkin: GL/CL layered on D3D lets us simplify our overall driver stack and increase the number of platforms where we have hardware support for those APIs, yeah
19:06 imirkin: jenatali: GL as well?
19:06 jenatali: Yep
19:06 imirkin: cool. will keep that in mind.
19:06 imirkin: jenatali: only on top of DX12 right? or also DX11?
19:07 jenatali: imirkin: Yeah just a d3d12 backend, not 11
19:07 imirkin: (and sorry for using the wrong acronyms ... i guess DX includes more than just D3D)
19:07 jenatali: GL's the main reason we decided to go for Mesa at all - we probably could've picked something a bit more standalone if we were just interested in CL, but IMO there's no viable alternative to bring up a new GL driver
19:08 jenatali: Eh they're basically the same these days, but yeah D3D is a bit more accurate
19:08 imirkin: yeah, GL's pretty annoying to implement
19:08 karolherbst: especially if you want to implement it driver agnostic
19:08 karolherbst: *vendor
19:09 bnieuwenhuizen: second place would be trying to extend angle to GL?
19:09 vsyrjala: raster: running gentoo on that box. looks like efl-1.25.1 and e-0.24.2 are packaged. dunno if that's good enough
19:09 daniels: ddevault: sure, but my ideology is based around enabling successful and impactful open-source projects which deliver meaningfully open (in code as well as process) software into the hands of as many users as possible. tilting at the SMTP windmill doesn't help me achieve that ...
19:10 daniels: the realistic result of that happening for a long time is that systemd and flatpak and a lot of other projects just walked off to GitHub, with many others, and a lot of them were on the point of following
19:10 karolherbst: I am actually wondering when we will have this "user without email" shift
19:10 jenatali: bnieuwenhuizen: Yeah that was something we talked about too, but seems like a lot more work, and ANGLE still only has a D3D11 backend, not 12 which is what we wanted here
19:10 karolherbst: 5 years?
19:10 karolherbst: 2 years?
19:10 karolherbst: can't be that long anymore
19:10 ddevault: daniels: emersion and I are tilling at that windmill so you don't have to
19:10 ddevault: just don't get in our way, eh?
19:10 daniels: I didn't think I was
19:11 ddevault: I didn't say you were
19:11 karolherbst: the future is to plan without email :p
19:11 daniels: :)
19:11 bnieuwenhuizen: karolherbst: they will have email due to their google account for the android phone
19:11 dcbaker: karolherbst: well, since apple, google, and microsoft all give you email for signing up with them... never?
19:11 daniels: jenatali: you mean that Clover wasn't the deciding factor?
19:11 raster: vsyrjala: i added the debug EEEKS to git master efl though.
19:11 karolherbst: if you say so :p
19:11 jenatali: daniels: I mean, the fact that Clover exists meant that there was precedent for using Mesa to do CL, so that helped :)
19:11 raster: but basically just use your desktop for liek 10-15 mins and i get a streap of EEEKs :)
19:11 daniels: jenatali: a kind answer
19:11 karolherbst: :D
19:12 karolherbst: very diplomatic
19:12 jenatali: I try ;)
19:12 raster: vsyrjala: if yhou have an ebuild for git efl you'll get the EEEK detects to stderr.
19:12 karolherbst: jenatali: ohh btw, I have a WIP branch where I tried to use rust within mesa to implement CL :D
19:12 dcbaker: I honestly expect that google, apple, and microsft will come up with a replacement for email and just start using that under the hood
19:12 dcbaker: much like sms vs rcs vs imessage
19:12 karolherbst: dcbaker: exactly
19:13 jenatali: karolherbst: Yeah I saw that a while ago. And after I saw that I learned rust (at least somewhat) but haven't gone back to re-read your branch
19:13 karolherbst: yeah..
19:13 imirkin: dcbaker: oh, is that the thing where people stop being able to send you sms's when you stop using apple?
19:13 karolherbst: I need to start from scratch anyway :D
19:13 vsyrjala: raster: doesn't look like there is one. i guess i could build by hand. how hard can it be? :P
19:13 karolherbst: still waiting until all the bindgen and other meson bits land
19:13 karolherbst: and redo it then
19:13 jekstrand:🍿
19:13 dcbaker: imirkin: well, I use android so I'm the one that ruins everyones good time, lol
19:14 raster: vsyrjala: the build for git is itentical for for a release so you could adapt the 1.24 ebuild....
19:14 imirkin: dcbaker: dunno if it's still a thing, but basically they would link your phone number to your iwhatever account
19:14 karolherbst: jekstrand: you missed a lot btw :D
19:14 raster: both meson ... :)
19:14 jenatali: karolherbst: Apparently there's a bunch of people inside Microsoft that are really excited about Rust and pushing more of it into our products, so I see it as just a matter of time before it's everywhere
19:14 jekstrand: karolherbst: I've skimmed the back-log
19:14 karolherbst: I am sure you have like 8 hours of backlog to read up on
19:14 imirkin: and then there was no way to unlink them
19:14 karolherbst: :D
19:14 karolherbst: jenatali: cool
19:14 cmarcelo: karolherbst: what branch? (-:
19:14 karolherbst: cmarcelo: https://gitlab.freedesktop.org/karolherbst/mesa/-/commits/rusticl
19:14 dcbaker: imirkin: yeah, my family sends each other imessages,then when I join it's mms for everyone. I get rcs, which is the thing everyone *except* apple is using
19:14 imirkin: so other iphone users would end up using imessage or whatefver to send to you (transparently to them), and so you would just never get those
19:15 jenatali: dcbaker: I can empathize with that :P
19:15 dcbaker: I personally use signal whenever possible (and have for a long time)
19:15 dcbaker: but trying to convince people to do that was hard
19:15 dcbaker: until recenetly
19:15 karolherbst: yeah
19:15 dcbaker: karolherbst: I think the bindgen wrapper in meson is going to land for 0.57, btw
19:15 imirkin: i've hard-refused to use skype, whatsapp, telesomething, etc
19:16 karolherbst: but IM is superior over emails, because you can send 1GB files relibaly over it :p
19:16 imirkin: maybe signal could be ok
19:16 karolherbst: dcbaker: cool
19:16 dcbaker: if I can just figure out why one of our CI images is failing to build
19:16 karolherbst: try sending 1GB files via email
19:16 karolherbst: good luck
19:16 jekstrand: RE "e-mail standards": Anything which requires humans to type text which does not get syntax-checked by a computer is not a standard.
19:16 dcbaker: karolherbst: lol
19:16 dcbaker: I did that once
19:16 dcbaker: once
19:16 karolherbst: :D
19:16 dcbaker: ☹️
19:16 karolherbst: and decided I never send files bigger than 10MB again via email? :D
19:17 dcbaker: lol yes
19:17 jenatali: Or executables...
19:17 dcbaker: mostly decided not to send anything that wasn't text or pdf again...
19:17 karolherbst: encrypted archives :p
19:17 dcbaker: lololol
19:17 jenatali: Yep, that's the only solution we've found
19:17 karolherbst: "but email is great" :p
19:17 dcbaker: shell scripts are my favorite
19:17 dcbaker: outlook says "shell script, no!"
19:17 karolherbst: just call it .txt
19:17 bnieuwenhuizen: I thought every email provider now also provides cloud storage (:
19:18 imirkin: gmail prompts you when you try to attach something large
19:18 karolherbst: bnieuwenhuizen: you mean you weren't aware of the users with 100MB mailboxes?
19:18 imirkin: and/or refuses
19:18 imirkin: i forget
19:18 bnieuwenhuizen: karolherbst: I mean the various dropbox like stuff that every large provider has too
19:18 karolherbst: I know
19:18 karolherbst: but yeah.. not every provider has that I think
19:18 bnieuwenhuizen: yes, well, the world moves on
19:19 karolherbst: right, and it will ditch email asap
19:20 ccr: I, for one, welcome our new Facebook-based development platforms!
19:20 karolherbst: if you get a proper internet connection, sending an 1GB file via IM is faster than writing a text email :p
19:20 daniels: dcbaker: PDFs make me sad because of the Poppler Bugzilla attachments containing crasher reproducers, which are now flagged as malware by everyone's favourite search engine
19:21 karolherbst: daniels: haha :D right
19:21 karolherbst: well, technically it doses your browser
19:21 daniels: (LibreOffice source archives on cgit were also frequently marked as malware for quite a long time, on which I am making no judgement)
19:21 daniels: it hasn't DoSed anyone's browser since like 2008 when it was fixed :P
19:21 karolherbst: :D
19:21 karolherbst: true
19:21 karolherbst: but I am sure to remove the hashes you have to file a paper form and fax it
19:22 karolherbst: dcbaker: the other issue is what do to with external crates :/
19:22 karolherbst: there are quite some good and useful ones :/
19:23 dcbaker: oh, I have a branch
19:23 karolherbst: sure, but I meant more the packaging perspective
19:23 dcbaker: I can almost get clap to build as a subproject
19:23 dcbaker: yeah, that's a hard one
19:23 dcbaker: becasue it probbalby requires changes from upstream cargo as well
19:23 karolherbst: or we just ignore it and let distributions deal with it.. dunno
19:23 karolherbst: yeah.. my hope is, that distributions already have workarounds in place
19:24 karolherbst: like fedora actually packages bindgen as well
19:24 dcbaker: I think it's easy to deal with binaries like bindgen
19:24 dcbaker: but what do distros want to do about libraries?
19:24 karolherbst: well, it also has deps
19:24 karolherbst: let's see
19:25 karolherbst: ohh wait
19:25 dcbaker: that might be a good question for ajax or mattst88 what distros want to do about rust
19:25 karolherbst: I think fedora didn't packge it, but debian
19:26 dcbaker: debian does, arch does
19:26 dcbaker: I konw that from looking at CI
19:28 karolherbst: but bindgen does depend on rust libs or do they handle it in a magic way?
19:29 karolherbst: mhh..
19:30 daniels: karolherbst: just look at who's shipped any version of librsvg from the last 2-ish years
19:31 karolherbst: :D
19:31 karolherbst: why librsvg?
19:33 ccr: it was C, was rewritten in Rust
19:34 imirkin: looking in from the outside, but it seems like rust is wildly anti-hermetic...
19:34 vsyrjala:grumbles about i686==sse2 according to rust
19:35 imirkin: my previous box was a k7 which didn't have sse2
19:35 imirkin: had to build chrome by hand on that one, which ... was not very fast
19:35 imirkin: (mind you, this was 10 years ago)
19:36 jekstrand:wants 32-bit to die
19:36 vsyrjala: i still have p3 w/o sse2. had to mask librsvg update on that one
19:37 vsyrjala: i forget it p4 always has sse2. still have those too
19:37 karolherbst: jekstrand: +1
19:37 imirkin: i think there's some silly one which doesn't, but like 99% do
19:41 imirkin: or maybe i'm thinking of silly exceptions to sse4 being a thing... i forget
19:42 imirkin: definitely x86_64 implies sse2
19:42 dcbaker: I had a p4 without SSE4
19:42 dcbaker: it was one of the ones that could use DDR or RAMBUS
19:42 imirkin: so if there are exceptions to be had, i'd look at the non-x86_64 p4's for those
19:42 imirkin: lol. rambus.
19:42 dcbaker: I had ddr
19:43 dcbaker: I got talked out of rambus, which in retrospect was a very good call, lol
19:44 airlied:declares scrolback bankruptcy on last night
19:44 dcbaker: airlied: with your distro hat on, how do you feel about cargo dependencies in mesa?
19:44 dcbaker: karolherbst: ^
19:45 karolherbst: "make it work" :p
19:45 vsyrjala: raster: i got englightenment master running. anything specific i should run on it?
19:46 jekstrand: airlied: But the scrollback is so entertaining!
19:46 raster: vsyrjala: well i just yuse it
19:46 raster: focus windows, move things around
19:46 raster: etc. etc.
19:46 raster: do things. type in irc...
19:46 anholt: for chromeos there's some magic cargo wrapping to point things to the installed rust libs, but I think we'll be fine with it.
19:46 raster: cpufreq and other thigns will jump and and down and drive animation as you go...
19:47 raster: just tail -f your stderr from e and grep for EEEK
19:47 raster: :)
19:47 dcbaker: anholt: I almost have clap building as a sub-project in meson with my branch
19:47 dcbaker: just need to finish sorting out cfg() parsing
19:48 dcbaker: so it may be possible in some cases soonish
19:48 dcbaker: meson release is the 7th, so not this release, but maybe the next one?
19:48 imirkin: dcbaker: hey, so when do you plan on doing the mesa release?
19:48 imirkin: i want to update something in my commit first, want to know how much time i have
19:49 dcbaker: soon
19:49 imirkin: in units of time, if possible?
19:49 dcbaker: I'll be doing rc4 soon
19:49 dcbaker: I've already started
19:49 imirkin: oh, so it's too late?
19:49 dcbaker: usually I try to cut off commits for releases the day before so they have time to run through all of the CIs and I can fix any bugs before the release
19:50 airlied: so rsvg bundles all the rust deps in their tarball relesaes
19:50 airlied: do that :)
19:50 dcbaker: cool, that's currently how my branch works
19:50 dcbaker: lol
19:50 dcbaker: because `cargo vendor` is easy
19:50 dcbaker: some of the gnome people want to be able to do fancier things
19:50 imirkin: dcbaker: ah ok, then i won't bother rushing
19:50 dcbaker: but I think I'll let them figure that out
19:51 airlied: dcbaker: the only rule distros normally have is builders can't access the internet
19:51 dcbaker: I know debian can be finicky about vendored things
19:51 airlied: but I don't think we have a good answer for rust in how to make anything works in light of that rule
19:51 airlied: fedora is finicky as well
19:51 airlied: but rust doesn't really give you any other way
19:52 dcbaker: I learn all I know from LWN :)
19:52 dcbaker: I mean, with meson + cargo I'm not actually calling cargo, I'm parsing the toml and generating meson ast on the fly
19:52 dcbaker: which is how cmake works in meson as well
19:52 dcbaker: so I can have meson look for pkg-config if that's what you wanted to do
19:52 airlied: dcbaker: though I'm not sure how we could build from git snapshots if there is ever a need
19:52 airlied: but currently we mostly build mesa from releases only
19:53 dcbaker: yeah... the gnome people want to be able to use meson's wrap functionality for fetching them on the fly
19:53 dcbaker: that would solve 90% of the build from git problem I guess
19:53 dcbaker: just not distros building from git
19:53 airlied: yeah just not useful for the distro end
19:54 dcbaker: I feel your pain though, rust is very different than C/C++ in a ton of ways
19:55 dcbaker: it's painful for meson too
19:55 dcbaker: lots of bugs, lots of assumptions that don't hold up
19:55 dcbaker: I've poked at zig a bit too, and it has many of the same problems
19:55 airlied: I'd also suggest we try and limit how many things mesa decides to pull in from crates
19:55 airlied: but I'm guessing once we open the floddgates it'll get nuts
19:56 jekstrand: Likely
19:56 dcbaker: yeah
19:56 jekstrand: You need crates for even some pretty basic things. :-(
19:56 cmarcelo: I think this support is both a blessing (for meson and mesa) and a "curse" (for mesa). meson needs some solution, that's great. code reuse easier in mesa, that's great. but rust ecossystem has a bias toward "a lot of libraries", I just hope if we ever go rust way, we don't have like a tree of 10s of dependencies to deal with.
19:57 dcbaker: yeah, I really wish rust would take a leaf out of python's book. Python has lots of problems, but the standard library is so dang good that it makes up for a lot of it
20:12 jenatali: With the limited use of Rust in Windows so far we've already got quite a handful of crates vendored in, and I can only imagine it growing a lot over time
20:23 robclark: airlied, danvet: speaking of how git-over-email workflow, has anyone brought up the idea of individual drm drivers switching to gitlab workflow and how that might work? Presumably in the end that would translate into normal email based pull-req
20:25 robclark: heh, ok, I guess that scared danvet off :-P
20:26 bnieuwenhuizen: gitlab for msm?
20:26 robclark: well, it's only a crazy thought atm, but it would be nice
20:27 robclark: (there might be other non-technical hurdles.. like qcom folks pushing to same gitlab which also hosts mesa.. so not sure how practical it would be)
20:27 bnieuwenhuizen: no idea how that'd work process wise, but looking forward to some of the mesa gitlab niceties coming to kernel land
20:28 robclark: but would be a nicer way to (a) make sure things don't fall thru cracks and (b) not deal with patches that are based on some random other patches/branch
20:28 robclark: and maybe even hooking in CI.. that would be the cherry on top
20:38 airlied: robclark: nouveau is looking into a bit at the moment
20:38 robclark: oh, cool
20:39 airlied: but we'd like to avoid any driver specific processes from sneaking if we do move to gitlab workflow as an alternate
20:40 airlied: "sneaking in"
20:40 airlied: if you do move to gitlab, I'd advise not getting too comfortable with any workflow as they'll be pushes to converge
20:40 robclark: fair, that is kinda part of why I'd wondered about whether someone else had started thinking about this
20:41 airlied: danvet also knows a bit when he hasn't ran away :-P
20:41 zmike: what determines whether glsl compiler uses memory_barrier_atomic_counter or control_barrier?
20:41 karolherbst: airlied: yeah.. not really on planning to add any CI stuff, just to move to gitlab of the main mean of adding patches/mrs or so
20:41 robclark: I'm *kinda* suspecting it would involve creating a new -next branch each cycle, but not sure how that would work with linux-next.. and those sort of "small" details
20:42 jekstrand: zmike: The GLSL intrinsic called
20:42 karolherbst: or mayber rather as an "additional" thing? dunno
20:42 karolherbst: should talk with ben about it
20:42 airlied: karolherbst: CI is more interesting aspect or gitlab for me :-P
20:42 zmike: jekstrand: I'm running the same test with zink+anv and zink+nvidia and in the latter I get the atomic barrier somehow
20:42 karolherbst: airlied: right
20:42 airlied: I can start to trust that MRs I get are built on arm32 :-P
20:42 zmike: so I assume this is some shader pipe cap or something
20:42 jekstrand: zmike: Uh...
20:42 karolherbst: airlied: ohh, sure, build stuff could be added quite easily
20:43 zmike: jekstrand: yea that was my reaction
20:43 jekstrand: zmike: Coming out of glsl_to_nir, it's whatever was in the GLSL.
20:43 jekstrand: zmike: There may be a lowering pass somewhere that shuffles stuff around.
20:43 karolherbst: airlied: I have an idea... people MR against drm/drm and we CI there :p
20:43 zmike: I checked gdb and the atomic barrier case is never hit in glsl with anv
20:43 jekstrand: zmike: NIR_PRINT=1?
20:43 zmike: yup, that's how I know there's a difference :)
20:43 zmike: the first time I see the shader output the barrier is different
20:44 zmike: so it seems to me that the glsl compiler is somehow getting different ir
20:45 zmike: piglit/tests/spec/arb_compute_shader/execution/simple-barrier-atomics.shader_test
20:46 zmike: or...actually it's subtly different than that, the nvidia case just has an extra atomic barrier
20:46 agd5f: tzimmermann, what's the best way to implement unmappable drm client buffers for fbdev emulation? I want to do something similar for amdgpu
20:46 jekstrand: zmike: That's weird...
20:46 zmike: yep
20:47 zmike: I wonder...could this be like native hw atomic counter support vs none?
20:47 jekstrand: zmike: Congrats! I have just as much of a clue on this one as you do. Go fish!
20:47 zmike: hahaha
20:53 airlied: zmike: what app?
20:53 zmike: shader_runner with the file^
20:54 airlied: zmike: ah cool so not some app detecting nvidia
20:54 zmike: probably not?
20:54 zmike: trying to figure out how it's getting into the ir now...
22:52 Kayden: hmm, so...u_threaded_context's "do transfer map in the TC thread directly, not the driver thread" doesn't work for iris in a bunch of cases
22:53 Kayden: the main thing is...if our resource has color compression enabled, we have to resolve that before CPU mapping it. Resolving emits GPU commands. which...the TC thread isn't able to do safely.
22:54 Kayden: I'm not seeing a great way to communicate that
22:55 imirkin: Kayden: how do you deal with this under normal circumstances?
22:55 imirkin: e.g. thread 1 / context 1 creates resource, renders/etc
22:55 imirkin: thread 2 / context 2 tries to map the resource
22:58 bnieuwenhuizen: Kayden: I suspect radeonsi needs to do something similar for DCC compressed images
22:58 Kayden: Yeah, I would think so too...maybe that's what the use_forced_staging_uploads stuff is for? But I suspect the intel stuff is more complex :/
22:59 bnieuwenhuizen: how so?
23:01 Kayden: imirkin: there's always a synchronization problem in there...the app needs to synchronize between the two contexts. there, context 2 would queue up GPU commands to do the resolve, then wait for them, and do the map.
23:02 imirkin: Kayden: so why can't you do that with u_threaded_context?
23:02 Kayden: imirkin: but with u_threaded_context, it gets fundamentally unsafe - two threads try to access the same GPU command building infrastructure in the same context
23:02 imirkin: oh, it doesn't have its own "native" context?
23:02 Kayden: imirkin: correct. u_tc limits some hooks to not access the context
23:02 imirkin: i see
23:02 Kayden: and just says "it's fine, I can do this in a different thread"
23:03 imirkin: [and yes, i agree on the "fundamental" sync issue for the user who does this, so you have to assume they know what they're doing]
23:03 Kayden: bnieuwenhuizen: not sure. maybe it isn't
23:03 Kayden: our compression tracking stuff just seems to be more complex in general than radeon or NV
23:03 imirkin: i mean, generically, mapping a resource will require emitting GPU commands
23:03 imirkin: pretty much no matter what you do
23:04 imirkin: unless you're on a UMA system which doesn't have any funny business.
23:08 mareko: Kayden: transfer_map from the frontend thread is for unsynchroinzed buffer mappings only
23:09 mareko: Kayden: use_forced_staging_uploads is an optimization for invisible VRAM
23:10 mareko: Kayden: you can just ask me questions directly
23:11 mareko: Kayden: I don't think your compression tracking is more complex, ours is pretty ugly too
23:11 imirkin: Kayden: the only reason it's simple with nouveau is because we don't really do it :)
23:12 imirkin: there's these crazy zcull surfaces which we never quite worked out
23:19 Kayden: mareko: thanks!
23:20 Kayden: mareko: have you looked at helgrind much with u_t_c? I'm seeing a lot of potential issues there, and I think some are real, and some aren't
23:23 mareko: Kayden: there are a few minor things where we don't lock but also are OK with race conditions because they are harmless
23:38 Kayden: mareko: question about PIPE_CAP_SHAREABLE_SHADERS and threaded context...how do you deal with uploading the assembly into a buffer? until now, I've used a special u_upload_mgr in my context for that. and, pipe_transfer_map needs a context. it doesn't really matter what context
23:39 Kayden: but now I'm hitting an issue where some driver internal shaders are generated from the driver thread, and some are generated from the TC thread
23:40 mareko: Kayden: you can use the uploader from tc
23:40 Kayden: it kind of doesn't make sense to use an uploader tied to a context for something that's a global object..
23:41 mareko: Kayden: we upload shaders with memcpy to a mapped buffer, no context involved
23:42 Kayden: tc->base.stream_uploader and such?
23:42 mareko: yes
23:43 Kayden: hmm. I need the resources to be allocated to a particular VMA section though, so I had a custom uploader with a flag saying to pin memory in that region
23:43 Kayden: which is in iris_context, but ... probably wouldn't be in the TC base context
23:43 Kayden: I could make two of them if I could identify which to use
23:44 Kayden: I could also just open code u_upload_mgr as a threadsafe thing
23:44 mareko: Kayden: radeonsi adds create_(shader)_state into our shader compiler threaded queue and the queue compiles shaders without a context in up to num_cpus*0.7 threads or so
23:44 Kayden: awesome. yeah, I want to hook that up too
23:45 Kayden: started trying to find all the hooks for that
23:45 Kayden: si_set_max_shader_compiler_threads and si_is_parallel_shader_compilation_finished?
23:46 mareko: if the compiler is fast enough that it finishes before tc fills all its batch buffers, the compiler overhead is fully hidden
23:46 Kayden: maybe I should look at that first
23:53 mareko: Kayden: create_(vs,fs,...)_state = si_create_shader; that calls util_live_shader_cache_get. If the cache misses, it calls si_create_shader_selector (a selector of shader variants like any other driver has), which calls si_schedule_initial_compile, which calls util_queue_add_job. That's our overhead in the frontend thread. Draw time shader pipeline validation calls util_queue_fence_wait on all bound
23:54 mareko: shaders, which waits for the asynchronous compilation. Then it builds variants, which can be built by appending and prepending prolog and epilog binaries (fast) or complete recompilation (slow, usually not used).
23:58 Kayden: is live_shader_cache still useful?
23:58 mareko: yes
23:59 Kayden: I know it was for TGSI programs, but now we have st/mesa returning the same pipe_shader_state when the serialized NIR sha is the same, I thought
23:59 Kayden: which sounds pretty similar in function
23:59 mareko: st/mesa doesn't do that