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