Skip to content

S
swiftshader
Switch branch/tag
  1. 16 Jul, 2019 2 commits
    • Memory leak fix for SamplingRoutine cache · 6448bd66
      Alexis Hetu authored 
      - The SamplingRoutine cache is now owned by the Device and
  has the same lifetime as the device, which means it gets
  released when the device gets released.
- Added a utility class, SamplingRoutineCache, to contain
  the cache and release all routine entries upon destruction.
- Added a pointer to the current device in the sampler object
  in order to retrieve it during sampling, in order to access
  the routine cache
- The cache is now internally an LRUCache, so it can't cache
  a large quantity of routines and take up a lot of memory.

Bug b/129523279 b/137649247 b/137524292 chromium:971325

Change-Id: If4ff1fbc87962355d0a281b9d0acace4316a02b8
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32688Tested-by: 's avatarAlexis Hétu <sugoi@google.com>
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Reviewed-by: 's avatarChris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
    • LLVMReactor: Cache llvm::TargetMachines. · 52ce1e9f
      Ben Clayton authored 
      We previously created and held a TargetMachine per JITRoutine as the routine could be created with different optimization levels, which is a property used to create the TargetMachine.

However, a llvm::TargetMachine instance can consume a lot of memory and JITRoutines can accumulate in caches, causing dEQP test batches of 1000 to fail as all the system memory is exhausted on low-memory devices.

Optimization level is the only varying property of each TargetMachine, so simply cache these by optimization level on the JITGlobals. Until we start using compiling with different optimization levels, this will ensure a single TargetMachine is shared across all JITRoutines.

Bug: b/137524292
Change-Id: I97298708ea4ed14a81aa8026a51926f571d37148
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/34128
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: 's avatarNicolas Capens <nicolascapens@google.com>
Reviewed-by: 's avatarChris Forbes <chrisforbes@google.com>
Tested-by: 's avatarBen Clayton <bclayton@google.com>
  3. 15 Jul, 2019 6 commits
  5. 11 Jul, 2019 2 commits
    • Fix reporting VK_ERROR_OUT_OF_HOST_MEMORY · 4cd9767e
      Nicolas Capens authored 
      The regular C++ operator new calls the installed new-handler on
out-of-memory, which by default throws std::bad_alloc when exception
handling is enabled, or aborts when not. Under no circumstance is null
returned. Furthermore, LLVM installs a new-handler itself, which also
ends up aborting the program.

Using the std::nothrow version of new does not work because it still
calls the new-handler. Installing our own non-fatal new-handler is also
futile because the new operator will re-attempt allocation.

Setting the new-handler to nullptr will cause the nothrow version of new
to return null on out-of-memory. However, this still overrides any new
handler which the application may have installed, or, can be overridden
by the application again at any point.

Instead just use legacy malloc(), which is guaranteed to never throw and
returns null on failure. This is already checked for by vk::Create() and
it reports VK_ERROR_OUT_OF_HOST_MEMORY.

Bug: b/137093675
Change-Id: I6c9ccf738cfd21af9e52382d6e7755071d613d39
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/34028
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: 's avatarBen Clayton <bclayton@google.com>
Reviewed-by: 's avatarChris Forbes <chrisforbes@google.com>
Tested-by: 's avatarNicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
    • Fix for rendering being too dark · f3dce112
      Alexis Hetu authored 
      Using a non SRGB format with VK_COLOR_SPACE_SRGB_NONLINEAR_KHR
yields a resulting image in the wrong color space. Making sure
a surface format where format and color space are both SRGB
fixes the issue.

Bug b/137088174

Change-Id: I934e6b60afe5f65d22832162e48aecef773627e8
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/34048Tested-by: 's avatarAlexis Hétu <sugoi@google.com>
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Reviewed-by: 's avatarChris Forbes <chrisforbes@google.com>
  7. 10 Jul, 2019 3 commits
  9. 08 Jul, 2019 1 commit
  11. 05 Jul, 2019 6 commits
  13. 04 Jul, 2019 14 commits
  15. 03 Jul, 2019 2 commits
  17. 02 Jul, 2019 4 commits