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