00:36sysadmin: ATTENTION: This channel will be terminated. Any nicks remaining in the channel will also be terminated. This action cannot be undone.
00:39imirkin: sysadmin: seems doubtful. but i'll help you out.
00:40HdkR: Ah, they tried that in #radeon as well
01:33karolherbst: https://gitlab.freedesktop.org/karolherbst/ci-scripts/-/blob/65ad26a1999420d7f05bb649c9dae0333aa6f153/ci/gitlab-ci.yml :(
01:34karolherbst: I think I am overengineering this a little
01:35airlied: karolherbst: I assume rebases won't go throught that
01:35karolherbst: why not?
01:36karolherbst: or do you mean like if we rebase nouveau-next or whatever target we have?
01:36airlied: karolherbst: yes those ones
01:36karolherbst: good question
01:36airlied: like if you want to move from 5.10 to 5.11 base
01:36karolherbst: we could add a pipleine we can manually trigger to rebase
01:36airlied: I suppose you could also backmerge
01:36karolherbst: but that will be a bit overkill
01:37airlied: but either way you probably don't want that going via a git rebase --exec
01:37karolherbst: my solution was that somebody just force pushes or so...
01:37airlied: ah cool yeah makes sense
01:37karolherbst: airlied: yeah... that's just for plain MRs atm
01:37karolherbst: we also have the problem that when we rebase nouveau-next that all active MRs are borked
01:38karolherbst: airlied: actually.. the rebase is a huge issue we might have to think about
01:39airlied: for misc-next we never rebase I don't think
01:39airlied: I think it just always gets a backmerge
01:39airlied: whereas for drm-next I always rebase
01:39karolherbst: airlied: you think this is too much or the thing users want to see? https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/2#note_925450
01:40karolherbst: airlied: I think a back merge is probably better for MRs
01:40karolherbst: we just have to.... trick it through the CI somehow and probably through a custom pipeline which just pulls from linus/master or so
01:41karolherbst: because... it should just go through as long as there are no new commits...
01:41airlied: karolherbst: do you need to dump the artifacts into the MR?
01:41karolherbst: they are invalid after a day though
01:41airlied: it just feels a bit RHEL like where it you hit people in the face with too much info
01:42airlied: but yeah one day isn't long enough there
01:42karolherbst: the comment will stay, but.. I mean this was an #error inside a header file
01:42karolherbst: the error log shouldn't be too long in the normal case
01:42karolherbst: I already do make -k magic to really only print the errors
01:42karolherbst: or make I should only print 10...
01:43airlied: like compared to the amount of info mesa produces in the MR vs in artifcats it seems a lot
01:43karolherbst: huh? what do you mean specifically now?
01:43karolherbst: that the comment is too verbose?
01:45karolherbst: ehhh.. make doesn't support an error count for -k
01:45airlied: if you fail a mesa buidl you just told the pipeline failed
01:45airlied: you then have to dig the pipeline
01:45airlied: instead of it spamming the MR which might have interesting discussion in it
01:45karolherbst: I think I will just head -n 50 the output
01:46airlied: like if you want the MRs to have interesting discussion in them then you need to limit the automated output in them
01:46airlied: esp when it comes to reviews
01:46karolherbst: I think it is still valuable to print the result, but I also wanted to make it manually triggered
01:47karolherbst: but anyway.. just toying around atm and seeing what actually works
01:53airlied: karolherbst: checkpatch and building are a pretty good start
01:53karolherbst: airlied: but yeah.. I am also unhappy about the output of checkpatch
01:53karolherbst: but.. I have a solution here
02:14karolherbst: airlied: better? https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/2#note_925478
02:16airlied: karolherbst: yeah that seems nicer
02:18karolherbst: airlied: I am also thinking of checking a few different build configs.. but that could be a bit much
02:18karolherbst: but.. then we have those configs disabling some features and had build errors in the past
02:19karolherbst: oh well.. it's getting late
15:21karolherbst: https://gitlab.freedesktop.org/nouveau/ci-scripts/-/merge_requests/4 :)
15:24karolherbst: I might add checks for arm builds in the future, but I think that's good enough for now
19:18sysadmin: Remember Bitcoin in 2008??? Pi is a new digital currency developed by Stanford PhDs, To claim your piece of pi goto https://minepi.com and use "ilkde" as your invitation code. Get your piece of the pi now!
19:19imirkin: "T" for "Time to leave"?
19:20RSpliet: What even is a +q?
19:21ajax: means they can't speak in the channel. considered to be slightly less inflammatory than a straight ban, for some reason.
19:23ccr: it's like inverse of "voice"
19:23ccr: aka +v
19:23RSpliet: fair. Don't know whether "less inflammatory" matters at all in this situation, but w/e
19:24airlied: well for a lot of bots they don't realise they've been quieted, whereas the do realise they've been kicked
19:24airlied: so it's like keeping a phone scammer on the line
19:24ccr: you could think of it as "shadow ban", except the recipients can see it
19:25RSpliet: Yeah, plus bans are hard. Good chance their IP is a tor exit node
19:25ajax: that's the $a bit of the usermask. $a:ajax matches "user logged in as ajax"
19:26RSpliet: oh this is an authenticated user? lol
19:26ajax: that plus requiring registration to be voiced on a channel...
19:28ccr: out of morbid curiosity -- are there any other "regulars" than marten/whomever the .ee headcase is on many mesa/etc channels
19:28imirkin: just joss.
19:29ccr: I've been hanging out here for quite some time and "he" (marten whomever) is the one I've encountered most often
19:29ccr: "here" as in #nouveau, #dri-devel and #intel-gfx etc
19:29imirkin: yep. just joss ( = martm)
19:34ccr: are there any "easy" kernel/dri/mesa tasks for nouveau that I could possibly take up on? thus far I've fixed one small kernel bug and worked somewhat on Python and C stuff in Mesa related to Gallium driver tracing (scripts and the trace stuff itself in auxiliary/driver_trace)
19:37RSpliet: imirkin is most likely to know. Although he tends to hoover up a lot of the "easy" tasks. And the difficult ones too... just calls them easy and solves them too
19:37imirkin: ccr: yeah, so the problem with the easy tasks
19:37imirkin: is that they're much easier than the hard ones
19:37imirkin: and sometimes one doesn't have a ton of "thought" time to commit
19:37imirkin: and so one just fixes the easy stuff
19:38imirkin: the hard bits have much more staying power
19:38ccr: I totally get it
19:38imirkin: so the thing that'll drive my suggestions will be ...
19:38imirkin: what GPU do you have?
19:38ccr: my problem is that while I have lots of experience with C etc but I don' really have much experience about Mesa itself, or modern GPU stuff
19:39imirkin: ccr: too bad you weren't born with the knowledge like all of us were...
19:39ccr: my main desktop GPU is Intel Haswell 4600
19:39RSpliet: ccr: is there something that really really, and I mean really really really, bothers you about nouveau?
19:39imirkin: ccr: nouveau doesn't work well on Intel GPUs
19:39ccr: but I also have NVidia whatnot 218
19:39imirkin: do you have any "in-scope" GPUs
19:39imirkin: ok, GT218?
19:40RSpliet: imirkin: did you not need one of those for your compute work? :-P
19:40imirkin: RSpliet: too late, plugged one in.
19:40imirkin: RSpliet: the GDDR5 board works better than i thought
19:40ccr: the one I fixed the kernel bug for .. whatchamacallit
19:40RSpliet: just can't change its clocks
19:40imirkin: RSpliet: yeah ... any thoughts on what i need to do for that?
19:40imirkin: seems like we should have most of the pieces in place
19:41ccr: a NV4E
19:41imirkin: RSpliet: is it mostly a question of "insert flap A into slot B"? or is there a lot of tracing/etc left?
19:41ccr: or GeForce 6510 Go in my craptop
19:41imirkin: ccr: i consider nv3x to be abandonware at this point. you're welcome to improve things on it if you like. i could give many pointers. but it's hard and ancient.
19:42RSpliet: imirkin: I'd say the latter. I suspect in the end the memory script won't differ much from GDDR3, but you may get to deal with pushing PLLs to their limits and with link training that we've only done for *one* GT218 and for Fermi+
19:42imirkin: RSpliet: hm ok
19:43RSpliet: Oh, and that one gt218 (which happened to be my now-defunct-and-non-existent laptop) is different from all the other link training too!
19:43imirkin: RSpliet: is there something more i should do than just get mmiotraces of transitioning between perf levels?
19:44RSpliet: imirkin: I'll leave you to decide whether it's a good or a bad thing that there's like three of those GDDR5 cards in existence. I think the one I owned is now in Ben's hands.
19:44RSpliet: It does mean that you can't exactly do a very exhaustive exploration of all possible options. It also means they probably all have the same GDDR5 configuration and a first stab implementation works good enough (... famous last words)
19:45imirkin: RSpliet: yeah, i mean i could do something super-non-portable which works well for my board
19:45imirkin: and if anyone else ever shows up, we can incorporate their data ;)
19:45RSpliet: And there's a good chance that works for all the boards. It really wasn't that popular I don't think :-D
19:45imirkin: there are laptops with it
19:45imirkin: someone filed a bug about it
19:45imirkin: some sort of general instability
19:46ccr: imirkin, I'm rather happy with the level of NV4E functionality with Nouveau at the moment. unles it regresses, of course.
19:46imirkin: ccr: so the thing about GT218 is that it's an older gen, and most of its features have been completed
19:46imirkin: i'm trying to think what you could do
19:46imirkin: ccr: are you interested in opencl?
19:46RSpliet: please say "scan-out buffer" :-P
19:47ccr: there is an occasional hibernation issue that sometimes it hard-hangs (picture comes up) when unhibernating, but sometimes it works
19:47RSpliet: Or whatever that cache is called. NISO buffer?
19:47ccr: imirkin, not much, but if I can be of help, sure
19:47imirkin: ccr: i wouldn't hope to fix that suspend resume issue
19:47imirkin: i have no idea how one might go about even investigating what such a problem would be
19:48ccr: I don't care that much either, it only hangs very rarely
19:49RSpliet: imirkin: gt215_ram_calc() is where a lot of magic still needs to go for GDDR5
19:49imirkin: RSpliet: ok
19:49imirkin: well first it'd probably be prudent to get some traces
19:49imirkin: oooh, i wonder if i did that back in the day....
19:50tpefreedom: How well does nouveau support the nvidia 16 sereis (1650/1660 and variants)?
19:50ccr: define "well"
19:50imirkin: tpefreedom: define 'support' (not to mention 'well')
19:50RSpliet: imirkin: Yep. My modus operandi was "stop X, flip one bit in the ramcfg VBIOS table, enable trace, start X, diff the ramfuc script"
19:51imirkin: tpefreedom: everything since GTX 900 requires signed firmware, so there's no reclocking
19:51imirkin: which means you get something like 10% of the card's max perf, all things being equal
19:51RSpliet: but all things aren't equal. :-D
19:51imirkin: otherwise pre-ampere boards are fairly well supported at this point.
19:51ccr: in one of my experiences, with Ubuntu 20.04 (IIRC) a GTX 1660 card hung with NVidia blob v460 but worked (booted) just fine with Nouveau of that particular distro
19:53ccr: but it's always Your Mileage May Vary
19:53tpefreedom: Are there any recent graphics cards that work well w/o the proprietary drivers (and with the replacement drivers)?
19:54ccr: you again need to define what "well" actually means
19:54RSpliet: ccr: for a bit of background on that NISO thing I shouted earlier: if you want to change your DRAM clock, one of the things you need to do is make sure that there's no active users of the DRAM.
19:54RSpliet: One of the consumers of DRAM is "display scan-out", basically copying pixels to your monitor one at a time
19:55imirkin: tpefreedom: AMD and Intel.
19:55RSpliet: In the good old "single monitor" days, the trick to make this all work fine is to defer your DRAM clock change to the monitor's VBLANK period - a short pause (~0.5ms) that's good enough to stuff this in
19:56RSpliet: However, GT218 supports two monitors. Unless the two monitors' VBLANK periods are synchronised (they're not), that doesn't work
19:56ccr: tpefreedom, if you choose a NVidia card and hope to use open source drivers, you "have chosen poorly" https://stephenthelawyer.files.wordpress.com/2018/04/he-chose-poorly-2-1.jpg
19:57RSpliet: Enter the NISO buffer: a little "pixel cache" between DRAM and scan-out that can hold pixels for long enough to be able to do the DRAM clock change without starving the monitor of precious pixels
19:57tpefreedom: I have not chosen a gpu or computer yet. I just noticed that a lot of inexpensive gaming laptops have some variation of the 1650 or 1660.
19:57RSpliet: I think the configuration of that buffer is fairly simple on GT218. It's just a bunch of memory, and somewhere you can configure how that memory is divided over the two monitors
19:58RSpliet: But... I never looked into it in too much detail.
19:58RSpliet: And nouveau doesn't configure it afaik
19:58RSpliet: The benefit of configuring it is flicker-free multi-monitor reclocking on nouveau. Right now if you have more than 1 monitor, you get flicker for one frame
19:59RSpliet: It's a prerequisite for looking into "load-based" reclocking (rather than manual, which is the best we can do right now)