Skip to content
Snippets Groups Projects
  1. Jan 26, 2017
  2. Jan 25, 2017
  3. Jan 24, 2017
    • Dave Airlie's avatar
      radv: program a default point size. · 2ab2be09
      Dave Airlie authored
      
      Along the lines of what
      3b804819 anv: Default PointSize to 1.0 if not written by the shader
      does for anv, program a default point size in the hw of 1.0.
      
      This preempt fixes a bunch of geom shader tests.
      
      Reviewed-by: default avatarBas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
      Cc: "17.0" <mesa-stable@lists.freedesktop.org>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      2ab2be09
    • Marek Olšák's avatar
      radeonsi: handle first_non_void correctly in si_create_vertex_elements · eac7df43
      Marek Olšák authored
      
      This fixes R11G11B10_FLOAT, because it's in the category of "OTHER",
      meaning that it doesn't have any channel description.
      
      Cc: 17.0 <mesa-stable@lists.freedesktop.org>
      Reviewed-by: default avatarNicolai Hähnle <nicolai.haehnle@amd.com>
      eac7df43
    • Marek Olšák's avatar
      st/mesa: destroy pipe_context before destroying st_context (v2) · d9ef5492
      Marek Olšák authored
      If radeonsi starts compiling an optimized shader variant asynchronously
      with a GL debug callback set and the application destroys the GL context,
      radeonsi crashes when trying to write shader stats into the debug output
      of a non-existent context after compilation, because st/mesa was destroyed
      before pipe_context.
      
      Firefox with WebGL2 enabled hits this bug.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99456
      
      
      
      v2: protect against a double destroy in st_create_context_priv and callers.
      
      Cc: 17.0 <mesa-stable@lists.freedesktop.org>
      Reviewed-by: default avatarNicolai Hähnle <nicolai.haehnle@amd.com>
      d9ef5492
    • Timothy Arceri's avatar
      nir: bump loop max unroll limit · dd65f0ef
      Timothy Arceri authored
      
      The original number was chosen in an attempt to match the limits applied to
      GLSL IR.
      
      A look at the git history of the why these limits were chosen for GLSL IR
      shows it was more to do with the slow speed of unrolling large loops in
      GLSL IR than anything else. The speed of loop unrolling in NIR is not a
      problem so we may wish to bump this even higher in future.
      
      No shader-db change, however a furture change will disbale the GLSL IR
      optimisation loop in the i965 backend results in 4 loops from The Talos
      Principle failing to unroll. Bumping the limit allows them to unroll which
      results in the instruction count matching the previous output from when the
      GLSL IR opts were still enabled.
      
      Reviewed-by: default avatarJason Ekstrand <jason@jlekstrand.net>
      dd65f0ef
    • Timothy Arceri's avatar
      glsl: lower constant arrays to uniform arrays before optimisation loop · 34ab9b09
      Timothy Arceri authored
      
      Previously the constant array would not get copy propagated until the backend
      did its GLSL IR opt loop. I plan on removing that from i965 shortly which
      caused huge regressions in Deus-ex and Tomb Raider which have large
      constant arrays. Moving lowering before the opt loop in the GLSL linker
      fixes this and unexpectedly improves some compute shaders also.
      
      shader-db results BDW:
      
      instructions helped:   shaders/closed/steam/deus-ex-mankind-divided/374.shader_test CS SIMD16: 204 -> 194 (-4.90%)
      instructions helped:   shaders/closed/steam/deus-ex-mankind-divided/318.shader_test CS SIMD8: 1010 -> 741 (-26.63%)
      instructions helped:   shaders/closed/steam/deus-ex-mankind-divided/144.shader_test CS SIMD8: 542 -> 385 (-28.97%)
      
      cycles helped:   shaders/closed/steam/deus-ex-mankind-divided/318.shader_test CS SIMD8: 1831382 -> 1818492 (-0.70%)
      cycles helped:   shaders/closed/steam/deus-ex-mankind-divided/144.shader_test CS SIMD8: 216238 -> 206180 (-4.65%)
      cycles helped:   shaders/closed/steam/deus-ex-mankind-divided/374.shader_test CS SIMD16: 18484 -> 16644 (-9.95%)
      
      total instructions in shared programs: 13060313 -> 13059877 (-0.00%)
      instructions in affected programs: 1756 -> 1320 (-24.83%)
      helped: 3
      HURT: 0
      
      total cycles in shared programs: 256586698 -> 256561910 (-0.01%)
      cycles in affected programs: 2066104 -> 2041316 (-1.20%)
      helped: 3
      HURT: 0
      
      V3: only call the opt loop if lowering progressed (Suggested by Eric)
      
      V2: call opts before and after lowering (Suggested by Ken)
      
      Reviewed-by: default avatarEric Anholt <eric@anholt.net>
      34ab9b09
    • Ian Romanick's avatar
      mesa: Don't advertise GL_OES_read_format in core profile · c4a0c1ef
      Ian Romanick authored
      
      OpenGL ES implementations are not allowed to ship ARB extensions, and
      OpenGL implementations are not allowed to ship OES extensions.
      
      The functionality is also included in GL_ARB_ES2_compatibility.  Ever
      OpenGL core-profile driver currently exposes both extensions.  I don't
      know of any applications that explicitly check for GL_OES_read_format,
      so removing it seems very unlikely to cause problems.  No functionality
      is removed.
      
      I have left this extension in place for compatibility profile.  There
      are still OpenGL 1.x drivers in Mesa, and adding code to check for
      compatibility profile and not GL_ARB_ES2_compatibility for
      GL_IMPLEMENTATION_COLOR_READ_TYPE and GL_IMPLEMENTATION_COLOR_READ_FORMAT
      just feels dumb.
      
      Three other other alternatives considered:
      
       - Remove the string from compatibility profile drivers but leave the
         functionality in place.
      
       - Add a flag to expose the extension string, and set it in every OpenGL
         driver that does not expose GL_ARB_ES2_compatibility (and those
         drivers only).  I tried this.  You can't have two instances of an
         extension in the extension table (one dummy_true for ES1 and one with
         a flag for compatibility profile), so the implementation requires a
         bit of effort.
      
       - Only expose the extension in compatibility if the version is less
         than 2.0.  I didn't see an easy way to do this.
      
      Signed-off-by: default avatarIan Romanick <ian.d.romanick@intel.com>
      Reviewed-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      Cc: mesa-stable@lists.freedesktop.org
      c4a0c1ef
Loading