00:03Lyude: twod and fbcon separated! next up: nouveau learns about hw accel zfill with twod so we can use it for creating blank core surfaces when base is disabled, then afterwards (probably) also separating dma-copy from nouveau's bo code so we can also use that for zfills (and fbcon maybe, because why not)
01:13c_nix: I see kinda confusing info online on Quadro and multiple displays - are there models that work OK with Nouveau with multiple displays?
01:14c_nix: are Kepler based OK?
01:15imirkin: c_nix: multiple displays should work to the hardware's maximum capability
01:16c_nix: great, thanks
01:16imirkin: it's possible there are rare cases where this is not the case
01:16imirkin: but i can't think of a lot of them
01:16c_nix: display ports should work?
01:16imirkin: in general, yes
01:16c_nix: ok
11:41ccr: danvet, https://pastebin.com/G9A5SyJA .. here's the patch, hopefully the commit message is not too bad etc. but I'm open for suggestions, of course.
14:02RSpliet: ccr: as a minor nit: kernel style guide dictates that if the if() branch uses brackets, than the else() and else if () must have brackets around their body too - even if it's a one-line content. It's either all or none
14:03RSpliet: So lines 40-41 in that pastebin will need brackets.
14:08ccr: okay. checkpatch didn't warn about that .. of course it can't warn about everything, I suppose.
14:09RSpliet: On the content side of things, I am slightly confused why this solution is correct. validate_list should only return 0 if there are 0 relocs. After your patch, the boolean apply_relocs will remain untouched if there are no relocs.
14:10RSpliet: is apply_relocs being overriden in other places, and initialised properly?
14:12ccr: it is initialized in the calling function. I attempted to explain the issue in the gitlab ticket. and I agree that it's not a "nice" solution, but danvet seems to agree that it is acceptable.
14:12RSpliet: I don't see how it alters behaviour in any way
14:12ccr: heh
14:13RSpliet: Oh
14:13RSpliet: Hah
14:13RSpliet: Yes, there's the goto revalidate
14:13ccr: indeed
14:13ccr: and according to danvet the revalidation loop is required, so .. I guess it could be made cleaner but would require more extensive changes.
14:14RSpliet: Ok, In that case you should be able to replace the *apply_relocs = ret; withthe (conditional) *apply_relocs = true... or whatever the kernel standard is for boolean literals (0 and 1? true and false?)
14:18ccr: yes, that seems saner.
14:22ccr: https://pastebin.com/QNKFzQgH with your suggestions fixed I hope.
14:24ccr: RSpliet, thanks :)
14:25RSpliet: No worries! Looks good to me now :-)
14:26RSpliet: Oh, and thanks for writing up and testing this patch! And this is totally how people get drawn into the project, so... welcome on the team ;-)
14:27ccr:attempts to flee
14:27ccr: well, can't promise anything, but if I run into issues, I usually at least try to make an effort to provide all the possible information and help in the report etc
14:29RSpliet: Hahaha, in that case I hope you run into many more issues :-P
14:31ccr: there's one issue with suspend on my junk laptop, but it's probably not related to nouveau .. (without "echo 0 > /sys/power/pm_async" suspend takes like two minutes to finish, with it is normal few seconds.) unfortunately I've not found much information about debugging async suspend problems.
14:31ccr: e.g. some driver is not playing nice with async suspend
14:32ccr: not that it matters much since the workaround works, but still a bit curious
14:44danvet: ccr, aside from the {} nit looks good to me
14:44danvet: pls also cc: me as author of the offending commit
14:44danvet: and maybe also cc: dri-devel
14:51ccr: danvet, like this? https://pastebin.com/YC1UN4ms
14:55ccr: now, I have one more question .. when sending that patch, do I need to add those Cc:s to the actual mail Cc:s or does LKML do that for me in case I use alpine/Mutt or so to actually send? or should I use git send-email for that to happen?
14:55ccr: perhaps I should read some more documentation about this
14:56danvet: git send-email picks them up automatically
14:56danvet: if you send it some other way, then you need to add them manually
14:56ccr: okay
14:56danvet: also don't worry if you screw it up
14:57danvet: I've been doing this professionally more than 10 years
14:57danvet: and still get it wrong sometimes
14:57ccr: heh.
15:02danvet: tzimmermann, I'm assuming you volunteered mripard for review favours on your pending patch series?
15:03tzimmermann: danvet, i hoped he would look at the patches
15:03tzimmermann: don't let that stop you ;)
15:08danvet: hm mripard not around
15:08danvet: I wanted to give him that guilty feeling
15:15tzimmermann: danvet, we're in nouveau
15:16ccr: hmm.. still one more stupid question: should I just send this to linux-kernel@vger.kernel.org (and the Cc:s of course)? just confused because some sub-projects just seem to recommend sending to their own mailing list.
15:16tzimmermann: let's just copy-paste the conversion ito dri-devel :)
15:20tzimmermann: 'conversation'
15:20jcline: ccr, typically you cc linux-kernel as well as the sub-project mailing lists
15:21jcline: It's a very confusing process :(
15:21ccr: heh
15:23ccr: well, here goes nothing ..
15:24kherbst:wished we would finally use gitlab
15:25ccr: would probably be easier for a random drive-by contributor .. I'm sure all the regulars have a pile of scripts etc for automating things
15:25jcline: You can take comfort from the fact that pretty much no one reads LKML so if you mess up no one actually notices
15:25ccr: :D
15:26ccr: so no "you have shamed your family, your ancestors and descendants .."
15:26jcline: Yeah, that's never happened to me and I've messed up a number of different ways
15:28jcline: Once I sent some clearly-Red Hat-internal patches to several public lists by accident and no one complained
15:32ccr: hooray, at least it went somewhere .. "Subject: Your message to Nouveau awaits moderator approval"
15:38kherbst: huh
15:38kherbst: ccr: yeah, need to subscribe first.. but some moderator can also accept the message
15:38kherbst: the infra is just so old that I never know who actually is and I never bothered with becoming an ML mod
15:39danvet: ccr, yeah lkml is just for archiving
15:39danvet: although dri-devel is now also getting archived on lore.kernel.org
15:39danvet: so doesn't matter
15:39kherbst: danvet: we should just move over to gitlab :p
15:39kherbst: but I guess lkml is the annoying bit then
15:39danvet: kherbst, yeah, but gitlab admins don't like doing that without the setup fixed
15:39kherbst: ohh, what is there to be fixed?
15:39kherbst: permissions?
15:40danvet: lol
15:40danvet: fd.o server infra
15:40danvet: bentiss and daniels spending tons of time
15:40kherbst: ahh, so the normal being overloaded thing
15:40danvet: we need to switch gitlab from the omnibus to proper cloud setup for scaling
15:40danvet: and we need to move from google cloud to packet to not break the bank
15:40kherbst: right
15:40danvet: which means we also need to maintain the underlying machines
15:40daniels: yeah, nothing to do with permissions, just a bunch of phenomenally tedious legwork to make it more scalable
15:40danvet: yeah it's enormous
15:41danvet: from what I see being discussed
15:41daniels: none of which is visible until the endpoint of being able to confidently say that we can move the kernel repos there without breaking anything
15:41danvet: kherbst, I think once that's done it should be fairly smooth
15:41kherbst: yeah, okay. sounds good
15:41danvet: setting up gitlab-CI with all the caching and everything
15:41danvet: and getting lore.kernel.org to subscribe to our projects for "archiving"
15:42danvet: appeases the old hats :-)
15:42danvet: and then slowly moving everyone over
15:42kherbst: ehhh
15:42danvet: probably first subsystem pull requests so airlied/me didn't have to compile check stuff
15:42kherbst: if somebody complains, they might want to move into the 20th century as well
15:42danvet: and can just click buttons
15:42kherbst: uhm
15:42danvet: then maybe drm-misc
15:42kherbst: 21th
15:42danvet: kherbst, there's a lot of hold-outs
15:43danvet: even among dri-devel crowd
15:43danvet: so no point angering them for nothing
15:43kherbst: sometimes the solution is to not care and focus more on the next generation instead
15:43kherbst: :p
15:43kherbst: but yeah...
15:43kherbst: it's problematic sometimes
15:44kherbst:doesn't see why anybody prefers ML patch submission instead of proper PR/MRs but maybe I am just too young
15:46daniels: kherbst: yeah I mean I don't understand it even a bit either, and I'm a literal greybeard
15:47kherbst: in a fight against generations you also always have the older ones understanding the young ones :p
15:48kherbst: but yeah.. I guess if we would vote on it in public, we would have those ones nacking it outright and not being open for discussions
15:48kherbst: it's messy and I really have no proper idea on how to deal with it besides writing up some crappy MR <-> ML bridge which only works 50% of the time and only the ones against MRs caring enough
15:49ccr: the only thing I could see that if you have to go press buttons in a browser to do something simple, instead of running handy script or so on commandline, that might be somewhat annoying.
15:49kherbst: the problem with MRs is also, that I am pushing like 50 times as often as sending out patches, so that will also just not work
15:50kherbst: ccr: there are people just hating any kind of "website" for git, because "it's overcomplicating" things :p allthough there are also the ones just not liking gitlab as it's "overcomplicated" and prefer some simple website doing all that reviewing stuff, like patchwork
15:50kherbst: I think some even prefer gerrit over gitlab
15:52kherbst: but gerrit also has this terrible look and interface
15:53ccr: I've no experience of gerrit. gitlab seems okay, though based on overhearing some discussions about it on various fd.o channels, it seems that it is difficult/impossible to get some features to the "free" version.
15:53kherbst: yeah.. that's always the issue with software the creator has a business on
15:53ccr: which rather sucks for projects that are otherwise free/libre
15:55jcline: I did write a crappy MR <-> ML bridge 😬
15:55kherbst: jcline: did it work relibly or did people rather used MRs directly?
15:55jcline: Getting merge requests into patch form and emailed out actually isn't very difficult and quite reliable
15:56kherbst: I mean.. if it leads to people just using MRs that's "good" as well :D
15:56jcline: Get emails into merge requests is harder because everyone's basing their stuff off anything and everything so it might not apply cleanly
15:56kherbst: jcline: ohh right, that part I think is also fairly trivial. I am more wondering about those MRs with 30 patches, 200 50 force pushes and 100 comments
15:56kherbst: * 50 force pushes
15:56jcline: The red hat kernel people are using it and it mostly works
15:56jcline: I had it so that it only emailed after CI passed
15:57kherbst: mhhhhhhh
15:57kherbst: we could have a CI job doing "send out emails"
15:57kherbst: but people will forget
15:57jcline: And I set it so if the MR was N patches it'd send an email saying "run this git command to grab the merge request"
15:57kherbst: but on mesa you have to trigger the CI manually so far
15:58jcline: Oh, it was just a web hook handler that did it, doing privileged things like sending emails is dicey inside a CI job
15:59kherbst: yeah..
15:59kherbst: anyway, our problem is that we can't run the full CI on every MR automatically
15:59kherbst: and even then, you can push 30 times and pass each iteration
16:00kherbst: I am sure it works for low bandwidth communication stuff, but mesa upstream is brutally active in comparison to any other project I've ever seen
16:00kherbst: wouldn't be surprised if we have like four digit comments per week
16:00jcline: Yeah. It could be a simple "wait a bit before emailing" and it does neatly thread each merge request so you can mute an entire email thread
16:01kherbst: right
16:01kherbst: on the peak we send out 4MB of emails
16:01kherbst: gzip compressed
16:01jcline: Generally though, I'm not super interested in making a "perfect" email experience because that doesn't exist
16:02kherbst: just look at this for volume: https://lists.freedesktop.org/archives/mesa-dev/2017-June/thread.html
16:02kherbst: and I expect it to be worse with gitlab now
16:02kherbst: but yeah...
16:02kherbst: if it works, nice
16:03kherbst: I just don't think it's really worth it as it would become close to useless just based on the volume
16:04jcline: Right, there's certainly diminishing returns on that investment
20:12SolarAquarion: it nouveau perfectly usable if i don't need power management
20:37kherbst: SolarAquarion: well. more or less yes. Just some bugs and not enough time to fix all of those