01:06wwalker: 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:08wwalker: "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:12HdkR: DP link training failure usually is due to subpar cables
01:16wwalker: HdkR: OK, thank you, I'll buy new cables. Any company you recommend? I need HDMI (v1) and display port.
01:17wwalker: that would explain why the hangs are completely random.
01:27wwalker: would that result in a display that is still visible and the nouse cursor still works?
01:28gnarface: i have even had that bug with the official drivers
01:28gnarface: seems to be a lot of stuff that can cause it
01:28HdkR: Be very careful and make sure they state that the cable is rated for the full 32gbit/s datarate or something
01:29wwalker: Thank you both
01:29gnarface: 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:30gnarface: i got them at fry's, but they were no house brand
01:30gnarface: i don't know how you'd find them with a online search. i'm failing at it right now...
01:30wwalker: cool, Fry's in the morning then
01:30gnarface: i think i even checked back at fry's and i didn't have them, but ymmv since they're independently stocked
01:31wwalker: I live only 5 miles from a Frys's
01:31gnarface: i wish now that i had taken a picture of the box
01:31wwalker: Well I'll start there
01:32gnarface: other than just getting a reliable make, yea it's just about checking the stupid hdmi version #'s.
01:32gnarface: sometimes there will be cross-version interoperability but that's where stuff gets buggy
01:32wwalker: red and white is a good enough description
01:33gnarface: i was buying 50' cables so that really drops the selection and tolerances
01:34gnarface: the amazon-branded ones were about half price but didn't actually work as rated
01:34gnarface: (they were rated for 1080p@60 but only had enough bandwidth for 1080i@60 or 1080p@50 ... sneaky)
01:35gnarface: 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:42wwalker: :-) rpi is a crazy impressive little beast
01:42wwalker: yeah, 50ft is a long way to push that much bandwidth
01:46HdkR: For long runs you need to switch to fiber
01:46gnarface: remind me why we couldn't just use ethernet?
01:46HdkR: Or an active cable can get a decent amount of distance as well
01:47HdkR: Even ethernet has limits
01:47HdkR: 1gbit/s isn't much compared to displayport's 32.4gbit/s
01:47gnarface: fair point
01:49HdkR: 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:50gnarface:is running component, composite, s-video, svga and ethernet, too
01:50gnarface: just for the fun of it, really
01:54wwalker:quietly looks at his cat4 cables pushing 1 Gbps
01:57wwalker:doesn't want to go back in the attic and run new cable
02:15wwalker: 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:16imirkin: HdkR: wwalker: link training failure could also well be due to nouveau failure.
02:17imirkin: the link training stuff is tricky to get right without proper docs
02:17imirkin: HdkR: which fiber hdmi thing did you use?
02:17HdkR: lemme get the link
02:18imirkin:might need that at work
02:18HdkR: https://www.amazon.com/gp/product/B07BTN2FRS This one
02:18HdkR: Supports the full HDMI 2.0 BW
02:18imirkin: cool thanks
02:18HdkR: I'm pushing 4k HDR stuff over it
02:19imirkin: interesting. i would have assumed it'd be more pluggable
02:19imirkin: i.e. fiber <-> hdmi ends
02:19imirkin: and then whatever fiber middle you want
02:19imirkin: the real question - does it support CEC? :)
02:21HdkR: https://www.amazon.com/AV-Access-Fiber-Extender-4K60Hz/dp/B073QLRJDR Fiber transceiver boxes are pretty expensive
02:21wwalker: imirkin: any way I can get more data out of the nouveau driver to better troubleshoot?
02:21imirkin: wwalker: more data? sure. better troubleshooting? unlikely.
02:21imirkin: you can add .... hm
02:22imirkin: drm.debug=0x1e nouveau.debug=disp=trace,aux=trace
02:22HdkR: Haven't tested CEC on the thing sadly
02:22imirkin: iirc that should catch most of it
02:22imirkin: whoa, sfp modules on that one. fancy.
02:23imirkin: finally i can use my OC12 SFP+ modules
02:23wwalker: that goes into a modprobe conf file?
02:24imirkin: no, your kernel cmdline
02:25imirkin: the HDMI 1.4 ones seem nicer -- run over cat5!
02:25HdkR: If you want to be stuck with HDMI 1.4 sure :P
02:26wwalker: thank you imirkin ! and HdkR and gnarface !
02:28imirkin: 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:28imirkin: if someone has a chamelium board, it'd be interesting to see how nouveau fares on the DP tests
02:30imirkin: Lyude: did you have that?
02:47wwalker: 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:05Lyude: imirkin: yes I do
03:07imirkin: Lyude: should give it a whirl with DP on nouveau.
03:07imirkin: should be enough to make you cry...
03:25Lyude: imirkin: pardon? I've used it many times and fixed a few bugs, it worked fine last time I checked
03:26imirkin: Lyude: nouveau passes the chamelium tests with funny dp sinks?
03:26Lyude: I don't know about the new compliance tests
11:57mupuf: Lyude: yeah, the new tests are neat and might actually show issues in modesetting. Especially the modes one.
11:57mupuf: Is DP/HDMI audio working on nouveau too?
13:18Lyude: mupuf: I believe so
13:18mupuf: nice :)
13:32imirkin_: 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:32imirkin_: Lyude: just curious -- were you able to make progress with the CRC stuff?
13:33danvet: imirkin_, \o/
13:56Lyude: imirkin_: yeah! Haven't gotten it working yet, but I'm almost finished implementing it
13:56Lyude: splitting time between that and MST stuff atm
14:11imirkin_: looking forward to having better tests than squinting at the tv to see if it looks right
14:12imirkin_: although it's surprising how well the gradient test works
14:12imirkin_: (well, maybe not surprising, but at least pleasant)
14:14imirkin_: 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:50mooch: 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
19:13RSpliet: 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:14mooch: yeah, i already fixed that
19:14mooch: don't worry
21:22Hijiri: 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:23Hijiri: I also notice it on my computer with intel graphics but I don't really know where the problem is
21:23Hijiri: at 60fps motion looks fine
21:23imirkin_: is this in like a video?
21:24Hijiri: 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:24Hijiri: at 30fps
21:24Hijiri: I experience the jerking in both cases
21:24imirkin_: which gpu?
21:24imirkin_: and what environment?
21:24Hijiri: desktop I think is GTX 760 Ti, my laptop is HD 3000?
21:25Hijiri: it's Ivybridge, I can't find the numbers
21:25imirkin_: well, if it's happening on intel, i don't feel so bad :)
21:26imirkin_: might have to do with your flip strategy?
21:26imirkin_: if you don't wait for a buffer to be done being used
21:26imirkin_: you can end up overwriting the currently-being-"rendered" buffer
21:26Hijiri: wouldn't that give me tearing?
21:26imirkin_: resulting in weirdly-jerky motion
21:26imirkin_: imagine you have 3 buffers
21:26imirkin_: let's call them 1, 2, 3
21:26imirkin_: you draw 1, submit it to be rendered
21:26imirkin_: you draw 2, submit it to be rendered
21:27imirkin_: you draw 3, submit it to be rendered
21:27imirkin_: hold on
21:27imirkin_: i don't have this clear in my head
21:27imirkin_: but i've seen incorrect buffer reuse appear to be very jerky motion
21:27imirkin_: because basically an old frame is being displayed as if it were new
21:30Hijiri: I guess then if it completely finishes overwriting a buffer in the queue it would have the wrong motion without tearing
21:30Hijiri: and it wouldn't be noticable at 60fps because the differences are smaller?
21:32imirkin_: well, each buffer is displayed for 2 frames at 30fps
21:32imirkin_: and for 1 frame at 60fps
21:32imirkin_: so you have to be "more" careful at 30fps
21:33imirkin_: but it kinda depends on how the application works
21:33Hijiri: that might be the problem
21:34Hijiri: I changed the test to have the sprite just not move every other frame but keep rendering at 60fps
21:34Hijiri: and I don't get the jerking
21:34imirkin_: vsync and buffering is hard.
21:34imirkin_: it's amazing how something so obviously trival is somehow incredibly complicated =/
21:34Hijiri: actually no I wrote the program wrong
21:35Hijiri: it still jerks
21:35imirkin_: got something you can share?
21:35Hijiri: I've tried taking a video but my phone wasn't able to capture the vibration
21:35imirkin_: at this point your comment isn't really distinguishable from "i wrote some code and it doesn't work"
21:36imirkin_: i was thinking more like your test program
21:36Hijiri: do you want to look at the source or something to run
21:36Hijiri: I fixed it and think it's correct now
21:36imirkin_: i mean - just source, i can compile...
21:36imirkin_: but i also may not be able to look just this second - might be later on
21:36Hijiri: it's written for godot (a game engine)
21:37Hijiri: so you would need it
21:37imirkin_: probably a good thing anyways
21:38Hijiri: 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:39imirkin_: is there like a thing you can share that i can run in godot?
21:39imirkin_: given that all i know about godot is that it's a game engine
21:40Hijiri: I think I can just send my project directory and then running godot in that directory will run the game
21:41Hijiri: I've uploaded a zip file at https://arcana.moe/Jerktest.zip
21:42Hijiri: I could also try to export the game so that it includes the engine with it
21:43imirkin_: can you keep it up there for a few hours?
21:43Hijiri: I was planning on forgetting to take it down
21:44imirkin_: hehee, good plan
21:45imirkin_: what would i do with this zip file?
21:45imirkin_: will it be obvious how to import it into godot?
21:45Hijiri: if you unpack it then run godot in the game directory it should just run
21:45imirkin_: ok cool
21:45Hijiri: otherwise you can import it from the project menu
21:45Hijiri: and that way will let you browse/edit the files too
21:46Hijiri: the project menu opens if you run godot not in a game directory
21:47Hijiri: on my computer I experience severe tearing but that's in addition to the jerking
21:48Hijiri: oh, hmmm
21:48Hijiri: I found that if I disable vsync it actually goes pretty smooth and I don't notice tearing
21:48Hijiri: with the vblank_mode option
21:48Hijiri: I mean variable
21:49Hijiri: however the image looks a little bit fuzzy
21:50Hijiri: 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:50Hijiri: because the framerate was 60fps but it wasn't actually doing vsync properly?
21:52Hijiri: nevermind, that's something dumb I did
21:52Hijiri: I have the movement skip every other frame but with no vsync the framerate is much higher
21:53Hijiri: If I limit the project to 60fps it still has the jerking
21:56HdkR: Motion vibrating back and forth? Is this an issue of your project presenting buffers out of order and getting a past frame instead?
21:58Hijiri: 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:59Hijiri: well maybe it happens at lower framerates too, I've just been testing with 30fps
21:59Hijiri: but not at 60fps
22:00Hijiri: It's not my rendering engine either, it's a game engine in the test case
22:00Hijiri: originally I noticed the issue during video playback, in high contrast panning shots
22:00HdkR: 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:01Hijiri: I also notice it with the test at testufo.com (30fps lane)
22:01Hijiri: that would be however the browser is rendering it, don't know whether the issue is there (I'm using chromium)
23:14imirkin: boo, godot isn't packaged for gentoo
23:14imirkin: (there's some overlay though)
23:14Hijiri: I could export something that should run on its own