1. 18 Nov, 2020 1 commit
  2. 26 Jun, 2020 1 commit
    • Connor Abbott's avatar
      freedreno: On a5xx+ INDX_SIZE is MAX_INDICES · a32fb2f9
      Connor Abbott authored
      This was already done correctly for the indirect variants, and turnip
      was setting the correct value, but it seems freedreno missed the change
      in the non-indirect variant. Also, fix a misspelling of "indices" and
      add a type to INDX_SIZE.
      
      Part-of: <!5644>
      a32fb2f9
  3. 11 Jun, 2019 1 commit
    • Eduardo Lima Mitev's avatar
      freedreno/a5xx: Fix indirect draw max_indices calculation · 3fb7b1fd
      Eduardo Lima Mitev authored
      The number of elements to draw should not be affected by the offset.
      
      A similar fix was submitted for a6xx at 79180a05.
      
      Fixes these dEQP tests on a5xx:
      
      dEQP-GLES31.functional.draw_indirect.compute_interop.large.drawelements_separate_grid_500x500_drawcount_8
      dEQP-GLES31.functional.draw_indirect.compute_interop.large.drawelements_separate_grid_500x500_drawcount_2500
      dEQP-GLES31.functional.draw_indirect.compute_interop.large.drawarrays_separate_grid_500x500_drawcount_2500
      dEQP-GLES31.functional.draw_indirect.compute_interop.large.drawarrays_combined_grid_500x500_drawcount_2500
      dEQP-GLES31.functional.draw_indirect.compute_interop.large.drawelements_combined_grid_500x500_drawcount_8
      dEQP-GLES31.functional.draw_indirect.compute_interop.large.drawelements_combined_grid_500x500_drawcount_2500
      Reviewed-by: Rob Clark's avatarRob Clark <robdclark@gmail.com>
      3fb7b1fd
  4. 19 Jun, 2018 1 commit
  5. 03 Dec, 2017 1 commit
  6. 25 Nov, 2017 1 commit
  7. 14 Nov, 2017 1 commit
    • Rob Clark's avatar
      freedreno/a5xx: indirect draw support · d27318bd
      Rob Clark authored
      A couple failures in piglit tests w/ TF or gl_VertexID + indirect draws.
      OTOH all the deqp tests (although they don't test those combinations).
      I suspect this could be fixed by a firmware update, but I don't think
      there is much we can do in mesa for that.
      Signed-off-by: Rob Clark's avatarRob Clark <robdclark@gmail.com>
      d27318bd
  8. 14 May, 2017 1 commit
  9. 10 May, 2017 1 commit
    • Marek Olšák's avatar
      gallium: remove pipe_index_buffer and set_index_buffer · 330d0607
      Marek Olšák authored
      pipe_draw_info::indexed is replaced with index_size. index_size == 0 means
      non-indexed.
      
      Instead of pipe_index_buffer::offset, pipe_draw_info::start is used.
      For indexed indirect draws, pipe_draw_info::start is added to the indirect
      start. This is the only case when "start" affects indirect draws.
      
      pipe_draw_info::index is a union. Use either index::resource or
      index::user depending on the value of pipe_draw_info::has_user_indices.
      
      v2: fixes for nine, svga
      330d0607
  10. 06 Dec, 2016 1 commit
  11. 30 Nov, 2016 1 commit
  12. 27 Nov, 2016 1 commit
  13. 30 Jul, 2016 2 commits
    • Rob Clark's avatar
      freedreno: move needs_wfi into batch · e6bfe1c7
      Rob Clark authored
      This is also used in gmem code, which executes from the "bottom half"
      (ie. from the flush_queue worker thread), so it cannot be in fd_context.
      Signed-off-by: Rob Clark's avatarRob Clark <robdclark@gmail.com>
      e6bfe1c7
    • Rob Clark's avatar
      freedreno: move more batch related tracking to fd_batch · f02a64db
      Rob Clark authored
      To flush batches out of order, the gmem code needs to not depend on
      state from fd_context (since that may apply to a more recent batch).
      So this all moves into batch.
      
      The one exception is the gmem/pipe/tile state itself.  But this is
      only used from gmem code (and batches are flushed serially).  The
      alternative would be having to re-calculate GMEM layout on every
      batch, even if the dimensions of the render targets are the same.
      
      Note: This opens up the possibility of pushing gmem/submit into a
      helper thread.
      Signed-off-by: Rob Clark's avatarRob Clark <robdclark@gmail.com>
      f02a64db
  14. 02 Jul, 2016 1 commit
  15. 02 Jun, 2016 1 commit
  16. 13 Mar, 2016 1 commit
  17. 18 Nov, 2015 1 commit
  18. 12 Aug, 2015 1 commit
  19. 24 Feb, 2015 1 commit
  20. 02 Dec, 2014 1 commit
  21. 15 Nov, 2014 1 commit
  22. 15 Oct, 2014 1 commit
  23. 25 Jul, 2014 1 commit
  24. 01 Feb, 2014 1 commit
  25. 08 Jan, 2014 2 commits
  26. 26 Dec, 2013 1 commit
    • Rob Clark's avatar
      freedreno/a3xx: fix blend state corruption issue · 8ab47b43
      Rob Clark authored
      Using RMW on banked context registers is not safe.  The value read
      could be the wrong one.  So if there has been a DRAW_IDX launched,
      the RMW must be preceded by a WAIT_FOR_IDLE to ensure the read part
      of RMW sees the correct value.
      
      To avoid unnecessary WFI's, keep track if there is a need for WFI,
      and only emit one if needed.  Furthermore, keep track if we even
      need to update the register in the first place.
      
      And to cut down on the amount of RMW to avoid excessive WFI's, at the
      tiling/GMEM level we can always overwrite RB_RENDER_CONTROL, as the
      state at beginning of draw/clear cmds (which we IB to) is always
      undefined.  In the draw/clear commands, we always still use RMW (with
      WFI if needed), but only if the register value actually changes.  (At
      points where the current value cannot be known, the saved value is
      reset to ~0, which includes bits outside of RBRC_DRAW_STATE, so there
      never is chance for confusion.)
      Signed-off-by: default avatarRob Clark <robclark@freedesktop.org>
      8ab47b43
  27. 14 Dec, 2013 1 commit
  28. 14 Sep, 2013 2 commits
  29. 08 Jun, 2013 1 commit
  30. 12 Mar, 2013 1 commit
    • Rob Clark's avatar
      freedreno: gallium driver for adreno · 6173cc19
      Rob Clark authored
      Currently works on a220.  Others in the a2xx family look pretty similar
      and should be pretty straightforward to support with the same driver.
      
      The a3xx has a new shader ISA, and while many registers appear similar,
      the register addresses have been completely shuffled around.  I am not
      sure yet whether it is best to support with the same driver, but
      different compiler, or whether it should be split into a different
      driver.
      
      v1: original
      v2: build file updates from review comments, and remove GPL licensed
          header files from msm kernel
      v3: smarter temp/pred register assignment, fix clear and depth/stencil
          format issues, resource_transfer fixes, scissor fixes
      Signed-off-by: Rob Clark's avatarRob Clark <robdclark@gmail.com>
      6173cc19
  31. 12 Nov, 2012 1 commit
  32. 23 May, 2012 1 commit
  33. 15 May, 2012 1 commit
    • Paul Berry's avatar
      i965: Parameterize HiZ code to prepare for adding blitting. · 2c5510b7
      Paul Berry authored
      This patch groups together the parameters used by the HiZ functions
      into a new data structure, brw_hiz_resolve_params, rather than passing
      each parameter individually between the HiZ functions.  This data
      structure is a subclass of brw_blorp_params, which represents the
      parameters of a general-purpose blit or resolve operation.  A future
      patch will add another subclass for blits.
      
      In addition, this patch generalizes the (width, height) parameters to
      a full rect (x0, y0, x1, y1), since blitting operations will need to
      be able to operate on arbitrary rectangles.  Also, it renames several
      of the HiZ functions to reflect the expanded role they will serve.
      
      v2: Rename brw_hiz_resolve_params to brw_hiz_op_params.  Move
      gen{6,7}_blorp_exec() functions back into gen{6,7}_blorp.h.
      Reviewed-by: default avatarChad Versace <chad.versace@linux.intel.com>
      2c5510b7
  34. 10 May, 2012 2 commits
  35. 07 Feb, 2012 1 commit
    • Chad Versace's avatar
      i965: Rewrite the HiZ op · 7b36c68b
      Chad Versace authored
      The HiZ op was implemented as a meta-op. This patch reimplements it by
      emitting a special HiZ batch. This fixes several known bugs, and likely
      a lot of undiscovered ones too.
      
      ==== Why the HiZ meta-op needed to die ====
      
      The HiZ op was implemented as a meta-op, which caused lots of trouble. All
      other meta-ops occur as a result of some GL call (for example, glClear and
      glGenerateMipmap), but the HiZ meta-op was special. It was called in
      places that Mesa (in particular, the vbo and swrast modules) did not
      expect---and were not prepared for---state changes to occur (for example:
      glDraw; glCallList; within glBegin/End blocks; and within
      swrast_prepare_render as a result of intel_miptree_map).
      
      In an attempt to work around these unexpected state changes, I added two
      hooks in i965:
        - A hook for glDraw, located in brw_predraw_resolve_buffers (which is
          called in the glDraw path). This hook detected if a predraw resolve
          meta-op had occurred, and would hackishly repropagate some GL state
          if necessary. This ensured that the meta-op state changes would not
          intefere with the vbo module's subsequent execution of glDraw.
        - A hook for glBegin, implemented by brwPrepareExecBegin. This hook
          resolved all buffers before entering
          a glBegin/End block, thus preventing an infinitely recurring call to
          vbo_exec_FlushVertices. The vbo module calls vbo_exec_FlushVertices to
          flush its vertex queue in response to GL state changes.
      
      Unfortunately, these hooks were not sufficient. The meta-op state changes
      still interacted badly with glPopAttrib (as discovered in bug 44927) and
      with swrast rendering (as discovered by debugging gen6's swrast fallback
      for glBitmap). I expect there are more undiscovered bugs. Rather than play
      whack-a-mole in a minefield, the sane approach is to replace the HiZ
      meta-op with something safer.
      
      ==== How it was killed ====
      
      This patch consists of several logical components:
        1. Rewrite the HiZ op by replacing function gen6_resolve_slice with
           gen6_hiz_exec and gen7_hiz_exec. The new functions do not call
           a meta-op, but instead manually construct and emit a batch to "draw"
           the HiZ op's rectangle primitive. The new functions alter no GL
           state.
        2. Add fields to brw_context::hiz for the new HiZ op.
        3. Emit a workaround flush when toggling 3DSTATE_VS.VsFunctionEnable.
        4. Kill all dead HiZ code:
           - the function gen6_resolve_slice
           - the dirty flag BRW_NEW_HIZ
           - the dead fields in brw_context::hiz
           - the state packet manipulation triggered by the now removed
             brw_context::hiz::op
           - the meta-op workaround in brw_predraw_resolve_buffers (discussed
             above)
           - the meta-op workaround brwPrepareExecBegin (discussed above)
      
      Note: This is a candidate for the 8.0 branch.
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      Acked-by: Paul Berry's avatarPaul Berry <stereotype441@gmail.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43327
      Reported-by: xunx.fang@intel.com
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44927
      Reported-by: chao.a.chen@intel.com
      Signed-off-by: default avatarChad Versace <chad.versace@linux.intel.com>
      7b36c68b
  36. 22 Nov, 2011 1 commit