Skip to content
Snippets Groups Projects
  1. Jun 01, 2017
  2. May 31, 2017
  3. May 26, 2017
    • Daniel Stone's avatar
      egl/wayland: Ensure we get a back buffer · 8008bc8c
      Daniel Stone authored and Emil Velikov's avatar Emil Velikov committed
      
      Commit 9ca6711f changed the Wayland winsys to only block for the
      frame callback inside SwapBuffers, rather than get_back_bo. get_back_bo
      would perform a single non-blocking Wayland event dispatch, to try to
      find any release events which we had pulled off the wire but not
      actually processed. The blocking dispatch was moved to SwapBuffers.
      
      This removed a guarantee that we would've processed all events inside
      get_back_bo(), and introduced a failure whereby the server could've sent
      a buffer release event, but we wouldn't have read it. In clients
      unconstrained by SwapInterval (rendering ~as fast as possible), which
      were being displayed directly without composition (buffer release delayed),
      this could lead to get_back_bo() failing because there were no free
      buffers available to it.
      
      The drawing rightly failed, but this was papered over because of the
      path in eglSwapBuffers() which attempts to guarantee a BO, in order to
      support calling SwapBuffers twice in a row with no rendering actually
      having been performed.
      
      Since eglSwapBuffers will perform a blocking dispatch of Wayland
      events, a buffer release would have arrived by that point, and we
      could then choose a buffer to post to the server. The effect was that
      frames were displayed out-of-order, since we grabbed a frame with random
      past content to display to the compositor.
      
      Ideally get_back_bo() failing should store a failure flag inside the
      surface and cause the next SwapBuffers to fail, but for the meantime,
      restore the correct behaviour such that get_back_bo() no longer fails.
      
      Signed-off-by: default avatarDaniel Stone <daniels@collabora.com>
      Reported-by: default avatarEero Tamminen <eero.t.tamminen@intel.com>
      Acked-by: default avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98833
      Fixes: 9ca6711f ("Revert "wayland: Block for the frame callback in get_back_bo not dri2_swap_buffers"")
      (cherry picked from commit 1f2d0093)
      8008bc8c
    • Daniel Stone's avatar
      egl/wayland: Use per-surface event queues · ff3aa6a8
      Daniel Stone authored and Emil Velikov's avatar Emil Velikov committed
      
      During display initialisation, we need a separate event queue to handle
      the registry events, which is correctly handled. But we also need
      separate per-surface event queues to handle swapchain-related events,
      such as surface frame events and buffer release events. This avoids two
      surfaces from the same EGLDisplay, both current on separate threads,
      dispatching each other's events.
      
      Create separate per-surface event queues, create wl_surface and wl_drm
      proxy wrapper objects per surface, so we eliminate the race around
      sending events to the wrong queue. swrast buffers do not need a
      dedicated proxy wrapper, as the wl_shm_pool used to create the
      wl_buffers, being transient, can itself be assigned to a queue.
      
      Signed-off-by: default avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: default avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Fixes: 36b9976e ("egl/wayland: Avoid race conditions when on non-main thread")
      Cc: mesa-stable@lists.freedesktop.org
      (cherry picked from commit 03dd9a88)
      
      Squashed with:
      
      egl/wayland: verify event queue was allocated
      
      We're already verified that 'window' wasn't NULL, I'm guessing this
      allocation error is about the newly created queue.
      
      CID: 1409754
      Fixes: 03dd9a88 ("egl/wayland: Use per-surface event queues")
      Signed-off-by: default avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Reviewed-by: default avatarDaniel Stone <daniels@collabora.com>
      (cherry picked from commit 30dc56bb)
      ff3aa6a8
    • Daniel Stone's avatar
      egl/wayland: Don't open-code roundtrip · 701a10b5
      Daniel Stone authored and Emil Velikov's avatar Emil Velikov committed
      
      wl_display_roundtrip_queue() exists and can replace roundtrip(). The
      API was introduced with wayland 1.6, while we currently require 1.11.
      
      Signed-off-by: default avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: default avatarEmil Velikov <emil.velikov@collabora.com>
      Reviewed-by: default avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Cc: mesa-stable@lists.freedesktop.org
      (cherry picked from commit 8118bc26)
      701a10b5
    • Daniel Stone's avatar
      vulkan/wsi/wayland: Use proxy wrappers for swapchain · afbe5bf4
      Daniel Stone authored and Emil Velikov's avatar Emil Velikov committed
      
      Though most swapchain operations used a queue, they were racy in that
      the object was created with the queue only set later, meaning that its
      event could potentially be dispatched from the default queue in between
      these two steps.
      
      Use proxy wrappers to avoid this race, also assigning wl_buffers created
      for the swapchain to the event queue.
      
      Signed-off-by: default avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: default avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Cc: mesa-stable@lists.freedesktop.org
      (cherry picked from commit 5034c615)
      [Emil Velikov: wsi_wl_swapchain is missing surface_version, move image_count]
      Signed-off-by: default avatarEmil Velikov <emil.velikov@collabora.com>
      
      Conflicts:
      	src/vulkan/wsi/wsi_common_wayland.c
      
      Squahed with:
      
      vulkan/wsi/wayland: Fix proxy wrappers for swapchain recreation
      
      Before the swapchain event queue is destroyed, all proxy objects that reference
      it must be dropped. Otherwise we risk a use-after-free if a frame callback event
      or buffer release events are received afterwards.
      This happens when an application destroys and recreates a swapchain in FIFO
      mode between two frames without using the VkSwapchainCreateInfoKHR::oldSwapchain
      mechanism to keep the old swapchain until after the next redraw.
      
      Fixes: 5034c615 ("vulkan/wsi/wayland: Use proxy wrappers for swapchain")
      Signed-off-by: Philipp Zabel's avatarPhilipp Zabel <philipp.zabel@gmail.com>
      Reviewed-by: default avatarDaniel Stone <daniels@collabora.com>
      Cc: mesa-stable@lists.freedesktop.org
      (cherry picked from commit 1586768e)
      [Emil Velikov: image_count is not in base]
      Signed-off-by: default avatarEmil Velikov <emil.velikov@collabora.com>
      
      Conflicts:
      	src/vulkan/wsi/wsi_common_wayland.c
      afbe5bf4
    • Daniel Stone's avatar
      vulkan/wsi/wayland: Use per-display event queue · 55e66999
      Daniel Stone authored and Emil Velikov's avatar Emil Velikov committed
      
      Calling random callbacks on the display's event queue is hostile, as
      we may call into client code when it least expects it. Create our own
      event queue, one per wsi_wl_display, and use that for the registry.
      
      Signed-off-by: default avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: default avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Cc: mesa-stable@lists.freedesktop.org
      (cherry picked from commit c902a195)
      55e66999
    • Daniel Stone's avatar
      vulkan/wsi/wayland: Remove roundtrip when creating image · f7cc55dc
      Daniel Stone authored and Emil Velikov's avatar Emil Velikov committed
      
      There's no need to call wl_display_roundtrip() after trying to create a
      buffer through wl_drm; if it succeeds then everything is fine, and if it
      fails, then we get a fatal protocol error so can't recover anyway.
      
      Additionally, doing a roundtrip on the default / main application queue,
      is destructive anyway, so would need to be its own queue.
      
      Signed-off-by: default avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: default avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Cc: mesa-stable@lists.freedesktop.org
      (cherry picked from commit afe8c8a2)
      f7cc55dc
    • Daniel Stone's avatar
      vulkan: Fix Wayland uninitialised registry · b4a82e7f
      Daniel Stone authored and Emil Velikov's avatar Emil Velikov committed
      
      Untangle the exit cleanup paths so we don't try to use the registry
      variable before it's been initialised.
      
      Signed-off-by: default avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: default avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Cc: mesa-stable@lists.freedesktop.org
      (cherry picked from commit d9a8bba7)
      b4a82e7f
    • Ilia Mirkin's avatar
      nvc0/ir: SHLADD's middle source must be an immediate · 6dd570fa
      Ilia Mirkin authored and Emil Velikov's avatar Emil Velikov committed
      
      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: default 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: default 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 and Emil Velikov's avatar Emil Velikov committed
      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: default 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 and Emil Velikov's avatar Emil Velikov committed
      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: default avatarJason Ekstrand <jason@jlekstrand.net>
      Signed-off-by: default 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 and Emil Velikov's avatar Emil Velikov committed
      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
    • Lina Versace's avatar
      egl: Partially revert 23c86c74, fix eglMakeCurrent · b6ad01c7
      Lina Versace authored and Emil Velikov's avatar Emil Velikov committed
      
      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: default 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 and Emil Velikov's avatar Emil Velikov committed
      
      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: default avatarSamuel Iglesias Gonsálvez <siglesias@igalia.com>
      Cc: "17.1" <mesa-stable@lists.freedesktop.org>
      Acked-by: default 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 and Emil Velikov's avatar Emil Velikov committed
      
      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: default avatarSamuel Iglesias Gonsálvez <siglesias@igalia.com>
      Cc: "17.1" <mesa-stable@lists.freedesktop.org>
      Reviewed-by: default 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 and Emil Velikov's avatar Emil Velikov committed
      
      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: default avatarSamuel Iglesias Gonsálvez <siglesias@igalia.com>
      Cc: "17.1" <mesa-stable@lists.freedesktop.org>
      Acked-by: default avatarFrancisco Jerez <currojerez@riseup.net>
      (cherry picked from commit 354f7f2c)
      98f30c71
    • Emma Anholt's avatar
      vc4: Don't allocate new BOs to avoid synchronization when they're shared. · b50e9022
      Emma Anholt authored and Emil Velikov's avatar Emil Velikov committed
      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 and Emil Velikov's avatar Emil Velikov committed
      
      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
    • Topi Pohjolainen's avatar
      intel/isl/gen7: Use stencil vertical alignment of 8 instead of 4 · 968f0c65
      Topi Pohjolainen authored and Emil Velikov's avatar Emil Velikov committed
      
      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: default avatarTopi Pohjolainen <topi.pohjolainen@intel.com>
      Cc: "17.0 17.1" <mesa-stable@lists.freedesktop.org>
      Reviewed-by: default avatarJason Ekstrand <jason@jlekstrand.net>
      Reviewed-by: default avatarChad Versace <chadversary@chromium.org>
      (cherry picked from commit 236f17a9)
      968f0c65
    • Lucas Stach's avatar
      etnaviv: stop oversizing buffer resources · cebba270
      Lucas Stach authored and Emil Velikov's avatar Emil Velikov committed
      
      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: default avatarLucas Stach <l.stach@pengutronix.de>
      Reviewed-By: default avatarWladimir J. van der Laan <laanwj@gmail.com>
      Reviewed-by: default avatarChristian Gmeiner <christian.gmeiner@gmail.com>
      (cherry picked from commit 8173d7d9)
      cebba270
    • Emma Anholt's avatar
      renderonly: Initialize fields of struct winsys_handle. · cb8a159e
      Emma Anholt authored and Emil Velikov's avatar Emil Velikov committed
      
      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: default avatarEric Anholt <eric@anholt.net>
      Reviewed-by: default avatarChristian Gmeiner <christian.gmeiner@gmail.com>
      (cherry picked from commit c98f03c6)
      cb8a159e
  4. May 12, 2017
Loading