01:15imirkin: huh, apparently operator precedence matters.
01:17imirkin: gnurou: try again when you get a chance
01:17imirkin: no idea if i fixed the thing affecting you, but i did fix a pretty big oopsie
01:20feliksk: attempting the fan controll setting mentioned in the arch linux wiki about nouveau
01:20feliksk: so far hasn't done anything, i might try the MANUAL mode and set it to 0 but i dont know how to set it to manual
01:21imirkin: read that thermal doc i pointed you at
01:21imirkin: it describes everything
01:22imirkin: mupuf: worth adding a config parameter to make the fan default to "no touch" vs "auto"?
01:22imirkin: and/or skeggsb --^
01:22imirkin: there are a bunch of GF108's for which we can't properly control the fan
01:22imirkin: and same for at least my GK208 i believe
01:27feliksk: yes! i can control the fan
01:27feliksk: now all im scared about is overheating the card as it warns me
01:28feliksk: my pwm1_min was set to 60, which is pretty loud (compared to 3.10.17 kernel)
01:28feliksk: i changed pwm1_min to 0 and pwm1 to 0 and the fan turned off
01:28imirkin: chances are the fan isn't controllable below 30
01:28imirkin: 60 seems a little high
01:28feliksk: ok so the value was basically 30 then
01:28imirkin: anyways, you can use the auto setting
01:28imirkin: but just change the min
01:28imirkin: and/or adjust the ramps (they should be exposed too i think?)
01:29feliksk: echoing 30 to pwm1_min makes the card loud again
01:29feliksk: but 0 makes it quiet
01:29feliksk: i think
01:31imirkin: huh ok
01:31imirkin: so you probably have one of the cards we control wrong
01:31imirkin: try echoing 100
01:31imirkin: does that make it quiet by any chance?
01:31imirkin: i don't remember the exact dysfunction...
01:31feliksk: to what file, pwm1?
01:32imirkin: (in manual mode)
01:32feliksk: my pwm1_max is set to 97, echoing 100 to pwm1 (while in manual) doesn't seem to change anything
01:32imirkin: oh, well try 97
01:32feliksk: seems my pwm1 was capped to 97, should i change pwm1_max to 100?
01:33imirkin: the range comes from the vbios
01:33imirkin: most pwm's can't handle arbitrary duty cycles
01:33feliksk: nope setting to 97, it's still loud
01:33feliksk: enabling auto fan control and setting pwm1_min to 0 makes it quiet
01:34imirkin: that probably just turns it off though
01:34feliksk: im currently using 4.4.19-smp kernel, i could check what the default pwm values are on a 3.10.something kernel
01:34imirkin: you probably have one of the ones where we totally fail to control the fan
01:34imirkin: 3.10 didn't flip it to auto control by default
01:34imirkin: 3.10 left the bios-installed PMU on the board which iirc generally does an ok job of managing the fan speed
01:35imirkin: i think in like 3.13 or so we flipped to using nouveau code by default and iirc there's no way to turn that off
01:36feliksk: so there is no way to get back 3.10 fan control in the 4.x kernels?
01:36imirkin: not without applying a patch
01:37imirkin: mupuf should be able to tell you exactly where a change needs to be made
01:37imirkin: i don't know offhand
01:37feliksk: if i were to apply i patch i would need to download the nouveau driver source for my specific kernel (since it relies on functon calls that belong to that kernel), right?
01:38imirkin: no, you'd apply a short patch to your kernel.
01:38imirkin: to your kernel source, that is
01:38imirkin: (nouveau is part of the kernel)
01:38imirkin: (at least that bit that controls the fan)
01:43Riastradh: imirkin: I'm vanishing in a moment, but let me know if your NetBSD friend has any more questions about the new page (or feel free to direct your NetBSD friend to me).
01:43feliksk: ok, so disabling fan control is dangerous for my card, so i should just wait until someone gives me a patch?
01:43imirkin: Riastradh: he hasn't looked at it yet
01:44imirkin: Riastradh: i think he will over the weekend
01:44imirkin: feliksk: well, it's highly unlikely your card will self-destruct. however it may enter an emergency mode and effectively shut down your box.
01:57feliksk: if you wanted to know, the pwm1_min and pwm1_max values are the same when running kernel 3.10.17-smp, it's just that pwm1_enable is set to 0 by default
01:57feliksk: (pwm1_min is 65, pwm1_max is 97)
02:08imirkin: airlied: i dunno where your geom-fail thing comes from, but it triggers some *weird* corner case. still can't quite figure it out.
02:11airlied: imirkin: what's this btw? https://people.freedesktop.org/~airlied/piglit/si-nv-cts/cts_gl45/gl45-cts@firstname.lastname@example.org
02:12imirkin: airlied: "disappointing"
02:12imirkin: basically RA failure
02:54imirkin: skeggsb: SHADER 90000100, sph: 0x000100, stage: 0x10
02:54imirkin: skeggsb: would you say stage is frag?
02:54imirkin: or is it geom?
03:01feliksk: not really a problem but annoying, i made a /etc/udev/rules.d/50-nouveau-hwmon.rules file, i set pwm1_min to 0 and when i boot up, the fan turns on and after a few seconds it turns off
03:02feliksk: is there a way to make it so that it doesn't turn the fan on at all? is there a kernel parameter i could pass or something?
03:07feliksk: ok well i found out that the fan turns on and off when running like that anyway, i will just use nomodeset for now
03:07feliksk: thanks for your help
03:08feliksk: should i just stay on the IRC and wait for a patch? or i dont know
03:23airlied: imirkin: http://paste.fedoraproject.org/455971/47693377/ is the debug from that test
03:30imirkin: airlied: heh, that RA's for me, but i think coz i have a local patch
03:31imirkin: airlied: try applying this: http://hastebin.com/idecomukas.php
03:31imirkin: actually i guess i should revert it and see if i still get the fail
03:32imirkin: yep. that's it :)
03:32imirkin: obviously not a real fix
03:32imirkin: but ... real enough
03:33airlied: imirkin: tests still fails, but not the same failing
03:33airlied: is WARNING: value %d not uniquely defined from nouveau?
03:33imirkin: can't win 'em all
03:33airlied: if so I now have a bunch of those
03:33imirkin: yeah. those aren't *entirely* bad
03:33imirkin: i have a bunch of those too
04:20orbea: im having an intersting segfault/regression in the libretro port of reicast (Dreamcast emulator), the problem is that is only seems to occur with nouveau. I could not reproduce it with intel or the llvmpipe. I found the code bit of code that was causing problems, but I'm not really sure why. Backtrace: http://pastebin.com/UrE9Smsc Bad commit in reicast:
04:20orbea: https://github.com/libretro/reicast-emulator/commit/3b36f7c6aeab23d1e8a6240decc708c203003faf github issue: https://github.com/libretro/reicast-emulator/issues/35
04:21imirkin: ooooh, soul calibur. good times.
04:21orbea: yea, its still fun
04:22imirkin: is there a non-jit backend you can switch to?
04:22imirkin: or, better idea
04:22imirkin: make an apitrace
04:22orbea: sure, let me try both
04:22imirkin: and then replay it with valgrind
04:23imirkin: basically the crash is in not-nouveau
04:23orbea: reicast is in a really messy state and it probabl something there
04:23imirkin: so that suggests that nouveau stomps over something (or something stomps over nouveau)
04:23imirkin: normally emulator + valgrind = fail
04:25imirkin: orbea: are you running this with a core context, or not?
04:25imirkin: i.e. is the #ifdef CORE thing on?
04:25orbea: i think its a core context
04:26orbea: it doesn't black screen and should use some opengl 4.*
04:26imirkin: anyways ... i guess i'm not sure offhand what the issue is
04:26orbea: i'll add more info with the apitrace in a little bit
04:26imirkin: it's entirely possible it's an issue in nouveau
04:27orbea: i think twinaphex is willing to fix it, but he has an intel gpu and ofc cant reproduce it...
04:28imirkin: it's odd that they do glBindVertexArray(gl_state.vao); *before* all the glVertexAttribPointer calls
04:28imirkin: but i'm a bit weak on VAO's & co
04:29imirkin: try moving that up to the top of the function
04:29orbea: the story is the original reicast dev did a half assed job and then abandoned it when he realized no one was going to pay him anything....kind of left other people to clean it up...
04:30ystreet00: vao's need to be bound before vertexattrib (otherwise they don't affect anything)
04:30imirkin: orbea: sklm or whatever that guy's handle was?
04:30ystreet00: and in core you need a vao to be able to vertexattrib
04:30imirkin: definitely an s and k somewhere in there
04:31orbea: imirkin: yea, something liek that
04:33orbea: apitrace - http://ks392457.kimsufi.com/orbea/stuff/trace/libretro/reicast_crash.trace.xz valgring log output - http://pastebin.com/hmRRCFsf
04:34imirkin: orbea: ok, so no access errors
04:35orbea: crashes with without the generic jit, but that is on by default, so Im not sure how useful reciast is / was without it
04:35imirkin: what if you move the glBindVertexArray to the top of the function?
04:44orbea: If I did it rightthat didn't really work.
04:48orbea: twinaphex the one who has been working most on this core lately is probably asleep now, might have to wait several hours for him to reply.
04:52imirkin: i'll be asleep by then
04:53orbea: no worries, thanks for the advice so far
05:01imirkin: the main repo still has a bunch of activity
05:01imirkin: but i can't get it to run DOA2 =/
05:02orbea: i haven't heard of anyone getting it to work as far as slackware is concerned
05:02imirkin: a diff game works
05:05orbea: i guess he is awake now
05:06imirkin: or talks in his sleep :)
08:10gnurou: imirkin: looks like your branch update fixed it! gm206 using the Nouveau DDX, fonts are readable
08:11gnurou:checked Xorg.log to make sure, yep, that looks good
08:13mupuf: gnurou: yeah! I will check it out tonight
08:41hakzsam: imirkin: I could test on my gm107 as well, but if gnurou and mupuf say "it works", I think it's all good :)
09:03mupuf: hakzsam: try it on your gm107, it never hurts
09:03mupuf: and that will save me from trying two different GPUs
10:41sa: i want to downclock gf9600 to remove the cooler from it
10:41sa: is there a way to do this in nouveau? i've read modinfo nouveau and man nouveau(4), nothing appropriate
10:51mupuf: sa: sounds like a bad idea, given that our power management is so bad on tesla
10:53sa: what a pity
10:57sa: but if it's technically possible, i would try, let it burn
11:59karolherbst: sa: those gpus are usually quite hot
12:00karolherbst: also, chances are that you can't really control the voltage significantly, so the benefit is quite low
12:01sa: sorry i want the answer on the original question.
12:43karolherbst: sa: https://nouveau.freedesktop.org/wiki/KernelModuleParameters/
12:54sa: karolherbst, thank you.
12:58karolherbst: imirkin: just looked at the constant VS output patch, the changes are massive
12:59karolherbst: imirkin: I also have SR2 and SR3, also DX9 eon ports
12:59karolherbst: and performance is _bad_, real bad
12:59karolherbst: that might be a good reason
13:01sa: doesn NvClkMode* accept only those values listed in /sys/kernel/debug/dri/*/pstate? i have only 0f and AC there, both with too fast values
13:01karolherbst: sa: right, so you can't
13:01karolherbst: mind uploading your vbios.rom somewhere?
13:01karolherbst: maybe there are low clocks
13:01karolherbst: but chances are quite low
13:02sa: ok, i'll search how to obtain vbios.rom now
13:02karolherbst: starting with Fermi the situation improved, but everything before that, which is a desktop gpu, had only one clock state
13:02karolherbst: sa: look where the pstate file is
13:02karolherbst: imirkin: if you don't mind, I would look into how to implement this thing for nvc0, cause I also would have the motivation for this :D
13:04sa: karolherbst, http://184.108.40.206/tmp/vbios.rom
13:07karolherbst: sa: mhh, on your gpu we could indeed change the voltage, but mhh, it doesn't seem to have any other clock states
13:08karolherbst: sa: mind checking if nvidia changes the clocks?
13:09sa: let me look into it
13:23sa: karolherbst, i've restarted with config=NvClkMode=173,NvClkModeAC=173,NvClkModeDC=173
13:23sa: how can i know something changed?
13:23sa: pstate has the same content
13:24sa: and seems like nothing new in dmesg
13:24karolherbst: nothing changed
13:24karolherbst: you can't just set custom clocks, that won't work
13:24karolherbst: if the voltage stays the same, clocks won't matter at idle
13:24karolherbst: so your minimal power consumption doesn't change
13:25sa: so i can't change voltage too?
13:25karolherbst: you have to check what nvidia does
13:25karolherbst: no clue?
13:25karolherbst: currently depending on what we know, no
13:25karolherbst: maybe nvidia does something we don't know yet
13:26sa: seems like no chance for me. ok, thank you for explanation
13:27karolherbst: why can't you test with nvidia?
13:27sa: you mean proprietary driver?
13:27karolherbst: if they do lower the clocks
13:27karolherbst: and the gpu is significantly cooler
13:28karolherbst: we might be able to also reduce power consumption
13:28sa: even if i install it, i have no clue where to look
13:28sa: but maybe i'll try
13:29sa: later today
14:34mupuf: imirkin_: is your branch up to date?
14:39mupuf: imirkin_: your new branch segfaults for me
14:41mupuf: https://paste.pound-python.org/show/0rVvYCkiJ2fhnZ7IVKFB/ here you go
14:41pmoreau: So, the new Nintento Switch uses a custom Tegra processor. Are they going to use Nouveau on it? O:-D
14:42mupuf: pmoreau: ahah
15:06imirkin: mupuf: [ 591.694] (EE) NOUVEAU(0): [COPY] failed to allocate class.
15:09imirkin: mupuf: looks like the segfault is caused by something in xorg. perhaps we stomp on something.
16:07imirkin_: mupuf: try with AutoAddGPU false
16:07imirkin_: mupuf: i'll try to figure out wtf is up with the close function. i've only ever killed the X server, so it hasn't come up :)
16:08imirkin_: mupuf: although the fact that the copy channel doesn't allocate seems bad
16:08imirkin_: skeggsb: can you think of a reason why b0b5 wouldn't create properly on a GM206?
16:20orbea: karolherbst: what branch should I use for reclocking with linux 4.7.9? stable_reclocking_kepler_v6 no longer builds.
16:33orbea: I guess master_4.7 builds, is that the right one?
16:33imirkin_: i think the master_* branches on karol's tree are just what's upstream for that version.
16:36orbea: yea, I thought that too, but stuff apparently got changed around so I'm not sure.
16:40imirkin_: karolherbst: fyi i did the SLCT -> SET thing last night. still need to test it out.
17:04karolherbst: orbea: I rebased on 4.8
17:04karolherbst: but the master is fine too
17:07orbea: ah, i made the guess that you rebased it for 4.8 and started compiling that. I'm hoping the new version of my ethernet driver will build for that :P
17:07imirkin_: you have an ethernet card not supported by upstream?
17:08imirkin_: or is it some dumb wifi thing
17:08karolherbst: r8169 or so I guess
17:08orbea: yea, r8618, kernel only has r8619 which does not work
17:08karolherbst: orbea: r8169 should be fixed then ;)
17:08karolherbst: r8168 has other problems
17:08orbea: i guess I can complain to them then :P
17:09karolherbst: anyway, gotta go
19:59mupuf: imirkin_: the segfault happened when running glxinfo
19:59mupuf: so it is not while closing it
19:59mupuf: I can try tomorrow morning
20:00mupuf: samuel is using reator now
20:00imirkin_: mupuf: hmmmm ok
20:00imirkin_: i definitely tested glxgears at one point or another
20:00imirkin_: mupuf: either way, one big issue is that the copy engine channel isn't being properly set
20:01mupuf: I am using linux 4.7 with linux 4.8 nouveau code, IIRC
20:12manio: hi guys, i have the following errors in dmesg: nouveau 0000:02:00.0: fail set_domain; validating bo list; validate: -22
20:13manio: it is after setting "xrandr --setprovideroutputsource 2 0" and enabling output
20:13manio: my providers: http://pastebin.com/kjN0hLDW
20:13manio: any tips? :)
20:14manio: it is dual geforce configuration, one card is working ok while the second has the above errors and black screen
20:14imirkin_: are you using libdrm 2.4.60?
20:14imirkin_: and/or are you using an older kernel?
20:14manio: linux 4.7.6-1
20:15manio: libdrm 2.4.71-1
20:15imirkin_: alright... i got nothin' then
20:15imirkin_: pastebin xorg log?
20:18manio: don't look at the final backtrace, it was probably because i killed xserver at the end
20:19imirkin_: so you actually have 3 gpu's
20:19imirkin_: the main one, the intel skylake-based one
20:20imirkin_: is the one running the screen
20:20imirkin_: or rather
20:20imirkin_: the one doing rendering
20:20imirkin_: and the 2 NV cards are just display slaves
20:20manio: and the geforce gt220 is doing it ok, while the 6200 le has problems
20:21imirkin_: yeah, i'm not surprised
20:21manio: the displays are turning on but the screen is black
20:21imirkin_: i doubt pre-NV50 can do reverse-prime properly.... not sure.
20:21imirkin_: skeggsb would know for sure
20:22imirkin_: not sure if he's around... it's early in AU
20:22manio: skeggsb: ^^^^^ please look and let us know :)
20:23manio: imirkin_: much thanks for the info...
21:12karolherbst: mupuf: mind putting the gm107 into reator before saturday? I plan to look into the power budget this weekend
21:17imirkin_: karolherbst: i have a gm107 plugged in on my box, let me know if there are simple things you want me to check (with nva tools, not blob)
21:17karolherbst: imirkin_: well I planned to RE the power budget table
21:18karolherbst: imirkin_: does your gm107 have a power sensor?
21:19karolherbst: mupuf: does your gm107 have one? ...
21:19karolherbst: doesn't seem that way :(
21:20karolherbst: mupuf: :O !!!
21:20karolherbst: I have to check that, but what if the power_rails actually describe the method to calculate the power consumption if there is no sensor...
21:23karolherbst: hakzsam: can you tell me what is currently plugged in?
21:23imirkin_: karolherbst: i don't think so, but not 100% sure.
21:23karolherbst: imirkin_: mind checking if nvidia-smi displays any power consumption?
21:24imirkin_: karolherbst: https://people.freedesktop.org/~imirkin/traces/gm107-vbios.rom
21:24imirkin_: (a) i'm not in front of the machine and (b) i'm not going to load nvidia
21:27karolherbst: crap, I actually need a gm107 or gm108 with a power sensor :(
21:28imirkin_: i could imagine mupuf's would - his is a GTX 750 or 750 Ti
21:28karolherbst: doing that stuff on kepler is actually pretty much anoying, except you have an overpriced titan or quadro
21:28imirkin_: mine is a GTX 745
21:28karolherbst: nope, his doesn't
21:28karolherbst: but the titan has :D
21:28imirkin_: titan's a GM200 though
21:29karolherbst: mupuf: change of plans, need the titan again
21:29karolherbst: imirkin_: kepler titan
21:29imirkin_: (or you mean the GK110)
21:29karolherbst: yes, I do
21:29karolherbst: 355W power budget if I follow my last theory
21:30karolherbst: wiki only lists 250W though
21:30karolherbst: ohh wait, wrong
21:30karolherbst: I added the wrong entries
21:31karolherbst: uhh mupufs titan looks fun: https://gist.github.com/karolherbst/1e81bd12e13b947ddeb3a990633da237
21:32karolherbst: uhm, that's his gm206
21:32karolherbst: it would be so awesome to understand this table
21:34karolherbst: uhh, the gm206 has a new version, fun
21:37s0be: karolherbst, I have a gm107, how do I know if it has a power sensor?
21:37karolherbst: check the vbios
21:37karolherbst: or nouveau
21:37karolherbst: nouveau will tell you in sensors
21:37imirkin_: [with a new enough nouveau]
21:38s0be: GPU core: +0.60 V (min = +0.60 V, max = +1.20 V)
21:38s0be: that ?
21:38karolherbst: power, not voltage
21:38imirkin_: like that, but with Current: 100A
21:38imirkin_: [if you're in deep trouble]
21:38s0be: ahh, nope, doesn't look like it
21:38karolherbst: more like W though
21:38imirkin_: oh, yeah. sad.
21:39karolherbst: why sad?
21:39imirkin_: i like A
21:39karolherbst: sure, but the INAs are just configured to give us the shunt and the other voltage
21:39imirkin_: and yes. power, not current. so i'm the idiot.
21:39s0be: assuming 4.8 is new enough
21:39karolherbst: it is
21:39karolherbst: first support was added in 4.6 actually
21:39karolherbst: or so
21:40karolherbst: the kernel hwmon 3221 driver only exports the current though
21:42karolherbst: uhh, I see
21:42karolherbst: well, it won't help anyway
21:44s0be: NVIDIA Corporation GM107GLM [Quadro M2000M] is the card I have, if that helps at all
21:44s0be: feel free to poke me for any testing needed
21:44s0be: or blob dump captures
21:45karolherbst: get current master and ramp up your clocks to max
21:45karolherbst: all the testing I need
21:48s0be: what's the sysfs node to ticklet to bump freq?
21:48karolherbst: there ain't one
21:48karolherbst: it is in debugfs
21:48s0be: ahh, k
21:49imirkin_: s0be: release linux kernels won't change memory clocks on GM10x though
21:49imirkin_: s0be: you need skeggsb's tree (or one of karol's) to get that functionality
21:49imirkin_: karolherbst: btw, my GM107 has DDR3 vram. will be an interesting test-case.
21:49s0be: I pulled that in already
21:50s0be: echo'd 0f to pstate and it 'updated'
21:50s0be: had to have something spin up the gpu, it blocked while the gpu was offline
21:51karolherbst: imirkin_: yeah, just that it doesn't really matter
21:51karolherbst: s0be: right, it blocks currently
21:51karolherbst: s0be: you need to put some load on it though
21:51s0be: yeah, dri_prime'd glxgears
21:51karolherbst: but I somehow fear that this one might hang after a while
21:52karolherbst: if you want, you could try pixmark piano from gputest
21:52s0be: will grab it and give it a shot.
21:54s0be: fullscreen or window'd?
21:55s0be: stress test or benchmark?
21:55karolherbst: doesn't matter
21:55karolherbst: there is a script to run it in the window though
21:55karolherbst: never actually used anything gui thing
21:55karolherbst: cause the gui thing is pretty much broken
21:56s0be: yeah, gui was throwing llvm errors trying to launch
21:56s0be: damn, same trying to run the script
21:56karolherbst: are you really using nouveau though?
21:56karolherbst: glxinfo pls :p
21:57s0be: full glxifo, or just Vendor?
21:57karolherbst: check if it is using nouveau
21:57s0be: yeah, I launched using DRI_PRIME=1
21:58karolherbst: what kind of llvm error?
21:58s0be: CommandLine Error: Option 'asan-instrument-assembly' registered more than once!
22:00karolherbst: uhm, no clue
22:00s0be: yeah, looks like a toolchain issue on my box
22:00karolherbst: it tries to use opencl though
22:00s0be: ahh, opencl is actually screwed up on my box, I know that for a fact from playing with opencv
22:01karolherbst: mind removing opencl for now?
22:01s0be: nope, 1 sec
22:07karolherbst: s0be: so, your gpu already burning now?
22:10s0be: nah, still battling the llvm entry point issue
22:10karolherbst: I see
22:10karolherbst: have to sleep anyway
22:10s0be: sleep well.
22:10s0be: gpu is up to 58C, same as CPU right now
22:10imirkin_: the double command-line option thing happens when you try to static-link llvm iirc
22:11s0be: I have android building right now, so all in all, it's 'not bad' as far as temperature goes
22:15s0be: worked when I ran it as root. Will see how long before the computer crashes.
22:16s0be: (after getting rid of the opencl_x64.so, however)
22:20s0be: only seems to work against the skylake gpu. Will futz with llvm to fix the dbl command line issue then get this to work