00:26 orbea: so is it correct that vaapi and vdpau hardware decoding for videos doesn't work without the nvidia firmware with the nouveau drivers?
00:43 orbea: i solved issue, reinstall mesa packages...
00:44 orbea: err, sorry, wrong channel
00:44 orbea: solved a different issue...
00:56 pmoreau: Morning
01:18 karolherbst: imirkin: is the pcie width change inside rnndb?
07:27 imirkin: karolherbst: i thought so... you can't find it?
07:27 imirkin: orbea: correct.
08:23 karolherbst: imirkin: what do you think how much work would it be to port the fence thing away from busy waiting?
08:24 imirkin: karolherbst: don't think it's possible
08:24 imirkin: karolherbst: at least not without dropping the suballocation stuff
08:24 imirkin: the busy wait should be a fairly rare occasion though
08:25 karolherbst: messured 6% in borderlands
08:26 imirkin: 6% what
08:26 imirkin: with callgrind? that's irrelevant.
08:26 karolherbst: oprofile
08:26 imirkin: hmmm ok
08:26 imirkin: that's more relevant
08:26 imirkin: but... there's not a whole lot we can do
08:27 karolherbst: :/
08:27 imirkin: and having the kernel wait wouldn't improve the situation much
08:27 karolherbst: why not?
08:27 imirkin: because it'd still block the operation
08:27 imirkin: basically you'd have to add a "wait for fence sync" thing to the kernel, along with the fence/sequence info
08:28 imirkin: and then you'd just add the intr flag to all the fence emission junk
08:28 imirkin: it wouldn't be hugely difficult
08:28 karolherbst: mhh
08:28 karolherbst: so you doubt that cpu usage decreases in total?
08:29 imirkin: but fundamentally the game execution flow would still be blocked
08:29 imirkin: cpu usage might decrease a bit, but it won't speed the game up any
08:29 karolherbst: yeah I know
08:29 imirkin: would def want to hear skeggsb's thoughts on such a ioctl of course
08:29 karolherbst: but decreases cpu usage might actually improve cpu based tasks
08:29 karolherbst: *decreased
08:30 imirkin: karolherbst: other tasks, sure. not the current task though.
08:30 karolherbst: depends
08:30 imirkin: karolherbst: fwiw it does do a sched_yield() which, if there are any other runnable tasks, will yield to them. hopefully.
08:30 karolherbst: on single threaded application, okay, no big difference
08:30 karolherbst: bit if an application can make use of 2 or 4 cores
08:30 karolherbst: then it may make a difference, because of cpu boosts
08:31 karolherbst: but only a small one
08:31 karolherbst: a really small difference :D
08:31 karolherbst: might be actually nice for laptops running nouveau, too allthough these are rare these days
08:32 imirkin: if your argument is that it would be slightly better, then i agree
08:33 karolherbst: would be nice to profile an entire desktop setup over a few hours and check how much CPU usage is used there in total
08:34 karolherbst: to bad I don't get kerne spaced profiled :/
08:39 karolherbst: ohh, now it works
08:40 imirkin: use 'perf'
08:40 imirkin: instead of oprofile
09:13 salamanderrake: any news on nvidia being stingy with their binary blobs for the 900 series cards?
09:14 karolherbst: imirkin: with boost enabled I even get over 10% cpu usage inside the fence stuff
09:14 karolherbst: also ia32_sysenter_target is over 6% for me, but I don't know if thats good or bad
09:20 Yoshimo: salamanderrake: haven't seen any so far
09:21 salamanderrake: this makes me wish I had picked an amd card, except for the poor performance on linux.
09:21 karolherbst: salamanderrake: what do you mean with stingy?
09:22 salamanderrake: the refusal to release the signed blobbs for the nouveau team
09:22 RSpliet: it's not refusal, just endless red tape
09:22 RSpliet: and bike shedding
09:23 karolherbst: ahh this firmware issue?
09:23 salamanderrake: yeah
09:23 RSpliet: which arguably is justified, because all involved parties want to avoid nouveau ending up as a second rank project
09:24 imirkin: fwiw a sufficiently interested individual could extract the blobs from their drivers themselves.
09:24 imirkin: the problem is that the blob drivers read the fw out of sysram, which we don't intercept. so at the time of that read, we'd have to dump out that memory.
09:24 salamanderrake: I am pretty sure thats impossible as it stands now from what I understand from the situation.
09:25 salamanderrake: oh ok
09:25 RSpliet: salamanderrake: it's *somewhere* in the driver blob though...
09:25 karolherbst: you run a Linux box, there is no such thing as impossible here ;)
09:26 RSpliet: plus that... which DMA does the read out and how can we make it trip? :-P
09:26 imirkin: RSpliet: easy, just dump all of sysram on every mmio writes ;)
09:27 imirkin: salamanderrake: also i have a script that just "parses" their blob directly, but they changed stuff around enough that it no longer works
09:27 imirkin: but i haven't checked the 35x's... perhaps it's back
09:27 karolherbst: :D
09:27 karolherbst: I got the feeling, that it worked for me oO
09:28 karolherbst: maybe it was just trash, who knows
09:28 RSpliet: imirkin: hahahaha, oh yes, that's a brilliant solution; let's go and invent a supermassive interface to dump RAM :-D
09:29 karolherbst: you could also do it in RAM
09:29 RSpliet: how much bandwidth does mictor have?
09:29 karolherbst: most of the time
09:29 imirkin: more seriously though, you could just look at what they've poked through the iommu
09:30 imirkin: which is hopefully a much more finite quantity
09:30 imirkin: but anyways, it would require the hw, which i don't have
09:31 salamanderrake: so if this is so simple, how come no one has added the 900 series cards no nouveau list, this is not a jab but a serious question.
09:31 imirkin: and the will to live left too
09:31 imirkin: salamanderrake: it's not simple
09:31 salamanderrake: or is this one of those 'what an individual has to do on their own system' for legal reasons?
09:32 imirkin: if that were the case, then instructions could be arrived at
09:32 imirkin: but afaik no one but ben has one of these monsters
09:32 salamanderrake: I have a 960
09:32 imirkin: cool. then you work it all out.
09:33 salamanderrake: I will get right on that, first let me go to school for computer science...or watch a youtube video.
09:33 imirkin: so we're back to "no one has one of these but ben" :)
09:34 salamanderrake: pretty much
09:34 imirkin: i'm sure he's not the sole owner of such hardware, but definitely the sole owner among those interested and capable of getting it working
09:34 salamanderrake: so what I would need to do is get the blob out of my card right?
09:34 imirkin: and he gave up for it for now
09:34 salamanderrake: ah ok
09:34 imirkin: which to me is a sign that it's not particularly easy to do
09:35 orbea:thanks imirkin to the response to his earlier query
09:36 salamanderrake: orbea: did I hijack imirkin from your convo?
09:37 salamanderrake: ok just scrolled up, never mind then.
09:37 RSpliet: well, also because he has a couple million things up on his todo list
09:37 RSpliet: (Ben does)
09:37 imirkin: orbea: fwiw if you have a GT200 or older gpu, you can use XvMC (which does mpeg1/2) without any blob firmware. it's a separate hw decoding unit in the hw.
09:37 orbea: salamanderrake: no, asked yesterday and fell asleep before the reply :)
09:37 RSpliet: including RH bug reports I guess... he's a busy and devoted man :-)
09:37 imirkin: [and don't ask me why they had 2]
09:37 orbea: interesting to know, but my cards are newer
09:38 orbea: geforce 9800 gt
09:38 imirkin: that's probably a G92
09:38 orbea:looks into more
09:38 imirkin: or G94
09:38 imirkin: no?
09:38 salamanderrake: orbea: lol
09:38 imirkin: orbea: lspci -d 10de: should have the codename
09:39 salamanderrake: I think its a G92, I had one of those also.
09:39 orbea: g92
09:39 salamanderrake: same thing as a 8800gt
09:40 salamanderrake: which is the same family as the gtx 2** family I believe.
09:41 salamanderrake: or I could be wrong
09:42 salamanderrake: no I was right, its the same as some of the 2** series cards
09:44 orbea: unfortunately im not sure if mpv can do that even if slackawre provides it ootb apparently
09:45 imirkin: orbea: well, (a) it's only for mpeg1/2 which your cpu is plenty fast to do on its own
09:46 imirkin: orbea: in order to use it, you have to set up libXvMCW. mplayer works fairly well with it.
09:46 orbea:considers reinstalling mplayer...
09:46 imirkin: orbea: you'd also have to use the NOUVEAU_PMPEG=1 environment variable i think, otherwise it defaults to the other decoder, which requires firmware
09:46 salamanderrake: orbea: why? mpv is an updated fork of mplayer
09:47 orbea: I asked in #mpv, seems wm4 removed it
09:47 salamanderrake: oh
09:47 imirkin: salamanderrake: because mplayer works, and things that are not mplayer don't work
09:47 orbea: mpv does have a lot of other conveniences, like working with youtube-dl
09:47 imirkin: and they have millions of excuses for why they don't work
09:48 imirkin: but the end result is... mplayer works.
09:49 orbea: are there any plans to add hardware decoding with vdpau or even vaapi to nouveau? It might be a worthy kickstarter?
09:50 imirkin: orbea: it's there... you just need to install blob firmware to run on the video decoding processors.
09:50 imirkin: orbea: see http://nouveau.freedesktop.org/wiki/VideoAcceleration/ -- it has a lot of details.
09:50 imirkin: [only vdpau... vaapi won't work due to lack of caring]
09:51 orbea: imirkin: i tried that, a newer nvidia.run froze mpv, an older one froze my whole wm...
09:52 imirkin: erm... the firmware should be the same
09:52 imirkin: did you follow the actual instructions in there, or did you follow instructions that were similar to what was in the wiki
09:53 orbea: I tried this to be specific http://dpaste.com/3AX3NDR
09:53 imirkin: and that froze?
09:53 imirkin: oh right. shit. sorry
09:53 orbea: with the exact commands listed and also with 340.36.run
09:53 imirkin: G92
09:53 orbea: my cards could just be bad...
09:53 imirkin: is broken. for reasons i never understood :(
09:54 imirkin: nope, happens with all G92's
09:54 orbea: ah
09:57 imirkin: i never tried to debug it though, so it's not like i tried and failed
09:58 imirkin: i did look at a handful of mmiotraces, and nothing stood out
09:58 imirkin: i should probably give it another shot at some point
10:01 karolherbst: how bad are unknown functions in apitrace?
10:03 imirkin: uhhhh
10:03 imirkin: huh?
10:03 karolherbst: mhh no, its unimportant here
10:03 karolherbst: I try to apitrace witcher2
10:03 karolherbst: some *AMD *INTEL whatever stuff
10:04 karolherbst: maybe I should try out the new apitrace release
10:25 karolherbst: imirkin: witcher2: /var/tmp/portage/x11-libs/libdrm-2.4.62/work/libdrm-2.4.62/nouveau/pushbuf.c:726: nouveau_pushbuf_data: Assertion `kref' failed.
10:25 karolherbst: but I only got this once
10:25 imirkin: karolherbst: so... i added those assert's to prevent bad things from happening
10:25 imirkin: my observation is that they can happen for 2 reasons
10:25 imirkin: (a) bug in mesa
10:26 imirkin: (b) execution gets super-backed up
10:26 imirkin: did you get a gpu hang to correspond with it?
10:26 karolherbst: no hang
10:26 karolherbst: this was just while running apitrace
10:26 imirkin: well, i think i fixed the mesa bug
10:27 karolherbst: but apitrace doesn't get anything usefully anyway :/
10:27 karolherbst: just black all the way
10:27 imirkin: probably uses buffer storage
10:27 imirkin: are there glBufferStorage calls?
10:27 karolherbst: we had this topic once anyway: https://github.com/apitrace/apitrace/issues/232
10:28 karolherbst: "glBufferStorage: MAP_NOTIFY_EXPLICIT_BIT_VMWX set w/o MAP_PERSISTENT_BIT" and "glMapBufferRange: MAP_COHERENT_BIT unsupported (https://github.com/apitrace/apitrace/issues/232)"
10:29 imirkin: right.
10:57 blacklotus: if a gpu doesn't support opengl 4 functionality it will never have the functionality under nouveau right? for example through software fallbacks
11:00 orbea: nouveau could do opengl 4.0+ with the right cards?
11:02 imirkin: blacklotus: theoretically possible, but in practice totally useless
11:11 Karlton: orbea: yeah, it reports 4.1 right now with latest git version of mesa
11:11 blacklotus: imirkin: if i remember correctly not all opengl 4 features are hardware specific and I thought that maybe a part of the gl4 functionality can be done through hardware that only "has opengl 3 support"
11:11 imirkin: blacklotus: that's right, and that functionality will be exposed on older hardware if it isn't already
11:12 imirkin: blacklotus: perhaps you'd find this interesting: http://people.freedesktop.org/~imirkin/glxinfo/glxinfo.html
11:12 blacklotus: ok :) that's great thank you for the info and the link
11:12 imirkin: blacklotus: but there's functionality in GL 4.0 that requires hardware support, and hw which doesn't have it will never expose a GL version higher than 3.3
11:13 imirkin: which of course doesn't prevent extensions from being implemented
11:13 blacklotus: yeah shaders are the first thing that come to my mind (if you mean shaders :P)
11:13 imirkin: extensions are to the GL/GLSL specs... some deal with shader-related things, others don't
11:15 imirkin: among other things pre-GT21x doesn't support texture cube map arrays, no tesla's support gs instancing or tessellation or indirect draws
11:16 imirkin: i've grayed out the things the hw doesn't support on that page... not 100% accurate, but mostly reasonable
11:53 shakesoda: should changing pstate work on nv50? (it doesn't, at least, on my current kernel, just curious if it might work on a newer one)
11:54 imirkin: shakesoda: on a G80? no.
11:54 imirkin: shakesoda: it should work on GT21x's
11:54 shakesoda: it's a GT216M
11:55 imirkin: should work... you need to boot with nouveau.pstate=1
11:55 shakesoda: I did, maybe kernel is just too old
11:55 imirkin: 3.19+
11:55 shakesoda: that'd do it, I'll upgrade.
11:55 shakesoda: still on 3.13
11:55 shakesoda: thanks :)
11:56 imirkin: obviously no guarantees... still manual and all that.
11:56 imirkin: and while roy did a great job on it, he didn't exactly test on 10000 diff gpu's...
12:06 shakesoda: imirkin: works up to second highest pstate, which is a significant improvement for what I'm working on :)
12:07 shakesoda: highest makes my screen go a little crazy, but nothing fatal
12:08 imirkin: shakesoda: i think roy did observe some issues with highest pstate on some gpu's, never worked out what it was
12:08 shakesoda: I take it back, highest froze my system when I tried again. anyhow, helps a bunch to get to second highest.
12:12 shakesoda: the kernel update fixed the issue I was having where anything vsynced would lock up after waking from suspend, too.
12:13 imirkin: yay :)
12:15 RSpliet: hmm, I thought I ironed out most issues with the highest perflvl
12:16 RSpliet: shakesoda: mind sending me your VBIOS?
12:18 shakesoda: RSpliet: I'm using 3.19 and not absolute latest, I can try something even newer
12:18 RSpliet: let me just try and sort out whether anything changed
12:18 shakesoda: what's the magical incantation to dump the vbios?
12:19 imirkin: cat /sys/kernel/debug/dri/0/vbios.rom > gt216-vbios.rom
12:21 RSpliet: also, please paste a full a dmesg from your kernel on a paste website of choice, and share the URL
12:24 RSpliet: shakesoda: newer kernel isn't going to make a difference, but this patch could make a difference: http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=478cb0b865a6618c516f612249b8c3fb99b6b114
12:24 shakesoda: RSpliet: https://dl.dropboxusercontent.com/u/1960937/gt216m-vbios.rom
12:24 RSpliet: depending on the card you have
12:26 shakesoda: should I do anything specific (i.e. try to use highest pstate) before uploading the dmesg output?
12:26 RSpliet: nah, I think I already know enough from your VBIOS tbh
12:26 RSpliet: you don't happen to have envytools installed, do you?
12:27 shakesoda: I do not.
12:27 imirkin: RSpliet: didn't you still see texturing issues with one of the cards at the highest pstate btw?
12:28 RSpliet: shakesoda: darn, I was hoping to hear the value of a certain register to confirm the patch I linked you works
12:29 RSpliet: shakesoda: anyway, if you're feeling lucky you can build a kernel yourself with that patch applied and see if it fixes things
12:37 shakesoda: RSpliet: I'll give it a go
12:38 imirkin: ... or install envytools and look up that register :)
12:38 imirkin: seems easier
12:38 shakesoda: or that!
12:39 RSpliet: imirkin: one does not exclude the other :-P
12:43 shakesoda: RSpliet: I've got envytools now
12:45 RSpliet: try "nvapeek 0x101000"
12:45 RSpliet: as root
12:45 shakesoda: 00101000: 8f78a488
12:47 RSpliet: heh, that one was unexpected
13:28 RSpliet: shakesoda: ok, for now I don't think I can help you get the top perflvl rocking... I don't have enough information and currently no time to spare
13:28 RSpliet: however, it's not far off from the second-to-last in terms of mem clock, so you should be fairly good with the second-highest
13:32 imirkin: RSpliet: what's the info that you're missing?
13:32 shakesoda: RSpliet: I didn't try that patch yet, but even if it doesn't help, the second-highest pstate shaved 6.1ms off my frame times for the game I'm working on so I've got much more room to work with now :)
13:32 imirkin: i.e. what was surprising in his strap config?
13:33 imirkin: shakesoda: we've also figured out how to increase the pci speed to 5GT/s, can help with that if you're interested
13:34 RSpliet: imirkin: I didn't expect the highest two perflvls to have the same timing ;-)
13:35 imirkin: what's the diff between them?
13:35 RSpliet: 90MHz
13:36 imirkin: crosses the magical 750MHz barrier
13:36 imirkin: (that was the cross-over point right?)
13:36 shakesoda: http://hastebin.com/leyeramopi.mel
13:36 RSpliet: I think it was
13:36 shakesoda: ^ the states
13:37 imirkin: RSpliet: perhaps you got it wrong :)
13:37 RSpliet: imirkin: unlikely, I tested that barrier with coolbits
13:37 imirkin: RSpliet: ah ok
13:37 RSpliet: what does strike me is the bit ramcfg_10_04_08 is set
13:37 RSpliet: for the lowest two perflvls
13:38 RSpliet: this could imply that on upclocking a value is not masked away that should have been
13:38 RSpliet: however, to verify I need blob trace
13:39 RSpliet: also timing_23 is used in 0x100718, but that should not affect reclocking as the value doesn't change between perflvls
13:51 karolherbst: maybe if I have a lot time to spare, I will try to get the highest perf level working for me. Does anybody have a clue what's not that good with gddr5 currently?
13:58 imirkin: karolherbst: skeggsb would be the one to talk to. iirc he thought it was some missing config of the iso hub. however he was never able to get it to work.
14:05 shakesoda: something very recent (I last updated mesa within the last week) seems to be making my app OOM after about two seconds.
14:05 shakesoda: D:
14:06 imirkin: shakesoda: or kernel update
14:06 shakesoda: imirkin: I was running this for more than two seconds after updating the kernel, though, and I didn't apply that patch
14:06 shakesoda: I updated mesa after that.
14:07 shakesoda: I could boot on the old kernel though, I'll see if that changes it
14:07 imirkin: or old mesa
14:07 imirkin: it's been happening to karolherbst too i think
14:07 imirkin: and someone else with ... some game.
14:08 imirkin: [i'm a fountain of specific knowledge, aren't i...]
14:10 RSpliet: karolherbst: for Tesla, GDDR5 reclocking is not implemented at all
14:10 imirkin: he has a kepler
14:11 RSpliet: in that case, link training is the most likely offender
14:11 RSpliet: but any detail could be the culprit
14:25 shakesoda: trying again with downgraded mesa and 3.19 kernel
14:31 shakesoda: it's definitely the newer kernel, and I didn't get the crash before because I had vsync off. no vsync, no crash.
14:31 shakesoda:updates mesa again...
14:32 imirkin: well, at one point we stopped limiting GART
14:32 imirkin: that was probably a bad decition
14:32 imirkin: decision*
14:33 imirkin: shakesoda: on 3.13, what does it say under GART: ...
14:33 imirkin: is it 1.5TB or is it 512MB?
14:33 shakesoda: [ 3.604741] nouveau [ DRM] GART: 1048576 MiB
14:33 shakesoda: oh, sorry
14:34 shakesoda: this is 3.19, rebooting.
14:34 imirkin: er sorry yeah. 1TB. not 1.5TB.
14:34 karolherbst: what happend to me?
14:34 imirkin: (40-bits)
14:35 karolherbst: ahhh oom
14:35 karolherbst: yeah, metro redux
14:35 karolherbst: shakesoda: userspace reports nearly no memory usage, but a lot of memory is actually used
14:36 karolherbst: glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, 19) and glBufferData(GL_ELEMENT_ARRAY_BUFFER, 21390336. [data, size=20889], GL_DYNAMIC_DRAW) was inside my apitrace
14:36 karolherbst: though there was also the same pair of calls with GL_ARRAY_BUFFER
14:37 shakesoda: imirkin: same thing on 3.13
14:38 imirkin: shakesoda: hm ok.
14:38 imirkin: that's surprising. yet everything works fine on 3.13?
14:39 shakesoda: yes, everything works fine.
14:40 karolherbst: maybe a trace may help? could be the same calls
14:40 imirkin: shakesoda: if you could bisect it further, that'd be interesting
14:40 karolherbst: and if its a kernel issue, I might try to bisect it if I get that far, or are you up to that task shakesoda?
14:40 imirkin: a _ton_ of stuff changed between 3.13 and 3.19 i'm afraid
14:40 karolherbst: ohh right
14:40 karolherbst: 3.19 doesn't work for me :O
14:41 shakesoda: I'll give 3.16 a go, anything between those will require me actually compiling my own kernels.
14:45 karolherbst: ohh right, idea
14:47 shakesoda: I can't test 3.16... it kills my keyboard and mouse.
14:47 shakesoda: heh
14:47 karolherbst: :/
14:47 karolherbst: thats nice
14:51 karolherbst: imirkin: do you know what gf100_vm_map_sg does?
14:51 karolherbst: there are a lot of calls to it, but I don't know if thats bad
14:51 imirkin: karolherbst: magic.
14:52 imirkin: i think it maps vram into process vm? something like that.
14:52 karolherbst: it has like 1500 calls
14:52 karolherbst: for like 10 frames
14:52 imirkin: it gets hit when you do nouveau_bo_map()
14:52 karolherbst: 5 actually
14:53 imirkin: i wonder if http://cgit.freedesktop.org/~darktama/nouveau/commit/?h=linux-3.19&id=3412da881c922db33ff0c8e1820984880f4ca112 affects things
14:53 karolherbst: should I try to revert?
14:55 imirkin: looks like that came into 3.14?
14:56 karolherbst: a lot of conflcits though, but possible
15:00 karolherbst: :D
15:00 karolherbst: bus error :/
15:00 karolherbst: sda
15:00 karolherbst: sad
15:00 imirkin: take another bus :)
15:01 karolherbst: this "bo->mem.mem_type == TTM_PL_SYSTEM" part seems importat
15:02 imirkin: only revert the nouveau_ttm_io_mem_reserve change
15:02 imirkin: i wonder if we forget to clean up some mapping
15:02 imirkin: with the nouveau_bo_placement_set/nouveau_bo_validate combo
15:02 karolherbst: imirkin: this is tesla only
15:02 imirkin: i also am semi-randomly pointing out that change, there have been plenty of others :)
15:03 imirkin: huh?
15:03 karolherbst: "if (drm->device.info.family < NV_DEVICE_INFO_V0_TESLA || !node->memtype)" on master
15:03 imirkin: hold on
15:03 imirkin: time to look at what's up :)
15:04 karolherbst: I remove this tesla check
15:04 imirkin: pre-tesla doesn't have tiling in the first place
15:05 karolherbst: ohh wait
15:05 karolherbst: I am stupid
15:06 karolherbst: okay, I still get memory spikes
15:07 RSpliet: shakesoda: thanks for your VBIOS, seems like your card changes one voltage more than mine
15:07 RSpliet: I'm going to look into that... when I have time :-P
15:07 karolherbst: opreport output: https://gist.github.com/karolherbst/100d8440d5af6bbeda74
15:08 imirkin: karolherbst: learn how to use perf.
15:09 karolherbst: I tried, but it didn't let me show module stuff
15:09 imirkin: gf100_vm_map_sg -- this is just coz it writes a ton of stuff to vram via something slow
15:09 imirkin: it has to write in the PTE's, etc. i think.
15:10 karolherbst: nvkm_gpuobj_create_ ?
15:10 karolherbst: this seems like something which could need a lot of vram
15:11 imirkin: skeggsb: this looks wrong for G80... shouldn't it put the buffer from system -> vram if it's tiled?
15:11 imirkin: if (bo->mem.mem_type == TTM_PL_SYSTEM) {
15:11 imirkin: nouveau_bo_placement_set(nvbo, TTM_PL_TT, 0);
15:20 imirkin: mlankhorst: --^
15:23 shakesoda: imirkin: I'm trying more kernel versions to see how far back it happens and if it happens on latest (well, 4.1)
15:26 karolherbst: imirkin: do I have to do anything else for perf after I added the modules to the buildid cache? They addresses now show up, but not the symbols, allthough I passed vmlinux and -m to perf report
15:26 imirkin: karolherbst: that's weird...
15:26 imirkin: karolherbst: is the module in a funny place?
15:26 imirkin: (where perf can't find it)
15:26 karolherbst: ohh right, inside the repository :/
15:27 karolherbst: will overwrite the kernel one
15:27 karolherbst: mhh
15:27 karolherbst: it doesn't fine ttm as well
15:27 karolherbst: and I use the kernel one
15:28 imirkin: i guess i dunno... it has always Just Work'd for me
15:28 karolherbst: strace :/
15:28 imirkin: do you have kallsyms enabled?
15:29 karolherbst: do you have a perfconfig?
15:29 karolherbst: kernel symbols are all there
15:29 karolherbst: only ttm and nouveau are missing, which are both modules here
15:29 imirkin: hmmm
15:30 imirkin: no, i don't have anything fancy
15:30 imirkin: i just do 'perf record -g' and then 'perf report'
15:33 karolherbst: cat /proc/kallsyms | grep nouveau list a lot of stuff, I guess this is okay?
15:48 saintdev: what does "internal only" for the voltage adjustment mean in the power management table?
15:52 imirkin: saintdev: hm, which are you talking about?
15:52 saintdev: http://nouveau.freedesktop.org/wiki/PowerManagement/
15:53 imirkin: not sure... mupuf -- what did you mean by that?
15:56 imirkin: saintdev: is there an underlying question you're trying to answer, or just curious about that line on that page?
15:57 shakesoda: imirkin: the crash was introduced in either 3.18 or 3.19, about to test 3.18 now.
15:57 saintdev: a little of both
15:57 karolherbst: shakesoda: it works with 3.17? nice
15:58 shakesoda: yeah, 3.17 works fine
15:58 saintdev: I was looking if PM would work on a card for a headless server (the mobo requires a video card). But now I'm also curious what that line means :P
15:58 shakesoda: 3.18 seems to be good too
15:59 imirkin: saintdev: what gpu? that page is unfortunately not particularly good at reflecting end-user visible things.
15:59 shakesoda: so something between 3.18 and 3.19 did it
16:01 imirkin: well it did touch a bunch of bo stuff, regarding sync
16:01 saintdev: imirkin: whatever would be able to downclock.
16:02 imirkin: saintdev: what GPU
16:02 saintdev: imirkin: I haven't bought it yet
16:02 imirkin: well, kepler GPU's tend to boot to their lowest perf levels, so no need to worry about downclocking those
16:02 imirkin: like a GK208 you can get fairly cheap i think
16:03 saintdev: something cheap and low power are what I'm looking at
16:03 imirkin: on the order of $50
16:04 saintdev: cool, 208 was one of the ones I was considering :)
16:04 RSpliet: USD, mind you ;-)
16:04 shakesoda: karolherbst: I'm going to re-test some of the pre-3.19 kernels, I don't trust my results
16:04 imirkin: look for a GT 630 or 720 or 730, and make sure it supports PCIe 3.0 and has 384 cores. otherwise it's a fermi and not the one you want.
16:05 saintdev: the fermi ones are the ones that are really power hungry, right?
16:05 imirkin: you can get fanless ones too... i think all those are keplers
16:05 imirkin: not necessarily
16:05 imirkin: the original GF100 was a power-hungry monster, but later chips weren't so bad
16:07 saintdev: well, I mean relatively. the two numbers I saw for TDP(max) were ~25-30 for Kepler chips and ~50 for Fermi(?)
16:07 imirkin: the GK208's are especially low power
16:07 imirkin: lower than GK107's too
16:08 saintdev: that of course doesn't say anything about idle power, but those numbers are more difficult to find on these low end cards
16:08 saintdev: ok, I'll look at GK208 then, thanks!
16:09 imirkin: note that there exist other video card vendors
16:09 imirkin: some are even more open-source friendly than nvidia (if that were even possible)
16:10 imirkin: since this is a server, i assume getting integrated graphics is out, since intel doesn't stick that on their xeon chips
16:12 saintdev: nah, it's a desktop board without integrated graphics. I'm just re-purposing it, because I just replaced it :)
16:12 shakesoda: imirkin: I figured out the actual trigger for the crash on newer kernels - swapping buffers twice in a row.
16:13 imirkin: i wonder what that means
16:13 imirkin: [in terms of how the kernel sees it]
16:13 imirkin: shakesoda: if you have a small repro, that could be helpful
16:13 shakesoda: imirkin: yeah, I'll make one.
16:14 shakesoda: in the meantime I'm re-testing all these kernels, 3.18 doesn't work.
16:14 shakesoda: down the list...
16:14 karolherbst: shakesoda: did you ever bisect the kernel?
16:14 RSpliet: shakesoda: if you're confident with building a kernel of your own, you could consider doing a proper git bisect
16:14 RSpliet: hah, well, that
16:15 RSpliet: if succesful, you can pinpoint the problem to one specific commit using git bisect, rather than a full kernel version :-)
16:20 shakesoda: teach me your ways.
16:21 karolherbst: :D git cloing the kernel is fun
16:21 shakesoda: it's just a lot easier to snag a ton of kernel packages and go through the list instead of waiting for a whole ton of rebuilds
16:21 karolherbst: and which of the 13k commits is the faulty one?
16:22 karolherbst: checking 8 kernels, will only save you 3 rebuilds
16:22 shakesoda: 3.17 is bad too, time for 3.15
16:22 shakesoda: hm
16:23 karolherbst: never underestimate log search functions :)
16:24 karolherbst: if you have to find the bad commit out ot 100k you need 18 rebuilds to be 100% sure?
16:24 shakesoda: 3.15 is good
16:25 shakesoda: so at least that's a search range, 3.15 to 3.17
16:26 karolherbst: yeah
16:26 karolherbst: now git bisect would be handy :)
16:28 imirkin: note that you can restrict the bisect just to, say, drm or even nouveau
16:28 imirkin: which will speed things up considerably
16:29 karolherbst: if you compare against cloning time its not relevant anyway :/
16:29 karolherbst: except your internet connection is damn fast
17:25 shakesoda: I made a test case for it, http://hastebin.com/levetokeju.cpp
17:27 imirkin: shakesoda: what happens when i run that test case?
17:27 imirkin: fireworks, or just app gets killed?
17:28 shakesoda: imirkin: for me it crashes my compositor after 2 seconds (approximately), then if I run it again it will take out X.
17:28 imirkin: heh
17:28 imirkin: in that case i'll hold off on running it :)
17:28 shakesoda: it's a little nasty, yes :)
17:29 imirkin: short-term, you could make your application Not Do That (tm)
17:29 shakesoda: also, that's only if you run it in quick succession. if you wait a short while it'll just take the compositor out again (I'm not even sure it'll take all of them out, but it takes out Gala and so presumably also gnome shell)
17:29 imirkin: well, i don't have a compositor
17:30 imirkin: so i assume it'll go straight onto X
17:30 imirkin: how does it get taken out? segfault? something else?
17:38 shakesoda: http://hastebin.com/ropoxutohu.txt I get this when the app dies
17:38 shakesoda: not a segfault
17:39 shakesoda: I also get this in dmesg, not sure if it's remotely useful: traps: gala[5926] trap int3 ip:7f8fa04cd9c3 sp:7ffd0c900e10 error:0
17:48 imirkin: shakesoda: that's on the wrong end... that's just an X error and your application can't hadnle it
17:49 imirkin: the question is what happens to the compositor or X
17:54 shakesoda: dunno, nothing useful is happening in dmesg or the X log so I have no idea how to debug it.
23:50 mupuf: imirkinm saintdev: I probably meant that i2c- and pwm-based voltage scaling was not supported