00:31rhyskidd: karolherbst: so the runpm issues have been narrowed down to something in the Pascal vbios SEQ scripts?
00:41rhyskidd: mwk: as a reviewer are you happy w/ my PMU microcode doc PR for envytools, for me to merge it now? all comments should have been addressed
00:44imirkin: skeggsb: remind me what xf86-video-nouveau does that mesa doesn't?
00:49skeggsb: imirkin: the weirdo vblank stuff using sw methods
01:02imirkin: oh right yeah
01:02skeggsb: i'd have attempted to verify/fix myself by now, except the couple of times i've tried, i haven't been able to reproduce it..
01:04imirkin: skeggsb: it doesn't happen every time ... and i think some gpu's are more affected than others
01:05imirkin: no clue what drives that though
01:05skeggsb: it's "just" a race condition, if that's the cause
01:05skeggsb: no guarantee it actually is though
09:50SmallR2002: I am having issues with the nouveau driver. I have six screens over two cards using xrandr. Randomly the entire graphical part locks up, I cannot recover even when trying to kill X and start it again. I can still SSH in but can't switch to terminal. Here's a log or two from crashes. https://pastebin.com/DZE1d7Z9
09:51SmallR2002: I've tried noaccel but it simply prevents me from using a graphical desktop at all.
09:52HdkR: I had a similar issue once. Happened because I managed to overlap a couple screens by a few pixels in my setup. Other than that no idea :P
09:58SmallR2002: I have a grid of six screens but they're not all aligned quite perfectly by card, so top row is 1, 1, 2 the bottom row is 2, 2, 1. Maybe that's related?
09:59SmallR2002: The official drivers plus Xinerwhatsit have zero performance, this I can actually watch videos on and stuff but I'm getting at least a crash a day when using it.
11:44SmallR2002: I was hoping it'd be a bit more active on here, I've found similar bugs to mine on a few forums but no fixes
11:55karolherbst: SmallR2002: well, the log isn't helpful
11:55karolherbst: I _except_ that this could be due to our issues we have with multiple GL contexts or some other fails
11:59imirkin: SmallR2002: which two gpu's?
12:06RSpliet: Going through the public IRC logs (my bouncer is down :-C) I found this little ping from "adya" and "nikk_" (both not on IRC) about their effort for fbo-blending-formats. They linked to https://docs.google.com/document/d/19ifBXylDF0LyrzoB06rQ7gsBqkida08__aZqVEZUNV0/edit . Had anyone taken a look at their work?
12:11rhyskidd: can I get an R-b on this nv50/ir patch? https://patchwork.freedesktop.org/patch/243964/
12:12imirkin: rhyskidd: r-b
12:30SmallR2002: karolherbst and imirkin, two GPU's, yes, what would be useful logs?
12:31SmallR2002: VGA compatible controller: NVIDIA Corporation GK107 [GeForce GT 740] (rev a1)
12:32SmallR2002: They're as identical as I can be sure they are
12:32SmallR2002: Same lspci output
12:32SmallR2002: I do have onboard graphics too, would it make sense to try nouveau+intel instead of nouveau+nouveau?
12:34imirkin: SmallR2002: hm ok. those should work reasonably well.
12:34imirkin: intel+nouveau should be more reliable
12:34imirkin: use intel as primary
12:34SmallR2002: To be fair, I've used the official drivers and they are unbearably slow so even with crashes this is an improvement
12:36SmallR2002: OK, I'll have to find some DisplayPort to other things adapters and try the intel GPU
13:03rhyskidd: imirkin: thanks
14:04SmallR2002: nouveau+intel is also not really working. Plasma crashes, Gnome3 just displays to two screens and only from the intel card but I can put my mouse through all of them just not a background or application.
14:07SmallR2002: To get hexchat working and return I had to disable all but one screen
14:07SmallR2002: Any suggestions imirkin?
14:08imirkin: did you make intel primary?
14:08SmallR2002: Define primary
14:08SmallR2002: OK, that got a smirk from me
14:09imirkin: so that all rendering happens on intel gpu
14:09RSpliet: karolherbst: If you want to have a compute kernel that is as much "fun" as pixmark piano, look at the "heartwall" OpenCL benchmark in the Rodinia suite. The thing on kepler is 2890 instructions long and somehow manages with only 49 GPRs
14:09imirkin: and so that when you run 'glxinfo' it talks about intel, not nouveau
14:09SmallR2002: In my BIOS I told it that the 'IGP' was the main display and also allowed it to display to 'PGE/PGX' devices
14:09SmallR2002: In my x config I added the intel one as the first device
14:09SmallR2002: Checking glx
14:09imirkin: that shoudl generally translate into intel being primary in X, but check
14:11SmallR2002: Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel Open Source Technology Center (0x8086)
14:11SmallR2002: That's what glxinfo says
14:11imirkin: ok cool
14:11imirkin: and you're still getting issues?
14:12imirkin: are you using the intel ddx or modesetting ddx?
14:12imirkin: whichever you're using, try the other one
14:13SmallR2002: I'm going to go Google that :)
14:13imirkin: check your xorg log
14:14imirkin: does it say intel(0) or modeset(0)
14:15sigod__: hi imirkin
14:18SmallR2002: Most worryingly it appears that my Xorg.0.log isn't actually getting logged to
14:18imirkin: you're probably using systemd
14:18imirkin: which makes everything horrible.
14:18imirkin: good luck tracking it down.
14:18sigod: imirkin, i was just wondering about the progress of work on opensource firmware for kepler
14:19imirkin: sigod: is there something specific you have in mind?
14:20sigod: imirkin, just what stage it's at, whether 3d acceleration is working properly without the nvidia firmware
14:20imirkin: in general, yes
14:20imirkin: but there's tons of issues, almost none firmware-related
14:21imirkin: GTX 660's appear to have trouble with our firmware but work with nvidia firmware. no idea why.
14:21imirkin: been that way since the dawn of time
14:21sigod: oh ok so that isnt fixed yet
14:21imirkin: (some GTX 660's, that is)
14:21imirkin: not fixed, no one working on it, unlikely to ever be fixed.
14:22sigod: oh ok
14:22imirkin: [since that would require someone to work on it]
14:22sigod: that's what i was wondering
14:22imirkin: if you want a gpu that works well with open-source, stick to intel and amd.
14:22sigod: i thought karolherbst was taking a look at it
14:23imirkin: everyone's taken a look at it.
14:23imirkin: result => "huh, that's weird"
14:24sigod: ok no worries, dont amd gpus require non-free microcode
14:24imirkin: non-free ASICs too
14:24imirkin: and non-free PCB designs
14:24imirkin: all kinds of stuff really
14:24imirkin: but it's all part of "the hardware", and doesn't run on your cpu, so it doesn't really matter
14:25imirkin: i'm quite a bit more concerned about the intel microcode which DOES run on the cpu...
14:26sigod: yea intel management engine
14:26imirkin: amd has its own thing too, of course
14:26sigod: i have an i7 950 i dont think it has the ime
14:26imirkin: either way ... whether some stuff is shipped in a ROM on the board, of it it has to get loaded off my hd -- doesn't really concern me.
14:27sigod: but it would be better if it wasnt a binary though?
14:27imirkin: sigod: core2 and later have it. so you definitely do.
14:28imirkin: better? maybe. not materially different though. "insert this sequence of bytes to make our hardware operate properly".
14:28imirkin: we can decode the nvidia firmare just fine btw
14:28imirkin: we just can't ship it.
14:29imirkin: that's where the problems lie - distribution
14:29imirkin: amd/intel firmware is properly redistributable
14:29SmallR2002: I have previous X logs, just not the current one
14:29SmallR2002: How is that possible?
14:29imirkin: SmallR2002: you use systemd
14:29SmallR2002: Previous from the same day
14:29imirkin: with systemd, anything is possible.
14:29SmallR2002: This is true
14:30SmallR2002: So, I will play with those settings and see what I can/can't do
14:30imirkin: (except for the one thing you actually want...)
14:30sigod: so does the nouveau driver have "opensource firmware" in it
14:30imirkin: sigod: yes
14:30imirkin: well, compiled obviously
14:30RSpliet: SmallR2002: are you sure you checked your logs using the journalctl wizardry?
14:30imirkin: ultimately it's instructions we have to feed to the GPU
14:31SmallR2002: It claims there's no such thing as X, what else would I expect when doing it from a graphical X terminal...
14:31sigod: oh ok so if you can decode the nvidia firmware wouldnt you be able to compare that with the nouveau open source firmware for the gtx660 and find out why it is crashing?
14:31imirkin: sigod: sure. same way you can decode windows code and linux code and compare them to see why some piece of hardware isn't working.
14:31RSpliet: SmallR2002: There is Xorg... which on Fedora is usually launched from "gdm" (lightdm on Ubuntu/Debian derivatives? Idk...)
14:32sigod: oh ok so nvidia firmware is written totally differently
14:32imirkin: we can't *copy* it...
14:32imirkin: since that would, you know, violate copyright
14:32imirkin: so we have our own thing, they have theirs
14:32RSpliet: SmallR2002: Perhaps consult your distro channel for help on finding these logs - it depends as much on systemd as on the service file configuration shipping with your distro.
14:32SmallR2002: I am manually setting the driver to intel, does this simply mean setting it to modeset?
14:32imirkin: there's obviously some similarities (they're driving the same hw)
14:32imirkin: SmallR2002: Driver "intel" or Driver "modesetting"
14:33SmallR2002: It f'n worked an hour ago RSpliet, I swear systemd is designed to send me nuts
14:33SmallR2002: I have it set to intel, I shall switch and report back
14:33imirkin: SmallR2002: why do you use it if you hate it so much?
14:33imirkin: i hate it and i just don't use it :)
14:33RSpliet: SmallR2002: Don't shoot the messenger
14:33sigod: id like to help i need to go and learn lisp and read all your docs but im not in a good frame of mind
14:33imirkin: i'm just annoyed when people come in expecting me to debug it.
14:36sigod: do you guys ever think it would be better to abandon nvidia and just use hardware that has specs available
14:36sigod: or is it the challenge
14:40SmallR2002: RSpliet, I belong to the generation that remembers when log files were in log files ;)
14:40SmallR2002: imirkin, I actually don't hate it all the time, just when it breaks
14:41SmallR2002: Mostly, on desktops and laptops it works fine
14:41SmallR2002: Then OpenRC or SysV on servers
14:41RSpliet: SmallR2002: I'm neither defending nor attacking SystemD, my opinion is irrelevant. Just trying to give you the right pointers.
14:41SmallR2002: As for debugging it, I built this system and the playbooks behind it, I'll debug it but I am liable to complain
14:42RSpliet: From the sound of your last few claims, you're experienced enough to not need those pointers though.
14:43SmallR2002: Eh, maybe, maybe I'm a monkey with a keyboard, whatever claims I make are responsibility not experience. I can't get X not to crash so experience is kinda irrelevant ;)
14:44SmallR2002: Apologies for the frustration, my logs were in a file and then they weren't any more without any change on my end
14:44SmallR2002: OK, going to test again
14:45SmallR2002: I'll be back
14:58imirkin: sigod: reasons for developing differ. mostly it's around the fun of figuring things out.
15:01imirkin: as for contributing ... driver development isn't the easiest kind of development out there. not as hard as FPGA, but also not like some website.
15:01imirkin: depending on your experience level, it may be a difficult thing to start out in
15:39RSpliet: sigod: not to mention GPU drivers are the hardest kind of drivers ;-)
15:40sigod: RSpliet, i like the look of the EOMA68
15:41sigod: im just looking into the intel management engine
15:42RSpliet: Allwinner A20 isn't what you say a worthy opponent performance-wise
15:44RSpliet: You're better off with a Raspberry Pi or some of the few well-supported Qualcomm-powered boards
15:45sigod: ill just stick with what ive got until it dies
15:50sigod: that's my setup at the mo
17:18SmallR2002: Well, that works in principle. I'll wait and see if it crashes.
17:18SmallR2002: I appear to have a bad DP->HDMI cable which set me back
17:19SmallR2002: Oh, and a little digging found the file it was logging X to, which was specific to GDM and I have no idea why it switched to that.
17:21SmallR2002: Given I figured that out on my own, anyone got any idea where the tools to adjust my monitor stand went?
17:21gnarface: in the ... drawer maybe?
17:22SmallR2002: Yeah, actually you're right, thanks.
17:23SmallR2002: In a zip lock bag like a grown up
17:23gnarface: lucky guess
17:24SmallR2002: Or you've been going through my draws looking for valuables
17:24SmallR2002: Seems more likely that it was a lucky guess though, the dog would probably never let you leave
17:28gnarface: a strange thing to be so ubiquitous, but it's usually that random drawer in the kitchen or the den
17:28gnarface: i don't know why
17:28gnarface: i wonder how far back in society that goes
17:31SmallR2002: Now I just have to test if this works forever
17:31SmallR2002: So far, performance decent and it hasn't crashed
21:05Lyude: are there any generations of nv cards that nouveau supports that didn't use a DCB in their vbios?
21:38Lyude: karolherbst: noticed a dumb bug I introduced in the backlight refactor patch you reviewed for me the other day; would you mind taking another look to see if your R-b still stands (didn't add it to the patch yet) https://patchwork.freedesktop.org/series/48596/
21:43karolherbst: Lyude: which patch changed?
21:44karolherbst: ohh, the last one
21:47karolherbst: oh wow, I totally missed that as well
21:48karolherbst: Lyude: yeah, patch is fine
21:49Lyude: skeggsb: ^ patch 5 is good
21:49Lyude: karolherbst: yeah, it's even more bizarre because i actually tested it before sending it out to make sure the backlight still worked lol
21:50karolherbst: on pre nv50 hardware?
21:50karolherbst: ohh wait
21:50karolherbst: I see
21:50Lyude: karolherbst: well that broke >=nv50. I haven't actually tested nv40
22:01Lyude: karolherbst: going to do one last respin; I just noticed that new nouveau_backlight_init() will print a lot of NV_INFO if there's a gmux present, you OK if I change that to NV_INFO_ONCE? (and likewise; add NV_INFO_ONCE if we don't have that)