Announcement

Collapse
No announcement yet.

Intel SNA vs. Modesetting GLAMOR - DDX Benchmarks

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic Intel SNA vs. Modesetting GLAMOR - DDX Benchmarks

    Intel SNA vs. Modesetting GLAMOR - DDX Benchmarks

    Phoronix: Intel SNA vs. Modesetting GLAMOR - DDX Benchmarks

    Following all of the Intel 3D graphics tests this week for DRM-Next code for Linux 4.7, Mesa 11.3-devel, and more, there's been a few readers requesting a fresh xf86-video-intel vs. xf86-video-modesetting comparison...

    http://www.phoronix.com/scan.php?pag...-DDX-May-Tests

  • RickXy
    replied
    Originally posted by TeoLinuX View Post
    What about Ivy Bridge?
    Anyone has tried modesetting? Is it even available?
    Your distribution has to package and ship it. ON Debian, for example, it is bundled in the xserver-xorg-core package.

    To verify, your Xorg log should look like:

    Code:
    [    45.641] (==) Matched intel as autoconfigured driver 0
    [    45.641] (==) Matched intel as autoconfigured driver 1
    [    45.641] (==) Matched modesetting as autoconfigured driver 2
    [    45.641] (==) Matched fbdev as autoconfigured driver 3
    [    45.641] (==) Matched vesa as autoconfigured driver 4
    [    45.641] (==) Assigned the driver to the xf86ConfigLayout
    [    45.641] (II) LoadModule: "intel"
    [    45.641] (WW) Warning, couldn't open module intel
    [    45.641] (II) UnloadModule: "intel"
    [    45.641] (II) Unloading intel
    [    45.641] (EE) Failed to load module "intel" (module does not exist, 0)
    [    45.641] (II) LoadModule: "modesetting"
    [    45.641] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
    [    45.641] (II) Module modesetting: vendor="X.Org Foundation"
    [    45.641]    compiled for 1.18.3, module version = 1.18.3
    [    45.641]    Module class: X.Org Video Driver
    [    45.641]    ABI class: X.Org Video Driver, version 20.0
    [    45.641] (II) LoadModule: "fbdev"
    [    45.641] (WW) Warning, couldn't open module fbdev
    [    45.641] (II) UnloadModule: "fbdev"
    [    45.641] (II) Unloading fbdev
    [    45.641] (EE) Failed to load module "fbdev" (module does not exist, 0)
    [    45.641] (II) LoadModule: "vesa"
    [    45.641] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
    [    45.641] (II) Module vesa: vendor="X.Org Foundation"
    [    45.641]    compiled for 1.18.0, module version = 2.3.4
    [    45.641]    Module class: X.Org Video Driver
    [    45.641]    ABI class: X.Org Video Driver, version 20.0
    [    45.641] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
    [    45.641] (II) VESA: driver for VESA chipsets: vesa
    [    45.641] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
    [    45.641] (II) modeset(0): using drv /dev/dri/card0
    [    45.641] (WW) Falling back to old probe method for vesa
    [    45.641] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
    [    45.641] (II) modeset(0): Creating default Display subsection in Screen section
            "Default Screen Section" for depth/fbbpp 24/32
    [    45.641] (==) modeset(0): Depth 24, (==) framebuffer bpp 32

    IIRC, the biggest benefit with modesetting driver is the following:

    Code:
    [email protected]:~$ ps aux | grep Xorg
    rrs       3165  0.3  1.4 420616 117212 tty2    S+   Jun17  14:56 /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -background none -noreset -keeptty -verbose 3
    rrs      30444  0.0  0.0  12752  2168 pts/3    S+   18:37   0:00 grep --color=auto Xorg
    2016-06-20 / 18:37:37 ♒♒♒  ☺

    Leave a comment:


  • TeoLinuX
    replied
    What about Ivy Bridge?
    Anyone has tried modesetting? Is it even available?

    Leave a comment:


  • geearf
    replied
    xorg.0.log most likely.

    Leave a comment:


  • pq1930562
    replied
    The KODI and LibreELEC developers apparently are claiming that Intel developers would recommend to use xf86-video-modesetting instead of xf86-video-intel, see:

    https://github.com/LibreELEC/LibreELEC.tv/pull/136

    And they are also recommending their users to stop using xf86-video-intel, see:

    http://forum.kodi.tv/showthread.php?...595#pid2315595
    http://forum.kodi.tv/showthread.php?...913#pid2315913

    By the way:

    What is the best way to check which DDX driver is currently in use?

    Leave a comment:


  • nanonyme
    replied
    Originally posted by liam View Post

    NSA has issues with resuming from suspend...so I'm told!!!!...from someone on this site...

    Edit: also, sna STILL isn't the "official" default, IIRC.

    EditEdit: Dammit! SNA NOT NSA! Don't worry Luke, no one's cracked your impenetrable setup. Just keep organizing the Resistance
    Given how complex SNA is said to be, I think there's good chances Glamor becomes good enough for all workloads before SNA becomes the default

    Leave a comment:


  • liam
    replied
    Originally posted by Ericg View Post

    Because the SNA architecture has been finely tuned and is known to be basically stable? Modesetting is still under development. I'll be happy when everyone's switched over too, but the developers have decided we're not there quite yet.
    NSA has issues with resuming from suspend...so I'm told!!!!...from someone on this site...

    Edit: also, sna STILL isn't the "official" default, IIRC.

    EditEdit: Dammit! SNA NOT NSA! Don't worry Luke, no one's cracked your impenetrable setup. Just keep organizing the Resistance
    Last edited by liam; 05-20-2016, 11:57 PM.

    Leave a comment:


  • geearf
    replied
    Well yes GLAMOR uses the 3D part of the card, but I believe it is not used for 3D itself.
    As for the final image rendering, isn't it bypassing the 2D acceleration code anyway?

    Leave a comment:


  • Ericg
    replied
    Originally posted by geearf View Post
    What is the point of testing 3D stuff here? Isn't GLAMOR and co 2D acceleration?
    Kinda sorta. Glamor is 2D over OpenGL, so it's gonna hit some 3D stuff. Plus this is how rendered images wind up actually on the screen, so if one path is slower, then thats good to know.

    Leave a comment:


  • Ericg
    replied
    Originally posted by axfelix View Post
    you need to manually enable DRI3 in xorg.conf to avoid tearing under Gnome with SNA, but that's not too hard to do
    Any test case to force tearing? I've got Gnome + SNA + DRI2 on Broadwell with no tearing.

    Leave a comment:

Working...
X