12:38 Alexander_S: Hi, guys. Lately, I've been experiencing screen tearings on a proprietary driver wich I couldn't fix (every solution on the net was either not working or crashing my system).. so I've diceded to try out nouveau drivers. OK, screen tearings are gone, but now it seams I can't make my Nvidia GPU to work (I have a laptop with optimus). xrandr
12:38 Alexander_S: --listproviders shows only 1 card: Provider 0: id: 0x44 cap: 0x9, Source Output, Sink Offload crtcs: 3 outputs: 2 associated providers: 0 name:modesetting I have both xserver-xorg-video-intel and xserver-xorg-video-nouveau installed.. what else do I need (and how to check if I have it)?
12:38 Alexander_S: Oh.. I'm running Ubuntu 18.04 here.
12:45 Alexander_S: Oh.. and I've also read https://nouveau.freedesktop.org/wiki/Optimus/ where it says that I need: An updated graphic stack (Kernel, xserver and mesa). KMS drivers for both GPUs loaded. DDX drivers for both GPUs loaded. But I don't completely understand what it means :( How do I check wich of those do I have and wich I don't?
14:03 gunix: hello
14:04 gunix: on Lenovo X1 extreme, sway is starting with llvmpipe. can anybody help me with troubleshooting this?
16:13 imirkin: gunix: pastebin dmesg and sway startup log
16:13 imirkin: Alexander_S: pastebin dmesg and xorg log to help understand what's going on
16:29 karolherbst: imirkin, gunix: it's a turing gpu
16:29 karolherbst: so no OpenGL yet
16:30 karolherbst: I think... maybe not? I am confused actually
16:30 karolherbst: no, it has a 1650 probably, so yeah
16:30 karolherbst: gunix: in case it's not a turing one, dmesg and the log are useful still
16:39 imirkin: karolherbst: presumably should still have the intel gpu, no?
16:39 karolherbst: not when in discrete mode
16:40 imirkin: ah ok
16:40 karolherbst: something a lot of users used to do due to the runpm bug as well
16:40 karolherbst: let's them keep their external displays working
16:40 karolherbst: but yeah
16:41 karolherbst: Alexander_S: also.. you mind want to update your ubuntu installation to 20.04.. since back then a lot of stuff went in to make make a lot of things more automatic
16:42 karolherbst: like display offloading
16:42 karolherbst: so updating could just fix the problem and if not, you still updated what you need to do sooner or later anyway
16:45 karolherbst: also 20.04 is based on kernel 5.4 which got the runpm fix
16:58 gunix: imirkin: karolherbst: i need to restart everything to get a clean sway log so i will post later
16:59 karolherbst: gunix: but are you on dsicrete mode with a turing?
16:59 karolherbst: because if so, there is no point in digging into it
17:00 gunix: karolherbst: atm i am on hybrid graphics (form BIOS) and running sway
17:00 karolherbst: ahh okay
17:00 karolherbst: yeah.. then something is broken
17:00 gunix: karolherbst: ok so tell me what should paste
17:01 gunix: i will restart stuff now to get the logs needed
17:01 karolherbst: dmesg and the logs of sway should be helpful
17:01 karolherbst: gunix: did you had nvidia installed before? wondering if mesa is just not there or something
17:01 gunix: ok so i will go for reboot --> sway -d >sway.log 2>&1 --> post dmesg --> post sway.log
17:02 gunix: karolherbst: i have the mesa package installed. i did have nvidia before nouveau
17:02 imirkin: sway doesn't dump its log somewhere?
17:02 karolherbst: gunix: okay.. so probably nvidia is still in the way or something.. but yeah.. let's see the logs first
17:02 gunix: karolherbst: http://ix.io/2neG
17:03 gunix: ok, rebooting to have clean logs
17:03 gunix: brb
17:03 karolherbst: ahh, arch
17:05 karolherbst: mhh, libglvnd is there as well.. mhh
17:05 karolherbst: nothing obvious from the package list
17:06 gunix: karolherbst: http://ix.io/2neJ http://ix.io/2neK
17:07 gunix: karolherbst: these are logs from my "working" setup. stuff "works" unless I plug in an external monitor
17:08 emersion: i'm not sure what these eglQueryDmaBufModifiersEXT errors are about. we changed some EGL context stuff recently, maybe that's related
17:08 emersion: the "interesting" part is "GL renderer: llvmpipe"
17:09 emersion: there's interesting stuff in the dmesg also
17:10 karolherbst: uffff
17:10 emersion: e.g. "Cannot find any crtc or sizes"
17:10 karolherbst: gunix: try booting with nouveau.modeset=0 and see if this changes anything
17:10 karolherbst: emersion: I am sure sway is dumb here..
17:10 emersion: hm, but then sway won't be able to use it?
17:10 gunix: karolherbst: i have to add that as kernel param?
17:10 karolherbst: bails because it can't setup the offloading stuff
17:10 karolherbst: gunix: yeah
17:10 karolherbst: emersion: sure.. but we have no GL with nouveau anyway
17:11 karolherbst: I am sure sway is doing something dumb
17:11 karolherbst: I mean.. on Turing
17:11 gunix: linux /vmlinuz-linux root=UUID=f4c1a382-806e-4005-8b33-bbf2d4dae8ed rw cryptdevice=/dev/nvme0n1p2:cryptroot root=/dev/mapper/cryptroot loglevel=3 quiet nouveau.modeset=0
17:11 gunix: like this, yes?
17:11 karolherbst: yeah
17:11 emersion: well we just create an EGL device with the GBM platform and nouveau's node
17:11 emersion: it shouldn't pick llvmpipe
17:12 karolherbst: but it does use intel mesa [render/gles2/renderer.c:584] GL renderer: Mesa Intel(R) UHD Graphics 630 (CFL GT2)
17:12 karolherbst: mhhh
17:12 emersion: sway supports multi-gpu
17:12 emersion: creates one EGL device per DRM node
17:12 karolherbst: emersion: right... but uses it for what?
17:12 gunix: btw, in case needed: i7-9750H, GeForce GTX 1650 Mobile
17:13 karolherbst: but yeah...
17:13 karolherbst: I think this might be fine in the end
17:13 karolherbst: gunix: anyway, where did you see it using llvmpipe? in applications?
17:13 karolherbst: or just from the log?
17:13 gunix: karolherbst: just in log
17:13 karolherbst: ahh..
17:13 karolherbst: yeah.. then probably there is no issue
17:13 gunix: karolherbst: can you tell from sensors if it is overusing GPU or something?
17:13 emersion: the only multi-GPU setup supported rigth now is: composite on card0, then export a dmabuf from card0 to card1, then blit to scan-out FB
17:14 karolherbst: emersion: okay.. so the broken one :p
17:14 karolherbst: not that any compositor is better
17:14 emersion: aye
17:14 emersion: well there aren't many alternatives
17:14 karolherbst: gunix: I think there is no issue on your system
17:14 gunix: karolherbst: well, not if I do not plug in an external monitor
17:14 karolherbst: it uses the intel driver on the intel gpu
17:15 karolherbst: gunix: oh
17:15 karolherbst: okay, so what happens if you plug in an external monitor?
17:15 gunix: karolherbst: if i plug in the external monitor, sway just crashes
17:15 karolherbst: ehhh
17:15 emersion: well it doesn't crash
17:15 emersion: since there's no segfault
17:15 emersion: it seems to exit
17:15 gunix: emersion: ok... sway "exits" when i plug in an external monitor
17:15 gunix: :-D
17:16 karolherbst: gunix: okay.. so here is the deal, it can only use llvmpipe as there is no OpenGL support with Nouveau yet
17:16 emersion: hm, what do you mean by nouveau doesn't support opengl?
17:16 emersion: ah, no opengl for this card?
17:16 karolherbst: but.. nouveau.modeset=0 will remove all functionality from the GPU, so ... sway won't exit when you plugin an external display, but it won't display anything anyway
17:16 imirkin: no opengl on turing
17:16 karolherbst: emersion: yeah
17:16 karolherbst: no GL with turing yet
17:17 imirkin: or volta, not that it matters
17:17 emersion: i see, so llvmpipe is perfectly normal
17:17 karolherbst: yeah
17:17 imirkin: not if there's an intel gpu
17:17 imirkin: which should be the primary anyways
17:17 karolherbst: imirkin: well, it creates two contexts
17:17 karolherbst: one with "GL renderer: Mesa Intel(R) UHD Graphics 630 (CFL GT2)"
17:17 karolherbst: the other with llvmpipe
17:17 imirkin: ah
17:17 karolherbst: the question is.. why does sway exits
17:17 karolherbst: anyway
17:17 karolherbst: bug in sway :p
17:17 emersion: gunix: are you sure there's no segfault?
17:18 emersion: coredumpctl -r not showing sway?
17:18 emersion: yeah, thanks for clearing the llvmpipe issue up
17:19 gunix: emersion: i can give you logs from coredump, but please let's go through procedure first
17:20 emersion: karolherbst: regarding multi-gpu, i believe the only other alternatives is (1) import and scan-out directly the dmabuf, which wouldn't work in most cases and (2) go through CPU, which is meh
17:20 emersion: is there anything else?
17:20 gunix: so... 1. i force "exit" by plugging thunerbolt monitor. 2. I run coredumpctl -r | curl -F 'f:1=<-' ix.io
17:20 gunix: is that all?
17:20 emersion: hm, yeah, sure
17:21 emersion: i think coredumps are persistent anyway, so if sway crashes you should already have a bunch of entries in coredumpctl
17:22 emersion: gunix: let's continue the discussion in #sway
17:22 gunix: k
17:23 karolherbst: emersion: well.. you always have a system RAM to VRAM copy.. so the only benefit you could get is by the nv GPU doing the copy instead of the GPU.. but I doubt it matters much
17:23 karolherbst: no idea what mutter and others are doing
17:23 karolherbst: maybe having GL on both cards is required.. dunno
17:24 karolherbst: but doing a CPU copy is better then not being able to use the second display
17:24 karolherbst: so...
17:25 imirkin: emersion: you could end up with the same situation on e.g. usb displaylink thing -- no GL on secondary display
17:25 karolherbst: ahh, good point
17:25 karolherbst: also
17:25 karolherbst: SoCs
17:26 karolherbst: ehh..
17:26 karolherbst: where you'd end up creating two GL contexts on the secondary GPU?
17:26 emersion: yeah, i know we need to handle the case where the other gpu isn't display-capable
17:26 imirkin: rather render-capable
17:26 emersion: err, yes
17:26 karolherbst: yeah
17:26 emersion: it's still a TODO
17:26 imirkin: ah
17:27 karolherbst: emersion: might make sense to rewrite sway first, then add new features :p
17:27 imirkin: emersion: probably easy to add a error log that indicates this condition to the user
17:27 karolherbst: otherwise you rewreite everything later
17:27 imirkin: so that they know that they're about to enter a world of pain
17:27 emersion: > where you'd end up creating two GL contexts on the secondary GPU?
17:27 emersion: we only create one context per GPU
17:27 karolherbst: okay
17:27 emersion: karolherbst: rewrite? why?
17:28 karolherbst: emersion: display local rendering
17:28 karolherbst: this is a must
17:28 emersion: hm
17:28 karolherbst: and all compositor need to be rewritten
17:28 karolherbst: if not.. the others are useless
17:28 karolherbst: it's all fine with 4k displays
17:28 karolherbst: .. well
17:28 emersion: shouldn't require _that_ many changes tbh
17:28 karolherbst: a bit
17:28 karolherbst: but imagine 2 8k dispalays on the second gpu
17:28 emersion: the problem is that clients use… a GPU
17:28 emersion: maybe not the right one
17:28 karolherbst: emersion: no, no, no, you miss the point
17:29 karolherbst: compositing needs to be done on _all_ gpus
17:29 karolherbst: not just one
17:29 emersion: the compositor gets buffers from clients
17:29 karolherbst: and you composite the parts relevant on the display on the gpu it's connected on
17:29 emersion: clients may all use card0
17:29 karolherbst: and on two GPUs if the window is shown on two displays from different GPUs
17:29 emersion: if you want to composite on card1, you need to copy buffers anyway
17:30 karolherbst: emersion: clients don't matter here
17:30 emersion: clients can only use a single gpu
17:30 karolherbst: it's about where the compositor does it's compositing
17:30 emersion: they can't submit two dmabufs to the compositor
17:30 karolherbst: and it needs to be on the GPU the displays is connected to
17:30 emersion: well, if the clients submits a 4k buffer, what's the difference?
17:30 karolherbst: and if you have three gpus and 5 displays, you have 3 GL contexts for each GPU
17:31 karolherbst: for compositing
17:31 karolherbst: emersion: "clients don't matter"
17:31 karolherbst: forget the clients
17:31 emersion: wait… 3 contexts for each GPU?
17:31 karolherbst: it's a compositor issue
17:31 karolherbst: emersion: I meant.. on each gpu
17:31 karolherbst: one per GPU
17:31 emersion: why?
17:31 karolherbst: and all for compositing
17:31 emersion: i mean, why is it that important to composite on the scanout GPU?
17:31 karolherbst: because you want to get rid of the copies over the PCIe bus
17:32 karolherbst: again, imagine 2 8k monitors
17:32 karolherbst: currently... that's not working at all
17:32 karolherbst: not enough bandwidth
17:32 emersion: that won't get rid of copies, clients will send more amount of memory than the final buffer
17:32 karolherbst: second part: context migration
17:32 emersion: you can't just say "clients don't matter"
17:32 karolherbst: needs to be supported from gtk and qt5
17:33 karolherbst: if they get moved to the other GPU, you kill the context and let them create a new one
17:33 karolherbst: so they always stay on one GPU
17:33 karolherbst: I never said it's easy
17:33 emersion: so, speaking of this
17:33 karolherbst: just that's something every compositor needs to do
17:33 karolherbst: with eGPUs it's get even funnier
17:33 emersion: new wayland protocol change will allow cients to know which GPU they should be using https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/8
17:33 karolherbst: yeah
17:33 karolherbst: but what if you move them?
17:34 karolherbst: then you need to recreate the context
17:34 emersion: well, that's no the compositor's problem anymore, it's mesa's :P
17:34 karolherbst: it is
17:34 karolherbst: it needs to tell the clients to recreate their context
17:34 karolherbst: or do clients know on which gpus their windows are?
17:34 emersion: protocol change linked above
17:34 karolherbst: anyway.. it's more of a toolkit issue
17:34 karolherbst: this one
17:35 karolherbst: and you need to do double rendering on two gpus if you want to get rid of all copies
17:35 karolherbst: etc...
17:35 karolherbst: and then you have the problems of shadows seen on two displays...
17:35 emersion: well that isn't going to happen
17:35 karolherbst: many details
17:35 karolherbst: well
17:35 karolherbst: the compositor supporting all that will be the default compositor in the future
17:35 karolherbst: and every other will suck
17:36 karolherbst: or toolkits not supporting it
17:36 karolherbst: etc..
17:36 emersion:predicts everything will suck
17:36 karolherbst: it already sucks :p
17:36 karolherbst: especially eGPUs
17:36 karolherbst: no compositor supports any of this
17:36 karolherbst: so all need to be rewritten anyway
17:38 gunix: well it's a company laptop but if you give me stuff to test and the laptop burns, management will enlarge my holes before they buy a new one
17:38 karolherbst: gunix: why would it burn?
17:38 gunix: karolherbst: is the era over where software bugs can burn your laptop? :-D
17:39 karolherbst: dunno
17:39 karolherbst: I know we never burned a users nvidia GPU
17:39 karolherbst: can't speak for other hardwre
17:39 emersion: don't worry, we won't need to rewrite everything
17:39 karolherbst: or maybe we burned some in the past? dunno
17:39 gunix: :-D
17:39 karolherbst: I didn't hear of anything
17:39 RSpliet: I never managed
17:39 karolherbst: emersion: anyway.. probably easier to write a new compositor doing everything better from the start though
17:40 karolherbst: and just reuse the non graphic bits
17:40 RSpliet: And I reverse-engineered features that can make GPUs run hot
17:40 imirkin: the only ones that burned were the ones mupuf stuck into his oven
17:40 emersion: very likely not
17:40 imirkin: all in the name of science :)
17:41 karolherbst: emersion: well, people working on mutter are convinced they probably need to rewrite the entire graphic stuff if they want to properly support eGPUs and do local rendering instead of everything on the main gpu.. but maybe sway is better designed? dunno
17:41 karolherbst: RSpliet: yeah.. well.. if we disable the therm protection bits.. sure
17:43 Alexander_S: imirkin, you adked for my dmesg and xorg.log here they are https://pastebin.com/A7X2RDmf https://pastebin.com/XEYpKmRh
17:43 imirkin: Alexander_S: i see no mention of nouveau in your dmesg
17:43 imirkin: so that means it's not being loaded
17:44 imirkin: if you had blob before, i'd guess you have nouveau blacklisted
17:44 imirkin: grep -r nouveau /etc/modprobe*
17:46 Alexander_S: karolherbst, yes, I thought about updating.. just need to do a couple of things first and I need a definitely working computer for it :)
17:46 karolherbst: ahh, okay
17:48 Alexander_S: imirkin, damn! it is. /etc/modprobe.d/bbswitch.conf:blacklist nouveau
17:48 karolherbst: Alexander_S: if you have bumblebee installed, remove it :p
17:48 Alexander_S: sooo.. I should just remove that string?
17:49 karolherbst: Alexander_S: uninstall bbswitch and bumblebee I guess
17:49 karolherbst: could remove the file as well
17:49 karolherbst: and you won't need any of that anyway
17:51 Alexander_S: emm..seems like they are not installed: E: Unable to locate package bbswitch and Package 'bumblebee' is not installed, so not removed
17:51 karolherbst: ahh okay
17:51 karolherbst: then it might already be uninstalled and those files are stale
17:51 karolherbst: so yeah, you can remove them
17:51 emersion: karolherbst: mutter is… complicated
17:52 karolherbst: emersion: yeah.. I guess supporting X and wayland makes things ugly :p
17:52 Alexander_S: fileS? plural? should I delete something besides that /etc/modprobe.d/bbswitch.conf
17:52 Alexander_S: ?
17:53 karolherbst: Alexander_S: no.. it was just a reference to other files related to bumblbee/bbswitch might causing issues
18:04 Alexander_s: yaay! xrandr --listproviders now shows 2 cards! thank you guys! :)
18:09 Alexander_s: huray! everything's working.. one more question: should I do this "xrandr --setprovideroffloadsink nouveau Intel" each time I reboot or will it be remembered..?
18:11 imirkin: it will not be remembered
18:11 imirkin: (what would remember it?)
18:12 Alexander_s: IDK, that's why I'm asking :)
18:12 imirkin: some DE's auto-configure it
18:12 imirkin: not sure which ones
18:13 Alexander_s: OK, got it
18:14 Alexander_s: then I'll just make a shell-script with this line and put it into startup applications :)
18:15 imirkin: i seem to recall some patch going into X to auto-guess what the user wants
18:15 imirkin: don't remember the details though
20:04 Alexander_S: Hey, guys, me again.. Am I missing something here? Everyting seams to be working fine, the system infos in KODI and steam show either Intel or Nvidia video card depending on wether I launch them with or without that "DRI_PRIME=1".. But other then that I fail to see any difference between this two. The graphics and framerate in games stay the same
20:04 Alexander_S: (I think).. oh and one more thing: when I was using a proprietary driver - the fan in my laptop went crazy when I launched some game with Nvidia card, and now it stays silent.. So it looks like no Nvidia's GPU is actually working.. do I need to install or run something else to make it work?...
20:05 imirkin: Alexander_S: which GPU do you have?
20:06 Alexander_S: Umm.. I think it's M8.. something
20:06 imirkin: dunno what that is
20:06 Alexander_S: I honestly don't remember exactly :(
20:06 imirkin: lspci -nn -d 10de:
20:07 Alexander_S: 08:00.0 3D controller [0302]: NVIDIA Corporation GF117M [GeForce 610M/710M/810M/820M / GT 620M/625M/630M/720M] [10de:1140] (rev a1)
20:07 imirkin: no reclocking is supported on the GF117, sorry
20:08 imirkin: so you get stuck at whatever perf level the gpu boots to
20:08 imirkin: most likely the nvidia gpu is being used, but just not at the highest clocks, so the fans don't go nuts
20:08 Alexander_S: Oh.. so in other words this nouveau is useless to me?.. OK, thanks..
20:09 imirkin: it's your call as to its usefulness
20:09 imirkin: if what you're looking to do is get the maximum performance out of your nvidia gpu, then it's useless (with any line of their GPUs, actually)
20:10 imirkin: if what you're looking for is to not run closed blobs downloaded off the internet in kernel ring 0, then it's quite useful
20:11 Alexander_S: Of coarse I want the maximum performance, otherwise I could just use Intel's video.
20:11 imirkin: which intel GPU do you have?
20:11 imirkin: the GF117 was paired either with sandybridge or with ivybridge, usually
20:12 Alexander_S: IDK again.. :) All I know it's i3.. it's an older laptop really :)
20:13 imirkin: lspci -nn -d ::300
20:13 Alexander_S: 00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 0b)
20:13 imirkin: oh wow, haswell, ok
20:13 imirkin: yeah, that GF117 is worthless. even with blob drivers, it's probably not a lot better than the hsw
20:13 Alexander_S: So.. what does it mean?
20:14 imirkin: haswell was, in my estimation, intel's first actually-useful GPU
20:14 imirkin: some people might argue, but ... that's my opinion
20:15 Alexander_S: No-no-no! With proprietary "blob" it works fine in games. The problem is as I said in the begining - is that annoying screen tearings :(
20:15 imirkin: i understand, but my point is you'd get a similar level of perf with the intel gpu
20:17 Alexander_S: Oh.. I see. OK, will try to revert to blob, upgrade to 20.04 and see if that tearings are gone.. I see no other options :) Well, thanks anyway..
20:17 imirkin: good luck!
20:17 imirkin: i think screen tearing is going to be unavoidable
20:17 imirkin: if you run the GF117 as primary
20:17 imirkin: and the intel as secondary
20:18 RSpliet: Damn you "Remote host"
20:18 imirkin: almost as bad as this "Peer" hacker
20:19 RSpliet: Heh, oh the good old days where people's quit messages were hardcoded to "connection reset by pineapple"
20:19 imirkin: :)
20:19 RSpliet: Nowadays people just don't quit, with their fancy bouncers and stuff...
20:20 RSpliet: (and just now it sank in that "Peer" is the Dutch spelling for pear... this makes absolutely no sense in English)
20:21 linkmauve: imirkin, I’ve been gaming on Ivy Bridge quite a lot before I was forced to upgrade to this Kaby Lake, so I challenge your Haswell baseline estimation. :p
20:21 linkmauve: (I also did on Sandy Bridge, but I’d rather had not. :x)
21:25 imirkin: linkmauve: i think hsw had a fairly substantial jump over ivb, whereas skl isn't much faster than hsw
21:27 linkmauve: Possibly, I never had an hsw, but the ivb I had had the right levels of performances and features to let me play most games I wanted.
21:27 linkmauve: I was actually quite disappointed by this kbl not being so much faster than my previous ivb.
21:28 imirkin: can't speak to gen11/12, but the overall perf definitely stagnated for a while
21:34 HdkR: My Ice Lake is pretty good aside from the Ice Lake bugs :P
21:37 macc24: linkmauve: i was gaming on ironlake laptop
21:38 linkmauve: macc24, I was gaming on an… i810 laptop, BUUUUT. :D
21:38 HdkR: I was gaming on a Pandaboard!
21:38 macc24: linkmauve: i literally played latest ksp on i3 ironlake laptop with no dedicated gpu 4 weeks ago
21:39 linkmauve: What is ksp?
21:40 imirkin: kerbal space program
21:40 imirkin: known for unnecessarily heavy shaders
21:40 linkmauve: Oh.
21:40 macc24: imirkin: ksp is heavy on cpu too. especially with bigger rockets
21:40 imirkin: hehe
21:40 imirkin: i guess it's just bad all around then :)
21:40 macc24: i flew rocket to moon in 20fps
21:41 imirkin: i think there's a jules verne book about that
21:41 imirkin: journey to the moon, in 20fps
21:41 macc24: well i had ~40fps in map view
21:41 macc24: so that's where i spent most of time during that mission