00:18imirkin: airlied: fyi, see the piglit test i just sent - i think that's why those CTS geometry tests are failing
00:19imirkin: varying packing strikes again!
00:20airlied: imirkin: nice find
00:21imirkin: no super-great ideas on how to fix it quite yet - i've hacked up my local build to not varying-pack to confirm that was the issue
08:43karolherbst: mhh odd, a 960m should do better than any intel gpu, even running nouveau, funny. But somehow Eliasvans 960m had really bad perf overall, I doubt that we are _that_ bad on maxwell
08:53karolherbst: imirkin: seems like qtwebengine disables GPU acceleration now if it detects nouveau
08:54karolherbst: QT_WEBENGINE_DISABLE_GPU and QT_WEBENGINE_DISABLE_NOUVEAU_WORKAROUND are also added (first disables GPU accel on any GPU, and second disables the nouveau check)
09:07skeggsb: meh... i guess i'll try and do *something* about it before vk
09:08pmoreau: karolherbst: Ok, I’ll add that
09:18karolherbst: pmoreau: awesome :)
09:19karolherbst: skeggsb: yeah, I doubt that vk is a good thing to begin to work on if we have multithreaded issues anyway
09:19karolherbst: and due to the nature of vk, you would have to fix them anyway
09:20karolherbst: skeggsb: one thing, there are some patches to turn mesa multithreaded and marshal all gl requests and put them into a worker thread and execute them async
09:20karolherbst: skeggsb: do you think this could at least fix inner application race conditions?
09:21karolherbst: even if an application does gl calls in multiple threads, they are executed single threaded in the worker
09:21karolherbst: skeggsb: https://cgit.freedesktop.org/~mareko/mesa/log/?h=glthread-5-rebased
09:21karolherbst: mesa_glthread=true application
09:22karolherbst: I tested this a bit and it seems to run fine for most things. shader eviciton caused some crashes though
09:24karolherbst: maybe shadow of mordor would run with that on nouveau :O
09:29Eliasvan: karolherbst: anything else I can test for you?
09:32karolherbst: No idea really, perf is low, don't know why
09:32karolherbst: ask hakzsam_ he might be able to tell you what you could try
09:32hakzsam_: for what?
09:35Eliasvan: with the well, I've got a GTX960M, and it seems to perform as good or worse than my integrated Skylake GPU
09:36Eliasvan: (I'm talking about the 0f perf level with memory reclocking at 5GHz)
09:37Eliasvan: I do have the latest nouveau live usb, so I do have envytools installed
09:39Eliasvan: 01:00.0 3D controller : NVIDIA Corporation GM107M [GeForce GTX 960M] [10de:139b] (rev a2)
09:39hakzsam_: well, performance sucks with nouveau, that'sit :) but I have something in the pipeline for maxwell which should improve perf
09:39hakzsam_: still not ready though
09:39hakzsam_: but once it's done, you might want to give it a shot
09:40Eliasvan: glxgears is the only program that performs better than integrated
09:40hakzsam_: glxgears is not a benchmark
09:40Eliasvan: yeah, I know :)
09:41hakzsam_: and my stuff is also needed for GL 4.3, so we will get more perf + GL 4.3 in one shot :)
09:42Eliasvan: hakzsam_: that's nice; I think users tend to expect better performance when support for a major new GL version is exposed, for some reason
09:42hakzsam_: but this is specific to maxwell gen though
09:43hakzsam_: fermi/kepler already epoxse GL 4.3
09:43Eliasvan: yeah, I saw that
09:46hakzsam_: oh btw, do you build your own mesa?
09:46hakzsam_: ah but you use a live usb
09:49Eliasvan: you, I use those on https://nouveau.pmoreau.org/
09:50karolherbst: hakzsam_: I think it is weird, that on his gpu, pixmark_piano doesn't perform better than intel
09:50karolherbst: or are we really that bad?
09:50hakzsam_: we are :)
09:51karolherbst: he doesn't even come close to my
09:51Eliasvan: if you want me to test anything when your patches are done, you can see my email address on https://github.com/Eliasvan/
09:51karolherbst: I get like 17 fps, he 4?
09:51hakzsam_: Eliasvan: thanks
09:51hakzsam_: karolherbst: well, I have like 3 fps on my gm107
09:51karolherbst: what model?
09:51hakzsam_: 750 ti
09:51karolherbst: and do you mean the window mode or benchmark?
09:52hakzsam_: without reclocking and without scheduler though
09:52hakzsam_: so, not toally unexpected
09:52karolherbst: he does reclock
09:53karolherbst: without reclocking, he has 2 fps
09:53hakzsam_: I will try at some point to reclock mine as well
09:53karolherbst: 960m, which is nearly as fast as my 770m
09:53karolherbst: another thing
09:53karolherbst: furmark also sucks
09:53karolherbst: I get like 50 fps, he 20
09:53karolherbst: allthough he has higher memory throughput
09:54Eliasvan: I had core clock @ 1037MHz and memory clock @ 5009MHz
09:54karolherbst: ohh, only 128 bit has the 960m?
09:54karolherbst: I though it has also 192bit
09:54karolherbst: okay, it is a little slower than mine :D
09:55karolherbst: anyway, it should be faster, even on maxwell
09:55Eliasvan: karolherbst: yeah, but for furmark, the memory reclocking at least gave 10fps extra
09:55karolherbst: hakzsam_: mind checking furmark on lower clocks?
09:55hakzsam_: I can't right now, I don't have my gm107 here
09:55karolherbst: if we are really that bad, then scheduling won't be the reason
09:56karolherbst: well, not the main one
09:56karolherbst: would be surprised if it helps with furmark at all
09:56Eliasvan: I'll test some reclocking on the GT620M right now, I'll see what that gives (I'm participating in the Fedora Switchable graphics test day)
09:56karolherbst: that 620m is really slow
09:57karolherbst: and fermi
09:57karolherbst: so no reclocking
09:57hakzsam_: scheduling will help all apps
09:57karolherbst: ohh, really?
09:57karolherbst: I seriously doubt it will help furmark :p
09:58karolherbst: we are already like 90% close to nvidia and with my tex liveonly patch we are even 105% compared to nvidia
09:59karolherbst: it's like fillrate only and nothing else matters for it
09:59hakzsam_: are you sure you are talking about maxwell? it helps a lot, x2 or something IIRC
09:59hakzsam_: and it definitely makes sense
09:59karolherbst: pmu core counter with furmark: ~2% load
10:00karolherbst: well, I hope I am wrong here though
10:00Eliasvan: karolherbst: nice job! Somehow I get the feeling that NVIDIA's firmware does a lot more to get out of the box perf (when reclocked and boosted) without much optimizations on the driver side, versus AMD, is that just an illusion?
10:00karolherbst: sure is
10:00karolherbst: the hardware is just superior in general
10:01karolherbst: I think the newest gen compared, nvidia is around 30% more power efficient
10:03Eliasvan: so you think the main trump of NV is their hardware, not their drivers, versus AMD?
10:06karolherbst: well, on linux it is actually both I think
13:42karolherbst: Eliasvan: you said you had some instabilities with the live image?
13:42Lekensteyn: Is there some contact at NVIDIA (gnurou?) who can help in this ACPI firmware-related issue? https://bugzilla.kernel.org/show_bug.cgi?id=156341
13:43karolherbst: Lekensteyn: add an issue here: https://github.com/Gnurou/nouveau/issues
13:44Eliasvan: karolherbst: well yes, I had a lockup once, when starting glxgears when in 0f mode
13:45karolherbst: can you check how often that happens?
13:45Eliasvan: sure, what do you want me to test?
13:45Eliasvan: firing up glxgears multiple times?
13:46karolherbst: run glxgears with vblank disbaled
13:46Eliasvan: yeah, that's what I always do
13:46karolherbst: while true; do echo 07 > pstate; sleep 0.5; echo 0f > pstate; sleep 0.5; done
13:46karolherbst: if you are able to reclock for minutes, it should be fine
13:46karolherbst: maybe you got unlucky or something unrelated triggered
13:46Eliasvan: OK, I'll test that
13:47karolherbst: just make sure you are in the right directory ;)
13:47Eliasvan: yeah :p
13:47karolherbst: Lekensteyn: I doubt that it is nvidias fault though
13:47Eliasvan: I'll also do a cat, then I'm sure
13:47karolherbst: or that nvidia is able to provide any information
13:48Lekensteyn: karolherbst: that repo seems related to the firmware on the GPU, this is a problem with the ACPI interface (implementation)
13:49Lekensteyn: I wonder whether NVIDIA has some specs or guidance for platform firmware implementors
13:49karolherbst: I think the specs belongs to microsoft
13:49karolherbst: and nvidia simply implement what ms tells them to
13:50Lekensteyn: it is not just a single company that makes a mistake, there are many different manufacturers making the same mistake
13:50karolherbst: there aren't that many uefi implementations out there
13:51karolherbst: most of them just share the same
13:51karolherbst: I think clevo uses megatrend?
13:52karolherbst: anyway, their uefi implementation is utter crap anyway
13:52karolherbst: I found alone 5 serious bugs in mine
13:53imirkin: Lekensteyn: gnurou works on tegra and isn't intimately familiar with the various PC-side details. doesn't hurt to ask though - IME he tries to be as helpful as he reasonably can be.
13:53karolherbst: Lekensteyn: ohh right, you should post your issue there anyway
13:54karolherbst: we used to have a mail to mail stuff to, but well… it was a /dev/null version for mails basically
13:56karolherbst: Lekensteyn: I doubt it has anything to do with the gpu at all though. Somebody should check the GPU LED and see if it turns on at all
13:57Lekensteyn: karolherbst: the at first it seems an AMI problem, but it also affects Dell, Asus and HP
13:57karolherbst: Lekensteyn: also keep in mind, that the GPU isn't even POSTed after being turned on by ACPI
13:58karolherbst: it's basically just to turning on an on/off switch
13:58Lekensteyn: I wonder if the nouveau driver should cooperate here, sending some commands before powering off
13:58karolherbst: does anybody know if this also affects modern systems with AMD gpus?
13:59Lekensteyn: so far I have only seen this issue with Skylake laptops with a Maxwell GPU (hybrid), that makes me wonder whether it is a NVIDIA-specific issue
13:59karolherbst: well in doubt uefi implementations are crap and the driver needs to hack around this
13:59karolherbst: it wouldn't be the first time they violate the spec
14:00karolherbst: Lekensteyn: also I doubt that Dell, asus and HP write their own uefi
14:01Lekensteyn: there is AMI, Phoenix (or have they been acquired?), Insyde, I also doubt that Dell, Asus, etc. write their own, but they still base it off something
14:02karolherbst: in doubt, ami :p
14:03Lekensteyn: hm, would be interesting to see the ACPI implementations from the others to see what the intent is
14:03Lekensteyn: I'll follow imirkin's suggestion for now, asking cannot hurt I guess :)
14:03karolherbst: the uefi stuff should be inside the vbios I think
14:04karolherbst: not sure
14:04karolherbst: but seriously
14:04karolherbst: I doubt that the GPU has anything to do with that at all
14:04karolherbst: what can you expect from a non POSTed gpu?
14:06Lekensteyn: maybe there are some PCIe registers (link power state?) that have to be configured in some way
14:06Lekensteyn: then hopefully the driver team has some experience here
14:06karolherbst: I looked into the pcie stuff myself at some point
14:06karolherbst: the gpu does everything itself basically
14:07karolherbst: the registers are just interfaces to the pcie implementation on the gpu itself
14:09Lekensteyn: if you could guess, what could be a possible reason why one method (line 119) breaks (cannot power on) while another (line 140) works properly? https://github.com/Lekensteyn/acpi-stuff/blob/master/Clevo-P651RA/notes.txt#L119
14:11karolherbst: Lekensteyn: the loop doesn't end?
14:12karolherbst: that Q0L0 sounds odd
14:12karolherbst: I guess it has to be set to Zero somewhere
14:13karolherbst: yeah, I think the second method doesn't depend on external stuff, but the first one does
14:13karolherbst: the loop can't run forever int he second method
14:14Lekensteyn: Q0L0 is a register in the PCIe MMIO afaik
14:15Lekensteyn: the full, original ACPI source is at https://github.com/Lekensteyn/acpi-stuff/blob/master/dsl/Clevo_P651RA/ssdt3.dsl#L4001
14:16karolherbst: mhh, doesn't help really
14:16karolherbst: do you know which reg it is?
14:16karolherbst: if in doubt, you could just poke 0x0 into all regs starting with 0x88000 and 0x8c000
14:17Eliasvan_: karolherbst: after about 3 iterations of the while loop, I get a hang
14:17karolherbst: k, 3 is bad
14:17karolherbst: did it recover?
14:17karolherbst: and what did you get in dmesg?
14:17karolherbst: ohh wait, it is dri2, so X is totally screwed, right?
14:19Eliasvan_: karolherbst: I set it to DRI 3 before X started
14:20karolherbst: I see
14:20Eliasvan_: Git still hangs
14:20karolherbst: okay, then you also need this
14:20Eliasvan_: I'm not sure I can get the dmesg right now, maybe with ssh
14:21karolherbst: and install the dummy X driver
14:21Eliasvan_: but I don't think so since also the Intel locks up
14:21karolherbst: use that x config file
14:21karolherbst: this helps
14:22karolherbst: Lekensteyn: do you have a machine with this issue?
14:23Lekensteyn: karolherbst: with the lockup issue? Yes, a Clevo P651RA
14:24Lekensteyn: and I can only guess what the Q0L0 register is, I could not find it in the Intel register documentation for the PCIe stuff
14:25karolherbst: Lekensteyn: k, then I guess you should get the situation and do: nvapoke 0x88000 0x1000 0x0 and nvapoke 0x8c000 0x1000 0x0
14:26Lekensteyn: does that work if all other registers normally read back as 0xff?
14:26Lekensteyn: lspci -H1 does not even show the PCI device when the problem occurs
14:27Eliasvan_: karolherbst: thanks! nice document BTW; what is the key thing that your xorg.conf.d.nouveau.conf does? only setting DRI3 for Intel?
14:27Eliasvan_: oh, I see, the dummy driver
14:27karolherbst: load dummy for the nvidia gpu
14:30karolherbst: and make sure the right pci address is set
14:37Lekensteyn: filed a report at https://github.com/Gnurou/nouveau/issues/21, hopefully it is complete enough
14:38karolherbst: Lekensteyn: well if you want to wait 2+ months, then this is fine ;)
14:38karolherbst: Lekensteyn: but you should really try out that setting the pci regs to 0x0
14:38karolherbst: this may do _something_?
14:38karolherbst: and if that didn't help, try 0xffffffff
14:39Lekensteyn: karolherbst: set it before hitting the problem or after? (I can try, no idea if it works if even the normal PCI config space cannot be accessed)
14:45Lekensteyn: karolherbst: should I fill in 0xffffffff instead of 0x0 if it does not work? What does it do, POSTing the card?
14:47karolherbst: it does nothing smart, but if the firmware expects a certain reg to be set in the pci space, this is the best we can do
14:47karolherbst: even if it messes up the pcie things slightly
14:48Lekensteyn: ok, rebooting for test:)
15:01imirkin_: Lekensteyn: that bug has *very* few details. i'm not intimately familiar with all these details, but i know them a little, and it makes no sense. i'd recommend following up with a summary of your investigation and a more concrete question than "please fix my buggy code".
15:02imirkin_: unless all you really know is "it doesn't work"
15:09Lekensteyn: karolherbst: unfortunately, nvapoke is not helping, stuck in pci_config_pm_runtime_get
15:10Lekensteyn: imirkin_: ok, I'll try to add some things I have already tried
15:10karolherbst: Leftmost: nvapeek 0x0
15:10karolherbst: Lekensteyn: ^^
15:16Lekensteyn: karolherbst: nvapeek seems to access the PCI config space through sysfs, it will not work and hang because nouveau has not runtime-resumed yet
15:16Lekensteyn: maybe I could try bbswitch
15:16karolherbst: doesn't matter
15:16karolherbst: those tools work without any driver at all
15:17karolherbst: except the kernel blocks it, then we are screwed anyway
15:17karolherbst: and if nvapeek doesn't work, nvapoke won't either
15:17Lekensteyn: then we are screwed :)
15:17karolherbst: … silly sysfs
15:17Lekensteyn: 'cause when nouveau is loaded, pci config space cannot be read when runtime suspended
15:18karolherbst: uhm :/
15:18karolherbst: where does it hang in nouveau?
15:18imirkin_: iirc his issue is that resume doesn't work
15:19karolherbst: seems like we have to try those pokes within the module
15:19imirkin_: so ... not a ton you can do.
15:19Lekensteyn: I could try not to load nouveau and see if I can reproduce the problem and hopefully be able to use nvapeek/nvapoke
15:19imirkin_: should be able to wake the device up by hand by echo'ing stuff into sysfs
15:19imirkin_: behind nouveau's back
15:19imirkin_: not sure
15:19karolherbst: Lekensteyn: can you create the same situation with bbswitch?
15:20karolherbst: k, then this would work
15:22Lekensteyn: last time (a few minutes ago) the machine completely locked up, rebooting again to retry with bbswitch.
15:22Lekensteyn: what does nvapeek 0x0 do? just a sanity check?
15:23Eliasvan_: karolherbst: again locked up, now with your config, this time about 4 iterations; I made dmesg stream and sync to USB stick, so maybe I got lucky and have some info
15:23karolherbst: Eliasvan_: but X is still happy, right?
15:24Eliasvan_: uhm, no, my moue is locked up
15:25karolherbst: … silly X
15:25karolherbst: maybe something more serious is going on
15:35Eliasvan: karolherbst: it appears that I wasn't able to catch any line in dmesg at the moment of the hang
15:37Eliasvan: but before I ran the test, when I fired up glxgears, I did have three moments where everything hung for about 10s, I did capture that dmesg however: see [2797.996088] at http://pastebin.com/6H0FnpS1
15:38imirkin_: [ 4.136564] nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 022554 [ IBUS ]
15:38imirkin_: wtf is that
15:38Eliasvan: I did also capture the pstates sent to the GPU before it hung: http://pastebin.com/aBgAEH2b
15:44karolherbst: imirkin: "[drm] GPU HANG: ecode 9:0:0xfffffffe, reason: Hang on blitter ring, action: reset" any idea?
15:45karolherbst: this sounds like an intel error though
15:45karolherbst: Eliasvan: it looks like intel messes up, not nouveau
15:45imirkin_: yeah, that's intel
15:45Eliasvan: could be, Skylake doesn't seem to be in perfect condition stability wise, to be honsest
15:45imirkin_: woohoo, we're not the only ones with bugs!
15:46karolherbst: mhh odd
15:46Eliasvan: sounds like a small victory moment here? :P
15:46karolherbst: on my system I stress tested with around 600 reclocks per second
15:46karolherbst: and this worked for hours
15:47karolherbst: but I am somewhat lucky with my gpu, no clue why, but I hardly have any issues anyway
15:47karolherbst: Eliasvan: I guess intel can't handle that many frames
15:47karolherbst: Eliasvan: try with fullscreen glxgears
15:47Eliasvan: but that doesn't mean both issues are related, I wasn't reclocking at the moment those dmesg lines showed up
15:48karolherbst: imirkin: maxwell gpus always have those IBUS faults
15:48Eliasvan: karolherbst: OK, I'll remember, but now I can't test for a moment, have to go
15:48Eliasvan: thanks guys :)
15:50karolherbst: k, so maxwell reclocking looks stable enough then
15:51imirkin_: karolherbst: i don't think so
15:51Lekensteyn: karolherbst: I get "PCI init failure!" with nvapeek 0x0 (also tried modprobe nouveau runpm=0, does not make a diff.) strace shows -EINVAL for mmap something on /sys/bus/pci/devices/0000:01:00.0/resource0
15:51Lekensteyn: oh ffs nvidia is somehow loaded, sorry
15:51imirkin_: they have those HUB0 things
15:51imirkin_: but not the ibus fault
15:51karolherbst: I saw both
15:51karolherbst: I think
15:53imirkin_: well, let me put it another way - the IBUS thing isn't normal
15:53imirkin_: even if they all get it ;)
16:03Lekensteyn: karolherbst: ok, did two attempts, w/o blob nor nouveau loaded. Both times nvapeek shows "PCI init failure" after the failure event and the two nvapoke commands result in an full system lockup (even sysrq is not working)
16:04Lekensteyn: (cursor stops blinking, full system lockup)
16:05karolherbst: so bascially, even the drive wouldn't be able to do anything about it
16:05karolherbst: except something has to be done before going into suspend
16:14karolherbst: Lekensteyn: isn't there somewhere else in the uefi a reference to that field?
16:15Lekensteyn: I could not find such a reference (or did not try hard enough)
16:15Lekensteyn: one surprising thing is that I have to try OFF/ON/OFF/ON/.. multiple times with bbswitch until the lockup is triggered
16:15Lekensteyn: with nouveau it happens always at the first try
16:15Lekensteyn: that was even before the changes in 4.8
16:15karolherbst: and the lockup means the ACPI function doesn't finish?
16:16Lekensteyn: yes, but even if it finishes, the card is still off
16:16karolherbst: this is useless then
16:16karolherbst: so it isn't the same issue
16:16Lekensteyn: there is an infinite loop where it polls for the link state, at some point the kernel decides there is an infinite loop and stops the ACPI method
16:16karolherbst: well, it kind of is though
16:16Lekensteyn: it is the same
16:16Lekensteyn: how not?
16:16karolherbst: if the gpu stays of, nouveau can't communicate with it
16:17karolherbst: but then again, the fix has to be done before suspending or something else has to be done through ACPI
16:18karolherbst: I think the latter is the right approach, some acpi call is missing
16:18karolherbst: or a parameter isn't right
16:19Lekensteyn: I doubt it is another ACPI call, there was no such method in the traces I did against Windows 10
16:25karolherbst: maybe the device has to be set to D0 state before trying that acpi call? I have no idea how that power state handling works currently
16:46orbea: I tried the proprietary game SOMA (gog version) and it seems to work well, just steam in a select few areas is wrong with nouveau. llvmpipe unfortunately blackscreens, but I sent the trace to a friend and he was not able to reproduce it with amd. scrot: http://ks392457.kimsufi.com/orbea/stuff/pics/scrots/2016-11-03-094102_1680x1050_scrot.png with amd: https://share.riseup.net/#-Vxijkx6HQnQLDiA5vgmcw trace:
16:46orbea: http://ks392457.kimsufi.com/orbea/stuff/trace/Soma.bin.x86_64.trace.xz (kind of large, no savestates...)
16:46orbea: steam as in hot air
16:46karolherbst: orbea: looks good
16:47karolherbst: create a bug report with the apitrace then
16:47orbea: alright, will in a little bit :)
16:47karolherbst: and how large is large?
16:47karolherbst: sounds okay
16:47orbea: ~600 MB compressed with xz -9, ~900 uncompressed
16:48orbea: i prefer them to be smaller, but its hard when you gotta proceed through menus...
16:48karolherbst: everything below 10GB is not considered big :D
17:16orbea: bug report (hope I did it right): https://bugs.freedesktop.org/attachment.cgi
17:17orbea: err https://bugs.freedesktop.org/show_bug.cgi?id=98577
17:21imirkin_: orbea: little piece of advice - when you're recording traces, use a low resolution.
17:22imirkin_: orbea: is the initial load screen supposed to be all messed up?
17:22imirkin_: i guess so just glancing at it...
17:22imirkin_: (like "initializing" appears to have a weirdo scanline type issue on it)
17:22orbea: i think so
17:23orbea: the game uses a lot of effects for style
17:23imirkin_: orbea: fwiw that steam thing looks fine on i965/SKL with mesa 13.0
17:23orbea: and i will keep that in mind for future traces
17:23orbea: so it seems only nouveau
17:26orbea: at least the effects kind of add to the game....
20:05karolherbst: hakzsam_: how stable was the shadow of mordor benchmark for you? or did pmoreau test this?
20:05karolherbst: what about threading crashes?
20:06hakzsam_: it didn't crash
20:06karolherbst: it does for me
20:06karolherbst: you sure?
20:07karolherbst: do you know games which crash for you, which use threading a lot?
20:07hakzsam_: no, I don't launch a bunch of games
20:08karolherbst: mareks threaded gl branch seems to help though
20:09karolherbst: would be interesting if it also fixes qtwebengine stuff
20:10hakzsam_: karolherbst: do you have a mmiotrace from gm107? I would like to extract the firmware
20:10karolherbst: I have not such gpu, but in the repository should be enough
20:10hakzsam_: can you remember the names of that repo?
20:10karolherbst: what do you mean?
20:10hakzsam_: is there a repo with mmiotraces?
20:11karolherbst: the vbios one
20:11hakzsam_: ok, thanks
20:11hakzsam_: cloning :)
20:12karolherbst: how did you even survive without it...
20:12hakzsam_: I just don't look at vbios
20:12karolherbst: well, you want to look at traces ;)
20:12hakzsam_: and I'm lazy to do a mmiotrace myself :)
20:13karolherbst: if mareks threaded gl lands, we should enable it by default for nouveau I guess
20:13karolherbst: maybe not
20:13hakzsam_: he added a new cap for that?
20:13karolherbst: but tell users they should if they get plasma crashes
20:13karolherbst: it's a gallium thing
20:13hakzsam_: ah right
20:14karolherbst: mhh, performance seems much worse though in shadow of morder, big surprise
20:14karolherbst: uhh, a lot
20:14karolherbst: it's like just 50% as fast
20:15karolherbst: k, I need an application which crashes for sure
22:05s0be: so finally found time to upgrade and reboot. Pulled in the latest git xorg nouveau driver... am I hallucinating, or does it seem to be 'smart' now and able to selectively offload apps that use gl?
22:06s0be: yeah, I appear to be hallucinating.
22:27s0be: and dri_prime seems to pretty easily freeze up the system. You'd think the latest bleeding edge of git would be more stable than that ;-) Chips with support only recently added are OBVIOUSLY production ready right?
22:30s0be: oh, should add, gm107
22:47Lekensteyn: s0be: doesn't DRI_PRIME=1 bypass the DDX driver in which case only the kernel version matters?
23:13s0be: Lekensteyn, hmmm, not sure. This is my first time trying nouveau+intel hybrid. Prior it was always just modesetting+intel
23:16Lekensteyn: s0be: what specific GPU, laptop and kernel version do you have?
23:16Lekensteyn: (or is it a desktop?)
23:21s0be: Lenovo P50 - Xeon CPU (P530 gpu) - Quaddro M2000M (GM107GLM)
23:22s0be: Kernel is linux next from before plumbers, 4.9.0-rc2 (dirty cuz, I'm tinkering with some wifi shit)
23:23s0be: I don't ever actually use the discrete gpu for productive things, it's a pure dev machine, but occasionally I try things out for fun
23:27Lekensteyn: could you upload your acpidump?
23:31airlied: s0be: there we some fixes in drm-fixes for powering off one newer hw
23:31airlied: not sure if Linus has pulled them in yet
23:33airlied: doesn't look like it yet
23:34s0be: Lekensteyn, yeah, I did a while back. Let me see if I still have a reference to it somewhere. I can pastebin the decoded version if you want, or decompile a specific table and pastebin the method you're looking for.
23:35Lekensteyn: s0be: the whole acpidump would be nice, then I can run acpixtract and iasl and have all tables in one go
23:35s0be: airlied, yeah, those should be in this tree, it's the 'stuff destined for 4.10' test merge tree Stephen Rothwell does
23:36s0be: sure, will throw it somewhere real fast.
23:37Lekensteyn: s0be: I am hypothesing that you suffer from https://bugzilla.kernel.org/show_bug.cgi?id=156341 , but only an acpidump can tell for sure
23:37s0be: nah, it off/ons fine for me all the time
23:43Lekensteyn: interesting, your laptop unconditionally executes the code that works (that is, it does not have the alternative code that causes the issue I linked)
23:44Lekensteyn: can you check whether "freezing" comes from runtime PM or just from the workload?
23:44s0be: My repro case is DRI_PRIME=0 glxgears in 1 term, and DRI_PRIME=1 glxgears in another term
23:45s0be: if I do one or the other, repeated times, they're ifne
23:46s0be: checking glxinfo, DRI_PRIME is definitely working, and the framerates change depending on which I choose. I really need to get something with Intel AMT setup so I can get a serial log for stuff on this machine.
23:47s0be: It's 'enough' of a lock that sysrq won't trigger a reboot.
23:49Lekensteyn: "one or the other = fine"? then when does it break?
23:55s0be: Probably just related to using the bleeding edge xf86-video-nouveau. I just triggered it with just a DRI_PRIME'd glxgears.
23:55s0be: worked for 3s, then mouse started stuttering then deadlock'd system
23:56s0be: with no way to get useful kernel logs during this, my testing is mostly useless.