1. 05 Jan, 2016 1 commit
  2. 04 Jan, 2016 1 commit
  3. 23 Dec, 2015 1 commit
    • Kenneth Graunke's avatar
      i965: Consolidate BRW_NEW_TESS_{CTRL,EVAL}_PROGRAM flags. · f46dbfae
      Kenneth Graunke authored
      For several reasons, I don't think it's particularly useful to have
      separate flags:
      1. Most of the time, tessellation shaders are paired, so both will be
         replaced at the same time.
      2. The data layout is tightly coupled.  Both need to agree on the number
         of per-patch slots in the VUE map.  Even adding extra TCS outputs
         that aren't read by the TES will trigger the need for recompiles.
      3. The TCS is optional from an API perspective, but required by the
         hardware whenever tessellation is enabled.  So, atoms that deal with
         the TCS must check brw->tess_eval_program (BRW_NEW_TESS_EVAL_PROGRAM?)
         rather than brw->tess_ctrl_program to tell whether tessellation is
      So, not only is it unlikely to be useful, it's a bit confusing to get
      right.  Simply using one flag for both simplifies this.
      Signed-off-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      Reviewed-by: Jordan Justen's avatarJordan Justen <jordan.l.justen@intel.com>
  4. 11 Dec, 2015 1 commit
  5. 08 Dec, 2015 3 commits
  6. 03 Dec, 2015 1 commit
  7. 25 Nov, 2015 1 commit
  8. 24 Nov, 2015 1 commit
  9. 26 Oct, 2015 1 commit
  10. 19 Oct, 2015 1 commit
  11. 14 Oct, 2015 2 commits
  12. 09 Oct, 2015 1 commit
  13. 30 Sep, 2015 2 commits
  14. 29 Sep, 2015 1 commit
    • Jordan Justen's avatar
      i965/cs: Setup surface binding for gl_NumWorkGroups · 63d7b33f
      Jordan Justen authored
      This will only be setup when the prog_data uses_num_work_groups
      boolean is set.
      At this point nothing will set uses_num_work_groups, but soon code
      will set it when emitting code for the intrinsic that loads
      We can't emit this surface information earlier at the start of the
      DispatchCompute* call because we may not have generated the program
      yet. Until we generate the program, we don't know if the
      gl_NumWorkGroups variable is accessed.
      We also can't emit the surface as part of the brw_cs_state atom,
      because we might not need the surface if gl_NumWorkGroups is not used
      by the program.
      Lastly, we cannot emit the surface later (after state upload) in the
      DispatchCompute* call, because it needs to be run before the
      brw_cs_state atom is emitted, since it changes the surface state.
      Signed-off-by: Jordan Justen's avatarJordan Justen <jordan.l.justen@intel.com>
      Reviewed-by: Kristian H. Kristensen's avatarKristian Høgsberg <krh@bitplanet.net>
  15. 25 Sep, 2015 3 commits
  16. 10 Sep, 2015 1 commit
  17. 20 Aug, 2015 1 commit
    • Francisco Jerez's avatar
      mesa: Don't lose track of the shader image layer originally specified by the user. · b97d8c95
      Francisco Jerez authored
      The spec requires that all layers of the image starting from the 0-th
      are bound to the image unit regardless of the Layer parameter when
      Layered is true, so I was setting gl_image_unit::Layer to zero in that
      case for the convenience of the driver back-end.  However the
      ES31-CTS.shader_image_load_store.basic-api-bind conformance test
      checks that the layer value returned by glGetInteger is the same that
      was originally specified, regardless of the value of layered.  Rename
      Layer to _Layer as is usual for other derived state and keep track of
      the original layer value as gl_image_unit::Layer.
      Reviewed-by: 's avatarIan Romanick <ian.d.romanick@intel.com>
  18. 18 Aug, 2015 2 commits
  19. 11 Aug, 2015 3 commits
  20. 17 Jun, 2015 1 commit
  21. 02 May, 2015 1 commit
  22. 29 Apr, 2015 2 commits
  23. 14 Apr, 2015 1 commit
  24. 31 Mar, 2015 1 commit
  25. 02 Mar, 2015 1 commit
  26. 27 Feb, 2015 1 commit
  27. 10 Feb, 2015 1 commit
  28. 09 Feb, 2015 1 commit
  29. 31 Jan, 2015 1 commit
    • Francisco Jerez's avatar
      i965: Enable L3 caching of buffer surfaces. · 11f5d8a5
      Francisco Jerez authored
      And remove the mocs argument of the emit_buffer_surface_state vtbl hook.  Its
      semantics vary greatly from one generation to another, so it kind of
      encourages the caller to pass 0 which is the only valid setting across
      generations.  After this commit the hardware-specific code decides what the
      best cacheability settings are for buffer surfaces, just like we do for
      This together with some additional changes coming is expected to improve
      performance of pull constants, buffer textures, atomic counters and image
      objects on Gen7 and up.
      Reviewed-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
  30. 22 Jan, 2015 1 commit