00:57gnurou: imirkin_: they don't (sorry for the late reply!)
01:45inglor: Anyone can look at: https://bugs.freedesktop.org/show_bug.cgi?id=90388 ?
05:52Guest62642: I am using the kernel by kernel.org, linux-3.14.43. I have enabled nouveau-drm support in kernel but when i restart the computer , X is not loaded, only I have Linux text terminals. My graphics card, is nvidia-7200 and the binary drivers for that is nvidia-304xx from Nvidia company. But these binary rpms are installed only for Fedora kernels not a kernel by kernel.org. What should i do to enabled nouveau for linux-3.14.43, the kernel by kernel.org?
05:55Tom^: Guest62642: i think you are confused, nouveau is a opensource driver for nvidia and it comes with the kernel.
06:00logicman: nouveau does not work correctly on linux-3.14.43 , a kernel by www.kernel.org site and nvidia card-7200 ( the binary nVidia rpm for that is 304xx series). When i enable nouveau , X window can not be loaded in Fedora 20 and I only have Linux virtual terminals
11:25imirkin_: boxfire_: iirc dp dpms didn't work until some moderately recent kernel version... what kernel are you on?
14:09boxfire_: imirkin_: I am on 4.1 release
14:09boxfire_: probably should go from 4.1.0 to 4.1.3 but ive been busy lately
14:10imirkin_: ok, that's certainly recent enough.
14:10imirkin_: i was thinking more like 3.16
14:10boxfire_: imirkin_: the issue is that it does switch off, but after switching off its impossible to get the display back until I restart X
14:11boxfire_: xrandr claims its still set in the mode, and doing xrandr --output DP-1-1 --off, followed by turning it back on, or any combination with re-connecting the screen does nothing
14:12imirkin_: boxfire_: i'm largely ignorant as to a lot of the details, but i think that if you boot with "nouveau.debug=VBIOS=trace,PDISP=debug,I2C=debug,DRM=debug" and file a bug with a log after performing some of those actions, that would get the ball rolling
14:12imirkin_: boxfire_: oh, and also drm.debug=0xe
14:13imirkin_: i'm very surprised that unplugging/replugging doesn't fix it
14:17boxfire_: imirkin_: I will have to do the trace later, but yes there is no result when unplugging
14:17boxfire_: well the xrandr no longer shows the display connection, but when replugged setting the mode has no effect
14:17boxfire_: I should be careful about the word 'nothing'
18:08imirkin_: anyone around with a kepler (GK10x) and can do a mmt trace on top of the blob?
19:38imirkin_: buhman: do you have the blob running right now?
19:38imirkin_: and do you have valgrind-mmt and a piglit checkout?
19:39buhman: not yet
19:39imirkin_: valgrind-mmt: http://nouveau.freedesktop.org/wiki/Valgrind-mmt/
19:39imirkin_: when you get that going, i've love to get a trace of
19:41imirkin_: some piglits... i can give an exact list
19:41imirkin_: bin/shader_runner tests/spec/arb_tessellation_shader/execution/variable-indexing/tcs-input-array-float-index-rd.shader_test -auto
19:42imirkin_: bin/shader_runner tests/spec/arb_tessellation_shader/execution/variable-indexing/tcs-output-array-float-index-wr.shader_test -auto
19:42imirkin_: bin/shader_runner tests/spec/arb_tessellation_shader/execution/variable-indexing/tes-input-array-float-index-rd.shader_test -auto
19:43imirkin_: bin/shader_runner tests/spec/arb_tessellation_shader/execution/variable-indexing/tes-both-input-array-float-index-rd.shader_test -auto
19:43imirkin_: they're 4 separate tests
19:43buhman: I can't read
19:44imirkin_: so basically if you alias that valgrind --bla stuff to 'mmt', i do like mmt --log-file=foo.test bin/shadeR_runner bla
19:54buhman: imirkin_: should it be result: fail?
19:55imirkin_: that would not be ideal.
19:55imirkin_: do all of them fail?
19:55imirkin_: i'd still like the results
19:55imirkin_: even if they fail
19:56buhman: all failed
19:57imirkin_: well, i don't feel so bad about nouveau failing them then
19:57buhman: maybe I'm doing it wrong
19:57buhman: the valgrind looks completely not useful
19:57imirkin_: can you try e.g.
19:57imirkin_: bin/shader_runner tests/spec/arb_tessellation_shader/execution/quads.shader_test -auto
19:57imirkin_: that one should almost definitely pass
19:57buhman: O.o fail?
19:58imirkin_: what about without mmt?
19:58imirkin_: oh wait
19:58buhman: I'm an idiot
19:58imirkin_: add -fbo
19:58imirkin_: blob driver does something retarded
19:58buhman: no, it's because my build is weird
19:58imirkin_: ok, but you *also* need to add -fbo
19:58imirkin_: i.e. -fbo -auto
19:59imirkin_: the mmt traces would be great for all of thoe
19:59imirkin_: xz -9 them
20:05buhman: https://ptpb.pw/1Ljp.xz https://ptpb.pw/a02C.xz https://ptpb.pw/_NSQ.xz https://ptpb.pw/O1FQ.xz
20:05buhman: tcs-input-array-float-index-rd.shader_test.log.xz tcs-output-array-float-index-wr.shader_test.log.xz tes-both-input-array-float-index-rd.shader_test.log.xz tes-input-array-float-index-rd.shader_test.log.xz
20:05buhman: all pass
20:06imirkin_: awesome thanks
20:06imirkin_: what blob version were you using?
20:06imirkin_: oh, it says it right there -- 352.21
20:07imirkin_: mmt is broken with the 350 series :(
20:07imirkin_: will need to figure out what's going on there....
20:07buhman: want me to downgrade?
20:09imirkin_: i think that 0xcaf00001 thing just corresponds to handle 0x00000001
20:09imirkin_: joi: http://hastebin.com/wamunewoge.m -- do those handles seem odd to you?
20:10imirkin_: it then tries to find handles 0xcaf00001 0xcaf00002 etc