1. 26 May, 2017 14 commits
    • Ilia Mirkin's avatar
      nvc0/ir: SHLADD's middle source must be an immediate · 6dd570fa
      Ilia Mirkin authored
      The instruction encodings only allow for immediates. Don't try to
      replace a zero (which is dumb to have in that op in any case) with RZ.
      Signed-off-by: Ilia Mirkin's avatarIlia Mirkin <imirkin@alum.mit.edu>
      Cc: mesa-stable@lists.freedesktop.org
      (cherry picked from commit 82e77d4e)
      6dd570fa
    • Emil Velikov's avatar
      st/va: fix misplaced closing bracket · 33f3ae1d
      Emil Velikov authored
      It's been like this since the code was introduced.
      
      Fixes: 86eb4131 (st/va: add headless support, i.e. VA_DISPLAY_DRM)
      Cc: <mesa-stable@lists.freedesktop.org>
      Cc: Julien Isorce <julien.isorce@gmail.com>
      Signed-off-by: default avatarEmil Velikov <emil.velikov@collabora.com>
      Reviewed-by: default avatarNayan Deshmukh <nayan26deshmukh@gmail.com>
      Reviewed-by: Christian König's avatarChristian König <christian.koenig@amd.com>
      (cherry picked from commit aaea53c2)
      33f3ae1d
    • Nanley Chery's avatar
      i965/formats: Update the three-channel DXT1 mappings · 87d16afa
      Nanley Chery authored
      The procedure for decompressing an opaque DXT1 OpenGL format is
      dependant on the comparison of two colors stored in the first 32 bits of
      the compressed block. Here's the specified OpenGL behavior for
      reference:
      
         The RGB color for a texel at location (x,y) in the block is given by:
      
            RGB0,              if color0 > color1 and code(x,y) == 0
            RGB1,              if color0 > color1 and code(x,y) == 1
            (2*RGB0+RGB1)/3,   if color0 > color1 and code(x,y) == 2
            (RGB0+2*RGB1)/3,   if color0 > color1 and code(x,y) == 3
      
            RGB0,              if color0 <= color1 and code(x,y) == 0
            RGB1,              if color0 <= color1 and code(x,y) == 1
            (RGB0+RGB1)/2,     if color0 <= color1 and code(x,y) == 2
            BLACK,             if color0 <= color1 and code(x,y) == 3
      
      The sampling operation performed on an opaque DXT1 Intel format essentially
      hard-codes the comparison result of the two colors as color0 > color1.
      This means that the behavior is incompatible with OpenGL. This is stated
      in the SKL PRM, Vol 5: Memory Views:
      
         Opaque Textures (DXT1_RGB)
            Texture format DXT1_RGB is identical to DXT1, with the exception that the
            One-bit Alpha encoding is removed. Color 0 and Color 1 are not compared, and
            the resulting texel color is derived strictly from the Opaque Color Encoding.
            The alpha channel defaults to 1.0.
      
            Programming Note
            Context: Opaque Textures (DXT1_RGB)
            The behavior of this format is not compliant with the OGL spec.
      
      The opaque and non-opaque DXT1 OpenGL formats are specified to be
      decoded in exactly the same way except the BLACK value must have a
      transparent alpha channel in the latter. Use the four-channel BC1 Intel
      formats with the alpha set to 1 to provide the behavior required by the
      spec. Note that the alpha is already set to 1 for RGB formats in
      brw_get_texture_swizzle().
      
      v2: Provide a more detailed commit message (Kenneth Graunke).
      v3: Ensure the alpha channel is set to 1 for DXT1 formats.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100925
      Cc: <mesa-stable@lists.freedesktop.org>
      Acked-by: Tapani Pälli <tapani.palli@intel.com> (v1)
      Reviewed-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      Signed-off-by: Nanley Chery's avatarNanley Chery <nanley.g.chery@intel.com>
      (cherry picked from commit 688ddb85)
      [Emil Velikov: attribute for BRW to ISL format rename]
      Signed-off-by: default avatarEmil Velikov <emil.velikov@collabora.com>
      
      Conflicts:
      	src/mesa/drivers/dri/i965/brw_surface_formats.c
      87d16afa
    • Nanley Chery's avatar
      anv/formats: Update the three-channel BC1 mappings · cbd47216
      Nanley Chery authored
      The procedure for decompressing an opaque BC1 Vulkan format is dependant on the
      comparison of two colors stored in the first 32 bits of the compressed block.
      Here's the specified OpenGL (and Vulkan) behavior for reference:
      
         The RGB color for a texel at location (x,y) in the block is given by:
      
            RGB0,              if color0 > color1 and code(x,y) == 0
            RGB1,              if color0 > color1 and code(x,y) == 1
            (2*RGB0+RGB1)/3,   if color0 > color1 and code(x,y) == 2
            (RGB0+2*RGB1)/3,   if color0 > color1 and code(x,y) == 3
      
            RGB0,              if color0 <= color1 and code(x,y) == 0
            RGB1,              if color0 <= color1 and code(x,y) == 1
            (RGB0+RGB1)/2,     if color0 <= color1 and code(x,y) == 2
            BLACK,             if color0 <= color1 and code(x,y) == 3
      
      The sampling operation performed on an opaque DXT1 Intel format essentially
      hard-codes the comparison result of the two colors as color0 > color1. This
      means that the behavior is incompatible with OpenGL and Vulkan. This is stated
      in the SKL PRM, Vol 5: Memory Views:
      
         Opaque Textures (DXT1_RGB)
            Texture format DXT1_RGB is identical to DXT1, with the exception that the
            One-bit Alpha encoding is removed. Color 0 and Color 1 are not compared, and
            the resulting texel color is derived strictly from the Opaque Color Encoding.
            The alpha channel defaults to 1.0.
      
            Programming Note
            Context: Opaque Textures (DXT1_RGB)
            The behavior of this format is not compliant with the OGL spec.
      
      The opaque and non-opaque BC1 Vulkan formats are specified to be decoded in
      exactly the same way except the BLACK value must have a transparent alpha
      channel in the latter. Use the four-channel BC1 Intel formats with the alpha
      set to 1 to provide the behavior required by the spec.
      
      v2 (Kenneth Graunke):
      - Provide a more detailed commit message.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100925
      Cc: <mesa-stable@lists.freedesktop.org>
      Reviewed-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      Signed-off-by: Nanley Chery's avatarNanley Chery <nanley.g.chery@intel.com>
      (cherry picked from commit 56458cb1)
      cbd47216
    • Tom Stellard's avatar
      gallivm: Make sure module has the correct data layout when pass manager runs · ca697dda
      Tom Stellard authored
      The datalayout for modules was purposely not being set in order to work around
      the fact that the ExecutionEngine requires that the module's datalayout
      matches the datalayout of the TargetMachine that the ExecutionEngine is
      using.
      
      When the pass manager runs on a module with no datalayout, it uses
      the default datalayout which is little-endian.  This causes problems
      on big-endian targets, because some optimizations that are legal on
      little-endian or illegal on big-endian.
      
      To resolve this, we set the datalayout prior to running the pass
      manager, and then clear it before creating the ExectionEngine.
      
      This patch fixes a lot of piglit tests on big-endian ppc64.
      
      Cc: mesa-stable@lists.freedesktop.org
      (cherry picked from commit 14e525a4)
      ca697dda
    • chadversary's avatar
      egl: Partially revert 23c86c74, fix eglMakeCurrent · b6ad01c7
      chadversary authored
      Fixes regressions in Android CtsVerifier.apk on Intel Chrome OS devices
      due to incorrect error handling in eglMakeCurrent. See below on how to
      confirm the regression is fixed.
      
      This partially reverts
      
          commit 23c86c74
          Author:  Chad Versace <chadversary@chromium.org>
          Subject: egl: Emit error when EGLSurface is lost
      
      The problem with commit 23c86c74 is that, once an EGLSurface became
      lost, the app could never unbind the bad surface. Each attempt to unbind
      the bad surface with eglMakeCurrent failed with EGL_BAD_CURRENT_SURFACE.
      
      Specificaly, the bad commit added the error handling below. #2 and #3
      were right, but #1 was wrong.
      
          1. eglMakeCurrent emits EGL_BAD_CURRENT_SURFACE if the calling
             thread has unflushed commands and either previous surface is no
             longer valid.
      
          2. eglMakeCurrent emits EGL_BAD_NATIVE_WINDOW if either new surface
             is no longer valid.
      
          3. eglSwapBuffers emits EGL_BAD_NATIVE_WINDOW if the swapped surface
             is no longer valid.
      
      Whe I wrote the bad commit, I misunderstood the EGL spec language
      for #1. The correct behavior is, if I understand correctly now, is
      below. This patch doesn't implement the correct behavior, though, it
      just reverts the broken behavior.
      
          - Assume a bound EGLSurface is no longer valid.
          - Assume the bound EGLContext has unflushed commands.
          - The app calls eglMakeCurrent. The spec requires eglMakeCurrent to
            implicitly flush. After flushing, eglMakeCurrent emits
            EGL_BAD_CURRENT_SURFACE and does *not* alter the thread's
            current bindings.
          - If the app calls eglMakeCurrent again, and the app inserts no
            commands into the GL command stream between the two eglMakeCurrent
            calls, then this second eglMakeCurrent succeeds without emitting an
            error.
      
      How to confirm this fixes the regression:
      
          Download android-cts-verifier-7.1_r5-linux_x86-x86.zip from
          source.android.com, unpack, and `adb install CtsVerifier.apk`.
          Run test "Projection Cube". Click the Pass button (a
          green checkmark). Then run test "Projection Widget". Confirm that
          widgets are visible and that logcat does not complain about
          eglMakeCurrent failure.
      
          Then confirm there are no regressions in the cts-traded module that
          commit 263243b1 fixed:
      
              cts-tf > run cts --skip-preconditions --skip-device-info \
                       -m CtsCameraTestCases \
                       -t android.hardware.camera2.cts.RobustnessTest
      
          Tested with Chrome OS board "reef".
      
      Fixes: 23c86c74 (egl: Emit error when EGLSurface is lost)
      Acked-by: Tapani Pälli's avatarTapani Pälli <tapani.palli@intel.com>
      Cc: "17.1" <mesa-stable@lists.freedesktop.org>
      Cc: Tomasz Figa <tfiga@chromium.org>
      Cc: Nicolas Boichat <drinkcat@chromium.org>
      Cc: Emil Velikov <emil.velikov@collabora.com>
      (cherry picked from commit 8f62d21b)
      b6ad01c7
    • Samuel Iglesias Gonsálvez's avatar
      i965/vec4: load dvec3/4 uniforms first in the push constant buffer · 8be7de22
      Samuel Iglesias Gonsálvez authored
      Reorder the uniforms to load first the dvec4-aligned variables in the
      push constant buffer and then push the vec4-aligned ones. It takes
      into account that the relocated uniforms should be aligned to their
      channel size.
      
      This fixes a bug were the dvec3/4 might be loaded one part on a GRF and
      the rest in next GRF, so the region parameters to read that could break
      the HW rules.
      
      v2:
      - Fix broken logic.
      - Add a comment to explain what should be needed to optimise the usage
        of the push constant buffer slots, as this patch does not pack the
        uniforms.
      
      v3:
      - Implemented the push constant buffer usage optimization.
      Signed-off-by: Samuel Iglesias Gonsálvez's avatarSamuel Iglesias Gonsálvez <siglesias@igalia.com>
      Cc: "17.1" <mesa-stable@lists.freedesktop.org>
      Acked-by: Francisco Jerez's avatarFrancisco Jerez <currojerez@riseup.net>
      (cherry picked from commit e69e5c70)
      8be7de22
    • Samuel Iglesias Gonsálvez's avatar
      i965/vec4: fix swizzle and writemask when loading an uniform with constant offset · b7923353
      Samuel Iglesias Gonsálvez authored
      It was setting XYWZ swizzle and writemask to all uniforms, no matter if they
      were a vector or scalar, so this can lead to problems when loading them
      to the push constant buffer.
      
      Moreover, 'shift' calculation was designed to calculate the offset in
      DWORDS, but it doesn't take into account DFs, so the calculated swizzle
      for the later ones was wrong.
      
      The indirect case is not changed because MOV INDIRECT will write
      to all components. Added an assert to verify that these uniforms
      are aligned.
      
      v2:
      - Fix 'shift' calculation (Curro)
      - Set both swizzle and writemask.
      - Add assert(shift == 0) for the indirect case.
      Signed-off-by: Samuel Iglesias Gonsálvez's avatarSamuel Iglesias Gonsálvez <siglesias@igalia.com>
      Cc: "17.1" <mesa-stable@lists.freedesktop.org>
      Reviewed-by: Francisco Jerez's avatarFrancisco Jerez <currojerez@riseup.net>
      (cherry picked from commit 8aa6ada8)
      b7923353
    • Samuel Iglesias Gonsálvez's avatar
      i965/vec4/gs: restore the uniform values which was overwritten by failed vec4_gs_visitor execution · 98f30c71
      Samuel Iglesias Gonsálvez authored
      We are going to add a packing feature to reduce the usage of the push
      constant buffer. One of the consequences is that 'nr_params' would be
      modified by vec4_visitor's run call, so we need to restore it if one of
      them failed before executing the fallback ones. Same thing happens to the
      uniforms values that would be reordered afterwards.
      
      Fixes GL45-CTS.arrays_of_arrays_gl.InteractionFunctionCalls2 when
      the dvec4 alignment and packing patch is applied.
      Signed-off-by: Samuel Iglesias Gonsálvez's avatarSamuel Iglesias Gonsálvez <siglesias@igalia.com>
      Cc: "17.1" <mesa-stable@lists.freedesktop.org>
      Acked-by: Francisco Jerez's avatarFrancisco Jerez <currojerez@riseup.net>
      (cherry picked from commit 354f7f2c)
      98f30c71
    • Eric Anholt's avatar
      vc4: Don't allocate new BOs to avoid synchronization when they're shared. · b50e9022
      Eric Anholt authored
      If X11 did a software fallback to the entire screen, we would throw out
      the BO the screen is scanning out from and allocate a new one.
      
      Cc: mesa-stable@lists.freedesktop.org
      (cherry picked from commit e8ea42d2)
      b50e9022
    • Hans de Goede's avatar
      glxglvnddispatch: Add missing dispatch for GetDriverConfig · 356b0b2b
      Hans de Goede authored
      Together with some fixes to xdriinfo this fixes xdriinfo not working
      with glvnd.
      
      Since apps (xdriinfo) expect GetDriverConfig to work without going to
      need through the dance to setup a glxcontext (which is a reasonable
      expectation IMHO), the dispatch for this ends up significantly different
      then any other dispatch function.
      
      This patch gets the job done, but I'm not really happy with how this
      patch turned out, suggestions for a better fix are welcome.
      
      Cc: Kyle Brenneman <kbrenneman@nvidia.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarEmil Velikov <emil.velikov@collabora.com>
      Cc: mesa-stable@lists.freedesktop.org
      (cherry picked from commit 84f764a7)
      356b0b2b
    • Pohjolainen, Topi's avatar
      intel/isl/gen7: Use stencil vertical alignment of 8 instead of 4 · 968f0c65
      Pohjolainen, Topi authored
      The reasoning Chad gave in the comment for choosing a valign of 4 is
      entirely bunk.  The fact that you have to multiply pitch by 2 is
      completely unrelated to the halign/valign parameters used for texture
      layout.  (Not completely unrelated.  W-tiling is just Y-tiling with a
      bit of extra swizzling which turns 8x8 W-tiled chunks into 16x4 y-tiled
      chunks so it makes everything easier if miplevels are always aligned to
      8x8.)  The fact that RENDER_SURFACE_STATE::SurfaceVerticalAlignmet
      doesn't have a VALIGN_8 option doesn't matter since this is gen7 and you
      can't do stencil texturing anyway.
      
      v2 (Jason Ekstrand):
       - Delete most of Chad's comment and add a more descriptive commit
         message.
      Signed-off-by: Topi Pohjolainen's avatarTopi Pohjolainen <topi.pohjolainen@intel.com>
      Cc: "17.0 17.1" <mesa-stable@lists.freedesktop.org>
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      Reviewed-by: chadversary's avatarChad Versace <chadversary@chromium.org>
      (cherry picked from commit 236f17a9)
      968f0c65
    • Lucas Stach's avatar
      etnaviv: stop oversizing buffer resources · cebba270
      Lucas Stach authored
      PIPE_BUFFER is a target enum, not a binding. This caused the driver to
      up-align the height of buffer resources, leading to largely oversizing
      those resources. This is especially bad, as the buffer resources used
      by the upload manager are already 1MB in size. Height alignment meant
      that those would result in 4 to 8MB big BOs.
      
      Fixes: c9e8b49b ("etnaviv: gallium driver for Vivante GPUs")
      Cc: mesa-stable@lists.freedesktop.org
      Signed-off-by: Lucas Stach's avatarLucas Stach <l.stach@pengutronix.de>
      Reviewed-By: Wladimir J. van der Laan's avatarWladimir J. van der Laan <laanwj@gmail.com>
      Reviewed-by: Christian Gmeiner's avatarChristian Gmeiner <christian.gmeiner@gmail.com>
      (cherry picked from commit 8173d7d9)
      cebba270
    • Eric Anholt's avatar
      renderonly: Initialize fields of struct winsys_handle. · cb8a159e
      Eric Anholt authored
      vc4 was rejecting renderonly's import, because the offset field was
      nonzero.
      
      Fixes: 848b49b2 ("gallium: add renderonly library")
      Cc: mesa-stable@lists.freedesktop.org
      Signed-off-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Christian Gmeiner's avatarChristian Gmeiner <christian.gmeiner@gmail.com>
      (cherry picked from commit c98f03c6)
      cb8a159e
  2. 12 May, 2017 26 commits