01:11 Physicist: Hey, I had a question about nouveau and GeForce cards.
01:12 Physicist: Do the Nouveau drivers allow GPU passthrough on GeForce cards (something that nvidia's drivers seem to expressly forbid).
01:13 Physicist: I want run something like Arch Linux as hypervisor and passthrough to a Win10 or SteamOS guest.
01:35 specing: you must not load nouveau or nvidia blob for the device you are passing through
01:35 specing: kernel has a PCI stub driver for this purpose
01:41 Physicist: Ok. I presume then, the guest installs a driver like normal and it isn't even aware it's got this middleman. Right?
01:52 specing: pretty sure
02:43 imirkin: Physicist: only if you have an iommu... otherwise it won't work at all.
02:44 specing: why wouldn't it work?
02:44 specing: the stub driver does pass-through
02:44 MichaelLong: Physicist, this: http://vfio.blogspot.de/
02:44 specing: oh wait, nouveau would need to handle mappings properly
02:46 MichaelLong: Physicist, begin with "VFIO GPU How To series, part 1 - The hardware", I'm using such setup for a quite some time with passed through nvidia (and amd) cards to various linux and one windows guest.
02:47 Physicist: Thanks, MichaelLong. I presume they are the nvidia cards (like GeForce) that do not normally allow GPU passthrough (such as with a VMWare EXDi host)?
02:49 MichaelLong: Physicist, no. typical consumer cards, I've tested dog old cards like a 7300GS, and newer ones 560 Ti and a 980 GTX. except the last one the all run great in linux
02:49 Physicist: Awesome, seeing 560Ti is what I wanted; I'm using a 550Ti.
02:50 Physicist: I would imagine the 980 support will come soon; aren't the standard Linux nvidia drivers proprietary direct from nvidia?
02:51 Physicist: I even saw that NVidia employees have contributed to Noveau.
02:51 MichaelLong: Physicist, I guess so.
02:55 Physicist: Oh man, this is exactly what I was looking for. Thanks again.
02:56 MichaelLong: Physicist, still before getting too excited check your hardware.
02:57 Physicist: I kind of think even if this declares that I "Just can't", that's better than spending days troubleshooting it to no success.
03:03 Yoshimo: https://www.youtube.com/watch?v=dnG0X0uwLuY , Physicist . They have but so far mostly limited to tegra chips
03:23 joi: imirkin: http://people.freedesktop.org/~mslusarz/w2.demmt.xz http://people.freedesktop.org/~mslusarz/w2.txt
03:24 joi: first file is 850MB, 16GB uncompressed
03:27 joi: search from the end, address 0007bf5000 is used twice, it's the next to last which is a problem
05:05 karolherbst: in which subdev should the power sensors be, ptherm?
05:30 karolherbst: https://gist.github.com/karolherbst/fd61f5961c344a9a421e :)
06:42 karolherbst: little question: does this work to get the gpio for memory voltage? ret = nvkm_gpio_find(gpio, 0, 0x18, DCB_GPIO_UNUSED, &func);
06:42 karolherbst: ohh 0x18
06:44 karolherbst: ohh I don't have such gpio
06:53 broucari: Any news of #90976 ?
06:53 broucari: what should I test ?
06:57 karolherbst: broucari: you should wait
06:58 karolherbst: it is a GM20X card
06:58 karolherbst: where nouveau needs signed firmware from nvidia first
06:58 karolherbst: and until that happens, the card is pretty much useless
06:58 broucari: karolherbst: I do not care about 3D. Only modesetting
06:58 karolherbst: which kernel are you running?
06:59 broucari: broucari: 4.1
06:59 broucari: karolherbst: 4.1
07:00 karolherbst: mhhh
07:00 karolherbst: this is a bit strange "nouveau E[ PFIFO][0000:01:00.0] unsupported engines 0x00000001"
07:01 karolherbst: and the kernel channel fail
07:01 karolherbst: you could upgrade to 4.2 or 4.3 kernel and try out the main nouveau tree
07:01 broucari: karolherbst: Will test and report error
07:02 broucari: karolherbst: BTW I have also a nouveau regression on my laptop I am stuck with 3.16 :S
07:02 karolherbst: broucari: you could also open a bug for that
07:02 karolherbst: and if that is a regression you could git bisect it
07:03 broucari: karolherbst: will do
07:04 broucari: karolherbst: what means unsupported engine ?
07:05 karolherbst: something bad happend
07:26 broucari: karolherbst: 4.2 does not work
07:26 karolherbst: you could try out to build nouveau yourself
07:26 karolherbst: http://cgit.freedesktop.org/~darktama/nouveau/
07:26 karolherbst: and load this module then
07:27 karolherbst: when this doesn't help (or the dmesg output doesn't change), then we should dig deeper what the real problem is
07:27 broucari: karolherbst: for 4.2 the output does not change
07:28 karolherbst: it will most likely not change with a new module either, because they aren't that many changes related to your card anyway
07:30 broucari: karolherbst: what should I install for compiling ? kernel source ?
07:39 karolherbst: I guess so
08:30 broucari: karolherbst: I posted lapto crash here 92057
10:18 imirkin: karolherbst: unsupported engine is coz of PGRAPH
10:18 karolherbst: k
10:31 imirkin: mwk: do you know precisely what the blob ctxsw fw does with method 0x2310? it takes 3 scratch values along with a mmio reg, but i'd like to know exactly what it uses the scratch values for
10:40 mwk: imirkin: it's more or less nvmask
10:40 mwk: the param to it is a mmio reg
10:40 mwk: SCRATCH[1] (0x3404) is val
10:40 imirkin: that's what i figured, but it didn't seem apparent exactly how that mask was applied
10:40 mwk: SCRATCH[2] (0x3408) is mask
10:41 imirkin: ohhhhh
10:41 mwk: old = mmrd(reg); mmwr(reg, (old & ~mask) | (val & mask));
10:41 imirkin: interesting.
10:41 imirkin: yeah ok that makes a lot more sense
10:41 mwk: that's on ancient GF100 microcode, but I seriously doubt anything changed
10:41 imirkin: yeah it's unlikely
10:42 imirkin: i'm trying to get gmem to work
10:42 imirkin: and it looks like it clears bits 0x1e000000 in 0x408904
13:46 karolherbst: imirkin: any idea in which subdev I should put the power sensor code?
13:47 imirkin: talk to ben
13:48 pmoreau: karolherbst: If you have any patches, I'd be interested in seeing the power consumption on my laptop. :)
13:49 pmoreau: Guess I could start with Martin's script
13:52 karolherbst: pmoreau: which chip do you have?
13:52 pmoreau: G96 and MCP79
13:53 karolherbst: pmoreau: mupuf only hacked up support for ina3221 and ina219 power sensors and I won't hack in more then stuff he already found out
13:53 karolherbst: he also said he has some patches, so I postponed this part until then
13:53 karolherbst: but I have another task for ya :p
13:53 pmoreau: Hum! :D
13:54 pmoreau: Let's hear about it
13:54 karolherbst: pmoreau: https://github.com/karolherbst/nouveau/commit/967d9788d53a5d03dc7a9bf07f4692d45ee0b652 and https://github.com/karolherbst/nouveau/commit/2ea6ed5be5ad88758623711efecb3452dedbec49
13:54 karolherbst: the former is for support to get the memory voltage
13:54 karolherbst: and the latter for exporting core/memory voltage to perfmon
13:54 karolherbst: I am not sure how to get the memory voltage though
13:55 pmoreau: So I should apply these two patches on HEAD, fiddle with some parameters and hope nothing crashes? O:-)
13:55 karolherbst: actually there are three
13:55 karolherbst: https://github.com/karolherbst/nouveau/commits/master_karol
13:55 karolherbst: last three
13:55 karolherbst: but the middle one is useless for now
13:56 karolherbst: it only contains the stubs for exporting power usage to perfmon
13:56 pmoreau: Ok
13:56 karolherbst: and no, nothing will crash
13:56 karolherbst: the first patch adds a virtual function to nvkm_ram
13:57 karolherbst: I know there are like two gpios for memory voltage, but mhhh
13:57 karolherbst: I don't understand clearly how that works
13:57 karolherbst: I think one gpu sets 1.5V vs 1.8V and the other sets the actual memory voltage to 50% or 70% of the fromer value
13:57 karolherbst: but as I said, I have no idea how that really works
13:57 pmoreau: So what should I look for / test?
13:58 karolherbst: you could try to figure out how to get the memory voltage on your board
13:58 karolherbst: core voltage should work out of the box with those patches
13:59 pmoreau: I should be able to change core voltage, but not memory voltage, right? How do I change it?
13:59 pmoreau: (core voltage that is)
14:00 karolherbst: pmoreau: for me it prints this now: https://gist.github.com/karolherbst/fd61f5961c344a9a421e
14:00 karolherbst: pmoreau: pstates
14:00 karolherbst: and cstates
14:01 karolherbst: pmoreau: but memory voltage should also change depending on memory clock? I don't know
14:01 karolherbst: but nouveau doesn't let you read the voltage yet anyway
14:02 karolherbst: maybe I also drop the idea of exporting memory voltage, because usually you don't care about this
14:02 karolherbst: imirkin: okay, will try
14:05 karolherbst: pmoreau: I hope it works for you though (I mean core voltage)
14:06 pmoreau: Haven't tried yet, but I'll probably do that in a couple of minutes.
14:07 pmoreau: karolherbst: In which commit did you add get_volt function for your card?
14:14 imirkin: karolherbst: if you get a chance, i could use a kepler mmt trace of bin/shader_runner tests/spec/arb_shader_atomic_counters/execution/vs-simple-inc-dec-read.shader_test
14:18 pmoreau: karolherbst: I get a value for Core on the main card, but not on the other one.
14:19 pmoreau: Sorry, it's the opposite: I don't have a value for Core on the integrated one. But it could make sense.
14:30 karolherbst: pmoreau: in none
14:30 karolherbst: pmoreau: ohhh strange
14:30 karolherbst: usually you should get one
14:31 karolherbst: will check it
14:31 karolherbst: G96 is integrated?
14:31 karolherbst: imirkin: okay
14:31 karolherbst: imirkin: blob?
14:31 imirkin: karolherbst: yes
14:31 imirkin: karolherbst: i want to see if it does the same register write as fermi
14:32 karolherbst: cmake piglit run needs too much time :D
14:32 karolherbst: I bet it spends more time configuring the project than compiling it
14:34 karolherbst: imirkin: how long does the test take?
14:35 karolherbst: or do I need "-auto"?
14:35 imirkin: -fbo -auto
14:35 imirkin: like all the other ones
14:35 imirkin: :)
14:35 karolherbst: :D
14:36 karolherbst: imirkin: http://filebin.ca/2GLFQ9yPcVZj/vs-simple-inc-dec-read.xz
14:37 imirkin: thnaks!
14:37 karolherbst: it is quite big, I hope it is okay
14:37 karolherbst: np
14:37 karolherbst: the first time I could use my awesome script :D
14:38 imirkin: oh wow
14:38 imirkin: i am *sincerely* hoping that the blob compiler just throws random nonsensical instructions into the middle of code for no good reason
14:39 imirkin: but the good news is that it doesn't seem like it needs any of that context write bs
14:51 karolherbst: imirkin: I saw them too
14:52 karolherbst: you mean like mov $some_non_used_reg 0x0
14:53 imirkin: karolherbst: no, you're probably misunderstanding what the shader does
14:53 imirkin: karolherbst: but look at the vertex shader in your trace that does the GMEM writes and all
14:53 imirkin: laneids, lanemasks
14:53 imirkin: ugh
14:53 imirkin: and an envydis bug
14:53 karolherbst: ohh okay
14:54 karolherbst: but why should a binary set a reg to 0x0, when this reg gets overwritten later on?
14:54 karolherbst: without being read once
14:55 imirkin: perhaps it is read
14:55 imirkin: could be some sort of fail in the blob, but it's rare
14:55 imirkin: this is tons of code which does things
14:55 karolherbst: I should still have that binary
14:55 imirkin: but which should be much shorter
15:02 imirkin: i'm gonna play more with buffers on kepler then
15:02 imirkin: coz i really don't want to have to modify the firmware
15:02 imirkin: [and more importantly, debug it]
15:03 karolherbst: imirkin: https://gist.github.com/karolherbst/8845221b34120c43947b
15:03 karolherbst: or do I don't see something?
15:03 karolherbst: r8 doesn't seem to be used
15:04 karolherbst: any anyway, I thought r63 is always 0x0?
15:04 karolherbst: so why should the compiler set some reg to 0x0
15:05 imirkin: karolherbst: x = 0; if (foo) x = 5;
15:05 imirkin: oh, and envydis decodes $r63 as 0x0 sometimes
15:05 karolherbst: ohhh okay
15:05 imirkin: see how the second r8 write is predicated?
15:05 karolherbst: ahh yeah
15:06 imirkin: it's precisely the scenario i mentioned
15:06 karolherbst: okay, then I choose a bad example :)
15:06 imirkin: [although there can be other situations]
15:06 karolherbst: the other ones had like 1500 instructions in between
15:07 karolherbst: but okay, that makes somehow sense then
15:08 karolherbst: imirkin: okay, there is no r63 in the file
15:24 mrnuke: imirkin: so, I'm g;ad I actually took some time to test that patch of yours, which you may or may not remember
15:24 mrnuke: I'm sorry to say. I'm just as surprised as you are
15:24 mrnuke: but it works
15:25 imirkin: mrnuke: awesome! i sent a real patch too -- http://lists.freedesktop.org/archives/nouveau/2015-September/022314.html
15:26 imirkin: feel free to reply to that with a Tested-by
15:27 mrnuke: BTW, I was going to ask, what's up with that if of an elseif on a new line style?
15:27 imirkin: mrnuke: dunno. i just followed the existing style.
15:36 mrnuke: heh. I actually thought I found a few bugs, until I realized that those weren't bugs, that's the actual style
15:37 mrnuke: so of course, I used some whisky during the tests, to make sure results are reproducible :p
15:39 imirkin: make sure you use the same brand
15:40 imirkin: otherwise the results may differ
15:43 mrnuke: brand is irrelevant
15:43 karolherbst: pmoreau: are your vbios' inside the git repo?
15:44 mrnuke: the idea is that if I have doubts about the validity of a test, when I repeat it, I don't remember what I did the first time, so I don't make the same mistake twice
15:49 karolherbst: pmoreau: okay, it doesn't make sense, that you don't get the voltage for both
15:49 karolherbst: something is funny then
15:59 karolherbst: okay, I think pcie speed changes are done for kepler+ now
16:01 mrnuke: imirkin: I'll admit, I have no idea how to reply to a mail to a list that I'm not subscribed to
16:02 imirkin: mrnuke: ah yeah, that can be annoying
16:03 imirkin: well wtvr
16:04 mrnuke: well, feel free to add Tested-by: Martin Nukerton <mr.nuke.me@gmail.com>
16:04 mrnuke: JK, that's not my real name
16:11 mrnuke: "gr: GPC0/TPC1/MP trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp 10009 [INVALID_ID_OPCODE]"
16:12 mrnuke: well, that's new. Plenty of those too
16:13 imirkin: mrnuke: do you have the latest mesa? at least 11.0?
16:13 imirkin: i fix maxwell issues every so often
16:14 mrnuke: let mecheck
16:19 karolherbst: imirkin: do you think the pcie speed stuff is different on GM20x? It works on GM10x so I assume it also should work on GM20x :/
16:19 imirkin: no clue
16:21 karolherbst: at least I know I should not touch nvea :D
16:25 mrnuke: imirkin: guess what. I was still stuck on 10.6.3 :D
16:25 karolherbst: mhhh, I wonder again: why are there only G84+ cards with CARD_SPEED==5.0
16:25 karolherbst: and noone with 2.5
16:27 imirkin: mrnuke: hmmmm... dunno if i've fixed anything of consequence since then, i forget
16:27 imirkin: might have broken a thing or two as well :)
16:34 karolherbst: okay, that's plain wierd now, why can I call functions which doesn't exist
16:35 karolherbst: did I ignore a warning somehow all the time?
16:41 mrnuke: imirkin: OK, so I'm on 11.1.0. The error messages went away, and it seems to be far less horny to freeze up
16:42 mrnuke: but it's very seizure inducing
16:42 mrnuke: it's like top half of screens are painted, and the bottom half is black
16:42 mrnuke: and that happens very very fast
16:43 mrnuke: and the GPU gets quite hot too :)
16:44 mrnuke: I should probably take a video and show you
16:52 karolherbst: if somebody wants to try out pcie speed changes on kepler+ (or fermi pcie version change): https://github.com/karolherbst/nouveau/commits/pcie_speed
16:59 karolherbst: imirkin: somehow I like to talke with these eon guys, doesn't seem to be techicall unaware support guys with no clue at all
16:59 mrnuke: imirkin: https://www.youtube.com/watch?v=ddwy2JZjwZw
17:00 karolherbst: a nice desktop effect you got there
17:00 karolherbst: somehow this remainds me of a really bad kind of tearing issues :D
17:00 karolherbst: mrnuke: try to disable tearing prevention for now
17:01 imirkin: is the tearing/flashing just a camera artifact, or is that real?
17:02 karolherbst: imirkin: I think it is real :p
17:02 mrnuke: imirkin: that's real
17:03 mrnuke: with two screens, everything's perfect
17:03 mrnuke: three screens, and the fan gets struck by defecation
17:03 imirkin: maybe something has an 8k limit that we're not respecting
17:03 karolherbst: mrnuke: does changing something in tearing prevention changes anything?
17:04 karolherbst: full scene repaints are kind of heavy when not right implemented :/
17:04 mrnuke: imirkin: same issue when I make the monitors fit in a 8k x 8x FB
17:04 imirkin: hm ok
17:04 mrnuke: karolherbst: no. Whatever I change in that KDE menu has no effect on display with 3 screens
17:04 karolherbst: mrnuke: okay
17:05 mrnuke: it could be KDE has some bugs too, but I didn't see this on Intel hardware with similar size framebuffer
17:07 karolherbst: would be funny if changing pstates change anything
17:07 karolherbst: maybe the clock is just too slow?
17:13 karolherbst: imirkin: https://openbenchmarking.org/result/1509200-BE-NOUVEAUPS46
17:13 karolherbst: don't know who did this, but mhhh
17:14 karolherbst: the boost are pretty small
17:14 karolherbst: *is
17:14 karolherbst: maybe these games are just strange
17:16 imirkin: well, they become more core-limited than memory-limited
17:16 imirkin: could be coz we don't make good enough use of the cores
17:16 karolherbst: maybe, or hte games are just plain wierd
17:17 karolherbst: they have also a settings to use more of the vram
17:17 karolherbst: vor vertex shader
17:17 karolherbst: *for
17:17 karolherbst: or something like that
17:17 karolherbst: to store them there? I don't know
17:17 karolherbst: something unusual
17:17 karolherbst: VBOs, right
17:18 karolherbst: like you can disabled VBOs entirly, and this isn't part of the video settings
17:19 imirkin: what is and isn't part of "video settings" is entirely game-specific
17:19 imirkin: as well as what each thing in those settings means
17:20 karolherbst: yeah I know, but they describe it like "use VBOs for storing stuff inside vram"
17:21 karolherbst: I can only imagine, that they tray to do shady things to not use vram too much, dunno
17:23 imirkin: you definitely want to use VBOs :)
17:23 karolherbst: yeah, I have them all enabled
17:23 karolherbst: there are 4 settings for this :/
17:24 karolherbst: and they are not effected if you set the graphic settings to "ultra" or "low" or anything
17:24 karolherbst: anyway, unigine should be a much better benchmark :D
17:35 mrnuke: so, is there a way to find out what cocks the GPU is running?
17:35 mrnuke: s/cocks/clocks/g
17:36 mrnuke: well, _easy_ way I should say
17:36 imirkin: should tell you on load
17:36 imirkin: you want the AC line
17:38 chithead: cat /sys/class/drm/card0/device/pstate
17:39 chithead: (if card0 is your nvidia card)
17:42 mrnuke: chithead: no such file or dir :(
17:43 karolherbst: mrnuke: it has to be enabled through nouveau.pstate=1 first
17:43 chithead: you need a recent kernel and nouveau.pstate=1 kernel parameter
17:43 karolherbst: but I wasn't talking about thouse clocks
17:43 karolherbst: but more the hidden one
17:44 karolherbst: but pstate will change them too
18:04 mrnuke: http://paste.fedoraproject.org/269548/44279735/
18:04 mrnuke: no idea what that means, but I'm assuming it means clocks aren't at snail pace
18:12 imirkin: mrnuke: that means clocks are at their low level, which is expected, that's how most cards boot
18:13 mrnuke: imirkin: So, I did "echo 0f > /blablabla", and now it shows core at 1037MHz, memory at 810 MHz
18:13 mrnuke: should I believe those numbers?
18:14 mrnuke: I'm still seeing the same tearing and flickering as before
18:15 imirkin: mmmmmaybe
18:15 imirkin: i didn't think reclocking on maxwell was hooked up
18:16 mrnuke: maybe if it gets even hotter, that's a good sign?
18:17 mrnuke: 61C vs 55C before
18:17 mrnuke: or maybe it's just getting hotter in here. Today has been a bitch, and I don't have air conditioning