01:36 RSpliet: skeggsb: I hope you're not at work today, but in case you are: I sent a trace of the blob with NVAC firing up a 1920x1080 monitor to the dumps mail
01:36 RSpliet: in response to the NVAC no signal problem reported by poma that I too observed
01:37 RSpliet: I can confirm it doesn't work with 4.8, and it does work with 4.9 when I commented away the 0xac case from the workaround codename switch
01:37 RSpliet: I didn't get a 4.9 unmodified data point, sorry for that
01:40 mwk: yay, first case of weirdo hidden state found on NV4-NV1x
01:40 RSpliet: my VBIOS is in the usual repo
01:41 RSpliet: mwk: weirdo hidden state?
01:41 mwk: RSpliet: PGRAPH state not visible via MMIO regs
01:41 mwk: apparently two methods behave differently depending on what the last rendered primitive was
01:42 mwk: that's going to be a pain to model
01:43 RSpliet: ouch... that sounds unpleasant (yet not completely unsurprising for a fixed-pipeline GPU)
01:43 RSpliet: esp since that's from the pre-context switch era presumably?
01:43 mwk: so, if the last rendered primitive was a line, the GDI bitmap color 0 format is set by the format method; but if it was a rectangle, the format is set by the bitmap color 0 method
01:44 mwk: I mean, what the fuck
01:44 mwk: RSpliet: that's the 2D engine FWIW :(
01:44 mwk: there's no such thing as a "pre-context switch era" on nvidia, NV1 is already designed for context switching
01:45 mwk: and the state... doesn't even make sense
01:48 RSpliet: my failure to parse your phrase explaining the different state made me strongly believe it doesn't make sense... is that deliberate or just a hw error on the "MMIO command decoding" side?
01:48 mwk: it completely doesn't make sense, so I'd guess a hw bug
01:49 mwk: but then, I don't even see why you'd want two different settings of which method sets this piece of state
01:49 mwk: so... I'm guessing it's something done on purpose, but gone wrong
01:51 mwk: eh
01:51 mwk: I'll deal with that later, I have to finish the cleanup of existing tests first
05:41 gnurou: hakzsam: definitely. not before 01/05 though, as I am far from any board until then
05:41 gnurou: hakzsam: I think that's some fantastic work btw, thanks for this
09:25 hakzsam: gnurou: untested on gm20x though, but it's the same ISA, so it should work
09:25 hakzsam: thanks
09:28 karolherbst: by the way, it is really hard to get new devs on board here :O
09:28 pmoreau: hakzsam: Congratulations on your series and job! Et Joyeux Nowel! :-)
09:30 pmoreau: I would assume that the firmware situation is not helping.
09:30 karolherbst: pmoreau: there are some especially interested in challenges like that though
10:53 hakzsam: pmoreau: thanks, let me know if you can test the series on your gm206 :)
10:56 RSpliet: hakzsam: I'll try and dust off my TX1 after the Christmas break
11:11 pmoreau: hakzsam: I’ll give it a whirl for sure once I get back home, some time end of next week.
14:23 haagch: gnurou is here too, nice
14:23 haagch: opengl in X works fine if I revert this patch https://github.com/Gnurou/mesa/commit/a97f868a806ab4f1aaab88c72d4b55bfb18cc3cc
14:24 haagch: probably need more permissions to use card1 than to use renderD128
14:25 haagch: maybe someone else here knows this? When /dev/dri/card1 is used, nouveau_getparam(dev, NOUVEAU_GETPARAM_FB_SIZE, &v); returns -13, permission denied
14:25 haagch: does that only work for drm master?
14:27 haagch: this is with the renderonly branch from here on my tegra k1 chromebook: https://github.com/Gnurou/mesa/commits/renderonly
14:27 haagch: kmscube in a tty gives no trouble, but the ioctls in X only work as root
20:33 nyef``: Hello all. I'm trying to track down a problem with resume-from-suspend on one of my laptops, where the display starts flashing between bright white and black instead of resuming properly. The nvidia blob works fine. I've managed to get a dmesg of the entire sequence here: http://lisphacker.com/temp/m17x-nouveau-suspend-dmesg.txt and I'm wondering what my next step should be. Any hints?
20:42 karolherbst: nyef``: does it work with nouveau.runpm=0 ?
20:44 karolherbst: nyef``: nvm my comment
20:46 nyef``: Okay, I presume that that means that you expect that it won't help?
20:46 karolherbst: nyef``: could you test with a drm-next kernel? Because the display code was pretty much rewritten a lot
20:46 karolherbst: nyef``: https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next
20:47 karolherbst: branch: drm-next
20:47 karolherbst: and use --depth 1 for cloning
20:47 karolherbst: if that doesn't help, ping skeggsb, he might know more, and create a bug.
20:48 nyef``: So, "git clone --depth 1 git://people.freedesktop.org/~airlied/linux"?
20:49 nyef``: Hrm. And "-b drm-next"
20:49 nyef``: ?
20:49 karolherbst: yes
20:50 nyef``: Cloning now.
20:51 nyef``: I don't suppose there's any chance that the opengl stuff will do quad buffers with a 3dvision2 emitter, is there?
21:01 karolherbst: huh
21:01 karolherbst: honestly, I have no clue about opengl, just doing kernel stuff
21:03 nyef``: Okay, that's fair.
21:03 karolherbst: anyway, with that kernel tree you should get super stable reclocking on your gpu with nouveau
21:03 karolherbst: hopefully
21:04 karolherbst: if not, then you are one of the few with a troubling card
21:04 nyef``: Which outcome should I hope for? (-:
21:05 karolherbst: mhh, depends
21:05 karolherbst: if you wanna help out finding out why, then of course a troubling one
21:05 karolherbst: I don't have access to such a gpu
21:05 karolherbst: all I have access to work fine
21:09 nyef``: Trying to build now.
21:09 nyef``: If this works, do you have any idea of the timeframe for this hitting mainline?
21:10 karolherbst: 2-3 months
21:10 karolherbst: but you can use the rc kernels real soon
21:14 nyef``: Okay, and given one of the other things wrong with this machine I can expect to be running a patched kernel for a while anyway...
21:25 nyef``: Time for a test run, back in a few minutes.
21:33 nyef``: And I'm back. Brief garbage on the screen during resume, but then solid black. A definite improvement, but still not useful. http://lisphacker.com/temp/m17x-nouveau-suspend-drm-next-dmesg.txt
21:36 nyef``: Is that "failed to read link config" bit significant?
22:30 nyef``: Initial digging suggests that the "failed to read link config" bit should probably be expected, and that it kicks off the actual configuration and training sequence.
22:36 karolherbst: mhh
22:36 karolherbst: ask skeggsb
22:36 karolherbst: nyef``: can you switch ttys?
22:37 karolherbst: it indeed looks better than the output before
22:37 karolherbst: but I have not much knowledge about the display code
22:37 karolherbst: skeggsb wrote most of it
22:37 karolherbst: he should be around soon or maybe not due to holidays
22:38 nyef``: Haven't tried switching ttys. Would that even work if the link isn't trained, though?
22:39 karolherbst: maybe X is just messed up
22:39 karolherbst: allthough that I doubt somehow
22:39 karolherbst: I guess something isn't right
22:39 karolherbst: mhhh
22:39 nyef``: It's not X, I'm not yet at the point of running X.
22:39 karolherbst: I wanted to suggest removing the display for a short period....
22:39 karolherbst: ohh I see
22:40 nyef``: And sure I can remove the display for a short period... but not while the system is running. Laptop panel and all. (-:
22:40 karolherbst: well yeah, create a bug then on bugzilla against nouveau
22:40 karolherbst: https://bugs.freedesktop.org/
22:41 karolherbst: xorg/Driver/nouveau
22:41 nyef``: I probably will at some point, but not while I'm still have leads to chase down.
22:45 karolherbst: uhh well, your choice, you would just save you the time letting skeggsb handle this, except you want to fix it yourself in the code :)
22:46 nyef``: Sure. Right now, I'm learning stuff, which might end up in the bug report.
22:55 nyef``: So, it calls dp_set_link_config(), but then doesn't call dp_link_train_cr(), so dp_set_link_config() returned nonzero.
23:03 nyef``: Backing up a few steps, during kernel startup I see a message "aux power -> always" before the initial link training. During suspend, I see "aux power -> demand". Early in resume, I see BOTH.
23:05 nyef``: ... And the distinct impression I get here is that I should be seeing only the one, and a training sequence at that point.
23:07 skeggsb: nyef``: can you get a log with "nouveau.debug=disp=trace,i2c=trace drm.debug=0x14"
23:08 nyef``: skeggsb: Sure. Still on the drm-next kernel?
23:08 skeggsb: yep
23:09 nyef``: Trying now, back in a few minutes.
23:09 karolherbst: skeggsb: by the way, it would be nice if you take a look into my stable_reclocking_kepler_v6 and pmu_counters branches
23:10 karolherbst: skeggsb: my dynamic reclocking stuff depends on this, and I need to make a big rewrite there
23:10 karolherbst: and I actually would like to include your reviewing comments there while doing so
23:11 karolherbst: finally figured out how nvidia calculates the memory load
23:11 skeggsb: karolherbst: i'll try and get to it in the new year, give me a ping early jan as a reminder though just in case it gets lost in the storm
23:11 karolherbst: sure, will do
23:11 skeggsb: it's on my list though :)
23:11 karolherbst: :)
23:11 karolherbst: silly nvidia uses the memory and shader clocks for memory load calculations :/ this basically destroys my current design
23:12 skeggsb: hm interesting
23:12 karolherbst: yeah
23:13 karolherbst: nv_mem_load = pmu_mem_load * 100 * (engine_clock / mem_clock)
23:13 karolherbst: ...
23:13 karolherbst: nv_mem_load = pmu_mem_load * 10 * (engine_clock / mem_clock)
23:13 skeggsb: i wonder what that's all about :/
23:13 karolherbst: well
23:13 karolherbst: shader waiting on memory
23:14 karolherbst: they do busy waits
23:14 skeggsb: oh, right
23:16 karolherbst: that mem counter is still unreliable, I guess we will have to use pretty pessimistic algorithms, so that the pstate is high enough
23:16 karolherbst: or memory clock
23:16 nyef```: Looks like it overflowed the kernel log buffer, but I took copies pre- and post-suspend, so I've got all of it. Just need to stitch it together and copy it to my webspace.
23:17 karolherbst: it works perfetcly as long as I stay on the highest pstate
23:17 karolherbst: still have to check how nvidia decides which mask to set on each index, but maybe this just depends on the chipset feature or model features
23:21 nyef```: skeggsb: http://lisphacker.com/temp/m17x-nouveau-suspend-drm-next-i2c-debug.txt
23:23 nyef```: Hrm. "sink not detected", huh?
23:25 skeggsb: yes, that's slightly problematic
23:27 skeggsb: does nouveau work if you: boot with nomodeset to runlevel 3, suspend/resume, connect over ssh (or type blindly, because the screen will be black) and load nouveau ?
23:28 nyef```: Hrm. So, rebuild with nouveau as a module, then "echo mem > /sys/power/state; sleep 2; modprobe nouveau" ?