Nouveau - May 2014 - [Bug 79266] New: (two) GT 430 / GF108 sluggish, unstable performance and blue tint with vdpau

https://bugs.freedesktop.org/show_bug.cgi?id=79266

          Priority: medium
            Bug ID: 79266
          Assignee: nouveau at lists.freedesktop.org
           Summary: (two) GT 430 / GF108 sluggish, unstable performance
                    and blue tint with vdpau
        QA Contact: xorg-team at lists.x.org
          Severity: major
    Classification: Unclassified
                OS: Linux (All)
          Reporter: afasdfsdfaa at master.ms
          Hardware: x86-64 (AMD64)
            Status: NEW
           Version: unspecified
         Component: Driver/nouveau
           Product: xorg

Created attachment 99879
  --> https://bugs.freedesktop.org/attachment.cgi?id=99879&action=edit
dmesg

1. All the problems exist in exactly the same form since I had this PC, that is
3 years now - and it runs well (mostly) with the proprietary driver (so I
didn't bother)
2. None of the common fixes and workarounds (without recompiling) work and they
don't seem to target the problem at all
3. Affects all sorts of versions since 3 years, seems to be an issue with the
particular cards rather

For vdpau, the issue looks almost identical to:

https://bbs.archlinux.org/viewtopic.php?id=137877&p=1 (If you watch the
Avatar
movie trailer on youtube, people are blue Na'vi have skin color)

... except that nothing of the suggested options works, that is without turning
vdpau off. If vdpau is used, flash plugin might crash often and randomly.
Mplayer exhibits arbitrary behavior, such that the video only plays and plays
as fast as you wiggle/move the mouse. The white OSD in mplayer is black. 

If X is killed, the computer sometimes freezes entirely. Sometimes arbitrary
crashes, even if vdpau was never used since X was started. Suspend to memory
won't wake up. 3 years ago I removed vdpau entirely and still applications
would crash more frequently and the system was more unstable.

If compared 1:1 to the nvidia driver, it becomes immediately obvious that the
performance is slower, applications open slower by 100-500ms (sometimes
seconds), you can literally see little squares updating the screen bit by bit
if xorg windows are closed/switched instantly. Conversely, CPU consumption is
low all the time and rest of the PC is decent enough (like 32GB RAM and what
not). 

I tried all the combinations of the documented (under "man nouveau")
xorg
options, including vblank sync, multihead or single screen or no xorg.conf and
whatever you can but the tearing during video playback is just enormous with
the nouveau driver (It was already annoying with the nvidia driver though but
with nouveau it is *massive*). CPU load is still 5% or something...

I just tried wine and it did not run either, although glxgears did. Not sure
why that is.

It is some issue with this particular card, possibly related to the motherboard
or some hardware constellation, but I guess it is just the card. Nothing of the
sorts exists with the proprietary driver (suspend works, colors ok, vdpau ok,
GL ok, etc. though there also is some tearing in videos).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140526/db85bafc/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=79266

Ilia Mirkin <imirkin at alum.mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal
            Summary|(two) GT 430 / GF108        |[NVC1] GT 430 / GF108
                   |sluggish, unstable          |sluggish, unstable
                   |performance and blue tint   |performance and blue tint
                   |with vdpau                  |with vdpau

--- Comment #1 from Ilia Mirkin <imirkin at alum.mit.edu> ---
This is a complete ramble... lots of various issues. Pick one and we can go
from there. Otherwise it becomes a placeholder bug for "there are _still_
things that don't work quite right for me". A few observations:

(a) Reclocking isn't supported on your card. Compared to blob driver, your
card
is running at 1/2 the memory clock speed (and 4/7ths of the shader speed, but
the lower memory speed can really kill things). Opening bugs about this will
just get them insta-closed. It's not that we don't care, but we know
that
reclocking isn't supported, and having bugs open about it will do nothing
but
clog up the bug tool

(b) You don't have the firmware for video hardware acceleration, so
you're only
using the presentation layer of vdpau. (I divined this from the "unable to
load
firmware data" messages from the BSP engine.) No clue why the colors are
messed
up though, that's quite odd. Perhaps something flipped the order of the UV
planes. But this is the first I'm hearing about this, I suspect it would
have
come up before if it was that simple...

(c) Tearing is an issue with the nouveau driver. Unresolved, and also known.
Setting GLXVblank can help.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140526/a87380aa/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=79266

--- Comment #2 from C0NPAQ <afasdfsdfaa at master.ms> ---
Yes, this is a ramble but it is so by necessity. The random crashes, random
mplayer behavior in combination with vdpau, suspend issues, etc. it all speaks
for a single cause issue. I know very similar behavior (crashes, suspend
issues) from the proprietary drivers with other cards (GT8400) where the
nouveau driver works and the proprietary driver causes the problems. Those
issues are simply (in that case) not implementation/firmware related and I
doubt they are here, that's why it is important to mention all of this
'ramble'.

(a), no one cares if the card is running 1/2 memory speed because it still is
way fast enough and it has nothing to do with it or to contribute to the issue
afaik.

(b) sounds like you equally are just guessing around but have no clue what is
going on

(c) if you read the documentation you knew that GLXVblank is documented, hence
I tried it, hence it did nothing as mentioned



I realize this bug is difficult, but if you got a GT430 you basically have to
use nvidia and can't use nouveau. Google a bit, you will find *all* of the
desribed issues scattered around the net.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140526/ef4b79ee/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=79266

--- Comment #3 from Ilia Mirkin <imirkin at alum.mit.edu> ---
If you can't identify an issue to work out, I will close this bug as
invalid,
as it will be completely non-actionable. If you're looking to help get stuff
fixed, I'd recommend taking a less hostile approach.

It very well may be that all the problems stem from one single cause. However
the way to work it out is to drill down into ONE of the things and understand
it well. If resolving it fixes other issues, so much the merrier.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140526/50955f0f/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=79266

--- Comment #4 from C0NPAQ <afasdfsdfaa at master.ms> ---
Sorry, but I am just annoyed by your attitude. It is a bug that affects
multiple things at once that are inconclusive each by themselves and you argue
that you have to discard those kind of bugs because it conflicts with your
problem solving approach... To put bluntly, it sounds like you are trying to
grab excuses with your points a, b ,c and on top of all finish by telling me
(in other words) "If I want help I should be less cocky about my
problems."
....

Someone just has to look at this in close detail, possibly testing with the
hardware. Maybe that is not feasible to you currently, but it doesn't make
the
bug report invalid and it doesn't change that it is broken. If you can't
fix
it, you leave it, at least that's how I know bug reporting.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140526/6f2de5df/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=79266

--- Comment #5 from C0NPAQ <afasdfsdfaa at master.ms> ---
If all you wanted to say is "Sorry: won't solve - ever - too
complicated" why
don't you do so? 

I guess that is where my bewilderment stems from.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140526/902123a5/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=79266

--- Comment #6 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to comment #4)
> Sorry, but I am just annoyed by your attitude. It is a bug that affects
> multiple things at once that are inconclusive each by themselves and you
> argue that you have to discard those kind of bugs because it conflicts with
> your problem solving approach... To put bluntly, it sounds like you are
> trying to grab excuses with your points a, b ,c and on top of all finish by
> telling me (in other words) "If I want help I should be less cocky
about my
> problems." ....
I was merely making observations that I thought might help you out. They
didn't. There are two separate things... your problems, and your attitude.
Your
problems are fine. I was suggesting taking a more collaborative and less
confrontational attitude. My goal here is to either get this bug into a state
where someone can do something (aka "actionable"), or to close it as
invalid
because such a state is not achievable.
> 
> Someone just has to look at this in close detail, possibly testing with the
> hardware. Maybe that is not feasible to you currently, but it doesn't
make
> the bug report invalid and it doesn't change that it is broken. If you
can't
> fix it, you leave it, at least that's how I know bug reporting.
This approach, while initially friendlier to the bug submitter, leads to
enormous bug lists that nobody ever looks at, which in turn may as well not
exist. In the end, I believe that this does a disservice to bug submitters.
I'm
trying to keep all of the open bugs actionable so that an interested party can
look and see what the things to do are. If you don't like my problem solving
approach, I would love nothing more than to hear a more effective one.

The way that resolving these issues tends to work is largely collaborative. You
have to describe the issues clearly, and perhaps do some tracing. If you're
not
willing to help along, this issue becomes non-actionable (and thus invalid).

So.... let's start with the basics. Let's say I have a GT 430. What do I
need
to do in order to reproduce one of the issues.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140526/25b08bcc/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=79266

--- Comment #7 from C0NPAQ <afasdfsdfaa at master.ms> ---
I am sorry if I reacted harshly. I am not aware of your organization structure. 

However, I would intuitively expect that you would leave the bug open, and
eventually more people will find it and report the same problem. Thereby it
will become clear if all GT430 are affected or if it is due to a hardware
combination. At some point a developer would have to have a closer look at the
issue and reproduce it with the same graphics card chipset at least.

I honestly have no clue but I guess it is some memory access violation, buffer
overflow issue within the card that causes the weird behavior, like 1 byte
offset in some register then the colors get weird and the video only plays if
the mouse is moved around and such. Possibly because the driver assumes the
wrong chipset. 

Someone who knows this stuff just has to look at it, test it, that's all you
can really do.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140526/a41d0f41/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=79266

--- Comment #8 from Emil Velikov <emil.l.velikov at gmail.com> ---
C0NPAQ

I can see some frustration/anxiety in your replies. Please step back for a
second and check with what Ilia is saying. Thank you.

With that said, here is my interpretation + some tips:

 * blue tint - irrc flash has an issue with blue tint with vdpau for which the
wrapper library added a workaround (enable_flash_uv_swap). Check if the
detection code [1] is not miss-behaving on your system/setup.

 * flashplayer crashes randomly regardless of the OS + driver combo on my
system :'(

 * You're missing the firmware required for vdpau to work properly with
nouveau. Install the nouveau-fw package from AUR or follow the instructions [2]
to do it manually.

 * Use only the recommended options when using mplayer + vdpau. If that does
not work provide a link to a sample which people can test against.

 * GL/VDAPU may be slow. As mentioned there is no reclocking at the moment,
making some things (tearing) even more annoying.

 * "I just tried wine and it did not run either" - now that is a bit
too vague.
I would give some specific examples - running wine v.XXX, under distro YYY. I
get XXX output in console etc...
>From the above you can see three different topics (vdpau, gl and
performance),
and possibly even more bugs.

_Please_ keep them separate as things are easy to find/work on when you do not
have one massive blob that covers everything (divide and concur).

Don't take this the wrong way, but if you insist that these issues are due
to a
single bug, then you are either delusional or far more knowledgeable in GL,
VDPAU and nouveau intrinsics than nearly everyone that has ever worked on
nouveau.


[1]
http://cgit.freedesktop.org/~aplattner/libvdpau/tree/src/vdpau_wrapper.c#n300
[2] http://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware
[3] http://nouveau.freedesktop.org/wiki/VideoAcceleration/#usingvdpau

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140526/c0272947/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=79266

--- Comment #9 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Briefly adding to what Emil said (which I agree with all of):

The one-frame-at-a-time thing... is that flash only, or does it happen
elsewhere? If it's flash-only, I'm inclined to discount it as a flash
bug.
Flash has _tons_ of bugs in the video functionality, they only test it directly
with the nvidia implementation, and when it works there they stop. We do not
aim to be bug-for-bug compatible with the nvidia impl.

If the one-frame-at-a-time thing happens elsewhere too, that most probably
points to an interrupt delivery problem. An easy thing to try would be to
disable MSI (boot with nouveau.config=NvMSI=0) which was added with kernel
3.13. If the issue was happening before 3.13, it's something else.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140526/20fa427a/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=79266

--- Comment #10 from C0NPAQ <afasdfsdfaa at master.ms> ---
I am sorry, but I am testing this on my main machine and it is driving me nuts. 

Now that I installed the nouveau-fw package, the flash colors are ok, but
everything is still extremely sluggish and, for lack of better words, just
weird. Also the PC crashed 2 times now since I tested in an hour or what, when
there was high disk load and I transversed from one screen to another ...


Why weird? For example this: the screen only updates if I move/wiggle the
mouse. If I create a new window, for example urxvt, I have to wiggle the mouse
around or it won't show ... literally. I can open alsamixer 'half
way' from top
top to bottom if I stop moving the mouse. 

I have recorded some of the sluggishness with ffmpeg and that is when it got
even weirder: I recorded on :0.0 and the mouse would show from :0.0 but the
background was from :0.1 . Also, :0.0 is 1200x1028 and :0.1 is 1920x1080 (and
:0.2 is 1080x1920) and when I open firefox on :0.1 it only draws like 1200
pixell. 

Oh my god I am sorry, there is so much more, it is so hard to type because
seemingly arbitrarily the text/characters I type only shows 100ms to 2 seconds
later it makes me so agitated I have to stop and switch to nvidia again or I
will throw something out of the window the laggishness is just impossible.
Sorry. OPlease see the sxcreenshot I attached.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140526/e510ec48/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=79266

--- Comment #11 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to comment #10)
> I have recorded some of the sluggishness with ffmpeg and that is when it
got
> even weirder: I recorded on :0.0 and the mouse would show from :0.0 but the
> background was from :0.1 . Also, :0.0 is 1200x1028 and :0.1 is 1920x1080
> (and :0.2 is 1080x1920) and when I open firefox on :0.1 it only draws like
> 1200 pixell. 
Can you talk a bit more about your setup? Are you using ZaphodHeads?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140526/8e5dac45/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=79266

--- Comment #12 from C0NPAQ <afasdfsdfaa at master.ms> ---
Created attachment 99889
  --> https://bugs.freedesktop.org/attachment.cgi?id=99889&action=edit
nouveau weirdness example

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140526/1b73c4e3/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=79266

--- Comment #13 from C0NPAQ <afasdfsdfaa at master.ms> ---
OK, I switched back to nividia driver.

My setup is 3 monitors, from left to right 1200x1024, 1920x1080,1080x1920. I
have two identical GT430 and 6 outputs total are possible. Before I tell you
that I used Option "ZaphodHeads" and "monitor-[OUTPUT NAME]"
(whatever that is
called, and it is documented nowhere but it works) in xorg, let me tell you
that the sluggishness definitively has nothing to do with it, since the first
thing I did when I noticed it was to run without xorg.conf and use only one
screen. Sometimes the 'mouse-wiggle' occurs sometimes it doesn't.
Maybe the
crashes get worse if I use multiple screens but definitively the whole system
crashes either way, single screen or not.

I will upload a video to youtube, I recorded with my mobile phone, of the
mouse-wiggle issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140526/1247e0be/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=79266

--- Comment #14 from C0NPAQ <afasdfsdfaa at master.ms> ---
Here is a demo, just to clearly show what I mean by "mouse-wiggle
issue":

https://www.youtube.com/watch?v=6RDF_rSCQk8

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140526/76455704/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=79266

--- Comment #15 from C0NPAQ <afasdfsdfaa at master.ms> ---
Also let me tell you that I am running another PC with two nvidia 8400GS and 5
monitors, all rotated clockwise with the Option "ZaphodHeads" and
"monitor-[OUTPUT NAME]" "[MONITOR NAME]" Option
"Rotate" "Right" (under
"[MONITOR NAME]" under Monitor Section) successfully with the nouveau
driver
and without issues (despite a minor increase in tearing, which is probably due
to the clocking issue you mentioned) off a HDD clone of this machine with same
window manager, same distribution and everything except the hardware, where I
also used this mouse, if that is relevant at all.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140526/d22a1254/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=79266

--- Comment #16 from C0NPAQ <afasdfsdfaa at master.ms> ---
(In reply to comment #9)
> Briefly adding to what Emil said (which I agree with all of):
> 
> The one-frame-at-a-time thing... is that flash only, or does it happen
> elsewhere? If it's flash-only, I'm inclined to discount it as a
flash bug.
> Flash has _tons_ of bugs in the video functionality, they only test it
> directly with the nvidia implementation, and when it works there they stop.
> We do not aim to be bug-for-bug compatible with the nvidia impl.
> 
> If the one-frame-at-a-time thing happens elsewhere too, that most probably
> points to an interrupt delivery problem. An easy thing to try would be to
> disable MSI (boot with nouveau.config=NvMSI=0) which was added with kernel
> 3.13. If the issue was happening before 3.13, it's something else.

What do you mean by "one-frame-at-a-time"? And -no-, although most of
the
issues seem to be 'intensified' by using flash player they occur
regardless if
it is used or not. Seemingly the correlating factor is merely processor and
memory utilization combined with sheer randomness, which would conform to my
memory-leak-somewhere theory. MSI might be a possiblity, but I won't test
again
anywhen soon. I almost cried half an hour ago it was so terrible.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140526/ce16c836/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=79266

Ilia Mirkin <imirkin at alum.mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #17 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Too many conflated issues in a single bug report. Pick *one* problem and file a
new bug. Make sure to use an up-to-date software stack as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20151022/e10d8f7e/attachment.html>