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