00:24 nyef: HDMI display regression?
01:12 mwk: *sigh* modeling 8kB more state in hwtest didn't exactly help the performance
01:58 mangix: so is it possible to mod the VBIOS of a 980 to raise the clocks?
02:15 imirkin: mangix: it'd be easier to just use nouveau to raise the clocks. the issue is we can't control the fan if we do that.
02:16 imirkin: nyef: look at ben's tree... the like HEAD^^ commit
02:26 nyef: Ah, okay. I remember this now.
02:33 nyef: Hunh. -rc4 is out.
02:38 mangix: imirkin: but I can :)
02:38 mangix: fn + 1 on this laptop maxes the fans
02:38 mwk: huh, that's a useful key
02:46 mwk: yay
02:46 mwk: clear_zeta does write to zcull memory after all :)
02:57 mangix: mwk: modded BIOS :)
03:08 Celelibi: How do I know which driver xorg is using right now?
03:09 Celelibi: Is this correct? grep drivers /proc/$(pidof Xorg)/maps
03:09 Celelibi: Is modsetting a valid video driver?
03:12 kuzetsa: http://i.imgur.com/pWNcXwj.png <<< GFXBench GL thinks gentoo + nouveau driver is a "Virtualized or Custom OS" for some stupid reason (really, a pretty mundane desktop environment with pretty middle-of-the-road settings... like I'm just using a standard "Desktop" profile for my gentoo install - nothing fancy)
03:13 kuzetsa: Celelibi - yes, modesetting is a valid driver, and the acceleration feature is provided by nouveau
03:14 Celelibi: Hm. Nouveau isn't loaded.
03:14 kuzetsa: that makes a difference then
03:15 kuzetsa: kuzetsa@soyokaze ~ $ glxinfo | grep nou
03:15 kuzetsa: Vendor: nouveau (0x10de)
03:15 kuzetsa: OpenGL vendor string: nouveau
03:15 kuzetsa: ^ for mine, it's deffinitely loaded
03:16 Celelibi: Mine just say extension "GLX" missing.
03:17 Celelibi: Ah yes, but nvidia blacklists nouveau.
03:17 kuzetsa: err
03:17 kuzetsa: you shouldn't have nvidia's driver installed at the same time
03:17 Celelibi: Why not? I want to choose what I use.
03:18 imirkin: mangix: ah, in that case, i've been encouraging karol to write some patches to enable that sort of usecase
03:18 kuzetsa: I'm confused
03:19 kuzetsa: I didn't think it was possible for 2 different drivers to be used on the same physical GPU at the same time
03:19 kuzetsa: how does that even work then
03:19 imirkin: mangix: it should be possible for nouveau to support reclocking on those, but ... presently not supported. however modifying the vbios to boot to higher clocks is prohibitively difficult. all the "applications" that help you do it assume you have a driver capable of doing the reclocking, they don't modify the boot sequence.
03:20 imirkin: kuzetsa: it's not possible to use at the same time. it is, however, possible to switch back and forth. (including unloading/reloading the relevant modules.)
03:20 kuzetsa: fair enough
03:20 kuzetsa: I wonder how udev decides which one to load if they're both present at the same time O_O
03:21 kuzetsa: like - without manual intervention
03:39 mwk: whee
03:39 mwk: zcull structure is starting to make some sense
03:40 mwk: tiles made of tiles made of tiles...
03:40 mangix: imirkin: what do you mean those. laptop GPUs?
06:57 gnurou: imirkin: thanks - I will fix that. sorry about it, I should have looked more closely at the Nouveau part of the code (only cared about making the patch work again on Mesa ToT)
09:03 LeWhoo: hi. I am running Fedora 25 on my optimus laptop with nvidia gtx 1060 and I get unrecognised chipset message during boot. Is there anything I can do to run this graphics card on linux?
10:17 rah: [61454.080882] nouveau 0000:01:00.0: fifo: write fault at 0000260000 engine 00 [GR] client 0f [GPC0/PROP_0] reason 02 [PTE] on channel 2 [007fb31000 Xorg[3141]]
10:17 rah: [61454.080886] nouveau 0000:01:00.0: fifo: gr engine fault on channel 2, recovering...
10:17 rah: I get this from the kernel
10:17 rah: and X is frozen
10:17 rah: when I attached to X with gdb, I get a meaningless backtrace: https://paste.debian.net/908946/
10:19 rah: I put some printk's near those error messages and it seems to be continuing without issues
10:20 rah: can anyone make my life easier and tell me where in userspace I should start to put printf's to pick out the problems around this freeze?
10:21 rah: that is, does anyone know where the code that caused the fault, presumably "007fb31000 Xorg[3141]", is likely to be?
10:46 pmoreau: RSpliet: Yeah, yeah… I still have to look into that RA issue when doing loops with a body having more than 1 BB.
11:39 Celelibi: Hm, do you think my bug with nouveau might be related to this? https://wiki.archlinux.org/index.php/NVIDIA_Optimus#Lockup_issue_.28lspci_hangs.29
11:42 Celelibi: Most of the decription matches with my laptop. It's just that it happens with nouveau and not nvidia (not tried nvidia yet).
13:00 rah: here https://nouveau.freedesktop.org/wiki/KernelModuleParameters/ it says:
13:00 rah: Example: nouveau.debug="PTHERM=debug,PTIMER=debug"
13:00 rah: should there really be quotes around the value there?
13:15 RSpliet: pmoreau: :-D
13:16 RSpliet: rah: the quotes are optional, but improve readability imho
14:01 lucas-arg: guys im having problems with gtx950m using ubuntu or fedora freezes the boot process
14:01 lucas-arg: using bumblebee and nouveau druiver
14:01 lucas-arg: only way i can boot is adding nouveau.modeset=0 in kernel parameters
14:04 imirkin: right, yeah. definitely don't stick around for a response...
14:04 imirkin: o well.
14:04 imirkin: rah: note that the names of all those things changed in kernel 4.3 :(
14:05 imirkin: rah: e.g. PTHERM is now therm. etc.
14:05 rah: imirkin: are the new identifiers documented anywhere?
14:05 imirkin: nope.
14:05 rah: imirkin: not even in the commit that modified them?
14:05 imirkin: nope.
14:07 rah: http://settrans.net/~rah/misc/facepalm.jpg
14:08 rah: does anybody here happen to know what PGRAPH changed to?
14:08 rah: would it be gr by any chance?
14:08 imirkin: gr
14:10 rah: thank you
14:12 imirkin: rah: note that your issue has nothing to do with Xorg, most likely. i've seen the process id being misleadingly reported a lot lately
14:12 imirkin: LeWhoo: GP106 should be recognized in kernel 4.10-rcN. however that won't get you acceleration support.
14:13 LeWhoo: imirkin: I want HDMI to work only. It seems it is connected to nvidia on my laptop
14:14 imirkin: LeWhoo: ah, they started doing that again? unfortunate =/
14:15 LeWhoo: I tried 4.10-rc3 from rawhide repository and indeed it changed "not recognised" message to some other error messages, maybe not so severe. But anyway, this kernel is so unstable that I have trouble running X
14:15 LeWhoo: I am not sure when kernels 4.10 will start to hit the main repositories
14:15 imirkin: you should get an error messaging saying some channel couldn't be created or something like that
14:15 LeWhoo: yes, it was something like that
14:16 imirkin: however another user had trouble getting output offloading working with a GP10x board, i think
14:16 rah: imirkin: depends on (1) which issue you're referring to, the write fault or the failure to recover, and (2) depends on whether you mean the Xorg code as opposed to the nouveau video driver code, or the Xorg process, which presumably loads the nouveau video driver?
14:16 imirkin: the write fault. the failure to recover is fully expected. nouveau recovery is roughly non-existent.
14:17 rah: orly?
14:17 imirkin: it recovers from some simple things, but most things take it down hard
14:17 rah: :-/
14:18 LeWhoo: imirkin: it is a stopper for using a linux on my new notebook now, since nvidia rivers also do not seem to work... Lot's of troubles with gtx 1060 apparently
14:18 imirkin: LeWhoo: yeah, i'd definitely recommend against any kind of optimus-style arrangement if you want things to work well
14:18 rah: RSpliet: you know I'm looking at option.c in nouveau and params.c in the kernel and neither look like they deal with quotes
14:19 imirkin: rah: the quotes definitely work.
14:19 rah: I stand corrected
14:19 imirkin: rah: the kernel option parser is what deals with them
14:19 imirkin: not the option parsing in nouveau
14:19 rah:plainly has not looked closely enough into params.c in the kernel
14:20 LeWhoo: imirkin: it was working very well on my previous laptop... well, I guess I was just lucky
14:21 rah: /* Don't include quotes in value. */
14:21 rah: ah
14:24 rah: that there function call which plainly had nothing to do with what I was looking for, was what I was looking for
14:24 RSpliet: rah: that sounds nice and ambiguous, they probably mean "don't include them in driver-expected values, because params.c strips them out/uses them as delimeters
14:26 inglor: imirkin: some further update on the nouveau core dump. It seems after a couple of starts the game now run. I have no clue on what changed. It's still low on FPS but that's something else entirly (i blame unity).
14:27 rah: RSpliet: yeah that's not clear sorry; it's a comment in the parsing code, meaning not to include possible quotes in the first and last characters of the value being returned from the parser
14:28 imirkin: inglor: very weird. for maor fps, try reclocking if your gpu supports it.
15:02 RSpliet: hakzsam: rcp has a latency of 13? Didn't expect it to be so expensive...!
15:02 RSpliet: hakzsam_: ^
15:03 imirkin: it's a SFU op...
15:05 RSpliet: oh, and it appears to be an iterative method
15:06 mwk: it's not, actually
15:06 mwk: https://github.com/envytools/envytools/blob/master/nvhw/sfu.c#L75
15:07 mwk: many flops died to bring us this information.
15:08 RSpliet: mwk: sfu_square() looks like the kind of thing that can trade die area for cycles
15:09 mwk: sfu_square is a horrible hack on a multiplier
15:10 RSpliet: (thanks for the pointer!)
15:10 mwk: you have no idea how many flops died for sfu_square...
15:11 hakzsam_: RSpliet: at least 13, and rcp needs a barrier
15:11 hakzsam_: like all MUFU ops
16:20 inglor: imirkin: it should automatically reclock right ?
16:20 inglor: gtx 690
16:20 imirkin: inglor: no - manually.
16:39 inglor: imirkin: what's the echo value for /sys/kernel/debug/dri/0/pstate
16:39 imirkin: cat it first
16:39 imirkin: that will give you the list of options, as well as the current value on the AC: line
16:39 imirkin: s/current value/current state/
16:39 imirkin: inglor: if you want successful reclocking, you really want kernel 4.10-rcN though
16:40 inglor: give!
16:40 inglor: 4.9.x is kinda unstable
16:40 inglor: for irelevant to nouveau issues
16:40 inglor: so i'm hoping 4.10.x is better
16:41 imirkin: (the specific options depend on what's in your vbios... although for kepler usually the highest pstate is 0f)
16:41 inglor: something with ACPI
16:41 inglor: 07: core 324 MHz memory 648 MHz AC DC *
16:41 inglor: 0a: core 324-862 MHz memory 1620 MHz
16:41 inglor: 0d: core 540-1202 MHz memory 6008 MHz
16:41 inglor: 0f: core 540-1202 MHz memory 6008 MHz
16:41 inglor: AC: core 324 MHz memory 648 MHz
16:41 inglor: correct! :)
16:42 imirkin: and the diff between 0d and 0f is probably in something not printed there
16:42 inglor: my g/f would probably whine a bit for the noise but heh what can you do :D
16:42 inglor: I though that was automatic :/
16:42 imirkin: it's not.
16:42 imirkin: every reclock brings a chance it'll hang your box
16:42 imirkin: if displays are being driven
16:43 inglor: Then how does nvidia does it? is it the same risk ?
16:44 imirkin: no, they have better docs than we do
16:45 imirkin: it's something to do with the linebuffer not being flushed or ... something
16:45 imirkin: we don't really know
16:46 nyef: Or having to be timed such that most of the hardware is idle, and the displays just entering vblank, so that everything has time to stabilize before benig used, or something like that?
16:47 imirkin: we already do that.
16:47 nyef: Ah, okay.
16:48 imirkin: the reclock script starts with "wait for next vblank" :)
16:48 nyef: Guess it was too obvious a possibility. (-:
16:48 imirkin: this is some issue with the crtc still trying to access vram ... or something.
16:48 imirkin: anyways, i haven't heard a ton of complaints, esp with manual
16:49 imirkin: but moving to automatic reclocking means you have to take reliability to the next level
16:51 nyef: Yeah, that I understand. If it doesn't work on manual, you quickly learn not to do it. If it doesn't work on automatic, you have more of a problem.
16:53 imirkin: well, if it fails 1/1000 times on manual - it won't come up that often
16:53 imirkin: automatic tends to reclock a lot more often
16:53 imirkin: and at much more inopportune moments :)
17:57 haagch: yup, definitely not using my tegra k1 chromebook as a vr machine :) https://i.imgur.com/3B7rZgy.png
17:58 haagch: but it's impressive that it can handle a 2160x1200@90Hz display. my laptop with ivy bridge can not do that...
18:01 pmoreau: Rohh, 21 fps is almost the same as 90 fps though! :-D
18:05 imirkin: why is there so much color separation?
18:05 imirkin: is that normal?
18:06 orbea: hmm, seems with 4.10 after resuming from pm-suspend I have no vsync. http://dpaste.com/1BQ5TQ0
18:06 imirkin: skeggsb: --^
18:06 imirkin: skeggsb: perhaps that's why you couldn't repro? didn't think to suspend/resume first? :)
18:07 orbea: i take it this has happened to others?
18:07 haagch: it's normal. the HMDs have lenses that refract light of different colors differently
18:07 imirkin: haagch: ah, fancy
18:07 imirkin: orbea: yeah, it's been reported a handful of times, but so far, ENOREPRO
18:08 haagch: it's also not normal because it's not the right distortion correction for my OSVR 2HDK anyway
18:08 imirkin: haagch: makes sense, it's hard to make lenses like that without abberation
18:08 imirkin: impressive that they mapped the abberrations out and compensate for them in software.
18:09 haagch: apparently reversing the lense effects is a relatively cheap operation on the gpu
18:10 imirkin: yeah, it should be a very regular effect, just separate the colors
18:11 haagch: and barrel distortion
18:34 glennk: also a practical use case for multiple viewport rendering
18:34 imirkin: each color gets its own viewport?
18:35 glennk: well, more with eye tracking you can render the fovea area at higher resolution than the edges
18:36 imirkin: how do multiple viewports help with that? or you mean the multiview stuff?
18:39 glennk: NV_viewport_array2 and similar
18:39 imirkin: ah yeah
19:33 ElectroJunkie: What is the reason why, for DRM build, kernel 2.6 is used specifically? or maybe it does not matter for Nouveau DRM development?
19:35 imirkin: not sure what you're talking about...
19:35 imirkin: nouveau is developed on top of the latest kernel
19:36 ElectroJunkie: imirkin: there is a good chance that I do not know what I am talking about XD. I am based on the git tree name 'git://anongit.freedesktop.org/nouveau/linux-2.6'
19:37 imirkin: ah. (a) that's just the name of a tree, (b) that's no longer the most up-to-date place
19:37 ElectroJunkie: I am struggling to understand the code structure and graphics stack concepts right atm.
19:37 imirkin: start with a concrete question, move on from there
19:38 ElectroJunkie: thank you for the tip!
19:38 ElectroJunkie: Regarding (b), what would be the most up-to-date place?
19:39 imirkin: https://github.com/skeggsb/nouveau is a out-of-tree module which you can build against some linux trees. there's also a separate linux repo in there which has basically the same thing, but inside a regular linux kernel tree.
19:41 ElectroJunkie: Perfect. Thank you for clarifying this! :)
21:43 RSpliet: imirkin: the linebuffer stuff is merely an aesthetic issue on multi-monitor set-ups. Can't wait for more than one display to go into VBLANK, so unless we correctly configure the linebuffer to contain about 0.15ms worth of pixels per display, all but the one we waited for will flicker
21:43 imirkin: RSpliet: oh, so it won't hang if the second monitor is trying to access vram while we reclock it?
21:44 RSpliet: imirkin: I don't think that's the source of our problems, as there's some form of underflow detection-and-handling logic in the display engines
21:45 RSpliet: that doesn't mean it cannot hang, but the source of the hang is unknown (at least to me)
21:45 imirkin: RSpliet: huh ok