00:55orbea: karolherbst: someone was able to find the nine trace, here it is http://slackless.raccoons.tech/trace/Tales%20of%20Zestiria.trace.xz
00:55orbea: note this needs wine and the msvc apitrace from https://apitrace.github.io/#download
03:01LarryTheCow: Hi. Is there support for GP108M?
03:17pl44c: I asked arround in #bumblebee but no one was home
03:18pl44c: so I'm trying to configure it with nouveau because when I tried with the proprietary driver there was no way to get 3 displays to work
03:18pl44c: my hardware is a w530 with a k2000m
03:19pl44c: well 3 displays worked but there was unsolvable tearing unless I used the nvidia card as the primary gpu
03:20pl44c: but now that I'm using nouveau I'm having trouble even getting the displays to go on and optirun bugs out
03:21pl44c: I'm not concerned with using the gpu for more than outputting to the displays
03:22pl44c: as I plan on having it bind to vfio-pci when undocked so I can use the gpu in a vm
03:26pl44c: currently optirun glxgears kills xorg with these settings I have tried to make work https://dpaste.de/vbHq
03:49gnarface: pl44c: did you try this? https://nouveau.freedesktop.org/wiki/Optimus/
03:50gnarface: (i don't know if it will work with your particular card but it's a better solution than bumblebee if it does)
03:51gnarface: that said, i would think you could get the proprietary drivers to do it if you had a manually configured xorg first (with proper refresh ranges for each monitor explicitly defined) and you carefully worked around their omissions in xrandr command parsing
03:52gnarface: i would imagine in fact that NOT doing that, and having 3 unmatched monitors relying entirely on auto-detect to be pretty much a worst-case scenario for tearing and other misbehaviors
03:53gnarface: i wouldn't expect that to be different fundamentally from driver to driver, either
03:53gnarface: though the misbehaviors might be
03:54gnarface: (anyway, nouveau will obey xrandr better)
03:55pl44c: Problem with explicitly defining things in my understanding is that I have to run "optirun intel-virtual-output -f" which from my trial and error resulted in having which display is which varry
03:55pl44c: so the monitor that was supposed to be on the left was on the right etc
03:55pl44c: my monitors are all the same model hooked up via displayport to mini-displayport cables
03:56pl44c: one is hooked via the mdp end into the laptop though but I assume it's all the same
03:56gnarface: yea, you won't need a passthrough program like that if you can get DRI_PRIME working with nouveau, so that should obviate that particular issue and you can move on to debugging your xorg config
03:58gnarface: if they're all the same model and they're all plugged into the same interface then an explicit monitor profile may not be necessary but it won't hurt, either
03:58gnarface: the one that's not plugged into displayport might not be the same though, that might not be a safe assumption
03:59gnarface: these monitors i have are matched but give out very different refresh capabilities between DVI and HDMI, despite that you'd expect that not to be the case
03:59pl44c: well it's mini-displayport on the laptop
03:59pl44c: the dock has 2 displayport (regular) ports
04:00pl44c: all cables are mini-displayport to displayport cables
04:00pl44c: so I assume the same signal is going across all cables
04:01pl44c: my only other option is to use the two dvi ports on the dock and convert to hdmi on the monitor or even worse use mst
04:02pl44c: I assume mst is hell with nouveau and I've had a hell of a time with amdgpu
04:02pl44c: on a desktop
04:02gnarface: well, i don't have any idea whether the problem could be related to the displayport part of the driver itself, but if you have the spare cables on hand it's at least worth trying just as a test
04:03gnarface: (trying dvi or hdmi instead; i'd try dvi first)
04:03pl44c: I don't have hdmi ports on the dock
04:04pl44c: the dock is a 433835U if you want to see all the ports
04:05pl44c: the monitors are u2415s with mini-displayport displayport and hdmi
04:05pl44c: I have dvi to hdmi adapters but they all differ in terms of make
04:06pl44c: would probably make things worse
04:08gnarface: hmmm, that's problematic, adapters add another layer of uncertainty
04:09gnarface: the dvi to hdmi adapters
04:09gnarface: it probably matters what type
04:09gnarface: i don't know what the terminology is exactly, but look on the dvi end and make sure they're not the type that is missing the middle pins
04:10gnarface: there's one type that's missing a chunk of dvi pins in the middle and one that isn't
04:10gnarface: the ones missing the pins might cause weird issues
04:11pl44c: Well I only have 1 cable that has the middle pins (dual link) and the other adapter I only have a single-link (no middle) to plug into it
04:11pl44c: I still figure using one mdp tp dp cable the other way around for 1 output shouldn't cause issues
04:11pl44c: it's the same model of cable even
04:12pl44c: as if I went with dvi I'd only be able to get 2 displays
04:12gnarface: just fractions of a second of difference in timing/latency can throw this stuff off though
04:13gnarface: like, small enough differences that the tearing might go away if you take the cpu out of powersave mode...
04:14gnarface: (if it's already locked to max speed during your tests though, nevermind that)
04:14gnarface: i suppose i should ask... did you try using a compositor and enabling vsync with it to see if that would force them to sync up?
04:15gnarface: or are you reporting seeing the compositor tearing?
04:15pl44c: I had tearfree in xorg.conf for the intel side
04:15gnarface: oh, hmmm.
04:16pl44c: I was using i3
04:16gnarface: well on nouveau with DRI_PRIME that won't affect the nvidia card part, i don't think
04:16gnarface: i guess i'm not sure
04:20pl44c: I haven't tried with nouveau as I haven't even gotten a working config to test yet
04:21pl44c: it's possible it'll just with with prime
04:33pl44c: ok I removed bumblebee but only get intel as a provider with xrandr -listproviders gnarface
04:34gnarface: DRI_PRIME won't work with the binary drivers
04:34gnarface: it only works with nouveau
04:34gnarface: also, if it doesn't work i don't know how to help
04:34pl44c: I know I'm attempting to use nouveau because the binary drivers didn't work
04:35gnarface: someone in here might though
04:35gnarface: i think they're all asleep now
04:35gnarface: you'll have to wait for a while
04:35gnarface: sorry :(
04:36pl44c: it's alright it's not your fault m8 it's the shitty vendors' fault
14:33pl44c: ok so I've got the outputs of both cards to appear in xrandr
14:33pl44c: however only 1 monitor will actually turn on
14:33pl44c: and it has tearing
14:34pl44c: the output that works is on the laptop itself while the two on the dock do not turn on at all
15:20karolherbst: pl44c: you might want to update your kernel
15:20karolherbst: Lyude was fixing tons of those issues recently
15:20karolherbst: and they might be not all backported
15:20karolherbst: you really want a 4.19 or even 4,20 kernel
15:24pl44c: debian only has rc7 kernels on experimental
15:24pl44c: do I need to release version or would rc7 also work
15:24joepublic: my debian kernel: Linux localhost 4.20.0-rc3-x64-joe-1 #1 SMP PREEMPT Mon Nov 19 21:28:31 EST 2018 x86_64 x86_64 x86_64 GNU/Linux
15:25pl44c: I don't even see 4.20 kernels in repo
15:25pl44c: is the package not linux-image?
15:26joepublic: I compiled it -- if you compile a kernel with "make deb-pkg" it makes deb files to install with dpkg
15:33karolherbst: pl44c: better would be to use release kernels or the newest
15:33karolherbst: if you have a 4.20 rc it should be fine
15:39pl44c: yeah I just tried 4.19rc7 and it didn't work
15:40pl44c: so I guess I gotta get the source from kernel.org
15:41pl44c: as 4.19-rc7 is the newest they have on debian's repos
15:43orbea: karolherbst: can you confirm if you got the nine trace? Not sure if you saw.
15:44karolherbst: yeah, got them
15:46karolherbst: pl44c: mhh, I would more or less assume it may work with 4.19, but maybe some fixes are still missing. Worst case Lyude could look into what's the issue in your case
16:10karolherbst: orbea: okay, uhm, what's the issue?
16:10karolherbst: it looks good as it is for me
16:10karolherbst: ohhh wait. I am stupid :D nvm
16:12orbea: heh, i just realized the examples pics are gone too
16:12karolherbst: totally forgot that nine isn't part of upstream staging
16:13orbea: there was some changes to how to build nine lately, but I haven't learned it yet
16:13karolherbst: on this machine I'll just use a copr
16:13orbea: in short, the colors with that game are very wrong
16:13karolherbst: nice, found one with a build 12 days ago
16:13karolherbst: sounds good enough
16:13orbea: in other games the issues were more subtle like broken shadows
16:14orbea: i'm not sure how widespread it is since I only have a few games to test, but all the games I do have are broken in some way...
16:18karolherbst: now it's faster :)
16:18karolherbst: gp107 without reclockign support is quite painful
16:19karolherbst: yeah... and now it looks wrong
16:37karolherbst: ahhhh, is that d3dadapter path hardcoded or what?
16:39karolherbst: allthough, that lib shouldn't matter
16:39karolherbst: still ugly
16:41karolherbst: uhm.. now, that's the most important bit
16:48karolherbst: *sigh* it requires an entry in Software\\Wine\\Direct3DNine
16:49karolherbst: in HKCU
16:57karolherbst: side note: debugging wine is painful
17:01BootI386: karolherbst: Not that much, actually
17:02BootI386: You just have to get used to it
17:03karolherbst: emitFMZ causes an assert for fadds
17:03karolherbst: add dnz f32 $r2 $r2 c0[0x10c]
17:05karolherbst: some mad -> add optimization is doing that
19:04karolherbst: orbea: I'll have a fix in a moment you could try out i
19:04karolherbst: just need to test a few things
19:29orbea: karolherbst: sure, i'll need to rebuild wine stuff
19:30orbea: maybe my old build is enough...
19:32orbea: yea, I seem to be ready to test a fix :)
19:33karolherbst: orbea: https://github.com/karolherbst/mesa/commits/nv_fix_d3dnine
19:33karolherbst: top two patches
19:33karolherbst: uhh, author went horrible wrong
19:34karolherbst: ahh no, that was a github link issue
19:34orbea: I'll rebuild mesa and test now :)
19:51joepublic: ha ha
19:52karolherbst: orbea: I've pushed an updated patch, which should be a bit better performance wise
19:52karolherbst: but might break things
19:53orbea: i'll test that one, had to find the wine with d3d9 compiled in...
19:54karolherbst: the patch looks a bit too trivial for me, but... I am sure it's the correct thing to do
19:55orbea: finally building with the patch
20:10orbea: karolherbst: yay, seems both Tales of Zestiria and Berseria are now fixed :)
20:12orbea: atelier sophie is fixed too and that expires my list of d3d9 capable games I have ready to test...
20:12karolherbst: mhh, yeah, but something is still not quite right with the patch
20:14orbea: hmm, i'll be here to test any updated patches
20:15karolherbst: actually, I think it's fine
20:16orbea: On an unrelated note, the title screen in Tales of Berseria looks better with the bug than without... With: https://i.imgur.com/znLGmV1.png Without: https://i.imgur.com/itjbVVv.png :P
20:16karolherbst: orbea: pushed an updated patch, but I don't expect it breaks anything
20:16orbea: i'll retest :)
20:17karolherbst: orbea: everything looks better with that bug :p
20:17karolherbst: white clothers is for posers (in that trace)
20:18karolherbst: I actually think dark souls had the same issue triggered
20:18karolherbst: but there it was making a huge difference
20:19orbea: i wouldn't be surprised if lot of games where broken in one way or another
20:19orbea: but I only have the console version ofr dark souls
20:32orbea: karolherbst: still seems fixed here :)
20:34pl44c: When compiling the kernel I get "make: *** No rule to make target 'debian/certs/test-signing-certs.pem', needed by 'certs/x509_certificate_list'. Stop." what package am I missing?
20:34orbea: pl44c: ask a debian related channel, looks specific to debian
20:37joepublic: pl44c, from your config, remove the line CONFIG_SYSTEM_TRUSTED_KEYS and try again: https://lists.debian.org/debian-kernel/2016/04/msg00582.html
20:37joepublic: from your .config I should say
20:38karolherbst: is this a GPL violation btw? Because the GPL kind of requires you to give you every file to recreate the same binary witht he same functionality?
20:38karolherbst: I mean, there should be some package having the public keys
20:39joepublic: there is a package containing debian's private keys, but I should think that you would need to guess them.
20:40karolherbst: I am sure there is no package containing the private keys
20:40karolherbst: should contain the public ones
20:41joepublic: I am guessing that pl44c based his kernel config on the .config of his running kernel, which would expect to be provided debian signing keys; if you take out that config line, it gets signed by a one-time not-debian key.
20:41pl44c: yeah that's what I did
20:41pl44c: thank you
20:41joepublic: np enjoy
20:43joepublic: good point about the binaries not being identical.
20:46joepublic: by the way, for processors with many cores, "make -j `nproc` deb-pkg" tends to be quite a bit faster. nproc, if installed, returns number of available cores/threads.
20:47pl44c: I heard some musings about l1tf that hyperthreading is no long beneficial on systems affected by it?
20:48pl44c: is this true or false
20:48joepublic: it is true that hyperthreading can be a security risk, and it is true that hyperthreading provides little if any benefit in most situations.
20:48karolherbst: I think the avg perf gain by HT is like 40% or something
20:49joepublic: that much? I will have to run some compiling benchmarks and see what I get.
20:52pl44c: from what I saw on threadripper systems it wasn't even that much
20:53joepublic: This workstation has a Xeon E5 with 10 cores so should be a pretty good test
20:53karolherbst: well, with all those mitigations enabled it might be actually less
20:54joepublic: I guess I should try with and without nopti
20:54pl44c: forgot what the pref was for l1tf
20:55karolherbst: that spectre_v2 stuff is more relevant
20:55karolherbst: I don't think anybody should disable pti
20:56joepublic: for the purpose of comparing speed difference would be a good reason to turn it off for a test cycle.
21:00orbea: karolherbst: so what is the next step on the d3d9 issue?
21:00karolherbst: I run piglit and post the patch and see what Ilia says
21:01orbea: okay, sounds good :)
21:01orbea: thanks for the fix!
22:56pl44c: So version 4.20 rc3 built and I'm running it now
22:56pl44c: the issues persists to where only the port on the laptop displays
22:56pl44c: the 2 ports on the dock do not work
22:57pl44c: in addition there is still tearing on the 1 display that does work
22:58karolherbst: Lyude: any ideas?
23:02pl44c: ok so this is odd
23:03pl44c: if I disable the lvds display things rendered with the intel chip i.e. mpv playing a random youtube video seems to screw up
23:05pl44c: glxgears also doesn't really work
23:07pl44c: is this just a hardware thing or is there a workaround?
23:09joepublic: very good job going from "i don't see it precompiled" to building and running a new kernel all in the same day, by the way
23:09pl44c: I used to run gentoo when I was younger compiling isn't really complex
23:09pl44c: understanding how it works is
23:16karolherbst: pl44c: mhh, what do you mean by glxgears doens't really work?
23:16pl44c: like it loads but runs at like 1 frame per 10 seconds
23:16pl44c: and mpv plays the video really oddly
23:17karolherbst: ohh, after you turned the lvds display off and use displays provided by nouveau, but ports are on the laptop directly?
23:18karolherbst: mhh, those should be all issues of the intel driver afaik. It's just that parties involved with enough man power don't care and we don't have enough manpower to fix all those issues :/
23:19pl44c: ah so I have to leave my laptop display on then
23:19karolherbst: if you say it is better with the laptop display on, then so be it
23:20karolherbst: but that should be all some weirdo driver issues :/
23:20karolherbst: most likely intel
23:20karolherbst: like doing some power management stuff if no display is active
23:20karolherbst: or something
23:20pl44c: man is there any laptop with 2 gpus that isn't hell to work with
23:20karolherbst: under linux? no
23:20karolherbst: GPU vendors don't care
23:21joepublic: small part of a small part of a small market
23:21karolherbst: joepublic: you mean most laptops?
23:21joepublic: I mean people who use linux, who use laptops, who use linux on the laptops, who like laptops with dual GPUs
23:21pl44c: is there at least a laptop of which uses the intel chip to drive all the displays
23:21karolherbst: well, intel and AMD have devs payed doing open source driver stuff
23:22karolherbst: pl44c: yes, laptops with only the intel GPU
23:22karolherbst: but there are some hybrid laptops which also only use one GPU fir displaying
23:22karolherbst: but... it's hard to detect those
23:22pl44c: because I only want a secondary gpu to use a a vm
23:22karolherbst: pl44c: anyway, you should probably file bugs against the intel driver for those perf issues you see
23:23karolherbst: pl44c: that will be even more painful, because then you can't use external displays
23:23pl44c: Windows 10 has looking glass
23:23pl44c: which lets me copy the frame data to the host
23:24karolherbst: that's a different scenrio than using the GPU in the vm
23:24pl44c: I only planned on using the vm when not docked so I didn't plan on using the displays
23:24pl44c: while using the vm
23:30pl44c: anyway the weird thing when disabling the laptop display isn't happening anymore
23:31karolherbst: pl44c: do you know if the dock connections are working if you boot docked or try redocking later on?
23:31karolherbst: I know we had some issues there, but I was sure we fixed most of them...
23:31pl44c: the dock worked fine with the proprietary drivers
23:31pl44c: just had tearing
23:32pl44c: haven't had the dock ports working at all since switching to nouveau
23:32pl44c: when I reboot I have to undock it else it hangs at boot then dock it once booted
23:32karolherbst: you mean with that nvidia prime config thing?
23:32pl44c: bumblebee yeah
23:32karolherbst: pl44c: are you sure you booted your new kernel? Because we fixed those issues...
23:33karolherbst: pl44c: not bumblebee
23:33karolherbst: with the prop driver you can't use nvidia connected displays
23:33karolherbst: at least not for extending your desktop
23:33pl44c: $ uname -a
23:33pl44c: Linux shortysfloatingbox 4.20.0-rc3 #1 SMP Sat Nov 24 14:43:14 CST 2018 x86_64 GNU/Linux
23:34pl44c: the dock thing is not a nouveau thing
23:34pl44c: it hangs at bios
23:34karolherbst: that is even more troublesome
23:34pl44c: and then sometimes before I can enter my decryption pass
23:35karolherbst: normally you have some firmware upgrade (laptop and for the dock) to fix those things
23:35pl44c: so I often have to reboot twice
23:35pl44c: I'm on the latest firmware on the laptop
23:35karolherbst: the plymouth thing should be fixed though
23:35pl44c: don't think lenovo docks have update for them
23:35karolherbst: or maybe your firmware does something funky
23:35karolherbst: what laptop is it?
23:35pl44c: 433835U dock
23:36karolherbst: maybe we have both
23:36karolherbst: anyway, more DP-MST fun for Lyude :p
23:36Lyude: w530 doesn't use mst
23:36karolherbst: Lyude: not even the dock
23:37karolherbst: okay so we need fixes for the non mst stuff now?
23:37Lyude: feel free to double check though
23:37pl44c: I was able to *SEE* the other monitors when I tried mst with the non-free drivers
23:37pl44c: never got mst working well though
23:37pl44c: so I scrapped the idea of using it
23:37karolherbst: Lyude: do you have access to a w530?
23:37karolherbst: + the dock?
23:37Lyude: karolherbst: yes; but not here. you'll have to wait till I'm in the office. I also don't know that I actually have any docks that would work with it
23:37karolherbst: pl44c: is there some firmware option to enable MST?
23:38pl44c: it probably works as I can see the other displays with the non-free drivers via mst
23:38pl44c: I just dislike having monitors chained
23:38karolherbst: pl44c: I am actually wondering how that works out with bumblebee, normally your desktop won't extend and you need to tell the second X to actually display something
23:39karolherbst: or did you literally had two desktops?
23:39Lyude: there shouldn't be any option to turn it on or off, maybe I'm mistaken though and they do actually use mst on that
23:39pl44c: it uses dp 1.2 so mst is supported
23:39pl44c: It just doesn't work
23:39Lyude: pl44c: what kernel version?
23:39karolherbst: Lyude: anyway, I thought with 4.20 most of those issues should be fixed though?
23:39pl44c: like you can see the display that is connected via mst
23:39pl44c: I was on 4.18.19 at the time
23:39Lyude: karolherbst: yeah, they should be
23:40Lyude: 4.18.19 should have gotten those fixes as well
23:40karolherbst: except there are more weirdo issues
23:42karolherbst: pl44c: what I meant was, you told us that with the nvidia driver you were able to use the displays attached to the nvidia GPU, but that can't be if you only used bumblebee, because it just never worked that way
23:42pl44c: karolherbst: if you use intel-virtual-output you can extend the desktop with the proprietary driver
23:43pl44c: worked perfectly beside the screen tearing
23:43pl44c: I was able to have 3 displays via the two displayport ports on the dock and the 1 mdp port
23:43pl44c: on the laptop
23:44Lyude: pl44c: can you get the latest kernel version from master, then try getting the displays working with drm.debug=0x116 log_buf_len=100M
23:44karolherbst: ahh, right
23:44Lyude: then send me the dmesg from tha
23:45pl44c: 4.20 rc3 not new enough? don't mind doing it but it'll be awhile for my machine do compile
23:46Lyude: pl44c: that should be knew enough
23:47karolherbst: that intel-virtual-output sounds like a big hack though and I highly doubt those tearing issues can be fixed in any way
23:47pl44c: karolherbst: no from what I read it's only possible if the nvidia card is used as the primary gpu
23:48pl44c: which will not work for my intended setup
23:48karolherbst: but then you are not using bumblebee
23:48karolherbst: that intel-virtual-output thing is basically using virtual outputs which can be anything, like even some WiFi display thing. Of course those solution work, but they are super painful
23:49pl44c: of course
23:49pl44c: plus the virtual outputs varry on which display they actually are
23:49pl44c: make in impossible to script my display layout
23:49pl44c: *makes it
23:54pl44c: Lyude: https://dpaste.de/JZbs
23:55pl44c: here is dmesg with the kernel flags you said to pass
23:55pl44c: and trying to attach the displays