1. 10 Oct, 2017 2 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>
      e6764348
    • Eric Anholt's avatar
      mesa: Only expose GLES's EXT_texture_type_2_10_10_10_REV if supported in HW. · cee5585d
      Eric Anholt authored
      Previously, we were downconverting to 8888 automatically if the hardware
      didn't suport it.  However, with the advent of
      GL_OES_required_internalformat, we have to actually store the
      internalformats we advertise support for.  And, it seems rather
      disingenuous to advertise the extension if we don't actually support it.
      
      v2: Throw an error when using the format on ES2 without the extension present.
      Reviewed-by: default avatarNicolai Hähnle <nicolai.haehnle@amd.com>
      cee5585d
  2. 03 Oct, 2017 1 commit
  3. 05 Sep, 2017 8 commits
  4. 25 Aug, 2017 2 commits
  5. 22 Aug, 2017 2 commits
  6. 06 Aug, 2017 4 commits
  7. 03 Aug, 2017 1 commit
    • Brian Paul's avatar
      st/mesa: fix handling of NumSamples=1 (v2) · 6839d336
      Brian Paul authored
      In Mesa we use the convention that if gl_renderbuffer::NumSamples
      or gl_texture_image::NumSamples is zero, it's a non-MSAA surface.
      Otherwise, it's an MSAA surface.  But in gallium nr_samples=1 is a
      non-MSAA surface.
      
      Before, if the user called glRenderbufferStorageMultisample() or
      glTexImage2DMultisample() with samples=1 we skipped the search for the
      next higher number of supported samples and asked the gallium driver to
      create a surface with nr_samples=1.  So we got a non-MSAA surface.
      This failed to meet the expection of the user making those calls.
      
      This patch changes the sample count checks in st_AllocTextureStorage()
      and st_renderbuffer_alloc_storage() to test for samples > 0 instead of > 1.
      And we now start querying for MSAA support at samples=2 since gallium has
      no concept of a 1x MSAA surface.
      
      A specific example of this problem is the Piglit arb_framebuffer_srgb-blit
      test.  It calls glRenderbufferStorageMultisample() with samples=1 to
      request an MSAA renderbuffer with the minimum supported number of MSAA
      samples.  Instead of creating a 4x or 8x, etc. MSAA surface, we wound up
      creating a non-MSAA surface.
      
      Finally, add a comment on the gl_renderbuffer::NumSamples field.
      
      There is one piglit regression with the VMware driver:
      ext_framebuffer_multisample-blit-mismatched-formats fails because
      now we're actually creating 4x MSAA surfaces (the requested sample
      count is 1) and we're hitting some sort of bug in the blitter code.  That
      will have to be fixed separately.  Other drivers may find regressions
      too now that MSAA surfaces are really being created.
      
      v2: start quering for MSAA support with samples=2 instead of 1.
      Reviewed-by: default avatarRoland Scheidegger <sroland@vmware.com>
      Reviewed-by: default avatarMarek Olšák <marek.olsak@amd.com>
      6839d336
  8. 28 Jul, 2017 1 commit
  9. 26 Jul, 2017 1 commit
  10. 21 Jun, 2017 16 commits
  11. 15 Jun, 2017 1 commit
  12. 14 Jun, 2017 1 commit