Announcement

Collapse
No announcement yet.

Intel OpenGL/Vulkan Developers Join #intel-3d

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

  • Intel OpenGL/Vulkan Developers Join #intel-3d

    Phoronix: Intel OpenGL/Vulkan Developers Join #intel-3d

    For those having issues with the "i965" OpenGL or "ANV" Vulkan drivers within Mesa, Intel open-source developers have now setup the #intel-3d IRC for discussions around these Intel Mesa 3D drivers...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I've always been curious why we have an i965 X11 driver, i965 DRM module, yet X11, lsmod, find /sys, etc all report i915 is in use instead, when my hardware isn't even supported by the i915 driver, at least according Intel... anyone got any insights?

    Comment


    • #3
      Originally posted by linuxgeex View Post
      I've always been curious why we have an i965 X11 driver, i965 DRM module, yet X11, lsmod, find /sys, etc all report i915 is in use instead, when my hardware isn't even supported by the i915 driver, at least according Intel... anyone got any insights?
      Linux breaks up hardware support in 3 separate drivers: Kernel driver (exposes hardware to userspace and runs in kernel), Xorg driver (userspace, 2D acceleration), Mesa driver (userspace, 3D acceleration).

      Afaik Intel kernel driver is i915 for pretty much all their hardware (naming convention is "driver is named as first hardware supported by it"). lsmod and /sys show that because they are looking at kernel modules.

      Afaik on Intel hardware there are different 2D/3D drivers depending on hardware, the i915 and the i965 and maybe others too. You should probably see the i965 being loaded in xorg logs (for 2D) and in Mesa driver info console commands (for 3D).

      This is an excerpt from my box's /var/log/Xorg.0.log that shows kernel driver is i915 (first line) while Xorg has loaded i965 driver (4th line from bottom).
      In case you are wondering what is a "HD Graphics P4000", it is the "pro" version of the HD4000 which is found in my Ivy Bridge Xeon CPU.

      Code:
      [ 28.279] (II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20160919
      [ 28.280] (WW) Falling back to old probe method for modesetting
      [ 28.280] (WW) Falling back to old probe method for fbdev
      [ 28.280] (II) Loading sub module "fbdevhw"
      [ 28.280] (II) LoadModule: "fbdevhw"
      [ 28.280] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so
      [ 28.332] (II) Module fbdevhw: vendor="X.Org Foundation"
      [ 28.332] compiled for 1.18.3, module version = 0.0.2
      [ 28.332] ABI class: X.Org Video Driver, version 20.0
      [ 28.332] (WW) Falling back to old probe method for vesa
      [ 28.332] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics P4000
      [ 28.332] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3, sse4.1, sse4.2, avx; using a maximum of 4 threads
      [ 28.332] (II) intel(0): Creating default Display subsection in Screen section
      "Default Screen Section" for depth/fbbpp 24/32
      [ 28.332] (==) intel(0): Depth 24, (--) framebuffer bpp 32
      [ 28.332] (==) intel(0): RGB weight 888
      [ 28.332] (==) intel(0): Default visual is TrueColor
      [ 28.333] (II) intel(0): Output VGA1 has no monitor section
      [ 28.333] (II) intel(0): Enabled output VGA1
      [ 28.333] (II) intel(0): Output HDMI1 has no monitor section
      [ 28.333] (II) intel(0): Enabled output HDMI1
      [ 28.333] (II) intel(0): Output DP1 has no monitor section
      [ 28.334] (II) intel(0): Enabled output DP1
      [ 28.334] (--) intel(0): Using a maximum size of 256x256 for hardware cursors
      [ 28.334] (II) intel(0): Output VIRTUAL1 has no monitor section
      [ 28.334] (II) intel(0): Enabled output VIRTUAL1
      [ 28.334] (--) intel(0): Output HDMI1 using initial mode 1280x1024 on pipe 0
      [ 28.334] (==) intel(0): TearFree disabled
      [ 28.334] (==) intel(0): DPI set to (96, 96)
      [ 28.334] (II) Loading sub module "dri3"
      [ 28.334] (II) LoadModule: "dri3"
      [ 28.334] (II) Module "dri3" already built-in
      [ 28.334] (II) Loading sub module "dri2"
      [ 28.334] (II) LoadModule: "dri2"
      [ 28.334] (II) Module "dri2" already built-in
      [ 28.334] (II) Loading sub module "present"
      [ 28.334] (II) LoadModule: "present"
      [ 28.334] (II) Module "present" already built-in
      [ 28.334] (II) UnloadModule: "modesetting"
      [ 28.334] (II) Unloading modesetting
      [ 28.334] (II) UnloadModule: "fbdev"
      [ 28.334] (II) Unloading fbdev
      [ 28.334] (II) UnloadSubModule: "fbdevhw"
      [ 28.334] (II) Unloading fbdevhw
      [ 28.334] (II) UnloadModule: "vesa"
      [ 28.334] (II) Unloading vesa
      [ 28.334] (==) Depth 24 pixmap format is 32 bpp
      [ 28.335] (II) intel(0): SNA initialized with Ivybridge (gen7, gt2) backend
      [ 28.335] (==) intel(0): Backing store enabled
      [ 28.335] (==) intel(0): Silken mouse enabled
      [ 28.335] (II) intel(0): HW Cursor enabled
      [ 28.335] (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message.
      [ 28.335] (==) intel(0): DPMS enabled
      [ 28.335] (==) intel(0): Display hotplug detection enabled
      [ 28.335] (II) intel(0): [DRI2] Setup complete
      [ 28.335] (II) intel(0): [DRI2] DRI driver: i965
      [ 28.335] (II) intel(0): [DRI2] VDPAU driver: va_gl
      [ 28.335] (II) intel(0): direct rendering: DRI2 enabled
      [ 28.335] (II) intel(0): hardware support for Present enabled
      I don't remember atm how to dump Mesa driver info, the Xorg log is enough to prove my point.

      Comment


      • #4
        Thanks starshipeleven, you got me on the right path. Short answer for anyone else who was interested:

        X startup log showing the drivers being loaded but the wrong DRI version (DRI2) being initialized for screen 0:

        Code:
        user@localhost:~/$ grep -i "\(dri[123]\|i9[16]5\)" /var/log/Xorg.0.log
            915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
        [ 87810.404] (II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20161121
        [ 87810.437] (II) Loading sub module "dri3"
        [ 87810.437] (II) LoadModule: "dri3"
        [ 87810.437] (II) Module "dri3" already built-in
        [ 87810.437] (II) Loading sub module "dri2"
        [ 87810.437] (II) LoadModule: "dri2"
        [ 87810.437] (II) Module "dri2" already built-in
        [ 87810.442] (II) intel(0): [DRI2] Setup complete
        [ 87810.442] (II) intel(0): [DRI2]   DRI driver: i965
        [ 87810.442] (II) intel(0): [DRI2]   VDPAU driver: va_gl
        [ 87810.442] (II) intel(0): direct rendering: DRI2 DRI3 enabled
        [ 87810.460] (II) AIGLX: Loaded and initialized i965
        [ 87810.460] (II) GLX: Initialized DRI2 GL provider for screen 0
        And then confirmation that DRI3 is actually in use and the i965 driver library is being used:

        Code:
        user@localhost:~/$ LC_ALL=C LIBGL_DEBUG=verbose glxinfo >/dev/null
        libGL: pci id for fd 4: 8086:0166, driver i965
        libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/i965_dri.so
        libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
        libGL: Using DRI3 for screen 0
        And then some commentary. I was interested in this because I have an old laptop I got from my sister that I'm using as Kodi box and it had terrible screen tearing.

        On Ubuntu 16.04, creating the following file solved the screen tearing problems, by enabling DRI3 + SNA for 2D and tearfree in the driver:

        Code:
        $ cat /usr/share/X11/xorg.conf.d/20-intel.conf
        Section "Device"
          Identifier "Intel Graphics"
          Driver "Intel"
          Option "DRI" "3"
          Option "AccelMethod" "sna"
          Option "TearFree" "true"
          #Option "TripleBuffer" "true"
          #Option "MigrationHeuristic" "greedy"
          Option "Tiling" "true"
          #Option "Pageflip" "true"
          #Option "ExaNoComposite" "false"
        EndSection
        Now I just have to adjust the audio delay to get lip sync right, lol.
        Last edited by linuxgeex; 23 August 2017, 04:59 PM.

        Comment


        • #5
          Originally posted by linuxgeex View Post
          And then some commentary. I was interested in this because I have an old laptop I got from my sister that I'm using as Kodi box and it had terrible screen tearing.

          On Ubuntu 16.04, creating the following file solved the screen tearing problems, by enabling DRI3 + SNA for 2D and tearfree in the driver:
          I'd actually recommend you to rather deinstall the intel ddx driver. Xorg will then use the modesetting driver with glamor, which is way more stable. That's what all radeonsi cards do, aswell as what happens on wayland (using glamor for xwayland).

          Edit: that's what more recent distributions do, see http://www.phoronix.com/scan.php?pag...ndon-Intel-DDX and https://www.phoronix.com/scan.php?pa...tel-DDX-Switch

          Edit2: you probably want to have the hwe-stack installed if you do it https://wiki.ubuntu.com/Kernel/LTSEnablementStack
          Last edited by treba; 23 August 2017, 07:11 PM.

          Comment


          • #6
            Originally posted by treba View Post
            I'd actually recommend you to rather deinstall the intel ddx driver. Xorg will then use the modesetting driver with glamor, which is way more stable. That's what all radeonsi cards do, aswell as what happens on wayland (using glamor for xwayland).
            This is valid if he has a recent modesetting driver and Mesa though. On a normal Ubuntu 16.04 (or on OpenSUSE Leap, like in my case) it's probably better to stick to Intel ddx driver.

            Comment


            • #7
              Originally posted by starshipeleven View Post
              This is valid if he has a recent modesetting driver and Mesa though. On a normal Ubuntu 16.04 (or on OpenSUSE Leap, like in my case) it's probably better to stick to Intel ddx driver.
              Sure he can, if he wants the shittiest display experience he can possibly imagine. I'm actually quite surprised he claims he eliminated tearing, I don't think that's actually possible with Intel's DDX. I'm sure he just needs to open a browser and scroll to realize it isn't actually fixed for all scenarios. He really should be on the modesetting DDX. Intel desperately needs to make modesetting the default DDX for their products immediately.
              Last edited by duby229; 24 August 2017, 09:10 AM.

              Comment


              • #8
                Originally posted by duby229 View Post
                Sure he can, if he wants the shittiest display experience he can possibly imagine. I'm actually quite surprised he claims he eliminated tearing, I don't think that's actually possible with Intel's DDX. I'm sure he just needs to open a browser and scroll to realize it isn't actually fixed for all scenarios. He really should be on the modesetting DDX. Intel desperately needs to make modesetting the default DDX for their products immediately.
                As said above, if the modesetting driver is not RECENT then Intel DDX is better simply because modesetting sucked more.
                Ubuntu 16.04 is not RECENT.

                Distros dropped Intel DDX in their RECENT newest versions, not retroactively.

                That said, some applications like firefox render like crap anyway because they fail at hardware acceleration on their own, but that's not the driver's fault. It's easy to find people complaining about FF tearing when on Windows and using NVIDIA drivers too.

                Comment


                • #9
                  Originally posted by starshipeleven View Post
                  As said above, if the modesetting driver is not RECENT then Intel DDX is better simply because modesetting sucked more.
                  Ubuntu 16.04 is not RECENT.

                  Distros dropped Intel DDX in their RECENT newest versions, not retroactively.

                  That said, some applications like firefox render like crap anyway because they fail at hardware acceleration on their own, but that's not the driver's fault. It's easy to find people complaining about FF tearing when on Windows and using NVIDIA drivers too.
                  Although I seriously doubt nVidia's xorg DDX has any real relationship to their windows display driver, I'd bet it was architected in a similar fashion. And the bottom line fact is that now Catalyst is gone, nVidia has -the- worst DDX driver of them all. It's not surprising what-so-ever that nVidia's driver tears unfixably.

                  Comment


                  • #10
                    Originally posted by duby229 View Post
                    It's not surprising what-so-ever that nVidia's driver tears unfixably.
                    That's not what I said. Tearing in Firefox is Firefox's fault, not the display driver's fault, especially on Linux where they don't use GPU acceleration at all.

                    Comment

                    Working...
                    X