16:29 pmoreau_: pendingchaos: Not yet :-/ I’m going to test some other patches with my GM206, so I’ll try to test it at the same time, if I remember how the setup works to get Steam games to use the Mesa stack I want.
17:17 karolherbst: pmoreau_: shell script and put "name_of_your_shell_script %command%" as the command line for that game
17:20 pmoreau_: karolherbst: Okay.
17:35 pmoreau_: pendingchaos: I’m getting an assert: "nvc0/nvc0_transfer.c:587: void nvc0_cb_bo_push(...): Assertion `offset + words * 4 <= size' failed."
17:38 pmoreau: (I applied the patch on top of latest master; let me try latest master without the patch.)
17:41 pmoreau: I don’t hit that assert if I don’t apply the patch.
17:42 pendingchaos: perhaps you can try changing "nvc0->state.uniform_buffer_bound[s] = 65536" to "nvc0->state.uniform_buffer_bound[s] = MAX2(65536, align(size, 0x100))"?
17:42 pendingchaos: I've gtg
17:42 pmoreau: Okay, no worries
18:05 pmoreau: pendingchaos: Same issue unfortunately :-/ I tried inserting a debugger, but I get SIGSEGV in glapi, on the "OpenGL dispatch" thread.
18:15 pendingchaos: try removing the uint32_t -> bool change in nvc0_screen.h
18:15 pendingchaos: that's probably causing it
18:16 pendingchaos: It was something I was experimenting with but forgot to fully revert
18:16 pendingchaos: pmoreau: ^
18:16 pmoreau: Okay, one sec
18:17 pmoreau: And keep the previous 65536 change?
18:17 pendingchaos: the MAX2(...) shouldn't be needed
18:25 pmoreau: Ah, yes, I can see how forcing that field to 0 or 1 could be undesirable.
18:26 pmoreau: pendingchaos: \o/
18:26 pmoreau: It’s working!
18:27 pendingchaos: it doesn't assert or it's artifact free?
18:27 pmoreau: Both :-)
18:27 pmoreau: I haven’t tried playing the game, but at least I no longer have those artefacts on the menu screen.
18:29 pmoreau: And you were right: the MAX2 thing is not needed.
18:30 pmoreau: pendingchaos: Good job, and thanks for the fix! :-)
18:33 pendingchaos: nice to know it fixes it
19:15 Lyude: nooo, why are we abusing drm_kms_helper_poll_enable() ;;
19:40 karolherbst: Lyude: do we?
19:44 karolherbst: Lyude: mhh, now I basically removed all the set power state calls and the GPU still doesn't wake up
19:45 Lyude: karolherbst: yes
19:45 karolherbst: but it also suspends, and I have no clue what actually do it
19:45 Lyude: we enable polling from the hotplug detection work
19:45 Lyude: which makes absolutely 0 sense
19:46 Lyude: so that's definitely not staying in nouveau
19:49 karolherbst: ohh
19:51 karolherbst: mhh "pci_raw_set_power_state: 7 callbacks suppressed"
19:53 karolherbst: Lyude: I tihnk all that pci stuff we do inside nouveau is done for those old _DSM based GPUs
19:53 karolherbst: which the pci subsystem doesn't manage
19:54 Lyude: i'd assume it is
19:54 karolherbst: no
19:54 karolherbst: the pci subsystem only handles the _PR3 ACPI methods
19:54 karolherbst: the old stuff is only implemented inside nouveau
19:54 karolherbst: that's basically the reason why d3cold doesn't work at all
19:54 Lyude: no I meant the pci stuff in nouveau, I'd assume you're correct
19:54 karolherbst: ahhh
19:55 Lyude: gah, there is a lot of stuff that is going to need to be fixed in nouveau's modesetting that i regret uncovering
19:55 karolherbst: which also means that you don't need bbswitch with bumblebee anymore on those _PR3 GPUs
19:55 karolherbst: as the kernel handles that already if you set the power control to auto
19:58 airlied: karolherbst: don't you need to call a special method prior to _PR3 to get cold?
19:58 karolherbst: no
19:58 karolherbst: _PR3._OFF is the ACPI handle for putting the device into d3cold on the XPS afaik
19:58 karolherbst: they added a firmware hack to only set it to d3hot
19:59 airlied:could've sworn when I wrote this first there was a magic flag saying on next _PR3 go cold
19:59 karolherbst: maybe we do have to do something before otherwise the device dies? dunno
19:59 karolherbst: airlied: maybe it depends on the firmware?
19:59 airlied: but I haven't really woken up yet and it was many years ago
19:59 karolherbst: but I don't think the ms docs say anything about that
19:59 airlied: yeah I think it was a W541 I had
19:59 airlied: but I could also be confusing ancient DSM and modern DSM
19:59 karolherbst: https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/firmware-requirements-for-d3cold
20:00 airlied: as opposed to modern DSM and PR3
20:00 karolherbst: might be, yes
20:00 airlied: yeah I think I must be
20:00 karolherbst: there is some driver opt in for d3cold though
20:00 karolherbst: but this is more like the driver saying, yeah I can do that
20:01 karolherbst: airlied: the XPS firmware is also a bit weird
20:02 karolherbst: as the device doesn't enter d3cold as long as the power supply is connected
20:03 karolherbst: or maybe it is the kernel
20:05 karolherbst: mhh, allthough, I am sure it is the kernel
20:05 karolherbst: because I know that the ACPI methods put the GPU to sleep immediatly
20:05 karolherbst: but then again, I have no clue why the device is kept awake when the power is plugged
20:07 airlied: karolherbst: they probably assume if the power is plugged in, you don't care :-P
20:08 nyef: It's not like it could affect battery recharge time or anything, right?
20:08 airlied: I'm sure they had focus groups and everything :-P
20:09 karolherbst: :(
20:09 karolherbst: but heat!
20:09 karolherbst: anyway
20:10 karolherbst: I think I write a new module to debug that stuff
20:10 karolherbst: a module which only claims the device and provides runtime_* stubs
20:10 nyef: All power outlets are in air-conditioned areas, so heat doesn't matter, obviously.
20:10 karolherbst: nyef: my hands claim otherwise
20:10 nyef: So does my lack of air-conditioner. What's your point?
20:13 airlied: karolherbst: isn't that bumblebee? :-)
20:14 karolherbst: no
20:14 karolherbst: I think they had a wip branch to do that
20:15 karolherbst: though
20:15 karolherbst: bbswitch didn't claim the device
20:15 karolherbst: it was just doing acpi stuff
20:15 karolherbst: there is this acpi-pr3 branch though
20:15 karolherbst: https://github.com/karolherbst/bbswitch/blob/acpi-pr3/bbswitch_dev.c
20:17 karolherbst: but I really want to do stubs
20:17 karolherbst: no implementation basically
20:17 karolherbst: and see how well that works
20:17 karolherbst: if it fails with an empty driver, it is a pci subsystem bug
20:18 karolherbst: or maybe something else messes with the device behind our backs
20:21 airlied: karolherbst: yeah it seems like a stub driver might be helpful for debugging
20:21 airlied: at least to see if the gpu powers back up at all
20:22 karolherbst: I am quite sure it isn't a nouveau bug itself, as I already removed all the pci power calls
20:22 karolherbst: and it still doesn't wake up correctly
20:22 karolherbst: but, I am not quite sure
20:22 karolherbst: anyway, without a driver loaded it works perfectly
20:24 karolherbst: which invovles the GPU gets turned off and I am able to use libpciaccess based tools
20:24 karolherbst: and the kernel resumes the GPU
20:24 karolherbst: allthough...
20:25 nyef: Wait, you've got a scenario where lspci and whatnot lock up?
20:25 karolherbst: ahh no, it works
20:25 nyef: Ah, okay.
20:25 karolherbst: without a driver loaded: https://gist.githubusercontent.com/karolherbst/d9458c477b2fb9267c53f012802c475e/raw/cc0e32d0598a5b182f1cc45a6d439e86ac929cb0/gistfile1.txt
20:26 nyef: I've got an lspci lockup scenario that I haven't bothered to try and diagnose. It's either a specific nvidia card or it's when I have TWO cards in that system.
20:26 karolherbst: _STA returns 0x0 when the GPU is off, 0x1 otherwise
20:26 karolherbst: nyef: yeah, that only happens when a driver is loaded
20:26 karolherbst: nyef: workaround: blacklist nouveau and set the power/control to auto for the nvidia GPU
20:26 karolherbst: this works
20:26 karolherbst: at least on my system
20:27 karolherbst: nvapeek 0 echo '\_SB.PCI0.PEG0.PG00._STA' > /proc/acpi/call ; cat /proc/acpi/call ; echo returns the nvapeek output + 0x1 of course
20:27 karolherbst: as the GPU isn't suspended yet
20:28 nyef: ... In my case, both GPUs are nvidia. One for the primary display, the other to experiment with.
20:28 nyef: Oh, and it also prevents the system from powering off.
20:28 mooch2: wow how the fuck?
20:29 mooch2: i guess you'd need to physically unplug it then :/
20:29 mooch2: or just turn off the psu
20:29 nyef: Hold the power button down for five seconds?
20:32 HdkR: Nobody needs to power hardware down anyway right? :P
20:33 nyef: HdkR: Sure we do, how else are we going to change out the video cards?
20:33 mooch2: tru lol
20:33 HdkR: PCIe hotplug of course
20:33 mooch2: yeah, i was about to say
20:33 mooch2: though that doesn't work on my motherboard so :c
20:34 mooch2: in fact, i don't think it works on MOST motherboards
20:34 nyef: Doesn't work with about half of the hardware that I have with nvidia cards.
20:34 HdkR: PCIe Surprise hotplug usually only works on server things
20:34 mooch2: on mine at least, it straight up powers off instantly if you try
20:34 mooch2: HdkR, ugh
20:34 nyef: ... Wait, half? Three quarters!
20:34 mooch2: lol
20:34 HdkR: and PCIe (non-surprise) hotplug is mostly vacant in the consumer space
20:34 nyef: Well, two of them take MXM cards, and the other is an AIO system with no slots.
20:35 nyef: The last only has two PCIe x16 slots, so there's no real way to have "enough" cards installed to test with.
22:26 karolherbst: airlied: okay... I managed to the runtime ref counter to be non 0 with a stub driver...