00:13 karolherbst: yeah well
00:13 karolherbst: at least metro killed his box I guess
03:41 dardevelin: hello eveyrone
03:41 dardevelin: *everyone
03:41 dardevelin: any ideas on GTX850 status ?
03:41 dardevelin: m to be more precise
04:29 skeggsb: imirkin: try poking bit 0 of 0x50405c for the fermi tf thing
04:41 huelter: imirkin: managed to hang the system even with the new reclocking (karol's v4) and increasing voltage. Don't know what else to do. https://bugs.freedesktop.org/show_bug.cgi?id=95031
08:29 karolherbst: mupuf: could you think of any value, why nouveau should clock the card below the lowest cstates even if it means keeping the same voltage?
08:29 karolherbst: like it would be for my card 135MHz instead of 405MHz
08:29 martm: karolherbst: due to some sceptisism i faced i managed to read some more, and generally speaking i finally understood that there is no reordering needed and final draft:D/revision/version of the scheme is ready
08:30 martm: this stuff really should work very simply and effeciently, i understand that more powerful gpu's have more SM's probably
08:34 martm: so the method i arrived couple weeks ago is fairly awesome, since that is so simple, there could be a chanche that i find time to fixup all things i need even, when i do i merge to master too
08:35 martm: actually i won't i'll find someone here who would do that on their name, some prestigic dev, i don't want to tie myself to the development
08:35 martm: too late for that...
08:39 karolherbst: uhhh
08:39 karolherbst: gm108 support landed
08:41 martm: cheers.
09:09 karolherbst: nice, my code doesn't seem to break my nvac :D
09:10 RSpliet: karolherbst: you mean the load-based clock switching?
09:10 RSpliet:crosses fingers
09:10 karolherbst: no, the fermi+ volting code
09:10 RSpliet: oh
09:10 RSpliet: hah
09:10 RSpliet: NVAC doesn't touch voltages
09:10 karolherbst: yeah, it shouldn't break older chips
09:10 RSpliet: ever
09:10 karolherbst: but
09:10 karolherbst: I touch like volt/base, clk/base....
09:10 karolherbst: a lot
09:10 karolherbst: :D
09:10 karolherbst: even therm/base
09:10 RSpliet: try anything that isn't an IGP
09:11 karolherbst: well what I don't touch is memory
09:11 RSpliet: NVAC doesn't change voltages
09:11 RSpliet: ever
09:11 RSpliet: there's no code for that
09:11 karolherbst: ohhh right
09:11 karolherbst: I see it now
09:11 karolherbst: sensors doesn'T return any voltage
09:12 karolherbst: well I have also my nvc1 here
09:12 karolherbst: let's enable engine recocks there and see how that goes
09:13 karolherbst: but
09:13 karolherbst: it has the same code path as my kepler...
09:13 karolherbst: stupid fermi card, why does it have the new tables :D
09:14 karolherbst: it actualy has GPUBoost implemented in the vbios
09:14 karolherbst: 660 MHz base, 800MHz boost clock :)
09:17 karolherbst: well I tested the code already on like 5 fermis anyway
09:20 karolherbst: mupuf: I think this 0x122634 reg is only used for the speedo fuse though
09:20 karolherbst: ohh
09:20 karolherbst: there are more regs
09:20 karolherbst: one for each fuse reg
09:20 karolherbst: 0x0212d4 -> 0x122638 and 0x0214a8 -> 0x122634
09:21 karolherbst: like that doesn't look any random
09:23 karolherbst: mhh I have an idea
09:26 karolherbst: mhhh
09:27 karolherbst: 0x0212d4 looks also like some hw specific value
09:27 karolherbst: maybe those 0x12263* regs activate some kind of sensor on the gpu?
09:28 karolherbst: and it is just a few ms before the speedo
09:36 karolherbst: mupuf: yeah I only see those writes for those two FUSE regs :/
09:45 karolherbst: 0x122600-0x12263c contains some sort of the same type of reg
09:45 karolherbst: *contain
09:45 karolherbst: at least nvascan returns the same for each
09:45 karolherbst: 122600: 00000000 800ffeff 00000000
09:46 karolherbst: and poking 0 into 122640 upsets the GPU
09:49 karolherbst: hehe, funny regs
10:00 martm: karolherbst: jou dude, did you inspect those sched codes, can you give me an example what they look like, so they fit into word or dw/doubleword?
10:01 martm: i mean what happens does it declude/remove some other parameter cause of the sched operand?
10:15 martm: https://github.com/NervanaSystems/maxas/wiki/Control-Codes right, a control code for every 7 instructions
10:15 martm: yay, that is wonderful, i can beat it
10:26 martm: like ed sheeran said, i am out of sight i'm out of mind, i'll do it all for you on time, and out of these things i've done i think i love you better now:D:D
10:38 karolherbst: ugh... https://gist.github.com/karolherbst/41f8b7cebd315a97293061d71e2be510
10:38 karolherbst: imirkin: that is what happens on the syscall level in metro
10:38 karolherbst: and like hundreds of those
10:39 karolherbst: and I guess those SHARED maps are only freed at exit :/
10:39 karolherbst: yeah
10:41 martm: karolherbst: right, but what is the outcome of those a deadlock?
10:43 karolherbst: imirkin: update with the gl calls: https://gist.github.com/karolherbst/41f8b7cebd315a97293061d71e2be510
10:44 martm: yeah well 18th of array buffers gets stucked somehow, karolherbst: how did you get this stuff?
10:44 martm: metro what is it?
10:45 karolherbst: last light
10:46 martm: karolherbst: am i right that this results in cpu lockup?
10:46 karolherbst: martm: no, excessive memory allocations in the kernel
10:47 martm: ouh that is kinda bad another bug inside nouveaus gallium interface
10:50 karolherbst: imirkin: :D funny, how intel does this: after glBufferData nouveau maps, unmaps, but Intel just unmaps the glBindBuffer area, but they seem to never map any RAM after glBufferData. Most likely because the intel gpu uses sys ram I would assume
10:50 karolherbst: mhh but metro reuses the same buffer over and over again
10:50 martm: karolherbst: so this happens all in single thread right?
10:51 martm: karolherbst: happens also on intel?
10:53 martm: karolherbst: this should be a kernel bug
10:53 martm: kernel does like relocate the buffer, and get handle back to userspace as i remember, but somehow it does not get that message back
10:54 martm: so it allocates again and again
10:54 karolherbst: no it doesn't happen for intel, and it is an userspace bug
10:57 martm: a userspace bug you think, then it could not work for other buffers too i belive, but not sure
10:57 martm: karolherbst: lets bet on one beer:)!
11:00 mupuf: karolherbst: hmm, I will check again the mmiotrace I checked, it would be weird if I only saw these two
11:00 mupuf: I checked the nec4/mupuf one
11:00 karolherbst: yeah me too
11:00 karolherbst: anyway
11:00 karolherbst: my results: https://gist.github.com/karolherbst/9750829926c3f04575ec608707d99b66
11:00 martm: but yeah could be that gallium does not increment the index somehow
11:08 martm: lets not bet:)
11:12 martm: karolherbst: this isn't free game right, cause i on cinnamon could step through it in windowed mode, and see where it is failing
11:12 martm: though i don't want to do that...but..., you see
11:14 karolherbst: imirkin: okay, it happens inside nouveau_transfer_staging
11:14 karolherbst: imirkin: "if ((size <= NOUVEAU_TRANSFER_PUSHBUF_THRESHOLD) && permit_pb)" else branch taken
11:16 martm: karolherbst: this metro stuff happens there?
11:17 karolherbst: imirkin: and size is either 91980800 or 21390336
11:17 fishxz: hey, even by setting "Option "GLXVBlank" "on"" i have tearing, but glxgears for example is capped to 60 fps.
11:18 karolherbst: fishxz: well check your compositor settings
11:18 fishxz: the interesting thing is. on gnome vsync is enabled by default on the nvidia driver, but doesnt seem to work for nouveau.
11:18 karolherbst: uhh
11:20 martm: + /* If the GPU is currently reading/writing this buffer, we shouldn't
11:20 martm: + * interfere with its progress. So instead we either wait for the GPU to
11:20 martm: + * complete its operation, or set up a staging area to perform our work in.
11:22 martm: still sounds like kernel, beers to me, thanks:)!
11:22 martm: ok ok
11:22 karolherbst: imirkin: :D tx->base.box.width is 21390336
11:22 karolherbst: isn't that a bit.. huge?
11:40 martm: ouh did couple of beers so tired, have not found a clue yet, doing kwrite nouveau_buffer.c
12:46 karolherbst: RSpliet: we have the vbios now with the 100MHz memory clock
12:47 karolherbst: I've put it in the repository already
13:19 RSpliet: karolherbst: thanks, I'll take a peek
13:26 imirkin: karolherbst: yeah, there's a special path for tiny buffers... 9MB and 2MB don't qualify :)
13:28 bozhan: карол
13:28 bozhan: karolherbst: :)
13:35 karolherbst: imirkin: right :) but as it seems those buffers are never unmaped :/
13:35 imirkin: karolherbst: right, we never unmap bo's until they are destroyed
13:35 karolherbst: well at exit time they are
13:35 imirkin: mapping is not a free operation
13:35 karolherbst: right, but into the gl options always the same buffer is passed
13:35 imirkin: you could try to change that policy and unmap
13:35 karolherbst: *calls
13:36 karolherbst: mhh where would be the best place to do so?
13:36 imirkin: dunno
13:36 imirkin: weird that we *never* unmap those bo's... they should get free'd eventually
13:36 karolherbst: right, but we are just memcpy them anyway
13:37 karolherbst: we could do something like if big enough we immediatly unmap, because the memcpy is the more expensive operation anyway
13:37 karolherbst: ohh wait
13:37 karolherbst: the memcpy was something else
13:38 karolherbst: I should check from where nouveau_transfer_staging is called
13:38 karolherbst: imirkin: well, those buffers aren't unmaped through opengl
13:38 karolherbst: and it happens real fast
13:39 karolherbst: 5GB are getting allocated in like 10 seconds
13:39 imirkin: good luck debugging.
14:20 karolherbst: imirkin: uhh nouveau_buffer_transfer_map -> buf->domain == NOUVEAU_BO_VRAM -> usage & NOUVEAU_TRANSFER_DISCARD usage & PIPE_TRANSFER_DISCARD_WHOLE_RESOURCE) buf->status &= NOUVEAU_BUFFER_STATUS_REALLOC_MASK
14:21 karolherbst: with the comment about copying back to VRAM on unmap
14:41 martm: imirkin: i am watching snooker, will look maybe later, but weird is that it does not unmap if so, but even weirder is why does it rellocate or remap all the time the that single buffer
14:43 martm: they mentioned that snooker star judd trump said , drinks on me if i get out of this jail, being 3-7 down to liang wenbo
14:43 martm: now it's 7-7 a possibility to get some drinks;)
14:54 martm: karolherbst: can i get this code you are running from somewhere, i.e that game or demo for free?
15:04 martm: obviously there is no recursion spottable right away but, it does not free something, so some buffer variable comes back with the same pointers , and just is allocated once again, karolherbst: nice would be to make a breakpoint to the staging function and then step forward line by line
15:09 martm: it's all in nouveau_buffer_transfer_map -> nouveau_buffer_vbtl -> nouveau_buffer_create kinda flow graph, me wonders if reallocate is recursive
15:10 martm: nouveau_buffer_allocate that calls nouveau_buffer_reallocate from nouveau_buffer_create is indeed recursive
15:19 martm: damn drifting away from drinks:) again but still 8:8
15:23 martm: looks like a kernel one, i dunno for some reason probably line 51 fails that filles some &buf->bo , it's in file nouveau_buffer.c line 51
15:29 heiko: hello
15:29 heiko: on kernel 4.5 i can not find cat /sys/class/drm/card0/device/pstate for reclocking my gtx 670
15:29 prg: it's now in debugfs
15:30 prg: if it's mounted, just try find /sys/ -name pstate
15:32 heiko: hmmm
15:32 martm: karolherbst: yeah it's all way to the kernel in nouveau.c and abi16.c from nouveau_bo_new that is defined in nouveau.c in drm, and included and called from mesa
15:32 heiko: what is -name ?
15:33 heiko: nouveau.pstate is set
15:33 martm: karolherbst: but surely before i can't run the code, i am not sure if this is the path that fails for you
15:33 pmoreau: heiko: Look into /sys/kernel/debug/dri/0
15:34 pmoreau: Or maybe /sys/kernel/debug/dri/1, depending if you also have an Intelcard
15:34 pmoreau: and you do not need th nouveau.pstate any longer
15:35 heiko: ok thanks
15:35 heiko: i change my script
15:59 n00000b: Hey guys im just trying out the new ubuntu which uses nouveau for my nvidia card, but i get a lot of graphics glitches
15:59 n00000b: will nouveau ever support GT215 properly or is that a dead end?
16:00 n00000b: if so are there any cards which are supported properly by nouveau for production usage?
16:04 n00000b: all i get from dmesg is this http://pastebin.com/PZdcyBqA
16:06 imirkin_: n00000b: not sure what you mean by "production"
16:06 imirkin_: n00000b: is this a GT215 with GDDR5 vram by any chance?
16:07 n00000b: imirkin_: yes thats correct GDDR5 version
16:07 n00000b: gainward something
16:07 imirkin_: congrats on finding the *most* unsupported card by nouveau
16:07 imirkin_: ;)
16:08 imirkin_: quite the achievement, those GT 240's are relatively rare
16:08 imirkin_: i have one in my system actually, and it's gotten a LOT better - used to lock up immediately on load
16:08 imirkin_: now it kinda-sorta works
16:08 imirkin_: but as you've discovered, not really
16:09 n00000b: it says something about this card before on boot http://pastebin.com/R0rRcDRS
16:10 imirkin_: yeah, that's basically the same one i have, except mine is 512MB vram
16:10 imirkin_: anyways, those GDDR5 ones have forever been problematic
16:10 n00000b: yes i can get a gui which made me hope i can use nouveau eventually
16:10 imirkin_: i dunno what you mean by 'production', but probably the best supported gpu's right now are from the kepler family
16:10 imirkin_: that's GTX 6xx and 7xx
16:11 Tom^: its all a matter of amount of donated whiskey sent to imirkin_
16:11 n00000b: haha :)
16:11 imirkin_: doesn't mean that they're *well* supported, just... best supported :)
16:11 imirkin_: if you're looking for actual support, i recommend switching to AMD
16:12 imirkin_: (or intel, but i'm guessing your 3d needs go beyond what their hw provides)
16:13 Tom^: from what i recall most of these low end 2xx series ran rather troublesome even on windows with various driver lockups etc
16:13 imirkin_: Tom^: well, it's specifically this one GT 240 with GDDR5
16:13 imirkin_: the ones with GDDR3 are fine
16:13 Tom^: ah ok
16:13 imirkin_: but they're the only gpu's of the tesla series that had GDDR5
16:13 imirkin_: and so some hacks are required to make it all work
16:14 imirkin_: it used to lock up immediately on load until skeggsb figured out the 2 magic bits we had to set somewhere to make it not insta-die
16:14 imirkin_: but the one i have plugged into my system does tend to work mostly fine... but i never run anything heavy on it, just piglit and such
16:14 imirkin_: for testing my tesla changes
16:15 noooooob: yay my system froze, sysrq barely got me rebooted
16:15 imirkin_: noooooob: you can boot with nouveau.noaccel=1 to disable... accel
16:16 imirkin_: you'll still get modesetting and the such
16:17 noooooob: so you suspect accel to cause my issues on GT215 GDDR5?
16:17 imirkin_: i mean... it's not really a suspicion but rather a fact
16:17 imirkin_: the question is *why* do you get issues, but i have no clue
16:20 noooooob: imirkin_: i got this version installed http://pastebin.com/SSvrGvAT
16:21 imirkin_: noooooob: yeah, that's well after the original GDDR5 fix went in... that was in like ... 3.18? something like that.
16:23 huelter: karolherbst: thanks for replying the bug report, I'm willing to try more things when you have time
16:23 noooooob: id really like to have my system full open source with nouveau its much faster on modeset and such
16:24 martm: karolherbst: well callgraph might had been the wrong way around, anyways, it'd be nice if you fixed that issue, cause i have to go
16:28 martm: karolherbst: RSpliet will look on the weekend perhaps the mt issues, but i have tools, but need a bit clarification...threads have their own set of regs, like it has a different copy of the program, well tls would use thread local copy of variables with the help of kernel, but i belive so would use atomics..theyd ensure that..
16:29 martm: that the shared memory is copied to the correct thread local var like a register
16:48 robclark: imirkin, btw, got a nv117? Or know if there have been some blending related fixes for that in something newer than 11.1 branch? I just noticed the gnome-shell overview (or whatever they call it) screen shows some messed up blending in f23 (on someone elses laptop, not sure if they've tried a newer mesa yet)
16:48 imirkin_: robclark: i don't remember fixing anything related to blending
16:49 imirkin_: robclark: however, i believe that xf86-video-modesetting is a fail on there for reasons unknown. and for other reasons unknown, that appears to no longer be the case.
16:49 imirkin_: no idea if a kernel change, mesa change, or glamor change precipitated that
16:49 imirkin_: but it used to be totally broken, but i hear it's fine now
16:50 imirkin_: (now = recent versions of things)
16:51 robclark: it was -modesetting... but that shouldn't come into play.. overview is just fullscreen gl rendering..
16:51 imirkin_: well... there HAVE been random shader instruction-related emission fixes
16:52 imirkin_: but no way to tell if gnome-shell uses them or not
16:53 imirkin_: integer carry fixes, spilling-related fixes, derivative-related fixes
16:53 robclark: it's shaders tend not to be that complex, but I guess not worth worrying about until trying a newer mesa..
16:53 imirkin_: doubt any of those would hit a gnome-shell shader, but dunno
16:53 robclark: yeah, it is, iirc, gl1.4 plus shaders.. doubt anything integer..
16:53 imirkin_: i've never run deqp on it, that'd probably be a good thing for someone to do
16:54 robclark: and doubtful the g-s shaders would trigger spilling
16:54 imirkin_: esp with 256 regs
16:54 imirkin_: well actually the spilling fixes were related to spilling of predicates
16:54 imirkin_: but there's still 8 of those
16:54 imirkin_: and it's very rare for more than 1-2 to ever be used
16:54 imirkin_: (at a time)
16:55 imirkin_: and using dFdx() under predication also seems unlikely :)
16:55 robclark: well, I only have one pred and hasn't been a prob for g-s :-P
16:56 imirkin_: of course that doesn't mean that there aren't more shader emission failures
16:56 imirkin_: but it does pass piglit
16:56 imirkin_: so it has to be weird things
16:57 imirkin_: could just be something simple and dumb and unrelated to blending, but just happens to look that way
16:57 imirkin_: i doubt that the "core" blending setup is wrong
17:35 robclark: imirkin, well seems to still be there w/ latest mesa... I'd *assume* piglit should be good enough to catch it but maybe someone needs to run dEQP on the thing..
17:41 imirkin_: robclark: well, someone def needs to run deqp on the thing...
17:41 imirkin_: robclark: latest mesa, i assume, means mesa 11.2.1?
17:44 robclark: master.. but you are off the hook.. seems to be an issue on display side which somehow messes up some colors more than others ;-)
17:46 imirkin_: ??
17:47 robclark: well, screenshot viewed on other laptop looks fine
17:48 imirkin_: the act of screenshotting can unscrew some stuff...
17:48 robclark: (and conversely screenshot taken on intel looks the same way w/ nv117 driving the output)
17:48 imirkin_: huh, ok
19:29 martm: karolherbst1: this is way too important snooker event, i am so sidetracked/distracet by this, kyren wilson seems to know how to play against joe perry too, lovely game
19:29 martm: karolherbst1: any news about this last light game failures, did you hunt something down, or need some help?
19:49 vita_cell: karolherbst
20:11 vita_cell: karolherbst1
20:15 martm: wtf. where this man cleared up, what the hell clearance was that, ouh kyren boy
20:25 martm: to sum it up in the thread world, the order which some enforce in cpu multi-threading land is not important (i read many reports where it was tried) as long as you guard mem operations with atomics, there is no way that thread gets a wrong copy, of the shared var, regardless of the order
20:26 martm: the cpu code would work correctly when the order is arbitrary, though gpu code would not
20:31 martm: or i do not even know, i fear one of such case reading the docs, where one context interleaves first then the intitial first
20:31 martm: that should be programmers responsibility, but i do not see any other of such things
20:31 martm: on gpu land
20:33 martm: so karolherbst get yourself together please and debug that games failure fully through, it's not that hard...
20:34 martm: we need to see where is the bug, it's probably though in the kernel like suggested first, but it does not however matter...any action that leads to resolving this bug i'd advise you to do
20:36 martm: i mean you could tap in the kernel, but generally just open up the files in kernel, and see where is the fault
20:38 martm: yeah there is kernel mode linux, systemtap and kprobes and stuff
20:38 martm: i am not an expert on how kernel debugging would work, but...i'd like to hear where the recursion happens
20:40 martm: uuh i have not seen some playing better or more higher standart then kyren wilson yet at the moment
20:49 martm: i head off to sleep, there are some kernel debuggers i could try myself, but tit not read about how to get the game
20:56 karolherbst: mupuf: I will play around with ezbench a bit :)
21:00 karolherbst: mupuf: okay, my first question: I would like to messure the performance changes of a set of patches with multiple patches + having a piglit run for each commit to be sure nothing broke. How do I have to run ezbench in this case?
21:23 mupuf: karolherbst: you want the auto bisect_
21:23 mupuf: ?
21:24 karolherbst: mupuf: somewhat
21:24 karolherbst: and I want to run the stuff without needing sudo :D
21:24 mupuf: if so: ./ezbench -b "piglit:gbm:gpu" -b gputest -c "COMMIT_BEFORE COMMIT_AFTER" -p mesa run
21:25 mupuf: and then, utils/ezbenchd.py
21:25 karolherbst: ok
21:25 mupuf: as for the sudo, if you are OK with using your already-running xserver, then you just need to delete the file profile.d/default/cond.f/ezbench.conf
21:26 mupuf: do install xterm though
21:26 karolherbst: or set EZBENCH_CONF_X11=0
21:26 karolherbst: I got it to run finally, but it also needs sudo for disabling boost on the CPU
21:27 mupuf: yep, that too
21:27 karolherbst: mhh
21:27 mupuf: it is soooo annoying...
21:27 karolherbst: can I pass also branches?
21:27 karolherbst: -c "master nouveau_opts" for example
21:28 mupuf: if git show $name works, then $name is valid
21:28 karolherbst: scipy is required
21:28 mupuf: yep, for auto bisect
21:28 mupuf: there a lot of dependencies
21:28 karolherbst: maybe I work on ebuilds for that at some point :)
21:28 mupuf: :)
21:29 mupuf: if you want, you can also use this syntax HEAD~10..HEAD
21:29 mupuf: that will force testing every commit
21:29 karolherbst: ahh good
21:29 mupuf: as I said, everything git is fine with, ezbench is fine with
21:29 karolherbst: then I guess master..$branch_name should also work
21:29 mupuf: it is documented in README
21:30 karolherbst: mhh where do I get libframetime?
21:30 mupuf: well, if your branch is master + something
21:30 mupuf: no, you do not need it anymore
21:30 mupuf: do I list it anywhere?
21:30 mupuf: oh, compile envdump btw
21:30 mupuf: cd utils/env_dump/
21:30 mupuf: make
21:30 mupuf: that is all that is needed
21:30 karolherbst: it is in the config
21:30 mupuf: and if you want hw info, you need dmidecode ... and root rights again
21:31 mupuf: yeah, right, let me delete this
21:31 karolherbst: well I want to get the perf benchmarking + piglit regression testing setup first
21:31 karolherbst: everything else isn't as important
21:32 karolherbst: and if I can let it run in the meantime while doing something else, then I am happy too
21:33 mupuf: yep
21:34 karolherbst: uhhhh
21:34 karolherbst: I need fortran
21:34 karolherbst: ...
21:34 mupuf: what, no!
21:34 mupuf: where do you see that? :D
21:34 karolherbst: scipy build dependencies
21:34 karolherbst: ....
21:34 mupuf: WHAT?
21:34 karolherbst: yeah...
21:34 karolherbst: sci-libs/blas-reference
21:34 karolherbst: https://gist.github.com/karolherbst/c64d87b8a43ae94f076cb622f66bfbfa
21:35 karolherbst: ohh wait
21:35 mupuf: shit, you are right!
21:35 karolherbst: there are multiple blas implementations
21:35 karolherbst: mkl
21:35 karolherbst: acml
21:35 karolherbst: blas-goto
21:35 mupuf: https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/python-scipy
21:35 karolherbst: and blas-reference
21:35 karolherbst: yeah
21:35 karolherbst: ...
21:35 karolherbst: meh
21:35 karolherbst: now I have to rebuild gcc with fortran :D
21:36 mupuf: ...
21:36 karolherbst: and I thought, that I won't need that ever
21:36 karolherbst: maybe mkl is good though
21:36 mupuf: scipy is needed for checking what is the variance of benchmarks
21:36 mupuf: and have more runs when needed
21:37 karolherbst: ohhh
21:37 karolherbst: scipy also needs fortran
21:37 karolherbst: would that be a reason for you to look for something else? :D
21:38 mupuf: scipy does not depend on fortran for runtime
21:38 karolherbst: no, only compile time
21:38 mupuf: yep
21:38 mupuf: only a problem on gentoo though :s
21:38 mupuf: but yeah, I can always have a look
21:38 mupuf: because I only need the student-t code
21:39 karolherbst: well
21:39 mupuf: and the one figuring out the margin (which does not work well at all, need more work on this)
21:39 karolherbst: "problem"
21:40 karolherbst: mupuf: +fortran is set in gcc for gentoo
21:40 karolherbst: so by default it is already enabled
21:41 karolherbst: I just have a global -* set which kind of disables everything, so I am a really special case
21:41 mupuf: ack
21:43 karolherbst: mupuf: anyway, if you want to look over the commits again: https://github.com/karolherbst/nouveau/commits/stable_reclocking_kepler_v5 :D
21:43 mupuf: I felt like using scipy was a good idea as it is very common and it has a lot of stats code
21:43 karolherbst: I am currently a bit unhappy about the commit order now
21:43 karolherbst: so I kind of have to think about that a bit
21:43 karolherbst: mupuf: yeah, which is no problem. and gcc-fortran is also no problem. Usually
21:43 mupuf: yeah, true
21:44 karolherbst: I just recompile gcc, that's all
21:45 karolherbst: today my libsqlite.so was bricked by my filesystem and randomly applications just segfaulted in ld.so ...
21:45 karolherbst: fun time debugging this
21:45 karolherbst: and I enabled the sqlite cache for portage so I couldn't reinstall anything
21:45 karolherbst: ....
22:03 Misanthropos: karolherbst, i have tried nouveau tree and your latest changes regarding voltage works perfectly in my gtx 650 Ti. do you have a rough estimate how long it will take until it gets into kernel.org?
22:04 karolherbst: Misanthropos: which latest change?
22:04 Misanthropos: uhm.. the stable_reclocking_kepler_v2
22:04 Misanthropos: or 4.6 reclocking
22:05 karolherbst: ...
22:05 karolherbst: well
22:05 karolherbst: you should know which branch you are using
22:05 karolherbst: but v5 is the newest one
22:05 Misanthropos: 4.6_reclocking i am using
22:05 karolherbst: mhh
22:05 karolherbst: this one is quite old
22:06 mupuf: karolherbst: ahah
22:07 Misanthropos: i cant believe it sold
22:07 Misanthropos: you made some recent changes didnt you?
22:07 karolherbst: yeah. Well there are a few other issues in the nouveau could which could lead to instabilities
22:08 karolherbst: it is a bit hard to track all the issues down, because you never know what the cause is
22:09 karolherbst: if with my changes the experience is most stable on the 0f pstate, then it is already good. And with better I mean usually more then doubled time to crash
22:09 Misanthropos: ok - no problem. i can stick to that tree. i was just curious how long it would take to get into main kernel
22:10 karolherbst: we try to get in into 4.7
22:10 karolherbst: but mostly it will be 4.8
22:10 Misanthropos: uh... that can take a while
22:11 karolherbst: mhh, well shouldn't be more then 20 weeks .D
22:11 karolherbst: 4.7 merge window opens soon though
22:11 karolherbst: it is just bed timing
22:12 Misanthropos: ok - looking forward to see the changes going into main tree
22:25 karolherbst: mupuf: gcc-fortran installed :)
22:25 mupuf: ahah
22:25 karolherbst: yeah building gcc takes a while...
22:26 karolherbst: really messy
22:29 mupuf: I will soon go to bed
22:29 mupuf: how long do you think it will take you to have all the dependencies?
22:30 mupuf: otherwise, we can continue tomorrow
22:31 karolherbst: scipy is compiling
22:31 karolherbst: the deps aren't the problem, just fortran was
22:32 karolherbst: where will ezbench install mesa by the way?
22:39 mupuf: you can change it, but it is by default in the builds/ folder
22:39 karolherbst: yay, done compiling
22:39 karolherbst: ahh okay
22:39 mupuf: no real install
22:39 mupuf: and it keeps the previous builds in cache
22:40 karolherbst: mhh
22:40 karolherbst: ImportError: /usr/lib64/python3.5/site-packages/scipy/special/_ufuncs.cpython-35m-x86_64-linux-gnu.so: undefined symbol: npy_exp
22:42 mupuf: you need numpy too, it is a dependency of scipy
22:42 karolherbst: I have numpy installed
22:43 imirkin_: but is it built for py3.5?
22:43 karolherbst: yeah
22:43 imirkin_: did you run python-updater after you installed py3.5?
22:43 karolherbst: I am sure something else is odd, because I use lto usually :/ guess another package has troubles exporting stuff the right way, what a bother
22:45 karolherbst: okay, that wasn't it
22:48 karolherbst: mupuf: but I think I will manage on my own for now. The fancy stuff we can do tomorrorw then
22:48 mupuf: ack!
22:49 mupuf: you can already test the runner like that:
22:49 mupuf: ./core.sh -b glxgears:window -r 1 -N report_name -P mesa HEAD
22:54 karolherbst: right, good idea
22:55 karolherbst: mupuf: I think there might be a better way to open terminals, wait a second
22:56 mupuf:is open to better ways. for sure!
22:57 karolherbst: mhh
22:57 karolherbst: on some distributions are x-terminal-emulator, some have xdg-terminal...
22:57 karolherbst: maybe there is also something which works on all :D
22:57 imirkin_: why on earth are you opening terminals??
22:57 karolherbst: because ezbench usually starts it's own X server
22:58 karolherbst: but yeah, why x terminals? :D
22:58 imirkin_: then just always use xterm. xterm is always installed.
22:58 karolherbst: no
22:58 karolherbst: I had xterm not installed for a long time
22:58 imirkin_: then you were wrong :p
22:58 karolherbst: I don't have to install it, do I?
22:58 imirkin_: xterm is a thing that should always be there.
22:58 karolherbst: but doesn't have to
22:58 imirkin_: anyways, i'm still unclear why ezbench needs a terminal
22:59 karolherbst: mupuf: $TERM is also a thing
22:59 imirkin_: just not a thing that is useful :p
22:59 imirkin_: e.g. for me it's set to xterm-color
22:59 imirkin_: it might be set to vt100
22:59 imirkin_: etc
22:59 mupuf: imirkin_: it is using xterm ... to show the copilation logs
22:59 mupuf: instead of a ... black screen
23:00 imirkin_: mupuf: draw them onto the background ;)
23:00 karolherbst: mupuf: I think you could use $TERM it should default to xterm
23:00 karolherbst: and then a user can simply add something in the .bash_profile or something
23:00 mupuf: karolherbst: sounds about good
23:00 imirkin_: again... TERM is not about the application
23:00 imirkin_: it's about the terminal type being emulated
23:00 mupuf: well, then let's add something in the config file
23:00 karolherbst: well $TERM is set to xterm for me
23:01 imirkin_: karolherbst: because that's one of the terminal types
23:01 mupuf: imirkin_: xterm is also used to show the progress of piglit
23:01 karolherbst: ohhh wait
23:01 karolherbst: on a tty TERM is set to linux :D
23:01 imirkin_: karolherbst: learn to trust the things i say :p
23:01 karolherbst: mupuf: I find something usefull then!
23:04 mupuf:went for the simple solution and just mandated xterm ... and twm :D
23:04 imirkin_: seems reasonable
23:04 karolherbst: uhhh
23:05 imirkin_: all part of the monolithic XFree86 distribution :)
23:05 karolherbst: I had troubles with twm
23:05 karolherbst: I had issues running fullscreen games on twm on my nvac
23:05 karolherbst: okay, the issue was lto indeed
23:06 karolherbst: now ezbench runs
23:06 karolherbst: starting ezbenchd now
23:06 mupuf: imirkin_: yep :p
23:07 karolherbst: mupuf: it doesn't do anything...
23:07 mupuf: what was your command line starting by ./ezbench?
23:08 mupuf: anyway, utils/ezbenchd.py --http_server=
23:08 mupuf: then take your browser to and you should see the report you started
23:08 karolherbst: ./ezbench -b "piglit:gbm:gpu" -b gputest -c "master..to_upstream" -p mesa run
23:08 karolherbst: "Invalid file name"
23:09 karolherbst: ahh now
23:09 mupuf: wait a sec, you want to test piglit on EVERY COMMIT?
23:09 mupuf: that sounds insane!
23:09 mupuf: oh, and sorry, I forgot the -r 1 to limit to 1 run of piglit :D
23:09 mupuf: by default, it is 3 runs
23:10 karolherbst: :O
23:10 karolherbst: well yeah
23:10 mupuf: the piglit integration is not over yet
23:10 karolherbst: they are like 10 commits though
23:10 mupuf: I only got it working last week end :p
23:10 karolherbst: mhh
23:10 karolherbst: by accident I started that stuff on my intel gpu
23:10 karolherbst: ...
23:10 karolherbst: *accidence
23:10 mupuf: hehe
23:10 mupuf: nope, it was accident, not accidence
23:10 karolherbst: mhh
23:10 karolherbst: ..
23:10 karolherbst: right
23:11 karolherbst: okay
23:11 karolherbst: how I can I whipe the queue?
23:11 karolherbst: ahh
23:12 karolherbst: logs/$name
23:12 mupuf: well, you can check the queue for one report by doing ./ezbench $name status
23:12 mupuf: and undo stuff by using negative values for -r
23:12 mupuf: or ... delete the folder :D
23:12 mupuf: in logs/
23:13 mupuf: whatever is most convenient to you
23:13 karolherbst: yay, I messed up
23:13 karolherbst: okay, now it works again
23:14 karolherbst: mupuf: how can I name a test?
23:14 mupuf: AAAAAHHHH
23:14 mupuf: you screwed up, you named your report ... run
23:15 mupuf: ./ezbench -b "piglit:gbm:gpu" -b gputest -c "master to_upstream" -p mesa my_report run
23:15 karolherbst: so run is a bad name?
23:15 karolherbst: ohhh
23:15 mupuf: it is not
23:15 mupuf: run is just a state, it says you are done staging your commands :p
23:15 karolherbst: -c gets a list of commit (ranges) to test=
23:15 karolherbst: ?
23:15 mupuf: yes
23:15 karolherbst: okay
23:16 karolherbst: much better now :)
23:16 karolherbst: I never got tessmark to run
23:16 karolherbst: ...
23:16 karolherbst: why can ezbench just run it...
23:16 karolherbst: what did I do wrong
23:16 karolherbst: ...
23:17 karolherbst: why, what...
23:17 karolherbst: :O
23:17 karolherbst: 250 fps though
23:18 karolherbst: mupuf: okay, now the test stalls. gputest already finished, but the process is still there
23:18 mupuf: ah ah, of course ezbench can run it .... because I force it to enable some extensions which are not needed :p
23:18 mupuf: well, GF is sort of getting pissed, so ... see you tomorrow!
23:19 karolherbst: cu
23:51 imirkin: skeggsb: you are a magician
23:51 imirkin: skeggsb: poking bit 0 of 0x50405c fixes the TF thing on fermi
23:52 skeggsb: cool :)
23:52 skeggsb: i vaguely recalled when we fixed something like the for >=kepler, and spotted the write while comparing our init with rm yesterday
23:52 airlied: TF being xfb of tess factor?
23:52 airlied: ^of^or
23:53 imirkin: xfb
23:53 imirkin: lookup -a gf100 0x50405c
23:53 imirkin: apparently this was known
23:53 imirkin: but not by me :)
23:54 airlied: you should ask for the offical name
23:54 airlied: actually that one sounds better
23:54 imirkin: skeggsb: i assume this is something to be handled in the kernel somewhere?
23:54 imirkin: or do i need to do a "firmware" write (which our ctxsw fw doesn't support)
23:55 skeggsb: airlied: the kepler version is NV_PGRAPH_GPC0_PPC0_PES_VSC_STREM_MASTER_PE, i suspect something similar for fermi's
23:55 skeggsb: except not on PPC
23:55 skeggsb: imirkin: yeah, i'll send the fix with some other patches later
23:55 imirkin: ok sounds good
23:55 imirkin: can you cc it to stable?
23:57 skeggsb: i'll try to order the patches so it'll apply on its own, sure
23:57 airlied:can hold fixes for a bit, since agd5f dropped the ball
23:58 skeggsb: a\ight, i'll just do that fix on its own right now then
23:58 imirkin: skeggsb: presumably it has to be done for each GPC/etc?
23:58 skeggsb: nope
23:58 imirkin: ok
23:58 imirkin: well this is a GF108, so it only has like ... a single transistor ... dedicated to this stuff
23:58 skeggsb: RM does it on GPC0_TPC0 for fermi, and GPC0_PPC0 for kepler
23:58 imirkin: huh, ok
23:58 skeggsb: it's selecting a unit to be the "stream master"
23:59 imirkin: and we all know what that means :po
23:59 skeggsb: nope, but i know what comments in the gk20a gr init say :P
23:59 skeggsb: /* Set the PE as stream master */
23:59 skeggsb: nvkm_mask(device, 0x503018, 0x1, 0x1);