Nouveau - Jun 2016 - Should I expect nouveau on 4.6 to work on a GM206?

On Sun, Jun 26, 2016 at 1:49 PM, Andy Lutomirski <luto at amacapital.net>
wrote:
> On Sun, May 29, 2016 at 12:27 PM, Andy Lutomirski <luto at
kernel.org> wrote:
>> On Sun, May 29, 2016 at 12:22 PM, Ilia Mirkin <imirkin at
alum.mit.edu> wrote:
>>> On Sun, May 29, 2016 at 3:07 PM, Andy Lutomirski <luto at
kernel.org> wrote:
>>>> On Sat, May 28, 2016 at 5:48 PM, Ilia Mirkin <imirkin at
alum.mit.edu> 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.
>
> 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.

  -ilia

On Sun, Jun 26, 2016 at 10:59 AM, Ilia Mirkin <imirkin at alum.mit.edu>
wrote:
> On Sun, Jun 26, 2016 at 1:49 PM, Andy Lutomirski <luto at
amacapital.net> wrote:
>> On Sun, May 29, 2016 at 12:27 PM, Andy Lutomirski <luto at
kernel.org> wrote:
>>> On Sun, May 29, 2016 at 12:22 PM, Ilia Mirkin <imirkin at
alum.mit.edu> wrote:
>>>> On Sun, May 29, 2016 at 3:07 PM, Andy Lutomirski <luto at
kernel.org> wrote:
>>>>> On Sat, May 28, 2016 at 5:48 PM, Ilia Mirkin <imirkin at
alum.mit.edu> 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

On Sun, Jun 26, 2016 at 2:04 PM, Andy Lutomirski <luto at amacapital.net>
wrote:
> Eeek!  My desire to hack on EXA is pretty low.  If there was some
Well, the EXA hacking was all done a long time ago. You'd just need to
add support for sticking 4 vertices into a buffer. (Maxwell killed
direct vertex submit, which was incredibly convenient for the DDX.)
> straightforward way I could try to figure out why GLAMOR was so slow,
> maybe I could fiddle with that a bit.
Upgrade mesa & pray. I think that X11 can end up being pretty
glReadPixels-heavy, which in a UMA system is ~free, but much more
expensive when the FB is in VRAM. Recently some changes were committed
to cache the entire texture in a staging texture if someone does a lot
of readpixels on it. Could help. Or could be totally unrelated.

You could do an apitrace of the X server
(github.com/apitrace/apitrace) and then analyze what all it's doing.
>
> 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.
Different workloads, I suppose. I had to use GLAMOR on a SKL while the
regular ddx was still lacking support for it, and my favorite
screensaver was unbearably slow on it (xlock -mode wator, in case
you're curious). [And regular usage was also not great, but not to the
point of frustration.] It runs plenty fast with the SNA backend
though.

  -ilia