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