00:09pabs3: last night I got another screen freeze (with Linux 5.2.9-2): https://paste.debian.net/1099988/
00:37gnarface: maybe i/o related?
00:37gnarface: i mean like, disk i/o?
00:37gnarface: or something?
00:37gnarface: i don't know
01:30pabs3: no, its a nouveau bug, see the paste
04:10imirkin: tagr: sorry, running out of time for testing it today. maybe tomorrow.
16:30karolherbst: imirkin: sqrt is SM52, not SM60
16:30karolherbst: already opened an MR for it, but the subversion handling in envyas is suboptimal.. https://github.com/envytools/envytools/pull/151
16:30imirkin_: yeah, i realized that after i said it...
16:31imirkin_: that's why i said to just do SM60. but we can also just not version it and say it's everywhere.
16:31imirkin_: even though it's not
16:31imirkin_: we don't have to be 100% precise on this
16:31karolherbst: well, with my MR it all works out
16:31karolherbst: it's just a bit ugly
16:31imirkin_: your MR is adding 75 variants though, no?
16:31imirkin_: which i dunno if it's the best path either
16:31karolherbst: why would it add 75 variants?
16:32imirkin_: maybe it doesn't. that was just my recollection.
16:33imirkin_: looking now...
16:33imirkin_: right. so you added a sm52 variant...
16:33imirkin_: and then we will add a sm53 variant for all the half-float ops
16:33imirkin_: so we end up with 30 diff variants.
16:34imirkin_: but wtvr. it's also acceptable...
16:34karolherbst: where sm53 would be the last anyway
16:34karolherbst: mhh, yeah..
16:35karolherbst: we could also modify envyas to be able to add stuff like that easier
16:35imirkin_: it adds precision
16:35imirkin_: but whether that precision is worth it ... dunno
16:35imirkin_: i figured it was fine to just hide it all behind SM60
16:35karolherbst: would be annoying if you read gm20x mmts and see unknown instructions and then you see it's just sqrt :p, but yeah
16:36imirkin_: hm, yeah
16:36imirkin_: well, wtvr. i'm open to stuff
16:45karolherbst: mhh, just retested it. seems to work as expected: https://gist.githubusercontent.com/karolherbst/39686ddc22952322b06f8cf4e6383152/raw/f23e12ba10761b4fd36a7d7fac8f6134dd2ac3b2/gistfile1.txt
16:45karolherbst: mhh.. without specifying -V sm50, I get "$p0 mov $r0 $s62"
16:46karolherbst: same on master though
16:47karolherbst: but that kind of makes sense
16:48karolherbst: imirkin_: if you have no further comments I'll merge it then... we might end up doing the same for sm53 but that would be the last time for maxwell/pascal anyway and I really don't see it's worth the effort reworking the core code to deal with that in a better way
16:48imirkin_: ok wtvr
17:06karolherbst: mhh, look what I've found: https://github.com/envytools/envytools/commit/cb5e7689596a45b985a5f63f5b3d44940d50217b
17:06karolherbst: no idea what this NO_SOFT_RESET does.. but I think it has some impact on the runpm path
17:06karolherbst: Lyude, skeggsb: ^^
17:09karolherbst:wishes we could declare ro and rw on rnndb
21:06HdkR: imirkin_: You're going to be so upset about the SM53b variant :P
21:07imirkin_: if i don't know about it, it doesn't exist.
21:21karolherbst: HdkR: I am sure it's equal to the SM53 except some instructions need higher stalls compared to SM50 and SM52 :p
21:22karolherbst: mhh 5.3 is gm20b...
21:22karolherbst: HdkR: let me guess, the SM53b is the nano
21:25karolherbst: or it's this weird T210B01 thing used for the new nintendo switch
21:26karolherbst: which uhm... makes it super pointless?
21:26HdkR: It's super pointless :D
21:30karolherbst: HdkR: nintendo should have went with PTX in all their games, even if it costs some CPU cycles initially :p now it bites them
21:30karolherbst: I am sure that's the story behind the SM53b, because they wanted something "new"
21:31HdkR: Nah, it's nothing like that
21:32karolherbst: would be funny
21:35karolherbst: another idea: internal marketing software is crap and due to the die shrink, there was a new SM version required :p
23:20karolherbst: nvd7 uses the kepler PCI linking code
23:20karolherbst: how did I miss that
23:21karolherbst: but not nvd9
23:21imirkin_: gf117 is logically after gf119
23:21imirkin_: both have elements of kepler
23:21karolherbst: mhh, yeah
23:22karolherbst: I was pimping the pcie code a bit
23:22karolherbst: just noticed that inside the traces
23:22karolherbst: apparently 0x08b8c0 is important
23:25karolherbst: skeggsb: ^^
23:25karolherbst: I think that covers most of it
23:26karolherbst: nvidia also does a post check to see if the value changed indeed...
23:26karolherbst: but.. meh
23:26imirkin_: oh dear ... aspm
23:26karolherbst: ohh, it's not aspm
23:26karolherbst: it's just a force disable
23:26karolherbst: doesn't do anything if aspm is already disabled :)
23:26imirkin_: oh i see. don't do aspm while renegotiating link changes?
23:27imirkin_: sounds like a reasonable policy
23:27karolherbst: essentially yes
23:27karolherbst: one bit is l0s the other one is l1
23:28karolherbst: no idea if it makes sense to add 0x08b8c0 to rnndb... because I have literally no idea what it does
23:28karolherbst: nvgpu calls it dl_mgr
23:28karolherbst: and that bit mgr_safe_timing_f
23:33karolherbst: heh.. crashe my kernel.. not nice
23:37Lyude: skeggsb: got nouveau running with only one fake mst encoder per head now :)
23:45karolherbst: mhh.. I am sure I confused the system with my runpm debugging scripts :)