On Sun, Jun 26, 2016 at 10:59 AM, Ilia Mirkin <imirkin@xxxxxxxxxxxx> wrote: > On Sun, Jun 26, 2016 at 1:49 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> On Sun, May 29, 2016 at 12:27 PM, Andy Lutomirski <luto@xxxxxxxxxx> wrote: >>> On Sun, May 29, 2016 at 12:22 PM, Ilia Mirkin <imirkin@xxxxxxxxxxxx> wrote: >>>> On Sun, May 29, 2016 at 3:07 PM, Andy Lutomirski <luto@xxxxxxxxxx> wrote: >>>>> On Sat, May 28, 2016 at 5:48 PM, Ilia Mirkin <imirkin@xxxxxxxxxxxx> wrote: >>>>>> Do you have mesa 11.2 or later? GM20x support was only added in mesa 11.2. >>>>>> >>>>> >>>>> I just upgraded to 11.2. I'm getting errors like this in the log: >>>>> >>>>> [ 5383.723240] nouveau 0000:09:00.0: fifo: read fault at 0000011000 >>>>> engine 07 [PBDMA0] client 06 [HOST] reason 00 [PDE] on channel -1 >>>>> [007f9ed000 unknown] >>>>> [ 5398.722676] nouveau 0000:09:00.0: systemd-logind[30778]: failed to >>>>> idle channel 2 [systemd-logind[30778]] >>>>> [ 5413.722853] nouveau 0000:09:00.0: systemd-logind[30778]: failed to >>>>> idle channel 2 [systemd-logind[30778]] >>>>> >>>>> and the display output in general is unreliable enough that I'm having >>>>> trouble telling whether the performance is remotely reasonable. >>>> >>>> If you're having trouble telling, that means it's not :) The error you >>>> pasted is quite odd. Was there anything in the log before those >>>> messages? If there's no channel associated, that means that it's the >>>> background copying between vram and sysmem? Not sure. >>> >>> Don't get too excited yet. In the process of upgrading mesa, I >>> managed to boot 4.5 without noticing. I'll post back later today with >>> actual valid test results. >>> >> >> I replaced the monitor (turns out that my monitor had a known DP >> problem), and now the screen lights up reliably. I still get > > Great to hear! > >> occasional log lines like this: >> >> [Jun26 09:25] nouveau 0000:09:00.0: fifo: FB_FLUSH_TIMEOUT >> [Jun26 09:30] nouveau 0000:09:00.0: fifo: FB_FLUSH_TIMEOUT >> [Jun26 09:32] nouveau 0000:09:00.0: fifo: CHSW_ERROR 00000004 >> [ +0.000162] nouveau 0000:09:00.0: fifo: CHSW_ERROR 00000005 > > These don't sound good at all! > >> [Jun26 09:46] nouveau 0000:09:00.0: disp: outp 04:0006:0f44: link >> training failed >> [ +0.107894] nouveau 0000:09:00.0: disp: outp 04:0006:0f44: link >> training failed > > These are surprising if your monitor is working. Usually it means > "couldn't establish link with the monitor". Perhaps something forces > it to retry and it eventually succeeds. Given the timing, I'm guessing that it tries a couple of times and eventually works. Given that the monitor is a newer, "fixed" revision of a known-seriously-broken Dell monitor, it wouldn't shock me if what's actually happening is that the monitor uses buggy DP hardware and the "fixed" firmware A03 actually works by forcing several retries when link training fails (as opposed to what A00 - A02 did, which seemed to involve failing a few times and then crashing, sometimes hard enough that even the monitor power button stopped working). > >> >> but they aren't causing an obvious problem. >> >>>> >>>> Note that with maxwell we have yet to add EXA support to >>>> xf86-video-nouveau, so you're ending up with GLAMOR (and Ben and I >>>> disagree on whether EXA support should be added in the first place). >>>> There was also an issue that glamor was hitting with nouveau which >>>> appears to have dissipated, either due to a change in nouveau or a >>>> change in glamor. So you might consider upgrading to Xorg 1.18.3 (as >>>> glamor is part of X). >> >> I do have a serious performance issue, though: when I scroll in >> Firefox (default configuration), the whole system drops to ~1fps or >> less and, if I scroll enough (even putting the mouse over a simple >> page like start.fedoraproject.org and flicking the wheel up and down a >> few times), the entire desktop will become unusable for several >> seconds. I seem to have this problem under X and under Wayland. >> >> For better or for worse, forcing Firefox's layers acceleration on >> fixes the problem and scrolling is fast. >> >> I have no idea whether this is an X problem, a gnome-shell problem, a >> mesa problem, a kernel problem, or something else. > > I believe the issue is with GLAMOR, but I'm not sure - in my > experience, GLAMOR is slow as molasses for actual X11 ops that aren't > "take this composited image and stick it on the screen", and the fact > that you are on the lowest perf level of your GPU isn't helping your > cause. Turning on acceleration in firefox probably makes it use more > optimized GL paths than having some X11 -> GL translation layer. > > If you're interested, I've a 95% (percentage made up) completed EXA > backend for maxwell, but I don't have the hw, or, to be frank, the > interest in completing it (as a result of NVIDIA's creation of these > locked down, actively anti-open source GPUs). However you're welcome > to hack on it if you like - > https://github.com/imirkin/xf86-video-nouveau/commit/abf0933a236b6069f42f86ad5b0bf5bbab28e0d6 > - if you ask in #nouveau on irc.freenode.net, would be happy to talk > about what all needs finishing. Eeek! My desire to hack on EXA is pretty low. If there was some straightforward way I could try to figure out why GLAMOR was so slow, maybe I could fiddle with that a bit. FWIW, my i915-based laptop uses the modesetting driver and GLAMOR as well, and it's plenty fast, so I don't think the problem is that GLAMOR is inherently terrible at legacy X11 operations. --Andy _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
