00:10 Lyude: ok, figured out why one test failure is happening
17:18 maccraft123: imirkin: hey, guess what broke for no reason
17:46 imirkin_: nouveau? it's a safe bet.
17:47 maccraft123: imirkin_: randomly one of displays goes batshit crazy
17:47 maccraft123: and displays garbage
17:47 imirkin_: reverse prime is hard.
17:47 imirkin_: you *could* just set it up the simple way.
17:48 maccraft123: reverse?
17:48 imirkin_: the one where the secondary gpu is the primary
17:48 maccraft123: randomly when i do xrandr --output VGA-1-1 --right-of HDMI-1-2
17:50 maccraft123: also
17:50 maccraft123: imirkin_: do you know anything that can get opengl calls
17:50 maccraft123: "calls"
17:50 maccraft123: and transfer it over network?
17:50 maccraft123: so server's gpu is used
17:50 imirkin_: iglx
17:51 maccraft123: but application runs on client computer
17:51 imirkin_: aka indirect glx
17:51 maccraft123: xorg crashes when i try to do that
17:51 imirkin_: it's not tested too often
17:51 imirkin_: you have to start X with a special flag to even allow it
17:51 imirkin_: since it's super-duper-insecure
17:51 maccraft123: yea i have it in configs
17:51 maccraft123: -listen tcp +iglx
17:51 maccraft123: set to launch only on tty2
17:52 imirkin_: also it limits GL to ... low values
17:52 maccraft123: low?
17:52 maccraft123: how low
17:52 imirkin_: definitely no GL4
17:52 imirkin_: maybe you get GL3? not sure.
17:52 maccraft123: i don't care as long as it runs some good graphical games
17:52 maccraft123: like subnautica
17:52 maccraft123: is there a thing like that for vulkan?
17:53 imirkin_: no, iglx is considered dead afaik
17:53 maccraft123: aww man
17:54 karolherbst: maccraft123: I guess for OpenGL over network you want to do something like primusrun is doing
17:54 karolherbst: just that you have a different method of transport
17:54 maccraft123: why does no one with more xorg coding experience also have shit laptop gpu and good desktop gpu but shit cpu
17:54 karolherbst: I did somrthing like that for a fun project where every pixel gets encoded as a string and pushed over the network
17:54 karolherbst: maccraft123: because xorg is considered "dead" as well
17:55 maccraft123: i wonder if wayland has thing like that
17:55 karolherbst: like what? sending over the network?
17:55 karolherbst: compositors implement the VNC protocol
17:55 maccraft123: using other computer's gpu
17:55 karolherbst: I think gdm has it
17:55 maccraft123: for opengl
17:55 maccraft123: vnc is too slow
17:55 karolherbst: there is no reason to do that on a X or wayland level really
17:55 maccraft123: vnc can't do 60hz and you think that it can run games?
17:56 karolherbst: that's because vnc protocl of transporting is shit
17:56 maccraft123: network isn't an issue
17:56 karolherbst: you need hw video encoding
17:56 maccraft123: or security
17:56 karolherbst: this is a real problem
17:56 maccraft123: why hw video?
17:56 karolherbst: because then you really don't need any bandwidth
17:56 maccraft123: it's just opengl stream
17:56 karolherbst: ehhh, an opengl stream can have tons of data
17:56 maccraft123: i have over 200mbps of 30cm ethernet cable
17:57 maccraft123: with pings measured in nanoseconds
17:57 karolherbst: apitraces of a few seconds can be N gbs big
17:57 maccraft123: at this point i may be hitting the bottleneck on pcie1.0x1 connection of nic
17:57 karolherbst: yes
17:57 karolherbst: you want hw video encoding/decoding for any kind of this stuff
17:58 karolherbst: and run the application remotely
17:58 maccraft123: no
17:58 karolherbst: yes
17:58 maccraft123: no running remotely
17:58 karolherbst: then you won't get 60 fps reliable
17:58 karolherbst: anyway
17:58 karolherbst: if anybody wants to do that, one would have to implement an OpenGL driver marshalling all calls and send it to a server
17:59 karolherbst: virgl is doing something like that as well for VMs
17:59 maccraft123: over network?
17:59 karolherbst: no, but I guess that would be easy to implement
18:00 Lyude: yay, fixed the issues with the nouveau crc tests and volta :)
18:00 karolherbst: the problem is really just having the API implemented and doing some shortcuts to reduce perf overhead
18:00 karolherbst: and virgl already does most of it
18:00 maccraft123: well
18:00 Lyude: which itself has exposed some bugs with our modesetting code for volta+ :)
18:00 karolherbst: maybe the communication is TCP/UDP stuff
18:00 maccraft123: opengl -> server
18:00 karolherbst: who know
18:00 maccraft123: udp opengl to server, h264 video to client
18:01 karolherbst: you don't want to use udp here
18:01 imirkin_: isn't that the google game thing?
18:01 maccraft123: packet loss is nothing
18:02 maccraft123: 0%
18:02 karolherbst: imirkin_: yeah, but is the server side open source? also they execute the game remotly, not locally
18:02 karolherbst: maccraft123: package ordering
18:02 karolherbst: also, at this bandwidth you have package loss
18:02 imirkin_: packet loss is 100% if you send fast enough
18:02 karolherbst: udp doesn't care about your bandwidth limit
18:02 karolherbst: if it has 2GB/s data, it sends that much
18:02 maccraft123: on 30cm cable?
18:02 imirkin_: sure, if you send at 1TB/s
18:02 karolherbst: if the client only accepts 500MB/s 1.5GB/s gets dropped
18:02 maccraft123: there should be some protocol
18:02 imirkin_: over a 1GB/s PHY
18:03 maccraft123: that speedtests network connection
18:03 imirkin_: most packets will get dropped.
18:03 karolherbst: UDP doesn't care about anything ;)
18:03 imirkin_: there is no such thing as "bandwidth of connection"
18:03 karolherbst: right
18:03 karolherbst: TCP resends automatically
18:03 imirkin_: TCP also has flow control to back off on how fast it sends
18:03 karolherbst: because package got dropped, due to data > bandwidth of connection
18:03 maccraft123: if multipath tcp is good
18:03 karolherbst: yeah.. but I guess you could do without it
18:04 maccraft123: i can try to do shitload of ethernet cables
18:04 karolherbst: it would just be a waste of CPU cycles
18:04 karolherbst: maccraft123: doesn't solve the issue
18:04 karolherbst: if your data output is bigger at any time than you connection, you have dropped packages
18:04 karolherbst: of course your machine won't send more than it can
18:05 karolherbst: anyway, if you use UDP for that, you have to deal with everything of that
18:05 karolherbst: especially package ordering
18:05 maccraft123: ok application can run on server
18:06 karolherbst: I mean.. it would be a fun project
18:06 karolherbst: just a lot of stuff to deal with
18:06 maccraft123: i want display on laptop
18:06 karolherbst: especially OpenGL extension
18:06 maccraft123: my "fun" project is coreboot on mcp78
18:06 karolherbst: that's indeed a fun one
18:06 maccraft123: not fun
18:07 maccraft123: porting a undocumented piece of trash isn't fun
18:09 karolherbst: well
18:09 karolherbst: guess how much of the nvidia gpu is documented ;)
18:09 maccraft123: 100%
18:10 maccraft123: 0%*
18:10 imirkin_: it's true ... probably is 100% documented
18:10 imirkin_: just ... we don't have access to those docs =/
18:10 maccraft123: yea
18:10 karolherbst: well, we have more than 0% though
18:10 maccraft123: for mcp78?
18:10 imirkin_: a lot more than 0
18:10 maccraft123: 50*0=0
18:10 karolherbst: fir mcp78 we probably have also more than 0% :p
18:11 karolherbst: but.. uff
18:11 maccraft123: links?
18:11 imirkin_: lots of stuff is documented. and there are code samples from xf86-video-nv. but lots more stuff is undocumented :)
18:11 karolherbst: you can try to find some names here: https://github.com/NVIDIA/open-gpu-doc
18:11 karolherbst: ohh, right, the nv driver
18:11 maccraft123: i don't care about gpu side
18:11 maccraft123: i am doing southbridge side
18:11 karolherbst: ahh, the motherboard bits, right?
18:11 maccraft123: yea
18:11 karolherbst: mhhh, I guess kernel sources is all you have here
18:12 maccraft123: for gpu stuff i have vgarom
18:13 karolherbst: I guess so
18:13 karolherbst: well, I was digging into a network device from that era at some point
18:13 karolherbst: but I don't think there was any documentation
18:19 maccraft123: karolherbst: nvidia calls their southbridges mcp too?
18:19 karolherbst: yeah
18:20 maccraft123: is mcp55 similar to mcp78?
18:20 karolherbst: no idea
18:31 Lyude: skeggsb: jfyi, I'm seeing some issues on turing with >1 head: https://paste.centos.org/view/0f9edfc6
19:03 Lyude: skeggsb: forgot to mention - this is a desktop turing GPU (rtx 4000), not a laptop one
19:44 cyberpear: karolherbst: wanted to report great success with your testing COPR. My hybrid Pascal laptop can successfully suspend and resume (not to mention boot)
19:44 karolherbst: :)
19:54 Lyude: karolherbst: i wouldn't mind asking nv to see if they'd be willing to do southbridge documents
19:55 karolherbst: I tried to get documentation about the ehternet chip
19:55 Lyude: it's quite old and i'm pretty sure that was post-nv-backup-failure
19:55 karolherbst: I wouldn't hold my breath
19:55 karolherbst: they still can't just publish those documents
19:56 karolherbst: so somebody would have to work through that
21:07 cyberpear: (It can hibernate once, but then external displays don't work, only the laptop display itself, which runs on the Intel chip; further attempts to hibernate or suspend fail. runpm=0 has no effect. I haven't tested the suspended battery life with the newest version of runpm_fixes, but it was only about 8 hours when I was still on the F29 kernel with your patches)
21:08 cyberpear: A contrast with the RHEL 8 kernel, which won't even boot without nouveau.modeset=0
21:08 imirkin_: just wait 'til RHEL 12 -- i bet it'll run nice by then
21:09 karolherbst: imirkin_: RHEL kernels get drm backports though ;) so the drm code isn't all that old
21:10 imirkin_: my point was that it'd be good in like 5 years' time
21:10 imirkin_: not about RHEL kernels being old
21:10 imirkin_: although that's a good point too.
21:11 karolherbst: cyberpear: well, if you are using RHEL you can always bother RH with those issues :p
21:11 cyberpear: :P
21:12 cyberpear: I thought I'd try it out w/ their Developer Program copy since the hardware claims to support RHEL or "certified"
21:12 karolherbst: well, it's an honest suggestion though. RH is the only company which pays devs to work on nouveau
21:12 cyberpear: running Fedora mainly on the system
21:13 cyberpear: I work w/ RHEL every day at work, so maybe I can find a work machine w/ a Pascal card and open a Support Case
21:13 karolherbst: yeah
21:14 karolherbst: but I kind of heard about hinteration issues before...
21:14 karolherbst: I guess there aren't many people out there using hibernation
21:15 cyberpear: My personal laptop sits in my bag idle most of the working day, so hibernation is a good fit for me.
21:15 cyberpear: overall, using nouveau is much more seamless than the proprietary blob driver, and doesn't tend to brick the system
21:16 cyberpear: I think the off-then-on-again patch is probably the one folks don't want to merge upstream? -- I think that's the magic that gets the system to even boot
21:17 karolherbst: I think skeggsb wants to figure out what's actually broken there
21:17 karolherbst: but I don't think he found anything yet
21:17 cyberpear: I agree it's nice to get to the real cause of an issue...
21:25 cyberpear: Is it possible to completely power off the nvidia card on a hybrid laptop, then power it back on when needed?
21:26 cyberpear: so if I'm on-the-go, I save the power, but when I'm at a desk, I can turn it back on and use external monitors?
21:31 karolherbst: the GPU should automatically turn off lready
21:31 karolherbst: *already
21:31 karolherbst: when you check with sensors, the temperature should be reported as "N/A" if the GPU was turned of
22:27 Lyude: skeggsb: hm. no idea if I'll get the time to look at it more today but I have a strong hunch on why that turing issue I linked you to a few hours ago is happening
22:30 Lyude: basically - my guess is we're setting the set mask for head-0 to ~0 somewhere, despite the fact that we're not setting the clr mask for it and it's already enabled at commit time. I don't even think we need to be setting anything on head-0 in that commit anyway since it's not having its mode changed
22:30 Lyude: haven't confirmed that yet though