03:07 chatter29: hey guys
03:07 chatter29: allah is doing
03:07 chatter29: sun is not doing allah is doing
03:07 chatter29: to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
10:06 gry: using nouveau with "01:00.0 VGA compatible controller: NVIDIA Corporation G72M [Quadro NVS 110M/GeForce Go 7300] (rev a1)" on debian jessie kde 4, after a day or two its performance degrades to the point of unusable, maybe it is my graphics card? how do i troubleshoot?
10:19 pmoreau: gry: Not sure. Could you paste the output of dmesg somewhere please?
10:20 gry: grep it for anything in particular? the whole thing is too much info
10:22 pmoreau: Hum… nouveau and drm
10:28 gry: pmoreau: http://dpaste.com/2WT18R1.txt
10:31 pmoreau: Nothing really special there.
10:31 gry: yep, this is fresh after a reboot, i'll take a note of it next time it starts being slow and come back to you
10:31 pmoreau: Ah, ok
10:32 pmoreau: Does that happen with the NVIDIA driver? What makes you believe it could be Nouveau?
10:33 gry: i didn't try nvidia driver; some internet forum posts cite graphics as one possible reason for kde being slow, so i'd like to find a way to rule it out somehow
10:34 RSpliet: pmoreau: G72 is pre-Tesla. I'm sure there could be some memory leaks in the NV30 code...
10:35 RSpliet: gry: when it's unusable, did your system run out of memory?
10:35 gry: i didn't check, i'll check next time it happens, thanks
10:35 pmoreau: RSpliet: That is a possibility.
10:35 gry: RSpliet: is there a particularly easy way to do that short of looking at output of 'top' ?
10:36 RSpliet: Linux always confuses me with its reporting of free memory
10:36 RSpliet: this being said... it could just as well be video RAM that's leaking... for which we have no probes I think...
10:38 pmoreau: It’s definitely not something that is reported to userspace. Not sure whether it is already tracked in the kernel module or not.
10:38 gry: actually i've found 'free -h', will keep an eye on that
10:38 gry: and it is using .. wait, i can't believe i only have 1GB of memory, that's somewhat exotic
10:39 RSpliet: systems from the G72 era often only had one or two GiB of RAM
10:49 RSpliet: meanwhile, I'm baffled to see that my OpenCL for-loop has been split in two by the NVIDIA compiler
10:57 pmoreau: RSpliet: Eh? Like `for (int i = 0; i < 4; ++i) { do_some_stuff }` into `for (int i = 0; i < 2; ++i) { do_some_stuff }; for (int i = 2; i < 4; ++i) { do_some_stuff }`? Or the body of the for-loop has been doubled to increase ILP?
10:59 RSpliet: it seems to have turned the body of a for (i = 0; i < 7; i++){} into two running from 0 to 6
11:00 RSpliet: which is surprising, given there's a data dependency between the operations in the loop body
11:02 pmoreau: I guess it can still benefit from some higher ILP?
11:04 RSpliet: let's find out
11:11 RSpliet: No it doesn't make a lot of sense... it's like it did some very aggressive reordering to move the async_work_group_copy() into the inner loop or sth...
11:11 RSpliet: no, this too makes no sense at all
11:16 RSpliet: oh... it's created a loop where it processes two elements at the time instead of one. And then a second _loop_ that processes the last element
11:18 RSpliet: that looks very awkward... the least they could do is - if unrolling a loop _twice_, assume that the fixup either runs once or non at all. That'll let them eliminate some of the loop overhead (test+branch)
11:18 RSpliet: soodaa: ^ although this is the 367.27 driver
11:26 sooda: strange indeed
11:27 sooda: i don't really work with cuda or compilers so no idea what's going on, i can only guess like you :P
11:27 RSpliet: sooda: well I presume it's a generic loop unrolling pass that uses register count as its constraint
11:27 sooda: yeah, something like that would make sense
11:28 RSpliet: ... there's so much fun to be had with optimising compilers, why am I doing this PhD thing :'(
11:30 sooda: :)
11:31 sooda: the grass is always greener elsewhere
11:37 RSpliet: ouch, and here the blob unrolls by 4 although my loop only runs from 0 to 2 :-D let's be cheeky and abuse this information in a pragma unroll
11:37 RSpliet: and presto, 20% perf!
11:39 karolherbst: \o/
11:39 karolherbst: well getting only 20% perf of the original pers if kind of bad ;)
11:42 RSpliet: pendants: making the world a little more sour every day! *insert gif of Briton pouring vinegar on chips*
11:42 RSpliet: *pedants
11:43 sooda: ew, vinegar-seasoned chips are the worst
11:43 mupuf: RSpliet: would be nice to save these shaders and add them in shaderdb
11:43 mupuf: oh, sorry, it is cuda
11:43 mupuf: too bad
11:43 RSpliet: mupuf: OpenCL
11:44 mupuf: hmm, save them then :p
11:44 RSpliet: I'm preparing a spreadsheet with them ;-)
11:44 mupuf: we'll eventually want to improve shaderdb to be able to run opencl kernels
11:44 mupuf: :D
11:51 pmoreau: How does one run shader-db on Nouveau?
11:55 mupuf: pmoreau: what do you mean, I don't remember needing to do anything
11:56 dboyan_: mupuf: I happened to notice the gsoc project on perfmon support for apitrace last year. Does that work support AMD_perfmon well?
11:56 mupuf: you'll still need our private shaderdb
11:56 mupuf: dboyan_: in apitrace, yes
11:56 pmoreau: What commands to run, the very basic stuff.
11:56 mupuf: in qapitrace... not yet
11:56 pmoreau: I never used it
11:57 mupuf: ./run shaders/
11:58 pmoreau: That end up running on the Intel card, not the NVIDIA one.
11:58 pmoreau: Even with DRI_PRIME=1
11:59 hakzsam: pmoreau: -d 1 maybe?
12:00 dboyan_: mupuf: It can used to monitor performance counters per frame, I guess?
12:00 pmoreau: hakzsam: Ah, way better! Thanks! :-)
12:00 hakzsam: dboyan_: and per draw call
12:01 dboyan_: wow, that'd be nice
12:04 mupuf: dboyan_: per frame or drawcall
15:34 RSpliet: dboyan_: over the kernels I'm looking at, I'm observing about 20% with another one of insn are "dual issued"
15:35 RSpliet: sorry, that sentence came out botched. 20% of insn executed have a 0x4 scheduling value. So depending on your def 20% or 40% are dual issued :-P
15:37 mwk: alright, here come falcon hwtest results
15:38 mwk: not tested yet: all sorts of loads/stores, xfers, io read/writes, tlb access, crypto
15:38 mwk: now I need to fix up the docs...
15:57 RSpliet: karolherbst: does that somehow match your findings as well? 20% (or 40% depending on how you look at it) dual issue?
16:08 sbstn: Hello! I'm wondering does nouveau support DP daisy chaining? I tried debian sid a while ago with two displays using DP in daisy chain mode, but did only get them working in cloned mode (instead of separate displays).
16:12 RSpliet: sbstn: I don't recall anyone working on this, so I highly suspect it's not supported with nouveau
16:13 sbstn: suspected as much, thanks anyways
16:13 RSpliet: this being said... you could always try the latest kernel. Erm, that is
16:14 RSpliet: as soon as the latest display code rewrite is brought upstream
16:14 RSpliet: (which really really turned half the driver upside down again. I fear the day he finds out DP daisy chaining requires a different design again :-P)
16:16 sbstn: the main reason I have these screens in daisy chain is that I don't happen to have long enough cables otherwise. Simplest thing might be I just go and buy a bit longer DP cable
16:16 sbstn: was just hoping it was something I might have missed in configuration or just needing more recent kernel or so
16:18 RSpliet: I personally don't know what it takes to configure hardware to do this. I suspect it's slightly more than what we currently implement, and keep my fingers crossed that it's not a lot ;-)
16:38 jamm: hakzsam: hope you got my email ^^
16:38 hakzsam: jamm: yep
16:38 hakzsam: thanks
16:39 jamm: do take a look at sched (st 0x1 wt 0x3f) in the patch
16:39 jamm: i did that because apparently using the right bars (as per my knowledge) to wait on didn't seem to work
16:40 hakzsam: good to know
16:40 hakzsam: I will have a look later on :)
16:40 jamm: no worries! cheers :)
19:23 gry: pmoreau, RSpliet: thanks for your enthusiastic assistance a few hours ago. The RSpliet's question whether I ran out of memory was the key. :) The laptop had only 1GB of ram and now I've put 3. I'll see whether that is enough for the problem to go away.
19:26 pmoreau: gry: Ok, let’s see if that helps. :-)
19:26 gry: yup, hopefully so :-)
23:41 RSpliet: gry: well, if it now pops up after 4 days of uptime we know there's some leaks to plug.
23:42 RSpliet: (but then the Q is whether it's nouveau, KDE, or...)