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