06:55josla972: I have nouveau + gnome 3.30 (without systemd) on wayland almost working the way I want it with a hybrid graphics setup. DRI_PRIME=1 glxinfo works in the sense that the nvidia card is used and so on. My question is: Is it possible to force second monitor to use the nvidia card instead of the intel card. I get high CPU-load from gnome-shell just by moving around windows etc on the second monitor.
12:17rhyskidd: skeggsb: do you still have the GTX 1650 card in or ready access to the mmiotrace?
12:17rhyskidd: re: https://github.com/skeggsb/nouveau/commit/3c204c7dd75a4cc1eaef91874c0b9d95ebc8e7a1
12:18rhyskidd: are you sure that the chipset in boot0 for TU117 is 0x167 and not 0x177? (and similarly for the TU116 when support added, 0x166 for the chipset?)
12:18rhyskidd: i've been looking at a couple of vbios' for those cards, and the chipset seems to be 0x17x
12:19rhyskidd: at least in envytools land
12:25rhyskidd: see here: https://github.com/Echelon9/envytools/blob/feature/tu117-support/nvbios/info.c#L336
12:57karolherbst: rhyskidd: mhh, maybe it differs from where you get that info?
12:57karolherbst: rhyskidd: do you have a tu117/6 card at hand?
12:58rhyskidd: no, just the vbios at the moment
13:00karolherbst: rhyskidd: I wouldn't be surprised if there is some messup, it's kind of the first time they really make use of the second digit for the three digit chipsets
13:01karolherbst: or well
13:01rhyskidd: if so, i'll be interested to see what the tu116 chipset is!
13:02karolherbst: I guess the plan was to release those hardware under tu106, but later on it made more sense to make the difference more explicit?
13:03karolherbst: anyway, only checking the hardware itself will help us here
13:03rhyskidd: i think we all know the turing series was a weird one, held back to clear pascal stock. i imagine the ultimate marketing decisions were well after the engineering work was largely done
13:04rhyskidd: that reminds me, i need to clean up and send some patches with the last couple of devinit opcodes pre PMU intepreter, and then a series with a couple of the new volta+ devinit opcodes
13:04karolherbst: yeah, that would be helpful
13:04karolherbst: to nouveau or envytools?
13:04rhyskidd: we don't seemingly need to handle the PMU interp ones in the kernel, but it should help in understanding what devinit scripts are doing
13:04rhyskidd: there's one pre-PMU interpreter one for nouveau + envytools
13:04karolherbst: it would have been useful to me once as I had to "bisect" the devinit script
13:05rhyskidd: the post-PMU interpreter ones are just envytools
13:05karolherbst: so I ran in on the kernel instead of the pmu
13:05karolherbst: but yeah.. missing opcodes
13:05karolherbst: anyway, if somebody adds those to envytools, we can add it to the kernel later on
13:06rhyskidd: i also want to test your runpm patches for a bit longer
13:06rhyskidd: but they are looking good so far! thanks
13:06rhyskidd: (on gp107)
13:06rhyskidd: i think we have the same xps ...
13:06karolherbst: so yeah, the same
13:07karolherbst: with the secboot workaround?
13:07rhyskidd: so I need to add the secboot turn-it-on-and-off again patch as well
13:07rhyskidd: just running a kernel with runpm series atm
13:08karolherbst: well you need it if you start booting the graph engine, like if you start use OpenGL or something
13:08rhyskidd: i haven't really had a chance to test it properly, so don't take my reports as "final" yet ...
13:08karolherbst: had to improve it a little: https://github.com/karolherbst/nouveau/commit/0f5fb210e2202f6b8ff3e06590ce85ffa81b0171
13:09rhyskidd: ok, thanks
13:20karolherbst: rhyskidd: thanks for testing by the way.
13:20karolherbst: but I also kind of wished some pci folks would chime in on the list :/
13:20karolherbst: sadly.. they don't
13:24karolherbst: ohh wait, we runtime suspend the controller as well...
14:13skeggsb: rhyskidd: 171.540649 read32 #3 +0x00000000 -> 0x167000a1
21:55rhyskidd: skeggsb: ok, thanks