01:06 wwalker: I'm getting repeated (~daily, sometimes hourly) HangDiagnosis - 2. Display is frozen in X, but mouse cursor moves. Can usually get into the VT console. dmesg has nothing but
01:08 wwalker: "link rate unsupported by sink" "training failed" Xorg.0.log has a bunch of modelines. How can I gather more info? NVIDIA Corporation GM206 [GeForce GTX 950] and two 4K monitors.
01:12 HdkR: DP link training failure usually is due to subpar cables
01:16 wwalker: HdkR: OK, thank you, I'll buy new cables. Any company you recommend? I need HDMI (v1) and display port.
01:17 wwalker: that would explain why the hangs are completely random.
01:27 wwalker: would that result in a display that is still visible and the nouse cursor still works?
01:28 gnarface: i have even had that bug with the official drivers
01:28 gnarface: seems to be a lot of stuff that can cause it
01:28 HdkR: Be very careful and make sure they state that the cable is rated for the full 32gbit/s datarate or something
01:29 wwalker: Thank you both
01:29 gnarface: so i can't find pictures or a link, because this doesn't seem to be the type of thing people advertise, but the best deal on cables i ever found were these ones in red&white boxes that i swear were put out by the hdmi consortium itself or something like that... they were otherwise unbranded, but they were official. aka not cheap crap
01:30 gnarface: i got them at fry's, but they were no house brand
01:30 gnarface: i don't know how you'd find them with a online search. i'm failing at it right now...
01:30 wwalker: cool, Fry's in the morning then
01:30 gnarface: i think i even checked back at fry's and i didn't have them, but ymmv since they're independently stocked
01:31 wwalker: I live only 5 miles from a Frys's
01:31 gnarface: i wish now that i had taken a picture of the box
01:31 wwalker: Well I'll start there
01:32 gnarface: other than just getting a reliable make, yea it's just about checking the stupid hdmi version #'s.
01:32 gnarface: sometimes there will be cross-version interoperability but that's where stuff gets buggy
01:32 wwalker: red and white is a good enough description
01:33 gnarface: i was buying 50' cables so that really drops the selection and tolerances
01:34 gnarface: the amazon-branded ones were about half price but didn't actually work as rated
01:34 gnarface: (they were rated for 1080p@60 but only had enough bandwidth for 1080i@60 or 1080p@50 ... sneaky)
01:35 gnarface: and a modern consumer with good display gear might never even notice this. i noticed something was weird but didn't figure out what until i tried hooking it to a raspberry pi.
01:42 wwalker: :-) rpi is a crazy impressive little beast
01:42 wwalker: yeah, 50ft is a long way to push that much bandwidth
01:46 HdkR: For long runs you need to switch to fiber
01:46 gnarface: remind me why we couldn't just use ethernet?
01:46 HdkR: Or an active cable can get a decent amount of distance as well
01:47 HdkR: Even ethernet has limits
01:47 gnarface: heresy!
01:47 gnarface: lol
01:47 HdkR: 1gbit/s isn't much compared to displayport's 32.4gbit/s
01:47 gnarface: fair point
01:49 HdkR: I have a fiber HDMI connection running in my place because it was the only viable option to go the distance and not be a thick pita :P
01:50 gnarface:is running component, composite, s-video, svga and ethernet, too
01:50 gnarface: just for the fun of it, really
01:54 wwalker:quietly looks at his cat4 cables pushing 1 Gbps
01:57 wwalker:doesn't want to go back in the attic and run new cable
02:15 wwalker: I remember when a friend called me to wire his new house before the dry wall went up. 10 base T, printer cables and 25 pin serial cables throughout his house :-) Times have changed a little bit since then
02:16 imirkin: HdkR: wwalker: link training failure could also well be due to nouveau failure.
02:17 imirkin: the link training stuff is tricky to get right without proper docs
02:17 imirkin: HdkR: which fiber hdmi thing did you use?
02:17 HdkR: lemme get the link
02:18 imirkin:might need that at work
02:18 HdkR: https://www.amazon.com/gp/product/B07BTN2FRS This one
02:18 HdkR: Supports the full HDMI 2.0 BW
02:18 imirkin: cool thanks
02:18 HdkR: I'm pushing 4k HDR stuff over it
02:19 imirkin: interesting. i would have assumed it'd be more pluggable
02:19 imirkin: i.e. fiber <-> hdmi ends
02:19 imirkin: and then whatever fiber middle you want
02:19 imirkin: the real question - does it support CEC? :)
02:21 HdkR: https://www.amazon.com/AV-Access-Fiber-Extender-4K60Hz/dp/B073QLRJDR Fiber transceiver boxes are pretty expensive
02:21 wwalker: imirkin: any way I can get more data out of the nouveau driver to better troubleshoot?
02:21 imirkin: wwalker: more data? sure. better troubleshooting? unlikely.
02:21 imirkin: you can add .... hm
02:22 imirkin: drm.debug=0x1e nouveau.debug=disp=trace,aux=trace
02:22 HdkR: Haven't tested CEC on the thing sadly
02:22 imirkin: iirc that should catch most of it
02:22 imirkin: whoa, sfp modules on that one. fancy.
02:23 imirkin: finally i can use my OC12 SFP+ modules
02:23 imirkin: :)
02:23 HdkR: :D
02:23 wwalker: that goes into a modprobe conf file?
02:24 imirkin: no, your kernel cmdline
02:25 imirkin: the HDMI 1.4 ones seem nicer -- run over cat5!
02:25 HdkR: If you want to be stuck with HDMI 1.4 sure :P
02:26 wwalker: thank you imirkin ! and HdkR and gnarface !
02:26 gnarface: np
02:28 imirkin: wwalker: unfortunately DP is a finicky protocol. we have neither the DP spec nor the hw docs, so i suspect that some error cases are handled incorrectly, leading to your woes
02:28 imirkin: if someone has a chamelium board, it'd be interesting to see how nouveau fares on the DP tests
02:30 imirkin: Lyude: did you have that?
02:47 wwalker: ah, have to completely reverse engineer it, that is painful. I managed a team of developers writing code for the 5 different processors on the PlayStation 2. Without docs or support, and having to stay "clean". It was the most fun and the most challenging problems I've ever seen. Luckily I was not the developer.
03:05 Lyude: imirkin: yes I do
03:07 imirkin: Lyude: should give it a whirl with DP on nouveau.
03:07 imirkin: should be enough to make you cry...
03:25 Lyude: imirkin: pardon? I've used it many times and fixed a few bugs, it worked fine last time I checked
03:26 imirkin: Lyude: nouveau passes the chamelium tests with funny dp sinks?
03:26 Lyude: I don't know about the new compliance tests
11:57 mupuf: Lyude: yeah, the new tests are neat and might actually show issues in modesetting. Especially the modes one.
11:57 mupuf: Is DP/HDMI audio working on nouveau too?
13:18 Lyude: mupuf: I believe so
13:18 mupuf: nice :)
13:32 imirkin_: danvet: good news and bad news. good news -- i built a kernel with your changes. bad news -- i haven't rebooted. but i'm one step closer! :)
13:32 imirkin_: Lyude: just curious -- were you able to make progress with the CRC stuff?
13:33 danvet: imirkin_, \o/
13:56 Lyude: imirkin_: yeah! Haven't gotten it working yet, but I'm almost finished implementing it
13:56 Lyude: splitting time between that and MST stuff atm
14:11 imirkin_: nice
14:11 imirkin_: looking forward to having better tests than squinting at the tv to see if it looks right
14:12 imirkin_: although it's surprising how well the gradient test works
14:12 imirkin_: (well, maybe not surprising, but at least pleasant)
14:14 imirkin_: btw - how _do_ the crc tests work? it's not like there's a consistent way of computing scanout crc... so what does it compare to?
14:50 mooch: hey, does anybody know why with this code, riva128_ptimer_tick is called extremely rarely? keep in mind, the function it's used in is called dozens of times a second
14:50 mooch: https://hastebin.com/fiyasoledo.cpp
19:13 RSpliet: mooch: well, even if thread safety is guaranteed... if riva128_counter happens to become 10 the very instance that riva128->pmc.enable & (1 << 16) evaluates to false, it has to roll over before there's a chance of riva128_ptimer_tick() is called
19:14 mooch: yeah, i already fixed that
19:14 mooch: don't worry
21:22 Hijiri: Hi, I'm having an issue where motion at 30fps on a monitor with 60fps refresh rate looks like the motion is vibrating back and forth, in the axis of motion
21:23 Hijiri: I also notice it on my computer with intel graphics but I don't really know where the problem is
21:23 Hijiri: at 60fps motion looks fine
21:23 imirkin_: weird
21:23 imirkin_: is this in like a video?
21:24 Hijiri: It was originally in video, but the video's 24fps so I wanted to rule out the problem being not dividing 60Hz evenly. So I wrote a test program in a game engine that just moves a large sprite across a black background
21:24 Hijiri: at 30fps
21:24 Hijiri: I experience the jerking in both cases
21:24 imirkin_: which gpu?
21:24 imirkin_: and what environment?
21:24 Hijiri: desktop I think is GTX 760 Ti, my laptop is HD 3000?
21:25 Hijiri: it's Ivybridge, I can't find the numbers
21:25 imirkin_: well, if it's happening on intel, i don't feel so bad :)
21:26 imirkin_: might have to do with your flip strategy?
21:26 imirkin_: if you don't wait for a buffer to be done being used
21:26 imirkin_: you can end up overwriting the currently-being-"rendered" buffer
21:26 Hijiri: wouldn't that give me tearing?
21:26 imirkin_: resulting in weirdly-jerky motion
21:26 imirkin_: welllll
21:26 imirkin_: imagine you have 3 buffers
21:26 imirkin_: let's call them 1, 2, 3
21:26 imirkin_: you draw 1, submit it to be rendered
21:26 imirkin_: you draw 2, submit it to be rendered
21:27 imirkin_: you draw 3, submit it to be rendered
21:27 imirkin_: mmmm
21:27 imirkin_: hold on
21:27 imirkin_: i don't have this clear in my head
21:27 imirkin_: but i've seen incorrect buffer reuse appear to be very jerky motion
21:27 imirkin_: because basically an old frame is being displayed as if it were new
21:30 Hijiri: I guess then if it completely finishes overwriting a buffer in the queue it would have the wrong motion without tearing
21:30 Hijiri: and it wouldn't be noticable at 60fps because the differences are smaller?
21:32 imirkin_: well, each buffer is displayed for 2 frames at 30fps
21:32 imirkin_: and for 1 frame at 60fps
21:32 imirkin_: so you have to be "more" careful at 30fps
21:33 imirkin_: but it kinda depends on how the application works
21:33 Hijiri: ah
21:33 Hijiri: that might be the problem
21:34 Hijiri: I changed the test to have the sprite just not move every other frame but keep rendering at 60fps
21:34 Hijiri: and I don't get the jerking
21:34 imirkin_: vsync and buffering is hard.
21:34 imirkin_: it's amazing how something so obviously trival is somehow incredibly complicated =/
21:34 Hijiri: actually no I wrote the program wrong
21:35 Hijiri: it still jerks
21:35 imirkin_: got something you can share?
21:35 Hijiri: I've tried taking a video but my phone wasn't able to capture the vibration
21:35 imirkin_: at this point your comment isn't really distinguishable from "i wrote some code and it doesn't work"
21:36 imirkin_: i was thinking more like your test program
21:36 Hijiri: oh
21:36 Hijiri: do you want to look at the source or something to run
21:36 Hijiri: I fixed it and think it's correct now
21:36 imirkin_: both
21:36 Hijiri: ok
21:36 imirkin_: i mean - just source, i can compile...
21:36 imirkin_: but i also may not be able to look just this second - might be later on
21:36 Hijiri: it's written for godot (a game engine)
21:37 imirkin_: o...
21:37 Hijiri: so you would need it
21:37 imirkin_: mmmm
21:37 imirkin_: probably a good thing anyways
21:38 Hijiri: this isn't going to have any of the rendering logic since that's in the engine, but this is the script I put on my sprite https://paste.debian.net/1105777
21:39 imirkin_: is there like a thing you can share that i can run in godot?
21:39 Hijiri: yeah
21:39 imirkin_: given that all i know about godot is that it's a game engine
21:40 Hijiri: I think I can just send my project directory and then running godot in that directory will run the game
21:41 Hijiri: I've uploaded a zip file at https://arcana.moe/Jerktest.zip
21:42 Hijiri: I could also try to export the game so that it includes the engine with it
21:43 imirkin_: thanks
21:43 imirkin_: can you keep it up there for a few hours?
21:43 Hijiri: I was planning on forgetting to take it down
21:44 imirkin_: hehee, good plan
21:45 imirkin_: what would i do with this zip file?
21:45 imirkin_: will it be obvious how to import it into godot?
21:45 Hijiri: if you unpack it then run godot in the game directory it should just run
21:45 imirkin_: ok cool
21:45 Hijiri: otherwise you can import it from the project menu
21:45 Hijiri: and that way will let you browse/edit the files too
21:46 Hijiri: the project menu opens if you run godot not in a game directory
21:47 Hijiri: on my computer I experience severe tearing but that's in addition to the jerking
21:48 Hijiri: oh, hmmm
21:48 Hijiri: I found that if I disable vsync it actually goes pretty smooth and I don't notice tearing
21:48 Hijiri: with the vblank_mode option
21:48 Hijiri: I mean variable
21:49 Hijiri: however the image looks a little bit fuzzy
21:50 Hijiri: actually now that I look more carefully, I think it's still tearing, but just at random spots in the image, and with vsync on, the tear was always in the same place
21:50 Hijiri: because the framerate was 60fps but it wasn't actually doing vsync properly?
21:52 Hijiri: oh
21:52 Hijiri: nevermind, that's something dumb I did
21:52 Hijiri: I have the movement skip every other frame but with no vsync the framerate is much higher
21:53 Hijiri: If I limit the project to 60fps it still has the jerking
21:56 HdkR: Motion vibrating back and forth? Is this an issue of your project presenting buffers out of order and getting a past frame instead?
21:58 Hijiri: I don't know, but I experience it only when movement is happening at 30fps (the rendering rate is still 60fps so it's rendering two unchanged frames)
21:59 Hijiri: well maybe it happens at lower framerates too, I've just been testing with 30fps
21:59 Hijiri: but not at 60fps
22:00 Hijiri: It's not my rendering engine either, it's a game engine in the test case
22:00 Hijiri: originally I noticed the issue during video playback, in high contrast panning shots
22:00 HdkR: I've encountered something similar to that when I was doing something clever with async presentation. Which was entirely my app's fault, not the driver's fault
22:01 Hijiri: I also notice it with the test at testufo.com (30fps lane)
22:01 Hijiri: that would be however the browser is rendering it, don't know whether the issue is there (I'm using chromium)
23:14 imirkin: boo, godot isn't packaged for gentoo
23:14 imirkin: (there's some overlay though)
23:14 Hijiri: I could export something that should run on its own
23:16 Hijiri: https://arcana.moe/Jerktest.x86_64