1. 15 Apr, 2019 1 commit
  2. 26 Feb, 2019 1 commit
  3. 21 Feb, 2019 1 commit
    • Kenneth Graunke's avatar
      iris: Initial commit of a new 'iris' driver for Intel Gen8+ GPUs. · 2dce0e94
      Kenneth Graunke authored
      This commit introduces a new Gallium driver for Intel Gen8+ GPUs,
      named 'iris_dri.so' after the hardware.
      
      Developed by:
      - Kenneth Graunke (overall driver)
      - Dave Airlie (shaders, conditional render, overflow query, Gen8 port)
      - Chris Wilson (fencing, pinned memory, ...)
      - Jordan Justen (compute shaders)
      - Jason Ekstrand (image load store)
      - Caio Marcelo de Oliveira Filho (tessellation control passthrough)
      - Rafael Antognolli (auxiliary buffer fixes)
      - The rest of the i965 contributors and the Mesa community
      2dce0e94
  4. 14 Feb, 2019 1 commit
  5. 05 Feb, 2019 1 commit
  6. 22 Jan, 2019 1 commit
  7. 08 Jan, 2019 1 commit
    • Tapani Pälli's avatar
      dri3: initialize adaptive_sync as false before configQueryb · c2924147
      Tapani Pälli authored
      Fixes following errors from valgrind output:
      
         ==23388== Conditional jump or move depends on uninitialised value(s)
         ==23388==    at 0x48B4924: loader_dri3_drawable_init (loader_dri3_helper.c:381)
         ==23388==    by 0x48A97D2: dri3_create_drawable (dri3_glx.c:386)
         ==23388==    by 0x489E190: driFetchDrawable (dri_common.c:369)
         ==23388==    by 0x48A9187: dri3_bind_context (dri3_glx.c:195)
         ==23388==    by 0x488B75C: MakeContextCurrent (glxcurrent.c:220)
         ==23388==    by 0x488B8DB: glXMakeCurrent (glxcurrent.c:267)
         ==23388==    by 0x10A987: ??? (in /usr/bin/glxgears)
         ==23388==    by 0x4BEB412: (below main) (in /usr/lib64/libc-2.28.so)
         ==23388==
         ==23388== Conditional jump or move depends on uninitialised value(s)
         ==23388==    at 0x48B5A40: loader_dri3_swap_buffers_msc (loader_dri3_helper.c:923)
         ==23388==    by 0x48A9B7E: dri3_swap_buffers (dri3_glx.c:587)
         ==23388==    by 0x4887A81: glXSwapBuffers (glxcmds.c:857)
         ==23388==    by 0x10ADED: ??? (in /usr/bin/glxgears)
         ==23388==    by 0x4BEB412: (below main) (in /usr/lib64/libc-2.28.so)
      
      Fixes: 2e12fe42 "loader/dri3: Enable adaptive_sync via _VARIABLE_REFRESH property"
      Signed-off-by: 's avatarTapani Pälli <tapani.palli@intel.com>
      Reviewed-by: 's avatarMichel Dänzer <michel.daenzer@amd.com>
      Reviewed-by: 's avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      c2924147
  8. 28 Dec, 2018 1 commit
    • Nicholas Kazlauskas's avatar
      loader/dri3: Enable adaptive_sync via _VARIABLE_REFRESH property · 2e12fe42
      Nicholas Kazlauskas authored
      The DDX driver can be notified of adaptive sync suitability by
      flagging the application's window with the _VARIABLE_REFRESH property.
      
      This property is set on the first swap the application performs
      when adaptive_sync is set to true in the drirc.
      
      It's performed here instead of when the loader is initialized for
      two reasons:
      
      (1) The window's drawable can be missing during loader init.
          This can be observed during the Unigine Superposition benchmark.
      
      (2) Adaptive sync will only be enabled closer to when the application
          actually begins rendering.
      
      If adaptive_sync is false then the _VARIABLE_REFRESH property
      is deleted on loader init.
      
      The property is only managed on the glx DRI3 backend for now. This
      should cover most common applications and games on modern hardware.
      
      Vulkan support can be implemented in a similar manner but would likely
      require splitting the function out into a common helper function.
      Reviewed-by: 's avatarMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: 's avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      2e12fe42
  9. 10 Dec, 2018 1 commit
  10. 04 Dec, 2018 1 commit
  11. 17 Nov, 2018 1 commit
    • Eric Anholt's avatar
      loader: Factor out the common driver opening logic from each loader. · d971a423
      Eric Anholt authored
      I copied the code from egl_dri2.c, but the functionality was equivalent
      between all the loaders other than their particular environment variables.
      
      v2: Drop the logging function equivalent to loader_default_logger()
          (requested by Eric, Emil).  Move the SCons workaround across.  Drop
          the now-unused driGetDriverExtensions() declaration that was lost in a
          rebase.
      
      Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> (v1)
      Reviewed-by: Emil Velikov <emil.velikov@collabora.com> (v1)
      d971a423
  12. 16 Nov, 2018 1 commit
  13. 18 Oct, 2018 1 commit
  14. 12 Sep, 2018 2 commits
  15. 05 Sep, 2018 1 commit
  16. 31 Aug, 2018 1 commit
  17. 17 Aug, 2018 3 commits
  18. 02 Aug, 2018 1 commit
  19. 01 Aug, 2018 1 commit
    • Mario Kleiner's avatar
      loader_dri3: Handle mismatched depth 30 formats for Prime renderoffload. · 9bd8b0f7
      Mario Kleiner authored
      Detect if the display (X-Server) gpu and Prime renderoffload gpu prefer
      different channel ordering for color depth 30 formats ([X/A]BGR2101010
      vs. [X/A]RGB2101010) and perform format conversion during the blitImage()
      detiling op from tiled backbuffer -> linear buffer.
      
      For this we need to find the visual (= red channel mask) for the
      X-Drawable used to display on the server gpu. We use the same proven
      logic for finding that visual as in commit "egl/x11: Handle both depth
      30 formats for eglCreateImage()".
      
      This is mostly to allow "NVidia Optimus" at depth 30, as Intel/AMD
      gpu's prefer xRGB2101010 ordering, whereas NVidia gpu's prefer
      xBGR2101010 ordering, so we can offload to nouveau without getting
      funky colors.
      
      Tested on Intel single gpu, NVidia single gpu, Intel + NVidia prime
      offload with DRI3/Present.
      
      Note: An unintended but pleasant surprise of this patch is that it also
      seems to make the modesetting-ddx of server 1.20.0 work at depth 30
      on nouveau, at least with unredirected "classic" X rendering, and
      with redirected desktop compositing under XRender accel, and with OpenGL
      compositing under GLX. Only X11 compositing via OpenGL + EGL still gives
      funky colors. modesetting-ddx + glamor are not yet ready to deal with
      nouveau's ABGR2101010 format, and treat it as ARGB2101010, also exposing
      X-visuals with ARGB2101010 style channel masks. Seems somehow this triggers
      the logic in this patch on modesetting-ddx + depth 30 + DRI3 buffer sharing
      and does the "wrong" channel swizzling that then cancels out the "wrong"
      swizzling of glamor and we end up with the proper pixel formatting in
      the scanout buffer :). This so far tested on a NVA5 Tesla card under KDE5
      Plasma as shipping with Ubuntu 16.04.4 LTS.
      Signed-off-by: 's avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Cc: Ilia Mirkin <imirkin@alum.mit.edu>
      Reviewed-by: 's avatarEric Engestrom <eric.engestrom@intel.com>
      9bd8b0f7
  20. 31 Jul, 2018 1 commit
  21. 22 May, 2018 1 commit
    • Michel Dänzer's avatar
      dri3: Stricter SBC wraparound handling · fe2edb25
      Michel Dänzer authored
      Prevents corrupting the upper 32 bits of draw->recv_sbc when
      draw->send_sbc resets to 0 (which currently happens when the window is
      unbound from a context and bound to one again), which in turn caused
      loader_dri3_swap_buffers_msc to calculate target_msc with corrupted
      upper 32 bits. This resulted in hangs with the Xorg modesetting driver
      as of xserver 1.20 (older versions and other drivers ignored the upper
      32 bits of the target MSC, which is why this wasn't noticed earlier).
      
      Cc: mesa-stable@lists.freedesktop.org
      Bugzilla: https://bugs.freedesktop.org/106351Tested-by: 's avatarMike Lothian <mike@fireburn.co.uk>
      fe2edb25
  22. 09 May, 2018 1 commit
  23. 24 Apr, 2018 1 commit
  24. 20 Mar, 2018 1 commit
  25. 16 Mar, 2018 2 commits
  26. 09 Mar, 2018 2 commits
  27. 02 Mar, 2018 1 commit
    • Thierry Reding's avatar
      loader: Add support for platform and host1x busses · f9bc48d4
      Thierry Reding authored
      ARM SoCs usually have their DRM/KMS devices on the platform bus, so add
      support for this bus in order to allow use of the DRI_PRIME environment
      variable with those devices.
      
      While at it, also support the host1x bus, which is effectively the same
      but uses an additional layer in the bus hierarchy.
      
      Note that it isn't enough to support the bus that has the rendering GPU
      because the loader code will also try to construct an ID path tag for a
      scanout-only device if it is the default that is being opened.
      
      The ID path tag for a device can be obtained by running udevadm info on
      the device node, as shown in this example on NVIDIA Tegra:
      
      	$ udevadm info /dev/dri/card0 | grep ID_PATH_TAG
      	E: ID_PATH_TAG=platform-50000000_host1x
      
      The corresponding OF_FULLNAME property, from which the ID_PATH_TAG is
      constructed, can be found in the sysfs "uevent" attribute for the card0
      device's parent:
      
      	$ grep OF_FULLNAME /sys/devices/platform/50000000.host1x/drm/uevent
      	OF_FULLNAME=/host1x@50000000
      
      Similarily, /dev/dri/card1 corresponds to the GPU:
      
      	$ udevadm info /dev/dri/card1 | grep ID_PATH_TAG
      	E: ID_PATH_TAG=platform-57000000_gpu
      
      and:
      
      	$ grep OF_FULLNAME /sys/devices/platform/57000000.gpu/uevent
      	OF_FULLNAME=/gpu@57000000
      
      Changes in v2:
      - avoid confusing pre-increment in strdup()
      - add examples of tags to commit message
      Reviewed-by: 's avatarEric Engestrom <eric@engestrom.ch>
      Reviewed-by: 's avatarEmil Velikov <emil.velikov@collabora.com>
      Signed-off-by: 's avatarThierry Reding <treding@nvidia.com>
      f9bc48d4
  28. 21 Feb, 2018 3 commits
  29. 20 Feb, 2018 2 commits
  30. 15 Feb, 2018 1 commit
  31. 25 Jan, 2018 1 commit
  32. 20 Jan, 2018 1 commit