00:00Lyude: that's weird
00:00Lyude: it looks like it brings them up just fine
00:01pl44c: only the screen attached to the laptop turns on
00:02Lyude: pl44c: did you try attaching/detaching it multiple times in that log?
00:03pl44c: I ran xrandr 3 times to bring up each monitor one at a time
00:04Lyude: what's weird about this is I don't see anything with the dpcd transactions that doesn't look correct
00:05Lyude: and it manages to commit the final state
00:06Lyude: pl44c: it doesn't come up in anything else outside of X does it?
00:09pl44c: Meaning that it extends the desktop and doesn't turn on the display? Yes
00:12pl44c: oh wait you mean xorg logs?
00:15pl44c: here's the xorg log from the session
00:35Lyude: pl44c: sorry-was in the shower
00:35Lyude: but, I had some shower ideas
00:36Lyude: if you try with a single MST display hooked up, and only one MST topology, does it come up?
00:40pl44c: I haven't been using mst
00:41pl44c: are you suggesting to switch to mst using the port on the laptop?
00:41Lyude: i mean, that last log you sent me showed it was using mst
00:41Lyude: the dmesg one I mean
00:41pl44c: I have three separate cables
00:41pl44c: I don't think I'm using mst?
00:41Lyude: karolherbst was right actually-the dock you're on is actually MST
00:42Lyude: it looks like there's more then one topology as well
00:42Lyude: so try with one monitor hooked up, preferably not the vga port
00:42Lyude: and make sure it's hooked up on the dock and not directly to the laptop
00:42Lyude: then try getting the display to come up from a fresh boot, just to be safe
00:44pl44c: ok so try with only a single displayport on the dock got it
00:50pl44c: ok so the port I tried still resulted in no display
00:50pl44c: I tried unplugging it for the other dp port and it still didn't work
00:51Lyude: skeggsb: ^ think you could take a look at those logs and see if you find anything unusual?
00:51Lyude: atomic commit succeeds just fine, but they're saying nothing comes up on their screen
00:58Lyude: pl44c: feel free to poke me in the afternoon on monday when i'm in the office and I can see if I can get my hands on a working dock for the w530, but I don't know what the chances of that are
01:12pl44c: what timezome are you in Lyude?
01:23Lyude: pl44c: EST
01:23Lyude: i'm in the us
01:24pl44c: Ah so you're an hour ahead I'm in the US as well but CST
01:28pl44c: there are four docks for the w530 the one I have is a 433835U
01:29pl44c: the 433830U should be similar as it just has esata rather than usb 3.0
01:29pl44c: but the 4337XXU docks both have different video ports
02:10moreno: Hi, im having trouble with suspend to disk in a laptop with hybrid graphics (i5-2450m + gf119m)
02:11moreno: after wakeup i get a spam of this messge on the kernal log: nouveau 0000:01:00.0: fifo: PBDMA0: 80206000 [ILLEGAL_MTHD] ch 2 [003fc23000 X] subc 0 mthd 0008 data ffffffff
02:13moreno: suspend to ram works fine
02:14karolherbst: moreno: you might be the first actually trying this
02:15HdkR: and here i thought I was upset with suspend to disk failing with the blob :P
02:15moreno: karol: for this specific gpu?
02:23moreno: anything I can do?
02:41karolherbst: moreno: no, generally
02:41karolherbst: it seems to work more or less for intel GPUs
02:42karolherbst: but doing it for dedicated GPUs is on a completly different level
02:45moreno: if i were to try to debug this myself, any idea where should i start?
02:46karolherbst: the problem is that VRAM needs to be restored somehow
02:46karolherbst: either by telling applications to resubmit everything or by storing it while suspending
02:48karolherbst: HdkR: I would have expected more from nvidia :p
02:48moreno: i never messed with kernel/drivers but i have some interest in doing so, is this to much to start with?
02:49karolherbst: but then again, I was also hitting issues with system suspend under nvidia
02:49karolherbst: moreno: yes
02:49HdkR: karolherbst: It's something to do with nvidia-uvm not understanding suspend
02:49karolherbst: normally fixing bugs is a good start, but this here is adding a new feature alltogether
02:50karolherbst: HdkR: doubtful
02:50karolherbst: nvidia-uvm isn't even always used
02:50HdkR: That's what my particular issue was anyway since I was doing cuda things :P
02:50karolherbst: but there is like no suspend to disc support at all
02:51karolherbst: I don't even know if radeon supports it
02:51karolherbst: or amdgpu
02:51karolherbst: probably not
02:51HdkR: yea, it's expected that if you're suspending while the GPU is doing tasks then yolo
02:51karolherbst: intel supports it
02:51karolherbst: but again, with stolen RAM it becomes rather trivial
02:52HdkR: Yea. Might not be bad if you can dump everything from vram during suspend
02:52karolherbst: what you have to do on the GPU is to actually halt/finish all running tasks, dump all VRAM, save the additional stuff for the MMU state and restore all that on resume
02:53karolherbst: problem with resuming from disc is, that you get your full driver state
02:53moreno: well for me this happens even if the nvidia gpu is turned off (by switcheroo)
02:53karolherbst: because the GPU sends signals that something is odd
02:54karolherbst: well, suspend to disc is a messy feature
02:55karolherbst: the big problem is, that you boot a new kernel, which does _something_ to the GPU
02:55karolherbst: because you still want to display something at some point
02:55karolherbst: but then you switch over to your old boot state and then things just go south
02:56moreno: makes sense
02:56rhyskidd: i've queued up a larger pci rom parsing series and a short BIT header parsing improvement to envytools, if there are keen reviewers
02:57rhyskidd: most is just good housecleaning -- one or two changes should help the groundwork ahead of turing support
02:58karolherbst: rhyskidd: I try to not forget tomorrow
02:58moreno: is it even worth trying removing the nouveau module before suspend and adding it after? (i have nouveau compiled directly into the kernel, so i would need to recompile to test)
03:02pl44c: something I noticed with both the proprietary and open source drivers with my k2000m is that it performs worse in the basic benchmarks from globs and glxgears
03:02pl44c: even when playing xonotic the initegrated is 80-50 fps ahead
03:05pl44c: I'm not going to be gaming/doing anything with the chip besides powering displays but I think it might be misconfigured and it should probably be addressed
03:09karolherbst: moreno: that might actually work, yes
03:10karolherbst: pl44c: glxgears has no meaning regarding performance
03:10karolherbst: and every fps above your refresh rate is meaningless as well
03:11karolherbst: the problem is that with bumblebee/nouveau you have to copy each frame over the PCIe bus
03:11karolherbst: and the bus isn't exactly fast
03:11karolherbst: also, the k2000m is quite a slow GPU
03:13karolherbst: bumblebee caps around 150 fps at FHD, Nouveau at 250 at FHD or something?
03:13karolherbst: the overhead is lower with the approach we have for open source drivers
03:13moreno: Im going to try that then
03:14pl44c: so the GPU is too slow to negate the penalty of copying data over the bus to be faster than the integrated
03:15karolherbst: pl44c: more or less, yes
03:15pl44c: I suppose it'll perform better in a vm
03:15karolherbst: my numbers are for PCIe 3.0 x16
03:15karolherbst: pl44c: how can it?
03:15karolherbst: you still need to copy each frame
03:16karolherbst: you might be able to render at higher speeds inside the VM
03:16karolherbst: but you won't be able to copy the frames fast enough
03:16karolherbst: you can also just start the second X and do a "DISPLAY=:8 ..."
03:16karolherbst: there you get faster frames as well
03:16karolherbst: but no output
03:17karolherbst: mhh, that display thing only works with bumblebee
03:17pl44c: I'm just using prime now
03:17karolherbst: well, there isnt much you can do about all that
03:17pl44c: Are there benefits to using bumblebee with nouveau?
03:17pl44c: over DRI_PRIME
03:17karolherbst: higher PCIe bottleneck ;)
03:18pl44c: so how do I go about unloading the nouveau module to load vfio-pci
03:18karolherbst: pl44c: you are reclocking the GPU under nouveau with the psate file, right?
03:18karolherbst:really should finish his auto reclocking stuff :/
03:19pl44c: karolherbst: no I wasn't and that might have something to do with it but even with bumblebee and the proprietary driver the performance was bad
03:19karolherbst: right, but through the pstate file it should be better than with the prop driver, at least if you hit the PCIe bottleneck
03:19karolherbst: but anyway
03:19karolherbst: it doesn't matter much
03:20pl44c: yeah no because I was only testing and I plan on just using it in a vm mostly
03:20karolherbst: makes no difference if intel still displays at 60 fps, except you care about faster updates and don't mind tearing
03:22pl44c: and don't care about battery
03:25pl44c: ok so vgaswitcharoo says DrnOff for the descrete
03:26pl44c: but nouveau won't unload
03:32pl44c: ok it had a phantom output but it no longer does but now says DynPWR
03:32pl44c: is there a way to force it to stop
03:52moreno: already got nouveau as a module but i can't rmmod it as it says it's in use
04:07karolherbst: moreno: it is in use by X sadly
04:07karolherbst: and if you use nouveau for external displays you can't really change that :/
04:12moreno_: not using it for any display atm
04:13karolherbst: moreno_: then you can configure the dummy driver for the nvidia gpu
04:13karolherbst: I have a config somewhere
04:14moreno_: i first gonna stop X and see if suspend works
04:14moreno_: otherwise its not worth the trouble
04:14karolherbst: you migh want to play around with the intel part a bit though :/
04:15karolherbst: they seem to want to use modesetting these days
04:15karolherbst: but that kind of depends on the gpu if you really want it or not
04:15karolherbst: but then you need the PCI address of the intel gpu as well or something
04:16karolherbst: this is what I am currently using: https://gist.githubusercontent.com/karolherbst/fc7984d221475d369253586b79befb8e/raw/805800e27e12c7d0a20788249f0dcc4a2cf6efb7/gistfile1.txt
04:18moreno_: ty, gonna try out the suspend now, brb
04:38moreno: did some testing and suspend works if i rmmod nouveau
04:40moreno: if i start X without modprobing nouveau suspend still works
04:41moreno: and it looks like X can attach in some way to the driver as i can modprobe it after starting X but then it doesen't let me rmmod it until i stop X again
04:43moreno: karol: just to clarify, the settings you sent wont let me use the video ports that connect directly to the nvidia gpu
04:44sigod: i feel like emailing nvidia to tell them to open their firmware
04:49sigod: they aren't letting me use their product
04:49sigod: even though i bought it
04:50sigod: i might email gigabyte too
04:50sigod: tell them to release a free bios
04:51sigod: stop being such stingy holdouts
04:52sigod: the hate is strong
07:22sigod: i know i've asked this a few times before, but is there any progress on the free firmware for gtx660s in regards to hardware acceleration
07:23sigod: im just not sure where to look to understand the progress
16:48HerrSpliet: msg nickserv status
19:25ReinUsesLisp: from a month ago, TEXS' F16 flag is in the bit 60
19:27karolherbst: ReinUsesLisp: what do you mean?
19:27karolherbst: or what are you refering to?
19:28karolherbst: ReinUsesLisp: sure, but I mean, why looking into it?
19:31ReinUsesLisp: it was brought up when imirkin said to HdkR that he thought he had added all the H* stuff to envydis (kind of old tbh)
19:31karolherbst: I see, mhh
19:31karolherbst: I never actually saw a fp16 texs to be honest
19:32karolherbst: but yeah, might be
19:32ReinUsesLisp: the blob seems to emit half float instructions when you enable `#pragma optionNV(fastprecision on)`
19:34karolherbst: ohh, interesting