Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 25

Thread: Intel Linux Driver Still Working To Address Tearing

  1. #11
    Join Date
    Oct 2011
    Posts
    31

    Default

    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.

  2. #12
    Join Date
    Aug 2007
    Posts
    6,641

    Default

    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.

  3. #13
    Join Date
    Oct 2011
    Posts
    31

    Default

    Quote Originally Posted by Kano View Post
    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.


    Code:
    [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.

  4. #14
    Join Date
    May 2010
    Posts
    684

    Default

    Quote Originally Posted by tecknurd View Post
    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.


    Code:
    [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.

    Quote Originally Posted by tecknurd View Post
    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.
    Last edited by bwat47; 11-01-2012 at 07:22 AM.

  5. #15
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    1,052

    Default

    Quote Originally Posted by bwat47 View Post
    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.

    Quote Originally Posted by bwat47 View Post
    I don't get any tearing on either of them,
    I have tearing, especially on flash video with kwin xrender compositing.

    Quote Originally Posted by bwat47 View Post
    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...

  6. #16
    Join Date
    May 2010
    Posts
    684

    Default

    Quote Originally Posted by ChrisXY View Post
    I have a 3632qm.


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


    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...
    I haven't yet tried kwin on my ivybridge machine (an intel i5-3210m), but on my ironlake machine (i5-460m) I had no issues with tearing, flash, or any kind of corruption. I've only used compiz on ivybridge which seems to work with zero issues, I can watch flash videos fullscreen with no problems, and I can watch videos in vlc using vaapi with no issues.

    From what I can see the gles issue is a mesa bug that only cropped up with a recent update and was working before, so perhaps it will be fixed quickly:
    https://bugs.archlinux.org/task/31956
    Last edited by bwat47; 11-01-2012 at 10:00 AM.

  7. #17
    Join Date
    Dec 2011
    Posts
    123

    Default

    Quote Originally Posted by bwat47 View Post
    I don't like the idea of losing power savings
    Me too. I think I'll stay with 3.7 unless this new feature can be disabled.

  8. #18
    Join Date
    Nov 2011
    Posts
    287

    Question

    What about tearing on older Intel graphics?! Like the GM45 / 4500MHD. It started a year ago and is still present. On gnome shell the best results I get are with: environment
    CLUTTER_PAINT=disable-clipped-redraws:disable-culling
    CLUTTER_VBLANK=True
    20-intel.conf
    Section "Device"
    Identifier "Intel Graphics"
    Driver "intel"
    # Option "TearFree" "true"
    # Option "SwapbuffersWait" "true"
    Option "AccelMethod" "sna"
    EndSection
    But the desktop is laggy then. Is there anything more I could do?

  9. #19
    Join Date
    Feb 2013
    Posts
    465

    Default

    Quote Originally Posted by ickle View Post
    You will get tearing if any of the following are true:

    1. Not using a compositor or the application (for Xv, DRI apps) itself requests tearing.
    2. Not using SNA
    3. Not using a kernel >= 3.8
    4. vsync disabled through xorg.conf
    Quote Originally Posted by ickle View Post
    Quote Originally Posted by enteon View Post
    Will it eliminate tearing for multi-monitor setups, too?

    Because right now I get almost tear-free playback on my main monitor (DVI) via kwin vsync (except for a bug in 4.9) but lots of tearing on the second (HDMI).
    No. The way to achieve that is to use pageflipping. Otherwise you will need to process a synchronized update on one pipe, then a synchronized updated on the second pipe, which is very likely miss the vblank every time and so lead to stuttering. Unlike pageflipping which is asynchronous and saves power. (The latter being a major issue on more recent chipsets.)
    What is the required combination of kernel/desktop/compositor/appconfig to eliminate tearing on a multiple monitor setup? Can it be done? Is there any page flipping compositor that properly supports multiple monitors?

    I have "TearFree" enabled in the Intel driver, and I still see tearing when dragging windows around in both Gnome and XFCE (with XFWM/Compton). My main complaint is that tearing is very noticeable when scrolling a page up and down in Firefox/Iceweasel. I do not get the message "Kernel page flipping support detected, enabling" in Xorg log, is that still relevant? I am using Debian Testing, SNA and TearFree are enabled in xorg.conf, Ivybridge i5 laptop HD4000 graphics with triple external DVI monitors connected via passive 1x HDMI>DVI and 2x DP>DVI cables.

    Quote Originally Posted by droste View Post
    I don't think so. My workaround is to switch the primary display via xrandr to the display I'm actually using. So when I work or browse the internet I use 'xrandr --output DVI-0 --primary' to get no tearing with the DVI monitor and when I watch movies/videos I use 'xrandr --output HDMI-0 --primary' to get tearfree video output.
    This does not seem to make any difference.
    Last edited by chrisb; 05-19-2014 at 12:56 PM.

  10. #20

    Default

    Quote Originally Posted by chrisb View Post
    What is the required combination of kernel/desktop/compositor/appconfig to eliminate tearing on a multiple monitor setup? Can it be done? Is there any page flipping compositor that properly supports multiple monitors?

    I have "TearFree" enabled in the Intel driver, and I still see tearing when dragging windows around in both Gnome and XFCE (with XFWM/Compton). My main complaint is that tearing is very noticeable when scrolling a page up and down in Firefox/Iceweasel. I do not get the message "Kernel page flipping support detected, enabling" in Xorg log, is that still relevant? I am using Debian Testing, SNA and TearFree are enabled in xorg.conf, Ivybridge i5 laptop HD4000 graphics with triple external DVI monitors connected via passive 1x HDMI>DVI and 2x DP>DVI cables.



    This does not seem to make any difference.
    TearFree works correctly with multiple monitors, rotated, transformed, cloned or just extended. As always, you need to be using recent drivers to avoid bugs, and in particular you should be using at least 2.99.908, and I have been working on optimising TearFree itself just last week (by reducing the required copies for tracking damage). debian testing is not tracking the relevant bug fixes for SNA / TearFree.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •