1. 06 Nov, 2020 1 commit
  2. 26 Aug, 2020 1 commit
  3. 04 Mar, 2020 1 commit
  4. 18 Sep, 2019 1 commit
  5. 12 Jan, 2017 1 commit
  6. 11 May, 2016 1 commit
  7. 11 Dec, 2015 1 commit
  8. 09 Dec, 2015 1 commit
  9. 24 Nov, 2015 1 commit
  10. 19 Oct, 2015 3 commits
  11. 08 Oct, 2015 2 commits
  12. 02 Oct, 2015 1 commit
  13. 30 Sep, 2015 1 commit
  14. 14 Sep, 2015 1 commit
    • Kristian Høgsberg Kristensen's avatar
      i965: Move compute shader code around · dc70c86b
      Kristian Høgsberg Kristensen authored
      This moves the compute shader code around in order to make the way the
      code is split up more consistent. There should be no functional changes.
      Typically we have a few files per stage:
          brw_vs.c, brw_wm.c brw_gs.c:
              code to drive code generation and implement precompiling and
              cache search.
              gen specific implementation of the state emission for the shader
      The brw_*_emit() functions are all in the same files as the visitor
      classes they use (with the exception of VS, which may use either vec4 or
      To make compute follow this convention, we move the brw_cs_emit()
      function into brw_fs.cpp. We can then rename brw_cs.cpp to brw_cs.c and
      do this in C like the other similar files.  Finally, move state setup
      and atoms to gen7_cs_state.c.
      Reviewed-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      Reviewed-by: Jordan Justen's avatarJordan Justen <jordan.l.justen@intel.com>
      Signed-off-by: Kristian H. Kristensen's avatarKristian Høgsberg Kristensen <krh@bitplanet.net>
  15. 13 Sep, 2015 1 commit
  16. 11 Jun, 2015 1 commit
  17. 02 May, 2015 2 commits
  18. 09 Mar, 2015 3 commits
    • Kenneth Graunke's avatar
      nir: Plumb the shader stage into glsl_to_nir(). · c6f2abe6
      Kenneth Graunke authored
      The next commit needs to know the shader stage in glsl_to_nir().
      To facilitate that, we pass the gl_shader rather than the raw exec_list
      of instructions.  This has both the exec_list and the stage.
      Signed-off-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason.ekstrand@intel.com>
    • Kenneth Graunke's avatar
      nir: Add native_integers to nir_shader_compiler_options. · b200cbb0
      Kenneth Graunke authored
      glsl_to_nir, tgsi_to_nir, and prog_to_nir all want to know whether the
      driver supports native integers.  Presumably other passes may as well.
      Adding this to nir_shader_compiler_options is an easy way to provide
      that information, as it's accessible via nir_shader::options.
      Signed-off-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason.ekstrand@intel.com>
    • Kenneth Graunke's avatar
      nir: Try to make sense of the nir_shader_compiler_options code. · a55da73b
      Kenneth Graunke authored
      The code in glsl_to_nir is entirely dead, as we translate from GLSL to
      NIR at link time, when there isn't a _mesa_glsl_parse_state to pass,
      so every caller passes NULL.
      glsl_to_nir seems like the wrong place to try and create the shader
      compiler options structure anyway - tgsi_to_nir, prog_to_nir, and other
      translators all would have to duplicate that code.  The driver should
      set this up once with whatever settings it wants, and pass it in.
      Eric also added a NirOptions field to ctx->Const.ShaderCompilerOptions[]
      and left a comment saying: "The memory for the options is expected to be
      kept in a single static copy by the driver."  This suggests the plan was
      to do exactly that.  That pointer was not marked const, however, and the
      dead code used a mix of static structures and ralloced ones.
      This patch deletes the dead code in glsl_to_nir, instead making it take
      the shader compiler options as a mandatory argument.  It creates an
      (empty) options struct in the i965 driver, and makes NirOptions point
      to that.  It marks the pointer const so that we can actually do so
      without generating "discards const qualifier" compiler warnings.
      Signed-off-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      Acked-by: Jason Ekstrand's avatarJason Ekstrand <jason.ekstrand@intel.com>
      Reviewed-by: Emma Anholt's avatarEric Anholt <eric@anholt.net>
  19. 15 Jan, 2015 1 commit
  20. 09 Jul, 2013 2 commits
  21. 23 May, 2012 1 commit
  22. 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>
  23. 10 May, 2012 2 commits
  24. 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
        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
           - the meta-op workaround in brw_predraw_resolve_buffers (discussed
           - the meta-op workaround brwPrepareExecBegin (discussed above)
      Note: This is a candidate for the 8.0 branch.
      Reviewed-by: Emma 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>
  25. 22 Nov, 2011 1 commit
  26. 18 Oct, 2011 1 commit
  27. 22 Jul, 2011 1 commit
    • Paul Berry's avatar
      glsl: Create a standalone executable for testing optimization passes. · f1f76e15
      Paul Berry authored
      This patch adds a new build artifact, glsl_test, which can be used for
      testing optimization passes in isolation.
      I'm hoping that we will be able to add other useful standalone tests
      to this executable in the future.  Accordingly, it is built in a
      modular fashion: the main() function uses its first argument to
      determine which test function to invoke, removes that argument from
      argv[], and then calls that function to interpret the rest of the
      command line arguments and perform the test.  Currently the only test
      function is "optpass", which tests optimization passes.
  28. 24 Jun, 2010 1 commit
  29. 05 May, 2010 1 commit
  30. 23 Apr, 2010 1 commit
  31. 21 Apr, 2010 1 commit
  32. 08 Apr, 2010 1 commit