07:27RSpliet: inglor: pong
07:52mupuf_: imirkin_: Hey, I plugged a nv50/g86, if you want to get some glxinfo stats and/or run piglit
07:55inglor: RSpliet: hi I'm off to work but I'll try login from there.
07:55RSpliet: inglor: no worries. Read your e-mail,
07:55RSpliet: I'm currently away for summer school, so not very interactive
07:56inglor: RSpliet: if you want to redirect me to another person who would be interested and it's not involving transatlantic posting let me know
08:18karolherbst_work: mupuf_: any ideas how the situation would be if you would got a used GTX 690?
08:18unnew: under kernel 4.6 with nouveau, when kms is enabled, it just "switches off" my monitor and i'm left there
08:18karolherbst_work: regarding import taxes or something. Allthough know it should be fine for UK to you, right?
08:19unnew: if i put "nomodeset" then the screen stays on, but of course of course won't use nouveau then, i'm left with "vesa" driver
08:19karolherbst_work: unnew: dmesg and does it happen when X starts or before?
08:19unnew: karolherbst_work: before, if i boot in single user mode i have the same issue
08:20unnew: dmesg is hard to do since my screen is off so i can't save dmesg :)
08:25mupuf_: 690 == nve4, right?
08:25mupuf_: I do not have one
08:25gis: hi, I've got an NV110 based graphics adapter (Lenovo P50) and I have huge performance problems with editing text in eclipse
08:28gis: this is on latest debian unstable. I have another (older) notebook with a difference nvidia card and have no such problems there
08:28karolherbst_work: mupuf_: yeah, but if we assume somebody would send you one
08:29karolherbst_work: mupuf_: though UK is still inside the UK, so there shouldn't be any fees, right?
08:29karolherbst_work: *inside EU
08:33mupuf_: yeah, no fees
08:33karolherbst_work: inglor: okay, back to the original plan, mupuf_ will gladly take it :p
08:35karolherbst_work: mupuf_: the 690 has a TDP of 300W, but I hope that's fine for you, anyway, this card will be a good think for working on SLI
08:35mupuf_: oh, right! SLI
08:36mupuf_: Well, 300W Is stil lfine
08:36karolherbst_work: mupuf_: inglor is the lucky guy who got 2x 690 for free
08:36mupuf_: wait, what? :D
08:36mupuf_: inglor: how did this happen? :D
08:36karolherbst_work: yeah, his rig can't handle two, soo
08:39karolherbst_work: mupuf_: log: https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=nouveau&date=2016-06-06
08:40karolherbst_work: ohh mhh, maybe he didn't said it there .D
08:41karolherbst_work: thing is, he decided to give up on one and thought it may be a good idea if we would get it to work on SLI support
08:45mupuf_: SLI is probably the lowest thing on the priority list
08:46mupuf_: it is complex, poor performance benefit and one GPU can be made to perform twice as fast ... for everyone's benefit
08:46karolherbst_work: right, but maybe we could do some prime offloading
08:47karolherbst_work: like run the desktop on one core, play on the other
08:47mupuf_: yeah, that is possible
08:47karolherbst_work: or something like that
08:47karolherbst_work: but currently it would go through the PCIe port, right?
08:47karolherbst_work: idea would be to handle this over SLI instead
08:49unnew: so, what can i do?
08:49karolherbst_work: unnew: check dmesg
08:50karolherbst_work: maybe over ssh or something
08:50karolherbst_work: or try to login blind from tty
08:50karolherbst_work: and output to file
08:50mupuf_: lunch tim
08:50karolherbst_work: or check your sys log
08:50karolherbst_work: mupuf_: anyway, it would be nice to have at least such a gpu :p
08:51karolherbst_work: uhh maybe there is also a pmu counter for sli :D
08:52unnew: karolherbst_work: what should i check in dmesg?
08:52karolherbst_work: everything, paste it somewhere and post the link
10:08karolherbst_work: unnew: I was serious, you can try to find the issue yourself though
10:30inglor: I'd be more interesting in making the power management work properly on a SLI card such as 690
10:31inglor: so it can run on low cool temps and then finally spin down out of 100% fan speed
10:31inglor: I think the power management in kepler 5 is confused since there are two cards running and 1 fan
10:32inglor: Even with nvidia drivers which I can monitor the thermal stuff one of the cores might "stuck" to profile 0 (which is the turbo charged)
10:36mupuf_: inglor: yeah, that is a good point
10:38inglor: usually after a restart everything is fine but after a day or two or keeping it running (monitor goes in sleep mode but the system doesn't suspend) the sound is obvious and the nvidia-settings shows 1 core (i will start refering to them as cores) at profile 0 and another at profile 3 (lowest clocked)
10:39inglor: I doubt nvidia will fix this issue in linux for a 3 years old card :D
10:40inglor: I tried send an email RSpliet karolherbst_work and mupuf_ but I managed to find only RSpliet email.
10:40inglor: others got bounced.
10:42inglor: Also further to this I'd be interested to get my hand dirty and work on some dev / test work.
10:42inglor: How / where do I start?
10:57unnew: karolherbst_work: sure, but how can i find the issue myself if i don't know what to look for?
12:34karolherbst_work: inglor: if unsure, send to https://lists.freedesktop.org/mailman/listinfo/nouveau
12:34karolherbst_work: unnew: that's why I said to you to paste the entire dmesg and give us the link :p
12:42lesshaste: it seems the nouveau driver randomly restarting my computer
12:43lesshaste: Jul 13 13:34:22 lesshaste-desktop kernel: [ 170.577755] nouveau [ PTHERM][0000:01:00.0] temperature (123 C) hit the 'critical' threshold
12:43lesshaste: Jul 13 13:34:23 lesshaste-desktop kernel: [ 171.281409] nouveau [ PTHERM][0000:01:00.0] temperature (120 C) went below the 'critical' threshold
12:43lesshaste: what can I do?
12:43karolherbst_work: lesshaste: what gpu do you have`
12:44lesshaste: 01:00.0 VGA compatible controller: NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] (rev a1)
12:46karolherbst_work: I guess the gpu has a fan?
12:46karolherbst_work: does the fan spin up?
12:50karolherbst_work: well, you should at least create a bug with your vbios and if you get time also a mmiotrace with nvidia
12:50karolherbst_work: lesshaste: as a workaround you might be able to enable reclocking and downclock the gpu
12:52lesshaste: karolherbst_work, is there a way to see if the fan is spinning from the command line?
12:52lesshaste: I can't open the box right now
12:53karolherbst_work: you should hear it
12:53lesshaste: I am not sure it has a fan.. isn't this built into the motherboard?
12:53karolherbst_work: no clue
12:53lesshaste: I can hear a fan :) But it could be the cpu and case
12:54karolherbst_work: a gpu running above 100°C should have a "loud" fan
12:54karolherbst_work: create a bug with the vbios attached and keep an eye on it
12:54lesshaste: how do I get the "vbios"?
13:02karolherbst_work: well the last method is the prefered one
13:03karolherbst_work: the cat /sys/kernel/debug/dri/0/vbios.rom
13:23Yoshimo: karol where is the difference between cat and nvagetbios?
13:30karolherbst_work: with nvagetbios you can also read from pramin
13:30karolherbst_work: not sure how nouveau reads the vbios out though
13:30karolherbst_work: I would guess it is from prom, but I really don't know
14:14unnew: karolherbst_work: how can i get dmesg from the previous boot?
14:21karolherbst_work: unnew: depends on your system
14:22unnew: damn, got to reboot again...
14:30unnew: if i put nomodeset on kernel commandline, nouveau xorg driver won't work, right?
14:34unnew: i get this in my log, but thanks to journalctl i can't say if it's from when modeset was disabled or enabled: http://paste.debian.net/hidden/455a0738/
14:35ajax: enabled. that code wouldn't run if it was disabled.
14:37unnew: when modeset is enabled, it "switches off" my monitor (aka, not just blank), so i can't see any tty, xorg or anything, i can just reboot
14:38unnew: by "switch off", i mean, no backlight
14:40karolherbst_work: maybe the backlight is just set to 0
14:40karolherbst_work: this is a desktop though, right?
14:41unnew: desktop, yes
14:42unnew: there's some blinking light on the monitor which i think means "no signal" since it's also blinking if the monitor's on but computer off
15:24karolherbst_work: unnew: well the best way would be to use ssh
15:24karolherbst_work: unnew: do you have a second computer somewhere?
15:28unnew: there's an old laptop i should the remove the dust
15:28unnew: karolherbst_work: what should i do after i will be on ssh?
15:30karolherbst_work: run dmesg
15:32unnew: will try
15:39Yoshimo: on a kepler card, how do i set higher clockspeeds?
15:42imirkin_: Yoshimo: echo a perf level into pstate
15:42imirkin_: mupuf_: thanks, but hakzsam already grabbed it from the NV96 you plugged in
15:42mupuf_: imirkin_: not for the g80 though
15:43mupuf_: interested in the nv40?
15:43imirkin_: mupuf_: oh yeah, don't have one of those plugged in atm
15:43imirkin_: mupuf_: ALSO - if you feel like wasting a bit of time,
15:43imirkin_: set up the blob to run on the nv40
15:43imirkin_: which will probably mean a funny xorg install
15:44mupuf_: hmm, yeah, possible. Why do you want this?
15:44imirkin_: i want to trace how it sets psize from the shader
15:44mupuf_: Arch has packages for nv40 IIRC
15:44imirkin_: coz it doesn't work
15:44imirkin_: (in nouveau)
15:44imirkin_: but i'm about 150% sure the hw is capable of it
15:45Yoshimo: what if the terminal replies with write error, function not implemented?
15:46imirkin_: Yoshimo: then you lose!
15:46Yoshimo: old kernel?
15:46imirkin_: Yoshimo: pastebin dmesg
15:46imirkin_: could be a few reasons
15:53Yoshimo: i think i got the problem, it is a fermi card. That doesn't work yet does it=?
16:00imirkin_: Yoshimo: correct
16:07unnew: so, when the modeset is enabled, likely something freezes, i can't ssh to the machine
16:09Yoshimo: imirkin_: is it being worked on at the moment?
17:32Ming__: Hi, I’m working on supporting real-time task using GPU. I’ve been doing experiment with CUDA for a while to try to understand the scheduling happening down there (in runtime lib/driver/hardware). I know nVidia doesn’t have any open documentation about these. Do you guys have any clue of where I can find any information? If I shouldn’t ask such question here, I’m sorry and should I post to the email list? Thanks!!
17:48karolherbst: Ming__: I am sure you will reach out to more people if you post on the mailing list
17:50imirkin_: Ming__: "the scheduling"?
17:51karolherbst: imirkin_: I guess this stands for software/hardware scheduling or whatever nvidia does
17:51imirkin_: i'd prefer to avoid guessing.
17:52karolherbst: well, until maxwell2, we kind of know how the hardware scheduling works, right?
17:53imirkin_: i meant to avoid guessing what Ming__ was talking about
17:53karolherbst: I know
17:53karolherbst: I am just curious about this
17:54Ming__: The scheduling of kernels' execution after kernels being launched. As far as I know, each copy/execution engine has its own queues but the order of kernels is unknown and not controllable.
17:55imirkin_: ok, so you mean the scheduling of hw contexts?
17:55imirkin_: i wouldn't be surprised if you could set a priority on them, but i don't know specifically
18:00Ming__: Actually, I don't know if some scheduling also happen in the driver or runtime level. But yes, scheduling of hw contexts is important.
18:00Ming__: Yes, cuda has an api to define priority of streams
18:01imirkin_: i don't really know much about the cuda api specifically
18:01imirkin_: i suspect there should be docs that talk about this
18:02Ming__: I didn't find docs about detailed scheduling. I was hoping nouveau reverse-engineered some of it.
18:02imirkin_: let's say we had -- now what?
18:05Ming__: With the knowledge of the scheduling, I might be able to try some techniques to make the kernels' execution more predictable.
18:06Ming__: Like for now, GPU is treated as a black box with only one kernel fed at a time.
18:06Ming__: I mean in our current framework.
18:08karolherbst: I think somebody said once, that at least for shaders, once a shader program runs, it can't be stopped/interrupted, not quite sure who that was, mupuf_ maybe?
18:08karolherbst: but this is pretty much on the hardware level already
18:09karolherbst: Ming__: I also guess every older than fermi is pretty unimportant for you?
18:09Ming__: Yes, once kernels are submitted to GPU, they can't be preempted until the new Pascal architecture.
18:10karolherbst: right, I heard pascal changed that
18:10Ming__: Since I'm not working for a production but a research project, new GPU and architecture is more important.
18:10Ming__: But preemption is not a solution
18:10karolherbst: our knowledge on maxwell is also kind of limited
18:10Ming__: nVidia people said the context switch cost is huge
18:11imirkin_: it is.
18:11karolherbst: you have like 64k regs to save on kepler I think
18:11karolherbst: per smx
18:11imirkin_: you want nothing to do with context switches
18:12mupuf_: Ming__: talk to RSpliet
18:13mupuf_: he is also doing research on this topic
18:13imirkin_: mupuf_: bwidawsk was looking for you
18:14Ming__: wow! Thanks!
18:14mupuf_: imirkin_: Yes, but didn't you see my answer?
18:16mupuf: imirkin_: I see, I was not logged in as mupuf --> my messages were going to /dev/null
18:16karolherbst: allthough I guess RSpliet might have a hard time now :/
18:21Ming__: why's that, should I not bother him now?
18:21Ming__: or her..
18:21karolherbst: ohh well, just UK things currently
18:23karolherbst: there are some funding cuts from the EU to UK research projects cause as it seems UK might leave the EU
18:23karolherbst: no idea if this affects him in any way though
18:24Ming__: I see..
18:30karolherbst: mupuf: did you hear, intel/nvidia got beaten in the super computer rankings :D in both raw power and efficiency
18:30mupuf: karolherbst: nope! Link?
18:30karolherbst: compare 1. and 2. :D
18:30karolherbst: Sunway is a chinese thing I think
18:31karolherbst: allthough the intel one is a sandybridge xeon
18:31karolherbst: well a bit more than one actually
18:34karolherbst: mupuf: you are aware of the fact, that this happened, because the US gov thought exporting new stuff might be "missues" by the chinese gov, so they can't get the new chips... or something like that
18:34mupuf: they produce them ... but they cannot use then?
18:34mupuf: well, produce == assemble
18:35karolherbst: I guess so
18:36karolherbst: MIPS chips with x86 compatibility mode, yes, why not :D
18:37karolherbst: ohh wait, that was with the "old" prototypes
18:38karolherbst: when plans backfire big times :D
18:38mupuf: ah ah
18:40karolherbst: and I am sure those chips are actually cheaper :p
20:35unnew: karolherbst: actually i can't ssh when i have the blank screen
20:36unnew: the machine doesn't answer at this moment
20:36imirkin_: unnew: what gpu do you have?
20:36imirkin_: it looks like your disp is busted
20:37karolherbst: or a bit more
20:37karolherbst: usually ssh should response
20:38karolherbst: but I guess the machine totally hangs somewhere
20:44karolherbst: unnew: mhh there is another thing you might be able to do: Start the machine with nouveau blacklisted, run dmesg -w in a ssh session, load nouveau from a tty login
20:44karolherbst: imirkin_: I think he has a G94 or something, it is in the log of today
20:44karolherbst: ohh wait
20:44karolherbst: that was somebody else
20:45karolherbst: okay, we don't know the gpu
21:17unnew: imirkin_: gtx 460
21:17imirkin_: hmm ok
21:18unnew: karolherbst: "modprobe nouveau" to "load nouveau from a tty login" ?
21:47karolherbst: unnew: yeah
21:47karolherbst: when you are lucky, you should see something in the ssh session