02:55neur0sis: hdmi output work now
02:55HdkR: yep yep
02:55neur0sis: upgrade the kernel did the tricks
02:55neur0sis: thanks a lot
03:15HdkR: Time to wait a couple years for 3D rendering support to come up? :)
03:31cyberpear: if I don't load nouveau, will the GPU be powered down at boot?
03:31gnarface: it'll just fail over to some other driver
03:33gnarface: tons of basic functionality will be crippled but you will probably still get a display
03:33gnarface: with big, blocky, oversized console fonts
03:33cyberpear: I've got gp107 with optimus Intel
03:33gnarface: oh, that changes things. in that case, it might be powered down actually. i'm not sure
03:34cyberpear: hoping to minimize power usage on battery
03:34gnarface: well it comes down to manufacturer-specific firmware choices
03:34gnarface: in that case
03:35gnarface: but yea, most people with optimus hardware - turning it off isn't the part they have problems with
09:49neur0sis: re, small update, the hdmi output of my rtx work only with modesetting while the seconds gpu use nouveau. Problem the desktop doesn't last long 10 minutes, it constently freeze and the log does'nt give clue on the problem. I edited my xorg.conf to use only 1 gpu with nouveau, : (EE) Unknown chipset: NV162 for the rtx. I can output the hdmi only using the Pascal gpu. Anyway there is no rush but if
09:49neur0sis: someone want to look into it, I can be the tester.
09:58RSpliet: neur0sis: "Pascal GPU" you say? NV162 I think is Turing...
09:58RSpliet: Oh... there's more backstory
09:58neur0sis: no my 137
09:58neur0sis: seconds GPU
09:58neur0sis: first GPU turing yest
09:58neur0sis: seconds one NV137
09:59RSpliet: Ok. The "Unknown chipset NV162" is because the/your nouveau-ddx driver doesn't support the Turing GPU.
10:00RSpliet: I don't know whether it's a good idea to try and have two NVIDIA GPUs in the same system, one on modesetting and one using the DDX. Theoretically there's not a huge problem, but practically speaking theory is often wrong :-P
10:02RSpliet: I don't think there's a GL implementation for the Turing card either yet... so I suspect what you'll end up with is making X.org use the modeset DDX driver
10:05RSpliet: That's not necessarily a bad thing. The kernel side of nouveau (being a Direct Rendering Manager-compliant driver) is uniform so the X.org modeset driver should give you all you need for basic operation. Not sure about any form of acceleration though, in absence of a dedicated 2D acceleration module (like the nouveau ddx), you tend to rely on standard OpenGL for acceleration (through GLamor)
10:06RSpliet: Which to the best of my knowledge is non-existent for Turing at this point
10:06neur0sis: it does, but it freeze the system in less than 10 min
10:07RSpliet: ... oh
10:07neur0sis: startx, 10 min max can't do a thing
10:07neur0sis: I will have to enable the debug module of nouveau to catch the problem
10:07neur0sis: since the log doesn't give a clue
10:10RSpliet: Do you know which of the two GPUs is the culprit?
10:10neur0sis: that's how I ended using my seconds gpu only. I'm unsure what make the system freezing, could be something wrong on my side.
10:10neur0sis: I guess the rtx
10:11RSpliet: Think you can isolate that?
10:11neur0sis: I will enable the debug nouveau in the kernel and give a shot again
10:11neur0sis: should have some log in about 20 minutes
10:11neur0sis: will do it now
10:11RSpliet: Also, update your kernel
10:12RSpliet: The newer the better, Turing is under active development. Stuff like https://github.com/skeggsb/nouveau/commit/5856288884c987995aaa735f0e4b9f42f0169318 can make a difference
10:13neur0sis: can't use higher for now since I'm using some hardened patch, their last release is 5.0.12-gnu
10:20neur0sis: alirght I reboot , I wait for the crash and pastebin the log
10:25RSpliet: neur0sis: Thanks for your commitment to generating data. Once you got a log, feel free to open a bugreport on the freedesktop bugzilla. Makes it a bit easier for our Australian kernel koala to chime in
10:25neur0sis: re, I' using the hdmi output of the rtx
10:25neur0sis: Provider 0: id: 0x6f cap: 0x2, Sink Output crtcs: 4 outputs: 5 associated providers: 0 name:modesetting
10:25neur0sis: Provider 1: id: 0x46 cap: 0x7, Source Output, Sink Output, Source Offload crtcs: 4 outputs: 3 associated providers: 0 name:nouveau
10:26neur0sis: it should crash soon
10:26neur0sis: freeze I meant*
10:26neur0sis: np thanks to you for nouveau
10:27RSpliet: neur0sis: don't thank me, I haven't been much involved in a few years other than eyeballing the channel and trying to extract info from people with trouble :-P
10:28neur0sis: https://pastebin.com/DQ9dDrik the actual xorg log (with the rtx modesetting...)
10:30neur0sis: boot log
10:31neur0sis: waiting for an enventual crash...
10:44neur0sis: so far so good... weird
10:45RSpliet: Oh no it's perfectly normal for bugs to only appear when you're not trying to fix them.
10:48neur0sis: right =D
10:49neur0sis: question, it is possible to get the sound trought hdmi (spdif) with modesetting ?
10:50neur0sis: with my pascal gpu it's about few line in asound.conf to make it work
10:51neur0sis: but I'm unsure if I can make it work now
10:52RSpliet: I think that should not depend on whether you use modeset or nouveau-ddx, as the audio device is registered as a physically different subdevice on the kernel side.
10:52neur0sis: https://pastebin.com/2S1BpMrt that is the asound.conf
10:52RSpliet: However, I don't know whether audio through HDMI is supported at all currently for Turing
10:52neur0sis: will check gentoo wiki
10:54RSpliet: not sure if that's the best source of information
10:55neur0sis: will just some cheap stereo and use my sound card instead
10:55neur0sis: I feel I will waste a long time if I tried trought hdmi, which I already have today for this problem
10:56RSpliet: This stuff should be plug&play anyway... alsactl should be able to list the devices in your system.
10:56RSpliet: Of course, I didn't do away with PulseAudio, which, given you write your own asound.conf, you might have done...
11:01neur0sis: yes no pulseaudio, https://pastebin.com/2S1BpMrt this was working with the GPU pascal only, but now the hdmi pass trought turing in modesetting, so I changed the card and device as it should but the sound doest work, I don't thing this is supported for now
11:40neur0sis: alright did freeze I spoted the problem
11:42neur0sis: When the cpu is in active use (emerge) full freeze, but I think the system doesnt really crash, only freeze and whatever I do it stay freeze
11:44neur0sis: while with the single gpu or on my other gentoo system (which have proprietary nvidia drivers), using 2 gpu / emerge, steam... never experienced this
11:45neur0sis: and the log doesn't show anything anormal
11:47neur0sis: will try to run emerge and wait for a while to see if the system come back after the task
11:53RSpliet: neur0sis: but the logs don't show anything unusual? Manage to SSH into the machine from a second machine to see whether the GPUs report anything unusual in dmesg?
11:54neur0sis: yeah could o the tricks, will connect my rpi
12:13neur0sis: doesn't seem to be the problem, I made some cpu work didn't get the freeze... No the kern.log / dmesg / message / Xorg and even the portage log nothing.. just before the crash some "audit" apparmor log. will do an emerge -e system && emerge -e world with the upgrade of gcc and the kernel this morning probably not bad idea.
16:25pmoreau: HdkR: Once I have played with VK_NV_ray_tracing, I am definitely planning on implementing it (assuming there is a Nouveau Vulkan driver by then)! Though, not the TTU support, for obvious reasons.
17:36imirkin: neur0sis: looking at your logs, both of your GPUs' HDA devices are loaded by alsa
17:36imirkin: neur0sis: you should check the ELD data, which is available ... somewhere inconvenient
17:38imirkin: neur0sis: ls /proc/asound/*/eld*
17:38imirkin: if there's no eld, then 99% chance there won't be sound
17:38imirkin: (if there is an eld, that doesn't guarantee it though)
18:20imirkin: skeggsb: do you know if the disp scaler has limits?
18:26imirkin: looks like someone at least has trouble with 720x400 -> 2880x1800.
18:27imirkin: skeggsb: also looks like the eDP panel in MacBookPro11,3 reports resolutions in its edid, but fails to actually switch to those modes.
18:27imirkin: i'm tempted to just dmi-match it or something
19:06HdkR: pmoreau: rtcore*