00:39mupuf: rhyskidd: thansk for the info
00:41mupuf: rhyskidd: cool for IGT!
00:41mupuf: I ran it on maxwell, there are tons of low hanging fruits on that. We have a presentation about this tomorrow with Arek
03:51that_one_guy_798: Does Nvidia Optimus work with SLI?
03:51that_one_guy_798: Do all 10-seriers notebooks/laptops automatically have Optimus or only some of them?
04:51justin__: i'm in need of assistance. anyone awake and sober?
04:52that_one_guy_798: I am awake and sober, but I am too stupid and inexperienced to help you. :'(
04:53justin__: it'd be like dumb and dumber if we tried to help each other
04:55that_one_guy_798: justin__: I only had general questions, that maybe you could help me with? Does Nvidia Optimus work with SLI? o all 10-seriers notebooks/laptops automatically have Optimus or only some of them?
04:59justin__: in case anyone is lurking - looking for help forcing edid from grub for a VGA monitor that's connected to DVI-I-1 (dongle used). It's a dual monitor setup and I have the edid binary from the other monitor that's in DP-1 and working fine. Thus far adding lines to /etc/default/grub and then update-grub followed by reboot all show errors on boot "error while trying to load edid fimrware" The firmware has been placed in both
04:59justin__: /lib/firmware and /lib/firmware/edid before running update-grub. I suspect I have the syntax wrong in the grub file --- or the edid file is corrupt.
05:00justin__: forgot to mention - Mint 18.3 Cinnamon
15:14Yoshimo: The fosdem slides mention: 2018: New documentation dump for the vbios tables , is that already available somewhere?
15:18Ananace: Oh yeah, is there any link to the FOSDEM slides? Missed that talk due to the AW-building
16:15pmoreau: Yoshimo: https://download.nvidia.com/open-gpu-doc/BIOS-Information-Table/1/BIOS-Information-Table.html
17:57mupuf: Speaking about documentation dump, how about nv_gpu supporting pascal discrete GPUs :o
17:57mupuf: And here is a lot of magic: https://nv-tegra.nvidia.com/gitweb/?p=linux-nvgpu.git;a=blob;f=drivers/gpu/nvgpu/include/nvgpu/bios.h;h=c6465313cf2054e4e6ceadb484466e9741809cb0;hb=l4t/l4t-r28.2-rc
17:58mupuf: karolherbst and I are looking into it, and so far it appears to match our RE, except that we had almost no knowledge for pascal
17:58mupuf: skeggsb: ^
18:01mupuf: Lyude: there is plenty of things for you too, some things are reated to clock gating
18:07JordiGH: I think Google Maps is crashing nouveau (and hence Linux).
18:07JordiGH: How can I provide more information?
18:07imirkin: what kernel are you on?
18:08JordiGH: Btw, I absolutely love nouveau. I got an old Dell laptop on Ebay, and I accidentally bought it with an nvidia card. I thought I was doomed to the blob, but nouveau works perfectly.
18:08JordiGH: (Well, except perhaps now)
18:08imirkin: (and what gpu)
18:08JordiGH: It's linux by Debian, 4.9.65-3+deb9u2
18:08JordiGH: 01:00.0 VGA compatible controller: NVIDIA Corporation G86M [GeForce 8400M GS] (rev a1)
18:09JordiGH: That's what lspci says.
18:09imirkin: right in the sweetspot for GPUs that had those solder joint issues =/
18:09imirkin: anyways, i don't want to definitely blame it on that, but just something to keep in mind
18:10imirkin: and what kinds of errors are you getting?
18:10imirkin: there's a (unfortunately undiagnosed) class of issues that appear to hit tesla gpu's fairly randomly (of which yours is one)
18:19JordiGH: imirkin: I don't know how to get any diagnostic output.
18:19imirkin: ssh in, or use netconsole
18:20JordiGH: This is on my laptop.
18:20JordiGH: The only behaviour I see is a hard lock, followed by a white screen and a reboot.
18:20imirkin: (not sure how that changes things)
18:20JordiGH: Well, why would I ssh into my own laptop?
18:21JordiGH: What is netconsole?
18:21JordiGH: You think I should ssh in from another machine into this one?
18:22Asu`: JordiGH: i used ssh to grab logs while nouveau had crashed and it was pretty easy
18:22JordiGH: Okay, so what am I looking for, syslog?
18:28JordiGH: Okay, I'll try later when I have another laptop. :-)
19:31Lyude: mupuf: oh, I will have to take a look at that next chance I get
21:54nullspoon: Can anyone help me get DRI3 working? I'm using modesetting with "Option DRI 3" in my xorg.conf. Still my Xorg.0.log shows "Initialized DRI2 GL provider for screen 0"
21:55imirkin: nullspoon: that's not the issue
21:55imirkin: i get that line, and DRI3 works fine for me
21:55imirkin: [ 9.320] (II) NOUVEAU(0): DRI3 on EXA enabled
21:55imirkin: you're missing that line iirc
21:55imirkin: figure out why
21:57nullspoon: Well that was helpful.
21:58nullspoon: looks like glxinfo is showing dri3
21:58nullspoon: next need to figure out why DRI_PRIME isn't working
21:58gnarface: i remeber another xorg variable regarding EXA and something else
21:58gnarface: i found it along side the dri2/3 setting
21:58imirkin: oh. you're a different person than the one who was having this issue yesterday or day before.
21:58imirkin: gnarface: in a handful of versions of nouveau
21:58gnarface: imirkin: people are having the same issue on some hardware with intel too
21:59imirkin: nullspoon: LIBGL_DEBUG=verbose DRI_PRIME=1 strace -f -e open glxinfo
21:59imirkin: pastebin the output of that.
22:00gnarface: Option "AccelMethod" "uxa"
22:00gnarface: Option "AccelMethod" "exa"
22:00gnarface: there it is
22:00gnarface: for some reason i thought there was a third possible value i could be wrong
22:00imirkin: that's for xf86-video-intel
22:00imirkin: the options are actually uxa and sna
22:01gnarface: i just remember there was something about having to specify that and the dri version together, as not all the default combinations worked on all hardware
22:01gnarface: but yea it was with intel
22:01gnarface: seemed like basically the same bug but i don't know
22:01nullspoon: imirkin: https://pastebin.com/raw/2Hnch16a
22:01imirkin: it might look similar, but entirely unrelated.
22:02imirkin: nullspoon: that is not the complete output of that command.
22:02nullspoon: erm, just grabbed stdout
22:02imirkin: if you're redirecting to a file, make sure to redirect stderr as well.
22:02imirkin: (which has the actually interesting info)
22:04imirkin: and you're sure you have DRI_PRIME=1 there?
22:05imirkin: ls -l /dev/dri
22:05nullspoon: Yep... LIBGL_DEBUG=verbose DRI_PRIME=1 strace -f -e open glxinfo 2>&1 | xclip -selection clipboard
22:05imirkin: fyi you can do |& instead of 2>&1
22:06imirkin: [same end result]
22:06nullspoon: ls /dev/dri..... by-path/ card0 renderD128
22:06nullspoon: wow. I had no idea
22:06imirkin: so .... uhm ... something seems missing.
22:06nullspoon: Been using linux for years. Never even seen that trick.
22:06imirkin: did you expect there to be a second gpu in there?
22:06nullspoon: I think so?
22:07imirkin: pastebin 'lspci -nn' and 'dmesg'
22:07nullspoon: My box has an intel gpu with an nvidia 1050ti
22:07imirkin: ah. 1050ti might be problematic. let's see what dmesg says.
22:07nullspoon: It's one of those weird ones with a muxer I believe.
22:08nullspoon: I got it working about 6 months ago, but cannot remember for the life of me how I did it.
22:08nullspoon: Except for the wonderful help of the people from this channel. :)
22:08imirkin: you can always check the logs
22:09nullspoon: oh oh oh
22:09nullspoon: I think I might have found it
22:09nullspoon: nouveau 0000:01:00.0: unknown chipset (ffffffff)
22:09imirkin: it's off.
22:10imirkin: powered off
22:10nullspoon: makes sense
22:10imirkin: (pci is active-low, so, that means you read 0xffffffff without power)
22:10nullspoon: so a ways back, I got the tip of modprobing nouveau with runpm=0 because when I probed for it without that, it'd lock my system solid.
22:10imirkin: you can also try pcie_pm=off
22:11imirkin: newer boards have new and improved weird things they do
22:11nullspoon: "new and improved"
22:13nullspoon: well, modprobing with that switch gave me the same error
22:14imirkin: it's not a nouveau error
22:14imirkin: not a nouveau parameter
22:14imirkin: you'd have to boot with it
22:14nullspoon: oh, so can't just do that on modprobe them.
22:14imirkin: hold on
22:14nullspoon: I'll update my kernel params
22:14imirkin: i might have messed up - let me double check
22:15nullspoon: ah, okay
22:15imirkin: (it's a pci parameter, not nouveau-specific)
22:15nullspoon: can I still use it when modprobing?
22:16imirkin: you still can't :)
22:16nullspoon: Just clarifying for my own certainty.
22:16nullspoon: okay. Added to my kernel params. Back in a few
22:20imirkin: and i gotta reboot too... bbiab, hopefully
22:25nullspoon: imirkin_: well, that got me closer I think
22:26nullspoon: at least, I got a different behavior. Now I modprobe nouveau, my box freezes solid for about 30 seconds, and if I try to do glxinfo with DRI_PRIME, the command hangs and my box freezes solid and I have to force reboot.
22:26nullspoon: the modprobe operation blows up my kernel log with nouveau messages
22:27nullspoon: Notably, I get 'nouveau 0000:01:00.0: timeout'
22:29nullspoon: Ha. And the logs point me back to the old bug I added to 5 months ago. https://bugs.freedesktop.org/show_bug.cgi?id=100228
22:30karolherbst: imirkin_: anything wrong with this? 8: not $p0 sustp 2D_MS $r0 $s0 f32 # $r0d $r4q $r2 (8)
22:31karolherbst: I get a ../src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp:3004: void nv50_ir::CodeEmitterGM107::emitSUTarget(): Assertion `insn->tex.target == TEX_TARGET_1D' failed.
22:31nullspoon: imirkin_: Also, now 'ls /dev/dri' gives me card0 and card1
22:35karolherbst: imirkin_: you fixed the blend_equation_advanced CTS tests as it seems?
22:36imirkin: karolherbst: fyi i plugged a GM107 in, so should be easier to get bindless going
22:37karolherbst: I think we miss like 20 CTS tests on my Pascal for 4.5.....
22:37karolherbst: this can't be right, but I can't do a proper full run now anyway
22:38karolherbst: and 9 of those fails are fp64 stuff
22:38karolherbst: ohh, maybe people took care of those API issues
22:39imirkin: could be
22:39imirkin: how'd the talk go today?
22:39karolherbst: fp64: easy
22:40karolherbst: pipeline_statistics_query: we could disable it
22:40imirkin: hmmm .... i wonder why those are failing
22:40karolherbst: precision for fp64
22:41imirkin: i thought we had that covered though
22:41imirkin: or is that without dboyan's patches?
22:41karolherbst: not on pascal
22:41imirkin: a little surprised by that
22:41karolherbst: I think this was a silly error
22:41karolherbst: let me run it
22:42karolherbst: "3D images are not really supported!" :)
22:42imirkin: i can take a closer look
22:42imirkin: 3d images are supported on maxwell+
22:42karolherbst: that what gets printed
22:42imirkin: (warning gets printed, but they really are)
22:42imirkin: maxwell+ gained 3d access
22:43imirkin: although ... hmmm... i could definitely see us mess up the slice thing
22:43karolherbst: those CTS people....
22:43karolherbst: Test log: https://gist.githubusercontent.com/karolherbst/e4211c8c5b606408a8039383402b52cb/raw/95f291b081cd67a45f38360926d5171aff6f8c6b/gistfile1.txt
22:43imirkin: i.e. binding a single layer of a 3d image
22:43imirkin: and treating it as a 2d image
22:43imirkin: i could see that get buggered
22:44karolherbst: Copy with imageLoad and imageStore failed for texture type: 3d. Source and destination textures are different
22:44imirkin: <Text>Copy with imageLoad and imageStore failed for texture type: 3d. Source and destination textures are different</Text>
22:44imirkin: thanks guys
22:45karolherbst: well we probably end up with official 4.5 GL support on Maxwell+ quite fast I guess now
22:45karolherbst: I will probably just go ahead and fix those things at some point
22:51imirkin: i'm getting the same issue with lack of DRI3 that the other dude was having
22:51imirkin: it's not there in the xdpyinfo
22:51imirkin: ok, it's *on*
22:51imirkin: heads are gonna roll
22:51imirkin: hopefully not mine.
22:52imirkin: oh good one.
22:52imirkin: thanks udev.
22:52imirkin: master.st_mode == render.st_mode
22:52imirkin: crw-rw----+ 1 root video 226, 0 Feb 3 17:23 card0
22:53imirkin: crw-rw-rw-+ 1 root root 226, 128 Feb 3 17:23 renderD128
22:53nullspoon: uh oh
22:53imirkin: and now i gotta restart X
22:55imirkin: ok that's better.
22:55imirkin: damn you udev!
22:55nullspoon: Unfortunately, I'm now getting 'Error allocating PGRAPH context for M2MF' on running things with DRI_PRIME
22:56nullspoon: What'd udev do?
22:57imirkin: nullspoon: that's coz you don't have acceleration
22:57imirkin: it's what udev *didn't* do -- it didn't chown the render nodes
22:58nullspoon: ahh. Got it
22:58nullspoon: didn't know those were supposed to be root:video
22:59nullspoon: Actually, looks like mine are.
23:05imirkin: well, i just read the code to try to understand why i wasn't seeing stuff
23:11nullspoon: man this is frustrating
23:12nullspoon: So, I've booted with pcie_port_pm=0 and nouveau.runpm=0 on kernel params. my kernel logs are full of nouveau traces now, from the timeouts.
23:12imirkin: what's the status of your issue?
23:12imirkin: pastebin latest dmesg?
23:14imirkin: something's still stuck
23:15nullspoon: It's really unhelpful that the majority of responses to these errors online are "switch to nvidia"
23:20nullspoon: any chance this could be a conflicting driver issue?
23:21imirkin: would it help if i made a response of like "switch to amd"? :)
23:25nullspoon: I won't lie, after all the pain of having this nice laptop and spending so much time tryign to get this working, I'd consider getting a different gpu manufacturer in the future.
23:25nullspoon: It's like nvidia goes out of their way to make this as hard for open source folks as possible.
23:26imirkin: i don't flatter myself enough to think that they'd go to that trouble
23:27nullspoon: Doesn't make any financial sense of course.
23:27nullspoon: Oh sunnuva
23:27nullspoon: What's wrong with this kernel param.... "ro pci_port_pm=off nouveau.runpm=0"
23:28nullspoon: *sigh*. Rebooting.
23:31nullspoon: Sadly, nope. Didn't fix it
23:31nullspoon: Still get the pgraph error
23:33imirkin: can you get a dmesg that includes the start of all your errors?
23:33imirkin: the one you pasted earlier was kind of in the middle of things
23:33nullspoon: yep. Sorry about that. System had been running long enough. looks like it didn't include all of it.
23:35imirkin: there's like 0 chance this matters, but ...
23:35imirkin: mind trying nouveau.config=NvForcePost=1
23:39nullspoon: looks like no effect
23:40imirkin: was worth a shot =/
23:40imirkin: oh, there's like
23:40imirkin: some acpi_osi thing
23:41imirkin: acpi_osi="!Windows 2015"
23:41imirkin: (kill the forcepost thing)
23:42nullspoon: that's a hell of a workaround
23:42imirkin: nullspoon: which laptop do you have?
23:43nullspoon: asus rog gl753v
23:45imirkin: looks like this dude did a bunch of research
23:45imirkin: unfortunately, no resolution
23:46imirkin: unfortunately my knowledge of all this stuff is limited ... Lekensteyn is the expert.
23:47nullspoon: that's a lot of great info.
23:47nullspoon: I'll have to try a few of those.
23:47nullspoon: Likely some of that will behave a little differently for me (I hope). I run Crux and compile my own kernel, no systemd, etc.
23:48imirkin: crux is a distro?
23:48imirkin: ah yeah.
23:48nullspoon: my favorite. :)
23:49nullspoon: The distro is just a hair above being configured with a big shell script.
23:49imirkin: ah cool. seems slackware-ish
23:49nullspoon: It is, but with recursive dependency resolution
23:49imirkin: haven't used slackware in a while
23:49nullspoon: and hosting your own packages is really easy. The packaging format is just a shell script with a few predefined variables and a build() function
23:50imirkin: i remember downloading the floppies on a 14.4 modem.
23:50imirkin: a, d, x... maybe another one
23:50nullspoon: I wasn't into linux in those days. I do remember the stack of sloppies for windows 3.1 though.
23:54imirkin: it was my first experience with linux iirc... a bit rough.
23:58nullspoon: well, no go on that
23:58nullspoon: I think I'm going to give up for the day