08:47 pmoreau: imirkin_: Yeah, it did… mismatch between drm-next and Ben’s tree IIRC. And I have been too lazy to look for a heuristic that would pull in the correct drm-next version.
08:48 pmoreau: I was hoping for it to solve by itself, but… it didn’t sadly. :-D
08:49 karolherbst_work: pmoreau: well you can always search the last drm-next commit in bens tree ;)
08:50 pmoreau: karolherbst_work: My lazyness was too strong to write the command line that would parse the last commit messages to figure that out.
08:50 karolherbst_work: :D
08:50 pmoreau: Even though it shouldn’t be really difficult
08:51 karolherbst_work: well, I also need it and didn't bother enough to write it too…
08:51 pmoreau: I have a patch sitting untouched for at least one month, where I just need to press send basically, and I still haven’t done it! --"
09:45 asdf__: Hi, i have a problem with my graphics card link speed, is this the best place to find help?
09:54 RSpliet: asdf__: that depends on the graphics card, the driver and the kernel version you use
09:57 RSpliet: in general, if you are using nouveau for your NVIDIA graphics card, the link speed can change if 1) you change "Performance level" 2) if the VBIOS tells it to 3) if your motherboard doesn't have a weird quirk that forbids higher link speeds
09:57 RSpliet: note that 1) only works for many graphics cards when using karolherbst_work's patched up kernel
10:01 karolherbst_work: asdf__: what is the problem you have, are you always stuck at 2.5?
10:03 asdf__: well, i'm not sure if this was the best place to ask, a friend suggested here. I'm running windows 10. Before I install my drivers, it shows up as Microsoft Basic video adapter. Importantly, lspci shows
10:03 asdf__: LnkCap: Port #0, Speed 8GT/s, Width x16
10:03 asdf__: LnkSta: Speed 2.5GT/s, Width x1,
10:03 asdf__: when I install the drivers, lspci shows
10:03 asdf__: LnkCap: Port #0, Speed 2.5GT/s, Width x16,
10:04 asdf__: LnkSta: Speed 2.5GT/s, Width x1,
10:04 asdf__: so for some reason, installing the drivers causes the card to change what PCI version it reports, from PCIE 3 (8GT/s) to PCIE 1 (2.5GT/s)
10:05 asdf__: my system supports PCIE 2.0; my question is, is it possible to use setpci to change the link speed to pcie 2.0?
10:06 asdf__: or at least find out which registers I need to change? I'm asking here because I figured people here would have knowledge of the lower level drivers etc
10:07 karolherbst_work: well, you can just poke into the device regs and change the level on the fly
10:07 karolherbst_work: it is mostly figured out how it works for tesla and newer
10:08 karolherbst_work: but the nvidia driver sets the link depending on the current perf level
10:08 karolherbst_work: so if you play something and the gpu is under high load, nvidia sets up the pcie link automatically
10:08 asdf__: Where can I find out information about the device registers? I have a program running in the background and the pci link doesn't increase
10:08 karolherbst_work: well
10:08 karolherbst_work: it depends on the load
10:09 karolherbst_work: but usually the benefit of higher pcie link is rather small
10:10 karolherbst_work: asdf__: most of the stuff you can find here in the C code of nouveau: https://github.com/skeggsb/nouveau/tree/master/drm/nouveau/nvkm/subdev/pci
10:10 karolherbst_work: pcie.c is the basic part
10:10 asdf__: I'm running x1 link, so going from pcie 1 x1 to pcie 2 x1 would double the bandwith for me :). I'm running a game and the bus usage and gpu load is about 95 and 100% respectively
10:10 karolherbst_work: and in the chipset specific files are the device regs
10:10 karolherbst_work: I see
10:10 karolherbst_work: asdf__: what gpu?
10:10 asdf__: 660Ti
10:10 karolherbst_work: kepler then I guess
10:10 asdf__: VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 660 Ti] (rev a1)
10:10 karolherbst_work: look into gk104.c then
10:11 karolherbst_work: gk104_pcie_set_link_speed is the function
10:11 karolherbst_work: but there is also a cap and other stuff you might have to set before
10:12 karolherbst_work: have to go for a bit now
10:12 asdf__: thanks, this has given me a new lead to investigate. I'm guessing it would be more complex than doing something like
10:13 asdf__: setpci -s 03:00.0 xx.b=x
10:13 asdf__: where x = some address and value?
10:21 karolherbst_work: mhh
10:21 karolherbst_work: we have tools to abstract those pci stuff away
10:21 karolherbst_work: but I doubt they run on windows
10:23 Yoshimo: can someone tell me why nouveau on a fresh Kubuntu LiveCD that includes maxwell firmware fails to load them from the correct gr-subfolder and instead look one level higher?
10:24 Yoshimo: Even the kernel source of 4.4 used there seems to have that line correct
10:26 asdf__: but I can setpci could be used to set the device registers on the fly, is that right?
10:26 asdf__: *i can use setpci to change the registers on the fly
10:26 asdf__: ?
10:27 Yoshimo: log is https://pastee.org/ykc4r still , help appreciated
10:57 karolherbst_work: asdf__: I think so, yes
10:58 karolherbst_work: asdf__: you just need to figure out the right address and I can't say how to calculate it
10:58 karolherbst_work: Yoshimo: the path is wrong
11:00 Yoshimo: i know, but why? This is official packaging and according to the source the path should be right
11:02 karolherbst_work: Yoshimo: does it work with the adjusted path?
11:03 Yoshimo: this is a fresh live cd from a source that has the right name so i can't adjust stuff and i shouldn't have to
11:04 Yoshimo: http://packages.ubuntu.com/xenial/linux-image-4.4.0-28-generic source seems to be fine
11:05 karolherbst_work: well, maybe they borked the packaging?
11:35 Yoshimo: maybe or are these lines wrong?
11:35 Yoshimo: if (gr->firmware) {
11:35 Yoshimo: nvkm_info(&gr->base.engine.subdev, "using external firmware\n");
11:35 Yoshimo: if (gf100_gr_ctor_fw(gr, "fecs_inst", &gr->fuc409c) ||
11:42 karolherbst_work: ask gnurou
11:43 karolherbst_work: or maybe they just ship an incompatible linux-firmware/kernel combination
11:43 Yoshimo: when is he usually around?
12:12 RSpliet: Yoshimo: Japan timezone iirc
12:12 Yoshimo: oh, sounded more like france from the name or canada
12:14 hakzsam: he lives in tokyo yes
12:14 pmoreau: Yoshimo: Being French does not prevent him from living in Japan. ;-)
12:15 Yoshimo: no it doesn't but its not the first thing that you assume
12:15 pmoreau: True
12:15 Yoshimo: 9pm there, well
12:15 RSpliet: interestingly, that makes his timezone very close to Ben's... :-P
12:15 pmoreau: Just saying you weren't completely off
12:57 imirkin: Yoshimo: i dunno what you have, but kernel 4.4 did not include support for secboot on GM20x
12:57 imirkin: Yoshimo: so you're using some frankenkernel...
12:58 Yoshimo: it doesnt? so what are those lines that i quoted for then?
12:58 imirkin: not from kernel 4.4 :)
12:59 imirkin: perhaps someone took kernel 4.6, but in an effort to make it stable, renamed it to kernel 4.4?
12:59 imirkin: (or perhaps used the more popular term for this, "backported")
13:00 Yoshimo: maybe, the file is linux-4.4.0.orig.tar.gz so i assumed ubuntu guys used that as base and had a diff on top
13:00 Yoshimo: anyway i will get a fresher mainline kernel
13:00 karolherbst_work: those buntu guys :p
13:33 karolherbst_work: ohhhhhh!!! imirkin: now we know why talos got a perf improvement through pcie uplink… why do I only recognize this now…
13:37 gnurou: Yoshimo: on Maxwell 2 the firmware is loaded by secboot, not gr. Should be in nvkm/subdev/secboot in the Nouveau tree, but it wasn't merged for 4.4
13:37 Yoshimo: ah ok so it is definet´ly the kernel that is too old ok
13:38 gnurou: yes
13:38 gnurou: secboot has been merged with 4.6, but of course the more recent the better
13:40 imirkin_: gnurou: did you see my question about your code?
13:41 imirkin_: from a few days ago
13:41 Yoshimo: while you are around gnurou any update for reclocking the newer maxwell cards any time soon and the plans for the ne 1080 and related?
13:42 imirkin_: gnurou: it seems like gr/ is never appended to the paths...
13:42 gnurou: Yoshimo: Laaa la la la
13:42 gnurou:covers his ears
13:42 imirkin_: gnurou: oh, are you saying that i was looking at gr code but should have been looking at secboot code? that seems plausible...
13:43 gnurou: Yoshimo: sorry :) I cannot give any estimate for that, screwed up badly in the past and don't want to do the same mistake
13:43 Yoshimo: you should better cover your eyes instad, but it is sad to have a new generation of cards and not being able to use the older card before that ;)
13:43 gnurou: Yoshimo: all I can say is that this is not under my control (else it would have progressed :/)
13:43 gnurou: imirkin_: yes, all signed firmware is managed by secboot and thus loaded there
13:43 Yoshimo: i assume so, just had to mention it once again so it won't be forgotten
13:44 gnurou: Yoshimo: oh don't worry, I am constantly reminded of this >_<
13:45 gnurou: well technically reclocking *should* be feasible... it's just that you then cannot control the fans and thermal throttling will seriously limit performance
13:45 gnurou: not to mention the card will get hot... but still it shouldn't die
13:46 imirkin_: gnurou: i dunno, i've pretty much written off the possibility of nvidia gpu's being usable with open-source in the future
13:47 Yoshimo: well the maxwell reclocking branch for the v1 of the series didn't get a usefull log on the 980 so somthing is still missing
13:47 imirkin_: gnurou: on the bright side, amd gpu's are faring much better now, so that provides a viable solution for linux users
13:47 Yoshimo: and reducing lifetime by overheating is also not a good outlook
13:48 gnurou: in any case I am done with promises for the future... I will just do my best
13:49 gnurou: which probably won't come close to enough enough
13:49 gnurou: to being enough
13:49 Yoshimo: would you be able to steer these guys into how to do reclocking without fan control? ;)
13:51 imirkin_: gnurou: you've been most helpful :) but sadly you don't control the policy at nvidia
13:51 imirkin_: [or do a *really* good job of hiding it if you do]
13:51 karolherbst_work: gnurou: hi gnurou :p
13:52 imirkin_: i think ultimately there will be a reversal of the mantra "use nvidia if you want graphics to work" towards amd. but it'll take a few years.
13:53 gnurou: actually I think that our (NV employees) involvement with Nouveau may eventually have *hurt* support
13:53 gnurou: say that we never officially release any Maxwell FW, and never submitted code to load it
13:54 imirkin_: someone would have had to RE it ... iirc ben spent quite some time trying to work it out
13:54 imirkin_: and if he can't do it, No One Can (tm)
13:54 gnurou: what would likely have happened is that someone would have found a way to extract the FW blob from the proprietary driver (when it is running), load it from Nouveau, and RE the protocol to control fans and the rest
13:54 imirkin_: [ok, probably not, but it indicates a certain level of dedication]
13:55 gnurou: and at the end of the day we won't be wondering when a more capable firmware is released
13:55 imirkin_: gnurou: the second bit of this is that the fw blob is no longer easily findable in traces =/
13:55 imirkin_: otherwise we would have done that in a second
13:55 gnurou: well on the other hand you could not redistribute the FW, but support would still be better
13:56 gnurou: imirkin_: not in traces, but it is in VRAM
13:56 imirkin_: just as we had done with prior generations
13:56 imirkin_: hmmmm good point
13:56 gnurou: a big fat blob, ready to be run
13:56 imirkin_: and it's probably loaded via pointer in falcon rather than written to the code/data ports
13:57 imirkin_: (since if it were, we would have had it in traces)
13:57 gnurou: imirkin_: it is
13:58 gnurou: still, I think you guys have RE'd worse than that
13:58 imirkin_: i think doing this would require a new infusion of enthusiasm into nouveau
13:59 gnurou: and would probably have done it, if not for us interfering
13:59 imirkin_: maybe. i do know that ben tried a whole bunch of things.
14:05 imirkin_: simultaneously i've been providing substandard support for maxwell+ [and have no plans on changing that until the firmware issue resolves itself one way or another]
14:13 gnurou: imirkin_: I can tell you are not happy about the situation :)
14:13 gnurou: (neither am I, TBH)
14:13 imirkin_: not *extremely*, no
14:15 imirkin_: but i have neither the time, nor the expertise, nor the hw [in that order of importance] to do anything about it
14:18 hakzsam: well, I do work on maxwell, it's slow-going but hopefully we will have GL 4.3 in few weeks
14:24 Yoshimo: i have a card you have the skills, is there something we can work out to find that blob imirkin?
14:43 imirkin_: Yoshimo: you missed the most important bit - time.
14:44 imirkin_: Yoshimo: also i don't have the expertise in that area, although with time i could obtain it
14:44 Yoshimo: i can only talk about me there of course and i made an offer for lending a bit of mine to the cause, if someone wants to take me up on that its fine. If not well its fine too
14:47 Yoshimo: you were the one joining the conversation and looked a bit frustrated about the whole situation, you were the first that came to mind therefore
14:57 karolherbst_work: nobody is frustrated about the whole situation :p
14:57 imirkin_: i am!
14:57 karolherbst_work: sure
14:58 karolherbst_work: allthough it actually bothers me, that we can't relock those maxwell2 gpus
14:58 karolherbst_work: because we have the code already for it :/
15:00 hakzsam: tess/images are frustrating on maxwell too (really different) :/
15:01 Leftmost: I've been working on the tess, but I'm inexperienced and slow.
15:02 hakzsam: tess is hard on maxwell
15:05 hakzsam: but images are almost done
15:05 Yoshimo: karol did you read what alexandre said earlier? "[15:45] gnurou: well technically reclocking *should* be feasible... it's just that you then cannot control the fans and thermal throttling will seriously limit performance"
15:11 Lekensteyn: skeggsb_: if I'm not mistaken "drm/nouveau/disp/sor/gf119: select correct sor when poking training pattern" is a revert of "drm/nouveau/disp/sor/gf119: both links use the same training register", why isn't it just a straight Revert then? (and what about the original issue that the patch was supposed to fix)? Just curious
15:11 imirkin_: Lekensteyn: off by one letter
15:12 imirkin_: l vs s
15:12 karolherbst_work: Yoshimo: guess why I said that we have the code
15:13 Yoshimo: i thought your code only worked with the first gen?
15:13 karolherbst_work: well
15:13 karolherbst_work: we could upload the pmu code on maxwell2 too
15:13 karolherbst_work: but as gnurou said: we have no fan control
15:14 imirkin_: karolherbst_work: i guess it'd be safe if there is no fan, e.g. in a laptop
15:14 karolherbst_work: and without fan control it is kind of pointless
15:14 imirkin_: (or rather, where the fan is controlled by a diff subsystem)
15:14 karolherbst_work: imirkin: true
15:15 karolherbst_work: mupuf_ said that the fsrm might be not enable too
15:15 karolherbst_work: and without that I wouldn't really want to reclock either
15:15 karolherbst_work: having no overheating protection kind of sucks
15:17 karolherbst_work: Lekensteyn: you had a mobile maxwell2, right?
15:17 Lekensteyn: imirkin_: ah, almost missed that, the (reverse) diff has the same pattern. Only one letter of a difference...
15:17 imirkin_: Lekensteyn: yep, easy to miss
15:17 Lekensteyn: karolherbst_work: not sure if it is 2, does PCI ID 10de:13d9 help?
15:18 karolherbst_work: Lekensteyn: GM20x, right?
15:18 imirkin_: Lekensteyn: yep, GM204M
15:18 imirkin_: according to pci.ids at least
15:18 Lekensteyn: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204M [GeForce GTX 965M] [10de:13d9] (rev ff)
15:18 karolherbst_work: Lekensteyn: if you had maxwell1, you would be able to reclock it ;)
15:18 karolherbst_work: mhhh
15:19 karolherbst_work: maybe I find some time on the weekend
15:19 karolherbst_work: but I have really now clue how the pmu stuff would work out there
15:19 karolherbst_work: *no
15:19 karolherbst_work: gnurou: could we upload the nouveau pmu image just like on gm10x?
15:20 imirkin_: karolherbst_work: sure
15:20 imirkin_: the secure thing just prevents that code from accessing certain things
15:20 karolherbst_work: good
15:20 imirkin_: doesn't prevent you from uploading + running unsigned code
15:20 karolherbst_work: so, if we know we have no fan, we could just reclock then
15:20 imirkin_: [there might be a mode which requires signed code, i forget, but nouveau certainly doesn't flip the gpu into that mode]
15:21 karolherbst_work: we should just check if the fsrm isn't in place for sure though
15:21 Lekensteyn: reclocking is not a must for me but I would be glad if I could help out there. For me an external monitor and runtime PM are more important (v2 patches for the latter will be sent "soon" once I figure out one edge case)
15:21 karolherbst_work: Lekensteyn: well at some point you need higher pcie/memory speeds
15:21 karolherbst_work: especially with offloading and big screens
15:23 Lekensteyn: if you still need ssh access for testing, let me know so I can swap disks
15:24 karolherbst_work: we also have some gm20x cards I think
15:24 karolherbst_work: hakzsam: I assume one is in reator currently?
15:24 hakzsam: gm107
15:24 karolherbst_work: ohh, k
15:25 karolherbst_work: well everybody is free to send me a maxwell MXM card *cough*
15:25 karolherbst_work: :p
15:26 hakzsam: actually two, because I need one too :p
15:27 karolherbst_work: :D
15:27 karolherbst_work: I would gladly accept a 970M :D
15:27 karolherbst_work: allthough the 965M should be already faster than mine
15:27 hakzsam: but not right now because maxwell only exposes GL 3.3 :)
15:28 karolherbst_work: true
15:28 karolherbst_work: my fans are good for around 77W though
15:29 imirkin_: so no 90W light bulbs? but 75W ones are fine? :)
15:29 karolherbst_work: yes
15:29 RSpliet: s/light bulbs/heatballs/i
15:30 karolherbst_work: ohh right, I managed to get my gpu above the 75W TDP...
15:30 karolherbst_work: well actually above 80W too
15:30 karolherbst_work: because the vbios tells me 80W
15:30 karolherbst_work: but while running the card at 79W+ consumption, the heat raised to like 102°C
15:33 karolherbst_work: Lekensteyn: there is one thing you could do
15:33 karolherbst_work: ohh wait, no, nvm
15:34 karolherbst_work: it only works for [nvc0,nvf0)
15:36 Lekensteyn: karolherbst_work: I have a nvc0 at home, but I think with 4.5 or 4.6 it throws a lot of nouveau errors to the point of hanging/delaying boot iirc
15:37 orbea: if i upgrade mesa, the changes should take effect next time I start a gl program, right?
15:37 dcomp: I suspect the guesses in gk104_ram_init are incorrect
15:37 karolherbst_work: orbea: yes
15:37 karolherbst_work: dcomp: which guesses?
15:37 orbea: thanks
15:38 dcomp: the count and data
15:38 dcomp: 0x128f: 11 15 13 0b 10 04 00 40 00 00 00 00 00 00 00 00 b0 15 00 00 03
15:38 karolherbst_work: ahh
15:38 karolherbst_work: might be
15:38 karolherbst_work: mhh
15:38 karolherbst_work: 0xb0 and 0x3
15:38 karolherbst_work: looks fine?
15:39 karolherbst_work: dcomp: soo, what is the error?
15:39 karolherbst_work: cnt = 3 and data is 0xb0
15:39 karolherbst_work: looks okay to me
15:40 karolherbst_work: dcomp: just to make sure: 0x10 is 16 and 0x14 is 20
15:40 karolherbst_work: you know this, right?
15:40 dcomp: http://pastebin.com/aGD29XMn
15:40 mupuf_: karolherbst_work: yeah, the FSRM may not be set up properly for secondary cards. We need to check if nouveau makes the writes or not
15:40 mupuf_: (based on the vbios's scripts)
15:41 karolherbst_work: ahh
15:41 karolherbst_work: mupuf_: but what if you have a laptop with intel + maxwell2
15:41 karolherbst_work: this should be fine, right`
15:41 karolherbst_work: mupuf_: and then we could simply reclock laptop maxwell2 gpus, because we don't care about the fan anyway and let the EC do the stuff
15:42 karolherbst_work: if we have no fans from the vbios
15:42 karolherbst_work: or detect we have none
15:42 dcomp: NVIDIA runs 1 script with 10f65c = 0x10
15:42 dcomp: Nouveau runs that same script with 10f65c = 0x20
15:43 karolherbst_work: [0] 819.836790 MMIO32 W 0x10f65c 0x00000020 PBFB_BROADCAST+0x65c <= 0x20
15:43 karolherbst_work: nvidia does it too with 0x20
15:44 karolherbst_work: well maybe another one
15:44 karolherbst_work: anyway, skeggsb_ knows that some stuff are still missing and he has a collection of gpus which won't memory reclock yet or maybe they do
15:45 karolherbst_work: dcomp: ohhh
15:45 karolherbst_work: dcomp: I am sutpid, this was nouveau and not nvidia
15:45 karolherbst_work: my mistake
15:45 dcomp: My nvidia trace doesn't set 10f65c to 0x20 at all
15:46 mupuf_: karolherbst_work: yeah, that should be OK
15:55 karolherbst_work: mupuf_: is there a way to detect there is no fan for sure?
15:58 karolherbst_work: dcomp: I assume you can't reclock your gpu even with all my patches (newest version)?
15:58 karolherbst_work: dcomp: you should try to talk with skeggsb_, maybe he knows something
15:59 dcomp: karolherbst_work: Ive been unable too use thr card atm. But I think Im on thr right track
15:59 karolherbst_work: I see
15:59 karolherbst_work: got to go know anyway. skeggsb_ is the better person to talk too for this anyway I think.
20:29 RushPL: ok guys, I'm getting T440p with Nidia gt 730m - I see it has reclocking support. Should I be excited? Will it work fine with DRI_PRIME=1 ?
20:30 RushPL: fine = performing :P
20:46 urmet: unrelated: are there any signs of pascal support? :)
20:47 mupuf_: karolherbst: not really, no. Some fans may have a fixed power input but may still have a GPIO for the RPM
20:49 imirkin_: urmet: no.
20:49 imirkin_: RushPL: maybe, maybe not - give it a shot. gt 730m could be a fermi i think, in which case, no reclocking
20:50 imirkin_: oh hm, according to pci.ids, should be GK107M or GK208M, both of which should be reasonably well supported
20:50 RushPL: imirkin_: it's listed as Kepler https://nouveau.freedesktop.org/wiki/CodeNames/#nve0familykepler
20:52 imirkin_: RushPL: such things are not absolute. marketing folks like to dick around with this stuff.
20:53 RushPL: I see ... I'll be testing it anyway
20:58 karolherbst: RushPL: don't bother with a 730m
20:58 vita_cell: guys, it is possible to have installed nouveau+blob, and manually select what driver to load?
20:58 vita_cell: 730 gddr5 works fine
20:58 karolherbst: RushPL: intel cards aren't that much slower
20:58 karolherbst: and will run better than nouveau
20:59 karolherbst: vita_cell: well, you need to change the kernel driver on the fly
20:59 vita_cell: my intel 4000hd doesn't run better that nouveau+730
20:59 karolherbst: vita_cell: 730m
20:59 vita_cell: 730m probably better stay with some Intel gpu
21:02 vita_cell: karolherbst do you think that in GNU/Linux 4000hd works as good as in Windows
21:02 imirkin_: RushPL: if you're looking for good open-source support, try to get a laptop with an amd gpu
21:03 vita_cell: imirkin I have one with 8670m, and slow and bad like hell
21:03 vita_cell: + switcheroo doesn't work correctly, almost it doesn't
21:03 imirkin_: vita_cell: have you reported issues to the amd team?
21:03 vita_cell: not
21:04 vita_cell: because anyway, 8670m doesn't run better that intel 4000hd
21:04 glennk: 8670m is a pretty low end dgpu isn't it?
21:04 karolherbst: vita_cell: well, I have no issue with an intel hd4000
21:04 vita_cell: very very shit, I can not understan, why HP built-in 8670m in an laptop with 4000hd, which runs a bit better
21:05 karolherbst: vita_cell: there are a lot of those laptops around....
21:05 vita_cell: so, I payed some more money for useless problematic GPU
21:05 glennk: laptop manufacturers seem to like running single channel memory, and then a low end dgpu also with its own single channel memory
21:05 karolherbst: intel should have add iris gpus to i5 and i3 as well ....
21:06 vita_cell: 8670m 64bits of gddr3
21:06 karolherbst: uhhh
21:06 karolherbst: DDR3 is faster, right? :D
21:06 vita_cell: laptops with Iris, are not common
21:06 karolherbst: vita_cell: because they are too exepnsive
21:06 glennk: probably as they use about as much power as a faster dgpu :-/
21:06 karolherbst: and that's why intel should have made i3 and i5 iris
21:07 karolherbst: glennk: not really
21:07 vita_cell: ddr3? 64bits? probably you can better performance with Intel gpu with dual channel ddr3 RAM
21:07 glennk: the edram ones definitely
21:07 karolherbst: it doesn't matter on idle
21:08 vita_cell: AMD are furnance + high power consumption
21:08 vita_cell: +firmware blob in kernel
21:09 karolherbst: vita_cell: well, it isn't x86 code afaik
21:10 vita_cell: I don't know what it is that firmware, but it's blob, needed for 3d aceleration and resolution detect
21:11 vita_cell: I can not understan why it is not open-source
21:13 glennk: 3rd party ip involved probably
21:15 karolherbst: most likely
21:32 jvesely: vitac_cell, everything uses fw blobs, nouveau, amd, intel, most wi-fi or high speed networking, ...
21:35 imirkin_: jvesely: well, the nouveau ones are compiled from source that we wrote...
21:37 vita_cell: Maxwell g2 uses blobs
21:39 imirkin_: that's right, because nvidia's hw requires it to be signed
21:39 imirkin_: and nvidia won't sign nouveau's
21:40 Lekensteyn: l1k: do you happen to know if drm-next is supposed to have runtime_usage leaks? (for me, modprobe nouveau runpm=0, rmmod nouveau increases the refcount...)
21:40 l1k: lekensteyn: you mean the series I posted to fix the runtime pm ref leaks?
21:41 karolherbst: Lekensteyn: I have the same issue and l1k patches fixes that :p
21:41 l1k: that series got merged to drm-intel/topic/drm-misc before danvet went on vacation, he said it should "ssoak" there a little.
21:42 l1k: he'll return next week, I'm hoping that he'll send another pull to airlied then so that this gets into 4.8
21:43 l1k: s/ssoak/soak
21:43 l1k: so right now it's not yet in drm-next
21:44 l1k: it's in linux-next though :) didn't hear of any regressions
21:58 vita_cell: imirkin_ what nouveau project would do with Maxwell g2 and the next one?
21:59 vita_cell: (I'm talking about signed firmware)
21:59 imirkin_: vita_cell: can you rephrase your question? i don't understand what you're asking.
22:00 vita_cell: Here is no way to avoid nvidia's signed firmware for make work Maxwell g2 card?
22:00 Lekensteyn: l1k: oh I thought that drm-next would be new enough, let's see if I can find that branch somewhere
22:01 karolherbst: vita_cell: well, if you dont care about fan control+ you can simply use nouveaus firmware
22:01 l1k: lekensteyn: https://github.com/l1k/linux/commits/drm_runpm_fixes_v2_acked
22:02 vita_cell: so, you can make work it without signed firmware? is there some fake firmware?
22:02 Lekensteyn: l1k: should I test it on top of drm-next or w/o?
22:02 karolherbst: vita_cell: what do you mean
22:03 l1k: lekensteyn: well these are bugfixes, it's certainly recommendable to use them. just cherry-pick from that branch on github.
22:03 vita_cell: does maxwell g2 card work without signed nvidia's firmware? so, like a normal nvidias older card with no reclock
22:04 karolherbst: signed firmware has nothing to do with reclocking
22:04 karolherbst: or not directly
22:04 karolherbst: there are co processors on the gpus, which cant access specific things with unsigned firmware
22:04 karolherbst: like fan control+
22:04 karolherbst: but there is more to it
22:06 vita_cell: Ok, co-processors, like Intel vPro, ME...
22:07 karolherbst: vita_cell: no, the one of the nvidia gpus are indeed important for various stuff
22:08 karolherbst: like context-switching or SEQ scripts to reclock memory or video decoding/encoding...
22:09 vita_cell: but do you know why Nvidia doing that in that way?
22:09 Lekensteyn: l1k: for nouveau, are these sufficient: f397b5b a8c6739 3ab4d89 6268975
22:09 karolherbst: vita_cell: does it matter?
22:10 karolherbst: mupuf_: "Devinit scripts are signed and executed on the PMU so that these scripts can configure protected registers like thermal shutdown parameters."
22:11 mupuf_: yes, that is on maxwell
22:11 karolherbst: yeah
22:11 karolherbst: ohh right
22:11 karolherbst: I am stupid
22:11 karolherbst: this doesnt matter when posting the card, right?
22:12 mupuf_: well, it does
22:13 Lekensteyn:applied f397b5b a8c6739, rebooting.
22:13 karolherbst: ohhh
22:13 karolherbst: the falcon stuff is in the open gpu docs now
22:14 l1k: Lekensteyn: stop!
22:14 l1k: Lekensteyn: you're too fast for me :)
22:14 l1k: Lekensteyn: you need four patches:
22:14 vita_cell: karolherbst, previously I played games on GNU/Linux + nouveau, all worked fine (except stuttering and high fps drops), now I am with 730 gddr5, here are only "0f" and "07" pstates. When I playing CS:GO works fine, but I got already 3 crashes, that GPU never crashed in Windows7
22:14 l1k: https://github.com/l1k/linux/commit/636f2247c8141176a1511b8eda40866287514221
22:15 l1k: ugh, sorry, trying again
22:15 l1k: drm/nouveau: Don't leak runtime pm ref on driver unload
22:15 vita_cell: how I can see log correctly in GNU/Linux?
22:15 l1k: drm/nouveau: Forbid runtime pm on driver unload
22:15 karolherbst: ftp://download.nvidia.com/open-gpu-doc/virtual-p-state-table/1/virtual-P-state-table.html
22:15 karolherbst: ...
22:15 karolherbst: this is...
22:15 l1k: drm: Add helpers to turn off CRTCs
22:15 karolherbst: usefull?
22:15 l1k: drm/nouveau: Turn off CRTCs on driver unload
22:15 l1k: Lekensteyn: got that? or already gone rebooting?
22:15 Lekensteyn: l1k: aborting!! ok I'm listening :p
22:16 l1k: phew :)
22:16 karolherbst: ohh
22:16 karolherbst: except this thing: "Fastest thermally sustainable vP-state for the TDP app on worst case silicon, worst case conditions (also known as base clock)"
22:16 l1k: Lekensteyn: yeah these four patches should be sufficient for nouveau.
22:16 karolherbst: 0x38 table, let me check
22:17 l1k: Lekensteyn: I cc'ed you on my e-mails of June 15 and 22 regarding merging of those patches because I understand they're sort of prerequisites for your optimus work.
22:18 karolherbst: mupuf_: ohh, that is the base clock table...
22:18 Lekensteyn: l1k: those are the patches I reviewd/tested right?
22:18 Lekensteyn: I saw your follow up on that, looks sane too
22:19 karolherbst: ...
22:19 karolherbst: they are joking right
22:19 karolherbst: ....
22:19 karolherbst: mupuf_: just by guessing I already knew all which is on that vp thing...
22:20 imirkin_: vita_cell: no, there is no way to have (reasonable) acceleration without firmware signed by nvidia for GM200+
22:20 mupuf_: karolherbst: yeah, but I wonder why they documented this :s
22:20 karolherbst: no idea :D
22:20 mupuf_: we must have gotten something wrong
22:20 karolherbst: well
22:20 karolherbst: it isnt upstreamed yet
22:21 karolherbst: and no, we got it right afaik
22:21 skeggsb_: they documented this because they don't believe we'll be able to properly manage "full" reclocking, and believe we should stick to that clock
22:21 karolherbst: ....
22:21 karolherbst: ....
22:21 karolherbst: are you serious?
22:21 skeggsb_: it makes sense
22:21 karolherbst: well
22:21 skeggsb_: why else only document that, and not the rest
22:22 karolherbst: I default to that on my branch though
22:22 karolherbst: well
22:22 karolherbst: why document it so half assed, if we already know more
22:22 skeggsb_: perhaps they didn't realise
22:22 karolherbst: yeah, most liekly
22:23 karolherbst: but now we know how we should treat those "Reserved" in general
22:23 karolherbst: :D
22:24 karolherbst: in "Virtual P-state Table Entry Structure" the Reserved 32bit thing
22:24 karolherbst: this is something I didnt figure out yet
22:24 karolherbst: but I think it is related to power consumption
22:24 karolherbst: "-- entry 0, pstate = f, unk0 = 7499, unk1 = 4472, clock0 = 1725 MHz"
22:24 karolherbst: where my power budget is like 80W
22:25 karolherbst: maybe it is something like min/max estimated power consumption under full load
22:25 karolherbst: or something like that
22:26 karolherbst: but thanks for the confirmation I guess :/
22:27 karolherbst: display engine also got docs
22:27 karolherbst: nv50-gm204
22:27 karolherbst: ftp://download.nvidia.com/open-gpu-doc/Display-Class-Methods/1/README.txt
22:27 skeggsb_: yeah, they've been around for ages
22:27 karolherbst: really?
22:28 karolherbst: I never see those
22:28 skeggsb_: yep
22:28 skeggsb_: rnndb even got updated as a result, i believe
22:28 karolherbst: mhh
22:28 Lekensteyn: l1k: runpm=0 issue is gone, unfortunately it did not fix runtime_usage=-1 (!) for the HDMI device :(
22:29 karolherbst: modified on "1/13/15, 1:00:00 AM" ...
22:29 karolherbst: k
22:29 karolherbst: the virtual-p-state table doc was added on "6/22/16, 10:01:00 PM"
22:29 karolherbst: fairly new
22:29 skeggsb_: yeah, gnurou pointed it out in here last week i think
22:30 karolherbst: ahh
22:30 karolherbst: yeah well, I am dissapointed
22:30 karolherbst: the thing I didnt figure out isnt documented there :/
22:37 l1k: Lekensteyn: sorry I was briefly AFK. I think you tested v1, but I posted a v2 afterwards based on feedback from danvet. Not that big a difference though between the two versions. v2 is what was merged.
22:38 Lekensteyn: l1k: oh, your patchset is fine! It's just a new issue with the snd-hda-intel driver
22:38 Lekensteyn: that one leaks on rmmod too
22:38 l1k: Lekensteyn: OMG :/
22:41 karolherbst: skeggsb_: maybe I should just finish my dynamic reclocking things before XDC :/ ...
22:41 karolherbst: :D
22:45 karolherbst: well I will head to bed now anyway
22:45 karolherbst: good nigh