01:49RSpliet: mupuf: do you have a titan?
01:51RSpliet: or a GTX780-like high-end GPU
02:01mupuf: RSpliet: of course, I am a freaking millionaire
02:01RSpliet: Intel pays well, doesn't it :-P
02:02mupuf: no complaints there :D But I would rather save the money or use it for travelling than getting a card that noone else cares about using nouveau on
02:03RSpliet: fair enough
02:03RSpliet: I'm just looking around to see if I know anyone with such excessive hw ;-)
02:14mupuf: RSpliet: what for?
02:14RSpliet: research on ctxswitches
02:51kivutar: Hi, If I get errors like that while compiling mesa, what packages should I upgrade?
02:51kivutar: mesa-11.2.0-rc1/src/gallium/drivers/nouveau/nouveau_screen.c:153:4: error: implicit declaration of function 'nouveau_drm'
02:52kivutar: my libdrm is up-to-date
02:52RSpliet: kivutar: sure you're trying to build against the right libdrm headers?
02:54pmoreau_: I would expect `nouveau_drm()` to have been around for quite some time
02:54RSpliet: pmoreau_: have the parameters changed recently?
02:54pmoreau_: Maybe? I'll have a look
02:58kivutar: RSpliet, I think so, I'm building all from source, with openelec build system (an automated LFS)
02:59kivutar: I'm using libdrm 2.4.67
03:00RSpliet: that's sufficiently up to date
03:01pmoreau_: Right, it was added by https://cgit.freedesktop.org/mesa/drm/commit/nouveau/nouveau.h?id=b845d61de93c762f73463a67a634ecb1ae8c4c35 on 2015-12-22.
03:01pmoreau_: But I do have that function define with 2.4.67
03:06kivutar: i'm cleaning, rebuilding and reinstalling libdrm just in case
03:12kivutar: it doesn't fix the problem
03:12pmoreau_: karolherbst: The new patch still works (for MMIO) :-)
03:13karolherbst: pmoreau_: awesome :)
03:13kivutar: I do have --enable-libkms and --enable-nouveau
03:13pmoreau_: kivutar: Check that it's using the correct headers, as RSpliet pointed out.
03:15kivutar: yeah, you're right, I don't see any other explanations
03:16pmoreau_: Wait a second: `nouveau_drm()` is defined in `libdrm/nouveau/nouveau.h`, but `nouveau_screen.c` only includes `libdrm/nouveau_drm.h`which doesn't include `libdrm/nouveau/nouveau.h`...
03:18pmoreau_: But `nouveau_context.h` does include it, and it is included by `nouveau_screen.c`, so it should work
03:21RSpliet: kivutar: just out of interest: what compiler are you using?
03:25karolherbst: ohhhh wait
03:26karolherbst: what is his issue?
03:26karolherbst: I had once an issue after upgrading libdrm to 2.5.67
03:26karolherbst: caused by stalled files inside include/libdrm
03:27karolherbst: kivutar: if you use a local installation of libdrm and you are upgraded to 2.4.67, remove include/libdrm and install it again
03:27karolherbst: and see if that helps
03:34kivutar: ok, I was able to sort it, there were a deprecated header in my tree taking precedence over the new one
03:34kivutar: you were right, thanks for the help!
03:35RSpliet: glad it's sorted out!
03:36hansg: Hi aLl, I'm currently working on fixing an issue where the second DVI output on a quadro fx 380 does not light up. I've been comparing the bios scripts executing of nouveau vs a mmio trace of the blob
03:37hansg: Weirdly enough this card seems to use 2 different scripts for its 2 different connectors. skeggsb thought this might be an issue with how we pick the script, but the blob seems to be doing the same
03:38RSpliet: whoa, few steps back :-P it's a G96 - they can only drive 2 monitors at a time - hence I assume it's just the two DVI monitors
03:38RSpliet: is any of the two outputs trying to use dual-link DVI?
03:38hansg: At least the first couple of register accesses done by the blob on supervisor interrupt 0x20 match those nvkm does, only after a few writes things start diverting. So I think we may be interpreting the script for the second dvi connector wrong
03:39hansg: RSpliet, coorect, only 2 dvi connectors on the card, I'm using a single link dvi monitor, which works on the first connector but not on the second.
03:39hansg: Note the above all was meant as intro do my actual question, which is easy to answer I think:
03:39RSpliet: oh so it's not even a dual-monitor set-up :-) sorry, carry on
03:40hansg: How do I dump the bios (x86_64 machine) and extract / decompile the scripts
03:40pmoreau_: It seems that dual monitoring / internal laptop screen + external monitor, isn't working really well with G96s...
03:40RSpliet: assuming you're after the VBIOS your best bet is grabbing the VBIOS from debugfs
03:40hansg: (so that I can compare them manually with what the blob mmiotrace shows and with what nvkm does)
03:40RSpliet: you can look inside it using envytools' nvbios tool
03:41hansg: RSpliet, ack I want the VBIOS (specifically the scripts)
03:41hansg:fires up the test machine (I've only been looking at traces gathered yesterday so far)
03:42RSpliet: make sure it loads nouveau, NVIDIA is not so kind to provide the vbios in debugfs ;-)
03:42hansg: Good one, so I just copy that file and then run nvbios on it ?
03:43hansg: Sounds easy, I was wondering why there wasn't a wiki page for this, but if its that easy that explains :)
03:44karolherbst: there should be
03:44karolherbst: but then again, the pages are hardly updated :/
03:44hansg: I couldn't find it, might be just me though
03:45karolherbst: we really should update the wiki
03:45pmoreau_: hansg: Regarding the backlight patch, `bl_interfaces_nbs` should have been `bl_interfaces_nb`. No idea why an 's' decided to join.
03:45RSpliet: could be helpful grabbing a copy of your strap register as well (nvapeek 0x101000 > strap_peek), so that nvbios knows which entry to pick for those multi-pick register writes
03:45RSpliet: karolherbst: I agree, but I recall it's quite a pain to get wiki write access (I wouldn't know my password anymore for sure :-P)
03:45karolherbst: RSpliet: fdo account
03:46karolherbst: I don't have one anyway
03:46hansg: pmoreau, maybe when I figure out why the second dvi connect is acting up, the fix will help second displays on laptops too
03:46hansg: could be it has the same root cause
03:46pmoreau_: RSpliet: I'm sure I forgot the password, and the SSH key used might have been deleted some time ago as well. :-D
03:48RSpliet: the faff around the wiki is not really helping :-P
03:48pmoreau_: hansg: FYI, I have the same problem on my laptop (using the mini-DP output), but only with some adaptors. It did work with a DP -> HDMI (but flickered horribly when starting some GL program), but didn't work with DP -> DVI (or maybe the opposite)
03:49karolherbst: let just move the wiki to github :D
03:49karolherbst: there we have a git tree of the wiki and we can accept even PRs for the wiki
03:49RSpliet: I propose we take an approach that leads to *less* faff if you don't mind
03:49karolherbst: but to be honest
03:50mupuf: karolherbst: the wiki is already a git repo
03:50karolherbst: I was thinking about creating a nouveau organisation and move nouveau in there and have multiple groups with different access rights or something
03:50karolherbst: mupuf: ahhh I see
03:50karolherbst: mupuf: you just need a fdo account?
03:50mupuf: just a wiki account, need one?
03:50RSpliet: mupuf: I need mine recovered :-P
03:50pmoreau_: karolherbst: Let's move it to the fdo phab instance
03:50karolherbst: I have none, might come in handy
03:51mupuf: RSpliet: and you have no fd.o account yet? :o
03:52mupuf: just PM me the htpasswd
03:53karolherbst: mhh how do I get htpasswd? :D
03:53mupuf: karolherbst: read the page :D
03:53karolherbst: I mean the binary
03:54karolherbst: I bet it is part of apache or something
03:54mupuf: use the browser one then
03:55mupuf: I see, just reported the bug
03:55karolherbst: there is app-admin/apache-tools
04:41fdiebold: hi - I've got a thinkpad W540 with a Quadro K1100M and Optimus and I'm trying to attach an external monitor via displayport. this actually worked fine with linux 3.16, but on any kernel since, the monitor doesn't turn on; when I try hotplugging it, the system just hangs for a few seconds. anyone got an idea what to do?
04:41fdiebold: http://pastebin.com/CQsucnK0 here's the dmesg when hotplugging the monitor
04:42karolherbst: fdiebold: if the ports are wired to intel, it is an intel bug, not nouveau
04:48fdiebold: karolherbst: I was under the impression that the DP port was wired to the discrete card, but I admit there's not a lot of nouveau in that dmesg
04:49karolherbst: yeah well, you are better of if they are wired to the intel one anyway
04:49karolherbst: be lucky
04:51karolherbst: mwk: you encountered something funny with movw on fuc5?
06:16hansg: Ok, I think I've found the bug, the problem is this bit of nvbios script:
06:17hansg: 0xbc78: 75 0f CONDITION 0x0f
06:17hansg: 0xbc7a: 38 NOT
06:17hansg: 0xbc7b: 76 05 IO_CONDITION 0x05
06:17hansg: 0xbc7d: 5b df bc CALL 0xbcdf
06:17hansg: 0xbc80: 72 RESUME
06:18hansg: Hi Ilia, excellent timing I've a problem you may be able to help with
06:18imirkin: Jayhost: urghhh... demmt needs to be updated for the new nouveau ioctl stuff :(
06:18hansg: Also good morning
06:19imirkin: hansg: you're on irc! has the world ended?
06:19hansg: So nvkm is behaving differently on a bios script then the blob
06:19hansg: imirkin, who knows, maybe ?
06:19mupuf: hansg: good to see you here
06:19imirkin: that'd be nice, then you wouldn't have to worry about this stupid vbios issue :)
06:19hansg: The problem is this script (bit) :
06:20hansg: 0xbc78: 75 0f CONDITION 0x0f
06:20hansg: 0xbc7a: 38 NOT
06:20hansg: 0xbc7b: 76 05 IO_CONDITION 0x05
06:20hansg: 0xbc7d: 5b df bc CALL 0xbcdf
06:20hansg: 0xbc80: 72 RESUME
06:20imirkin: oh, i remember IO_CONDITION 5
06:20imirkin: you're not running on an ancient kernel are you?
06:20hansg: Both conditions are false, yet the blob does the call 0xbcdf
06:20hansg: imirkin, nope, latest master from torvalds
06:21imirkin: load nouveau with nouveau.debug=bios=trace
06:21imirkin: that will print lots of info
06:21imirkin: that will hopefully help you avoid going *completely* insane
06:21hansg: Right, already done that, and comparing it with an mmiotrace of the blob, which is why I know the blob does the call 0xbcdf and nvkm doesn't
06:21imirkin: but i've debugged this very issue
06:22imirkin: on G96, no less
06:22imirkin: and fixed it
06:22imirkin: like 2 years ago
06:22hansg: Heh, can you dig up the commit fixing it ? Because guess what I'm on a g96
06:22imirkin: you can see the full saga at https://bugs.freedesktop.org/show_bug.cgi?id=60680
06:23hansg: Ok, reading, thx
06:23imirkin: you might enjoy the way i diff'd the mmio traces :)
06:24hansg: Hmm, that looks highly related, yet different. So the 2 conditions in my bios are:
06:24hansg: [0x0f] R[0x000008] & 0x000000f0 == 0x00000010
06:24hansg: [0x05] 0x03d4[0x94] & 0x80 == 0x80
06:24hansg: And from the blobs mmiotrace:
06:24hansg: MMIO32 R 0x000008 0x00000000 PMC.BOOT_2 => 0
06:25hansg: MMIO32 R 0x619494 0x00080060 PDISPLAY.VGA.CR+0x94 => 0x80060
06:25imirkin: that & 80 == 0...
06:26imirkin: there is a crazy hypothesis here that CALL shouldn't be affected by the execution mask
06:26hansg: Yet despite both conditions being false, it seem to call 0xbcdf, as the trace goes on exactly as if bcdf is called
06:26imirkin: and that the execution mask only applies to things that actually write and such
06:26imirkin: that would be an ENORMOUS change though (well, the patch itself would be like 1 line... but testing... ouch.)
06:26imirkin: should be easy to check in the disasm
06:27imirkin: just need to find an old enough vbios whose assembly is still readable, but new enough that it has the CALL op :)
06:29imirkin: hansg: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/subdev/bios/init.c#L1346 -- change that to if (1)
06:31hakzsam: imirkin, hey welcome back :)
06:33hakzsam: imirkin, btw, there is no LDSLK on SM50... sad! But there is ATOMS which is probably much better
06:33imirkin: hakzsam: yeah, sounds that way :)
06:33imirkin: hakzsam: just don't do the lowering, and add emission logic
06:33hakzsam: imirkin, yep
06:33hakzsam: I'll do
06:34hakzsam: imirkin, if by chance you have time today, I have a bunch of patches waiting for you on mesa-dev ;)
06:34imirkin: sorry =/
06:41hansg: imirkin, hmm, comparing the scripts after that call closer with the mmiotrace, I think I might be wrong and that it is not calling bcdf after all ...
06:41imirkin: hansg: i've been staring at the disasm, but while it used to totally make sense, i can't seem to figure any of it out right now.
06:42imirkin: hansg: try diff'ing the mmiotraces... that's how i identified the issue
06:42hansg: imirkin, anyways thx for input, I'll keep going at it. For starters I'll also do a mmiotrace of nvkm
06:42imirkin: i have some good diff commands in that bug
06:42hansg: I'll take a look and borrow them :)
06:44pmoreau: gnurou: Finally got Nouveau to work with accel on the GM200 (thanks to mupuf): on the last tries, it did build every gallium driver except Nouveau, which wasn't going to help…
06:45mupuf: pmoreau: tried some 3d apps?
06:45pmoreau: glxgears ;-)
06:46pmoreau: Not sure I have anything else beside that…
06:46pmoreau: Oh, maybe I do
06:48pmoreau: A lab from our High Performance Graphics course
06:48pmoreau: An OpenGL deferred renderer
07:01gnurou: pmoreau: ah, excellent! a gallium driver might indeed be helpful here :P
07:04mupuf: gnurou: really? Why ? :D
07:05mupuf: anyway, that was for sure something wrong on his side because it just worked for me (TM)
07:05gnurou: mupuf: not sure, I've been told it writes shit into buffers that may or may not be interpreted by the GPU...
07:05mupuf: Anyway, about the PMU, anything to share yet? :D
07:06mupuf: as in, planing on releasing nvidia's?
07:06imirkin: hansg: btw, i think skeggsb has done a lot more vbios analysis than i have, so he probably has disassemblies of various ops on-hand
07:06mupuf: or write another one that will be signed?
07:06imirkin: hansg: all the newer vbios's (nv11+) use a table-based approach, which makes reading asm trickier [gotta find the table]
07:06mupuf: or just sign our fw?
07:06mupuf: but I guess no-one wants to do the security review of our PMU
07:07gnurou: yeah that last one won't happen
07:07mupuf: hehe, I had no hope of this
07:07gnurou: we are currently lobbying to release the RM firmware and the real ACR in the same fashion
07:08gnurou: the super-secure firmware that loads the others
07:08mupuf: I see
07:08gnurou: the current one is a custom-made version for Nouveau which starts the GR falcons after loading
07:08gnurou: something the PMU firmware is normally in charge of doing
07:08mupuf: ah, I see
07:09gnurou: aligning all firmware with RM and getting automatic releases would be a big push forward...
07:09gnurou: then we could also start talking NVDEC, NVENC, etc.
07:09gnurou: but again, no promises, no ETAs...
07:09mupuf: maybe it will be ready two gens after pascal :p
07:10gnurou: maybe faster! maybe only one gen after pascal! I know, it's crazey
07:11mupuf: 3D first, it is the most important
07:11mupuf: reclocking can come after (requiring PMU)
07:11mupuf: video decoding/encoding is low priority
07:12mupuf: gnurou: did you see that reclocking is almost there for maxwell already? :D
07:12mupuf: it is apparently almost the same as kepler
07:12gnurou: mupuf: wow. how's that
07:12gnurou: ah, of course
07:12gnurou: but you need the PMU firmware...
07:12mupuf: not on the GTX 750
07:13imirkin: nobody really cares about video decoding... if they did, *someone* would have looked at it on maxwell
07:13mupuf: memory training from the host side is going to be interesting, but I guess nothing should prevent it
07:13mupuf: imirkin: yeah, it matters on laptops only, and it just does not work out of the box :s
07:14mupuf: nvidia could help here though
07:14mupuf: by telling us: Yes, you may redistribute the fw you already have
07:14mupuf: that should be sort of easy
07:15imirkin: mupuf: meh, the people who expect stuff to work out of the box aren't going to help figure out how decoding works on maxwell
07:15gnurou: from what I have seen, nvdec support on the kernel side is just loading firmware into a falcon and managing a channel, and the rest is entirely in user-space, right?
07:15mupuf: gnurou: yep
07:15imirkin: gnurou: you make it sound so simple.
07:15mupuf: but we have no rights to redistribute the fw
07:15imirkin: we still don't have perfect h264 decoding =/
07:15RSpliet: don't Teslas and Fermis upload firmware from user-space as well?
07:15imirkin: RSpliet: yes.
07:16imirkin: xtensa/falcon blobs are supplied by userspace
07:16gnurou: well if we can release the signed firmware this means redistribution will be possible... and we can also talk about previous (non-signed) generations too
07:16imirkin: these do the actual heavy lifting... the thing loaded by the kernel is just a little RTOS
07:24hansg: imirkin, I would not worry too much about bios disasm / our nv script call semantics, I think my initial analysis was wrong. Still don't know what is the actual problem though ...
07:24hakzsam: except CAS, all shared+atomic operations on GM107 work
07:36mupuf: gnurou: yep. It is not like we ask for a process or any work aside from a legal waiver saying: You may redistribute the firmwares that you extracted from our binary driver
07:37gnurou: mupuf: it would be more like "you may redistribute the firmwares that we uploaded to linux-firmware" ;)
07:37mupuf: ah ah, if you upload them yourself to the linux-fw, then we are all good :D
07:38mupuf: and yes, that sounds better from nvidia's perspective
07:38mupuf: it should be a one time effort anyway
07:38mupuf: imirkin: do we have the fw for nvenc or not yet?
07:42curvv: hi, trying to set up desktop environment on gentoo. getting this in Xorg.0.log: [mi] EQ overflow continuing
07:42curvv: any idea what might be the cause?
07:44curvv: getting a black screen and mouse pointer when launching session
08:00RSpliet: curvv: which GPU, X.org version and driver are that?
08:03karolherbst: gnurou: yeah, we are able to fully recklock gddr5 1gen maxwells, didn't try out the ddr3 ones, but who cares about those :D
08:03karolherbst: RSpliet: ahh you have a ddr3 maxwell1?
08:04RSpliet: but I care about equality :-$
08:04karolherbst: if somebody has such a maxwell, he can try out my branch and see if it works
08:04RSpliet: anyway, good to know the mem controller hardly changed
08:05mupuf: RSpliet: no, I do not have a cheap maxwell :s
08:05karolherbst: yeah, I didn't go into the details though
08:05karolherbst: it just looked pretty similiar to my gk106 and I thought I just try it out with the kepler code
08:05curvv: RSpliet: x server 1.17.4 and nvidia geforce 8200M G
08:06karolherbst: especially because I found out that the fuc5 pmu was broken, so even if somebody tried it out, memory recklocking shouldn't work at all
08:06karolherbst: ahh I should post updated patches
08:06RSpliet: curvv: MCP77, hmm, those are not extremely common I think
08:07karolherbst: mupuf: anything against ld/st accepting addresses above 0xffff?
08:07RSpliet: still, shouldn't matter: mind posting the dmesg and Xorg.0.log onto a paste website of choice and sharing the URLs?
08:07mupuf: karolherbst: ^^
08:08karolherbst: k, then I use simply imm32 there instead of mov
08:08karolherbst: and cpp will constant fold the stuff away anyway
08:08karolherbst: ohh wait, it won't
08:08karolherbst: I don't care anyway
08:09curvv: ok will do
08:13curvv: RSpliet: Xorg.0.log - https://dpaste.de/4K1V
08:13curvv: dmesg: https://dpaste.de/Pp9Y
08:14curvv: once i get the black screen the only way i can get out is to log in via ssh and reboot
08:15curvv: cannot switch to virt terminal, frozen
08:15curvv: mouse pointer moves, though
08:18karolherbst: mupuf: I was thinking, shouldn't be memory recklocking on gk20x be broken as well then?
08:18curvv: i see reference to nvidiafb there. is that frambuffer drivers? i read somewhere that i had to disable framebuffer drivers for kernel... which i thought i did.
08:19mupuf: karolherbst: it should
08:19RSpliet: curvv: hmm, a couple of funny unrelated things, but have you tried it with a kernel 4.4 already?
08:19curvv: no i haven't
08:19karolherbst: mupuf: strange, did anybody complained about it?
08:19mupuf: no-one tests reclocking
08:19mupuf: it is too "risky"
08:20curvv: i will try it
08:20mupuf: and there are only a few GPUs in the gk2xx
08:20mupuf: and they are slow IIRC
08:20RSpliet: curvv: that'd be helpful already. Next it'd be good if your nouveau ddx module has debugging symbols in the backtrace - although it looks like the card just stalls unnoticed
08:21curvv: ok i'll try 4.4 kernel first
08:23karolherbst: damn you 100 KB size limit...
08:31RSpliet: karolherbst: for.... ?
09:08martm: hi guys, i wanted to tell, that first time in life, i managed to capture a gpu lockup i used google-earth for some time, it was allready closed, and innocent banshee media player locked up the gpu
09:09martm: i did not do any debugging of the issue, X never came up again, i think the console was responsive on it's own
09:09martm: 01:00.0 VGA compatible controller: NVIDIA Corporation Device 0f02 (rev a1)
09:09martm: 01:00.1 Audio device: NVIDIA Corporation GF108 High Definition Audio Controller (rev a1)
09:10Jayhost: imirkin "demmt needs to be updated". So wait patiently?
09:13martm: i think i have low clocks, haven't even looked i have been so busy thinking about different type of things, but google-earth works and renders very well and fast still
09:13martm: ouh...Another crash happened while handling crash!
09:13martm: after the lock-up it does not start again
09:14martm: but it worked kinda long and i did not see any issues, this low end card with low clocks was sa satisfying to deal with this program when it did work
09:22martm: and that is it by me, i am taking a break from computer stuff, as there are no very high-attention needing issues left, and i am preparing for a trial against set of people here
09:22martm: to once solve the issues i am seeing in my life
09:24martm: cheers, ah well i kinda promised to offer another pseudo code for the scheduler, if i managed to get a nice hour without nightmares popping in, i really sorted it out ..then i put it on the pastebin for developers, who want to integrate the idea
09:25martm: it should work out nicely, only a little work needed there amongst different cards and drivers, it isn't very complex , quite simple and effecient method it should be, bye at the moment
09:30Yoshimo: karolherbst: so the find expression from last night, revealed:
09:31Yoshimo: looks fine to me
09:32karolherbst: then most likely you didn't change the branch, forgot to rebuild or initramfs wasn't updated right
09:32karolherbst: your vbios has issues
09:32karolherbst: yeah, maybe it would be best to take a look at your vbios
09:33Yoshimo: if the git checkout says that i am fully up to date with origin/maxwell_reclocking i at least assume the branch is correct
09:33karolherbst: did you rebuilt inside drm?
09:34Yoshimo: the vbios might already be somewhere in your db, it used to crash the tools
09:34karolherbst: nvbios crashed?
09:34Yoshimo: i think it used to, but that was quite some time ago
09:35karolherbst: gm206 was it?
09:35Yoshimo: 206 is the 950, i have a 980 so it is a 204
09:35Yoshimo: nouveau 0000:01:00.0: NVIDIA GM204 (124000a1)
09:36karolherbst: I have no idea if we have your vbios though
09:37Yoshimo: i am not sure either, but it is a fairly simple process to dump it again
09:38Yoshimo: might also be that i confuse it with the 560ti
09:38Yoshimo: i'll be right back with a dump
09:48Yoshimo: any good hoster without too much ads where i should dump that rom file?
09:54Yoshimo: karolherbst: http://workupload.com/file/zxxJuGCS try that one
09:55karolherbst: yeah okay, we got that one already
09:56Yoshimo: nvagetbios had a couple of errors about mmio read faults, and an invalid signature
10:10karolherbst: mupuf: it is the 0xc reg for sure
10:10karolherbst: if I change it, performance changes by a lot, but nouveau reads the same clock out, now I just have to figure out how to adjust the readout
10:12karolherbst: and 0x10 too :/
10:26karolherbst: ohhh no...
10:26karolherbst: there is a DVFS now?
11:05snkcld: im on a macbook pro with nvidia graphics (using nouveau, and when i change my resolution , the screen goes black.
11:05snkcld: has anyone heard of this issue?
11:14pmoreau: snkcld: Which card(s) do you have?
11:15snkcld: 01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT 750M Mac Edition] (rev a1) (prog-if 00 [VGA controller])
11:15snkcld: pmoreau: ^
11:15pmoreau: Oh, an MBP Retina then?
11:16pmoreau: It should have an integrated Intel GPU as well, are you sure you are on the NVIDIA one?
11:17pmoreau: Could you give a link to your dmesg and Xorg.log please?
11:17pmoreau: snkcld: ^
11:17snkcld: no problem
11:18snkcld: do you have a recommended easy way to get the logs to pastebin?
11:19snkcld: http://pastebin.com/7m4eRMp6 <- nvidia from dmesg
11:19karolherbst: no grep
11:19karolherbst: second: why nvidia?
11:19pmoreau: karolherbst: +1 ;-)
11:20snkcld: my apologies
11:20snkcld: i forgot that i rebooted to use nvidia, ill have to reboot into nouveau
11:20snkcld: to show the proper log
11:20mupuf: karolherbst: what do you mean by DVFS?
11:21karolherbst: dynamiv voltage and frequency stuff, no idea what s was again :D
11:21mupuf: well, you mean there would be that in HW?
11:21mupuf: No way
11:21pmoreau: the emergency frequency divider thing?
11:21mupuf: clock gating, yes
11:21karolherbst: Ill show you why I think that
11:21karolherbst: mupuf: https://github.com/kfractal/nouveau/blob/hwref/drm/nouveau/include/nvkm/hwref/gm107/trim.h#L44-L48
11:22karolherbst: I bet DVFS means something else here then :p
11:22mupuf: nope, it is DFS
11:22mupuf: dynamic frequency switching
11:22karolherbst: so the DVFS part is just for show
11:22mupuf: the V part
11:22mupuf: now, how the fuck can this work :o
11:23karolherbst: well it does affect performance at least
11:23karolherbst: in a weird way
11:23karolherbst: does nouveau have tegra X1 support yet?
11:23karolherbst: k, then I will check there
11:23mupuf: and you can have a look at the android tree
11:24karolherbst: yeah, because gm20b has no clk subdev yet...
11:25karolherbst: It might be that all maxwells would be currently underclocked through nouveau
11:26mupuf: brb, goigng back home and I will have a look with you
11:26mupuf: if there is DFS, there is activity signal
11:26mupuf: and there is a function to link activity with clock
11:26karolherbst: what of these are the right sources by the way? https://android.googlesource.com/kernel/tegra/
11:26mupuf: there is no actual reclocking, so it likely is the equivalent of what the FSRM used to do
11:27mupuf: will check when I am home
11:27karolherbst: ahh okay
11:27karolherbst: so, when no load, fake a lower clock to save _some_ power
11:27karolherbst: well "fake"
11:27karolherbst: the clock gets lower, but voltage stays the same
11:40mupuf: it likely gates some ticks
11:41mupuf: did you check with nvatiming or shall I do it?
11:41karolherbst: sadly you don't have a gk110, because to add support for it first would be a bit simplier
11:41karolherbst: I didn't check
11:42karolherbst: here are the data from the blob: https://gist.github.com/karolherbst/b2bf786ed20503d1714c
11:43karolherbst: no idea about the refclock though, I didn't dig through enough to actually also read this out
11:43karolherbst: 0x13701c doesn't seem to have any effects though
12:01karolherbst: mupuf: which of the nvatiming clocks is the gpc?
13:34karolherbst: okay, letting nvidia set the voltage to 0.6V is a bad idea...
13:35karolherbst: but why does the gpu completly disconnects itself from the bus? :/
13:36pmoreau: (FYI, I'm using Reator)
14:01karolherbst: ... those mode 3 entries are the weirdest ones...
14:05karolherbst: it makes no sense...
14:08karolherbst: ohh well
14:08karolherbst: mode 3: (info.min + info.max) / 2
14:09karolherbst: but why does nvidia won't load as long as c0 is below 128 or something...
14:48snkcld: i booted back into nouveau, and when i change my resolution, the screen turns black and i cant do anything
15:08Jayhost: karolherbst are you working on gm107 reclock?
15:10snkcld: any idea whats going on?
15:13karolherbst: Jayhost: it already works , just those patches has to be upstreamed
15:14Jayhost: Had you fixed the lock up or do you just mean the kepler stable patches
15:18karolherbst: Jayhost: well there might be different issues besides volting, but that I try to figure out after I got those volting stuff merged
15:18karolherbst: also there is some gpu boost stuff which has to be taken care of too
15:19karolherbst: it's kind of important that clocking itself works table enough, then we can deal with those rare instabilities
15:19Jayhost: karolherbst how can I help?
15:20pmoreau: snkcld: Do you have a dmesg from when using Nouveau?
15:21pmoreau: mupuf: Where is piglit hidden on Reator?
15:22gnurou: karolherbst: I have a gm20b clk subdev in my tree, did not submit it yet because I need to factorize all the duplicate code and logic with gk20a... the Android people did not care and copy/pasted before changing bits here and there :/
15:23karolherbst: gnurou: I see
15:23karolherbst: gnurou: currently we want to know what the 0xc and 0x10 reg do on the gpc
15:23karolherbst: 13700c and 137010
15:23gnurou:makes a note to look at that
15:24karolherbst: thanks a lot :)
15:24karolherbst: it also affects gk110 a bit though
15:24karolherbst: currently we have troubles reading the clock out with the nouveau code on gk110+ gpus
15:24karolherbst: Jayhost: which gpus do you have?
15:26karolherbst: pmoreau: src is a lot of stuff, maybe it is in there?
15:26karolherbst: gnurou: well it would be enough to know how the clock changes according to 13700c and 137010 for now
15:26gnurou: karolherbst: actually gm20b can work in PLL NA mode (whatever that means), and the logic is quite different in that case. Otherwise it seems like it can also be controlled the way gk20a is. How this translates to dGPU is unknown to me though
15:27pmoreau: karolherbst: Yeah, thought about it as well, but couldn't find a folder with a similar name in it
15:27karolherbst: gnurou: yeah I know, we checked with hwref already
15:27karolherbst: gnurou: thing is just, that it may be that nouveau sets lower clocks now than it thinks it set
15:27Jayhost: karolherbst I only have gm107 at the moment
15:28karolherbst: Jayhost: k, get my maxwell_recklocking branch to work :)
15:28karolherbst: and then do stuff at full clocks until the gpu crashes
15:29karolherbst: gnurou: ohh wait
15:29karolherbst: gnurou: gk20a already has the 0x13700c reg
15:29karolherbst: this helps us with gk110 already
15:29karolherbst: GPCPLL_CFG2 in nouveau code
15:30Jayhost: karolherbst. Okay mirkin says demmt is outdated so what should I do when stuff crashes
15:31karolherbst: Jayhost: I updated my branch the last days, so maybe it is better now :/
15:31karolherbst: Jayhost: where you able to get full memory recklock?
15:32Jayhost: alright I'll check it out. I just installed an SSD.
15:38karolherbst: mupuf: I think gk20a_pllg_slide is the stuff we search
15:38karolherbst: at least for gk110 that is
15:44karolherbst: it doesn't make sense...
15:45karolherbst: can somebody send a gk110 to mupuf? :D I really need one
16:49karolherbst: pmoreau: still there?
17:07karolherbst: Jayhost: any luck yet?
17:21Jayhost: karolherbst the memory does not reclock
17:21Jayhost: it shows 5400 but only goes 810
17:21karolherbst: Jayhost: do you use my updated branch?
17:22Jayhost: I believe so kepler stable
17:22karolherbst: use maxwell_recklocking
17:22Jayhost: Okay just a sec
17:22karolherbst: why do I always write reclocking wrong
17:25Jayhost: muscle memory
17:26Jayhost: I'm not sure how to get the maxwell branch
17:27karolherbst: git checkout maxwell_reclocking
17:27karolherbst: you should git fetch origin first
17:27Jayhost: Still not there
17:28Jayhost: I could just clone it again
17:28karolherbst: does git checkout origin/maxwell_reclocking work?
17:30Jayhost: okay in detached head mode
17:30karolherbst: then do this:
17:31karolherbst: git checkout origin/maxwell_reclocking -b maxwell_reclocking
17:31Jayhost: okay built
17:33Jayhost: Something is blocking me from hotswap. GDM or something else
17:34Jayhost: Yeah my script is set up for ldm
17:35karolherbst: I didn't actually test it with a display, so it might mess up what is shown on the display :/
17:35karolherbst: Jayhost: another question: did you had any sort of tearing?
17:35Jayhost: Screen tearing
17:35karolherbst: or vsync not working the right wait?
17:36karolherbst: ahh, that might be fixed as well
17:36Jayhost: What other kind of tearing
17:37karolherbst: well I meant the ugly lines you see on the screen ;)
17:37Jayhost: Nothing way out of the ordinary
17:37karolherbst: and with as well I meant besides memory reclocking
17:37Jayhost: when using kernel 3.16 it starts with red lines
17:38Jayhost: And those lines go away when switch to terminal and back
17:40karolherbst: does it still happen with the new branch?
17:42Jayhost: But also I don't know how to use the new module with the old kernel
17:43karolherbst: you can't
17:43Jayhost: still mem 810 in pstate
17:47karolherbst: Jayhost: also can you check which is the newest commit in your git tree?
17:47karolherbst: I am sure it should have worked though (well you still need to manucally recklock though)
17:49Jayhost: would be easier if I could scp the dmesg
17:50karolherbst: maybe you want to reboot with the newest nouveau module
17:50karolherbst: because by just loading the new one
17:50karolherbst: you shouldn't get any errors
17:50karolherbst: even after reclocking
17:50Jayhost: Those errors I guess are from Doom3
17:51karolherbst: most likely
17:52karolherbst: it would be easier to test reclocking without running anything for now
17:52karolherbst: so that dmesg don't get polluted
17:53Jayhost: command to check newest commit
17:53karolherbst: newest should be "clk: don't create cstates which voltage is higher than what the gpu can do"
17:54karolherbst: wrong branch
17:54karolherbst: fb: maxwell memory reclocking looks like kepler, so try it out
17:57karolherbst: Jayhost: how do you reload nouveau by the way? unbing vtcon, rmmod nouveau, insmod?
17:57karolherbst: ahh okay, good
17:57Jayhost: karolherbst modprobe instead of ins
17:57karolherbst: try insmod to be sure it does load the compiled one :/
17:59imirkin: Jayhost: you can also force it to use the old ioctls... somehow
18:00imirkin: mupuf: no, i don't think anyone's bothered even extracting the nvenc fw. maybe mwk? not sure.
18:01imirkin: curvv: weeeird. your gpu on boot has 2x the shader clock of the max perf level. that's probably not very good.
18:02Jayhost: imirkin is that the best way to figure out what's going wrong
18:02imirkin: curvv: try booting with nouveau.pstate=1 and then doing "echo 0f > /sys/class/drm/card0/device/pstate"
18:02imirkin: Jayhost: you could also run the game with NV50_PROG_DEBUG=1 and capture all output until you see that error, and then stare at shader disassemblies.
18:03imirkin: Jayhost: you had the invalid opcode thing right?
18:03imirkin: karolherbst: gk208 memory reclocking works fine... at least it did for me.
18:05Jayhost: imirkin GPC0/TPC0/MP trap: global 00000000  warp 3000e [MEM_OUT_OF_BOUNDS]
18:06imirkin: that's not bad in and of itself... i think
18:06karolherbst: imirkin: mhh odd, maybe for DDR3 the pmu script isn't as important? :/
18:07imirkin: or it didn't hit on any of the issues
18:07karolherbst: could be
18:08karolherbst: I know I tested it a bit and it simply didn't work on gm107 without my pmu fixes
18:08karolherbst: it somtimes worked though
18:08karolherbst: and sometimes not so much
18:11Jayhost: karolherbst insmod doesn't work. I had assumed it was outdated. modprobe had always worked for me before
18:11karolherbst: if insmod doesn't work, there is something wrong
18:11karolherbst: well you have to give a path to insmod
18:12karolherbst: and if it fails you should check why
18:13karolherbst: Jayhost: what error does insmod give you ?
18:15Jayhost: It worked this time but still no mem
18:15karolherbst: also content of pstate would be nice
18:17karolherbst: that's the old module
18:19karolherbst: with the new branch "nouveau 0000:01:00.0: clk: base: 1176 MHz, boost: 1254 MHz" should be in two lines now
18:20Jayhost: karolherbst It shouldn't be the old module because then I wouldn't be able to test pstate
18:21karolherbst: Jayhost: well, it is the one you tried out from my branch, but it's not the new one with the maxwell memory fix
18:21Jayhost: You should see Boost if you grep. unless I sent the wrong dmesg
18:22karolherbst: Jayhost: it's there, but with the new branch it should be split in two lines
18:22karolherbst: Jayhost: you may want to build inside drm again, remove nouveau
18:23karolherbst: and insmod nouveau/nouveau.ko
18:23Jayhost: karolherbst okay I should have it soon
18:35karolherbst: Jayhost: I know that installing nouveau is a pain :/ Maybe if somebody has a good idea we can improve it a bit or at least have a better way to verify that the expected built was loaded
18:38Jayhost: karolherbst okay two lines now
18:38Jayhost: was confused a bit at having it reclock at startup
18:38Jayhost: still 810
18:38karolherbst: dmesg then
18:38karolherbst: and content of pstate
18:38Jayhost: okay after 0f
18:38Jayhost: It's up
18:44karolherbst: nice :)
18:44karolherbst: I will head to bed now anyway
18:44karolherbst: but you can do some testing and see if the perf is also much better now
18:44karolherbst: and stable
18:48Jayhost: karolherbst any good resources to read about reclocking other than what's on nouveau home page