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