1. 15 Feb, 2018 1 commit
  2. 18 Jan, 2018 2 commits
  3. 09 Jan, 2018 1 commit
  4. 08 Jan, 2018 1 commit
  5. 21 Dec, 2017 2 commits
  6. 14 Dec, 2017 1 commit
  7. 08 Dec, 2017 2 commits
  8. 29 Nov, 2017 2 commits
  9. 13 Nov, 2017 1 commit
  10. 20 Oct, 2017 1 commit
  11. 19 Oct, 2017 3 commits
  12. 16 Oct, 2017 1 commit
  13. 12 Oct, 2017 1 commit
  14. 10 Oct, 2017 4 commits
    • Eric Anholt's avatar
      mesa: Implement a new GL_MESA_tile_raster_order extension. · e6764348
      Eric Anholt authored
      The intent is to use this extension on vc4 to allow X11 to do overlapping
      CopyArea() within a pixmap without first blitting the pixmap to a
      temporary.  With associated glamor patches, improves x11perf
      -copywinwin100 performance on a Raspberry Pi 3 from ~4700/sec to
      ~5130/sec, and is an even larger boost to uncomposited window movement
      performance (most copywinwin100 copies don't overlap).
      v2: Fix glIsEnabled() on the new enums.
      v3: Drop the local spec since I'm upstreaming the spec.
      Reviewed-by: default avatarNicolai Hähnle <nicolai.haehnle@amd.com>
    • Eric Anholt's avatar
    • Eric Anholt's avatar
      docs: Fix a typo in the old MESA_program_debug spec. · 9ab0d830
      Eric Anholt authored
      Noticed that we had two 0x8bb4 in the spec while grepping to find an open
      slot in the MESA enums set.  gl.xml had the right value.
      Acked-by: default avatarNicolai Hähnle <nicolai.haehnle@amd.com>
    • Eric Anholt's avatar
      mesa: Expose GL_OES_required_internalformat on GLES contexts. · c16a7443
      Eric Anholt authored
      This extension is effectively a backport of GLES3's internalformat
      handling to GLES 1/2.  It guarantees that sized internalformats specified
      for textures and renderbuffers have at least the specified size stored.
      That's a pretty minimal requirement, so I think it can be dummy_true and
      exposed as a standard in Mesa.
      As a side effect, it also allows GL_RGB565 to be specified as a texture
      format, not just as a renderbuffer.  Mesa had previously been allowing 565
      textures, which angered DEQP in the absence of this extension being
      v2: Allow 2101010rev with sized internalformats even on GLES3, citing the
          extension spec.  Extend extension checks for GLES2 contexts exposing
          with texture_float, texture_half_float, and texture_rg.
      v4: Mark GL_RGB10 non-color-renderable on ES, fix A/L/LA errors on GLES2
          with float formats.
      Reviewed-by: default avatarNicolai Hähnle <nicolai.haehnle@amd.com>
  15. 05 Oct, 2017 1 commit
    • Adam Jackson's avatar
      egl: Simplify the "driver" interface · b174a1ae
      Adam Jackson authored
      "Driver" isn't a great word for what this layer is, it's effectively a
      build-time choice about what OS you're targeting. Despite that both of
      the extant backends totally ignore the display argument, the old code
      would only set up the backend relative to a display.
      That causes problems! One problem is it means eglGetProcAddress can
      generate X or Wayland protocol when it tries to connect to a default
      display so it can call into the backend, which is, you know, completely
      bonkers. Any other EGL API that doesn't reference a display, like
      EGL_EXT_device_query, would have the same issue.
      Fortunately this is a problem that can be solved with the delete key.
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
  16. 03 Oct, 2017 2 commits
  17. 02 Oct, 2017 3 commits
  18. 25 Sep, 2017 3 commits
  19. 20 Sep, 2017 1 commit
    • Roland Scheidegger's avatar
      llvmpipe, gallivm: implement lod queries (LODQ opcode) · 88662696
      Roland Scheidegger authored
      This uses all the existing code to calculate lod values for mip linear
      filtering. Though we'll have to disable the simplifications (if we know some
      parts of the lod calculation won't actually matter for filtering purposes due
      to mip clamps etc.). For better or worse, we'll also disable lod calculation
      hacks (mostly should make a difference for cube maps) always - the issue with
      per-pixel lod being difficult is mostly because we then have different mipmaps
      needed for the actual texel fetch, which isn't a problem with lodq.
      We still use approximation for the log2 - for that reason I believe the float
      part of the lod is only accurate to about 4-5 bits (and one bit less with 1d
      textures actually) which is hopefully good enough (though d3d10 technically
      requires 6 bits - could use quadratic interpolation instead of linear to get
      8 bits or so).
      Since lodq requires unclamped lod, we also have to move some sampler key
      calculations to texture sampling code - even if we know we're going to access
      mipmap 0 we still have to calculate lod and apply lod_bias for lodq.
      Passes piglit ARB_texture_query_lod tests (after having fixed the test).
      Reviewed-by: Jose Fonseca's avatarJose Fonseca <jfonseca@vmware.com>
  20. 17 Sep, 2017 4 commits
  21. 16 Sep, 2017 2 commits
  22. 13 Sep, 2017 1 commit
    • Kenneth Graunke's avatar
      i965: Add an INTEL_DEBUG=submit option for printing batch statistics. · edfd8d42
      Kenneth Graunke authored
      When a batch is submitted, INTEL_DEBUG=bat prints a message indicating
      which part of the code triggered the flush, and some statistics about
      the batch/state buffer utilization.
      It also decodes the batchbuffer in debug builds...which is so much
      output that it drowns out the utilization messages, if that's all you
      care about.
      INTEL_DEBUG=submit now just does the utilization messages.
      INTEL_DEBUG=bat continues to do both (as the message is a good indicator
      that we're starting decode of a new batch).
      v2: Rename from "flush" to "submit" (suggested by Chris) because we
          might want "flush" for PIPE_CONTROL debugging someday.
      Reviewed-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>