00:07imirkin: orbea: that happens when there's a desync between the commands being written and the parser
00:07imirkin: [or an outright bug in nouveau]
00:08imirkin: method 360 is something we emit when we update fragment shaders
00:08imirkin: i guess something like that could also happen if something's triggering concurrent draws
00:09orbea: that was my first guess, but nothing I have tried is doing it...either Im missing something or its been resolved...
00:10imirkin: subc 0 mthd 000c data 20040360
00:10imirkin: the actual deal is that 20040360 is a command itself
00:10imirkin: [i can tell, coz i've stared at these a lot]
00:11imirkin: but it's being read in as data
03:00Yuken: I have nouveau installed and set to use nouveau in my xorg.conf and additional drivers page, yet glmark2 is reporting " GL_VENDOR: VMware, Inc." and the resolution of the machine is stuck at 1024x768 on a GTX 860M under Lubuntu 15.10. I've also asked at #ubuntu
03:01sarnex: Yuken: what about DRI_PRIME=1 glmark2
03:01Yuken: sarnex, not sure exactly what you mean there. Is that a launch option or config option to glmark2?
03:01sarnex: vmware means software, there is some underlying issue
03:01sarnex: can you paste xorg.log
03:01Yuken: Where would I find that?
03:03Yuken: No, I can not, apparently. No connection to anything other than IRC due to current network issues, can't connect to anything that uses HTTP/HTTPS.
03:04sarnex: ok i have to go, but someone helping will likely need that and dmesg
03:04Yuken: While I wait for a proper connection, I'll check out the log file myself and see if anything is woefully obvious.
11:59hussam: Is there a memory leak with hibernate/resume on nouveau? Every time I hibernate/resume, 100MB of memory gets eaten.
11:59hussam: doing systemctl isolate rescue.target doesn't free it.
11:59hussam: so it's in the kernel
12:00hussam: using the proprietary driver doesn't have such issues.
12:24RSpliet: hussam: I wouldn't rule it out completely... how do you measure that memory usage?
12:25hussam: free -m
12:25RSpliet: okay, which GPU and kernel are you using?
12:26hussam: 630GT GF108 (a fermi card). linux 4.5
12:27RSpliet: in that case, I'm sorry it's only general advice, but would you mind filing a bug on the freedesktop bugzilla please?
12:28RSpliet: I find it very difficult to judge whether the memory is actually missing or just ends up in cached pools
12:29karolherbst: hakzsam: do you know if ST_DUMP_SHADERS will dump compute shaders?
12:31hussam: RSpliet: https://bugs.freedesktop.org/enter_bug.cgi no nouveau product.
12:31RSpliet: hussam: here's some general guidelines for filing bugs: https://nouveau.freedesktop.org/wiki/Bugs/
12:31RSpliet: I guess the answer to your question would be "Bugs in the 2D driver and the Nouveau DRM (kernel) part are filed under product “xorg”, component “Driver/nouveau”"
12:39hussam: RSpliet: I don't know much about this but it is possible when I hibernate, the used gpu memory is pushed into swap for hibernating then when resuming, it is is pushed into both system memory and gpu memory instead of just gpu memory? then after a few hibernate cycles, system memory is polluted with stuff that should have been freed?
12:40hussam: filing a bug now.
12:46hussam: On an unrelated note, this could be a general Linux issue?
12:47karolherbst: hussam: try suspending 100 times
12:47karolherbst: if it is a leak which occurs on every suspend, after 100 times you should have a really high memory usage
12:48karolherbst: hussam: but the only value which is important in free -m is used
12:48karolherbst: free means nothing
12:49karolherbst: well, if free is too big you have a problem somewhere, but this isn't related to anything you encounter
12:49hussam: karolherbst: I'm back on the proprietary driver right now because gnome-shell uses 30% CPU on noueau.
12:49karolherbst: yeah, the CPU usage is known
12:50karolherbst: it's mostly causes by busy waiting on stuff I think
12:50hussam: I'm not complaing. I plan to eventually migrate to nouveau so I test it every new mesa/Linux kernel release.
12:50karolherbst: well what changes in free -m after you resume?
12:51hussam: used column does.
12:51hussam: buff/cache column fluctuates.
12:52karolherbst: okay, that means something happens currently
12:52karolherbst: -+10m is normal, but if it changes much more
12:52karolherbst: then something causes disc io
12:52karolherbst: you could check if something does something stupid after resume with iotop
13:14Misanthropos: karolherbst, i took your drm tree 4.6_reclock and it works. i just get a message from the kernel: [ 9084.333676] nouveau 0000:04:00.0: clk: failed to set cstate 160
13:14Misanthropos: [ 9084.333681] nouveau 0000:04:00.0: clk: error setting cstate 160: -22 like ever second
13:14karolherbst: yeah, okay something is odd
13:15karolherbst: Misanthropos: I don't know if that works, but can you echo -1 into pstate?
13:15Misanthropos: karolherbst, i just replace the novueau tree from your repository and put it to the kernel tree, right?
13:15karolherbst: like you did. the error only occurs on my tree anyway
13:16Misanthropos: echo -1 >pstate
13:16Misanthropos: bash: echo: write error: Operation not permitted
13:16karolherbst: ahh okay
13:16karolherbst: why doesn't it want to set the cstate
13:16karolherbst: Misanthropos: last line of pstate?
13:17Misanthropos: AC: core 324 MHz memory 5400 MHz
13:17karolherbst: content of boost?
13:17Misanthropos: 2: 1032 MHz
13:17karolherbst: can echo echo 2 into boost?
13:18Misanthropos: *2: 1032 MHz
13:18karolherbst: is the error still printed?
13:18karolherbst: and last line of pstate?
13:18Misanthropos: let me see
13:19Misanthropos: AC: core 1032 MHz memory 5400 MHz
13:19karolherbst: mhh okay
13:19karolherbst: and the message stopped for sure?
13:19Misanthropos: but: no prints anymore confirmed
13:19karolherbst: then I know what the issue is
13:19karolherbst: your vbios doesn't contain any base clocks
13:19karolherbst: and boost 0 and 1 (default) are limiting the clocks to the base/boost clocks
13:19karolherbst: but for your base and boost point to the entry 0xff
13:20karolherbst: which means disabled
13:20RSpliet: karolherbst: could you verify that with the VBIOS first?
13:20karolherbst: RSpliet: I have his
13:20RSpliet: ah okay
13:20karolherbst: but if there would be valid entries, boost would contain a line with 0 and 1 too
13:21Misanthropos: so it did not reclock before?
13:21karolherbst: not fully
13:21karolherbst: only memory
13:21karolherbst: but the error message every second is caused by the nouveau thermal daemon
13:21karolherbst: it checks the temperature and adjust the clocks/voltage according to ti
13:21karolherbst: and it tried to set an invalid cstate every second
13:22Misanthropos: well i think i have to test a game then to see if its stable.. i thought it was clocked to 0f
13:22Misanthropos: but it was not obviously
13:22karolherbst: you should have wondered about the poor performance :D
13:23Misanthropos: it was actually ok
13:23karolherbst: I don'T know where this number 160 comes from though...
13:34Misanthropos: karolherbst, i just tested a game with the current settings and it seems to be stable. It normally froze in between some minutes... and did not.
13:38karolherbst: Misanthropos: when did you update my nouveau tree?
13:40Misanthropos: yesterday night
13:40karolherbst: Misanthropos: mind updating the tree again?
13:40karolherbst: and see if you can recock to 0f without the stupid issues now
13:41Misanthropos: using stable_reclock_kepler_v2?
13:41karolherbst: Misanthropos: also can you echo 1 into boost and tell me what happens?
13:42Misanthropos: 2: 1032 MHz and messages started again
13:42karolherbst: I should validate this a bit
13:42Misanthropos: karolherbst, which branch should i take?
13:43karolherbst: the same
13:44Misanthropos: there was no change
13:44Misanthropos: except: + e3abcc8...6be203e stable_reclocking_kepler_v2 -> origin/stable_reclocking_kepler_v2 (forced update)
13:45karolherbst: did you use git fetch?
13:45Misanthropos: no. i used pull
13:45karolherbst: mhh I don't know how pull handles forced updates...
13:46Misanthropos: i take whats there
13:46karolherbst: commit hash of newest commit?
13:46karolherbst: should be 6be203e78242472f3fa17953d1b7cf73e2061b0a
13:46karolherbst: git reset --hard origin/stable_reclocking_kepler_v2
13:47Misanthropos: now its correct
13:47Misanthropos: i take that branch and apply it to the kernel
13:50RSpliet: karolherbst: on monday I'm getting a GTX 780 to borrow for a few days
13:50RSpliet: will you be around to debug PM related issues?
13:51karolherbst: RSpliet: yeah
13:51karolherbst: but on this the clock readings are wrong
13:51karolherbst: we would have to fix those first I think
13:52RSpliet: what's wrong with them?
13:52karolherbst: it's just wrong
13:52karolherbst: there are new regs
13:53karolherbst: in [137000+0x0, 137000+0x20)
13:53RSpliet: that doesn't sound too wrong
13:53karolherbst: and they change the GPC clock
13:53karolherbst: we read soemthing different
13:53karolherbst: and then it is impossible for us to now which cstate nvidia clocked the card to
13:54RSpliet: meh, I don't have a mountain of time to debug all of that, but that probably has sth to do with the very high clocks?
13:54RSpliet: did you try interpreting them as two PLLs, one as input for the other?
13:54karolherbst: it is just parsing the reg right and check with the GPC clock in nvatiming
13:54karolherbst: nvatiming is also broken
13:55karolherbst: it doesn't get the GPC count
13:55karolherbst: and I think there is another issue somewhere related to that
13:55karolherbst: RSpliet: no, because the difference is too small, or maybe I should have, don't know
13:55RSpliet: didn't you fix that when adding support for maxwell?
13:56RSpliet: okay, but bad reads imply that we also write the clock incorrectly...?
13:56karolherbst: I only fixed the engines on maxwell
13:56karolherbst: RSpliet: well yes, maybe
13:56karolherbst: it affects nvf0, nvf1 and all maxwells
13:56karolherbst: but maxwell2 more than maxwell1
13:56karolherbst: on maxwell there are even more changes
13:56karolherbst: so I want to get nvf0
13:56karolherbst: /nvf1 working first
13:56karolherbst: and then look into maxwell
13:57RSpliet: hmmm okay
13:57RSpliet: well, I'll get data asap
13:58RSpliet: if you have time that'd be grand
13:58karolherbst: yeah I suppose I will have
13:58RSpliet: (as your head is more emerged into these devices as mine)
13:59karolherbst: hakzsam: saintrs row IV is free this weekend
13:59karolherbst: ohh wait
13:59karolherbst: this was long time ago
14:10karolherbst: RSpliet: but I doubt there will be any issues related to volting with my branch anymore. I just think that the new clocking regs might affect stability somewhat?
14:17karolherbst: ... 780 ti 286 points in pixmark_piano on 2560x1440...
14:39mupuf: karolherbst: ah ah
14:39mupuf: how long was the test?
14:39mupuf: 20 seconds?
14:39mupuf: score = frame rendered during the execution
14:40mupuf: it should be frame rendered / time
14:40karolherbst: I think a full becnhmark run
14:40mupuf: yes, but how long did you configure it to run?
14:40mupuf: 30 seconds? 20 seconds?
14:40mupuf: it is in the config file
14:40karolherbst: I didn't do it
14:40karolherbst: but I try to find out
14:41karolherbst: 60000 ms
14:42mupuf: so, that's 3.5 FPS :D
14:42karolherbst: yeah but on this resolution
14:42mupuf: 4.7 sorry
14:42mupuf: I misrembered the score
14:42karolherbst: let me check what I get at full hd
14:47karolherbst: I get 363 points on 1920x1080
14:50mupuf: btw, ezbench seems to be bisecting piglit tests just fine now! Except for a few tests that are stupid and cannot be ran from the name found in the report
14:50imirkin: mupuf: why not just use the cmdline in the piglit results file?
14:50mupuf: it is now bisecting on HSW when tesselation shaders got enabled :p
14:51karolherbst: mupuf: :D
14:51mupuf: imirkin: well, that could be a way ... but that means parsing the output of all the tests myself
14:51mupuf: use the print_commands script
14:51imirkin: mupuf: json is easy to parse...
14:52imirkin: mupuf: anyways, hatever
14:52imirkin: just pointing out that there's a simple and reliable way.
14:52mupuf: right, but then I lose the visualization support :s
14:52moritz_s: mupuf: Hi, I have a GTX 970 and the fans are on full power all the time. The FAQ says I should talk to you if I want to work on fixing that
14:53mupuf: moritz_s: oh dear
14:53imirkin: moritz_s: are you using kernel 4.6-rc1?
14:53moritz_s: imirkin: 4.5.0
14:53mupuf: imirkin: why rc1?
14:53imirkin: i meant rc1+ :)
14:53mupuf: moritz_s: is this a regression? I doubt it is since we have not touched this code in a long time
14:53imirkin: mupuf: in case you don't remember... GM20x
14:54karolherbst: mupuf: well you did
14:54moritz_s: mupuf: I'm not sure, I just switched from the proprietary driver to nouveau a few days ago
14:54mupuf: moritz_s: ack
14:54mupuf: imirkin: sure, but I added the code in november lazst year
14:54mupuf: so, everything should be in place :D
14:54moritz_s: I can test an older kernel if that helps
14:54mupuf: moritz_s: which tz are you in?
14:54imirkin: moritz_s: well, if you want acceleration on there, you'll want to grab a 4.6-rc and install the nvidia-supplied firmware required to get it going
14:54moritz_s: mupuf: GMT+1
14:54mupuf: nope, no point
14:54imirkin: mupuf: can we write to the fan control stuff on those?
14:55mupuf: moritz_s: good, I am still at work
14:55mupuf: oh, right, GM2xx
14:55moritz_s: GM204 is my card I think
14:55karolherbst: moritz_s: if you want you can already give us your vbios /sys/kernel/debug/dri/0/vbios.rom
14:55mupuf: well, yeah, seems like we won't be able to do anything
14:55karolherbst: mupuf: really?
14:55imirkin: moritz_s: unfortunately you've bought a super-locked down GPU that we can't really access directly.
14:55karolherbst: we can't control the fans on gm20x yet?
14:56moritz_s: imirkin: damn :(
14:56imirkin: moritz_s: we basically have to wait until nvidia provides us with firmware
14:56mupuf: karolherbst: we will never be able to
14:56karolherbst: ohh shit
14:56karolherbst: is it done on the PMU=
14:56imirkin: moritz_s: they've done so for context switching, but no for PMU (which is the bit that controls things like fans among other things)
14:57imirkin: moritz_s: if you're looking for opensource-friendly hw, i think AMD is the only option that provides add-in GPU's
14:57imirkin: moritz_s: also nouveau is doing OK on the last-gen NVIDIA hardware, Kepler (GTX 6xx, 7xx)
14:57karolherbst: hey... keplers aren't as bad now anymore :D
14:58moritz_s: So my only choice is to use nvidia's binary driver at the moment?
14:58imirkin: [and obviously intel is great, but their hw doesn't really compete against the discrete gpu monsters...]
14:58karolherbst: moritz_s: well if the fan annoys you, yes
14:58moritz_s: karolherbst: It does :-)
14:58karolherbst: if you care about performance, most likely
14:58karolherbst: ohh wait
14:58karolherbst: on gm20x performance is also a yes for nvidia
14:59moritz_s: karolherbst: performance wouldn't be a big issue, but the fans are really annoying
14:59karolherbst: yeah, I believe this
15:01moritz_s: karolherbst: so should I still give you the vbios.rom?
15:02karolherbst: moritz_s: I don't think it matters now
15:02gnurou:feels guilty every time he sees GM20x mentioned here
15:02karolherbst: gnurou: :p
15:02karolherbst: gnurou: you should
15:03moritz_s: damn you nvidia!
15:03gnurou: not worthy, not worthy >_<
15:03mupuf: gnurou: ah ah
15:03mupuf: good reference :p
15:03mupuf: I watched Wayne's world again recently
15:03mupuf: as stupid as ever ;p
15:03gnurou: I wish I could transfer that guilt to the people who could give me the ack to release that fw
15:04karolherbst: ohh so it is done already?
15:04gnurou: well technically it is not a big challenge
15:04karolherbst: gnurou: mhh I think the firmware isn't as important now anyway. It would be good enough to have the PMU interface
15:04gnurou: if you have the right ACR and PMU firmware
15:04karolherbst: so that we can already begin porting nouveau code to the new interface
15:04gnurou: you boot them the same way (almost) and a new world opens
15:04mupuf: karolherbst: just having the fw would take care of the fan management
15:04karolherbst: mupuf: ohh :/
15:05karolherbst: yeah well
15:05karolherbst: but if it is easier to get the interface documentation or something like that, we can already adjust to this
15:05gnurou: karolherbst: yeah but if you want the PMU interface, you need the "real" ACR firmware to load the PMU
15:05karolherbst: and have less work later
15:05mupuf: but yes, PMU is going to be more problematic than PGRAPH
15:05karolherbst: gnurou: we would have to port our PMU code too
15:05karolherbst: gnurou: we don't want to have the nouveau and the nvidia interface at the same time
15:05gnurou: karolherbst: correct
15:06gnurou: well who doesn't like a new level of abstraction :)
15:07gnurou: step 1 would be to load the real ACR and PMU firmwares that RM uses
15:07gnurou: for which I sadly cannot help
15:09karolherbst: gnurou: yeah but I just meant, it would be great if we would knew what interface will be used, so that we just have to adjust the loader code and can already use the new PMU firmware with minor changes needed maybe
15:09gnurou: ah I see
15:09karolherbst: but if it isn't possible to get the interface before getting the firmware itself, then it is no problem
15:09karolherbst: it would just speed up the process a bit
15:10gnurou: this puts me in a very frustrating situation where I would *love* to help, but sadly am not allowed to :(
15:10gnurou: my deepest apologies
15:10mupuf: well, we already know a little what is the protocol
15:10karolherbst: yeah no problem, I just asked because I was thinking this might be easier
15:10mupuf: at least on the first PMU version
15:11RSpliet: I was going to say, quite a lot of hours were stuck into reverse engineering the PMU firmware and the SEQ scripts
15:11mupuf: at some point, we should add support for this in demmio
15:11gnurou: it would definitely be easier, and I hate that the firmware thing is only halfway solved at the moment
15:12karolherbst: well at least on kepler+maxwell1 we can be competetive ...
15:12RSpliet: karolherbst: don't forget Tesla gen 2
15:12gnurou: karolherbst: and pretty much so, I have switched my workstation to a Kepler + Nouveau, what a breeze :)
15:12karolherbst: gnurou: stock nouveau or my patches?
15:12gnurou: karolherbst: thanks a lot for all your work on that
15:12RSpliet: esp since NVIDIA calls that legacy nowadays, so two X.org versions from now people will default to nouveau
15:13gnurou: stock Nouveau for now
15:13karolherbst: well stock will be only a bit unstable and soemtimes don't even reclock the core
15:13karolherbst: depends on the vbios though
15:13karolherbst: RSpliet: right
15:13karolherbst: but nouveau shouldn't see its goal to be a better legacy driver ;)
15:14RSpliet: karolherbst: well, it's a good start ;-)
15:14RSpliet: it's a valid use-case
15:15karolherbst: yeah I know
15:16karolherbst: I didn't try to downtalk it in any way. It is just that I am sure that it is possible to be much better than this
15:16imirkin: gnurou: only feel guilty if it's your fault. fairly sure it's not :)
15:17mupuf: karolherbst: yeah, being competitve on older hw is a nice goal!
15:17RSpliet: if you look at the USPs for nouveau, it's basically KMS, native DX9 on Linux, good out-of-the-box experience so low maintainance, security through process separation and openness - whatever that may mean :-P
15:17mupuf: but the real one is to be competitive on the previous family
15:18karolherbst: which is maxwell now...
15:18karolherbst: so close...
15:18mupuf: not really :D
15:18karolherbst: yeah well
15:18mupuf: but yeah, maxwell is going to be a challenge for sure
15:18karolherbst: before the kepler code will be landed it most likely will
15:18karolherbst: maxwell1 is doing good though
15:18karolherbst: just the PMU part on those gm20x is a pain
15:18mupuf: like superman? :D
15:19mupuf: jokes aside, it should not be too much work yeah
15:19karolherbst: I think the gpc clock is the only thing
15:19karolherbst: the memory reclocking bits are really close enough to just work (tm)
15:19karolherbst: at least I didn't hear anybody complaining that the kepler bits didn't work
15:20karolherbst: so 100% success rate for now
15:20RSpliet: well, it's not a particularly widespread rumour that things might work
15:20RSpliet: and since it's mostly mid-end cards, memory is more resilient to configuration errors
15:21RSpliet: so it could definitely do with a thorough pass of verification before advertisement :-P
15:22RSpliet: there might be some small changes or new memcontroller bits that need fumbling to increase reliability or reduce power consumption
15:22RSpliet: ugh, I should stop being so distracted!
15:23karolherbst: yeah well, maxwell1 is pretty unimportant anyway...
15:28pmoreau: gnurou: You’ve been sending a few patches on properly detecting whether the card should be POSTed or not, for Fermi+. Is there anything related for Tesla?
15:32RSpliet: pmoreau: gnurou had a ping timeout
15:33pmoreau: RSpliet: Ah, k. Thanks for warning :-)
15:43pmoreau: gnurou: You’ve been sending a few patches on properly detecting whether the card should be POSTed or not, for Fermi+. Is there anything related for Tesla?
15:44gnurou: pmoreau: this particular register is from Fermi - I don't know if there is something similar for Tesla...
15:45gnurou: pmoreau: but I have checked and this register is not there before Fermi
15:45pmoreau: Maybe there was another register? Dunno
15:46Yuken: Nouveau seems to be crashing my system... and proprietary nVidia drivers don't work. http://pastebin.com/s3cz8nCt
15:46pmoreau: At least on my laptop (would need to check on my other Tesla cards), but NVIDIA posts both cards whereas Nouveau posts none of them.
15:47gnurou: pmoreau: feel free to fill an issue on my Github repo, if you want me to check
15:47imirkin: Yuken: you should use modesetting, not xf86-video-nouveau.
15:47gnurou: (and yes I am looking at these, promised)
15:47Yuken: This is a completely fresh Lubuntu 15.10 install, as well; nothing fiddled about with.
15:47pmoreau: gnurou: Ok, will do. :-)
15:47imirkin: Yuken: if you update your xf86-video-nouveau, it will properly reject loading on your GPU, and will fall back to xf86-video-modesetting
15:47Yuken: imirkin, how would I go about doing that? I've never dealt with graphics drivers on Linux, as all my Linux machines either worked perfectly out of the box with nouveau (a GT 330 or something) or were Intel-based.
15:48imirkin: Yuken: sorry, i don't do distro support
15:48imirkin: reach out to your distro's support channels for help on operating it
15:48imirkin: the thing is that GM107 is not supported by xf86-video-nouveau
15:49imirkin: you happen to have a version that has a half-broken attempt at using GLAMOR for it. it's... half-broken :)
15:49imirkin: modesetting has a proper integration with GLAMOR
15:49Yuken: Oh my. No wonder things are crashing :p
15:50imirkin: gtg... good luck!
16:19karolherbst: anybody any idea when pstates were added to nvidia gpus?
16:19karolherbst: I saw a nv36 with two pstates
16:20karolherbst: ohh also a nv31
16:24imirkin_: karolherbst: i think some GeForce 2 Go's had power features
16:24imirkin_: that'd be nv17 or whatever
16:24BootI386: Hello! I have a setup with two card, a GTX 960 (NV126) and a GTX 760 (NVE4). And here are the Xorg logs : http://termbin.com/l6h1
16:25karolherbst: imirkin_: okay, then I just enable the pstate handling for nv04 then to be sure. there is no real downside anyway
16:25karolherbst: cstates are a fermi thing anyway
16:25imirkin_: karolherbst: that said, nouveau only ever reports pstates for nv30+
16:25karolherbst: and dynamic voltage
16:25karolherbst: imirkin_: yeah, but the code is still in place even for nv04 gpus
16:25imirkin_: BootI386: pastebin dmesg too?
16:25mupuf: karolherbst: do not care about anything under c0 for what you are doing
16:25karolherbst: mupuf: I know, but I need to make my implementation fermi+
16:26karolherbst: mupuf: I don't need to update the voltage for older cards
16:26BootI386: I know nouveau DDK is outdated and that's why NV126 chipset is not supported, but it should at least try to probe the NVE4 too, instead of failing miserably, no?
16:26karolherbst: or react to the temperature
16:26imirkin_: BootI386: also, do you have an xorg.conf?
16:26imirkin_: BootI386: nouveau ddx is *not* outdated...
16:26imirkin_: i'm in the faction that strongly supports keeping per-hw ddx's and not using modesetting+glamor for everything
16:27imirkin_: it's a cute hack, but it does not perform, esp if you aren't using some hyper-modern desktop
16:27karolherbst: mupuf: but in my current implementation the therm daemon would revolt the gpu even if it's a nv04 and I don't want to do that ;)
16:27BootI386: I mean, *my* nouveau DDX, it's not the upstream :p
16:28imirkin_: you have 1.0.12, which is the latest
16:28imirkin_: anyways.... i think the issue here
16:28imirkin_: is that the primary gpu ends up being the GM206
16:28imirkin_: and nouveau doesn't support it
16:28imirkin_: (the ddx)
16:29imirkin_: now for some *wholly* unknown reason, modesetting doesn't pick it up either
16:29imirkin_: i suspect that an xorg.conf can fix it right up
16:29BootI386: Yes, they don't like him :/
16:29imirkin_: but really you should just stick to your GK104
16:30imirkin_: GM206 isn't going to be well-supported by nouveau for quite a while
16:30BootI386: Yes, but I'd like to not have to unplug the GM206 to get the GK104 working :p
16:31imirkin_: are all your screens connected to the GK104?
16:31BootI386: One on the GM206, another on the GK104
16:31imirkin_: i'd recommend plugging them both into the GK104 and then writing a simple xorg.conf which tells nouveau to load the GK104 and ignore the GM206 for now
16:33imirkin_: BootI386: just a section that has Driver "nouveau" BusID "PCI:2:0:0" or whatever
16:33BootI386: Yes, thank you :)
16:33imirkin_: if performance is a concern for you, you could also try reclocking
16:34imirkin_: it might Just Work, or you might need some of karolherbst's patches
16:35karolherbst: well for stability he would like to have those anyway
16:35karolherbst: as long as he recocks
16:35imirkin_: but for laziness he might not :)
16:35karolherbst: if he doesn't reclock it should be fine
16:35BootI386: Yeah, laziness :)
16:37karolherbst: well with two monitors reclocking might help
16:37karolherbst: depends on the resolutions though
16:41BootI386: But there should be a bug in Xorg that make it forget to probe the 2nd card, right?
16:41karolherbst: BootI386: you can always specify the dummy driver for this
16:41imirkin_: BootI386: the xorg probing rules are ... confusing.
16:42imirkin_: and i have no idea what they are, and no inclination to investigate them.
16:42karolherbst: BootI386: this is my dev xorg.conf for optimus systems: https://gist.github.com/karolherbst/1f1bdd1a3822df74097f
16:42karolherbst: BootI386: and no driver is loaded for my nvidia gpu running nouveau
16:42imirkin_: if you'd like to pursue it with the xorg folk, feel free - #xorg-devel / #xorg-users
16:43karolherbst: imirkin_: I am sure that using the dummy driver it won't be "probed" anymore
16:43karolherbst: but I have no idea what happens when the nouveau ddx gets loaded
16:43BootI386: karolherbst: Oh, that's cool, yes, thank you :)
16:43karolherbst: BootI386: maybe you have to install the dummy ddx
16:44BootI386: It's installed :)
16:44karolherbst: then set the kepler to nouveau and the maxwell to dummy
16:44karolherbst: and hope that it just works this way
17:31Misanthropos: karolherbst, your latest patch works! have been playing a while now with pstate 0f and no messages and no freezes! good job!
17:35karolherbst: Misanthropos: awesome
17:44BootI386: So I tried multiple things, and the only way to get the GK104 work was to use the dummy ddx on the GM206... Even with two explicit Device sections, both with nouveau ddx, it keeps ignoring the GK104...
17:45imirkin_: BootI386: that's expected
17:45imirkin_: BootI386: have *one* device section with just the GK104
17:56BootI386: I see... There can be only one device in a Screen, so the others are attached as GPUDevice. And if the primary Device fails, it just ignores the subsequent Devices (as they are attached as GPUDevices)...
18:21karolherbst: okay. I think I am done with the little refactoring today :) now I only check on fermi+ except tegras if we have to update the cstates and also update the voltage :)
18:22karolherbst: gnurou: when do you plan to let nouveau update the voltage on tegras?
18:22karolherbst: gnurou: I have all the needed bits done for fermi and newer, but I saw that on tegra the temperature is always -10°C
18:27mupuf: imirkin_: the csv output of the piglit summary gives me the actual test name
18:27mupuf: it is only the console output that does not
18:27imirkin_: you mean the command?
18:27imirkin_: there can be arguments, etc.
18:28imirkin_: you need the full cmdline
18:28mupuf: nope, you get the cmdline with piglit-print-commands.py
18:28mupuf: I would rather use the piglit framework to run tests
18:28mupuf: and if I run piglit summary csv /path/to/report, I get : spec@arb_program_interface_query@arb_program_interface_query-getprogramresourceindex,<framework.results.TimeAttribute object at 0x7fa65bda3ac8>,1,fail
18:29mupuf: so, the name is until the '-'
18:30mupuf: actually, no
18:30karolherbst: has anybody any explenation why poking 0x0 into PIBUS.MMIO_HUB[0x1]+0x234 enables SPEEDO readout in PFUSE, but nvidia doesn't touch PIBUS.MMIO_HUB+0x234 at all=
18:30imirkin_: mupuf: right... so not at all what you need
18:30mupuf: the csv output does not show the subtest name
18:30imirkin_: mupuf: you need the actual command
18:30imirkin_: mupuf: e.g. bin/foo-bar
18:30mupuf: imirkin_: I do not need the command line
18:31imirkin_: yes you do.
18:31imirkin_: if you want it to always work, you do.
18:31imirkin_: if you want it to sometimes work, you don't
18:31mupuf: I can run any test I want through ./piglit run -t 'test_name' test/gpu.py report
18:31mupuf: or give it a file containing the list of tests, which I do
18:31imirkin_: mmmmmmmm questionable.
18:31imirkin_: that's a regex
18:32imirkin_: what if the test you want to run is 'texsubimage'
18:32imirkin_: that'll run like 75 tests
18:32mupuf: I am fine with over-running a little
18:33mupuf: and I can add $ at the end to be sure only texsubimage is run
18:33mupuf: that is really no problem
18:33mupuf: I already do this for ezbench
18:33imirkin_: ah ok
18:33imirkin_: if you run it via the piglit runner then i guess you're fine
18:33imirkin_: i assumed you wanted to run stuff directly.
18:33imirkin_: to avoid the 75-minute startup time of the piglit runner
18:33mupuf: but I need the actual test name
18:33imirkin_: while it parses EVERY shader_test
18:34mupuf: yeah, it is a bit bad, but it is nothing compared to the compilation of mesa
18:35mupuf: imirkin_: I guess we want to bisect at the subtest level, so I need to write a patch for piglit summary
18:35imirkin_: you can't run it one subtest at a time anyways
18:36mupuf: no, but I still want to bisect each of them
18:36mupuf: if one gets fixed, I want to know
18:36imirkin_: i wouldn't personally worry about it
18:36mupuf: the image size test has a shit ton of subtests
18:36imirkin_: but your call
18:36mupuf: same for program interface query
18:37mupuf: I went a bit overboard, but it is really convenient
18:37karolherbst: mupuf, mwk: any objections? or should I wait a little before pushing this? https://github.com/karolherbst/envytools/commit/c344e537243368fa0706536e609cd29aadab6d9e
18:37mupuf: crappy name, but that's nvidia's
18:37mupuf: so, let's keep it like that :D
18:37karolherbst: gnurou: by the way, what does speedo means? :D
18:38karolherbst: mupuf: it has a really akward sound to it
18:38Yoshimo: wonder when we will see pascal firmware ;)
18:41karolherbst: mupuf: I think I saw the fermi PFUSE reg also on other chipsets, let me check
18:41karolherbst: but it is funny that only kepler needs those stupid reg pokes to read it out
18:42karolherbst: Yoshimo: next year most likely :p
18:43Yoshimo: you don't think they are faster this time?
18:45karolherbst: well we still need stuff for maxwell :D
18:46Yoshimo: yes yes, but i have bigger problems than reclocking that card
18:47Yoshimo: if they prepare a new driver for pascal, maybe that also means a driver that doesn't need to embed the firmware files
18:47karolherbst: where should the firmware be otherwise?
18:48Yoshimo: wasn't the problem that the binary driver needs a stable interface to the firmware files that doesn't change before they can relase it?
18:48karolherbst: well you still want to be able to update those files
18:50Yoshimo: i agree with you though, playing with higher clocks on my 980 would be cool, the sddm log btw is not much use for fixing the missing login screen from yesterday
18:51karolherbst: it would be still possible to reclock without the firmware, but this isn't easy and quite a lot could go wrong
18:51karolherbst: the problem is also just the memory
18:51karolherbst: Yoshimo: well we found the issue by the way
18:51Yoshimo: i doubt it
18:51karolherbst: Yoshimo: the kernel was started with nomodeset
18:52Yoshimo: no it wasn't that was just a temporary test i should run for someone else that tried to help me
18:52Yoshimo: didn't change a thing
18:52karolherbst: mhhh okay
18:52karolherbst: then do you have a current X log without booting with nomodeset?
18:55Yoshimo: so the x log should have no match for nomodset, would be enough?
18:56Yoshimo: https://pastee.org/9sz23 , does it qualify?
18:57Yoshimo: sddm looks like this https://pastee.org/744pn
18:58karolherbst: much better
18:58karolherbst: the error is different now :)
18:58karolherbst: Unknown chipset: NV124
18:58karolherbst: nouveau ddx doesn't support gm20x
18:59karolherbst: (axnum >= dev->valuator->numAxes)'
18:59Yoshimo: why is it unknown now? i ran nouveau on that card before and i have the firmware files
18:59karolherbst: Yoshimo: unplug your gamepad
18:59karolherbst: and try again
19:00karolherbst: Yoshimo: because the modesetting DDX is taking care of those cards
19:00karolherbst: but the X server crashes due to your gamepad
19:00Yoshimo: mouse, headset, keyboard, and the avm wireless device, there are no gamepads plugged in, i do not have a gamepad at all
19:00karolherbst: see line 548 and later
19:00karolherbst: in the X log
19:01karolherbst: (II) evdev: Turtle Beach Turtle Beach PX3 (PS3): Faking axis ABS_X.
19:01Yoshimo: that is the headset
19:01karolherbst: then disconnect your headset
19:02Yoshimo: ok, weird, i have use that one before. I will try it in a minute
19:08karolherbst: wine 1.9.8 has finally TYPELESS texture support
19:08karolherbst: now d3d10 games can be played :)
19:13mupuf: karolherbst: I wonder when nine will support d3d10 again
19:13imirkin_: you mean when d3d1x will be resurrected?
19:13mupuf: right :
19:13imirkin_: d3d10 is a lot more similar to d3d11 than d3d9
19:13karolherbst: mupuf: never :D
19:13karolherbst: mupuf: I asked them and they said they don't plan to support it
19:14karolherbst: ohh right
19:14mupuf: karolherbst: not enough games using it? or is it easier to map to GL?
19:14karolherbst: mupuf: no plans
19:14mupuf: imirkin_: the csv output is also bad, I guess I will go with your original suggestion and just store the json file
19:14mupuf: parsing it in python should not be an issue
19:16mupuf: and that means less storage capacity needed, since I also wanted to store the reports anyway, at least for nouveau
19:16imirkin_: there's a json module.
19:16imirkin_: also the piglit summary logic is written in python
19:16imirkin_: so you can copy :)
19:16mupuf: yep, just need to check the license :p
19:16imirkin_: bsd, i think
19:18mupuf: I could just depend on piglit, but I decided against it since: 1. there may be testing suites not supported by piglit, 2. I did not need anything else but the full name and the status
19:18mupuf: but hey, now I also need the subtest name
19:18imirkin_: you could also add a custom summary moduel to piglit which does the thing you want.
19:19mupuf: but since I will want to store the piglit json file, then let's just do that
19:20mupuf: and if there is another testrunner I need to support, I will write a converter to get the wanted data
19:21mupuf: (in the same format as piglit)
19:27Yoshimo: all headset related entries are gone now, i still have [ 37.727] (EE) Unknown chipset: NV124 although i installed the kernel module from your mawell branch karol and i have a mesa build from last week active from thirdparty repo
19:27imirkin_: Yoshimo: that's expected.
19:27imirkin_: Yoshimo: pastebin xorg log
19:28Yoshimo: so unknown chipset is no problem ? i thought that is the kind of error that was fixed with your module and the new firmware from nvidia
19:28karolherbst: Yoshimo: does X start now?
19:29karolherbst: if so, just run glxinfo and see if nouveau is used
19:29Yoshimo: well i get the same greyish screen instead of the loginwindow just as before, but i do not count that as "x is running"
19:29karolherbst: ohh mhh
19:29karolherbst: yeah X log then
19:30karolherbst: mupuf: mind if I push the speedo reg commit? The values have the same range on fermi and kepler and it seems like the fermi reg really only exists on fermi
19:31mupuf: go for it
19:32karolherbst: low: 0x574 high: 0x756
19:32karolherbst: allthough the fermi ones seems a bit lower in avarage :)
19:39karolherbst: right, already pushed
19:40karolherbst: ups, that was my accidence
19:41karolherbst: thought I was viewing the branches of my repository...
19:43karolherbst: "modeset(0): glamor initialization failed"
19:43karolherbst: Yoshimo: can you give me your full dmesg output then?
19:43imirkin_: Yoshimo: seems working fine... what's the issue?
19:43karolherbst: "(EE) AIGLX error: dlopen of /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so failed (/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so: undefined symbol: _glapi_tls_Dispatch)"
19:43imirkin_: doesn't matter
19:43imirkin_: he's on kernel 4.4
19:44karolherbst: (EE) GLX: could not load software renderer
19:44imirkin_: no accel for GM20x
19:44imirkin_: glamor doesn't work with swrast
19:44imirkin_: (coz why would it...)
19:44karolherbst: yeah but it also can't load the nouveau one
19:44karolherbst: GLX: no usable GL providers found for screen 0
19:44Yoshimo: imirkin_: i don't the the graphical login screen from my kubuntu and i wonder where in the sequence the thing is messed up
19:44imirkin_: karolherbst: because... no accel.
19:44imirkin_: Yoshimo: what do you see? the xorg log you provided appears to be perfectly happy
19:45karolherbst: mhh right, so it should fallback to some unaccelerated modesetting stuff
19:45imirkin_: karolherbst: cpu-accelerated.
19:45Yoshimo: i see a light grey screen that doesn't change, and if i login on the terminal and use startx plasma says the driver isn't installed corrctly
19:46imirkin_: Yoshimo: that's because your environment probably REQUIRES glx or GL acceleration or something
19:46imirkin_: Yoshimo: since you don't have that, it fails?
19:46karolherbst: kwin either needs GLX, EGL or Xrender
19:46imirkin_: it should have xrender
19:46Yoshimo: i have used the same card with the same repositories before
19:46imirkin_: Yoshimo: but probably with nvidia blob driver?
19:46Yoshimo: hell i even ran piglit tests on that 980 with nouveau
19:46imirkin_: Yoshimo: certainly not on that setup
19:46karolherbst: Yoshimo: try it with a clean user
19:47imirkin_: Yoshimo: you're on kernel 4.4. no accel for you.
19:47Yoshimo: imirkin_: something broke and i need help to figure out what exactly
19:47imirkin_: Yoshimo: there's no way it could have ever worked with nouveau and accel on that kernel.
19:48imirkin_: GM20x accel is only supported starting with kernel 4.6-rc1
19:48karolherbst: imirkin_: ohh he used my branch on 4.4 most likely
19:48Yoshimo: https://github.com/karolherbst/nouveau/tree/maxwell_reclocking supports loading the maxwell firmware i downloaded and installed
19:49Yoshimo: yes i do karol, as we tried to figure out reclocking and realised i miss additional firmware ;)
19:49imirkin_: "Linux Nebulos 4.4.3-040403-generic"
19:49karolherbst: imirkin_: doesn't matter
19:49karolherbst: my branches are always backported from current master
19:49imirkin_: that sounds like not the name a normal person adds on there
19:49karolherbst: or usually they are
19:49karolherbst: out of tree nouveau
19:50karolherbst: Yoshimo: you should try to startx with a new created user (+ video group)
19:50karolherbst: Yoshimo: and see if you can start a plasmashell from there
19:57imirkin_: hakzsam: i see you pushed a commit to call the sured memory area img on gm107 - i don't think that's right. should just be g. there's no special "image" concept there... you just feed it an address, right? or do you feed it an image descriptor?
19:57imirkin_: either way i think it should be g
19:58imirkin_: img makes sense on GF100 where the image space is a dedicated space
20:05karolherbst: saints row 3 doesn't use compute shaders here :/
20:05karolherbst: even on nvidia
20:06imirkin_: what about 4?
20:07karolherbst: nouveua runs 85% slower on saints row 3
20:07karolherbst: so compute shaders are my smallest concern here
20:08karolherbst: but it uses GL_ARB_buffer_storage
20:08karolherbst: mhh let me try something
20:19karolherbst: uhh "total instructions in shared programs : 84230 -> 80905 (-3.95%)" with my patches
20:20karolherbst: and -0.54% gpc count
20:20karolherbst: that's why it was slightly faster
20:23karolherbst: -1.92% alone through the postRADCE pass
20:25karolherbst: and the other part through running passes in a loop
20:47karolherbst: let's take a look what the longest run shader is doing for crazy things :)
20:52karolherbst: what a crapy shader
20:52karolherbst: fragmant shader: PixelOutput = vec4( 0.0f, 0.0f, 0.0f, 0.0f );
20:53karolherbst: that's all
20:55karolherbst: ohh it uses glBindProgramPipeline
20:56karolherbst: but still
20:58karolherbst: I used scripts/profileshader.py and it gave me the thing which is executed the longest
20:58karolherbst: but mhh
20:58karolherbst: it doesn't look that bad
20:59karolherbst: just 2573535 draws
21:05karolherbst: imirkin_: is there something better than doing this? https://gist.github.com/karolherbst/b171212ba972980c0d1c1605edd6f581
21:05imirkin_: karolherbst: doubtful... i don't think registers are initialized
21:06karolherbst: .. well it should be easy to see what nvidia does :D
21:07karolherbst: vertex shader: https://gist.github.com/karolherbst/511b2104d3071fa44ccdb5e2b67e660a
21:07imirkin_: seems reasonable
21:07karolherbst: and apitrace says that nouveau spends most time in those two
21:08imirkin_: perhaps RA could be different to allow more dual-issue
21:08karolherbst: I have a patch for that and it didn't make much of a difference
21:10karolherbst: I am sure nvidia does something super smart with those both
22:33karolherbst: mupuf: ohh by the way. your pwm code rounds down...
22:36mupuf: did I write code to support voltage scaling on maxwell? :o
22:36mupuf: I have no recollection of this :D
22:36mupuf: I remember for the fan though
22:36mupuf: if this is what you mean ... then ... meh?
22:37karolherbst: mhh, yeah you did this
22:37mupuf: ok, well, I am getting old
22:37karolherbst: https://github.com/karolherbst/nouveau/commit/d38609fe77f897bd8485d37bd189d30b9e2ef69e ;)
22:38karolherbst: the issue is just this line: "duty = (uv - bios->base) * div / bios->pwm_range;"
22:38karolherbst: we should have an explicit rounding here
22:38karolherbst: and it should be rounded up
22:39mupuf: oh right, this crystal frequency
22:39mupuf: it bothered me a lot
22:39karolherbst: anyway I just noticed when I run my tool on nouveau
22:39karolherbst: that the set voltage is always lower
22:39karolherbst: which shouldn't be
22:39mupuf: a ceil would be good, indeed
22:40karolherbst: by the way
22:40karolherbst: I am really happy that the voltage map table ver 0x10 is a subset of the 0x20 one
22:41karolherbst: how do we want to handle those coefficients in nvbios?
22:41karolherbst: we could print a nice formular with the speedo and temp as variables
22:46mupuf: sounds good
22:46karolherbst: do we want to handle the speedo like the strap_peek?
22:48mupuf: what would be the point?
22:48mupuf: just write $speedo in the formula
22:51karolherbst: mupuf: to have it
22:51mupuf: so, you provide a value ... that is printed back as you gave it :D
22:52mupuf: that is quite pointless
22:52mupuf: unless you intend to also have the temperature
22:52mupuf: in which case, you may start using it for a tool to check ... but you already have a good tool for this
22:52mupuf: nvbios is for devs :_
22:53karolherbst: mupuf: well there is no ceil in the linux kernel I guess :D
22:54karolherbst: there is roundup though
22:54karolherbst: but somewhat I had troubles with it
22:54karolherbst: let me try again
22:56karolherbst: yeah, this works
22:59karolherbst: mupuf: https://github.com/karolherbst/nouveau/commit/4ac9ff0bef5b2c58e4586a3f261620ad816c5be1
23:02karolherbst: mupuf: by the way, the series is now 39 patches in total ... I am sorry
23:13karolherbst: mupuf: like this? "-- ID = 12, mode: 0 link: 30, voltage_min = 800000, voltage_max = 837500 [µV], volt = 9363180 / 10 + (289 * S) / 10 + (-6611 * S²) / 100000"
23:15mupuf: where is t?
23:16mupuf: I think you should write the formula with C1/2/3 and then just dump the values
23:16karolherbst: mode 0 has no T
23:17karolherbst: ohh no, with the values inside the formular it looks really good, you will see
23:19karolherbst: mhh for mode 2 it will be quite long though
23:20mupuf: ok, but what about the verbose mode? how do you map the constant with the values in the formula?
23:20mupuf: which ones are constants and which ones are per-entry?
23:20mupuf: it does not really matter in the end
23:20mupuf: but just food for thoughts :p
23:21mupuf: ok, so, for ezbench/piglit, I ended up writing a small python script, inline of the piglit test profile and it does want I want
23:21mupuf: let's test auto bisecting
23:22karolherbst: mupuf: the contents are just the last bytes, always 32bit
23:22karolherbst: but yeah mhh
23:22karolherbst: should be obvious though
23:23mupuf: as long as it is clear in the code, I am ok
23:23karolherbst: ohh it will be
23:24karolherbst: looks nice somewhat :D
23:26karolherbst: mupuf: should I remove the parts of the formular where the constant is 0?
23:29mupuf: no, KISS
23:30karolherbst: it will be simple
23:30karolherbst: and easier to read
23:32mupuf: you forgot the second S, stupid LD
23:33karolherbst: mupuf: cleaned up version: https://gist.githubusercontent.com/karolherbst/5190022731408a6daa9163b7f53ae7ad/raw/6cd6a0574a433ea9a53a896ff2bfcb1c70a3d4c7/gistfile2.txt
23:37mupuf: ok, now I have a problem when I do not make a partial run of piglit, but rather a full run
23:37mupuf: I just have no way to distinguish between a full run or a partial run, from the results
23:37mupuf: so, I do not know if I got all the wanted results or not
23:38mupuf: I guess I could add one last line at the end if piglit ran successfully, if not, It will be considered incomplete
23:52karolherbst: mupuf: https://github.com/karolherbst/envytools/commit/2a95e24b9a6a275d40725e219f95af3829b64ce7 :)
23:54karolherbst: though I could remove those mode/link prints for 0x10
23:54mupuf: this is absolutely bonkers :D
23:56karolherbst: :D why?
23:57karolherbst: the code looks so clean now
23:57Pie_Mage: the code
23:57mupuf: oh, I am talking about nvidia here :D
23:57Pie_Mage: THE COOOOOOODE!
23:57karolherbst: ahhh :D
23:57karolherbst: mupuf: I thought you mean my commit
23:58karolherbst: updated: https://github.com/karolherbst/envytools/commit/a552e7af08f8c95b5cd1b35b86e0d7f3923b6d8f
23:59karolherbst: here the new outputs: https://gist.github.com/karolherbst/285715f19b222e4401c9bfaf61c774f8
23:59karolherbst: I think it is good this way