Bug 79266

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.

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.

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.

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.

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.

(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.

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.

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

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.

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.

(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?

Created attachment 99889 [details]
nouveau weirdness example

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.

Here is a demo, just to clearly show what I mean by "mouse-wiggle issue":

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

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.

(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.

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.