00:00 Lyude: btw; I realized I should clarify: should I do this before I eventually submit the patch series, or fix it up later when we actually write the code for this
00:03 infinity0: btw 07 on this GF114 works well enough for me to play sc2 on high graphics settings at 20 fps, so congrats there
00:03 skeggsb: do you have something between 0x7 and 0xf on that board?
00:03 infinity0: Lyude: i tested with this branch: https://github.com/skeggsb/nouveau/tree/devel-clk
00:03 infinity0: skeggsb: nothing else shows up in /sys/.../pstate, only 03 07 0f
00:03 infinity0: oh and AC but it looks like that's just the "current one"
00:04 Lyude: infinity0: oh nice, I will definitely play with that
00:05 infinity0: Lyude: https://gist.github.com/infinity0/004c27287106d4f578c34cafdcebb5a2 for a one-click script to build it, more-or-less
00:05 skeggsb: wow... or you could just, you know, "cd drm; make" ;)
00:06 imirkin_: skeggsb: that tree is very hard for normal people to use
00:06 Lyude: hehe; doesn't matter a whole ton since i've got my own set of scripts for building/installing kernels anyway
00:06 Lyude: ^ that is also true
00:06 imirkin_: skeggsb: you have to guess which kernel it is
00:06 karolherbst: or git rebase and remove all rc/drm-next patches until it compiles :p
00:06 imirkin_: and you can't port patches easily
00:07 infinity0: the script includes some hacky logic to rebase the branch to 4.14 which is what i'm running
00:07 Lyude: i don't even use it because it's the only driver I work on that has it's own non-kernel branch, so it's easier for me to just make any patches for that branch work for the mainline kernel and do my development there
00:07 Lyude: oh lord i'd rather just rebase it myself lol
00:07 Lyude: no offense :)
00:07 karolherbst: Lyude: or let me rebase and use my branches :p
00:08 infinity0: none taken :p
00:08 karolherbst: saves you the trouble
00:08 Lyude: karolherbst: that works too!
00:08 infinity0: i just wrote it so i don't have to context-switch so much next time skeggsb updates that branch :p
00:08 Lyude: karolherbst: btw, what are your thoughts on the thing I asked about before with the pack formatting?
00:08 karolherbst: but I got kind of lazy with that, so some fixes are missing
00:08 karolherbst: Lyude: I don't remember
00:08 Lyude: i mentioned it less then 5 minutes ago lol
00:11 mischmerz: Hey karolherbst :D
00:11 karolherbst: yo
02:58 imirkin: RSpliet: can't find a trace for that nvce anywhere
02:59 imirkin: infinity0: looks like you'll have to make some traces
09:09 pmoreau: datalas: You need a more recent kernel, possibly 4.15? Or maybe it was already there in 4.14, let me check
09:10 datalas: good lord, sorry, didn't realise the kernel was that behind ...
09:10 datalas: (only just started using CentOS)
09:12 pmoreau: There should be some initial support for GP108 (1030) in 4.14. For hw acceleration, it will land in 4.16 by the looks of it.
09:13 datalas: mostly just using it for desktop gubbins so I'm not too worried about 3d, but getting the second monitor working would avoid me losing the IRC window :)
09:13 datalas: thanks for the advice, I'll try finding a new kernel in a bit ..
09:29 pmoreau: I’ll look into updating the news section of the wiki; we will need that information for the FOSDEM presentation anyway.
09:57 datalas: hello, back again ... so I tried a 4.14 kernel and got .. err.. shall we say different results :)
09:57 datalas: modprobe crashed with an init error and a return code of -12
09:57 datalas: X then stated with a single display and a max res of 800x600, which I assume is it falling back to MESA
10:02 gnarface: you mean VESA?
10:03 datalas: yes
10:03 gnarface: it might be falling back to VESA or some generic framebuffer driver
10:05 datalas: I guessed as much, but its more the -12 modprobe error I'm interested in
10:07 gnarface: yea, that's really weird
10:07 gnarface: i'd assume it would at least modprobe
10:07 gnarface: when you updated the kernel, did you forget to also update the modules?
10:07 datalas: maybe :)
10:08 datalas: fairly new to centos and ubuntu does it for me
10:08 gnarface: oh uh
10:08 gnarface: did you update by package? if so, there's maybe a separate module package (not sure, i don't know centos either, though it would be weird to me that they would keep it in a separate package, it doesn't seem their style)
10:09 datalas: so, installed the new kernel via elrep, so it might be possible I didn't update the modules
10:09 gnarface: if you updated by manual build and copying of bzImage or whatever, maybe you just forgot to run "make modules && make modules_install"
10:09 datalas: will have another play
10:10 gnarface: yea, check on that first. the modules have to come from the same kernel version for best results.
10:17 datalas: well, from what I can tell installing the kernel should also come complete with any kernel modules
10:20 gnarface: hmmm
10:20 gnarface: datalas: you don't happen to have the official drivers installed still by any chance?
10:21 gnarface: datalas: they don't play nice together. you have to blacklist the one you're not using
10:21 datalas: I don't think so, I certainly tried as hard as I could to remove them :)
10:21 datalas: this is now a fresh install, I've installed (and removed) kmod-nvidia, but AFAIK it should be gone
10:22 gnarface: well it would be easy to check: lsmod |grep nvid -i
10:22 datalas: yup, nothing
10:22 datalas: (thankfully)
10:23 gnarface: and nouveau isn't already loaded either?
10:23 datalas: although I'm back on the 3 kernal atm otherwise I've only got 8x6 :)
10:23 gnarface: oh hmm
10:23 datalas: sadly, I'm technically working so I'll not be able to play for a few moments
10:23 datalas: will grab the laptop and rejoin when I get chance
10:24 gnarface: alright, i'm out of ideas for now anyway
10:24 gnarface: something's definitely wrong but i can't be sure where the fault lies
10:25 datalas: well, the option might be to just wait, since I can use *a* display .. :)
10:26 gnarface: well, you may only have to wait until the morning when someone who actually knows stuff can help
10:26 gnarface: all i could do is help you check obvious user error stuff
10:26 datalas: :)
10:27 datalas: I'm in the UK, so it *is* morning :)
10:27 gnarface: oh heh
10:27 datalas: thanks for the help though
10:27 gnarface: no problem
10:27 datalas: it is appreciated (I'm never one to rule out obvious user error stuff, I'm normally the cause of many)
10:40 pmoreau: datalas: Could you paste the output of dmesg please, after getting that -12 error?
10:41 datalas: will try to find it .. two ticks
10:41 datalas: (as I say, I had to reboot to a kernel that worked)
10:43 datalas: pah, it's gone missing, I'll reboot after I've finished this meeting I'm in :)
10:44 pmoreau: Sure, no hurries. I’ll be going for lunch pretty soon. :-)
11:44 datalas: right, rebooted into 4.14
11:45 datalas: nouvear 0000:01:00.o: bar: one-time init failed, -12
11:46 datalas: shortly after err... nouveau 0000:01:000: fb: 2048 MiB GDDR5
11:47 datalas: and then systemd-udevd: vmalloc: allocation failure: 0 bytes, mode:0x14080c0(GFP_KERNEL|__GFP_ZERO), nodemask=(null)
11:47 datalas: and then lots of other stuff
11:49 pmoreau: Hum
11:50 datalas: looks like a kernal dump
11:50 datalas: with lots of mentions of nouveau things
11:56 pmoreau: datalas: Could you try a 4.15 kernel (I don’t think it has been released yet, so grab one of the latest RC)? That part has been reworked in 4.15, and has gained some more knowledge about Pascal specific features.
12:02 datalas: it's been a long time since I had to build my own kernel
14:50 RSpliet: imirkin: sorry, I must have not pushed them. I'm sure I have quite a few of those on my desktop PC on account of having actually used his GPU for VBIOS fuzzing for DRAM reclocking
14:50 RSpliet: If I have some time tonight after work, gym and dinner I'll see if I can push them for you.
14:51 RSpliet: Otherwise probably Sunday
14:54 RSpliet: and with "you", I mean skeggsb ;-)
15:20 bazzy: I seem to be experiencing a hardware issue where my screen pops on shutdown. Looks like an ungraceful powerdown of the screen. I'm not sure where to go for more information. I use a 2009 macbook pro, triple boot Win7 OS X and Gentoo Linux. Only Gentoo Linux experiences the problem, and I guess that's because OS X and Win7 have corresponding Apple drivers. But I thought someone here might have a clue what I
15:20 bazzy: could do to diagnose further and fix this
15:21 imirkin_: "pops"?
15:21 bazzy: IIRC, the screen would pop on shutdown irregardless if nvidia-drivers or nouveau was in effect
15:21 imirkin_: is this a MCP89 btw?
15:21 bazzy: imirkin_: mcp79
15:21 imirkin_: ah. so same as pmoreau's then, i think.
15:22 pmoreau: yup
15:22 bazzy: i think it's the screen, but it could be something else in the hinge I suppose (NIC?),
15:22 imirkin_: bazzy: when you say 'pop', is this like a sound, or a visual effect, or?
15:22 pmoreau: bazzy: does it also have a G96 (9600M), or just the MCP79?
15:22 bazzy: 9400M
15:24 bazzy: the pop is both visual and audio. IIRC the screen normally just goes black on graceful shutdown. but this time it's more like an oldschool TV where you can see some sort of light concentration in the center as it goes out, and I hear a pop sound. It's *just* loud enough to be concerning
15:24 pmoreau: Okay, I have a 9400M + 9600M model, but since the screen is driven by the 9400M, I should be able to hit the same issue.
15:25 bazzy: pmoreau: note that it doesn't pop if you do a `reboot`
15:26 bazzy: I experience pops on both `shutdown -h now` and `poweroff` -- in which case `shutdown -h now` seems more reliable as the rootfs gets remounted read-only, but that hasn't seemed the case with `poweroff` and it may be because of this issue (?)
15:26 pmoreau: Hum, I remember hearing that sound (not too sure about the visual effect), but I can’t remember if it’s still happening and if it was only when doing a “hard” shutdown or always.
15:27 bazzy: I'm going to do it again and try to assess the phenomenon better (shutdown -h now)
15:27 bazzy: brb
15:27 pmoreau: I’ll have a run when I get home (in a couple of hours).
15:28 bazzy: OK so this time I didn't see any visual effects, just the popping sound. Either my memory fails me, or it's inconsistent
15:29 bazzy: I even tried adding some lines to RC service where Alsa saves its config, to mute the master channel and remove the snd-intel-hda kernel module, still getting the popping. I really have trouble telling where it's coming from
15:29 bazzy: gonna try again and lean my ear in
15:48 bazzy: Hrm, yeah IDK. It could be the speaker. But I tried putting some things in alsa service that don't seem to affect it at all such as the following: https://paste.pound-python.org/show/jtd5dJPjUj7T2xS3dCUv/ (see stop())
15:54 bazzy: Seems to come from left side of the laptop, or left speaker.
19:12 Lyude: Am I right to assume that nouveau calls fini() for every subdev once the module loads, right before we actually start initing the subdevs?
19:22 imirkin_: yes
19:22 Lyude: cool
20:23 Lyude: hm, seems like now that I've fixed the s/r issues sometimes power consumption after resume is even lower then before we suspended, nice
20:23 Lyude: no idea how that works but, heh
20:28 Lyude: karolherbst: you're still planning on rebasing those fermi reclocking patches right?
21:49 Lyude: Hey; does anyone still have a working fermi system anywhere around that they would mind grabbing some mmiotraces from for me?
21:49 pmoreau: Mind if I do that tomorrow rather than tonight?
21:49 Lyude: pmoreau: sure; but also: can you actually use the old nvidia blob on there?
21:49 mupuf: Lyude: don't you have access to the vbios repo? There are plenty mmiotraces there
21:50 mupuf: otherwise, I can plug any GPU you want in reator and give you access to it
21:50 Lyude: mupuf: there are but I need something very specific in this trace
21:50 mupuf: ok :)
21:50 Lyude: that being: suspend/resume with the nvidia driver, and load/unload with the nvidia driver
21:50 pmoreau: I should be able to, I think
21:51 Lyude:eneded up deciding to just do fermi with the clockgating stuff, otherwise she'll have to rewrite a lot of it later if we ever add it and don't want the code to be ugly
21:51 pmoreau: Poor Lyude :-/
21:51 Lyude: hehe
21:52 Lyude: honestly now that I have a rather good understanding of how all of this works it hasnt been very difficult resplitting the code from kepler to fermi
21:53 pmoreau: Nice! Want to give Tesla some love as well, while you’re at it? ;-)
21:53 Lyude: no way
21:53 Lyude: sorry :P
21:53 Lyude: tesla is far different when it comes to clockgating from my understanding
21:53 Lyude: ...I also have no tesla hw, but I suppose finding someone with tesla hw isn't too difficult
21:54 pmoreau: Probably not
21:57 Lyude: pmoreau: my understanding with tesla is you have to do some nightmarish stuff to make clockgating work
21:57 Lyude: (or powergating? it might only be pg)
21:58 Lyude: iirc you have to continously reupload some firmware to the GPU because with one of those two features on, the GPU just kind of forgets the firmware
21:58 pmoreau: Could be, I think Karol was saying it was in a quite primitive state
21:59 pmoreau: Crappy :-(
21:59 Lyude: hehe
21:59 Lyude: yeah, but fermi+ is better then nothing
21:59 pmoreau: Is it like powergating its own DRAM chip holding the firmware?
22:00 pmoreau: *holding on
22:00 Lyude: I have no idea on the specifics
22:00 Lyude: I think it was karolherbst who mentioned it to me when I was getting started on this
22:00 pmoreau: Okay
22:00 Lyude: then you have fermi which continuously reads a bunch of power related registers for unneeded reasons, let's hope that's not going to break anything
22:01 Lyude: (we don't do that, but I have a feeling we don't need it either)
22:01 pmoreau: Good if we don’t need to
22:02 pmoreau: Once you have Fermi going on, will you be rolling on Maxwell-Pascal?
22:03 Lyude: maxwell1 yeah
22:03 Lyude: everything after that maybe
22:03 Lyude: I honestly haven't seen reclocking trigger any power related issues with cg, but I might just not have enough testing on this series
22:04 Lyude: (jfyi, current working kepler one is here https://github.com/Lyude/linux/tree/wip/kepler%2B-clockgating-v1r4 does s/r correctly, unload/reload probably needs to be fixed according to a trace I just made a moment ago)
22:04 pmoreau: Volta is going to take some time before getting support in Nouveau. Well, and some time to reach the market as well. :-D
22:04 Lyude: or anyone, for that matter <<
22:04 pmoreau: Still hoping to get my hands on a Titan V :s
22:04 pmoreau: Ah, thanks for the link, I’ll update the version I’m running :-)
22:05 Lyude: np
22:06 Lyude: also sorry this series has taken so long, it's only been the past week or two I've cleaned off my plate enough to work on nouveau
22:06 pmoreau: No worries :-)
22:09 Lyude: also hm, when nvidia dropped support for fermi in their blob does anyone recall if they dropped tesla support at the same time, or if they'd already dropped it earlier
22:09 imirkin_: i wasn't aware that nvidia dropped fermi
22:09 imirkin_: 340.x was the last for tesla
22:09 pmoreau: Tesla was last supported in340.xx
22:10 Lyude: huh? I thought they did
22:10 Lyude: maybe I got the generations mixed up, because if so I could just do the traces on here...
22:10 imirkin_: that'd still be consistent with my comment :p
22:10 pmoreau: They dropped it from CUDA (and OptiX), but I’m not sure about the driver.
22:10 imirkin_: they didn't do vulkan for fermi
22:10 Lyude: Oh. WELL THEN
22:10 Lyude: guess i've got some more traces to do
22:11 imirkin_: i think they're still shipping new fermi's
22:11 imirkin_: GT 910's and whatnot
22:12 pmoreau: Lyude: 390.xx still has Fermi support.
22:14 pmoreau: Lyude: Is it only the 4 topmost patches on that v1r4 branch?
22:15 Lyude: yeah and wow
22:15 Lyude: i can't believe I didn't realize that before, lol
22:16 Lyude: pmoreau: actually, those traces on 390.xx for nvc0 might still be helpful
22:16 pmoreau: Cool, going to compile a new kernel with those :-)
22:16 Lyude: realizing I noyl have a nvc8
22:16 Lyude: *I only
22:17 imirkin_: that's what i have =]
22:17 pmoreau: I have a nvc0 and... something else I think, can’t remember what though.
22:17 Lyude: well the more traces the better :)
22:19 Lyude: also for the sake of my label maker;was there both a fermi1 and fermi2? or just one big fermi family
22:19 imirkin_: GF119 has some differences from the rest of the family
22:20 imirkin_: and GF110 has a new compute class
22:20 imirkin_: but nothing major.
22:20 imirkin_: GF119 has an updated display unit
22:20 imirkin_: GF117 has no display :)
23:57 Lyude: out of curiosity, anyone know what FECS (like FECS_IDLE_FILTER) stands for?
23:58 Lyude: i'm assuming something regarding the falcon
23:58 Lyude: *falcons
23:59 imirkin_: front-end command submission? something like that
23:59 Lyude: cool