02:19karolherbst: imirkin: regarding the last tests: "nouveau 0000:01:00.0: clk: failed to raise voltage: -22"
02:34karolherbst: there seem to be more and more with this kind of issue :/
02:34karolherbst: mupuf: we have to do something about that :)
02:43karolherbst: so it could be, that even with the gddr5 fix, because of voltage issue, user may end up with less perf, because the gpu core clock doesn't get raised
02:46pecisk: but memory clock gets, so it is at least some performance improvement
02:47karolherbst: pecisk: yeah, but you get higher perf, when you switch to 0a first
02:48karolherbst: and with some games, gpu core is just more impotant
02:55karolherbst: mhhh, is here anybody with a maxwell gpu? I need to check some voltage thing on the blob
03:00karolherbst: mupuf: I know!
03:06karolherbst: mupuf: the "max value" is just the pwm value, where duty == div
03:06karolherbst: and we can go above
03:06karolherbst: values above duty seem to work, as I tested with the maxwell card
03:06karolherbst: 0x60 div, but 0x71 duty was too low for highest cstate, 0x72 was right
03:07karolherbst: but this doesn't fix gpio based voltaging
03:29pmoreau: karolherbst: The MCP79 is the integrated one, and the one reporting no voltage. The G96 did report no voltage because I had powered it off... After powering it back on, I did get a voltage.
03:37karolherbst: pmoreau: mhh could you look into the vbios of the MCP79 one to check if there is something voltage related for the cstates?
03:45pmoreau: karolherbst: Maybe :)
03:46pmoreau: Except, I'll probably get some food and start working after eating.
03:46pmoreau: But the vbios should be in the repo
04:03karolherbst: pmoreau: ohh which "user"?
04:05karolherbst: pmoreau: but I also thought I saw yours :/
04:05karolherbst: found it
04:06karolherbst: pmoreau: there is only the NV94 vbios
04:08karolherbst: pmoreau: you should either get 0.9V, 0.93V or 1.00V with the NV94
04:08karolherbst: but no clue for the other card
04:21pmoreau: karolherbst: I don't remember uploading the G94 VBIOS... But well :D
04:22karolherbst: could you add the other as well?
04:23pmoreau: G96 and MCP79 should be there
04:23pmoreau: RSpliet has the G94 now, as I sent it to him
04:23pmoreau: And my other cards are still at home, a few 1000kms from here. ;)
04:24karolherbst: then you have to pm me the email you used
04:24karolherbst: because I can't find them
04:37pecisk: karolherbst: as for that core clock getting higher because of switching to 0a first - isn't that because 0f fails due of last two clevels not being valid, in normal case it just fails to set frequency, in 0a case old value stays?
04:39karolherbst: no, the cstates are valid, but the voltages are just too high
04:39karolherbst: it is a bug somewhere in nouveau
05:14pmoreau: RSpliet: Hey! In the "volt: set 900000uv: 0" message, after doing a reclock on my MCP79, is the last 0 a good sign or not?
05:15pmoreau: RSpliet: Cause when using karolherbst's patches, I don't get any voltage displayed, only a N/A. And it calls the same function as nvkm_volt_set, so it should work the same I guess.
05:16karolherbst: pmoreau: my code uses nvkm_volt_get
05:16karolherbst: which calls volt->func->vid_get
05:16karolherbst: but yeah, I should get a voltage there
05:16karolherbst: I mean you
05:16karolherbst: but you do for the other card, and it works for mine too, so I don't think it is wrong to use it
05:16pmoreau: Eh, right!
05:29RSpliet: pmoreau: I don't think on MCP79 the voltage is touched ever
05:29pmoreau: Due to it being integrated?
05:30RSpliet: don't know why that would be a very compelling reason, but I have just stared at endless traces and VBIOSes
05:30RSpliet: without discovering anything ;-)
05:32pmoreau: It does have different voltages in its VBIOS.
05:32pmoreau: But maybe the ones you stared at also had some
05:35karolherbst: pmoreau: it is more important to have GPIOs to set the voltage
05:36karolherbst: pmoreau: gpios with VID_*
05:37karolherbst: RSpliet: do you know how to read the memory voltage out? (sorry if I ask you again, but I don't remember who I asked already :D )
05:37pmoreau: Oh, okay
05:47RSpliet: karolherbst: on kepler it's just looking at the GPIO lines
05:47RSpliet: you're not going to get hard values, but rather "high" or "low
05:47karolherbst: RSpliet: there is only one on my chip
05:47karolherbst: yeah, I figured as much
05:47RSpliet: with kepler I mean tesla
05:47RSpliet: for kepler I assume it's similar, but no experience
05:48karolherbst: I have a MEM_VREF gpio
05:49karolherbst: but I thought you need like 2 GPIOs for that
05:49karolherbst: FBVDDQ select and FBVREF select
05:49karolherbst: but even if I got those, how do I know which voltage this represents? or is there no telling
06:18stikonas: Hi, it looks like I won't be able to test bug https://bugs.freedesktop.org/show_bug.cgi?id=78439 anymore because that screen is now broken... Although, there wasn't much activity in that bug...
06:36imirkin_: stikonas: make a mention of it on the bug
08:01LordShadowWing: Has anyone here had any luck using a GeForce GTX 750 Ti in a fully free system?
08:03imirkin_: it should mostly work
08:06LordShadowWing: I am on Trisquel 7 with Kernel http://www.phoronix.com/scan.php?page=news_item&px=MTc5ODA
08:07LordShadowWing: Stupid copy/paste glitch
08:11imirkin_: LordShadowWing: ok, well that kernel was released several years before the hw in question
08:11pmoreau: LordShadowWing: If you want acceleration on your card, you need kernel 4.1, or at least 3.15 to get support for your card.
08:12imirkin_: oh, i guess not several years. but yeah. you should get 4.1
08:14karolherbst: imirkin_: I think he has to build his own kernel then
08:14karolherbst: seems like Triqsuel has only 3.13-libre
08:15imirkin_: doesn't change the fact that the kernel is super-old
08:15LordShadowWing: I think I'll stick with my GT 220 then
08:15karolherbst: LordShadowWing: why not upgrading kernel?
08:15LordShadowWing: I have no experience at all with compiling the kernel
08:16imirkin_: karolherbst: not everyone is comfortable with doing their own thing. many (most?) people prefer to just use things out of the box without modification
08:16karolherbst: yeah I figure...
08:17karolherbst: but Trisquel is just using debian pacakges afaik
08:17LordShadowWing: If I knew how to compile a kernel, I would
08:17avph: LordShadowWing: you might want to try this kernel: https://jxself.org/linux-libre/
08:17karolherbst: so you could just grab the debian libre kernel and install it
08:18karolherbst: avph: good link
08:18karolherbst: it claims Trisquel compatibility
08:21LordShadowWing: ok, trying now
08:22pmoreau: There is the linux-lowlatency-lts-vivid package in the update repo, which is 3.19, but well, that's still old.
08:23LordShadowWing: Installing 4.2
08:23LordShadowWing: Will reboot with the GT 220, but will try the GTX 750 Ti after successful reboot
08:24pmoreau: You'll probably want to update Mesa as well
08:24pmoreau: iirc, 10.3 should have basic support for the 750 Ti
08:25karolherbst: pmoreau: he wants a libre kernel ;)
08:25LordShadowWing: Gah, cant find a link on a how to for latest mesa
08:26LordShadowWing: unless mesa is somehow nonfree
08:26karolherbst: mhh it depends :D
08:26pmoreau: karolherbst: The linux-lowlatency-lts-vivid should be libre as it is from Trisquel repos
08:26karolherbst: but does patents count?
08:26karolherbst: pmoreau: ohh I see
08:27karolherbst: but with a new mesa, he also needs a new libdrm
08:28LordShadowWing: sucessful reboot
08:28LordShadowWing: I don't think trisquel has libdrm
08:38imirkin_: libdrm is required by all mesa versions, so i'm sure it has libdrm.
08:39karolherbst: libdrm is used by the kernel drm stuff
08:40karolherbst: and all gpus are driven by that
08:40LordShadowWing: 750 Ti is Functional
08:41karolherbst: LordShadowWing: does mesa do anything usefull with it too?
08:41LordShadowWing: no clue, Im not a gamer
08:41karolherbst: and for what do you need that 750 Ti exactly?
08:42LordShadowWing: I was a Gamer on Windows
08:42pecisk: mesa gives him gl 3.3 profile most likely
08:42karolherbst: LordShadowWing: so this is like your left over gpu
08:43karolherbst: allthough I assume a GTX 750 is a lot better for desktop usage than the GT 220
08:43karolherbst: LordShadowWing: does glxinfo print anything usefull?
08:43karolherbst: like nouveau as the driver and not something like llvmpipe
08:44LordShadowWing: I transferred to mobile atm ( quassel is awesome)
08:44pmoreau: He most likely has 10.1, which doesn't support 750 Ti
08:44karlmag: karolherbst: sometimes is "Because I Can" a more than sufficient reason. (Sometimes it also might be silly/stupid, but still.. :-P )
08:45karolherbst: karlmag: :)
08:45LordShadowWing: I will check when I get back to my pc
08:49LordShadowWing: Glxinfo Out https://paste.debian.net/312749/
08:50LordShadowWing: Mesa 10.1
08:50imirkin_: looks like you're using software rendering
08:50LordShadowWing: How to get the latest mesa
08:50imirkin_: maxwell is supported starting with mesa 10.3
08:50imirkin_: and mesa 11.0 was recently released
08:51imirkin_: you should check with your distribution for how to update it
08:51pmoreau: I saw a 10.3 package in the update repo
08:54pmoreau: LordShadowWing: Take your mesa packages name, and add -lts-utopic to get the 10.3 version
08:55LordShadowWing: Nah, Im just gonna compile the latest
09:13LordShadowWing: This may take an hour or so..
09:13LordShadowWing: ooh, done
09:15karolherbst: LordShadowWing: but the latest is 11.0
09:16karolherbst: or let's the more feature rich one
09:16LordShadowWing: I just did sudo make install, How do I force the new mesa version to be used?
09:19LordShadowWing: imirkin_: Any idea on how to force the new mesa version o be used??
09:19imirkin_: LordShadowWing: no idea how you installed it, you should talk to your distro about the proper way of doing this.
09:20imirkin_: we (or at least i) don't do distro support here
09:43LordShadowWing: I can't seem to "make" driproro-2.8 I get the error: make: Nothing to be done for `all'.
09:43imirkin_: is there anything to do? iirc it's just a header file
09:46tobijk: LordShadowWing: just make install it :)
09:46imirkin_: fwiw i'd strongly advise against using something like 'make install' without careful thought about where it's going
09:46tobijk: the same for all the *proto packages imho
09:47LordShadowWing: I can't read code, so that Could be a Huge Probklem
09:49LordShadowWing: Still, its using Mesa 10.1.3
09:50imirkin_: try to find a distro support channel and ask there what the proper way to get non-ancient software on it.
09:50LordShadowWing: I could use parabola, Its an arch based 100% libre distro
09:59avph: LordShadowWing: maybe just install libgl1-mesa-glx-lts-vivid from repo?
14:23RSpliet: shakesoda: did I ever ask you how your reclocking adventure went?
14:24RSpliet: I finally got round testing my tree from 3 weeks ago, seems to work fine
14:53imirkin_: whoa. 128-bit integer atomic add support.
14:54mwk: sounds like overkill
14:59imirkin_: mwk: /*0000*/ @P0 ATOM.ADD.U128 R131, [R64+0x1], R0; /* 0x684000008001020e */
14:59imirkin_: i'm just reading nvdisasm output. this is SM35 btw
14:59qq[IrcCity]: hello. which are reasonable values of hwmon/temp1_max for such passively cooling card as GeForce 8600 GTS?
15:00imirkin_: for when, you know, you want to increment a counter more than 2^64 times during an execution
15:00imirkin_: qq[IrcCity]: if it's passively cooled, doesn't matter
15:00glennk: imirkin_, or count the universe's age in femtoseconds
15:00imirkin_: qq[IrcCity]: but usually like 105C or so is when cards freak out
15:02imirkin_: qq[IrcCity]: note that esp around those generations, there were a lot of solder-related issues, so if it gets too hot for too long, it might unsolder itself a bit
15:03qq[IrcCity]: imirkin_, does some procedure to check for a (possible) hardware damage exist?
15:04imirkin_: qq[IrcCity]: not that i know... but some people have been successful in "fixing" hardware by sticking it into a toaster oven to reflow the solder
15:04imirkin_: obviously apply with care if you choose to go that route ;)
15:05imirkin_: the thing is that it's not like the chip falls off the board, but some of the pin contacts go bad
15:05qq[IrcCity]: can I trust readings of hwmon/temp1_input? temperature of what namely does it report?
15:06imirkin_: i forget exactly which file. but if you run 'sensors' it should get printed out
15:06imirkin_: unless it's an outrageous value, it's usually accurate
15:06imirkin_: sometimes it'll go nuts and print out like 1000 degrees, in which case it's probably safe to assume it's wrong ;)
15:06TheSchaf: my 8800 GTX had red artifacts when it got really hot :D
15:06qq[IrcCity]: is 'sensors' a command in some CLI tool?
15:07imirkin_: qq[IrcCity]: not sure what a "CLI tool" is, but it's a binary installed on many systems as part of the lm-sensors package
15:07imirkin_: which prints various information to stdout
15:08qq[IrcCity]: TheSchaf, I already observerd red and green snow, but removed the box’s conver to increase air outflow, and also it seemingly decreased when I installed Linux 4.3.
15:08TheSchaf: qq[IrcCity]: i just threw out my card at some point :(
15:09TheSchaf: and bought a 660 ti (overclocked) that crashs all the time because apparently they OC'ed it a bit too much
15:09TheSchaf: so i have to clock it down and it is stable -_-
15:11qq[IrcCity]: does the driver provide control over clock frequency?
15:11TheSchaf: no, on windows i use afterburner
15:22imirkin_: mwk: any idea what "safeadd" is? is that like without rollover or something?
15:31RSpliet: pmoreau: your G94 performs like the fire brigade ( ;-) )
15:32imirkin_: meaning what? loudly?
15:33RSpliet: yes, loudly is exactly what I meant
15:34imirkin_: skeggsb: do you happen to have your GK208 scan handy? i'm looking for RED.*
15:38imirkin_: nm, redoing the scan myself
15:44qq[IrcCity]: imirkin_: heating a video card can damage capacitors. and I haven’t pretext to do it, anyway.
15:54imirkin_: mwk: weird... SM35 only ever wants to CAS adjacent registers. do you remember seeing that for sm20/sm30?
15:54imirkin_: (there's an option to flip either or both to RZ as well, isntead of adjacent regs)
15:58imirkin_: urgh. and naturally if you flip the first arg to RZ, then the second one gets the original value.
15:58imirkin_: which means i get to make one big happy table
16:40AndrewR: hello all. can anyone tell me if current piglit/bin/glean -t fbo should fail noisely on nv92 ?
16:41imirkin_: AndrewR: http://people.freedesktop.org/~imirkin/nv50-comparison/problems.html
16:41imirkin_: looks like yes
16:41imirkin_: well, maybe not noisily, but definitely looks like it fails
16:44AndrewR: imirkin_, hm, ok ..but some time ago I was able to play UT (UnrealTournament) on wine (1.6.0 - so, buggy) with its efault setting (using fbo ). Now I only can play with 'backbuffer' rendering mode (updating wine not helped). So, I updated piglit, but not sure if it will make things easier - I completely forgot the point when it was working :(
16:44imirkin_: AndrewR: fbo's work in general... that glean test is just doing something funky
16:45imirkin_: AndrewR: i've also pushed a bunch of fixes for nv50... they should all be in Mesa 11.0, although some are probably in 10.6.x releases as well
16:46AndrewR: imirkin_, may be wine does it too ...because now I can hear game's sound, but screen looks like frozen with last image from my desktop. Tried to kill compositing, or run in windowd mode ...it fails. But for example 3dmark2011se works ....
16:46imirkin_: AndrewR: very odd
16:46imirkin_: AndrewR: perhaps i broke something
16:46imirkin_: AndrewR: unlikely to be directly related to fbo's though... there is no non-fbo support
16:47AndrewR: imirkin_, OpenGL version string: 3.0 Mesa 11.1.0-devel (git-8f6fd57) - this is what I have currently
16:47imirkin_: AndrewR: do you see any errors, either on the console or in dmesg?
16:48AndrewR: imirkin_, not in dmesg, on console just usual for this game errs/warns. Even more odd - even llvmpipe having troubles, apparently! (not tried old swrast)
16:49AndrewR: *3dmark2001se, not 2011 :}
16:59AndrewR: imirkin_, ah, I was running glean without --quick option, so failure was longer.. in # of lines printed to terminal
16:59imirkin_: yeah, glean's a crazy test
17:02karolherbst: how common is it to have low perf tesla cards without any VID GPIOs?
17:04karolherbst: ohh seems to be very common
17:05karolherbst: which is somehow strange? don't know
17:07imirkin_: oh wow. this is very clever.
17:08imirkin_: instead of each thread doing the atomic add
17:08imirkin_: instead it counts up how many threads are running, and makes only the very first thread perform the atomic op
17:08imirkin_: (and adds N times as many things)
17:13mupuf: imirkin_: nice :)
17:14imirkin_: well... the blob is doing this
17:14imirkin_: not me :)
17:14imirkin_: for nouveau it'll have to wait for the registered version
17:14karolherbst: mupuf: ohh we need a newer kernel on reator, all 4.2-rc have a symbol exporting issue and the blob won't compile :)
17:14mupuf: karolherbst: will update tomorrow
17:15karolherbst: thanks a lot :)
17:15mupuf: I am on my way back to Finland
17:15karolherbst: saw my comment about pwm voltages above "max"?
17:15mupuf: I thanked you in the nouveau talk for your work on reclocking
17:15mupuf: yes, I think this is nuts :D
17:15karolherbst: I saw it
17:15mupuf: nuts as in, it does not make sense :D
17:15karolherbst: why not?
17:15karolherbst: values below doesn't work
17:15mupuf: how could the duty be over freq?
17:16karolherbst: how should I now? :D
17:16karolherbst: but it works
17:16karolherbst: but for this I wanted to test the blob
17:16mupuf: what does the blob do?
17:16karolherbst: guess why I want a newer kernel :D
17:16karolherbst: anyway, nouveau clocks too high
17:16mupuf: yes, the rounding errors are problematic
17:16karolherbst: significantly too high
17:17mupuf: Would be nice to see how the blob computes everything
17:17karolherbst: but this "max" voltage issue is also problemativ somewhere else
17:17karolherbst: we really need to tackle this
17:17karolherbst: seems to be an issue all over the place
17:18karolherbst: allthough I never saw a Tesla card with voltage problems
17:18karolherbst: but it may be, that there are fermi cards which could trigger the same issue
17:18karolherbst: mupuf: but I was a bit suprised to get mentioned before anyway laned in the kernel :D
17:19karolherbst: didn't saw the talk though, only the pdf
17:21karolherbst: mupuf: ohh maybe the div isn't a div, but more like setting the size of the steps?
17:21mupuf: well, you have been active and worked on reclocking. Your code may not always be ready but you definitely did merge code in envytools and found some improvements to be made
17:21karolherbst: ohh okay
17:21mupuf: you'll get there eventually!
17:21mupuf: and you deserved the shout out :)
17:22karolherbst: I see
17:22karolherbst: I also got a phoronix article somehow, so maybe its fine :D
17:22mupuf: as for the PWM controller, you really need to take the time to understand the hw behind it
17:22mupuf: DIV should be called PERIOD though
17:23imirkin_: skeggsb: are you sure this is right? warp = nvkm_enum_find(gf100_mp_warp_error, werr & 0xffff);
17:23karolherbst: I know how pwm work, I am just saying, that the value doesn't need to be the thing we think it has to be, even if it kind of makes sense
17:23imirkin_: skeggsb: errrr... nevermind.
17:23karolherbst: it just means we lack some information, so it doesn't make sense anymore
17:23imirkin_: it's fine.
17:24karolherbst: if you lack enough information, everything makes sense :)
17:24mupuf: karolherbst: yep, but remember, extraordinary claims require extraordinary proofs :p
17:24karolherbst: yeah I get that :)
17:24mupuf: maybe the blob never uses these csteps
17:24karolherbst: yeah, I think that too
17:25mupuf: or simply never wants to get anywhere near those voltages
17:25karolherbst: maybe this is "outside" the safe domain, but when I overcklock it gets totally off the cstates
17:25mupuf: I never saw the blob getting close to the maximum voltage
17:25karolherbst: mupuf: downclock
17:25karolherbst: then it does
17:25karolherbst: it gets over them, too
17:25mupuf: downclocking increases the voltage?
17:25mupuf: this is nuts
17:25karolherbst: I think since kepler there is no "static clocking" anymore
17:25karolherbst: you only adjust the max clock
17:26mupuf: not sure what you mean by static clocking
17:26karolherbst: for exmaple my gpu: 0x3e PWM @ 862MHz (max: 862MHz +0 set in nvidia-settings)
17:26mupuf: kepler introduced finer steps between pstates, for the core clock
17:27karolherbst: but 0x3e PWM @ 727MHz (max: 862MHz -135 set in nvidia-settings)
17:27karolherbst: now some magic
17:27karolherbst: 0x3d PWM @ 862MHz (max:862MHz + 15)
17:28karolherbst: the higher I set the "max clock" the lower the pwm value gets at 862MHz
17:28karolherbst: usually -1 for every 15MHz
17:28mupuf: Ok, I would not trust their GUI
17:28karolherbst: I read the reg out
17:28karolherbst: and checked clock with your tool
17:28mupuf: you need to run the modified version of nouveau and check
17:28mupuf: and it does the same thing?
17:28karolherbst: yeah I did that
17:29karolherbst: as I told you. when max clock gets higher, pwm value decreases for a specific clock
17:29karolherbst: that's what I saw
17:30mupuf: ok, so please log the data in one graph with all the clocks and clock it
17:30karolherbst: will do at full load first, because it is easier to do so :D
17:30mupuf: and see if there are any other differences between the two values
17:31karolherbst: you will totally get what I mean :)
17:31mupuf: this may indicate that we need to set the voltage based on the highest clock in all the domains
17:31karolherbst: it's pretty reliable what happens
17:31karolherbst: mupuf: you know this table? https://gist.github.com/karolherbst/397ce9495d9986336211
17:32mupuf: very good, being able to reproduce consistently is the first thing to do. The second is, acquire data and infer :p
17:32karolherbst: I can explain how the blob does it
17:32mupuf: I want to see every clock domain
17:32mupuf: not just this one
17:32karolherbst: when max offset is set to 0, it uses 48-52 PWM value for 731
17:33karolherbst: when max clock is lowered by one step, it uses 49-52 and so on
17:33karolherbst: until max clock is set to 731, and uses 61-64
17:33mupuf: the thing is that this max clock does not relate to anything in the vbios
17:33karolherbst: I know
17:33karolherbst: this is coolbits stuff
17:33mupuf: so, this seems like an entirely-made-up concept
17:33mupuf: and I am very suspicious about it
17:34karolherbst: but I can trace it with your pwr_read tool ;)
17:34karolherbst: you will see
17:34mupuf: please do, have to go
17:36karolherbst: ohh already done, but not plotted :D
17:36karolherbst: I should plot it
17:42karolherbst: mupuf: http://www.plotshare.com/sessions/202135770/Plot2.png
17:42karolherbst: gpu full load, I merely adjusted the max clock in the gui
17:50karolherbst: this is at constant clock while adjusting max clock: http://www.plotshare.com/sessions/662564845/Plot2.png
18:03imirkin_: gnurou: any chance i could get you to look up warp error 0x10 for me? (0xe == mem out of bounds... error is in mp register 0x48)
19:00AndrewR: imirkin_, on my weird wine/UT bug - it works ok with mesa 10.5.9 (w/o gallium), but 10.6.8 and ~master fail ...
19:00imirkin_: what do you mean by "without gallium"?
19:00imirkin_: there is no non-gallium nouveau driver for your G92 gpu
19:00AndrewR: imirkin_, pardon, without llvm!
19:01imirkin_: oh. llvm shouldn't change anything for nouveau
19:01imirkin_: if you could bisect to identify the guilty change, that'd be most useful
19:02imirkin_:places bet on OP_MAD change
19:07AndrewR: imirkin_, it will be long road
19:07imirkin_: distcc if you have any fast boxes on the local network
20:32AndrewR: imirkin_, not your fault: 504903b827604f1a630a335d14231f88c2cf36be is the first bad commit ( st/mesa: don't call st_validate_state in BlitFramebuffer)
20:42imirkin: AndrewR: oh... hm
20:42imirkin: AndrewR: i was afraid that one would mess things up
20:42imirkin: AndrewR: can you make an apitrace and file a bug? perhaps marek can fix it
20:42imirkin: and/or at least repro it on radeonsi