00:24 nyef: Okay, wow. I can trash my nvaf fairly easily by running glxgears.
00:26 imirkin: fwiw we had an issue on nvaa/nvac where we weren't configuring something-or-other specific to the stolen-vram configuration
00:27 imirkin: i wouldn't exclude the possibility of nvaf having to have a similar workaround
00:28 imirkin: that'd be commit cb5cdd72027f90a9ed488e4d097b6e0a3911c8c9 . and for a separate nvaa/nvac issue, commit 9219296457e705e4b2d6dd158ed77caab99c193c
00:28 imirkin: thanks to pmoreau who did all the debugging work on them :)
00:30 airlied: i think skeggsb has an nvaf in a macbook in the cupboard
00:30 nyef: To be fair, this is initial setup time on this machine, so I'm not running the latest-and-greatest.
00:33 imirkin: nyef: well, those fixes were fairly long ago
00:33 imirkin: the latter was Oct 2015
00:34 nyef: Are these kernel commits, or some other repository?
00:35 imirkin: ben's repo
00:36 nyef: So... yes, kernel?
00:36 imirkin: no, his out-of-tree-module repo
00:36 nyef: Ah.
00:36 nyef: Okay. Too many moving pieces. (-:
00:39 imirkin: note that feature-wise, nvaa/nvac are similar to nva0, while nvaf is similar to nva3.
00:39 imirkin: pretty sure none of them have dedicated vram though.
00:40 nyef: I know that the nvaf doesn't.
00:40 imirkin: and you can see subdev/fb/mcp89.c uses the mcp77 ram creation logic
00:40 imirkin: (mcp77 = nvaa)
00:40 nyef: So I see.
00:41 imirkin: however it could very easily be that the logic has to do more or different work
00:41 imirkin: i don't know whether it was ever tested specifically against nvaf
00:41 imirkin: (or compared to traces, etc)
00:42 imirkin: .... and the fdo bug# in the code is wrong =/
00:42 nyef: Typical.
00:43 nyef: I have a few more bits to work on in getting this system more-or-less configured before I can dig into testing and debugging.
00:44 nyef: Little things, like setting up a proper boot loader.
00:46 imirkin: aha. dyslexia strikes again
00:46 imirkin: 25701 != 27501
00:46 imirkin: skeggsb: mind fixing the comment in nvkm/subdev/fb/rammcp77.c ?
04:27 orbea: huh, interesting issue. Was getting 20 fps in the RetroArch menu when I normally get 60 when fullscreen, non-fullscreen = too fast. Restarting my xorg session resolved it for now...
04:44 orbea: also replaying apitrace is so fast now I cant even see it! lol
04:50 orbea: i guess I see the problem, its forcing vblank_mode=0 http://dpaste.com/126FZT2
08:37 chillfan: hey, how can I enable the boost code?
08:37 chillfan: from 4.10-rc2
08:46 chillfan: I have pstate 0f enabled, perhaps it's already using boost? http://pastebin.com/pahLkTDc
09:12 chillfan: though I'm apparently missing the 'boost' interface in /sys/kernel/debug/dri/0/
09:23 chillfan: think I found out how brb :p
10:01 karolherbst_work: chillfan: there is no boost interface with the stock 4.10 module anyway
10:02 chillfan: yeah I figured that must have changed, anyway I managed to get it working.. first impression things are smooth, thanks for the work :)
10:02 karolherbst_work: you can set the boost level through a kernel parameter
10:10 drathir: mornin/evenin...
10:10 drathir: guys any reccomendation of cheap nvidia card working nicely with hw x265 decoding on linux?
10:59 chillfan: very impressed with the performance with boost=2 (evga gtx 780 ti SC)
11:01 chillfan: obviously not close to the blob nvidia driver, but it's pretty good for one game, acceptable for two others
11:02 karolherbst_work: with boost=2 your card might get really hot though, but there are mechanisms usually in place to prevent overheating, we just don't do anything inside the driver
11:04 chillfan: keeping my eye on the sensor, I should be okay mostly since I have a third party cooler
11:05 karolherbst_work: I see
11:06 chillfan: is there any test data you need? happy to run some benchmarks etc
11:16 pmoreau: imirkin: Oops… 25701 doesn’t look like the correct bug report indeed…
13:56 imirkin: pmoreau: yeah, 27501 is the one :)
13:56 pmoreau: Yup
13:58 pmoreau: Those issues… So far I found the work in Mesa to be far less frustrating. :-D
14:13 imirkin: yeah, it's a lot more predictable
14:17 pmoreau: And you (usually) don’t need to reboot to test a change :-)
14:26 imirkin: unless you mess up real bad
16:38 mlankhorst: first time I had the blob die on me http://paste.debian.net/906336/
16:39 imirkin_: hah! SPH error.
16:39 mlankhorst: yep
16:39 karolherbst_work: mlankhorst: amateur :p
16:40 mlankhorst: well it's interesting it's just as dead as it would be on nouveau
16:50 mlankhorst: thoroughly dead, had to reboot
16:50 karolherbst_work: never was able to recover from a "crashed" nvidia module
16:52 mlankhorst: even reboot -f didn't work, had to use sysrq :>
20:26 nyef: When I cat /sys/class/drm/card0/card0-HDMI-A-1/modes, is there any significance to most of the modes apparently appearing more than once?
20:26 imirkin_: they're different, just not in a way that's printed
20:27 nyef: Okay, is there an easy way to tell *how* they're different?
20:27 imirkin_: run 'xrandr' to see the real differences
20:27 imirkin_: or xrandr --verbose
20:27 mwk: ahh, ctxprogs, how much I missed you...
20:27 imirkin_: or, if you want to avoid X, you can use modetest i believe
20:27 nyef: Ah, refresh rate.
20:27 nyef: Thank you.
20:28 imirkin_: can also be dot clock even though the vrefresh is the same
20:28 imirkin_: [different porch size, etc]
20:59 nyef: On the upside(?), glxgears doesn't seem to trash my nvaf now that I'm running an updated kernel.
21:02 imirkin_: i'm sure you can still figure out a way to trash it
21:03 nyef: Probably, yes. But not likely to be worth the effort at this point.
21:03 nyef: Well, at least not worth the effort while doing normal stuff.
21:04 nyef:looks at nvkm/engine/disp/hdmigt215.c.
21:04 imirkin_: why?
21:04 nyef: 3D InfoFrame.
21:04 imirkin_: ah. i think right now we don't really generate proper infoframes
21:05 nyef: Imagine that.
21:05 imirkin_: nothing cares
21:05 imirkin_: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/engine/disp/hdmigt215.c#L65
21:05 imirkin_: it's pretty fixed.
21:05 imirkin_: we used to have more code that tried to do more things
21:06 imirkin_: nyef: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nouveau_hdmi.c?h=v3.7#n149
21:07 nyef: Hmm! Thank you.
21:07 imirkin_: they're all hardcoded to 0, but from my understanding, generating correct values was never of any help for anything
21:07 imirkin_: so it was easier to just leave it alone
21:07 imirkin_: however by now, there are common helper functions to generate this data
21:07 imirkin_: so we could look into reusing those
21:14 nyef: ... I don't suppose the blob driver can easily be convinced to generate HDMI 3D, can it?
22:28 nyef: Hrm. Can I usefully hit these registers from user space?
22:28 nyef: Guess I'd better work out what I want to put in them, first.
22:28 imirkin_: sure, envytools's nvapeek/poke