More info on the tearing problem

[Dale_K]

I'm running a Fiire Server with Fiire Invisible MD's.  I ran one MD on UI2 +alpha for about 2 weeks but changed it to overlay for astetic reasons (just didn't care for the UI).  My other two MD's have always run on UI2 +overlay.  In all cases I've never had tearing, black boxes, sluggish response or any of the issues noted here.  Not sure of the exact chipset/specs of the Invisible but maybe there is something there that can give a hint to a solution, they seem to have figured it out or I'm just extremely lucky.

I know that many people have less than stellar things to say about Fiire, but for me they've been perfect.  Timely delivery, good support when needed, accurate order, etc.  Again, maybe I'm just extremely lucky.

[colinjones]

It uses the 7050 nVidia chip, which is exactly the same as my core's on board chipset... and I always had the tearing problem with it no matter what options I chose... I now use a 7300GT card for other reasons, but this too had the tearing problem in exactly the same way even though general rendering on this chipset should be like 8 times faster.... So either you were VERY lucky some how, or I would like to know why Fiire have not contributed a "fix" back for this!

[purps]

Is there any possibility at all that the tearing issue is a PCIe problem? Does everybody who is having the problem use a PCIe card? I mention this because I have the dreaded tearing as well, but only with my PICe nVidia card. My old hybrid had an AGP nVidia, and it worked perfectly.

[totallymaxed]

Is there any possibility at all that the tearing issue is a PCIe problem? Does everybody who is having the problem use a PCIe card? I mention this because I have the dreaded tearing as well, but only with my PICe nVidia card. My old hybrid had an AGP nVidia, and it worked perfectly.

Dont think so... We see it on all combinations of onboard & PCIe GPUs.... Collins motherboard uses on an onboard 7050 GPU... thats not PCIe

Andrew

[colinjones]

The other thing is, blitting and frame buffer switching happens entirely on the GPU side of the PCI interface, the only thing that crosses the PCI boundary during this process is the command to trigger the blit or swap, not the actual data itself. And when this is sync'd to the vblank retrace period, it is triggered within the GPU anyway, so nothing is crossing that interface. (incidentally, Andrew, of course you are right that the 7050 is onboard, but it is still interfacing using the PCI bus EDIT: with the on board 7050, the frame buffer being in RAM means that this data does cross the PCI interface, so potentially could make it worse!)

But thinking this through, and in light of Thom's comments, makes me think that perhaps what is happening is the entire process is being sync'd to start at the beginning of the retrace period (when the notional "beam" is at the bottom-right of the screen - actually at the bottom right of the bottom vertical porch), but the process involves compositing before it can flip the screen buffers. And perhaps this composite takes so long that the retrace has completed and is already part way into tracing out the next frame... hence a tear occurs.

Logically, you would expect the composite to occur after video frame texture is drawn, but before the request for a buffer flip, and thus before the vblank sync which would mean that only a flip is needed between back v porch and front v porch, which takes no time whatsoever. This would also explain to some extent why the tear line is always in the same place, no matter how complex or not the graphics/video at the time... hmm.. just a thought. Perhaps the nVidia coding with the driver has the composite and vsync in the wrong order?

[totallymaxed]

Snip.....(incidentally, Andrew, of course you are right that the 7050 is onboard, but it is still interfacing using the PCI bus EDIT: with the on board 7050, the frame buffer being in RAM means that this data does cross the PCI interface, so potentially could make it worse!)
...Snip....

Well the above is certainly true... but of course the reality is that tearing in UI2 + Alpha in our tests is equally bad using either on-board GPU's or PCIe based ones. So this may be a factor... but its impact the same for both types of GPU.

Logically, you would expect the composite to occur after video frame texture is drawn, but before the request for a buffer flip, and thus before the vblank sync which would mean that only a flip is needed between back v porch and front v porch, which takes no time whatsoever. This would also explain to some extent why the tear line is always in the same place, no matter how complex or not the graphics/video at the time... hmm.. just a thought. Perhaps the nVidia coding with the driver has the composite and vsync in the wrong order?

Hmmm... well the above could very well be the case. Interesting hypothesis indeed!!

All the best

Andrew

[colinjones]

Logically, you would expect the composite to occur after video frame texture is drawn, but before the request for a buffer flip, and thus before the vblank sync which would mean that only a flip is needed between back v porch and front v porch, which takes no time whatsoever. This would also explain to some extent why the tear line is always in the same place, no matter how complex or not the graphics/video at the time... hmm.. just a thought. Perhaps the nVidia coding with the driver has the composite and vsync in the wrong order?

Hmmm... well the above could very well be the case. Interesting hypothesis indeed!!

All the best

Andrew
[/quote]

Pure guess work tho!

[Afkpuz]

I've also noticed that UI2+alpha is more responsive and clears out very quickly once I've pressed a button.  In UI2+masking, calling up the gyro menu sometimes begins slowly and leaves black boxes.  I've just learned to live with it, but alpha blending eliminates that for me.

well that is almost exactly what I was experiencing. Using the steps from the wiki, specifically:

Disable De-Interlacing
Change method to libmpeg2
Enable OpenGL

Fixed that issue immediately. My UI2-masked is ultra smooth and responsive now.
Just have to figure out how to get the changes to stick on a router reload. But go ahead and try it. Just the first parts. I have not modified the recorded tv parts of it, just the playback. Makes it super nice.

Just give it a try  

Regards,

Seth

So, is there a specific wiki page describing this process, or should I look for each individually?

[Viking]

Hi,

It uses the 7050 nVidia chip, which is exactly the same as my core's on board chipset... and I always had the tearing problem with it no matter what options I chose... I now use a 7300GT card for other reasons, but this too had the tearing problem in exactly the same way even though general rendering on this chipset should be like 8 times faster.... So either you were VERY lucky some how, or I would like to know why Fiire have not contributed a "fix" back for this!

A bit OT, but is this only when using UI2 + Alpha or also with the basic UI2 interface ?

I am asking because I have got tearings when playing DVD's with the basic UI2 interface.
EDIT: I am using 1080p resolution.

Greetings
Viking

[colinjones]

Tearing is a general issue as well, often related not vsync'ing for instance. With Alphablending generally you will always get it (a very small number of people say they haven't but generally...), and it seems always to be in the same spot on the screen, which is a little unusual... But with non-alpha modes you can get it as well, just like any other graphic animation task.... that is usually just that the video isn't vsync'd, and with that the tear will usually move around the screen a bit as the timing isn't the same with each frame. You can fix that by using the nvidia-settings tool... take a look on the wiki for more instructions...

