1. 08 Mar, 2021 4 commits
  2. 07 Mar, 2021 10 commits
    • Alyssa Rosenzweig's avatar
      nir/lower_viewport_transform: Allow geom/tess · e30994a4
      Alyssa Rosenzweig authored
      
      
      This pass needs to run on the last shader in a pipeline writing
      gl_Position. In GLES2, that's always the vertex shader, but in ES3.2, it
      can be a geometry or tessellation shader. The shared code works the same
      in this case, just make the assert more generous.
      Signed-off-by: Alyssa Rosenzweig's avatarAlyssa Rosenzweig <alyssa@collabora.com>
      Reviewed-by: Erico Nunes's avatarErico Nunes <nunes.erico@gmail.com>
      Part-of: <!9444>
      e30994a4
    • Alyssa Rosenzweig's avatar
      pan/bi: Treat +DISCARD.f32 as message-passing · 3436e529
      Alyssa Rosenzweig authored
      
      
      Likely errata, matches blob's handling. Closes #4387
      
      total nops in shared programs: 86266 -> 86272 (<.01%)
      nops in affected programs: 347 -> 353 (1.73%)
      helped: 1
      HURT: 2
      
      total clauses in shared programs: 20813 -> 20833 (0.10%)
      clauses in affected programs: 343 -> 363 (5.83%)
      helped: 0
      HURT: 20
      Clauses are HURT.
      
      total quadwords in shared programs: 91572 -> 91588 (0.02%)
      quadwords in affected programs: 1322 -> 1338 (1.21%)
      helped: 1
      HURT: 14
      Quadwords are HURT.
      Signed-off-by: Alyssa Rosenzweig's avatarAlyssa Rosenzweig <alyssa@collabora.com>
      Tested-by: Icecream95's avatarIcecream95 <ixn@disroot.org>
      Cc: mesa-stable
      Part-of: <mesa/mesa!9446>
      3436e529
    • Alyssa Rosenzweig's avatar
      pan/bi: Set clause_state.message conservatively · 6cb1a9b7
      Alyssa Rosenzweig authored
      Accidentally prevented scheduling message-passing instructions to
      anywhere but the last ADD of a clause.
      
      total nops in shared programs: 86280 -> 86266 (-0.02%)
      nops in affected programs: 1609 -> 1595 (-0.87%)
      helped: 9
      HURT: 4
      Inconclusive result (value mean confidence interval includes 0).
      
      total clauses in shared programs: 20993 -> 20813 (-0.86%)
      clauses in affected programs: 3488 -> 3308 (-5.16%)
      helped: 116
      HURT: 0
      Clauses are helped.
      
      total quadwords in shared programs: 91697 -> 91572 (-0.14%)
      quadwords in affected programs: 12257 -> 12132 (-1.02%)
      helped: 53
      HURT: 2
      Quadwords are helped.
      
      Fixes: f0c0082a
      
       ("pan/bi: Schedule blocks")
      Signed-off-by: Alyssa Rosenzweig's avatarAlyssa Rosenzweig <alyssa@collabora.com>
      Tested-by: Icecream95's avatarIcecream95 <ixn@disroot.org>
      Part-of: <mesa/mesa!9446>
      6cb1a9b7
    • Alyssa Rosenzweig's avatar
      pan/bi: Mark message-passing sources/dests live · 6322bc54
      Alyssa Rosenzweig authored
      More general, same data race.
      
      Fixes: 44726101
      
       ("pan/bi: Don't fill garbage")
      Signed-off-by: Alyssa Rosenzweig's avatarAlyssa Rosenzweig <alyssa@collabora.com>
      Tested-by: Icecream95's avatarIcecream95 <ixn@disroot.org>
      Part-of: <mesa/mesa!9446>
      6322bc54
    • Axel Davy's avatar
      st/nine: Set default dynamic_texture_workaround to true · 91755300
      Axel Davy authored
      
      
      Now the texture virtual memory usage is less of a problem,
      we can use this workaround permanently.
      
      In the spirit of the API it's certainly not the proper way
      of implementing DYNAMIC textures (it seems they are ok
      to have hidden copies in driver managed memory, but not have
      virtual addressing space reduced), but it makes sense for us,
      both performance wise, and to avoid bugs.
      Signed-off-by: Axel Davy's avatarAxel Davy <davyaxel0@gmail.com>
      Part-of: <mesa/mesa!9377>
      91755300
    • Axel Davy's avatar
      st/nine: Add driconf option to limit texture memory · 0beb7775
      Axel Davy authored
      
      Signed-off-by: Axel Davy's avatarAxel Davy <davyaxel0@gmail.com>
      Part-of: <mesa/mesa!9377>
      0beb7775
    • Axel Davy's avatar
      st/nine: Control the memfd virtual limit · 24eb1f21
      Axel Davy authored
      
      Signed-off-by: Axel Davy's avatarAxel Davy <davyaxel0@gmail.com>
      Part-of: <mesa/mesa!9377>
      24eb1f21
    • Axel Davy's avatar
      st/nine: Use the texture memory helper · a179ea2e
      Axel Davy authored
      
      
      Switch to the new texture RAM memory API.
      Signed-off-by: Axel Davy's avatarAxel Davy <davyaxel0@gmail.com>
      Part-of: <mesa/mesa!9377>
      a179ea2e
    • Axel Davy's avatar
      st/nine: Add RAM memory manager for textures · 90a7573a
      Axel Davy authored
      
      
      On 32 bits, virtual memory is sometimes too short for apps.
      Textures can hold virtual memory 3 ways:
      1) MANAGED textures have a RAM copy of any texture
      2) SYSTEMMEM is used to have RAM copy of DEFAULT textures
         (to upload them for example)
      3) Textures being mapped.
      
      Nine cannot do much for 3). It's up to driver to really unmap textures
      when possible on 32 bits to reduce virtual memory usage.
      
      It's not clear whether on Windows anything special is done for
      1) and 2). However there is clear indication some efforts have
      been done on 3) to really unmap when it makes sense.
      
      My understanding is that other implementations reduce the usage
      of 1) by deleting the RAM copy once the texture is uploaded
      (Dxvk's behaviour is controlled by evictManagedOnUnlock).
      
      The obvious issue with that approach is whether the texture is
      read by the application after some time. In that case,
      we have to recreate the RAM backing from the GPU buffer.
      
      And apps DO that. Indeed I found that for example Mass Effect 2
      with High Texture mods (one of the crash case fixed by this patch serie),
      When the character gets close to an object, a high res texture and replaces
      the low res one. The high res one simply has more levels, and the game seems
      to optimize reading the high res texture by retrieving the small-resolution
      levels from the original low res texture.
      In other words during gameplay, the game will randomly read MANAGED textures.
      This is expected to be fast as the data is supposed to be in RAM...
      
      Instead of taking that RAM copy eviction approach, this patchset
      proposes a different approach: storing in memfd and release the
      virtual memory until needed.
      
      Basically instead of using malloc(), we create a memfd file
      and map it. When the data doesn't seem to be accessed anymore,
      we can unmap the memfd file.
      If the data is needed, the memfd file is mapped again.
      This trick enables to allocate more than 4GB on 32 bits apps.
      
      The advantage of this approach over the RAM eviction one,
      is that the load is much faster and doesn't block the GPU.
      
      Of course we have problems if there's not enough memory to map the
      memfd file. But the problem is the same for the RAM eviction approach.
      
      Naturally on 64 bits, we do not use memfd.
      Signed-off-by: Axel Davy's avatarAxel Davy <davyaxel0@gmail.com>
      Part-of: <mesa/mesa!9377>
      90a7573a
    • Axel Davy's avatar
      st/nine: Add new function to know if we are the worker · 6087ff44
      Axel Davy authored
      
      
      This will be useful in a later patch
      Signed-off-by: Axel Davy's avatarAxel Davy <davyaxel0@gmail.com>
      Part-of: <mesa/mesa!9377>
      6087ff44
  3. 06 Mar, 2021 5 commits
  4. 05 Mar, 2021 21 commits