Intel Linux Driver Still Working To Address Tearing

[ChrisXY]

I've never had any stability issues with intel graphics, I have two laptops with them (one with ironlake, one with ivybridge).

I have a 3632qm.

I don't get any tearing on either of them,

I have tearing, especially on flash video with kwin xrender compositing.

Just because you ran into a bug on your system doesn't really mean intel is 'generally unreliable'. Intel is one of the more reliable choices for linux hardware.

Now that kwin has fixed the "MSAA bug" I can use opengl compositing again. It seems intel's driver bug where the gpu hangs isn't triggered anymore either. But instead now the graphical output freezes completely when putting a flash video on fullscreen with opengl compositing. with gles compositing it works but there are massive redraw issues. I still have screen corruption issues with tooltips or when I open the menus of chrome extensions.


Probably not all the issues I have are intel issues. But they are all issues I have since I use intel and that I didn't have when using radeon on a HD 6550M. Maybe intel just doesn't try to keep git master stable...

[bwat47]

If this thread reply is to me, nVidia's priorpetary driver is far better on reliability and stability compared to AMD and Intel graphic drivers. Occasionally, I get the following message with Intel graphics.

[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off

I never have instability issues with nVidia graphic cards like I get above. Also I do not get any video tearing when VSYNC is enabled for OpenGL and/or X-Video. Intel fixing the video tearing bug is not much of an issue for me compared to stability and reliability problems that I am having with Intel graphics in Linux.

I have no problems using OpenGL for video playback in fullscreen with nVidia graphics on my other systems. When I use Radeon graphics using open source drivers, video playback with OpenGL works even in fullscreen. I use X-Video for Intel graphics, so I can have the reliability and stability. My computer with i3-3225 is fast enough to handle 1080p content so I do not need VA API. My other computer with T7300 CPU that has a GeForce8 8400M GS can use VDPAU, but lately MPlayer has issues with VDPAU.

From I learn in the past of other Intel hardware like WiFi, relability and stability does not get fixed. Intel just provides the software for their hardware to a working condition and Intel expects open source developers to fix the issues if their drivers have any or add features.

I've never had any stability issues with intel graphics, I have two laptops with them (one with ironlake, one with ivybridge). I don't get any tearing on either of them, I've also never had a single issue with intel wireless, and every laptop I've ever used linux with has had intel wireless.

vaapi did give me a few issues with the ironlake chip, but is working perfectly with my ivybridge.

Just because you ran into a bug on your system doesn't really mean intel is 'generally unreliable'. Intel is one of the more reliable choices for linux hardware.

I have an Intel i3-3225 (Ivy Bridge) tearing is less on OpenGL even though vsync is enabled. I have to include TearFree in my xorg.conf file, but opens up other problems. When I enable TearFree and xscreensaver sends a stand-by command to my monitor, X Window System crashes. Using OpenGL for video playback is not an option because it is unreliable. I just have to deal with tearing or get a nVidia graphics card. People said that nVidia does not support FOSS, but nVidia supports their graphics for Linux better than other companies.

I use Calculate Linux (Gentoo based) and Xfce as my desktop manager with compositer disabled.

Using a compositer to fix the issue is the most stupidest work-around. Also switching from graphics port to the other is another stupid work-around. Your monitor might have less layers of processing for DVI compared to HDMI.

Compositing is the future, I can't stand using a desktop without compositing, personally. Currently I use ubuntu and the intel graphics are giving me a perfect, tear free experience out of the box, I've had zero issues. Intel is the only graphics company that actually develops OSS drivers themselves, so that makes them a winner in my book. I can't stand dealing with proprietary drivers.

[tecknurd]

Nvidia is not perfect as well. Basically what works for Intel+Nvidia is opengl output with disabled composite and fullscreen. Like when you use xbmc or so it usally looks good (for streaming vaapi is not fully stable, so maybe you have to disable that). mplayer fullscreen usally works as well.

If this thread reply is to me, nVidia's priorpetary driver is far better on reliability and stability compared to AMD and Intel graphic drivers. Occasionally, I get the following message with Intel graphics.

[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off

I never have instability issues with nVidia graphic cards like I get above. Also I do not get any video tearing when VSYNC is enabled for OpenGL and/or X-Video. Intel fixing the video tearing bug is not much of an issue for me compared to stability and reliability problems that I am having with Intel graphics in Linux.

I have no problems using OpenGL for video playback in fullscreen with nVidia graphics on my other systems. When I use Radeon graphics using open source drivers, video playback with OpenGL works even in fullscreen. I use X-Video for Intel graphics, so I can have the reliability and stability. My computer with i3-3225 is fast enough to handle 1080p content so I do not need VA API. My other computer with T7300 CPU that has a GeForce8 8400M GS can use VDPAU, but lately MPlayer has issues with VDPAU.

From I learn in the past of other Intel hardware like WiFi, relability and stability does not get fixed. Intel just provides the software for their hardware to a working condition and Intel expects open source developers to fix the issues if their drivers have any or add features.

[Kano]

Nvidia is not perfect as well. Basically what works for Intel+Nvidia is opengl output with disabled composite and fullscreen. Like when you use xbmc or so it usally looks good (for streaming vaapi is not fully stable, so maybe you have to disable that). mplayer fullscreen usally works as well.

[tecknurd]

I have an Intel i3-3225 (Ivy Bridge) tearing is less on OpenGL even though vsync is enabled. I have to include TearFree in my xorg.conf file, but opens up other problems. When I enable TearFree and xscreensaver sends a stand-by command to my monitor, X Window System crashes. Using OpenGL for video playback is not an option because it is unreliable. I just have to deal with tearing or get a nVidia graphics card. People said that nVidia does not support FOSS, but nVidia supports their graphics for Linux better than other companies.

I use Calculate Linux (Gentoo based) and Xfce as my desktop manager with compositer disabled.

Using a compositer to fix the issue is the most stupidest work-around. Also switching from graphics port to the other is another stupid work-around. Your monitor might have less layers of processing for DVI compared to HDMI.

[ickle]

Yes I do use OpenGL with enabled VSync option. The remaining tearing I'm seeing seems to be a bug in Kwin (https://bugs.kde.org/show_bug.cgi?id=307965)

This is only on my main monitor, on the second there does not seem to be any synching.

Edit: Windows is fine as long as you use an Aero theme, with anything different everything tears (both monitors).

So this looks like another Kwin bug?

Yes, the tearing you see in Kwin's compositor is because they use MESA_copy_sub_buffer rather than composite the whole framebuffer and swap. MESA_copy_sub_buffer was originally created as an optimisation and all the compositors were encouraged to use it. In retrospect, it was a bad idea, hurting the bandwidth constrained IGP devices the most. The very same devices that it claimed to be designed for. And now continued use of that extension is an extreme pessimation.

[enteon]

Yes I do use OpenGL with enabled VSync option. The remaining tearing I'm seeing seems to be a bug in Kwin (https://bugs.kde.org/show_bug.cgi?id=307965)

This is only on my main monitor, on the second there does not seem to be any synching.

Edit: Windows is fine as long as you use an Aero theme, with anything different everything tears (both monitors).

So this looks like another Kwin bug?

[ickle]

Nice to know that I can switch tearing between monitors, thanks.


Now my xorg.log states:
(II) intel(0): Kernel page flipping support detected, enabling

This might be a dumb question, but why do I see tearing then?
Is page flipping simply not used by X/Kwin?
Could I do something about it?

Thank you.

So the good news is that you do indeed have a system that supports pageflipping. However, as you rightly surmise, it requires an OpenGL application or compositor to replace the entire scanout buffer in a single glXSwapBuffers() request, i.e. we can only pageflip to the new buffer if that buffer should replace every single pixel on the scanout. Using Kwin, you would need to enable Desktop Effects using OpenGL. Or if you only care about tearing in individual fullscreen applications, choose applications that use DRI2 to update their output (i.e. OpenGL or VA-API).

[ickle]

I don't like the idea of losing power savings, is this something that will be enabled by default, or is it talking about the optional TearFree xorg conf option?

From what I've seen this tearing issue is only a problem if you aren't using an opengl compositor. Compiz in ubuntu 12.10 seems to support pageflipping, because I get no tearing on my intel card even with vsync disabled in compizconfig, and I get no tearing in gnome-shell as long as I use the CLUTTER_DEBUG=disable-culling workaround, no tearing in kwin either.

First note that all Intel hardware up to SandyBridge has functional vsync support with no greater cost than stalling the GPU until the blit can proceed.

The problem is that with the agressive powersaving of SandyBridge and the greater decoupling between the display engine and the GPU, the ability to delay rendering until a particular scanline had passed was assumed to be a legacy feature and the GPU commands to do so were removed. By presuming that all updates would then be through a compositor using pageflipping (i.e. their primary target, Windows Vista/7/8), they were then able to make further power savings. If you use an OpenGL (really DRI2) compositor that only pageflips (i.e. doesn't try to take "advantage" of MESA_copy_sub_buffer), you will not see any tearing, suffer very little jitter, and maximise the power savings of the GPU.

The TearFree option (still in its infancy, and really only a proof-of-principle at this stage) is to make sure that even a bare X only ever pageflips. This is primarily because future hardware will have even more widespread aggressive power savings that assume a compositor, and worst case scenario, the display engine will only be functional with a pageflipping compositor.

[bwat47]

I don't like the idea of losing power savings, is this something that will be enabled by default, or is it just talking about the optional TearFree xorg conf option?

From what I've seen this tearing issue is only a problem if you aren't using an opengl compositor. Compiz in ubuntu 12.10 seems to support pageflipping, because I get no tearing on my intel card even with vsync disabled in compizconfig, and I get no tearing in gnome-shell as long as I use the CLUTTER_DEBUG=disable-culling workaround, no tearing in kwin either.