10:41ipip: `This is quesada, different handle. I had a crash that didn't even give me TTYs, so I had to reboot. Here's dmesg from a recent boot: https://pastebin.com/bk0dnRfe
10:42RSpliet: ipip: in case you missed the IRC backlog
10:42RSpliet: karolherbst: quesada: if it happens again, downgrade to 4.9.29
10:42RSpliet: karolherbst: quesada: this should be the bug: https://bugs.freedesktop.org/show_bug.cgi?id=101184
10:42ipip: RSpliet: thanks, I did miss it
10:42RSpliet: for future reference, IRC is logged. See the subject line of this IRC channel
10:43RSpliet: other than that, we're don't really do distro support here. If a downgrade works, please also chime in on that bug report (and double-check that it still panics with a 4.11 kernel)
10:44ipip: I'm still on 4.9.30, and can't risk changing kernels
10:45ipip: but will chime in
10:46ipip: ah, 4.9.29 is the kernel
10:47ipip: too risky. But thanks, it's good to know there's a solution
10:47RSpliet: information about old versions not functioning is not useful to developers. Your bug potentially might have been fixed already in the meanwhile, and nobody has the time to chase a fixed bug. Unfortunately, we really only have 1.5 developer for the kernel side of nouveau, and there's a lot of work left to be done ;-)
10:47RSpliet: In this case, judging by karolherbst's reply I suspect it hasn't been fixed yet, but we can't know for sure
10:47ipip: I'm sure there is. I'm amazed you chased this one out. Thanks from the depth of my heart
10:49ipip: 4.9.27 is the only downwards path in manjaro. So the recommendation is to try to scape upwards, to 4.11.3-1
10:50ipip: interestingly, when plugged into an external monitor it works like a champ
10:50ipip: so I'd rather stay like this :)
10:59karolherbst: RSpliet: there is that patch which seems to work though
10:59karolherbst: ipip: every upstream 4.9 and 4.11 kernel has this bug
10:59karolherbst: ipip: so 4.9.27 is your choice
10:59karolherbst: or 4.11.2
12:41imirkin: RSpliet: i think you're being very generous in your developer counts
15:26tagr: imirkin: context regarding the released stuff that I might be able to point at? it's no longer in my backlog
15:29pmoreau: tagr: Here is the log, the last ~20 lines: https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=nouveau&highlight_names=&date=2017-06-03
15:30pmoreau: Some video decoding firmware for X1 it seems
15:31RSpliet: imirkin: I count Ben as slightly more than one
15:38karolherbst: I hope it won't stay at 1.5 though :/
15:42tagr: pmoreau: okay, thanks
15:43tagr: qlutoo: /dev/nvhost-nvdec is only available on the downstream kernels, but if you run that, you likely also have the downstream userspace around, right?
15:45tagr: qlutoo: I'm afraid the best way to find out what to feed to that device is to capture what the userspace sends it, we haven't released any documentation about the command stream for NVDEC
15:45karolherbst: tagr: maxwell/pascal video accell stuff?
15:45tagr: karolherbst: yeah
15:47tagr: I'm still hoping that we can get some information released eventually, but there's many people that need to be convinced and it's taking a while =\
15:47karolherbst: is there something happening on the tegra front though?
15:48tagr: karolherbst: not on the userspace side, but we have recently merged support for the VIC, which can be used to offload some image processing tasks, though it isn't very useful in itself for video decoding
15:48tagr: merged support in the kernel, that is
15:48karolherbst: I was more thinking about a gnurou replacement :p
15:49tagr: karolherbst: well, we all know that gnurou can't be replaced =)
15:50RSpliet: karolherbst: did you keep the receipt on this gnurou? Given it stopped working, we might be able to claim a comparable model under warranty
15:50tagr: but we've got someone who should be able to take over
15:50karolherbst: tagr: good to hear
15:51RSpliet: tagr: any timescale on a more formal announcement of this (not press release formal, but "here (s)he is, ta daaaahhh")?
15:51karolherbst: RSpliet: patch series from a @nvidia email address should be enough, I guess
15:53RSpliet: karolherbst: would be nice to initiate some communication before hacking commences. Of course all patches welcome and not up to me blablah, but it might help reduce incompatible-codestyle related faff ;-)
15:54karolherbst: but if the patches aren't mergeable, they aren't mergeable
15:55RSpliet: There's two ways of learning. The hard way, which is this. Or the soft way, which is engaging with community, asking questions when unsure.
16:41tagr: RSpliet: I don't think we have a timescale, but I'll make sure that the right process is followed
18:11RSpliet: tagr: as long as you don't form a solid wall between us, As much as I appreciate noise reduction I do prefer collaboration over lots of internal 'screening' :-)
18:12RSpliet: (I guess it's all a balance!)
18:14RSpliet: interaction with gnurou has always been very pleasant!
18:52Lyude: mupuf: hoping to get back to working on clock/block/power gating stuff/etc, is there anything with a bit more of an extensive explanation on what needs to be done still? I'm imaginging most of it, but just looking for somewhere to start since the trello card doesn't seem to say much
18:53mupuf: Lyude: hmm, good question
18:54mupuf: I would say that clock gating would be a good thing to finish, since you already started it
18:54mupuf: and you got some review
18:54mupuf: after that, power gating
18:54Lyude: ah, I thought we were going to have all of the patches for that stuff land at the same time?
18:54mupuf: Lyude: did we say that even power gating had to land at the same time?
18:54Lyude: maybe I misread the original messages
18:55mupuf: maybe there was a good reason for that, but all the clock gating patches need to land at the same time for sure
18:55mupuf: I can't see a reason why clock gating needs to depend on power gating though
18:55Lyude: gotcha, I will start working on that again then :)
18:55mupuf: and karol is still working on auto reclocking
18:56mupuf: so, all is well on this front
18:56mupuf: but we'll have to create test systems for this :s
18:56mupuf: we have been putting it off for too long :s
18:56Lyude: We really just need something to automate running intensive applications with perf level at high while checking to make sure nothing breaks correct?
18:57mupuf: well, dynamic workloads would be better
18:57mupuf: but I was more thinking about performance
18:57mupuf: dynamic reclocking should save power for free, basically
19:01RSpliet: mupuf, Lyude: we still don't have anyone looking into how the linebuffer (NISO buffer) works
19:01Lyude: what exactly is that, something similar to watermarks?
19:02RSpliet: Lyude: watermarks is part of the problem
19:02RSpliet: the linebuffer is a cache for pixels between DRAM and displays
19:02mupuf: oh, right! That part is really important for non-optimus machines
19:03RSpliet: needs to be configured, I think based partially on the resolution and clock etc... a well configured linebuffer will make sure display scanout doesn't underflow while reclocking
19:03mupuf: Lyude: but yeah, I would say that it should be simillar to the watermark computation for intel
19:03mupuf: so, you would be qualified for this job :D
19:04RSpliet: on top of that, for GF119+ I don't think sync-to-vblank is configured compeletely correctly.
19:04Lyude: mupuf: i'll go assign the trello card to me then :)
19:04RSpliet: there's a signal for that supposed to go into PDAEMON. For single-display systems we can wait for that event before we reconfigure DRAM
19:05Lyude: and also finish that clock gating stuff
19:05RSpliet: (which is exactly what we do on pre-GF119 to prevent the screen from flickering :-D)
19:05RSpliet: but *something* needs to be configured during modeset for this signal to be correct... maybe skeggsb has more details on this
19:07RSpliet: (this trick wouldn't work for multi-monitor set-ups, as since every monitor is running at 60Hz they're never going to line up. Except mumble mumble quadro... well, TMI :-D)
19:13mupuf: RSpliet: why wait for vblank when you have a line buffer?
19:13RSpliet: mupuf: sounds redundant to me too, NVIDIA does it though
19:13mupuf: probably is waiting on one screen
19:14mupuf: in order to reduce the number of requests during reclock
19:14RSpliet: I could imagine with very high resolutions the linebuffer could be too small to feed both monitors for 100ns?
19:15RSpliet: so you configure it entirely for monitor A, and wait for monitor B to vblank :-P
19:15mupuf: you mean us :D
19:15RSpliet: sounds more feasible
19:15mupuf: and the linebuffer has to be per CRTC
19:15mupuf: so, I doubt
19:15RSpliet: considering every MR configuration is 1000ns :-P
19:15mupuf: maybe we can force it to full before doing the reclock too :D
19:15rouk: I'm getting a kernel panic on a 660 Ti on startup. I found a bug report that seems to fix it for 650. Are the chips in the 660 Ti and 650 similar?
19:16mupuf: skeggsb: are you working on the ptimer.alarm fix?
19:16RSpliet: I *think* on pre-gf119 they have one linebuffer, and you configure it's division for the two monitors you drive
19:16mupuf: ah ah, fun
19:16rouk: This is the bug report: https://bugs.freedesktop.org/show_bug.cgi?id=101184
19:17rouk: Also seems to be nvkm_timer_alarm_trigger that's causing an issue.
19:17mupuf: skeggsb: I see, you already have a fix, good
19:17mupuf: rouk: I guess it will be in the pipes for mainline and stable kernels
19:17RSpliet: mupuf: makes perfect sense right. Twice the cache if you only have one monitor, means bigger transfers, means more likely to hit max throughput from DRAM :-D
19:18mupuf: RSpliet: right
19:18mupuf: it means a more predictible computation time too
19:18rouk: mupuf: So until then I wait for a package from Arch? How long does it usually take?
19:18mupuf: anyway, bbl
19:19mupuf: rouk: hmm, let's wait for skeggsb to get his patch pushed into Linus' tree
19:19mupuf: and at this point, it should take up to a week
19:19mupuf: and at this point, you can use linux-git
19:19mupuf: for now, use linux-lts
19:20rouk: Oh, alright. Thank you.
19:20RSpliet: rouk: (or patch and build your own kernel. Maybe the arch people can help you out of you need a fix today)
19:28rouk: RSpliet: I was planning on using the blob for a week... (Traitor!) But I've never built my kennel before, sounds scary.
19:29RSpliet: rouk: there's been times I built 15 in a day. It's not that scary and I'm sure arch peeps have good manuals for how to go that easily
19:29RSpliet: I'm a Fedora man, so can't really help you with that much
19:30RSpliet: Up to you though, pretty sure installing the blob is quicker
19:30rouk: RSpliet : I appreciate the help. I'm curious I might try.
19:30rouk: I'll ask them.
19:34rouk: Is it possible the panics are linked to a driver update on the Windows side? Do those affect the cards firmware? It came out of blue and I know Windows updated then behind my back because of the flashing to black.
19:34RSpliet: firmwares are uploaded on every boot, so no
19:35RSpliet: but the Windows driver might configure the card in a way that straight after a reboot it's in a different state from a fresh boot. It'd surprise me if that is the case (because it means your BIOS probably doesn't POST the card), but more feasible
19:37pmoreau: rouk: You could download the PKGBUILD of the linux package, add three lines in it, build and install.
19:37rouk: I mean I've never had an issue like this one with nouveau.
19:37rouk: pmoreau on the AUR?
19:38rouk: I've actually never used a patch file or edited a PKGBUILD sorry...
19:38rouk: I just check they don't do fishy commands.
19:39pmoreau: I can edit it for you or tell you how to do it, it is not too complicated
19:40rouk: If you have time to explain it'd be great. :D
19:40rouk: I have a USB live boot so I can just chroot
19:42pmoreau: So: you first need to add the patch file to the list of sources (`source` variable, line 15), and so add, either a 'SKIP' or the correct sha256 sum to the `sha256sums` variable, line 26. Source at index $i in `source` is matched against sha256 at index $i in `sha256sums`, so be sure to placed them at the same index in both.