00:00mwk: there was something about crc in pre-nv50 hardware iirc
00:01mwk:checks her notes
00:02Lyude: imirkin: ^ :)
00:02Lyude: time to patch dump
00:02mwk: yep, there is something
00:03mwk: 680608 is TEST_CONTROL where you can enable/reset the crc and select which channel you're CRCing (red green or blue), 68060c is the checksum value
00:03mwk: or at least so it seems from old register list leaks
00:05mwk: (bit 0 reset, bit 4 crc enable, bits 8-9 channel select, and the checksum seems to be 24-bit?!?)
00:05Lyude: mwk: it lets you select all the channels at the same time too, right?
00:05mwk: choose one
00:05Lyude: oh lord
00:05mwk: 0 is blue, 1 is green, 2 is red
00:05Lyude: yeah that's probably not worth the effort trying to implement
00:06mwk: and I have nfi what the algorithm is
00:06imirkin: why would you want to checksum multiple channels at once?
00:06imirkin: that's just ridiculous
00:06Lyude: imirkin: you only want to checksum multiple channels at once, that's how most modern hw does it (although the crc might have different channels in each 8 bits, depending on the algorithm)
00:06Lyude: also mwk the algorithm isn't important, igt assumes you don't know it
00:07Lyude: imirkin: ah lol
00:07Lyude: tbh that sounds a lot like matrox's CRC stuff
00:07Lyude: but i think even they let you select all channels
00:07imirkin: (that's a lie by the way ... in no way is it the end of my sarcasm)
00:08Lyude: mwk: any chance there's different tap points you can read CRCs from? maybe they don't all do channel selection
00:09mwk: there are only two registers on the whole card with "CRC" in the name
00:09mwk: and the other is the same thing, but for TV out
00:10Lyude: sad :(
00:10mwk: ... oh, and a third one, for digital output
00:10Lyude: ok, that sounds more like it
00:10Lyude: oh :(
00:10mwk: I mean the exact same thing
00:10mwk: except for TMDS, not DAC
00:11mwk: well that's because the checksum circuitry seems to be tied to the output resource
00:11mwk: which is a separate thing for (VGA) DAC, TV out, and TMDS out
00:13Lyude: mwk: no I meant just that it's weird that you could only select one channel on tmds as well
00:14Lyude: crc's are also tied to outps on gf119+, but can also come from different portions of the outp's scanout and additionally from the RG
00:14mwk: interestingly, the channels are called "7_0", "15_8", and "23_16" on TMDS and TV instead
00:14mwk: I don't think it's any different in behavior though
00:15Lyude: it is probably worth a shot to play around with at least, if anyone here gets bored enough
00:17mwk: have fun
00:17mwk: I don't even have hw access at this point, even if I wanted to
00:23Lyude: mwk: hehe, np, wasn't expecting you to :P
00:27pabs3: is there anything (as someone who doesn't know GPU stuff) I can do to help fix GPU hang issues? can I capture debug info somehow?
00:32mwk: Lyude: ... a few years ago, I'd have jumped at it and probably be reversing the algorithm by now :p
00:52Lyude: can someone approve the cover letter for https://patchwork.freedesktop.org/series/74804/ on nouveau's ml? it got blocked by it again
00:52Lyude: also - we should really change that
00:52RSpliet: Lyude: just so you know, I've definitely seen nouveau upload scripts to the PMU to do small display config thingies in VBLANK
00:53Lyude: RSpliet: oh neat, tbh though i'm not really sure it's worth the effort
00:53Lyude: also we can't upload random stuff to the pmu post maxwell 2 anyway
00:54RSpliet: Well, timing wise it's a lot more reliable than doing it on a multi-core time-shared CPU with interrupts and stuff :-P
00:54RSpliet: First thing we do for DRAM reclock is wait for VBLANK, such that at least one display doesn't flicker
00:54Lyude: RSpliet: that's what the vblank workers are for :)
00:54Lyude: they use the highest possible priority allowed by the scheduler , and intel's planning on using that for doing vblank-sensitive hw programming as well
00:55RSpliet: Yep, but CPU overheads are much higher as it has to cross a (shared) PCI-e BUS
00:56RSpliet: I think you have like... 500μs? Unless you get unlucky and find one of those reduced-VBLANK monitors
00:57RSpliet: Either way, it's something to bear in mind. If not for now, than perhaps for follow-up work. And for REing as well, if you feel like some bits are missing from NVIDIAs command stream, they might be hiding in plain sight in there
00:57Lyude: RSpliet: it's a bit more then that iirc, given a 60hz monitor it should be 16.6ms per-scanout period, I should probably also note it doesn't need to happen -within- the vblank, just before the next vblank
00:58Lyude: so even if the update gets processed half-way through the scanout period, that should still be ok, as long as the whole thing happens during that one scanout
00:59RSpliet: Ahh okay, yeah that changes requirements a bit
01:00RSpliet: DRAM reclocking must happen in VBLANK. I suspect so does reconfiguring the NISO buffer. But we don't do that sadly...
01:01Lyude: alright-misc work I came up with during CRC stuff, the actual CRC patches, and the igt tests for said patches are on the ml :).
12:31cosurgi: imirkin: any chance you could also test this with displayport?
12:33imirkin: no DP output on the GP108 :)
12:37cosurgi: ah :) But the general idea is the DP should work exactly the sae as HDMI, right?
12:38cosurgi: maybe there is some hidden mute switch which I didn't find. And it even plays the music but at zero volume
12:38imirkin: there's definitely more to it. DP audio didn't always work.
12:38imirkin: but we did make it work at some point
12:39imirkin: (and when i say 'we', i mean 'ben')
12:39cosurgi: I don't know why I can't regulate volume in alsamixer, only mute/unmute, and the channels are called S/PDIF, S/PDIF 1, S/PDIF 2, ...
12:39cosurgi: ah! good :)
12:39imirkin: sounds right
12:41karolherbst: cosurgi: S/PDIF is controlled on the end device as it's a digital signal
12:42imirkin: yeah, it's 100% digital to the monitor - no volume controls or anything
12:43imirkin: that's expected.
12:43cosurgi: ok then. So when I have set volume on the monitor to the max, and I even hear a faint white noise coming from the monitor speakers, then theoretically I have done all that I should have done?
12:47cosurgi: ok, good :) So if you will have experiments in mind to do with recompiling driver or kernel, plese let me know. Together we will fix it ;)
12:47cosurgi: albeit I prefer to reboot rarely.
17:54squimrel: The last working kernel version was 5.0.9Thinkpad P73 Dual-Graphic: Intel UHD Graphics 630 & NVIDIA GP107GLM [Quadro P620]Default Fedora 31 (5.5.9-200.fc31.x86_64) set-up. No proprietary nvidia stuff was ever installed.Packages: xorg-x11-drv-nouveau:1.0.15 libdrm-devel:2.4.100I was waiting since October on 5.0.9 for a magic fix so that I wouldn't
17:54squimrel: have to go and report this with no clue on how to report stuff in the first place. I didn't compile nouveau from master and test that so I don't know if it was magicly fixed in the latest version.journalctl -a -o short-iso-precise -k -b -1: https://pastebin.com/mCDRW5SpApart from that I can't say anything except that it doesn't boot properly an
17:54squimrel: there're stacktraces in the logs.
17:55squimrel: Spaces -.- https://pastebin.com/mCDRW5Sp
17:57imirkin: this is a good way to report
18:54squimrel: imirkin, Thanks! Please help me make sure the report is not lost in space.
18:55imirkin: squimrel: unfortunately it's not a great time for me. moving tomorrow.
18:55imirkin: keep the info handy, and repost it on, like, saturday
18:55imirkin: or maybe someone else will be able to have a look
18:55imirkin: i dunno what your issue is
18:56imirkin: but if it hangs
18:56imirkin: then chances are karolherbst has some patches for you to try
18:56karolherbst: what issue?
18:56imirkin: scroll up
18:56karolherbst: I asked because I was being lazy :p
18:57karolherbst: but yeah, looks like runpm
18:57karolherbst: squimrel: https://github.com/karolherbst/linux/commits/runpm_fixes top two patches
18:57karolherbst: if you run fedora 31 I can even provide you with a kernel build
18:58squimrel: karolherbst, Can you link me to a guide on how to test those as well?
18:58karolherbst: ahh, it's fedora 31
18:58karolherbst: squimrel: https://copr.fedorainfracloud.org/coprs/karolherbst/Nouveau_Testing/
18:58karolherbst: use that copr
19:06squimrel: karolherbst <3 !!!! That works! (Although my external monitor doesn't work yet.)
19:06karolherbst: could be some other issues
19:06karolherbst: Lyude might know
19:07karolherbst: or imirkin :)
19:07karolherbst: squimrel: does the monitor start working when you execute lspci?
19:07karolherbst: maybe hotplugging detection is screwed
19:07Lyude: i doubt it, usually hpd is pretty reliable these days
19:08Lyude: squimrel: can you boot your kernel with log_buf_len=50M nouveau.debug=disp=trace drm.debug=0x16
19:08squimrel: karolherbst, no
19:08Lyude: then get me your dmesg after trying to plug in the display?
19:09karolherbst: Lyude: I am actually kind of happy that my patch still always works when users complain as this is already limited to just that one intel bridge controller :)
19:09Lyude: yeah, it is a big relief
19:47squimrel: Lyude, so it's a little bit weird. The secondary monitor _sometimes_ works when re-plugging the display (usb-c) during boot. However so far didn't work when re-plugging it after boot and even makes it break. https://pastebin.com/3iuRHA64
19:49squimrel: So, it may be unrelated to nouveau?
19:55squimrel: karolherbst, :D Sorry - I should've waited for the magic fix a little longer.
19:55karolherbst: what do you mean?
19:58squimrel: karolherbst, I mean instead of being one of the users who comes and complains about an issue that will be merged into mainline soon. It's just really hard to find a solution for this with google.
19:59karolherbst: ohh no, it's fine
20:03Lyude: squimrel: can you send the whole log without trimming it at all?
20:05apteryx: hello, Icecat (based on Firefox) sometimes crash my X session, like:
20:05apteryx: is there something I should do to get a more useful log?
20:06squimrel: Lyude, now it works even after boot. Probably the fault of my crappy display. I assume the trimmed logs look normal to you as well. I guess that solves it. Thanks!!!!
20:07Lyude: not sure what I did but you're welcome!
20:07karolherbst: squimrel: could also be just something random though
20:07karolherbst: or maybe some latencies shifted
20:07Lyude: or a loose cable. never trust cables.
20:07karolherbst: or that
20:08Lyude: it's a little weird how USB-C adapters for video stuff seem to break so often
20:08squimrel: karolherbst, Using a different usb port fixed it. Not sure why. Yeah maybe cable.
20:08karolherbst: Lyude: annoying that my patch is stuck.. or maybe it got applied.. I should probably check
20:08Lyude: squimrel: might be that only one port can do video output
20:08Lyude: karolherbst: poke airlied maybe?
20:08karolherbst: Lyude: I would be interested in knowing how well that works with windows
20:08Lyude: karolherbst: hah
20:08Lyude: i promise the results may surprise you
20:09Lyude: or at least it was like that when I tried mst on windows, only to find out it's actually worse then linux
20:09Lyude: for intel anyway
20:09karolherbst: maybe it works better with macs then...
20:10karolherbst: sounds like something they would really care about
20:11Lyude: karolherbst: it'
20:12Lyude: *it's funny, I used to think getting confused by the DP spec was just a me thing, but everyone from intel/amd/google have trouble understanding it as well
20:12airlied: I think apple have avoided mst where possible :-P
20:12karolherbst: uhm... and who are the people who actually wrote it? :D
20:12Lyude: ^ that as well
20:12Lyude: karolherbst: those companies, probably
20:12karolherbst: airlied: what do they do on their usb-c/TB only macbooks then?
20:13Lyude: specs are hard
20:13karolherbst: not using MST?
20:13Lyude: karolherbst: you can run up to like two video streams through TB3 actually, iirc
20:13Lyude: but a lot of laptops don't support it
20:13karolherbst: I see
20:14airlied: karolherbst: just DP
20:33gruetzkopf: i've previously looked at what little public info there is about dp alt mode on usbc
20:34gruetzkopf: so - many - optional things
20:35Lyude: well yeah, otherwise it'd be too expensive to incentivize manufacturers to use it unfortunately