02:25 Orbstheorem: Hi, I'm running nixos 17.09, kernel 4.9.61. I have a Lenovo P50 with two GPUs (Intel P530 + NVIDIA Quadro M2000M). I'm trying to follow the instructions on https://nouveau.freedesktop.org/wiki/Optimus/ to get 3D offloading; but setting the DRI_PRIME env variable doesn't work: https://paste.gnugen.ch/raw/cGY1
02:26 Orbstheorem: using outputs on discrete gpu work well though
02:41 imirkin_: Orbstheorem: are you using DRI3?
02:41 imirkin_: Orbstheorem: pastebin dmesg?
03:52 Orbstheorem: imirkin_: https://paste.gnugen.ch/raw/3xYR
03:52 Orbstheorem: I'm not sure if I'm using DRI3, how can I verify/
03:53 imirkin_: hm. everything looks perfectly happy....
03:53 imirkin_: LIBGL_DEBUG=verbose DRI_PRIME=1 glxinfo
03:54 imirkin_: do you have nouveau_dri.so installed?
03:54 Orbstheorem: LIBGL_DEBUG: https://paste.gnugen.ch/raw/2lqh
03:55 Orbstheorem: yes, I have nouveau_dri.so
03:55 imirkin_: OpenGL renderer string: Gallium 0.4 on NV117
03:55 imirkin_: seems fine. what's the issue?
03:56 Orbstheorem: :o
03:59 Orbstheorem: I don't understand: https://paste.gnugen.ch/raw/6NnZ when I grep the "OpenGL vendor string" It magically changes to Intel...
04:00 Orbstheorem: Weird...
04:00 Orbstheorem: I can only say it was not working a couple of mins ago ><
04:00 Orbstheorem: Can't reproduce :/
04:09 imirkin_: uh huh
04:12 Orbstheorem: well, my kernel is not happy anymore: https://paste.gnugen.ch/raw/G4X4
04:15 imirkin_: some kind of multithreaded app probably?
04:17 Orbstheorem: modded minecraft
04:23 imirkin_: yeah, iirc minecraft has issues with nouveau
04:29 Aristar: i think my PRAMIN needs to get some more exercise, it keeps getting exhausted :)
04:29 Aristar: kernel: Emergency Sync complete (just in case, lol)
04:30 Aristar: can never get any useful dumps or traces from nouveau though
04:31 Aristar: probably need a crashkernel
04:31 Aristar: if it doesn't entirely lockup the hardware... which 95% of the time it does
04:35 Orbstheorem: what is DRI2/DRI3?
04:38 imirkin_: Orbstheorem: let's say you have a GPU, which can render images
04:38 imirkin_: Orbstheorem: and let's say you would like to have those images get displayed on some outputs on that gpu
04:39 imirkin_: but you're not the only program in the universe that wants to be controlling the images
04:39 imirkin_: DRI is a way to communicate "place GPU image X at place Y" to the controlling entity (e.g. Xorg)
04:48 Orbstheorem: thanks
04:48 imirkin_: (DRI = Direct Rendering Infrastructure)
04:49 imirkin_: the diff between DRI2 and DRI3 are some specifics as to precisely how that's done
06:08 imirkin: tobijk: have a look at https://hastebin.com/awopiyamew.php
06:08 imirkin: a bit hacky, but appears to be functional
06:09 imirkin: gets rid of a bunch of the undesirable cases
06:09 imirkin: should probably do the coalesce crap before the last CSE run - that should get a bunch more
06:09 imirkin: er, condenseSrcs
06:10 imirkin: otoh, more RA pressure. difficult call
06:11 imirkin: er hm, wait, i think i just did this the dumb way... let's try again
06:21 imirkin: yeah, this is way simpler: https://hastebin.com/duqozefaya.hs
06:46 imirkin: mildly more correct version - https://hastebin.com/rekusofiqa.hs
12:34 RSpliet: Wow... I never quite appreciated how complete Micron documents their DRAM chips.
12:35 RSpliet:takes a bow
12:37 karolherbst: RSpliet: if they would not, I am sure they would be flodded with customer support requests
12:41 RSpliet: karolherbst: Not sure... SKHynix documentation is a lot less complete
12:50 mupuf: RSpliet: maybe actual customers get all the information ;)
12:50 RSpliet: presumably...
12:52 RSpliet: Although all DRAM manufacturers are operating at maximum capacity. I can't even become a customer right now and get the sheets ;-)
12:53 karolherbst: mupuf: by the way, I am a bit unhappy about the response you got...
12:54 karolherbst: I mean, we already have an approximation right? No idea why we should get a different one just for the sake of helping in some way.
12:59 mupuf: karolherbst: what answer
13:00 mupuf: ?
13:00 mupuf: karolherbst: not sure I understand what you mean :)
13:01 karolherbst: from your doc request
13:01 karolherbst: well lets with what they come up with
13:23 tobijk: imirkin: oh, i just found your patch (https://hastebin.com/rekusofiqa.hs) in the logs, will check for its impact later
14:24 imirkin: pmoreau: https://github.com/Igalia/mesa/commits/arb_gl_spirv-series1-v1
14:24 imirkin: looks like it's getting close. and there's CTS tests for ARB_gl_spirv i believe.
14:26 imirkin: er, nevermind on the CTS
14:26 imirkin: pmoreau: either way, where's your code at nowadays? (i know you've told me 100x, but it's nowhere i can remember offhand)
14:26 pmoreau: :-D
14:26 pmoreau: No problems :-)
14:28 pmoreau: So, a bit hard to tell where it’s at. Feature-wise, it should handle most type of memory accesses (except anything dealing with textures and images), and some operations (haven’t added all the math stuff like cos & co).
14:28 imirkin: i was thinking a git remote i could fetch from for "where it's at"
14:29 pmoreau: Ah, that “at”. I wasn’t entirely sure :-)
14:32 pmoreau: imirkin: https://phabricator.pmoreau.org/diffusion/MESA/mesa.git, branch: nouveau_spirv_support
14:32 imirkin: right thanks
14:32 imirkin: let me add that to my git tree before i forget YET AGAIN
14:32 pmoreau: Ah ah ah. I won’t be mad at you if you forget about it and come back to ask me. :-)
14:33 imirkin: $ git remote add pmoreau https://phabricator.pmoreau.org/diffusion/MESA/mesa.git
14:33 imirkin: all done.
14:33 pmoreau: \o/
14:33 pmoreau: If you want to play with the OpenGL SPIR-V, I should probably set up another branch for you, which doesn’t involve having a custom LLVM.
14:34 imirkin: nah, do your thing, i'll do mine :)
14:34 imirkin: maybe we'll even converge
14:34 imirkin: there's a lot of stuff i want to do
14:34 imirkin: and pretty much zero time to do it in
14:34 imirkin: so ... me saying i want to look at something ... doesn't always translate into it actually happening
14:34 pmoreau: Yeah, I sadly know that as well.
14:36 pmoreau: You might want to revert 61a6227a3f6b “[HACK] clover: `clCreateProgramWithSource` using SPIR-V”, this is the one adding the custom LLVM requirement.
17:36 linkmauve1: Hi nyef`, I’ve been told you are the one who implemented HDMI 3D support in Nouveau, did you test it using a PSVR or some other kind of HMD?
17:36 linkmauve1: I just sent a series adding HDMI 3D support to Weston, you may be interested in testing it with Nouveau.
17:36 linkmauve1: https://patchwork.freedesktop.org/series/33793/
17:48 nyef`: linkmauve1: No, all of my work was with the PlayStation 3D Display and an LG 3D TV.
17:50 nyef`: That said, this looks interesting. I've been not-doing any of the userland stuff for various reasons, including wanting to cover the 3D Vision Kit hardware (which uses a different setup generally), and having been focusing on other projects.
17:52 linkmauve1: My main interest is in VR, but stereoscopy seemed like an obvious first step to make userland aware of this kind of setup.
17:52 linkmauve1: What is 3D Vision Kit btw?
17:53 linkmauve1: How is it exposed by the kernel?
17:53 nyef`: ... definitely going to have to read through this.
17:53 nyef`: The 3D Vision Kit is nVidia's IR setup.
17:54 nyef`: Roughly, you drive your display at 100Hz or more, and there's a USB device that has the IR emitter, and you tell it to switch sides every frame.
17:54 linkmauve1: Hmm, but the DRM API is the same, right?
17:55 imirkin_: it's unsupported on linux, atm
17:55 linkmauve1: The userland-kernel communication shouldn’t have to care about the particular hardware, in this case it would only see a stereo mode of 50Hz.
17:55 nyef`: No idea yet. There's some "drivers" for Linux, but they don't work for me.
17:55 linkmauve1: Hmm, I see.
17:55 nyef`: Apparently some of the tuning parameters are set by looking up the display EDID in an internal database.
17:56 linkmauve1: Ugh, so pretty much what will also be needed by VR displays, which seemingly think they are better than other displays and don’t advertise support for 3D modes…
17:57 imirkin_: the 3d vision thing is a purely software solution, right?
17:57 imirkin_: i mean, except for the IR emitter
17:57 nyef`: Also the 3D Vision Kit stuff for Linux is purely user-mode, and kindof sucks.
17:57 imirkin_: it's just a thing that cleverly displays stuff every other frame
17:57 imirkin_: with a plain ol' regular display
17:57 nyef`: Right. Nothing fancy on the display end except for supporting at least 100Hz refresh.
17:57 imirkin_: and presumably you have glasses that sync to the IR emitter thing
17:58 nyef`: Right. Or there are apparently wired-USB glasses, but I haven't come across any of those yet.
17:58 linkmauve1: Oh, I missed that part.
17:58 imirkin_: and if you looked at the display without glasses you'd get a seizure.
17:58 linkmauve1: :D
17:58 nyef`: Refresh rates are typically high enough that it's not particularly discomfiting to view straight-up.
17:59 linkmauve1: The two TVs I’ve tested had active glasses, probably also controlled through IR or some similar technology, since they would shut down once out of range for long enough.
17:59 imirkin_: wouldn't it be flickering pretty substantially due to the alternating left/right views?
17:59 imirkin_: or you just see it as a blur?
17:59 linkmauve1: On my TVs, you see it as two images displayed at once, each with 50% alpha.
17:59 nyef`: It's a bit of seeing both at once. Persistence of vision effects start kicking in by that point.
18:00 imirkin_: yeah ok
18:00 nyef`: The flickering thing is what you get at 30fps to each eye on a 60Hz refresh.
18:00 imirkin_: so don't try that trick on a 30hz display with 15 effective? :)
18:01 nyef`: ... That'll probably actually be annoying, not be a good overall display, but not nearly as headache-inducing.
18:01 nyef`: (Then again, should be easy enough to simulate in order to check, it's not like you'd need the 3D hardware for it.)
18:02 linkmauve1: nyef`, so the only differences with “traditional” 3DTV is that you don’t get the modes in the EDID (of course), and that currently it’s userland which needs to communicate/synchronise with the external device?
18:03 nyef`: The 3D Vision Kit drivers for windows have four sets of emitter firmware. I have hardware for two of them (one the desktop / external emitter, one the laptop emitter), I suspect that the other two might be the wired glasses and the "Pro" RF glasses.
18:04 nyef`: Not the only differences, but basically, yeah. Again, one of the differences is that the 3D Vision Kit currently doesn't generate a 3D effect at all on most displays... But if it did, it's tied into a "quad buffer emulator" so that existing userland applications should work with it.
18:05 linkmauve1: One of my goals was to implement quad buffering in Mesa, but it seemed like a ton of work and never got the time to even start.
18:07 linkmauve1: It would require writing an EGL extension too.
18:07 nyef`: Mmm. I want quad buffering in Mesa as well, but the hardware that I'm mostly going to want to use is my 3D Vision Kit stuff, not the 3DTV stuff, so I've not really been looking into it very much.
18:07 nyef`: I figured that DRI2 actually has the hooks for it already.
18:07 linkmauve1: There shouldn’t be much difference, right?
18:08 linkmauve1: I don’t have any interest in Xorg, fyi, so I would have to use EGL/Wayland or DRI3.
18:08 nyef`: I'm not particularly familiar with EGL, since I'm still running X, which means DRI2/DRI3.
18:08 nyef`: And DRI3 definitely *doesn't* have the hooks for it.
18:08 linkmauve1: My main usecase was the Citra emulator, to play the Nintendo 3DS on a bigger screen. :)
18:09 linkmauve1: I wrote a blog post talking about that: https://linkmauve.fr/blog/post/2017/09/08/adding-a-third-dimension-to-wayland/
18:09 nyef`: Yeah, it's linked from the cover letter of the patch series you posted. I already have it open. (-:
18:09 linkmauve1: ^^
18:11 nyef`: Citra sounds neat, though. And one of my use-cases for stereoscopy is actually Master System emulation.
18:12 imirkin_: isn't master well, well, well, well before stereo?
18:12 imirkin_: it's the one before megadrive/genesis
18:12 linkmauve1: imirkin_, emulation can do a lot of things. :p
18:13 linkmauve1: I’d like to point to this paper: https://www.cs.cmu.edu/~tom7/zelda/zelda.pdf
18:13 nyef`: imirkin_: There are a handful of games that use an LCD crystal shutter setup. 30FPS to each eye, from a 60Hz display refresh.
18:13 imirkin_: are we talking about diff things? i'm talking about a console
18:14 nyef`: http://segaretro.org/3-D_Glasses
18:15 imirkin_: The Glasses were released in the UK in October 1987 at a price of £39.95
18:15 imirkin_: wow.
18:15 imirkin_: i was not cool enough for that.
18:16 linkmauve1: Nice!
18:16 linkmauve1: I didn’t know about that.
18:16 imirkin_: nor did i know about the existence of a Master System II
18:17 nyef`: The real trick is going to be getting that going *and* a light gun.
18:17 imirkin_: hehe
18:18 linkmauve1: nyef`, a Wiimote? :)
18:18 nyef`: Hrm. Actually, thinking about it, I probably still have most of the hardware, and might just have to print new arms for the glasses and be able to play. I even still have a CRT TV!
18:18 imirkin_: did you know that nintendo released consoles before the wii? :p
18:19 linkmauve1: imirkin_, like the Virtual Boy? :D
18:19 imirkin_: wow, wii came out > 10y ago
18:19 imirkin_: there's a generation of kids that know nothing else.
18:19 imirkin_: linkmauve1: yes, just like that :p
18:19 nyef`: imirkin_: Some of them even had 3D games! But IIRC, just anaglyph stereo.
18:20 linkmauve1: I never knew the Virtual Boy, I was four when it got released.
18:21 linkmauve1: But I discovered the SNES and the NES way later, somehow. ^^
18:21 imirkin_: NES and Game Boy were awesome.
18:22 imirkin_: in an age before games on a TI-82 ;)
18:39 nyef`: Hrm... I wonder if the interlaced mode controls on the DISP could be abused to output a stereo framebuffer without needing to constantly swap left and right images in time?
18:40 nyef`: Not really something that needs digging into until I have the IR emitters working properly, but still...
18:51 imirkin_: mmmm ... i dunno how interlaced modes normally work
18:52 imirkin_: i think the idea is you have one fb, and you scan out every other line on alternating frames
18:52 imirkin_: but i have no idea what shows up on the screen when you do
18:52 imirkin_: esp with a LCD/CRT
18:55 nyef`: I noticed when I was messing with the timing calculations that interlaced modes are set up such that there's an odd half-line in the vertical blank period, and there's more timing registers in play for interlace, but I'm not remembering too much of the details.
18:56 imirkin_: right, i just mean when a display is in interlaced mode
18:56 imirkin_: it's not like it flips between one and the next picture
18:56 imirkin_: it "composites" them visually
18:56 nyef`: Right, but, at least historically, that was triggered by the odd half-line in the vblank period.
18:57 imirkin_: hmmmm ok
18:57 nyef`: So without the half-line, you get a progressive scan mode instead, at least on the display end.
18:57 imirkin_: interesting.
18:58 nyef`: And with an analog signal (VGA or DVI-A), there isn't really any other way to pass the mode information anyway.
18:58 imirkin_: right
18:59 nyef`: Since, IIRC, the sync signal polarity combinations are basically all assigned for other aspects of the video mode.
18:59 imirkin_: yeah i have no idea regarding the literal mode stuff
19:00 nyef`: And, of course, my local copy of the linux source pre-dates the stereo patches landing.
19:05 nyef`: Hrm. Pre-GF110, interlace is part of the "head mode". GF110 and later, it's set up in "dac enable" and "sor update".
19:09 nyef`: "dac enable" looks to be configuring sync pulses...
19:09 nyef`: ... wait, this is the *same logic* in "sor update". WTF?
19:12 nyef`: Okay, there's experimenting that can be done here, but not before Sunday at the earliest.
19:14 nyef`: ... And it doesn't really *need* to be done any time soon, if at all, because no working 3D Vision Kit.
22:12 pmoreau: tobijk: I don’t have push rights either :-)
22:12 karolherbst:is wondering if he should get some
22:13 pmoreau: I’ll probably ask for them in a couple of patches.
22:13 pmoreau: I might be eligible for the Steam thing now.
22:17 karolherbst: nice
22:18 pmoreau: karolherbst: Is kherbst you as well?
22:18 tobijk: maybe we all should try to get some pushrights :D
22:18 kherbst: pmoreau: maybe
22:18 pmoreau: :-D
22:19 pmoreau: Looks like it :-)
22:19 boot1: are there any cards that support eight monitors?
22:19 pmoreau: tobijk: Push rights party?
22:19 imirkin_: boot1: nvidia GPUs are limited to 4 CRTC's right now
22:20 imirkin_: boot1: i believe there's a successor to the NVS 420 which has 2 GPUs on it and supports 8 outputs from a single-slot board
22:20 nyef`: ... So, are there any cards with dual 4-CRTC GPUs? Since we know that they used to make a... Guess that answers that question.
22:21 boot1: does the NVS 420 exist yet or in production?
22:21 nyef`: The disadvantage there being, IIRC, that nouveau doesn't support them being used that way very well?
22:21 imirkin_: boot1: http://www.nvidia.com/object/nvs-product-overview.html
22:21 boot1: I like this card https://www.pny.com/nvidia_nvs_810_for_eight_dp_displays
22:21 imirkin_: NVS 810 is the successor
22:21 tobijk: pmoreau: yeah :)
22:21 boot1: but is there drivers for it?
22:21 boot1: er, are there
22:21 imirkin_: nvidia blob drivers certainly will work with it
22:22 imirkin_: nouveau should probably work semi-ok with it
22:22 boot1: can i use the blob drivers with libreboot?
22:22 imirkin_: no clue
22:23 imirkin_: i also believe you can get AMD gpu's with 6 outputs
22:23 imirkin_: those are much better supported by open-source drivers
22:23 imirkin_: i'm less familiar with specific models... you're looking for eye-finity
22:23 imirkin_: or something dumb like that
22:33 airlied: or use MST
22:36 imirkin_: how does that help?
22:38 nyef`: I can more easily see MST helping if you need duplicates of the same output, but would it help if you need *different* output for each display?
22:38 Lyude: yes
22:38 nyef`: Okay then.
22:38 imirkin_: really?
22:38 Lyude: the only thing you need to make sure is that you have the CRTCs to drive it
22:38 imirkin_: yeah
22:38 imirkin_: so since you only have 4 per GPU...
22:38 Lyude: if you're trying to workaround that: no, it won't help.
22:38 imirkin_: MST ain't gonna help you get 8
22:39 nyef`: Certainly won't get you to 3000.
22:39 imirkin_: i think there might be a limit of 64 displays per DP connection ;)
22:39 imirkin_: [at the protocol level]
22:40 imirkin_: when i said "6 outputs" i meant "6 CRTCs"
22:40 imirkin_: i think some amd parts don't have 6 crtc's, others do.
22:41 airlied: imirkin_: mst hubs lets you plug more things in
22:41 airlied: if you only have say 2 dp connectors
22:41 airlied: you can still run 6 monitors
22:41 imirkin_: airlied: sure. if you have 6 CRTC's.
22:41 airlied: nearly all radeon's have 6 crtcs
22:41 airlied: I think it's only the integraated ones that have less
22:41 imirkin_: oh really? i thought that some were fused off
22:42 imirkin_: airlied: have you tried adding loops in your MST hubs?
22:42 airlied: imirkin_: I didn't have the cables necessary, but the protocol "handles" loops :-P
22:42 imirkin_: just curious ;)
22:43 imirkin_: occasionally there's a gap between theory and practice
22:43 Lyude: yeah everything up to like, r600 I believe has 6 crtcs
22:43 Lyude: *down to like
22:43 airlied: hmm okay for some reason polaris 11/12 only have 5
22:43 airlied: polaris 10 has 6
22:43 Lyude: weird
22:43 airlied: and the integrated have 2 or 3
22:43 Lyude: I wonder if one of them is a special one that can do more bw then the others?
22:43 airlied: agd5f: why do pol10/11 only have 5 crtcs?
22:44 airlied: pol 11/12
22:47 agd5f: airlied, die size and bandwidth I guess?
22:47 agd5f: some APUs support 4
22:48 agd5f: KV and RV are 4, CZ/BR was 3
22:48 agd5f: the little APUs are usually 2
22:49 agd5f: some smaller dGPUs have less as well. E.g., cedar and caicos were 4
22:59 agd5f: I guess market segments and use cases are also a factor
23:02 airlied: agd5f: ah cool, just seemed strange if I replaced by pol10 with an 11 it would go backwards :)
23:03 agd5f: airlied, 11 and 12 are smaller dies, less CUs, etc.
23:24 boot1: ok
23:24 boot1: what are CRTCs?
23:24 nyef`: Cathode Ray Tube Controllers.
23:24 Lyude: CRT controllers, it's an old name for the piece of hw that scans out images to the display
23:25 nyef`: (From back when you actually had a desktop particle accellerator.)
23:25 Lyude: Basically the number of CRTCs you have is how many displays of the same resolution you can have supported, every additional pixel clock allows you to to support an additional resolution being used at the same time as the others
23:25 boot1: and MST?
23:25 nyef`: Multi-Stream Transport.
23:25 Lyude: multistream transport, it's for daisy chaining dp displays
23:25 nyef`: Or Mystery Science Theater.
23:25 Lyude: yes, or that
23:26 boot1: https://www.pny.com/nvidia_nvs_810_for_eight_dp_displays uses CRT?
23:26 Lyude: CRTCs
23:26 boot1: whoops, got to run, thanks for all the help guys!
23:26 Lyude: np
23:44 tobijk: imirkin_: the hunk you pastebinned today seems to work fine, now we only have to kill the leftovers: (look at $r3) https://hastebin.com/ipihubadok.pl
23:45 imirkin_: $r3 gets used ;)
23:45 imirkin_: just lower down
23:45 imirkin_: 57: st u64 # l[0x80] $r2d (8)
23:46 tobijk: mh quick skip overs are not good ;-)
23:46 tobijk: yeah nvm
23:46 imirkin_: [and i know why it happens, but ... non-trivial to fix]
23:47 imirkin_: tobijk: let me know if you run it against shader-db
23:47 tobijk: imirkin_: havent yet, but will do, it runs on its own, so not much to do for me ^^
23:50 tobijk: imirkin_: and yeah the other 0x0's are originating the $r3, so the "dumbest instruction scheduler known to mankind" is needed :) (you called it like that)
23:51 imirkin_: well, there's a few issues...