1. 18 Nov, 2020 1 commit
  2. 03 Nov, 2020 1 commit
  3. 22 Sep, 2020 2 commits
  4. 20 Jul, 2020 1 commit
  5. 18 May, 2020 1 commit
  6. 13 May, 2020 1 commit
  7. 07 May, 2020 1 commit
  8. 28 Apr, 2020 1 commit
  9. 10 Feb, 2020 1 commit
  10. 04 Jan, 2020 1 commit
  11. 14 Nov, 2019 1 commit
  12. 28 Oct, 2019 1 commit
  13. 23 Jul, 2019 1 commit
  14. 20 Mar, 2019 1 commit
    • Kenneth Graunke's avatar
      gallium: Add PIPE_BARRIER_UPDATE_BUFFER and UPDATE_TEXTURE bits. · 220c1dce
      Kenneth Graunke authored
      The glMemoryBarrier() function makes shader memory stores ordered with
      respect to things specified by the given bits.  Until now, st/mesa has
      saying that drivers should implicitly perform the needed flushing.
      This seems like a pretty big assumption to make.  Instead, this commit
      opts to translate them to new PIPE_BARRIER bits, and adjusts existing
      drivers to continue ignoring them (preserving the current behavior).
      The i965 driver performs actions on these memory barriers.  Shader
      memory stores go through a "data cache" which is separate from the
      render cache and other read caches (like the texture cache).  All
      memory barriers need to flush the data cache (to ensure shader memory
      stores are visible), and possibly invalidate read caches (to ensure
      stale data is no longer visible).  The driver implicitly flushes for
      most caches, but not for data cache, since ARB_shader_image_load_store
      introduced MemoryBarrier() precisely to order these explicitly.
      I would like to follow i965's approach in iris, flushing the data cache
      on any MemoryBarrier() call, so I need st/mesa to actually call the
      pipe->memory_barrier() callback.
      Fixes KHR-GL45.shader_image_load_store.advanced-sync-textureUpdate
      and Piglit's spec/arb_shader_image_load_store/host-mem-barrier on
      the iris driver.
      Roland said this looks reasonable to him.
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
  15. 19 Nov, 2018 1 commit
  16. 06 Nov, 2018 1 commit
  17. 21 Aug, 2018 1 commit
    • Dave Airlie's avatar
      r600/eg: rework atomic counter emission with flushes · 32529e60
      Dave Airlie authored
      With the current code, we didn't do the space checks prior
      to atomic counter setup emission, but we also didn't add
      atomic counters to the space check so we could get a flush
      later as well.
      These flushes would be bad, and lead to problems with
      parallel tests. We have to ensure the atomic counter copy in,
      draw emits and counter copy out are kept in the same command
      submission unit.
      This reworks the code to drop some useless masks, make the
      counting separate to the emits, and make the space checker
      handle atomic counter space.
      [airlied: want this in 18.2]
      Fixes: 06993e4e (r600: add support for hw atomic counters. (v3))
  18. 17 Jul, 2018 1 commit
  19. 05 Jul, 2018 1 commit
    • Gert Wollny's avatar
      r600: compare structure elements instead of doing a memcmp · 806a42fc
      Gert Wollny authored
      Structures might be padded by the compiler and these padding bytes remain
      un-initialized which in turn makes memcmp return a difference where from
      the logical point of view there is none.
       Fixes valgrind:
           Conditional jump or move depends on uninitialised value(s)
             at 0x4C32CBA: __memcmp_sse4_1 (vg_replace_strmem.c:1099)
             by 0xB8D2537: r600_set_vertex_buffers (r600_state_common.c:573)
             by 0xB71D44A: u_vbuf_set_driver_vertex_buffers (u_vbuf.c:1129)
             by 0xB71F7BB: u_vbuf_draw_vbo (u_vbuf.c:1153)
             by 0xB3B92CB: st_draw_vbo (st_draw.c:235)
             by 0xB36B1AE: vbo_draw_arrays (vbo_exec_array.c:391)
             by 0xB36BB0D: vbo_exec_DrawArrays (vbo_exec_array.c:550)
             by 0x10A989: piglit_display (textureSize.c:157)
             by 0x4F8F174: run_test (piglit_fbo_framework.c:52)
             by 0x4F7BA12: piglit_gl_test_run (piglit-framework-gl.c:229)
             by 0x10A60A: main (textureSize.c:71)
           Uninitialised value was created by a stack allocation
             at 0xB3948FD: st_update_array (st_atom_array.c:388)
      Signed-off-by: Gert Wollny's avatarGert Wollny <gert.wollny@collabora.com>
      Reviewed-by: default avatarRoland Scheidegger <sroland@vmware.com>
  20. 19 Jun, 2018 1 commit
  21. 08 Feb, 2018 1 commit
  22. 06 Feb, 2018 1 commit
  23. 04 Feb, 2018 1 commit
  24. 28 Jan, 2018 1 commit
    • Dave Airlie's avatar
      r600: add ARB_query_buffer_object support · 1c9ea24a
      Dave Airlie authored
      This uses a different shader than radeonsi, as we can't address non-256
      aligned ssbos, which the radeonsi code does. This passes some extra
      offsets into the shader.
      It also contains a set of u64 instruction implementation that may
      or may not be complete (at least the u64div is definitely not something
      that works outside this use-case). If r600 grows 64-bit integers,
      it will use the GLSL lowering for divmod.
      Reviewed-by: default avatarRoland Scheidegger <sroland@vmware.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
  25. 10 Jan, 2018 5 commits
    • Roland Scheidegger's avatar
      r600: don't emit tes samplers/views when tes isn't active · ea227f43
      Roland Scheidegger authored
      Similar to const buffers. The driver must not emit any tes-related state if tes
      is disabled, since the hw slots are all shared by VS, therefore it would
      overwrite them (the mesa state tracker might not do this, but it would be
      perfectly legal to do so).
      Nevertheless I think the dirty state tracking logic in the driver is
      fundamentally flawed when tes is disabled/enabled, since it looks to me like
      the VS (and TES) state would not get reemitted to the correct slots (if it's
      not dirty anyway). Unless I'm missing something...
      Theoretically, the overwrite problem could be solved by using non-overlapping
      resource slots for TES and VS (since we're not even close to using half the
      resource slots), but it wouldn't work for constant buffers nor samplers, and
      for VS would still need to propagate changes to both LS and VS, so probably
      not a useful idea.
      Unfortunately there's zero coverage of this with piglit, since all tessellation
      shader tests are just shader_runner tests, which are unsuitable for testing
      any kind of state dependency tracking issues (so I can't even quickly hack
      something up to proove it and fix it...).
      TCS otoh is just fine - like GS it has its own hw slots.
      Tested-by: Konstantin Kharlamov's avatarKonstantin Kharlamov <hi-angel@yandex.ru>
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
    • Roland Scheidegger's avatar
      r600: increase number of UBOs to 15 · 523b6c87
      Roland Scheidegger authored
      With the exception of the default tess levels only ever accessed
      by the default tcs shader, the LDS_INFO const buffer was only accessed by vtx
      instructions, and not through kcache. No idea why really, but use this to our
      advantage by not using a constant buffer slot for it. This just requires us to
      throw the default tess levels into the "normal" driver const buffer instead.
      Alternatively, could acesss those constants via vtx instructions too, but then
      we couldn't use a ordinary ureg prog accessing them as constants and would have
      to generate that directly when compiling the default tcs shader. (Another
      alternative would be to put all lds info into the ordinary driver const
      buffer, albeit we'd maybe need to increase the fixed size as it can't fit
      alongside the ucp since vs needs access to the lds info too.)
      Tested-by: Konstantin Kharlamov's avatarKonstantin Kharlamov <hi-angel@yandex.ru>
      Dave Airlie <airlied@redhat.com>
    • Roland Scheidegger's avatar
      r600: use GET_BUFFER_RESINFO vtx fetch on eg instead of setting up consts · c5162fd3
      Roland Scheidegger authored
      Contrary to what the comment said, this appears to work just fine on my rv770
      (tested with piglit textureSize 140 fs/vs samplerBuffer).
      Dave Airlie confirmed it working on cayman too.
      I have no clue though if it's actually preferrable to use it (unfortunately
      we cannot get rid of the tex constants completely, as we still require them
      for cube map txq).
      Albeit filling in the format (1 channels or 4?) and the stuff related to mega-
      or mini-fetch (what the hell is this...) is just a guess based on other usage
      of vtx fetch instructions...
      v2: it really needs to be done through texture cache (I botched the
      testing because sb optimizations turned it automatically into tc, but
      can't rely on it and isn't happening on tes).
      Tested-by: Konstantin Kharlamov's avatarKonstantin Kharlamov <hi-angel@yandex.ru>
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
    • Roland Scheidegger's avatar
      r600: set up constants needed for txq for buffers and cube maps with tes · 43292c78
      Roland Scheidegger authored
      We only did this for the other stages, but obviously tess eval/ctrl need it
      This fixes the (newly modified) piglit texturing/textureSize test when run
      with tes stage and bufferSampler.
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
    • Roland Scheidegger's avatar
      r600: fix sampler indexing with texture buffers sampling · 762ccf48
      Roland Scheidegger authored
      This fixes the new piglit test.
      While here also fix up the logic for early exit of setting up driver consts.
      Tested-by: Konstantin Kharlamov's avatarKonstantin Kharlamov <hi-angel@yandex.ru>
      Reviewed-by: default avatarReviewed-by: Dave Airlie <airlied@redhat.com>
  26. 30 Dec, 2017 1 commit
    • Roland Scheidegger's avatar
      r600: fix textureSize queries with tbos · 878bc4a5
      Roland Scheidegger authored
      piglit doesn't care, but I'm quite confident that the size actually bound
      as range should be reported and not the base size of the resource (and
      some quick piglit test hacking confirms this).
      Also, the array in the constant buffer looks overallocated by a factor of 4.
      For eg, also decrease the size by another factor of 2 by using the same
      constant slot for both buffer size (required for txq for TBOs) and the number
      of layers for cube arrays, as these are mutually exclusive. Could of course use
      some more logic and only actually do this for the samplers/images/buffers where
      it's required rather than for all, but ah well...
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
  27. 18 Dec, 2017 1 commit
  28. 06 Dec, 2017 2 commits
  29. 05 Dec, 2017 4 commits
  30. 01 Dec, 2017 1 commit
    • Dave Airlie's avatar
      r600: add ARB_shader_storage_buffer_object support (v3) · 4e7f6437
      Dave Airlie authored
      This just builds on the image support. Evergreen only has ssbo
      for fragment and compute no other stages.
      v2: handle images and ssbo in the same shader properly (Ilia)
      v3: fix RESQ on buffers,
          fix missing atom emit
          fix first element offset
          use R32 format
          write separate buffer rat store path.
      (from running deqp gles3.1 tests)
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
  31. 29 Nov, 2017 1 commit