1. 23 Oct, 2018 1 commit
  2. 05 Oct, 2018 1 commit
  3. 28 Sep, 2018 1 commit
    • Adam Jackson's avatar
      glamor_egl: Don't initialize on llvmpipe · 0a9415cf
      Adam Jackson authored
      Mesa started supporting GL_OES_EGL_image on llvmpipe in 17.3, after this
          commit bbdeddd5fd0b797e1e281f058338b3da4d98029d
          Author: Gurchetan Singh <gurchetansingh@chromium.org>
          Date:   Tue Aug 1 14:49:33 2017 -0700
              st/dri: add drisw image extension
      That's pretty cool, but it means glamor now thinks it can initialize on
      llvmpipe. This is almost certainly not what anyone wants, as glamor on
      llvmpipe is pretty much uniformly slower than fb.
      This fixes both Xorg and Xwayland to refuse glamor in such a setup.
      Xephyr is left alone, both because glamor is not the default there and
      because Xephyr+glamor+llvmpipe is one of the easier ways to get xts to
      exercise glamor.
      The (very small) downside of this change is that you lose DRI3 support.
      This wouldn't have helped you very much (since an lp glamor blit is
      slower than a pixman blit), but it would eliminate the PutImage overhead
      for llvmpipe's glXSwapBuffers. A future change should add DRI3 support
      for the fb-only case.
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
  4. 12 Sep, 2018 1 commit
  5. 11 Sep, 2018 2 commits
  6. 07 Sep, 2018 1 commit
  7. 27 Jun, 2018 2 commits
    • Thomas Hellstrom's avatar
      glamor: Work around GEM usage v2 · 9f02855e
      Thomas Hellstrom authored
      KMS drivers are not required to support GEM. In particular, vmwgfx
      doesn't support flink and handles and names are identical.
      Getting a bo name should really be part of a lower level API, if needed,
      but in the mean time work around this by setting the name identical to
      the handle if GEM isn't supported.
      This fixes modesetting driver dri2 on vmwgfx.
      Reviewed-by: default avatarDeepak Rawat <drawat@vmware.com>
      Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
    • Lyude Paul's avatar
      glamor: Unbreak glamor_fd_from_pixmap() · 186a21c4
      Lyude Paul authored
      When support for allocating GBM BOs with modifiers was added,
      glamor_fd_from_pixmap() was changed so that it would return an error if
      it got a bo with modifiers set from glamor_fds_from_pixmap(). The
      problem is that on systems that support BOs with modifiers,
      glamor_fds_from_pixmap() will always return BOs with modifiers.
      This means that glamor_fd_from_pixmap() was broken entirely, which broke
      a number of other things including glamor_shareable_fd_from_pixmap(),
      which meant that modesetting using multiple GPUs with the modesetting
      DDX was also broken. Easy reproducer:
      - Find a laptop with DRI prime that has outputs connected to the
        dedicated GPU and integrated GPU
      - Try to enable one display on each using the modesetting DDX
      - Fail
      Since there isn't a way to ask for no modifiers from
      glamor_fds_from_pixmap, we create a shared _glamor_fds_from_pixmap()
      function used by both glamor_fds_from_pixmap() and
      glamor_fd_from_pixmap() that calls down to the appropriate
      glamor_egl_fd*_from_pixmap() function.
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
      Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
      Fixes: c8c276c9 ("glamor: Implement PixmapFromBuffers and BuffersFromPixmap")
  8. 07 Jun, 2018 1 commit
  9. 28 May, 2018 1 commit
  10. 23 May, 2018 1 commit
  11. 16 May, 2018 1 commit
    • Lukas F. Hartmann's avatar
      glamor_init: clamp GLSL to 120 if platform doesn't have instanced arrays · 7437b6db
      Lukas F. Hartmann authored
      I upgraded Xwayland and the assorted libraries from git masters today,
      and noticed that glamor wouldn't work anymore on i.MX6/etnaviv. The
      error was:
      No provider of glVertexAttribDivisor found.  Requires one of:
          Desktop OpenGL 3.3
          OpenGL ES 3.0
          GL extension "GL_ANGLE_instanced_arrays"
          GL extension "GL_ARB_instanced_arrays"
          GL extension "GL_EXT_instanced_arrays"
          GL extension "GL_NV_instanced_arrays"
      The problem is that etnaviv offers GLSL 140 on GL 2.1 and glamor
      rendering assumes that glVertexAttribDivisor() is always available on
      GLSL>=130, which is not the case here. Forcing GLSL 120 makes glamor
      work fine again on this platform. After chatting with ajax in
      #xorg-devel, the following solution was proposed.
      This is my first time of submitting a patch, so please excuse me and
      advise if I'm doing it wrong ;)
      Lukas (mntmn)
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
  12. 08 May, 2018 2 commits
  13. 30 Apr, 2018 1 commit
  14. 17 Apr, 2018 1 commit
  15. 10 Apr, 2018 4 commits
  16. 04 Apr, 2018 5 commits
  17. 02 Apr, 2018 1 commit
  18. 28 Mar, 2018 1 commit
  19. 21 Mar, 2018 1 commit
  20. 09 Mar, 2018 1 commit
  21. 06 Mar, 2018 1 commit
  22. 05 Mar, 2018 3 commits
  23. 27 Feb, 2018 3 commits
  24. 26 Feb, 2018 2 commits
  25. 29 Jan, 2018 1 commit