00:35 karlmag: gnurou: awwwww... and \o/ and.... still not holding breath too hard ;-)
00:39 karlmag: But cool that it seems to have worked out, whatever the actual reason was. :)
00:41 gnurou: karlmag: yeah, sorry that gm206 is not released yet, but it should be a matter of days
00:42 karlmag: gnurou: no worries on my part. :-)
00:43 gnurou: karlmag: I thought your card was gm206?
00:44 karlmag: gnurou: I do have a gm206 yes.
00:44 karlmag: It's currently not even in a computer.
00:45 gnurou: ah, so I guess it can wait a bit and you will not spend your evening compiling Nouveau and hacking Mesa then ;)
00:46 karlmag: I'm not really a coder, but I do intend to (try to) test stuff.
00:46 gnurou: for those of you who feel like playing: https://lists.freedesktop.org/archives/dri-devel/2016-February/100773.html
00:47 karlmag: Not quite set up for it properly yet, unfortunately, but even now I can make it happen if I'm so inclined.
00:53 karlmag: gnurou: in any case; thanks. :-)
00:54 gnurou: karlmag: there is still a lot to do, so please bear with us :)
00:55 karlmag: gnurou: Oh, I do believe you on that. But this is a fairly big step forward.
01:07 mupuf: gnurou: YEAH!
01:07 mupuf: I do not have a GM204, just a 206, so I will wait for it :)
01:07 mupuf: I guess the GM206 will replace the other maxwell I currently have in the reverse engineering machine :)
01:10 hakzsam: mupuf, hey please keep the gm107 :D
01:10 mupuf: hakzsam: no point in discussing this until the fw for the GM206 are released ;)
01:11 hakzsam: mupuf, :)
01:11 karlmag: keep both in? :P (I guess that complicates things a bit)
01:12 mupuf: Devinit scripts are signed and executed on the PMU so that these scripts can configure protected registers like thermal shutdown parameters. --> Oh, well, fair enough :p
01:13 mupuf: gnurou: thanks for the short documentation
01:13 mupuf: karlmag: well, people also work on the kepler that is in
01:13 karlmag: three cards?
01:13 karlmag:lols
01:14 hakzsam: only two
01:15 karlmag: I mean, just add cards, not taking any out ;-)
01:41 pmoreau: gnurou: Damn! You were so happy you sent the email twice? :-D (Well, received it 4 times: 2x (Nouveau + DRI-devel))
01:42 gnurou: pmoreau: strange, I only received one copy
01:42 sooda: i saw it just once in nouveau. gnurou, congrats for this milestone! :)
01:42 pmoreau: Oh, maybe my client messing things then
01:43 pmoreau: gnurou: But congrats for getting GM200 and GM204 out! :-)
01:44 pmoreau: I'll try to play with my GM206 once the firmware is released.
01:58 karolherbst: mupuf: ohh I was sure I removed the _IDLE things
01:58 karolherbst: mupuf: https://github.com/karolherbst/nouveau/commit/899935d2c3d34184d1738014159b196855a80bf7 :/
01:59 karolherbst: guess I changed that after sending to the ML
02:00 mupuf: karolherbst: that's what review is for
02:01 karolherbst: :)
02:05 karolherbst: mupuf: and now you know why I choose to do a 0-255 range :D
02:06 mupuf: well, I do not really like the loss in precision
02:06 karolherbst: yeah I know
02:06 karolherbst: I was thinking of doing a 0-65535 range
02:06 karolherbst: this should be equally easy
02:07 mupuf: err, no, I meant in the division
02:07 karolherbst: but then adding a new load counter would be messy
02:07 karolherbst: ahhh okay
02:07 mupuf: 255 is definitely enough :D
02:07 karolherbst: k
02:07 karolherbst: mhhh
02:07 karolherbst: I don't think this is a problem
02:07 mupuf: .5% accuracy is fine
02:07 karolherbst: the counter is usually really high
02:09 karolherbst: I think I decided to divider here so that I don't have to deal with overflows at all, let me think about it a bit
02:11 karolherbst: ohhh I know
02:11 mupuf: you avoid a mul
02:11 karolherbst: I avoid increasiung the values of the counters
02:11 mupuf: because there are no mul64 in asm
02:12 karolherbst: instead I just reduce the ticks value
02:12 mupuf: but I wrote a function for it
02:12 karolherbst: yeah I know
02:12 karolherbst: I doubt it matters in the end though, because the values get reduced to 0xff precision anyway
02:12 mupuf: instead of doing : counter * 255 / cycles
02:13 mupuf: you do counters / (cycles / 255)
02:14 karolherbst: yeah and cycles is around 0x2000000 big
02:14 karolherbst: bigger actually
02:15 mupuf: yep
02:15 mupuf: hence the warning in my polling function
02:21 mupuf: pmoreau: seems like we are all cheap and only bought the GM206 :p
02:22 karlmag: cheap is relative I guess.. :-P
02:23 pmoreau: mupuf: It seems so. :-D I'll most likely buy a high end Pascal when they come out, and maybe a Titan X? But I might wait for another year and go for the Titan P or whatever it'll be called.
02:24 karolherbst: why the titan? for DP?
02:24 mupuf: :o What for?
02:24 Tom^: to compensate for the performance loss opensource gives.
02:25 Tom^: i thought i told you guys this before :P
02:25 mupuf: Tom^: ah ah
02:25 karolherbst: I would go for the Titan Z, because with that you will have more fun on nouveau *cough*
02:25 karolherbst: ohh the Titan X sucks?
02:26 karolherbst: I would have hoped at least the titan X has usable double precision perf
02:26 karolherbst: but it hasn't
02:26 karolherbst: ...
02:26 Tom^: also im sort of reading all the backlogs everyday now karolherbst hoping for a point of when volting can be tested xD
02:26 karolherbst: yeah ask me in a month
02:26 karolherbst: :D
02:26 karolherbst: I have to RE 6 fields in 4 different modes
02:26 karolherbst: and they can mean whatever
02:26 Tom^: ouch i see.
02:27 mupuf: yeah, I banged my head on them already for an entire day
02:27 karolherbst: though I think I am finished with one field for two modes :D
02:28 pmoreau: True, the Titan X isn't that much better than a 980 Ti… Maybe the extra memory might be interesting for some research projects, we'll see
02:28 karolherbst: Titan Z!
02:28 karolherbst: :p
02:28 karolherbst: the extra fun will be worth it
02:29 pmoreau: Meh! Don't want to buy a powerplant to be able to use that thing! :-p
02:29 karolherbst: yeah but then you kind of RE sli :p
02:29 pmoreau: I'm sure I can do some SLI stuff for way cheaper!
02:30 karolherbst: true
02:30 pmoreau: Like… using my laptop which I already have? :-)
02:30 karolherbst: 690
02:30 karolherbst: :D
02:30 karolherbst: yeah, but thats some funny config of sli...
02:30 karolherbst: I would say it is different
02:30 karolherbst: maybe not
02:30 karolherbst: who knows
02:30 karolherbst: and a lot of stuff could be broken because I am sure nearly nobody used it as sli
02:32 pmoreau: I should have a Reator computer soon (hopefully; I went to the shop last week and waiting to hear back) and it should have SLI-2 support, just in case it's needed.
02:32 karolherbst: nice
02:33 mupuf: pmoreau: ah ah, why do you want to put so much money on this, what is your agenda mister? :D
02:34 pmoreau: I haven't bought anything yet and can still retract when I see the price
02:34 Tom^: tbh you would probably enjoy dual xeons more :p
02:35 pmoreau: If I was doing CPU ray tracing, most likely, but, that's not the case
02:36 Tom^: you could compile the kernel while rendering 4k resolutions at the same time you code on nouveau.
02:36 Tom^: :<
02:36 pmoreau: :-D
02:37 karolherbst: well with a proper kernel that's also possible with an i7
02:37 RSpliet:hands gnurou a round of applause
02:37 Tom^: not if you want to compile it under 12 minutes.
02:37 RSpliet: good stuff!
02:37 karlmag: sli? I might not have too much insight in what that entails, but my impression is that it's usefulness is fairly limited.
02:38 karolherbst: Tom^: I need maybe 5 minutes for my kernel
02:39 Tom^: thats with cheats, aka tailored kernel config.
02:39 karolherbst: :p
02:40 karolherbst: if you have a dual xeon setup, you want a tailored kernel anyway
02:41 karolherbst: ohh signed firmware :O
02:48 karolherbst: mupuf: I think you somehow looked also at old version of my stuff
02:48 karolherbst: mupuf: https://lists.freedesktop.org/archives/nouveau/2016-February/023988.html
02:49 karolherbst: _IDLE stuff already removed
02:49 mupuf: karolherbst: I looked at the patches you sent on the ML
02:50 mupuf: hmm
02:50 karolherbst: yeah and I send a new series this month
02:50 mupuf: Sorry, I may have :s
02:50 karolherbst: but you replied to two of the new ones
02:50 karolherbst: and two of the old ones
02:50 mupuf: oh well...
02:50 karolherbst: ohh wait
02:50 karolherbst: no
02:51 karolherbst: you only replied to the old ones :D
02:51 mupuf: crap, made changes to perf.fuc since?
02:51 karolherbst: mhhh your comments still made sense
02:51 karolherbst: I didn't change anything big though
02:51 mupuf: very well
02:51 mupuf: sorry :s
02:52 karolherbst: I will send a new series out anyway after I fixed the stuff
02:52 mupuf: good :)
02:52 karlmag: hmm... test compile of standard 4.5-rc4, standard config (whatever that actually is).. on an i7; make -j 13 -> 1m32
02:53 karolherbst: karlmag: yeah and you left out a bunch of stuff :p
02:54 karolherbst: or does make also compile the modules?
02:54 karlmag: looks like it.. :-P I *though* it would do the modules too, but not sure
02:56 Tom^: yea you are not gonna get under ~12 minutes with the default config im quite sure :P
02:57 Tom^: to many modules and drivers for that ;)
02:57 karlmag: well.. a "make modules" now took 8 seconds
02:58 karlmag: so I guess they where already built
02:59 karlmag: or... I did something wrong somewhere :-P
03:02 karlmag: hmm... "Execute "make" or "make all" to build all targets marked with [*]" and vmlinux, modules and bzImage are all marked, so I guess it built modules too. :-)
03:03 karolherbst: make mrproper to clean it all up
03:04 karolherbst: :p
03:04 karolherbst: and then mhhh make archconfig? no idea how the argument for the arch defaults were
03:04 karlmag: this was a fresh download and unpack of 4.5.rc4
03:04 karolherbst: mhh k
03:05 karlmag: only thing I did was unpack, make menuconfig (and exit without doing anything), then time make -j 13
03:06 karlmag: not sure you can have a much cleaner start than that :)
03:06 Tom^: arent you required to run make config , too tho? *shrug*.
03:07 karlmag: I thought make menuconfig should do that, but sure, let me do that to be sure.
03:07 Tom^: something is fishy, it shouldnt be that fast =D
03:07 karolherbst: make defconfig
03:08 karlmag: Tom^: it is a 3.3GHz i7 (6core+HT) with 64GB ram, so it should be a bit fast.
03:09 karolherbst: and I have 3.4GHz (turbo) with 4core +HT and enough ram :p
03:09 karlmag: but sure I could have missed something
03:09 karolherbst: you have a ssd?
03:10 karlmag: yes, but I was actually doing it on a spinning disk
03:10 karolherbst: k
03:10 karolherbst: mhh seems like the defconfig hasn't much really
03:11 karlmag: hmm.. make config asks all the questions :-P
03:11 karlmag: quicker with menuconfig.. just start and exit and there you go; defaults
03:11 karolherbst: karlmag: make defconfig
03:11 karlmag: or make defconfig
03:12 karolherbst: ohh yeah, that is fast
03:12 karolherbst: I was at 2m52s though
03:13 karolherbst: ohh you had all the files chached in ram ... :p
03:13 karolherbst: cheating
03:14 karlmag: uhm... well, if that happens automatically, sure.. I didn't do anything to make that happen.
03:14 karlmag: I could have input and output on ramdisk, perhaps.. :-D
03:15 karlmag: 1m31.454s
03:15 karolherbst: well you also have higher clocks and two more cores than me
03:15 karolherbst: and most likely more cache too
03:15 mupuf: karolherbst: you have no SSD?
03:15 karolherbst: no
03:15 karolherbst: I have two at home, both bricked
03:15 karlmag: work machine is still at it (i5, 3.1GHz 4core, no HT)
03:15 mupuf: you have a beast of a GPU but no SSDs? You are weird :D
03:16 karolherbst: 16GB ram
03:16 karolherbst: file cache is like 11GB
03:16 karolherbst: sooo :p
03:16 karlmag: 3m25.015s
03:16 karolherbst: but I actually have 2 mSata ports :D
03:16 karlmag: not too shabby
03:16 karolherbst: mhh ssd raid, sounds fun
03:17 karlmag: heh
03:17 karolherbst: karlmag: how did you get 3m now? :D
03:17 karolherbst: ahh other machine
03:17 mwk: mupuf: I have craploads of GPUs and no SSDs :p
03:17 karlmag: a friend of mine actually had (has?) a mobo with 2msata ports and had managed to set it up with raid0.. then the mobo died :-P
03:18 karolherbst: ...
03:18 mwk: ... matter of fact, I have 1 HDD for 30 machines
03:18 karlmag: karolherbst: that was the i5 3.1GHz, 4core (make -j 5)
03:18 karolherbst: I don't trust these SSDs
03:18 karlmag: work machine
03:18 mupuf: mwk: well, the moment you try one, you will be hooked
03:18 karolherbst: and if they die, you are srewed anyway
03:18 mupuf: now, I think SSDs are still slow :s
03:18 mwk: mupuf: oh, I got one in my laptop, just not in any of my GPU machines
03:19 mwk: and I'm annoyed every time I sit on my desktop and do anything...
03:19 mupuf:booted my previous laptop yesterday and pestered so much about this
03:19 mupuf: See :p
03:19 karlmag: mwk: virtual or netboot?
03:19 karolherbst: well put more RAM in it
03:19 mwk: karlmag: netboot + nfs
03:19 Tom^: karlmag: then its safe to say the archlinux kernel config is no where near default. ;_;
03:19 karlmag: Tom^: hehe.. *that* I believe.
03:19 mupuf: I am so looking forward to intel xpoint!
03:20 karolherbst: I will buy another ssd if they get more reliable than hdds
03:20 mupuf: we are going to max out the PCIe BW
03:20 karlmag: Tom^: only realistic comparison is to use identical kernels and configs, so bog standard defaults is best.
03:20 karolherbst: and I don't talk only about failure rates
03:20 mupuf: karolherbst: never had issues with ssds, I cannot say the same with hdds
03:20 karolherbst: mupuf: yeah, but if a SSD dies you are screwed
03:20 karolherbst: if a HDD dies, you can still access the data usually
03:20 mupuf: exactly the same with hdds
03:20 mwk: heh
03:21 mwk: actually my previous SSD failed on me in a funny way
03:21 Monkeh: Depends on your definition of 'die'
03:21 mwk: every once in a few days it just hang
03:21 Monkeh: HDDs are quite capable of failing in a manner which leaves data recovery financially unviable.
03:21 karolherbst: I had like 5 dead hdds here and from all of them I could clone the entire fs, allthough they were really screwed
03:21 mwk: so, rather unusable, but still readable
03:21 Monkeh: karolherbst: So, not dead.
03:21 mwk: er, I meant to say, a few times a day
03:21 karolherbst: well you couldn't write new data on them
03:22 karolherbst: and the read/write head reset itself pretty much often
03:22 mupuf: mwk: that is bad
03:22 karolherbst: ohh I have a funny SSD here
03:22 Monkeh: The rather.. sudden failure modes of SSDs are a bit problematic, but it just reinforces the concept of backups.
03:23 karolherbst: it gets like 80°C hot when I plug it in :D
03:23 karolherbst: and does nothing
03:23 mupuf: wonderful SSD
03:23 mupuf: solid-state-dissipator :D
03:23 karolherbst: even the sata controller doesn't recognize it
03:23 Monkeh: Possibly repairable
03:23 karolherbst: I've tried
03:23 karlmag: From what I hear (colleague who had 3 SSDs die on him within about half a year), SSDs tend to really die when they die, while regular drives most often die gradually. YMMV though.
03:24 karolherbst: yeah
03:24 Monkeh: karlmag: Yes, when they go it's usually a case of the controller deciding to give up on talking forevermore.
03:24 karolherbst: with HDDs you usually notice when they are dieing
03:24 karolherbst: like they tend to make strange noises :D
03:24 mwk: karlmag: unfortnately HDDs are suspectible to death by gravity
03:24 Tom^: my ssd's is soon ~5 years i think so im quite pleased so far.
03:24 mwk: and that's not very gradual
03:24 Tom^: soon gotta replace them because 60gb is not enough :P
03:24 karolherbst: mwk: not new ones though, or if laptop manufactures would care
03:24 mupuf: I have 5 SSDs, 3 of them are 4 years old
03:24 Monkeh: HDDs are subject to death by gravity, heat, vibration, assembly, manufacturing defect, plain bad luck, and Seagate.
03:25 mwk: I had a funny incident once
03:25 karlmag: mwk: yeah... there are plus and minus with both types I guess... *mumble something about multiple copies of [important] data*
03:25 Monkeh: Also natural wear and tear
03:25 karolherbst: heat and HDDs?
03:25 karolherbst: how?
03:25 mwk: I bought a new HDD and was copying all data from old HDD
03:25 karolherbst: :D
03:25 karolherbst: I mean HDDs can get quite warm, but nothing near any SSDs
03:25 Monkeh: karolherbst: They generate quite a bit of heat, and the hotter they run, the greater the friction on the bearings.
03:26 mwk: I didn't have physical space in the machine, so the HDDs was hanging on the wires
03:26 mwk: once everything was done and I was happy that the system boots from the new HDD... I slipped and the new HDD (turned on) fell on the old HDD (turned on)
03:26 mwk: killed both
03:26 karolherbst: well I also don't by any HDD with a power consumption above 2W :D
03:26 Tom^: WD blacks or its not worth buying :p
03:27 karolherbst: I really should replace my hdd in my dvd slot with a ssd
03:27 karolherbst: but I don't trust them :O
03:28 Monkeh: Pretty much all 3.5" HDDs need 2W just to remain spinning.
03:28 karolherbst: well I only have three 2.5" because I only have a laptop
03:29 Monkeh: Ah, well, gravity and vibration are your enemy.
03:29 karlmag: mwk: owww.. that sucks... :-P Not long ago I did drop a newly tested (tested ok) old disk on the floor. Retested it and it was shot. So.. don't drop disks :-P
03:29 Monkeh: Can't say I've had any heat issues with an SSD in my laptop either :P
03:30 karolherbst: when my laptop falls, I have bigger problems than broken HDDs :D
03:30 Monkeh: And no moving parts.. except when you ask the CPU to do anything but sit in a sleep state.
03:30 karlmag: karolherbst: like?
03:30 karolherbst: I think the HDDs are the cheapest parts of my laptop
03:31 karolherbst: and I am sure they lock when falling
03:31 karolherbst: but never tested it
03:31 Monkeh: Few have that feature these days afaik.
03:31 karolherbst: which is stupid
03:31 Monkeh: But seeing as I'm not daft enough to DROP my laptop.. :P
03:31 Monkeh: Vibration is a bigger concern
03:32 Monkeh: Anyway, must go
03:32 Tom^: hdds doesnt like being out in ~-30C and then brought inside, the moist makes the platters unreadable.
03:32 karlmag: Monkeh: well, intensions and reality is sometimes... not quite the same :-P
03:32 Tom^: from my own experience =D
03:33 pq: karolherbst, I found a cure for my not trusting SSDs: automatic daily incremental backups to a HDD :-)
03:34 karlmag: I do have a few SSDs, but I only have the OS on them, not user data.
03:34 Tom^: karolherbst: also just have 1 ssd and 1 hdd in it, symlink dev folders to the hdd and other valuable stuff that doesnt require SPEED and keep the OS still fast as hell
03:34 Tom^: thats what i do anyways
03:37 karolherbst: Tom^: yeah my system was on a ssd
03:37 karolherbst: that's why my system hdd is in my dvd slot now
03:37 karolherbst: .D
03:46 karolherbst: mupuf: I get the feeling that the temp offset is based on kelvin :/
03:47 karolherbst: or something else funny :/
03:53 mupuf: °F? :D
03:54 karolherbst: now the fun part
03:54 karolherbst: when I clear the parameters
03:54 karolherbst: nvidia uses the ones from the pstate voltage entry....
03:54 mupuf: when values fall out of spec, nvidia often reverts to another default value
03:55 karolherbst: now stuff will be easier I hope
04:00 karolherbst: https://gist.github.com/karolherbst/714fd4c81c9a18a0e685 :)
04:02 karolherbst: mupuf: I need an educated guess: https://gist.github.com/karolherbst/714fd4c81c9a18a0e685
04:03 karolherbst: if the base is 0°C then the function isn't a linear one
04:03 karolherbst: maybe the base is higher
04:03 karolherbst: ohh wait
04:03 karolherbst: 0x0 means 0.6V
04:03 karolherbst: ...
04:08 karolherbst: much better: https://gist.github.com/karolherbst/714fd4c81c9a18a0e685
04:10 mupuf: sorry, can't have a look at that just now
04:10 karolherbst: k
04:11 karolherbst: figured it out now anyway :)
04:11 karolherbst: factor: 15.3
04:11 karolherbst: 15.3 * c2 * T = voltage_offset
04:11 mupuf: ass-pulled parameter again :D
04:11 karolherbst: course :D
04:12 karolherbst: did you look at the gk20a parameters?
04:12 karolherbst: they are all ass-pulled
04:12 karolherbst: :D
04:12 mupuf: well, at least, there is a precedent!
04:12 karolherbst: I just hope the constants are the same for all gpus...
04:12 karolherbst: and if not, I close my ears and eyes
04:13 karolherbst: sooo if all went well, mode 1 means: voltage = min(max(16.75 * c0 + 15.3 * c2 * T, voltage_min), voltage_max)
04:15 mlankhorst: wasn't that what I found?
04:15 karolherbst: now I try to get voltage_min with 1°C and increase the voltage by 6250µV for each °C :)
04:15 karolherbst: mlankhorst: you did?
04:15 mlankhorst: or something
04:16 mlankhorst: I posted a patch for nvc0
04:16 mlankhorst: ages ago
04:16 karolherbst: this would be really good, because if we both got to the same result, that means that we are most likely right or made the same mistakes
04:16 Monkeh: Which either way confirms the level of dain bramage involved? ;)
04:17 mlankhorst: something nvc0 voltage
04:17 mlankhorst: https://lists.freedesktop.org/archives/nouveau/2014-January/015515.html
04:17 mupuf: mlankhorst: you did not have such accuracy
04:18 karolherbst: mlankhorst: did you check the first byte?
04:18 mlankhorst: karolherbst: no idea, this is what I know
04:18 karolherbst: the first byte set is _important_
04:18 mupuf: because you were wokring with GPIOs
04:18 mupuf: karolherbst: is doing it with the PWM controlers
04:18 mlankhorst: mupuf: I think I did
04:19 mupuf: what the heck? I do remember you finishing this. I remembered pinging you on this :s
04:19 karolherbst: ohh this is most likely for the 0x0 mode though
04:19 mlankhorst: I modified some crap so the GPIO registers worked over a different range
04:19 mlankhorst: then watched the results
04:20 mlankhorst: hence a lot higher accuracy
04:20 karolherbst: I can confirm the 0.1 at least for mode==0
04:21 karolherbst: but the entire thing is something else when the mode==2
04:21 karolherbst: or mode==1
04:21 mlankhorst: yeah I just RE'd it with my nvc0, not sure what mode it has..
04:21 karolherbst: and cstates max point to a mode0 entry which links a mode1 entry in
04:21 mlankhorst: but vbios is available
04:21 karolherbst: mlankhorst: the mode is the first byte in the row
04:21 karolherbst: it can be set to 0-3 for each row
04:22 karolherbst: 1 means that at least c2 is affected by the temperature
04:22 mlankhorst: ah..
04:22 karolherbst: you see, 6 fields, 4 modes ;) => plenty of fun
04:23 mupuf: this is insane though
04:23 karolherbst: yeah
04:23 karolherbst: it is
04:23 karolherbst: I hope some parameters are ignored
04:23 karolherbst: because c3-c6 are never set for me
04:23 mupuf: well, to me, it screams: There are more variables
04:23 karolherbst: *c5
04:23 mupuf: as in, the temperature is one
04:23 karolherbst: yeah
04:24 karolherbst: most likely
04:24 mupuf: but there must be others
04:24 karolherbst: mode 0 could be without a variable one though
04:24 mupuf: otherwise, why not just write the wanted voltage
04:24 karolherbst: right
04:24 karolherbst: but what can the others be?
04:24 karolherbst: tempreature makes sense, right
04:25 karolherbst: but that's pretty much it
04:25 karolherbst: maybe power consumption?
04:25 mupuf: that would be too variable
04:26 karolherbst: well there are plenty ways to build avarage values for that
04:26 karolherbst: but then again
04:26 mupuf: maybe though, as in, how variable is load and how much capacity is on board to smooth out stuff
04:26 karolherbst: temperature would be enough
04:27 karolherbst: this would be insane to RE...
04:27 mupuf: insane, even by nouveau standards, yes
04:30 karolherbst: mode 1 c0, c2: done
04:31 karolherbst: c0: 13 400 000 c2: 408 => https://gist.github.com/karolherbst/971e461060dc8880a2c5
04:31 karolherbst: :)
04:31 karolherbst: looks pretty much like the thing I wanted to have
04:31 mupuf: are you going to write a fuzzer that checks your model with what the blob does?
04:32 karolherbst: what do yo mean by fuzzer?
04:32 mupuf: well, writes random values to the vbios
04:32 urjaman: thing that feeds in all the values ...
04:32 mupuf: check what the voltage is
04:32 urjaman: and sees the output
04:32 karolherbst: ohh, no currently I just put stuff into the vbios and see if nvidia does what I expect
04:33 mupuf: read the values back from the vbios, and computes what you would set before comparing
04:33 karolherbst: ohh
04:33 karolherbst: so you mean a piece of software which parses the volt map table, calculates a voltage and checks if nvidia does the same
04:33 mupuf: yes
04:33 karolherbst: one thing though
04:34 karolherbst: random won't work
04:34 karolherbst: because random will most likely hit some min/max value all the time
04:34 mupuf: you can make it random within a range
04:34 mupuf: or extract values found in the DB
04:34 mupuf: you can reuse nvbios to parse the vbios
04:35 mupuf: you may need to port the voltahge mapping table to the new nvbios style (separate parsing from printing)
04:36 karolherbst: first I want to understand all that stuff :D, but yes having a tool for this thing would be nice I guess
04:37 mupuf: well, this is what mwk does to RE the ISA
04:38 mupuf: I guess it makes sure you test enough cases to avoid the confirmation biais
04:38 karolherbst: yeah
04:39 mupuf: well, that would be for you
04:39 mupuf: for him, it makes sure that there is no hidden state he did not discover
04:39 karolherbst: thing is, we don't know which cstate nvidia uses ...
04:39 karolherbst: we could read the clocks out though
04:40 mupuf: well, you can disable dynPM
04:40 karolherbst: mhh
04:40 karolherbst: it would be nice to have a userspace tool which runs alongside nvidia and checks the set voltage with the expected ones
04:40 karolherbst: and wherever we are off, it would notify us
04:40 mupuf: that would also be a cool thing to have!
04:41 karolherbst: though I don't care if we are off by one (pwm/gpio) range value
04:41 karolherbst: because finding the _exact_ constants is just too messy
04:42 karolherbst: well if we are always off by one this is also bad, so if 5% of all combinations are slightly off, it should be good enough
04:44 mupuf: nope
04:44 mupuf: 5% under is a no-go
04:44 mupuf: 5% above, meh
04:44 karolherbst: mhh okay
04:44 karolherbst: but I was thinking more about rounding errors, because here we have a lot of them
04:44 mupuf: sure
04:45 mupuf: still not acceptable
04:45 karolherbst: better then what we currently have :p
04:45 karolherbst: *than
04:45 mupuf: sure, but when you leave work in a semi-working state, the incentive to actually fix it is low
04:45 mupuf: and you will always wonder if some instabilities are due to a voltage too low or not
04:46 mupuf: oh, other point of a tool like the one I described
04:46 mupuf: we can run it on many GPUs
04:46 mupuf: and see if the constants are actual constant or per-GPU
04:47 karolherbst: right
04:48 karolherbst: okay, mode2 c0/c2 is done: https://gist.github.com/karolherbst/971e461060dc8880a2c5
04:48 karolherbst: either I am really lucky, or the constants are kind of right
04:49 karolherbst: c2 408 translates to 6250µV steps, which my pwm does
04:53 mupuf: great :) Will need to be confirmed on other GPUs though :)
04:53 karolherbst: I will collect the stuff here: https://gist.github.com/karolherbst/3618ce3bf994779a3e0d
04:58 karolherbst: this is weird though
04:58 karolherbst: why not moving the 15.3 factor into the vbios?
04:58 karolherbst: it can only mean that those constant factors _might_ depend on something or can actually change
04:58 karolherbst: otherwise it doesn't make sense
04:59 mupuf: yes
04:59 Tom^: is it something that gets changeable when you start fiddling with coolbits?
05:00 karolherbst: no, the coolbits stuff is stupid
05:00 karolherbst: its just a clock offset :/
05:09 pmoreau: karolherbst: Sorry, didn't had time to look again at the MMIO stuff (I saw your ping this weekend). I'll do that tomorrow evening. Where would the latest version be? On your GitHub repo?
05:10 karolherbst: pmoreau: it is a kernel patch and I didn't put it into git yet
05:10 pmoreau: As a gist then?
05:10 karolherbst: just try this out: https://lists.freedesktop.org/archives/nouveau/2016-February/023994.html
05:10 karolherbst: ohh wait, I think this is a old version
05:11 karolherbst: pmoreau: https://gist.github.com/karolherbst/903bf75486134dd9505d
05:11 pmoreau: K, thanks
05:21 karolherbst: mupuf: mhh and c1 also does something :/
05:24 karolherbst: and it is unrelated to temperature...
05:25 karolherbst: 8447 -> 843750.0 µV .... please be that easy
05:26 karolherbst: k, that was an easy one
05:26 mupuf: ?
05:26 karolherbst: 100*c1 => µV
05:27 mupuf: you are working on the mode 2 right now?
05:27 karolherbst: 0x1
05:27 mupuf: ok, never tried this one
05:28 karolherbst: so µV = 0.0597*c0 + 100*c1 + 15.3*T*c2
05:28 karolherbst: ....
05:28 karolherbst: why
05:28 karolherbst: ....
05:28 karolherbst: if c1 is that useless, no wonder it is set to 0
05:30 karolherbst: and I think nvidia sets the pwm to 843750.0 µV for 840625.0-846875.0
05:32 karolherbst: or something really near that
05:38 karolherbst: this was indeed easy
06:10 karolherbst: µV = 0.0597*c0 + 100*c1 + 15.3*T*c2 + 100*T*c3
06:10 karolherbst: ...
06:32 nightfuri: karolherbst, changing the window shadow color in kde has seems to have worked. haven't faced any problems since
06:32 karolherbst: nightfuri: so you disabled the shadows?
06:32 karolherbst: or is just black broken?
06:33 nightfuri: karolherbst, i changed it to a non-black color and haven't touched those settings yet
06:33 karolherbst: mhh
06:33 karolherbst: nightfuri: would you like to verify that only pure black is broken? or if there is a pattern to the broken colors?
06:34 karolherbst: nightfuri: you have a maxwell card by the way, right?
06:35 nightfuri: karolherbst, GeForce 210. ok i will check changing back to black
06:35 karolherbst: ohh 210
06:43 KingEdgar: Hello hello
06:43 KingEdgar: so, just to make sure the reason there is no acceleration in the nouveau drivers for cards in the GM200+ is due to the fact nvidia hasn't released firmware up till now for the GM200-204, right?
06:43 KingEdgar: >_>
06:44 karolherbst: mupuf: oh we are so screweed :/
06:44 karolherbst: c5 isn*t linear for sure
06:44 karolherbst: I am now pretty sure there is another factor mixed in
06:45 karolherbst: and the 6 parameter are stuff like c0, p0T, p0^2T, p0T^2, something... maybe, maybe not :/
06:45 karolherbst: meh
06:46 pmoreau: KingEdgar: Well, firmware for GM200 and GM204 was released a couple of hours ago. :-)
06:46 KingEdgar: yes.
06:46 KingEdgar: I am aware, that's why I said up till now :v
06:46 pmoreau: Not sure if now was included or not
06:46 pmoreau: But yes, you're right
06:47 KingEdgar: So, why do you need the firmware for acceleration?
06:47 KingEdgar: and by acceleration i assume it is meant 3D acceleration, reclocking and all that jazz?
06:47 karolherbst: KingEdgar: for chip init stuff
06:48 pmoreau: Reclocking & co is usually under power management umbrella, not acceleration
06:48 KingEdgar: oh?
06:48 pmoreau: 2D and 3D acceleration are usually meant by acceleration
06:48 karolherbst: there are many little co processors (aka falcons) on the nvidia gpus
06:48 karolherbst: and these need special firmware files to work
06:48 karolherbst: some of them are 3d related, some video related
06:48 karolherbst: and some do other stuff
06:49 KingEdgar: so you coulc have all the reclocking ability you want on these cards but it be pointless because you wouldn't be able of accelerating anything pmoreau ?
06:49 karolherbst: and before gm2xx these firmware files could also be provided by nouveau, because there weren't signed
06:49 pmoreau: KingEdgar: Could be that reclocking needs another firmware as well, but I'm not sure
06:50 pmoreau: karolherbst: Was it you who tried a bit of reclocking on some Maxwell cards? (v1 and/or v2?)
06:50 karolherbst: yeah, v1
06:50 karolherbst: I think it works
06:50 karolherbst: if we ignore the core voltage
06:51 pmoreau: :-D
06:51 karolherbst: but core voltage I figure out now!
06:51 karolherbst: so we may be fine there
06:51 pmoreau: Oh nice! :-)
06:51 karolherbst: k
06:51 karolherbst: I think I am done with the mode 1 entries
06:51 pmoreau: With all those c1, c2, etc. thingy?
06:51 karolherbst: yeah
06:53 karolherbst: mode 1: µV = 0.0597*c0 + 100*c1 + 15.3*T*c2 + 100*T*c3 + 41 * c4 + 0.066 * T^2 * c5
06:53 karolherbst: though the last constant could be wrong
06:54 pmoreau: Interesting
06:54 karolherbst: yeah, now I make an entry with all things set, calculate what I expect and see what I get :)
06:54 pmoreau: Eh eh! :-)
06:55 karolherbst: the last one isn't fun at all, because it is not linear :/
06:55 pmoreau: I did progress a bit on the MMIO stuff, but then the NVIDIA module failed to build… --"
06:56 karolherbst: https://gist.github.com/karolherbst/62c0cf524812a8dc2b26
06:56 karolherbst: :D
06:56 karolherbst: pmoreau: this looks like a T^2 thing to you too, or not?
07:01 pmoreau: Yeah, could be
07:05 karolherbst: \o/
07:06 karolherbst: I put in c0 11891678 c1 -632 c2 -6611 c3 0 c4 0 c5 0 now and this is what I got: https://gist.github.com/karolherbst/5859c3fb7e997ca79a18
07:06 karolherbst: wait
07:06 karolherbst: c0 6700167 c1 2000 c2 25 c3 8 c4 4878 c5 0
07:06 karolherbst: these are the parameters
07:07 karolherbst: pretty close, right? :)
07:07 karolherbst: the values after the °C thing is what the pwm is set by the nvidia
07:07 karolherbst: driver
07:07 karolherbst: and expected is what I calculated inside python :)
07:07 pmoreau: Yep! :-)
07:08 karolherbst: well 0 means auto, so the last entry is crap :D
07:09 pmoreau: You might want to round to closest multiple of 6250 and you would get the blob's results
07:09 karolherbst: mhh
07:09 karolherbst: thing is, I am not 100% accurate with the constants
07:09 karolherbst: also nvidia doesn't seem to round that way
07:10 karolherbst: maybe it is more like of -30% +70% step size range
07:10 karolherbst: or something
07:10 pmoreau: if the odd lines are the blob's output, they are all multiples of 6250
07:10 karolherbst: yeah
07:10 karolherbst: pwm
07:10 karolherbst: +1 pwm means + 6250µV
07:11 pmoreau: Ok
07:11 karolherbst: I just peek the mmio reg for the pwm and calculate the voltage out of it
07:17 karolherbst: https://gist.github.com/karolherbst/5859c3fb7e997ca79a18
07:17 karolherbst: :)
07:17 karolherbst: now I've added a parameter for c5
07:18 karolherbst: seems I am a bit higher now in general
07:18 karolherbst: but that's fine for now
07:21 karolherbst: I am pretty sure there is a second variable/value in that formular I don't know yet
07:21 karolherbst: because otherwise 3 parameters would be enough
07:24 karolherbst: wait a second... : gk20a does this: c0 + c1speedo/x + c2speedo/x^2 + c3speedoT/x^2 + c4T/x + c5T^2/x^2 , I found out: 0.0597*c0 + 100*c1 + 15.3*T*c2 + 100*T*c3 + 41 * c4 + 0.066 * T^2 * c5
07:24 karolherbst: in the gk20a thing x is a "scale" value
07:25 pmoreau: Better higher than lower :-)
07:25 karolherbst: and speedo is a value gk20a gets from the chip for each cstate set...
07:25 karolherbst: and x was fixed to 100
07:27 karolherbst: mupuf: as you see the gk20a stuff is close, but different enough, that I don't think we can reuse it much :/
07:27 karolherbst: but that depends on the "speedo" value I have no clue what it is
07:29 karolherbst: pmoreau: I am already happy when I am close enough...
07:36 karolherbst: now mode 0 :)
07:39 karolherbst: this is nice though, because the linked entries make finally sense
07:40 karolherbst: like the effect due to temperature can be limited that way and stuff
07:59 pq: hm, ISTR a wiki page with some nvidia tiling formats explained, but I can't find it. It'd make a since link in a blog post I'm writing.
08:10 mwk: pq: IIRC it's gone, but there's doc for that in envytools
08:11 pq: mwk, I tried to look for it but didn't find it there either
08:11 mwk: http://envytools.readthedocs.org/en/latest/hw/memory/g80-surface.html
08:11 pq: "since link"?? a nice link, I meant to say
08:13 pq: mwk, thanks, that looks like the perfect link for "there's a whole world of wild things out there" :-)
08:39 karolherbst: Tom^: okay, I think I collected enough data to write some test stuff for your card and mine
08:40 karolherbst: Tom^: could you give me your highest clock at 90°C with the blob?
09:01 karolherbst: "error: SSE register return with SSE disabled" ... what a compile error
09:02 karolherbst: ahh no I get it
09:04 karolherbst: stupid compiler
09:15 karolherbst: tip #1: if you implement something the right way, remove all hacks first :D
09:16 karolherbst: yay
09:16 karolherbst: it seems to work
09:17 karolherbst: sooo, who has a 780 Ti?
09:17 karolherbst: ohh wait, nouveau still bails when voltage doesn't fit 100%
09:18 imirkin: karolherbst: can't wait to hear the rest of your tips :)
09:18 karolherbst: :D
09:19 karolherbst: okay
09:21 karolherbst: Dezponia: there?
09:35 karolherbst: Tom^: k, I have some patches ready you could try out if you want :)
09:55 Tom^: ok
09:56 Tom^: karolherbst: sure
09:58 Tom^: karolherbst: 980mhz
09:58 Tom^: karolherbst: or well it seems to step down until it reaches 324core , 648 mem
09:59 karolherbst: Tom^: I meant under full load
09:59 Tom^: i thought diablo 3 would suffice , seems not then
10:00 karolherbst: :D
10:00 karolherbst: https://github.com/karolherbst/nouveau/commits/master_karol_no_touchy three newest commits
10:00 Tom^: yeah 980 core , 7000 mem.
10:00 karolherbst: it isn't complete yet, but should cover the basics for your gpu
10:00 karolherbst: 980
10:00 karolherbst: okay
10:00 Dezponia: karolherbst: Yepp?
10:01 karolherbst: Dezponia: what version of nouveau are you using?
10:01 karolherbst: if you use the volt hack: use the three newest commits here isntead: https://github.com/karolherbst/nouveau/commits/master_karol_no_touchy
10:01 karolherbst: I hope that works
10:01 Dezponia: karolherbst: No idea. Not home at the moment so cant really tell
10:01 karolherbst: k
10:01 Dezponia: Probably whatever arch ships which is not the latests from you :)
10:01 karolherbst: :D
10:01 karolherbst: k
10:02 Dezponia: karolherbst: But if you want me to test something I'll poke around at it when I get home (if I have any time) :)
10:02 karolherbst: Tom^: 980 is only your base clock though
10:02 karolherbst: boost is more
10:02 karolherbst: anyway, test my patches
10:02 Tom^: yea well it doesnt boost when i go to 90C so
10:03 karolherbst: you should get slightly higher clocks than with the info.max hack
10:03 karolherbst: and it should still be stable
10:03 Tom^: moar points and i can finally beat Dezponia
10:03 Tom^: muahahah
10:04 Tom^: now just to recall which branch i was using that didnt have dynamic reclocking hm.
10:07 Dezponia: Tom^: Clearly my superior VRAM will prevail! VRAM is after all the most relevant performance factor
10:07 Tom^: not if i compile mesa with -Os
10:15 karolherbst: Tom^: well you could use my wip branch
10:15 karolherbst: I should have fixed dyn reclocking by now
10:15 Tom^: yea well i dont want it
10:15 Tom^: =D
10:15 Tom^: flickers to much
10:15 karolherbst: :p
10:15 karolherbst: well you can just fetch my repostiory
10:15 karolherbst: and pick those three commits
10:16 Tom^: mmh will try, compiling mesa and lib32 mesa tonight, then we shall see after work tomorrow if i get the time to test things
10:29 niligulmohar: Hi
10:29 niligulmohar: Is there any work done on getting KMS to work for GM200?
10:30 mupuf: karolherbst: please always round up
10:31 mupuf: very good work though!
10:31 mupuf: but before asking people to try out your code, you should make sure the coefficient are the same for every cards
10:31 mupuf: one sample point is not enough
10:32 imirkin: niligulmohar: https://github.com/skeggsb/nouveau/commits/master should have patches to recognize GM200
10:33 mupuf: oh, and rounding up will take care of the case where there are no entry high-enough for what you want
10:35 niligulmohar: imirkin: Thanks. I'll try them.
10:36 imirkin: GM204/GM206 should support KMS out of the box on 3.19+ i think
10:40 niligulmohar: imirkin: Not GM200 though.
10:45 imirkin: niligulmohar: indeed, that one got left out.
10:45 imirkin: not exactly a lot of people getting those high-end cards and playing with nouveau :)
10:46 niligulmohar: I can't see why o_o
10:50 Yoshimo: imirkin: do they prefer to be archaeologists and dig through ancient stuff instead?
10:51 imirkin: Yoshimo: ?
10:52 Yoshimo: " not exactly a lot of people getting those high-end cards and playing with nouveau ", so the opposite is true, isn't it?
10:55 karolherbst: mupuf: I round up
10:55 karolherbst: mupuf: https://github.com/karolherbst/nouveau/commit/1a157aa3d09604729f6283de287bd0a76cac524a
10:55 imirkin: Yoshimo: not necessarily
10:56 imirkin: Yoshimo: i suspect there's very few people using nouveau at all, with a vastly decreasing number now that nvidia gpu's in laptops are for offloading only
10:57 Yoshimo: yea, but that might be because the binary driver is superior by quite a margin for most people , at least for now
10:58 karolherbst: mupuf: what kepler cards do you have?
10:58 imirkin: Yoshimo: forever, i think
10:59 imirkin: [unless nvidia should decide to stop producing it for linux]
10:59 chithead: maybe if nouveau started to support freesync...
11:00 karolherbst: yeah, because freesync is so important...
11:00 imirkin: chithead: you really think that'd matter?
11:00 chithead: being able to use variable refresh without those insanely expensive g-sync monitors? yes, it could matter
11:00 imirkin: chithead: in a hypothetical situation where, today, we have support for freesync, you think people would switch over and lose their precious fps?
11:00 Yoshimo: imirkin: it isn't necessary to implement all the game specific optimisations in nouveau too
11:00 mupuf: karolherbst: nve6, nve7
11:01 karolherbst: mupuf: then I would like to test a bit with the nve7 one
11:01 chithead: 40 fps with freesync may be better than 50 fps without
11:01 mupuf: ok, will come back home soon-ish
11:01 imirkin: chithead: how about 4 fps?
11:01 karolherbst: k thanks
11:02 chithead: 4 fps would probably be too low to be useful
11:08 karolherbst: anybody a clue how I can disable downclocking with the nvidia driver? :/
11:08 karolherbst: it is quite annoying to disable it every time in nvidia-settings
11:08 mupuf: karolherbst: nvidia-settings also has a command line interface
11:10 karolherbst: mupuf: right, thanks
11:19 karolherbst: now I can also write a script doing the work for me! :O
11:24 Tom^: karolherbst: Option "RegistryDwords" "PerfLevelSrc=0x2222" in xorg.conf :p
11:24 Tom^: in Device section
11:24 karolherbst: that doesn't work for me
11:25 Tom^: seems coolbits has overvoltage with 346.x and newer hm.
11:25 karolherbst: not for me
11:25 Tom^: cli options
11:25 karolherbst: "The valid values for 'GPUOverVoltageOffset' are in the range 0 - 0 (inclusive)."
11:25 karolherbst: so you were saying? :p
11:25 Tom^: and you set the colbits to 16 ?
11:25 karolherbst: 28 actually
11:26 Tom^: ok nvidia ╭∩╮(︶︿︶)╭∩╮
11:31 Yoshimo: why Tom? they released maxwell firmware ,isn't that something?
11:31 karolherbst: they did not
11:31 karolherbst: :p
11:32 Yoshimo: pre-release?
11:32 karolherbst: not even that
11:32 karolherbst: just wip stuff nouveau devs should work with to smooth things out
11:33 karolherbst: it is official when it is inside linux-firmware
11:35 Yoshimo: without power management it isn't nice anyway
11:56 karolherbst: nice, when I set the right power_budget to 0, the driver won't load :)
12:38 karolherbst: wow....
12:38 karolherbst: I found a game which is so smart, that DRI_PRIME gets totally ignored
12:38 karolherbst: ...
12:38 mupuf: karolherbst: ah ah, it unsets it?
12:38 karolherbst: no clue yet
12:38 mupuf: env_dump shou;ld be able to track that
12:38 karolherbst: I guess it does a clean fork or something
12:39 mupuf: well, forks are not super well handled in env_dump (it won't tell you it forked) but you should still see changes to the environment
12:39 karolherbst: mhhh
12:39 karolherbst: DRI_PRIME=1 is set in the process
12:41 mupuf: imirkin: I have requested damien lespiau to add the nouveau ML to freedesktop's patchwork
12:42 imirkin: mupuf: cool
12:42 mupuf: this way, we will be able to apply patch series with: git pw apply -s 122
12:42 karolherbst: ....
12:42 karolherbst: /mnt/data/SteamLibrary/steamapps/common/The Stanley Parable/bin/libstdc++.so.6: error: version lookup error: version `GLIBCXX_3.4.20' not found (required by /usr/lib32/dri/nouveau_dri.so) (fatal)
12:42 mupuf: 122 being the patch series #
12:42 mupuf: karolherbst: not uncommon
12:43 imirkin: karolherbst: rm libstdc++.so.6 tends to fix it right up :)
12:43 karolherbst: yeah I guessed so far already :)
12:48 tobijk: hey there, with latest mesa snapshots i see a regression where only the compat profile is available with nouveau and no (or an undefined) core profile
12:49 karolherbst: noooooo...
12:49 tobijk: ? known bug?
12:49 karolherbst: nah, my gpu just crashed
12:50 karolherbst: and the application took my cursor with it :/
12:50 tobijk: if the gpu rashes / hangs for me it always pulls my whole system with it :D
12:51 imirkin: tobijk: not sure what you're talking about...
12:51 karolherbst: fifo: PBDMA0: 00000002 [MEMACK_TIMEOUT] ch 2 [00bf890000 stanley_linux[3927]] subc 0 mthd 001c data 00000002 :/
12:51 tobijk: imirkin: glxinfo freports no core profile for me anymore
12:51 imirkin: tobijk: pastebin
12:52 imirkin: (full glxinfo output)
12:52 tobijk: http://hastebin.com/vezasikufo.py
12:52 tobijk: Max core profile version: 0.0 <-- this makes me wonder
12:53 imirkin: huh
12:53 imirkin: i figured you had done something to lose GLX_ARB_create_context_profile but that's not it
12:54 imirkin: wtf, you're only getting ES 2
12:54 imirkin: that means you built mesa somehow funny
12:54 tobijk: happens since the compute shader are in
12:54 tobijk: mesa is build as always
12:54 imirkin: oh wait, this sounds familiar
12:54 imirkin: it happened to me too
12:54 tobijk: (buildservice)
12:54 imirkin: what was it...
12:54 imirkin: hakzsam: do you remember?
12:54 karolherbst: make clean?
12:55 imirkin: no.
12:55 tobijk: is clean :)
12:55 imirkin: it was a legit issue.
12:55 karolherbst: k
12:55 hakzsam: imirkin, no, I don't
12:56 imirkin: it was something very very dumb
12:56 tobijk: heh
12:56 imirkin: oh right
12:56 imirkin: was getting set to 7 for compute
12:57 imirkin: and destroying the universe
12:57 imirkin: if (pc->MaxNativeInstructions &&
12:57 imirkin: (options->EmitNoIndirectUniform || pc->MaxUniformBlocks < 12)) {
12:57 imirkin: can_ubo = FALSE;
12:57 imirkin: }
12:57 imirkin: hakzsam: can you figure out a fix? this affects kepler+
12:58 hakzsam: imirkin, what's the problem exactly?
12:58 imirkin: hakzsam: maybe bail on PIPE_SHADER_COMPUTE if PIPE_CAP_COMPUTE isn't supported?
12:58 imirkin: hakzsam: kepler+ reports 7 for MaxUniformBlocks
12:58 imirkin: (or 8)
12:58 imirkin: can_ubo = false --> no GL 3.1
12:58 hakzsam: oh okay
12:59 imirkin: in the PIPE_SHADER_COMPUTE case, i'd just check for the supported IRs thing, and if that's false, just continue
13:03 hakzsam: imirkin, is this a recent regression?
13:03 tobijk: hakzsam: since compute shaders are in this happens
13:04 imirkin: hakzsam: your commit :)
13:04 imirkin: hakzsam: https://cgit.freedesktop.org/mesa/mesa/commit/?id=7c79c1e3e25857a45150f6a0bf2e813fed074a6c
13:04 imirkin: the change to st_extensions
13:06 hakzsam: imirkin, what? how this can be related ?
13:06 hakzsam: oh right
13:06 imirkin: :)
13:06 hakzsam: it's below
13:06 hakzsam: lol
13:09 hakzsam: imirkin, this might affect other gallium drivers too
13:10 imirkin: yes.
13:10 imirkin: that's why i'm suggesting using the same criteria as for ARB_compute_shader enablement
13:18 karolherbst: mupuf: any idea how we want to monitor the power consumption?
13:18 mupuf: karolherbst: what do you mean?
13:18 karolherbst: well, should the pmu just monitor it and notify the driver when the power consumption is too high?
13:19 mupuf: ah, that
13:19 mupuf: yes
13:19 mupuf: I have code for that already
13:20 mupuf: but, it is premature as long as we do not parse the vbios tables properly
13:20 karolherbst: also any preference on the order of stuff getting finished? 1. downclock cause of higher power consumption 2. volting fixes 3. cstate fixes?
13:20 karolherbst: mupuf: yeah I would take care of that then
13:21 hakzsam: imirkin, http://hastebin.com/lasilejaqe
13:21 hakzsam: this should fix the issue
13:21 hakzsam: it's a bit ugly though
13:21 karolherbst: I just want to clarify now in which order stuff should get finished so that stuff gets ready in a order in which stuff gets merge faster
13:22 mupuf: over-power consumption is unlikely to be an issue with current nouveau
13:22 mupuf: and only a problem on insane GPUs
13:22 karolherbst: yeah but it might after volting gets fixed
13:23 mupuf: I would rather disable boost clocks first
13:23 karolherbst: okay
13:23 mupuf: get that working well
13:23 mupuf: and then move on to boost which requires the power sensor
13:23 imirkin: hakzsam: presumably you can just do that in the compute case directly?
13:23 mupuf: voltage fixes is definitely next on the list
13:23 karolherbst: so then 1. limit to base clock 2. cstate fixes 3. volting fixes 4. other stuff
13:24 mupuf: why cstate first?
13:24 karolherbst: because otherwise we have too high cstates which can never be reached
13:24 karolherbst: well I could fix volting first though
13:24 karolherbst: but this is pretty much done already :D
13:24 karolherbst: I mean the cstate fixes
13:24 mupuf: I highly doubt that
13:24 mupuf: ah, ok
13:24 hakzsam: imirkin, if you prefer this way, yes
13:24 imirkin: hakzsam: well, it seems to make sense, no?
13:24 mupuf: because the voltage is not fixed until proven otherwise
13:25 karolherbst: I know
13:25 karolherbst: ohhhh
13:25 karolherbst: mupuf: https://github.com/karolherbst/nouveau/commit/8966e66cac18c9032d1055acf026a5c1e01e9f64 ...
13:25 karolherbst: maybe I should also get this merged
13:25 karolherbst: seems important :D
13:25 mupuf: seems so :D
13:26 hakzsam: imirkin, http://hastebin.com/unobisasaw
13:26 karolherbst: mupuf: k then I clean up this stuff: https://github.com/karolherbst/nouveau/commits/stable_reclocking_kepler
13:26 karolherbst: but I really want to discuss the NvBoost option first (naming and valid values and such)
13:27 imirkin: hakzsam: presumably s/compute_supported_irs/supported_irs/
13:27 hakzsam: imirkin, okay
13:28 imirkin: hakzsam: otherwise looks fine, but send it out
13:28 tobijk: hakzsam: you can use me as the lab rat today ;-)
13:28 hakzsam: tobijk, hehe, thanks for reporting this :-)
13:29 tobijk: hakzsam: no problem :)
13:34 tobijk: oh i missed the important (patch) part :/
13:36 tobijk: Max core profile version: 4.1
13:36 karolherbst: mwk, mupuf: anything against this patch? https://github.com/karolherbst/envytools/commit/b3adc65bfe1ea98314275e441656c6f2230315b3
13:36 tobijk: hakzsam: tested-by
13:39 mupuf: karolherbst: please use start+0xXX instead
13:39 mupuf: but otherwise, looks good!
13:39 karolherbst: I am thinking about checking the row length
13:39 karolherbst: I somehow thing there are vbios with only three additional parameters
13:39 karolherbst: *think
13:40 mupuf: yeah, please check the length too, but you can do it at first
13:40 karolherbst: ahh no
13:40 karolherbst: version 0x10 has three entries
13:40 hakzsam: tobijk, thanks, patch sent
13:41 karolherbst: 0x20 has 6
13:41 karolherbst: it is already in nouveau
13:41 karolherbst: https://github.com/karolherbst/nouveau/blob/master_4.4/drm/nouveau/nvkm/subdev/bios/vmap.c#L83
13:42 tobijk: hakzsam: thanks :)
13:44 karolherbst: mupuf: complaints if I turn the link into a decimal number?
13:44 karolherbst: this always annoys me
13:44 karolherbst: especially because there is no 0x in front
13:44 mupuf: let me come back home and then we can talk :D
13:45 mupuf: link = pcie link speed?
13:45 karolherbst: it's a simple thing though
13:45 karolherbst: wait
13:45 karolherbst: -- ID = 12, mode: 0 link: 30, voltage_min = 800000, voltage_max = 837500 [µV] c0 9363180 c1 289 c2 -6611 c3 0 c4 0 c5 0--
13:45 karolherbst: 30 is 0x30 here
13:45 karolherbst: so not ID =30, but ID=48
13:45 karolherbst: this is just confusing
13:52 skeggsb: gnurou: well, my gm200 appears too come up ok :)
13:52 skeggsb: to*
13:52 imirkin: skeggsb: i assume that in your format rework you attempted to make sure that the same set of formats were exposed before and after, yes?
13:53 skeggsb: yes, it should be identical
13:53 imirkin: ok, just checking
13:54 imirkin: and did you run a piglit test on a pre-maxwell gpu?
13:54 skeggsb: not as of yet
14:01 imirkin: skeggsb: the original was also wrong, and i had noticed it like 2 years ago, but for some reason never pushed a fix... but VF(A, B10G10R10A2_UINT, UINT, 10_10_10_2, 0), -- that should have the bgra order...
14:01 imirkin: i think in practice it's unreachable or something... dunno.
14:03 imirkin: skeggsb: why do you need this? # include "nvc0/nvc0_screen.h"
14:04 imirkin: oh duh. for NOUVEAU_DRIVER.
14:15 imirkin: skeggsb: fyi there's a mesa branchpoint in a couple days, would be cool to get the initial gm20x support out the door by then
14:15 imirkin: skeggsb: it's all you though since i don't have one
14:15 skeggsb: yeah i'll try to, turns out my gm200 doesn't boot after all
14:16 imirkin: and your gm206 does you no good
14:32 karolherbst: mupuf: is there a safe way to increase the pwm accuracy somewhow?
14:36 vita_cell2: karolherbst how is going developing for haswell?
14:36 karolherbst: ?
14:37 vita_cell2: I read something about nvidia's formware
14:37 vita_cell2: for gtx900 series
14:37 karolherbst: so you mean maxwell?
14:37 karolherbst: I don't have any
14:37 vita_cell2: ahhhhh sorry
14:39 imirkin: haswell = intel gpu
14:41 karolherbst: skeggsb: ohh right I remember. I want to add the pmu engine load values to nvif, but I have no idea where I should put them
14:59 mupuf: https://patchwork.freedesktop.org/project/nouveau/patches/ <-- the patchwork instance is set up
14:59 mupuf: It is going to be a giant mess there since we will have both mesa and kernel patches there
15:00 mupuf: apparently, if we use --subject-prefix correctly, we should be able to separate the patches into their right projets
15:04 imirkin: and ben's repo patches
15:06 mupuf: yeah, that's what I told damien
15:06 mupuf: https://patchwork-freedesktop.readthedocs.org/en/latest/manual.html <-- some documentation about his work
15:12 mupuf: git pw seems to work, once one installs the right dependencies
15:27 skeggsb: mmmm xonotic on gm200 :D
15:27 skeggsb:thanks gnurou
15:28 Javantea: Glad to hear gm200 is happening, I look forward to using it
15:29 gnurou: skeggsb: awesome!
15:35 imirkin: there goes skeggsb's productivity...
15:38 skeggsb: haha, no, i'm onto piglit now...
15:40 imirkin: and what are you doing while you wait for piglit to complete? :)
15:40 imirkin: are you figuring out why running in parallel destroys the universe? or playing xonotic? :p
15:40 skeggsb: too many things, unfortunately
15:40 skeggsb: i know why most of it destroys the universe on gmxxx
15:41 skeggsb: i have my kernel hacked-up to avoid most of it, fixing properly is in my forever-in-wip branch to fix a whole bunch of that stuff
15:41 skeggsb: might need to fall back to serial for gm2xx though for the moment, resetting gr (for fault recovery) doesn't seem to work so well on it
15:41 skeggsb: gnurou: ^^^
15:41 skeggsb: [ 4273.791901] nouveau 0000:02:00.0: timeout at /home/skeggsb/git/nouveau/drm/nouveau/nvkm/subdev/secboot/base.c:47/falcon_clear_halt_interrupt()!
15:41 skeggsb: [ 4275.791948] nouveau 0000:02:00.0: timeout at /home/skeggsb/git/nouveau/drm/nouveau/nvkm/engine/gr/gf100.c:1469/gf100_gr_init_ctxctl()!
15:41 skeggsb: [ 4275.791953] nouveau 0000:02:00.0: gr: init failed, -16
15:43 gnurou: skeggsb: what were you doing?
15:43 gnurou: Ah, reset allright
15:43 skeggsb: yeah :)
15:43 gnurou: I also have issues with suspend/resume
15:44 skeggsb: yeah i haven't attempted that yet.. let's see
15:44 gnurou: unloading/reloading the Nouveau module works fine though
15:44 gnurou: I suspect reset and suspend are the same issue
15:45 gnurou: the falcon might need a reset that we are not doing
15:46 skeggsb: hm, the errors look potentially similar
18:27 gnurou: skeggsb: great, with your Mesa Maxwell texture header patches almost everything runs great on gm20b too
18:27 skeggsb: gnurou: cool!
18:28 skeggsb: piglit results looked promising too, it died for unknown reasons half way through all the tests, but the failure rate before that was similar to gm10x
18:28 gnurou: skeggsb: I think a good performance boost could be achieved by implemented proper shader scheduling
18:28 skeggsb: gnurou: i hope you're offering ;)
18:28 gnurou: but I'm not surprised GLamor runs
18:29 gnurou: skeggsb: well everything seems to be documented by maxas actually
18:29 skeggsb: it's "good enough" for an initial release i think, i'm doing some piglit runs requested by ilia so the texture header stuff can be merged
18:29 gnurou: so besides manpower I don't think I'd have much to offer :)
18:29 skeggsb: then i'll post the gm20x patch
18:29 gnurou: yeah it's pretty good actually
18:30 gnurou: I'm glad your Maxwell header implementation works better than mine ;) (I had crashes on some glmark benches)
18:30 gnurou: next we need to discuss the firmware format... I will start a ML thread for this
18:31 gnurou: and I need to fix this suspend/resume issue
18:31 gnurou: but not bad compared to where we were 24 hours ago :)
18:32 skeggsb: yep, it's a decent improvement - finally ;)
18:34 gnurou: argh, Mesa regression on gk20a, everything is rendered completely white - I have to fix this first >_<
18:34 gnurou: strange, same code works fine on gm20b
18:37 phillipsjk: at least they were nice enough to change the revision numbers ;)
18:37 gnurou: skeggsb: actually the only visual issue I see on gm20x is with glmark2 -b 'shading:shading=cel'
18:40 imirkin: gnurou: manpower would be most welcome :)
18:41 imirkin: gnurou: i looked through the maxas stuff, but couldn't really make too much sense of it
18:43 gnurou: imirkin: ah, well since I took a look at it for the Maxwell texture stuff (I erroneously thought it was a shader issue at first) maybe I can try to convince my boss to let me work on it a bit
18:44 imirkin: gnurou: as it stands, i have neither the hw, nor, more importantly, the desire, to deal with it.
18:46 imirkin: i've been trying to sucker someone into finishing tess on maxwell, thus far to no avail
18:48 gnurou: yay, GLamor and LXDE on Tegra X1 \o/ thanks skeggsb !
18:55 phillipsjk: My "new" nvidia card is a C1. (Re: testing gallium 9 (directx)) tried going fullscreen in PoE with a nVidia C1 based card. Nouveau :Pgraph emmited Trap channel 6; GPCO/TPCO/MP trap: MULTIPLE_WARP_ERRORS UNALINGNED_MEM_ACCESS
18:56 phillipsjk: not sure if that would be an nouveau bug or not (CONDENSED a bit since transcribed from dmesg (2 lines)
18:57 phillipsjk: disabling gallium 9 suppresses the error message. Gdb says that stack is corrupt when I attach it after PathOfExile.exe freezes
19:00 imirkin: phillipsjk: sure is
19:01 imirkin: phillipsjk: try to get NV50_PROG_DEBUG=1 output of the game when this happens
19:01 phillipsjk: how do I do that? Install the debug version of the driver?
19:04 phillipsjk:debates whether to use ixquick or do domestic chores.
19:04 imirkin: oh yeah, you need a debug build
19:04 imirkin: and then just stick that in the env
19:04 imirkin: and capture all the output
19:07 phillipsjk:did not keep detailed enough note on all the packages he replaced to get "bleeding edge" drivers. I suppose there is dpkg.log
19:20 phillipsjk: I don't think I have time today, so don't wait up ;)
19:26 phillipsjk: I kinda want to test how much power my "new" router computer draws instead. (Old-dell (board-frying) supply, modded to be ATX compatible, installed with my newest board sans P4 CPU connector.)
19:26 phillipsjk: Can only draw 96W on the 12V line.
19:27 phillipsjk: But my NICs draw on 5V anyway.
20:01 phillipsjk: looks like about 67W idle - not great.
20:01 phillipsjk: could try under-clocking maybe.
20:16 airlied: sarnex: are you using a particular ppa?
20:16 sarnex: airlied: for mesa i'm using ppa:oibaf/graphics-drivers, other than that eveyrthing is from source
20:16 airlied: oops wrong channel
20:16 sarnex: yeah lol
20:37 airlied: sarnex: did your xserver build enable glamor?
20:37 sarnex: wrong channel again lol
20:37 airlied: doh!
20:41 phillipsjk:feels like this is his fault somehow.
21:48 imirkin: skeggsb: let's say i'm lazy... were there any differences?
21:49 skeggsb: i meant to add that to the email sorry - no, there weren't
21:49 imirkin: oh awesome.
21:49 imirkin: what was the typo?
21:49 skeggsb: the gf100 one has two extra passes in fact - but - those look to be those spurious failures you mentioned
21:50 skeggsb: an "|" instead of an "=" in one place
21:50 imirkin: heh
21:50 imirkin: it should have known what you meant :)
21:50 skeggsb: well, i think so
21:50 imirkin: so the only thing is that i'm unsure about the naming of the maxwell bit
21:51 imirkin: i'd kinda prefer it to be called version or something, but... your call
21:51 skeggsb: oh, yeah, i forgot to address that.. well, i figure it's fine until if/when we get a third one, then can worry about it
21:51 skeggsb: but i also don't care either way :P
21:51 imirkin: you're good to push all those (including the gm20x enablement) from my end.
21:51 skeggsb: this was all a diversion from what i'm meant to be doing :P
21:52 imirkin: i bet you missed *something* in there, but... meh. we'll work it out.
21:53 skeggsb: cool. R-b/A-b? ;)
21:54 imirkin: A-b is probably most fitting
21:54 imirkin: i didn't review super-carefully
21:56 skeggsb: aaaand done, now i go hide in case there's fallout :P
22:05 imirkin: nice