[Viking]

Hi colin,

I already search a lot and also tried turning off vsync as shown in http://wiki.linuxmce.org/index.php/Nvidia_Card_Tweaks_For_Better_MythTV_and_UI_Performance
But that only made it worse, so I turned it on again.
Is it a difference that I am using an European TV with 100hz ? (did buy the 100hz version of the TV, so that I would have the option of turning the motion-improvement feature on or off. But that did no difference here)

I am at the moment testing DVD playback with SURFSUP.
At the beginning there is the zoom out and down of the columbia woman with the torch it stutters a bit. And then at 1:24 there is a couple of pannings over some "documents" where I get some tearing and stuttering  

I am also getting stuttering playback on VDR recordings. On camera movements it regularily stutters.

Greetings
Viking

[colinjones]

Viking

Turning ON vsync is what you need to do for dealing with tearing issue, not off. That article is about performance issues (and I don't agree with it anyway).

European TV is not 100Hz frame rate, it is 25Hz or sometimes 50Hz (for progressive scan). Your TV running at 100Hz could potentially cause a stobing effect (unlikely) see if you can switch it back to 50/25Hz temporarily to be sure.

Certainly the mismatch between the frame rate that the video source is at, and the refresh rate of the mode you are using on the graphics chipset could cause judder (but not normally tearing, if vsync is turned on). You should check what refresh rate the screen mode is using - probably 60Hz, and see if you can modify a modeline to pick a 50Hz screen mode. Also, trying in less than 1080p to start with might be useful. Say 720p - these actions will reduce the workload on your graphics chipset and reduce the possibility of the strobing effect, both of which will have a positive effect on judder, but again, not usually on tearing.

What graphics chipset are you using, and can you confirm that the xorg.conf file states the nvidia driver (not nv or vesa) is being used. Review the Xorg.0.log file to confirm that there are no errors when it tries to select this driver.

But first up be clear on the effect you are getting - juddering/jerking is when the pans/zooms or fast moving objects do not appear to move smoothly, as if some frames were dropped. Tearing is completely different - you will get a horizontal line somewhere on the screen, during motion (particularly horizontal) where an image appears to be sheared sideways, so the image above that line is somewhat to the left or right of the remaining part of the same image below that line. Not by a long way, but enough to be noticeable. If your video is correctly vsync'd this should not happen at all, unless you are running in alphablended mode.

Finally, from the KDE desktop, run glxgears and expand the window to be large, then watch the output in the console you ran the tool from and note how many frames per second it is able to achieve. Without vsync, a decent card should get several hundreds or even thousands of fps, with vsync it should be exactly 50 or 60 fps. When vsync is on, also note whether there is tearing on the animated gears.