00:04 k-man: imirkin, i got the same issue with 2 screens
00:04 imirkin: very odd.
00:11 k-man: this is in debian jessie. maybe its an old version of the driver?
00:12 imirkin: dunno, i don't keep track of debian codenames
00:12 k-man: or maybe its even two slow for 2 screens? but it is dual gpu, quad output, you'd think it would be fast enough.
00:12 k-man: imirkin, how do i tell what version of the driver i'm running?
00:12 k-man: is it in the kernel?
00:13 imirkin: lots of diff pieces
00:13 imirkin: if you're using something like gnome, then mesa could be in play too
00:13 k-man: oh
00:13 k-man: right
00:13 k-man: mesa. i am using gnome
00:14 k-man: Initialized nouveau 1.1.2 20120801 for 0000:06:00.0 on minor 1
00:14 imirkin: that version is ~never updated
00:14 k-man: maybe i shoud try an different wm
00:14 k-man: pauses are about 5 seconds long
00:15 k-man: about every 30 seconds or so maybe
00:15 imirkin: well, when in doubt, i blame the compositor
00:15 imirkin: you could also try disabling glxvblank
00:15 imirkin: as i had previously suggested
00:16 k-man: imirkin, i read that its desabled by default no?
00:16 k-man: but ok, i can try that
00:16 imirkin: it's on by default since 1.0.11 at least
00:16 imirkin: maybe earlier
00:16 k-man: oh, ok
00:16 imirkin: [version of the ddx]
00:16 k-man: ok, its a job for tomorrow. thanks imirkin
00:16 k-man: i'm off, ttyl
03:44 mupuf: gnurou: I got the jetson tk1
03:44 mupuf: it is going to be a busy week end :)
04:08 karolherbst: mupuf: have fun :D
04:09 mupuf: karolherbst: hehe, my goal will be to expose it on wtrpm by the end of the week end
04:09 mupuf: we'll see if this can happen in this time frame as cutting the power may be a bit tricky and I may not have all the components to make it work
04:11 karolherbst: at least you know what you going to do :p
04:12 karolherbst: mupuf: I am really struggeling with a clean and good design of that counter stuff :/
04:12 mupuf: really? Why so?
04:12 mupuf: it is not tied to any context
04:12 mupuf: not tied to any clock
04:12 karolherbst: well, you have to reset the counters
04:12 mupuf: not tied to any batch buffer
04:12 karolherbst: and if there are more than 1 which want to read them, it's getting messy
04:13 mupuf: the only purpose is to poll them every x ms
04:13 karolherbst: yes, but then you have to reset them
04:13 mupuf: yes
04:13 mupuf: poll all of them periodically
04:13 karolherbst: I was already thinking to start a polling alarm in the pmu subdev
04:13 mupuf: when a user asks for a value, return the newest one you got
04:13 karolherbst: copy the values into a struct and then reset
04:13 karolherbst: and having read functions which just read this struct out
04:13 mupuf: yes
04:14 mupuf: I kind of hate this because it adds 10 wake ups per second
04:14 karolherbst: mhh now that I think about that, I can have more than one alarm for that kind of thing :D
04:14 mupuf: but until we have pmu doing it, we are screwed
04:14 karolherbst: mhhh, right
04:14 mupuf: using tasks from the kernel would help with the coalescing
04:14 karolherbst: I was trying to figure out what the blob tells the pmu to do
04:14 mupuf: but ... we cannot rely on it because of our userspace ...
04:16 mupuf: maybe, do not poll the counters if you do not have dynpm enabled
04:17 karolherbst: I also wanted to include this downclock on high temp thing then
04:17 mupuf: if you don't and the userspace requests a value, just block and poll all the counters
04:17 mupuf: and then cache the results for 100 ms
04:17 mupuf: no, don't do that
04:17 mupuf: we have the FSRM for this
04:17 karolherbst: why would userspace ... ohh right, reading out the load might be interessting
04:18 mupuf: yes, you can expose that in the gallium hud
04:18 mupuf: ask hakzsam how to do it
04:18 karolherbst: first I wanted to add a debug fs thingy for that (or internal nvif API)
04:18 karolherbst: didn't thought that far
04:19 karolherbst: it is kind of bothering, that there are fewer counters on tesla
04:20 karolherbst: I think I will rather do that on the pmu from the start
04:21 mupuf: you can't...
04:21 mupuf: well, you can
04:21 mupuf: and I have the code for it
04:21 mupuf: but ... we are stuck on the interface
04:21 karolherbst: right
04:22 karolherbst: but this solves the wakeup issue
04:22 karolherbst: which is kind of important
04:22 mupuf: http://cgit.freedesktop.org/~mperes/nouveau/log/?h=ppwr_rework
04:22 karolherbst: because how does dynpm helps you, if you have 10 wakeups a second anyway
04:23 karolherbst: ohhh, that doesn't like like fun :D
04:24 mupuf: ah ah
04:24 mupuf: yeah, you need to learn how to code in fuc
04:24 karolherbst: I didn't touch assembly so far, oh well
04:26 mupuf: well, I guess we could rebase the code a bit
04:26 mupuf: it should apply quite cleanly
04:26 mupuf: except the last commit, of course
04:28 karolherbst: what is the proper way to call kernel code from the fuc?
04:28 karolherbst: is there some kind of event mechanism?
04:30 karolherbst: mupuf: ohh wait, is thre some kind of script for the .fuc => fuc.h translation?
04:30 AndrewR: karolherbst, hi. you were right, my card can use highest perf level with blob without hanging ... I posted mmiotrace here today, but then I don't even know for what I should look. demmio from envytools decode trace, but then I guess most interesting stuff in those not decoded writes and reads ....
04:30 karolherbst: AndrewR: which card was it?
04:31 AndrewR: karolherbst, same nv43
04:31 karolherbst: okay
04:31 karolherbst: there should be hwsq scripts inside the trace
04:31 karolherbst: you have to find the right one for the highest perf level
04:32 karolherbst: and around that are some reg writes/reg, but understanding this part is required for fixing the clocking code
04:32 karolherbst: I am not sure about nv43, but I think the memory reclocking part is actually inside the hwsq script
04:32 karolherbst: don't know for which regs to search for though
04:32 karolherbst: you may want to dig into the reclocking code in nouveau
04:33 karolherbst: it is in nvkm/subdev/fb/ram....c
04:33 karolherbst: AndrewR: and yes, demmio is the right tool
04:34 AndrewR: karolherbst, yea, no simple way for fixing this ... :} You said my card has different voltage levels for perf 0 (300/1000) and perf 1 (500/1000). Guess I better to find why reading this info failed first?
04:35 karolherbst: yes
04:35 karolherbst: this might actually fix your reclocking issue too :D
04:35 karolherbst: forgot about that
04:39 karolherbst: mupuf: okay, kind of understood your stuff
04:40 karolherbst: mupuf: thing is, the blob actually configures the counters on the cpu side
05:18 AndrewR: karolherbst, in nvkm/subdev/bios/volt.c, function nvbios_volt_parse, case 0x30 mean DCB ver 3.0? If yes - then it only set type and vidmask, not min, max, base and step as 0x40 and 0x50 case ....
05:31 karolherbst: AndrewR: it's okay
05:32 karolherbst: AndrewR: you only have a fixed voltage for each pstate
05:36 pmoreau: Wut?! "dlopen of /usr/lib/xorg/modules/dri/nouveau_dri.so failed (libdrm_amdgpu.so.1: cannot open shared object file: No such file or directory)"
05:37 karolherbst: pmoreau: you need the amdgpu libdrm package
05:37 RSpliet: pmoreau: what does ldd make of nouveau_dri.so ?
05:37 pmoreau: nouveau_dri.so depends on libdrm_amdgu.so.1? (and so does swrast_dri.so)
05:37 karolherbst: pmoreau: it's normal
05:37 RSpliet: no it isn't
05:37 pmoreau: O.O
05:37 karolherbst: it is
05:37 RSpliet: that sounds like a horrible linking problem
05:37 karolherbst: big driver thingy
05:37 pmoreau: Hum...
05:37 karolherbst: everyting compiled into one binary
05:37 RSpliet: then that should be "dri.so", not split up amongst several modules
05:38 karolherbst: the same for the classic drivers
05:38 pmoreau: I'm waiting for the moment when the NVidia blob depends on AMD Catalyst! :D
05:38 karolherbst: pmoreau: the gallium river binaries should be the same
05:38 karolherbst: *driver
05:38 karolherbst: RSpliet: yeah I know
05:38 karolherbst: RSpliet: but for some reasons, benchmark said, that one big driver is faster
05:39 karolherbst: because of in binary optimisation and stuff
05:39 RSpliet: for dri that shouldn't make much of a difference
05:39 RSpliet: for mesa it should
05:39 karolherbst: /usr/lib/xorg/modules/dri/nouveau_dri.so is the mesa driver
05:39 karolherbst: ohh wait
05:40 karolherbst: yeah, it should be
05:40 pmoreau: Oh, for some reason I had a libdrm-git package installed, which was stuck at 2.4.58... --"
05:40 karolherbst: RSpliet: the libdrm libs are usually in /usr/lib/
05:40 RSpliet: yes, got it
05:40 RSpliet: nouveau_dri is the mesa component
05:41 karolherbst: pmoreau: :)
05:42 pmoreau: Yeah! Works much better now :-)
05:44 nchauvet:looked at this also ^^
05:45 nchauvet: using pmap xorg pid, I found that r600_dri.so only is loaded in my case (which is accurate) but libdrm_intel.so and libdrm_nouveau also are
05:46 nchauvet: along with llvm-3.5.so which should not be used (unless for optinal fallback)
05:47 karolherbst: nchauvet: it is fine
05:47 pmoreau: Couldn't the llvm-3.5.so also be used by clover, and so by r600_dri as well?
05:47 karolherbst: pmoreau: llvm is usually used by llvmpipe
05:47 karolherbst: so it is in the gallium drivers anyway
05:47 pmoreau: Right, by the Radeon driver will also use it for OpenCL
05:48 karolherbst: yes
05:48 karolherbst: mesa should use symlinks for the drivers :/
05:49 karolherbst: I know it is not much, but for me that just means 27Mb saved
05:49 pmoreau: That's already quite nice!
05:50 karolherbst: I only have intel and nouveau installed
05:50 karolherbst: and gallium software
05:50 karolherbst: ohh nouveau_vieux too
05:50 karolherbst: I don't want that :D
05:51 RSpliet: is there already a nouveau_ancien for Riva 128?
05:52 nchauvet: karolherbst, >mesa should use symlinks for the drivers :/
05:52 nchauvet: karolherbst, they are using hardlinks actually
05:54 nchauvet: and readelf -a r600_dri.so |grep SONAME indiquates gallium_dri.so
05:54 karolherbst: ohhhh
05:54 karolherbst: why not symlinks?
05:54 karolherbst: hardlinks are a bit, well, messy to deal with
05:55 karolherbst: imagine you install a local build over the driver and just update part of the drivers
06:08 AndrewR: karolherbst, so, looking at nvkm/subdev/gpio/nv10.c func nv10_gpio_sense . I should look (in decoded mmiotrace) for reads from 0x600818 and 0x60081c ?
06:08 karolherbst: AndrewR: it might in hwsq scripts though
06:09 karolherbst: so better look for "600818"
06:13 AndrewR: karolherbst, http://www.fpaste.org/276390/ - not so much (last instances appears unrelated - just timestamp happens to have same string)
06:15 karolherbst: AndrewR: you have to find the gpio writes
06:16 karolherbst: search for PGPIO
06:16 karolherbst: I think 0x2 and 0x3 are your voltage gpios
06:16 karolherbst: these are the important regs
06:17 karolherbst: AndrewR: can you upload the trace somewhere?
06:19 AndrewR: karolherbst, http://s000.tinyupload.com/index.php?file_id=07309909598025436542 ?
06:20 karolherbst: please use xz in the future :)
06:21 AndrewR: karolherbst, nothing for PGPIO (at least in decoded version - using simple 'grep PGPIO')
06:21 AndrewR: karolherbst, xz a bit slow, but ok
06:21 karolherbst: I am pretty sure it is in the hwsq script already
06:21 karolherbst: AndrewR: 1. space 2. decompression speed
06:23 karolherbst: AndrewR: gzip: 13435473 xz: 5477816
06:23 karolherbst: size in bytes
06:24 AndrewR: karlook, will use it even on this slow machine
06:24 AndrewR: karolherbst,
06:25 karolherbst: yeah, I know it takes some time to decompress with xz, but these traces are usually stored somewhere in the internet so that nouveau devs can access it. Cutting size more than half is really usefull there ;)
06:25 AndrewR: karolherbst, http://www.fpaste.org/276395/ - grep for GPIO resulted in just two lines
06:26 mupuf: karolherbst: hey, I'm back
06:26 karolherbst: mupuf: hi
06:26 karolherbst: mupuf: currently debugging nv43 voltaging problems .D
06:27 mupuf: there is no RPC, aside from the event mechanism found in the code of the OS
06:27 mupuf: "OS"
06:27 karolherbst: yeah, but can the binary tell the CPU somehow when it is done executing?
06:27 karolherbst: something like that
06:29 mupuf: yes, we can send IRQs to the host
06:29 mupuf: it is super easy
06:30 karolherbst: it is possible, that between the 0.1 secs the host didn't read the results?
06:30 karolherbst: or what happens when the next binray runs overwrites the reg while read out by the host?
06:30 mupuf: but hey, what is the purpose of reading the counters from pdaemon if you are going to wake up the cpu every 100ms anyway?
06:31 karolherbst: mupuf: my first step would be to notify the host every 0.1 seconds about the results and just kprint them :D
06:31 mupuf: ok
06:31 karolherbst: mupuf: I move the algo inside pdaemon?
06:31 mupuf: sure
06:31 karolherbst: and just wake up when something changed
06:31 karolherbst: like if another perf state is requested
06:31 karolherbst: I just need to store the current state for pdaemon somehow
06:31 mupuf: when you reach a threshold, you need to post a message to the cpu to upclock
06:31 karolherbst: yes
06:31 mupuf: or downlock
06:32 mupuf: but before we reach this point, we need to find out the best thresholds
06:32 karolherbst: I also have to post to what the cpu has to clock
06:32 mupuf: and nvidia is pretty nice at upclock more or less fast depending on how far you are from the threshold
06:32 karolherbst: mupuf: well I have a highly modified gk20a algo :D
06:32 karolherbst: mupuf: I know
06:32 karolherbst: I have a 2 sec "safety pause" before downclock
06:33 karolherbst: but after a downclock, I will further downclock 0.5 secs later
06:33 mupuf: oh, 2s is aggressive already, how long is nvidia's?
06:33 karolherbst: maybe 5?
06:33 karolherbst: or 10?
06:33 karolherbst: too long :D
06:33 mupuf: well, it depends how fast you upclock
06:33 mupuf: and I am sure there are workloads that need this
06:34 karolherbst: yeah, I ignore 20 ticks before downclock
06:34 mupuf: and we need to talk with nvidia if we want to change it
06:34 karolherbst: mupuf: mhh the algo has two kinds of upclocking
06:34 karolherbst: 1. go near target
06:34 karolherbst: 2. go max
06:34 karolherbst: if the load reaches a specific value, it goes to max directly
06:34 karolherbst: currently above 95%
06:34 mupuf: yes
06:34 mupuf: that is good
06:34 karolherbst: target is 80% though
06:35 karolherbst: and this is pretty safe already
06:35 karolherbst: I usually have 4-5 cstates buffer to perf drops
06:35 mupuf: 80 is pretty high, but could be good!
06:35 mupuf: let's talk about that later, I am still at work
06:35 karolherbst: k
08:46 karolherbst: mupuf: the thing is, I was thinking to adjust the targets depending on "power modes" we want to use. with powesave we increase the target and with perf we lower it. And so I try to figure out a value which is high enough, but safe, so that we have a good value for powersave. With perf it really doesn't matter, so we can use something like 50 to be 100% safe
08:50 mupuf: powersave should be more aggressive time-wise, not with the thresholds
08:50 mupuf: as in, faster downclocks
08:51 karolherbst: mhh okay
08:51 mupuf: but again, this is something that needs to be benchmarked
08:51 karolherbst: yeah
08:51 karolherbst: to benchmark this, we need the cstate interface too
08:51 karolherbst: ohh well
08:51 karolherbst: we could simply switch to highest pstate
08:52 mupuf: we should make an apitrace of a browser
08:52 mupuf: since this is a common case that is ANNOYING for PM
08:52 karolherbst: :D
08:52 karolherbst: okay
08:53 mupuf: browsers are really the most dynamic tasks I can think of
08:53 karolherbst: I usually care more about laptops and are there any laptops with gt215 main gpus?
08:53 karolherbst: yeah
08:53 mupuf: yes
08:53 karolherbst: having a 0.4s max latency for required speed is a bit high then
08:54 karolherbst: ohh no, max latency is much higher
08:54 karolherbst: if the load stays underneath the max_load value
08:54 karolherbst: okay, I may do some browser testing then
08:54 mupuf: yes, life is hard, right? :D
08:55 mupuf: we may drop the polling period to 16ms if needed
08:55 karolherbst: currently I am occupied to get cm working on a htc m8s :D
08:55 mupuf: cm?
08:55 karolherbst: cyanogenmod
08:55 mupuf: :)
08:55 mupuf: have fu!
08:55 karolherbst: there are some EGL driver issues :D
08:56 karolherbst: surfaceflinger is crashing while calling eglCreateWindowSurface
08:57 mupuf:is more boring with his phone
08:57 mupuf:uses a jolla phone
08:58 karolherbst: :D
08:58 karolherbst: currently I have a m7
08:58 karolherbst: is sailfish any good?
09:23 mupuf: karolherbst: I love it, especially since the update!
09:23 karolherbst: I see
11:10 karolherbst: mupuf: how do I get the fuc code compiled?
11:10 imirkin: envyas
11:10 imirkin: works the same way as envydis
11:11 imirkin: except in reverse :)
11:12 karolherbst: ohhh
11:12 karolherbst: okay
11:12 karolherbst: :D
11:27 imirkin: someone even wrote a falcon backend for llvm i think, although it didn't quite work
11:27 imirkin: or... something
11:32 karolherbst: mhhh
11:32 karolherbst: somehow I do something wrong
11:33 imirkin: somehow.
11:33 karolherbst: when I do like "envyas -m falcon gf100.fuc3" I get syntax error
11:36 imirkin: -V fuc3
11:38 karolherbst: doesn't change anything
11:39 karolherbst: or do I have to preprocess the file furst?
11:40 imirkin: if it has cpp stuff, yes
11:41 karolherbst: mhh okay
11:41 imirkin: this is an assembler, no frills. it does know about comments, that's about it.
11:41 imirkin: look at the makefiles in the kernel -- they pass the fuc file through cpp first
11:41 karolherbst: cpp throws out these # 1 "gf119.fuc4" though
11:41 karolherbst: how can I get rid of them?
11:41 karolherbst: ohhh
11:41 karolherbst: there are makefiles for fuc? didn't found them
11:42 imirkin: there were.
11:42 imirkin: someone killed them :(
11:42 imirkin: skeggsb_: ---^
11:42 imirkin: please unkill those makefiles
11:43 karolherbst: so in the old tree there are still there
11:43 imirkin: hmmmmm am i misremembering?
11:43 karolherbst: with 4.1 there are not there
11:43 imirkin: heh
11:45 imirkin: i coulda sworn there was one
11:45 imirkin: but maybe not
11:47 imirkin: aha!
11:47 imirkin: origin/linux-3.12::nvkm/engine/graph/Makefile.am: cpp -Ifuc -CC $< | cpp | sed -e '/^#/d
11:47 karolherbst: I did grep -v \#
11:47 karolherbst: :D
11:48 imirkin: looks like it disappeared in 4.0
11:48 karolherbst: okay, this looks better
11:48 imirkin: still there in 3.19
11:49 karolherbst: okay, works
11:49 karolherbst: kind of
11:49 karolherbst: imirkin: how is the envyas call?
11:49 karolherbst: imirkin: maybe it was removed, because it required envytools?
11:51 imirkin: no. coz he converted everything to Kbuild
11:52 karolherbst: ohh okay
11:56 karolherbst: imirkin: okay, envyas needs -a -w
11:57 karolherbst: yay, no diff to the files inside the tree
11:57 karolherbst: :)
12:16 karolherbst: mupuf: do you want to rebase your code or shall I do it? Allthough I won't have time for that today, so it is a bit up to you know to decide
12:17 karolherbst: maybe I just do something from scratch anway?
12:17 karolherbst: *anyway
12:58 hakzsam: imirkin, http://cgit.freedesktop.org/mesa/mesa/commit/?id=47d11990b2ca3eb666b8ac81fee7f7eb5019eba1 has introduced some regressions, for example piglit test 'bin/texelFetch fs sampler2D 281x1-281x281 -auto -fbo' now fails with 'Assertion `PUSH_AVAIL(push) >= 5' failed'
12:59 AndrewR: karolherbst, stupid question, but how to extract (or find at first) those hwsq scripts? nvbios can't see them in bios image, and grep'ing demmio output only resulted in few lines like [0] 437.776201 MMIO32 R 0x001098 0x21ca0604 PBUS.DEBUG_6 => { HWSQ_OVERRIDE_MODE = READ_NORMAL | 0x21ca0604 }
12:59 imirkin: hakzsam: that's... unfortunate.
12:59 hakzsam: yeah
12:59 imirkin: i guess there's a spot or two that i missed =/
12:59 hakzsam: a push_space is probably missing somewhere
13:00 imirkin: there are a few manual calls to nouveau_pushbuf_space
13:00 hakzsam: yeah
13:00 imirkin: AndrewR: huh, i thought hwsq was a nv50 thing
13:00 imirkin: hakzsam: what's the backtrace?
13:01 hakzsam: sec
13:01 imirkin: hakzsam: fwiw i don't get a backtrace
13:01 AndrewR: imirkin, well, I was thinking the same. But then - what indicates reclock seq on nv4x ? (in mmiotrace)
13:01 imirkin: AndrewR: just various register writes... nv4x was a lot simpler
13:01 hakzsam: imirkin, http://hastebin.com/unupolotib.vhdl
13:02 imirkin: AndrewR: but i'm no expert
13:07 hakzsam: imirkin, is that possible to emit two fences consecutively without a push_space in between? If so, we're going to have a serious issue with patch I think
13:08 hakzsam: because now you never allocate space in nvc0_screen_fence_emit()
13:09 imirkin: hakzsam: well, allocating space in emit isn't going to work in the first place
13:10 imirkin: although the fact that it fails via nvc0_cb_bo_push isn't surprising
13:11 hakzsam: imirkin, why is it not going to work?
13:11 imirkin: because push_space can indirectly call the kick handler
13:11 imirkin: which in turn emits a fence
13:11 imirkin: which in turn... etc
13:12 hakzsam: okay, makes sense
13:13 imirkin: what's esp odd is that i don't hit this =/
13:14 imirkin: hakzsam: do you hit this on master, or just in your branch?
13:14 hakzsam: master
13:14 hakzsam: when I tried to do a full piglit run for my "split" series
13:14 imirkin: i have some local patches, rebuilding master now
13:14 imirkin: what gpu is this on?
13:14 hakzsam: imirkin, btw, you didn't run piglit for your patch, right? :)
13:14 hakzsam: GF110
13:15 hakzsam: and GF108
13:15 imirkin: hakzsam: i often skip it :) but i'm on a GF108 and having trouble reproducing, so dunno if that would have helped much
13:15 hakzsam: it's always reproducible on my gf108
13:16 hakzsam: if you can't really reproduce that issue, let me know and I'll do the tests for you
13:38 hakzsam: imirkin_, well, my piglit run always fails, that's unfornate
13:38 hakzsam: I used " ./piglit-run.py -x glx -x streaming-texture-leak -x max-texture-size -x texelFetch -1 --dmesg"
13:38 hakzsam: do I need to add other options to avoid that?
13:38 hakzsam: on GF110 btw
13:52 imirkin: i don't get how this is happening :(
13:53 hakzsam: that's strange
13:56 imirkin: nor do i get why it was working before
13:58 imirkin: oooohhhh.... there are other ways to emit a fence i bet
13:58 hakzsam: like what? :)
13:58 imirkin: like nouveau_fence_wait
14:00 hakzsam: mmh
14:00 imirkin: so basically it needs a way to tell if it's being called as a result of the callback or not
14:11 imirkin: this feels like such a hack =/
14:12 hakzsam: you already have a fix?
14:13 imirkin: working on one
14:13 imirkin: but i'm hating the way i'm doing it
14:17 hakzsam: :)
14:23 hakzsam: imirkin, how do you find the first of a piglit run which crashes X?
14:23 hakzsam: +test
14:24 imirkin: hakzsam: max-texture-size or streaming-texture-leak (iirc) are the two good candidates
14:25 imirkin: hakzsam: you can look in the log though -- they're stored sequentially, just look at where they start dying
14:25 hakzsam: I used "./piglit-run.py -x glx -x streaming-texture-leak -x max-texture-size -x arb_texture_multisample-texelfetch -1 --dmesg"
14:25 mdolezel: hi someone using t440p with nvidia gpu?
14:26 imirkin: hakzsam: why the texelfetch exclude?
14:27 hakzsam: imirkin, I thought it crashed the run but I'm not sure
14:27 hakzsam: I'l look at the results.json
14:27 mdolezel: some more info https://paste.fedoraproject.org/276643/
14:28 imirkin: mdolezel: are there any questions?
14:34 mdolezel: imirkin, sorry my connection is somehow unstable today
14:35 mdolezel: imirkin, i have asked if someone is using t440p with nvidia gpu
14:36 imirkin: mdolezel: just taking a poll?
14:38 mdolezel: imirkin, yes
15:14 skeggsb_: imirkin: they're still built (lib/Makefile)
15:14 imirkin: skeggsb_: ah ok
15:15 imirkin: aha, and you changed the command to not invoke cpp directly which defeated my grep
15:30 mdolezel: seriously no one with t440p and nvidia crap?
16:50 pmoreau: Finally got the SPIR-V binary from clover to Nouveau... :|
16:51 pmoreau: Next step: deal with inputs/outputs
17:02 diegoviola: how nouveau will be on a gtx 460?
17:02 diegoviola: is that fermi?
17:06 imirkin: diegoviola: it should operate it fine
17:06 diegoviola: ok thanks
17:06 imirkin: diegoviola: no reclocking though
17:06 diegoviola: ok
17:06 imirkin: diegoviola: so you're stuck to whatever the boot clocks might be
17:06 imirkin: usually middle or low for fermi
17:06 diegoviola: ok
17:06 diegoviola: ty
17:43 AndrewR: oops, I pasted this as 'private', hope it still readable if you follow url? (just grep'ing around in mmiotrace) http://www.fpaste.org/276706/51319144/
18:20 AndrewR: interesting, nv10.c in subdev/gpi doesn't have .reset function defined, unlike other files (nv50, gk104, g94, gf119). Does this mean gpio doesn't need reset here (on nv < 50), or it simply missing? Can lack of reset explain read failures?
18:20 AndrewR: *subdev/gpio
18:21 skeggsb_: AndrewR: that exists solely to support the devinit opcode that needs it, and that's never present before g80 that i've seen
18:23 AndrewR: skeggsb_, thanks ...
18:36 k-man: is xfce4 2d acceleration only?
18:39 imirkin: ask the xfce guys?
19:10 k-man: imirkin, i turned off the glxvblank thing and touch wood, i think that has fixed it
19:10 k-man: xfce4 also exhibted the pausing problem (hence my question about 2d and 3d)
19:10 k-man: how do i get the xrandr settings to stay fixed?
19:11 imirkin: don't know that there is a way to do it generically
19:13 k-man: ok
19:38 k-man: hmm... i got the hang again
19:38 k-man: but it seems less frequent
19:38 k-man: oh, maybe not... *sigh*
19:54 AndrewR: hm, nvkm_volt_get (in 4.3 http://cgit.freedesktop.org/~darktama/nouveau/tree/drm/nouveau/nvkm/subdev/volt/base.c ) apparently can't return -ENODEV anymore, yet nvkm_volt_init still checks for this and prints exactly "current voltage unknown\n"
19:54 AndrewR: in 4.2 http://cgit.freedesktop.org/nouveau/linux-2.6/tree/drivers/gpu/drm/nouveau/nvkm/subdev/volt/base.c?h=linux-4.2
19:59 k-man: could it be a gpu tepmerature issue?
20:06 k-man: is there a mailing list I can email about this pausing issue?
20:12 imirkin: sure, you can mail nouveau@lists.freedesktop.org. but you're not going to get a different audience.
20:36 k-man: imirkin, hehe ok
20:36 k-man: imirkin, i'm at a loss as to what else i can do to debug. oh, i didn't try that kernel parameter you mentioned
20:36 k-man: i had to switch back to the nvidia driver and 2 screens. need to do some real work
21:02 k-man: is there a 3 or 4 port card that is known to work well?
21:02 k-man: maybe my card is just too old and not supported well
21:04 imirkin: dunno, my G98 worked fine. but i've not run multiple monitors off of nouveau in a while
21:11 k-man: yeah, without having more hardware its hard to know
21:11 k-man: maybe driver age? is there a live distro with very recent drivers i can try?
21:32 AndrewR: ok, I've added some debug: http://www.fpaste.org/276752/ and then get this output [ 9.074765] nouveau 0000:01:00.0: volt: Volt->vid_nr, 0
21:36 AndrewR: so, it never reaches code inside 'for (i = 0; i < volt->vid_nr; i++)' structure
21:36 AndrewR: but why volt->vid_nr can be 0 ?
21:42 AndrewR: http://cgit.freedesktop.org/~darktama/nouveau/tree/drm/nouveau/nvkm/subdev/volt/base.c - so, looking at nvkm_volt_parse_bios i think my case must be at line 133 (} else if (data && info.vidmask) { ).
22:24 RSpliet: skeggsb_: mind getting back on the patches I sent 10 days ago?
22:38 AndrewR: with this debug patch http://www.fpaste.org/276783/ I only get " nvbios_volt_parse called!" but not "nvbios_volt_entry_parse called", nor any of "info.base and info.step were set\n" or "info.vidmask was set\n" printks
23:11 AndrewR: and I did it wrong? added printk + printk("volt_table_Version: %d\n", !!volt * *ver); resulted in " volt_table_Version: 0"
23:32 AndrewR: tadam! nvbios_volt_table_Ver, 16
23:35 AndrewR: by simply adding + printk ("nvbios_volt_table_Ver, %d\n", *ver); into nvbios_volt_table in /drm/nouveau/nvkm/subdev/bios/volt.c . Now .... lets guess where I should put this additional case. May be default debug printk should be added for catching this in the future