06:33 Mystral: imirkin: patch works \o/
06:34 Mystral: did you manage to compile current wine?
06:35 imirkin: Mystral: haven't tried yet, but i can't imagine i'll have any trouble with it
06:36 imirkin: Mystral: is there a patchwork or something similar i can download your test from? not sure what to do with the ml link... i guess i could just apply that as a plain patch
06:37 imirkin: [usually i use 'git am']
06:37 Mystral: yeah, that should work okay
06:37 imirkin: and once it's all built, what do i do?
06:37 Mystral: or git am on http://source.winehq.org/patches/data/111048 should work
06:38 Mystral: then you can go into dlls/d3d9/tests and run "make test"
06:38 imirkin: cool thanks!
06:39 Mystral: you can edit dlls/d3d9/tests/visual.c and comment out all the tests except test_updatetexture() and stream_test() from the function at the end of the file to make it quicker
06:40 imirkin: will all that end up as a 32-bit binary?
06:40 Mystral: by default, yes
06:41 imirkin: ah i guess i have to do --enable-win64
06:41 imirkin: (for no other reason than i don't feel like fixing up my 32-bit mesa build)
06:42 Mystral: that should work good enough for the tests but not necessarily for anything else
06:42 imirkin: tests are all i want ;)
06:42 Mystral: (it turns out that win64 does need win32 for most of the things, and that's on Windows)
06:42 imirkin: i have a system wine install i use for... wine things.
06:42 Mystral: yeah :)
06:44 imirkin: thanks for testing wine with nouveau btw -- i had the impression that wine guys tended to ignore it
06:49 Mystral: the maintainer has nouveau on his main box and he accepts patches only if the tests pass there ;)
06:50 imirkin: wow ok
06:50 imirkin: you mean alexandre?
06:50 Mystral: yep
06:50 imirkin: hah. i'm sure that drives stefan crazy
06:50 Mystral: from time to time :P
06:52 imirkin: does wine use core context yet?
06:52 Mystral: actually I'm working on it
06:52 Mystral: so, not yet, hopefully soon...
06:52 imirkin: awesome
06:53 imirkin: grrr... defeated. it tries to use my ~/.wine for some reason??
06:53 Mystral: ah, right
06:53 imirkin: WINEPREFIX right?
06:53 Mystral: add a WINEPREFIX=~/.wine-64 or something
06:53 Mystral: correct
06:55 stikonas: Hi, what does this error mean: E[ PDISP][0000:02:00.0] 02:0006:0344: link training failed
06:56 imirkin: stikonas: DP link training failed.
06:56 stikonas: my screen connected via display port doesn't work very reliably...
06:56 stikonas: actually, it doesn't work at all without one patch...
06:56 imirkin: probably related to that error message :)
06:57 stikonas: probably
06:57 imirkin: Mystral: i just get "Makefile:161: recipe for target 'd3d9ex.ok' failed"
06:57 imirkin: Mystral: is there any way to just run the visual test?
06:57 imirkin: Mystral: "make visual.ok"?
06:58 imirkin: ah yeah, that works
06:58 Mystral: right, that's even better
06:58 stikonas: this is the patch I'm using to make things work at least partially: http://pastebin.com/dEBhvBGu
06:59 imirkin: hrmph. fail. apparently my nvc0 patch doesn't work. or i did something else dumb.
07:01 Mystral: does it fail in test_updatetexture()?
07:02 imirkin: yeah, but individually they work. sound familiar? :)
07:02 Mystral: heh
07:02 imirkin: visual.c:18582: Test failed: Got unexpected color 0x0000ff00, case 0, 1.
07:02 imirkin: and so on
07:02 Mystral: yeah, it does sound like it
07:35 imirkin: anyways, something for me to hack on tonight...
07:35 imirkin: Mystral: feel free to report more nouveau issues btw, always nice to hear from actual users ;)
07:36 imirkin: stikonas: which gpu do you have? and what resolutions does the monitor report?
07:36 Mystral: I'll do, thank you for the fix btw
07:37 imirkin: stikonas: btw, you might also want to nuke the 324000 rate too -- that was also introduced in DP 1.2
07:37 stikonas: imirkin: NVIDIA Corporation GF108M [GeForce GT 425M]
07:38 stikonas: I think I'll have to reboot my laptop before I can check resolutions
07:38 imirkin: oh, that definitely doesn't do DP 1.2
07:38 imirkin: wtf, those higher rates should be getting culled
07:38 imirkin: yeah, definitely get rid of 324
07:39 stikonas: imirkin: ok, let me recompile
07:39 stikonas: before rebooting...
07:39 imirkin: stikonas: oh actually.....
07:39 imirkin: wait
07:39 stikonas: ok
07:39 imirkin: the "bad" ones are the ones with 0x10 in them
07:39 imirkin: { 540000, 0x14, 1 }, = bad
07:39 imirkin: but { 540000, 0x0a, 2 }, = good
07:39 imirkin: (2 lanes at 270)
07:40 imirkin: 324 = 2 lanes at 162
07:40 stikonas: ok, let's see if that helps
07:40 imirkin: if not, try killing all the 270-based ones as well
07:41 imirkin: it used to be that we picked the lowest link rate, but that got changed to pick the highest one
07:41 imirkin: something relating to MST i think? i forget.
07:42 imirkin:&
07:42 stikonas: it used to work on old kernels before DP rework...
07:42 stikonas: well, not perfectly
07:42 stikonas: but better than now
07:43 stikonas: so something like this: https://paste.kde.org/p9xf5ewhz
07:43 stikonas: I removed all 0x1
07:43 stikonas: or should I kill high rates as well?
10:00 stikonas: imirkin: are you still here?
10:00 imirkin_: no, but i am here to replace him
10:01 stikonas: so I can get rid of those link training errors if I leave two modes
10:01 stikonas: { 324000, 0x06, 2 } and { 162000, 0x06, 1 },
10:01 stikonas: I think...
10:01 imirkin_: that makes sense -- so the 270mhz link speed doesn't work for you for some reason
10:01 stikonas: but still something is wrong when I reconnect my screen...
10:01 imirkin_: (and all the multi-lane versions of it)
10:02 stikonas: (but it works fine immediately after boot)
10:02 imirkin_: what if you leave the 448 mode around as well? no go?
10:02 stikonas: need to test
10:02 imirkin_: er, 648
10:02 stikonas: I can take a picture of the corruption that I now have...
10:02 stikonas: maybe it would also give some hint
10:02 imirkin_: i wouldn't know what to do with it, but can't hurt i suppose
10:13 stikonas: imirkin_: I almost finished recompiling with 648 mode enabled. This is my xrandr output that you asked before: https://stikonas.eu/files/xrandr.txt
10:14 stikonas: and this is a picture of corrupted display when replugging: https://stikonas.eu/files/IMG_20150508_180343.jpg
10:14 imirkin_: ok, so this is a tiny monitor with normal-looking modes
10:14 imirkin_: it probably fits into a single 162 lane
10:15 stikonas: well, I'll soon test with two lanes
10:15 imirkin_: weird.
10:15 imirkin_: is the cable known to work btw? i think a bunch of people having problems with DP end up with shitty cables
10:16 imirkin_: they apparently don't do anything in terms of certification
10:16 stikonas: imirkin_: not really, haven't tested it anywhere else
10:17 stikonas: well, let's see what happens with two lanes...
10:17 stikonas: I'm rebooting now
10:17 glennk: crap cables shouldn't matter for dinky resolutions though, as long as the connection is solid
10:17 imirkin_: btw, if you boot with nouveau.debug=PDISP=debug that should provide a lot more debug info about what's going on
10:17 stikonas: ok, let me change kernel command line before rebooting...
10:17 imirkin_: (or maybe =trace actually)
10:17 imirkin_: i.e. nouveau.debug=PDISP=trace
10:18 stikonas: I guess I should increase buffer size too
10:18 imirkin_: that should print where its head is at wrt link training
10:18 stikonas: otherwise dmesg might not fit
10:18 stikonas: or is it not that big?
10:20 stikonas: ok, rebooting
10:25 stikonas: 648 mode makes everything worse...
10:25 stikonas: screen starts but everything flickers
10:26 imirkin_: ok, so your thing just hates multi-lane modes
10:26 imirkin_: just leave in the single-lane ones ;)
10:26 stikonas: ok...
10:26 stikonas: I can still show dmesg
10:26 imirkin_: oh yeah, probably good to save that off
10:27 imirkin_: ben would be able to actually debug the situation
10:27 imirkin_: he wrote all that code, and i don't even have any dp-capable nvidia cards
10:28 stikonas: https://stikonas.eu/files/dmesg.txt
10:28 stikonas: should I upload it somewhere else?
10:29 stikonas: well, I'm usually on #nouveau channel anyway...
10:29 imirkin_: uhm
10:29 stikonas: just different timezone from Ben's...
10:29 imirkin_: did that have a plug/unplug sequence?
10:29 stikonas: no
10:29 stikonas: this is just a fresh boot
10:29 imirkin_: ok good. coz i didn't see one ;)
10:30 stikonas: I can make plug unplug sequence with 1 lane
10:30 stikonas: here it's already corrupted a lot...
10:30 imirkin_: i mean... that log looks all happy
10:30 stikonas: blinking, etc...
10:30 imirkin_: it does the training
10:30 imirkin_: completes training
10:30 imirkin_: so it thinks that all is well
10:31 imirkin_: can you do nouveau.debug=PDISP=debug,I2C=trace
10:31 stikonas: with 2 lanes?
10:31 imirkin_: oh, and throw on drm.debug=0xe for good measure
10:31 stikonas: ok
10:31 imirkin_: with a setup that ends up broken-looking
10:37 stikonas_phone: imirkin_: https://stikonas.eu/files/dmesg1.txt
10:38 stikonas_phone: same setup as before just more debug info
10:38 imirkin_: cool. hopefully ben can make some sense of it. file a bug too?
10:39 imirkin_: and include your vbios, iirc some data for link training comes from there
10:39 stikonas_phone: ok, I'll see, maybe there is already a bug report by me, then I'll just update it...
10:58 stikonas: imirkin_: ok, looks like replugging bug is gone with 1 lane...
10:58 stikonas: (I thought I already tested it before and it was there)
10:58 imirkin_: 1x 270 or 1x 162?
10:58 stikonas: 162
10:58 stikonas: 270 is still disabled
10:58 imirkin_: heh ok
10:59 imirkin_: so presumably the change that flipped it from using lowest- to highest-bandwidth link speed is what killed it for you
10:59 stikonas: ok, now I have { 324000, 0x06, 2 }, and { 162000, 0x06, 1 }, enabled
10:59 stikonas: but 648 mode disabled
11:00 stikonas: well, at least I have something working a bit better now...
11:00 stikonas: but I still have to carry out of tree patch...
11:04 stikonas: ok, I found some bug that I reported a year ago...
11:04 stikonas: alraedy with vbios attached
11:05 imirkin_: if it's a different issue, file a new one. if it's the same, just update.
11:06 stikonas: https://bugs.freedesktop.org/show_bug.cgi?id=78439
11:06 stikonas: yeah, it's the same issue
11:07 stikonas: about reconnecting
11:07 stikonas: but now I now a bit more info
11:09 stikonas: hmm, actually reconnection issue is still here
11:09 stikonas: strange...
11:09 stikonas: well, I can attach one more dmesg....
11:12 stikonas: argh, looks like my dmesg buffer log is too small...
11:12 stikonas: even 1 MB is not enough
11:34 stikonas: imirkin_: I think I finished updating the bug report...
11:37 imirkin_: duly noted
13:44 yann-kaelig: Hi,
13:45 tobijk: hi...
13:45 yann-kaelig: I just start using the nouveau driver it is just disastrous, that start with artefact, and freeze all my OS
13:46 tobijk: please provide more info, maybe start with dmesg
13:46 yann-kaelig: I don't know what to do. I really need a full preempt kernel but the nvidia proprietary driver are not compatible with rt kernel.
13:47 yann-kaelig: tobijk: ok I try to find into the dmsg so info
13:47 tobijk: please provide the full dmesg
13:54 yann-kaelig: tobijk: https://bpaste.net/show/49b34d4c420d
13:55 imirkin_: i don't see anything untoward in there... what's the issue exactly?
13:56 imirkin_: pastebin your xorg log? perhaps you left some bits of blob driver around?
13:56 tobijk: yeah seems all fine :/
13:58 yann-kaelig: the issue is a total freeze of my system. there are some artefact at the begining , little by little it's just some lines and strange thing in my screen then a freeze of all my stsem, nothing to do just a hard rebbot
13:58 imirkin_: hmmm
13:59 imirkin_: there was an issue re compression page sizes being improperly initialized... or something
13:59 imirkin_: which kernel are you on?
13:59 tobijk: is that system ssh'able?
14:00 yann-kaelig: Xorg log https://bpaste.net/show/47bda2f9e01b
14:01 yann-kaelig: kernel is Linux 3.18.11-rt-rt7 #1 SMP PREEMPT RT Thu May 7 20:08:16 CEST 2015 x86_64 AMD Phenom(tm) II X2 550 Processor AuthenticAMD GNU/Linux
14:01 imirkin_: yep. seems all fine. so everything's happy until everything completely dies ;)
14:01 yann-kaelig: graphic card is GTX660OC
14:04 yann-kaelig: I have to quit that starting artefact that going to freeze
14:04 yann-kaelig: did you want something just before /
14:04 yann-kaelig: ?
14:05 yann-kaelig: quick
14:05 tobijk: try to remote login after the freeze
14:05 tobijk: see if that is doable
14:05 yann-kaelig: how ?
14:05 yann-kaelig: remote login
14:05 yann-kaelig: ssh ?
14:05 tobijk: ssh with a second machine, hope you got one at hand
14:06 yann-kaelig: then what Ihave to do after ssh ?
14:06 tobijk: try to gather dmesg Xorg log and see if there are errors
14:06 tobijk: try to kill X and so on...if you get to log in at all
14:07 imirkin_: could be that nouveau and rt don't play along either, dunno
14:09 tobijk: well whatever happens first, gather erros at hang or try a non-rt kernel and see if it freezes ...
14:38 yann-kaelig: hi again I compiled the last kernel Linux 4.0.2-gentoo with nouveau, I goign to see if the same problem occur
14:39 tobijk: :) we'll be here most certainly
14:48 yann-kaelig: well
14:49 yann-kaelig: look fine actually I wil wait a little more to be sure
14:49 yann-kaelig: that could be a kernel rt problem
14:55 tobijk: yann-kaelig: oh i remember a hang fixed in 3.19 for my card (its from the same family as yours), maybe try o get a newer r kernel, not sure if 4.0 is already available
14:55 yann-kaelig: well, no problem actually, no artefact. Something wrong with nouveau and RT kernel
14:56 tobijk: *rt kernel
14:56 yann-kaelig: ok interesting
14:57 yann-kaelig: tobijk: did you have any link about this bug, or information that icould read about a fix
14:58 tobijk: there was a bugentry at f.do i see if i can find it again
15:00 tobijk: yann-kaelig: for now, the commit for it: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19a10828814aa3ba483301b416b27f94330e0c80
15:00 imirkin_: various things have been fixed... e.g. 404ba3f79089a01c1ebacccafa08a5db4a4cd2af, adc346b133c952ec6988d90f6fa79cbe0a3eb7ef
15:02 yann-kaelig: thx I take a look
15:04 yann-kaelig: well, I'm not a expert, that mean from which version this patch is applied ?
15:05 tobijk: that pathc was against 3.19
15:05 tobijk: try to get a 3.19 rt kernel
15:06 tobijk: or better 4.0 whatever you can get :>
15:14 yann-kaelig: ok, thx tobijk.
15:14 yann-kaelig: thx you all
15:15 tobijk: you already tested it working?
15:34 imirkin_: tobijk: can you test http://hastebin.com/emozekimuk.mel on your G86?
15:35 tobijk: sure thing, give me some minutes
15:35 tobijk: what to expect?
15:35 imirkin_: i semi-expect it to fail
15:36 imirkin_: coz that would explain why rspliet's saturate thing broke pmoreau's g96
15:39 imirkin_: but if it passes, i'm going to have followup questions :)
15:40 tobijk: getting me a newer mesa on that thing, that takes a while...
15:42 imirkin_: uh oh... just noticed a bug
15:43 imirkin_: (not directly related to this)
15:43 imirkin_: why do i bother looking at code :(
15:44 tobijk: don't know, go out for a walk, grab your bike whatever ;-)
15:44 imirkin_: that's not going to make the bug go away
15:53 imirkin_: ok. much better.
15:59 imirkin_: anyways, i'm sure that wasn't affecting the portal situation (almost sure). since it would have been just as bad on nvc0
15:59 tobijk: care to share an explanation?
15:59 imirkin_: pushed a commit
15:59 tobijk: ke
16:00 imirkin_: every time i take a close look at the generated code, i notice various stupidity =/
16:01 imirkin_: although usually it's in the form of suboptimal code
16:02 tobijk: which we fold and bring us new goodies :D
16:03 imirkin_: this was one of the more rare cases of actually wrong code being generated
16:04 imirkin_: tobijk: did you get a chance to run that shader runner test?
16:08 tobijk: that system is still compiling...
16:08 imirkin_: heh ok
16:08 tobijk: getting it waffle piglit mesa
16:15 tobijk: imirkin_: fails
16:15 tobijk: visually most squares on bottom left are green, some red
16:15 imirkin_: which ones
16:16 imirkin_: can you give me the output to stdout?
16:16 tobijk: 16, 20, 28. 36 are failing
16:16 imirkin_: ok, so all the ones that actually got saturated
16:17 imirkin_: RSpliet: can you give it a shot on your G200? i'm guessing it's a SM12 thing, which is G200+
16:19 imirkin_: tobijk: what if above draw 20
16:19 imirkin_: you put in: uniform float expected -1.1305000266
16:19 imirkin_: uniform float tolerance 0.01
16:19 imirkin_: does that draw pass then?
16:21 tobijk_: 20 does now
16:21 imirkin_: ok. so it's just totally not saturating then.
16:22 imirkin_: oooooh well
16:22 imirkin_: give me a minute, i'm going to send you mad one
16:22 imirkin_: to see if it's just fmul that doesn't work or also fmad
16:24 imirkin_: tobijk_: http://hastebin.com/aqokozorol.mel
16:25 tobijk: pass
16:26 imirkin_: seriously?
16:26 imirkin_: but remove that + arg2 and it's fail?
16:28 tobijk_: yep
16:28 imirkin_: sad.
16:28 imirkin_: pmoreau: around?
16:28 imirkin_: or anyone with a nva0+?
16:29 tobijk_: well nve7...
16:29 imirkin_: :p
16:29 imirkin_: nva0 <= x < nvc0
16:30 tobijk: :D
16:36 yann-kaelig: bad news, I started a movie with mpv player and the OS freeze.
16:36 tobijk: libdrm 2.4.60? :>
16:41 yann-kaelig: well, I have only two choice now, use the low-latency non rt kernel with proprietary Nvidia driver, or use the rt-kernel with vesa driver, but I don't know if vesa is the best solution
16:41 tobijk: yann-kaelig: are you using libdrm 2.4.60?
16:41 yann-kaelig: tobijk: yes
16:41 tobijk: don't
16:41 yann-kaelig: :D
16:42 tobijk: take .59 or better 61
16:43 tobijk: you experienced .60 at its best with your movie :)
16:46 yann-kaelig: what's wrong with 2.4.60 ?
16:47 yann-kaelig: libdrm 2.4.61 will stop my OS freeze with nouveau driver ?
16:47 tobijk: hangs systems ...
16:47 tobijk: (.60 does)
16:48 imirkin_: it is a source of issues. it's not the only source of issues.
16:53 buhman: imirkin_: I do
16:53 buhman: imirkin_: pick me
16:53 yann-kaelig: I understand, thx. I'm just afraid that one time the next hard reset will destroy my data on my filesystem
16:53 imirkin_: buhman: what do you have?
16:54 buhman: NVA8
16:54 imirkin_: buhman: cool. can you run http://hastebin.com/aqokozorol.mel through shader_runner?
16:54 buhman: oh wait
16:54 buhman: I misread the codenames
16:54 imirkin_: did you actually mean NVE6?
16:54 imirkin_: coz i know you got one of those :p
16:55 buhman: K2100M != 2100M
16:56 buhman: nvc0 is ancient; why the interest in those?
16:56 imirkin_: buhman: people still have them
16:57 imirkin_: and i suspect now that nvidia has dropped support for them, more of the owners will move to nouveau
17:21 imirkin_: pmoreau: when you're back, can you run that shader test through both your nv96 and nvac, as well as remove the +arg2 (so 4 results total)
17:21 imirkin_: pmoreau: i suspect the only failure will be on the nv96 + arg2 removed.