1. 18 May, 2018 2 commits
  2. 11 May, 2018 5 commits
  3. 10 May, 2018 10 commits
  4. 09 May, 2018 3 commits
  5. 08 May, 2018 6 commits
  6. 07 May, 2018 1 commit
  7. 04 May, 2018 1 commit
  8. 03 May, 2018 6 commits
    • Neil Roberts's avatar
      spirv: Apply OriginUpperLeft to FragCoord · d90d4e61
      Neil Roberts authored
      This behaviour was changed in 1e5b09f4
      . The commit message
      for that says it is just a “tidy up” so my assumption is that the
      behaviour change was a mistake. It’s a little hard to decipher looking
      at the diff, but the previous code before that patch was:
        if (builtin == SpvBuiltInFragCoord || builtin == SpvBuiltInSamplePosition)
           nir_var->data.origin_upper_left = b->origin_upper_left;
        if (builtin == SpvBuiltInFragCoord)
           nir_var->data.pixel_center_integer = b->pixel_center_integer;
      After the patch the code was:
        case SpvBuiltInSamplePosition:
           nir_var->data.origin_upper_left = b->origin_upper_left;
           /* fallthrough */
        case SpvBuiltInFragCoord:
           nir_var->data.pixel_center_integer = b->pixel_center_integer;
      Before the patch origin_upper_left affected both builtins and
      pixel_center_integer only affected FragCoord. After the patch
      origin_upper_left only affects SamplePosition and pixel_center_integer
      affects both variables.
      This patch tries to restore the previous behaviour by changing the
      code to:
        case SpvBuiltInFragCoord:
           nir_var->data.pixel_center_integer = b->pixel_center_integer;
           /* fallthrough */
        case SpvBuiltInSamplePosition:
           nir_var->data.origin_upper_left = b->origin_upper_left;
      This change will be important for ARB_gl_spirv which is meant to
      support OriginLowerLeft.
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      Reviewed-by: Anuj Phogat's avatarAnuj Phogat <anuj.phogat@gmail.com>
      Fixes: 1e5b09f4 "spirv: Tidy some repeated if checks..."
      (cherry picked from commit e17d0ccb)
    • Deepak Rawat's avatar
      egl/x11: Send invalidate to driver on copy_region path in swap_buffer · cd1435aa
      Deepak Rawat authored
      Similar to swap_available path send invalidate to the driver because
      egl/X11 is not watching for for server's invalidate events. The
      dri2_copy_region path is trigerred when server supports DRI2 version
      minor 1.
      Tested with piglit egl tests for regression.
      V2: Move invalidate from dri2_copy_region to swap_buffer common.
      Cc: <mesa-stable@lists.freedesktop.org>
      Signed-off-by: default avatarDeepak Rawat <drawat@vmware.com>
      Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Acked-by: Michel Dänzer's avatarMichel Dänzer <michel.daenzer@amd.com>
      (cherry picked from commit 9a21c961)
    • José María Casanova Crespo's avatar
      intel/compiler: fix brw_imm_w for negative 16-bit integers · 0d15a443
      José María Casanova Crespo authored
      16-bit immediates need to replicate the 16-bit immediate value
      in both words of the 32-bit value. This needs to be careful
      to avoid sign-extension, which the previous implementation was
      not handling properly.
      For example, with the previous implementation, storing the value
      -3 would generate imm.d = 0xfffffffd due to signed integer sign
      extension, which is not correct. Instead, we should cast to
      uint16_t, which gives us the correct result: imm.ud = 0xfffdfffd.
      We only had a couple of cases hitting this path in the driver
      until now, one with value -1, which would work since all bits are
      one in this case, and another with value -2 in brw_clip_tri(),
      which would hit the aforementioned issue (this case only affects
      gen4 although we are not aware of whether this was causing an
      actual bug somewhere).
      v2: Make explicit uint32_t casting for left shift (Jason Ekstrand)
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      Cc: "18.0 18.1" <mesa-stable@lists.freedesktop.org>
      (cherry picked from commit f0e6dace)
    • José María Casanova Crespo's avatar
      intel/compiler: fix 16-bit int brw_negate_immediate and brw_abs_immediate · 1e5c3fa2
      José María Casanova Crespo authored
      From Intel Skylake PRM, vol 07, "Immediate" section (page 768):
      "For a word, unsigned word, or half-float immediate data,
      software must replicate the same 16-bit immediate value to both
      the lower word and the high word of the 32-bit immediate field
      in a GEN instruction."
      This fixes the int16/uint16 negate and abs immediates that weren't
      taking into account the replication in lower and upper words.
      v2: Integer cases are different to Float cases. (Jason Ekstrand)
          Included reference to PRM (Jose Maria Casanova)
      v3: Make explicit uint32_t casting for left shift (Jason Ekstrand)
          Split half float implementation. (Jason Ekstrand)
          Fix brw_abs_immediate (Jose Maria Casanova)
      Cc: "18.0 18.1" <mesa-stable@lists.freedesktop.org>
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      (cherry picked from commit 2a76f03c)
    • Bas Nieuwenhuizen's avatar
      radv: Don't check the incoming apiVersion on CreateInstance. · 57aebd42
      Bas Nieuwenhuizen authored
      This fixes
      CC: 18.1 <mesa-stable@lists.freedesktop.org>
      Reviewed-by: Samuel Pitoiset's avatarSamuel Pitoiset <samuel.pitoiset@gmail.com>
      (cherry picked from commit 467c562a)
    • Bas Nieuwenhuizen's avatar
      radv: Allow vkEnumerateInstanceVersion ProcAddr without instance. · e334caa4
      Bas Nieuwenhuizen authored
      Apparently the somewhere between 1.1.70 and 1.1.73 the loader started
      depending on this. The loader then creates a 1.0 instance, which gets
      into funny situation because we have a 1.1 device.
      No idea how to do line wrapping in Mako though, my random guesses
      did not work.
      CC: 18.1 <mesa-stable@lists.freedesktop.org>
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      (cherry picked from commit 9267ff98)
  9. 02 May, 2018 3 commits
  10. 01 May, 2018 2 commits
  11. 30 Apr, 2018 1 commit
    • Leo Liu's avatar
      st/omx/enc: fix blit setup for YUV LoadImage · 7a1f220b
      Leo Liu authored
      The blit here involves scaling since it's copying from I8 format to R8G8 format.
      Half of source will be filtered out with PIPE_TEX_FILTER_NEAREST instruction, it
      looks that GPU always uses the second half as source. Currently we use "1" as
      the start point of x for R, then causing 1 source pixel of U component shift to
      right. So "-1" should be the start point for U component.
      Cc: 18.0 18.1 <mesa-stable@lists.freedesktop.org>
      Reviewed-by: default avatarMarek Olšák <marek.olsak@amd.com>
      (cherry picked from commit 1c5f4f4e)