- 11 Jul, 2020 1 commit
-
-
Nicolas Capens authored
Image planes have a distinct meaning in Vulkan, signifying the disjoint memory regions which store components of a texel format. Typically this includes YCbCr formats that can have 2 or 3 planes for luminance and chroma data. Slices refer to 2D sections of 3D images. Currently we also use slices for storing each sample of a multisample image separately. Note only 2D images can be multisampled, so there are no 3D images with slices for the depth and the number of samples. Bug: b/159210008 Change-Id: I4b70a7b8bb49e79c7494e28aa8280752a5b9727d Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46288 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Antonio Maiorano <amaiorano@google.com>
-
- 10 Jul, 2020 4 commits
-
-
Antonio Maiorano authored
This change makes it possible to build SwiftShader against llvm-10 on Android. To enable this, the root Android.bp must be modified to depend on libLLVM10_swiftshader, which will be done in a separate change. Successfully built for arm, arm64, x86, and x64 with the following lunch configs: * blueline-userdebug * aosp_x86-eng * aosp_x86_64-eng Bug: b/152339534 Change-Id: Id70f16f1dbde313bb97763d8a10a73a92c3530c9 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46289 Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
-
Antonio Maiorano authored
Generated by running 'third_party/llvm-10.0/scripts/update.py android'. Bug: b/152339534 Change-Id: Icdac1e219a4660181f95cb5a3e73c7abbe931c3b Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46270 Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
-
Antonio Maiorano authored
Modified update.py to add arm64 for Darwin, then re-ran the script to update the configs. Note that due to an earlier change to update.py, this also removed the unsupported platforms from config files. This replicates the similar change made to llvm-7 here: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46029 Bug: b/152339534 Change-Id: Ib504e54cb99f3dac03a0dd3992db678d56b1b090 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46309Tested-by:
-
Antonio Maiorano authored
* Added validation to ensure that this script is run on the expected host OS. * Made it restrict the list of platforms LLVM is built for based on the selected target platform. * Made copy_common_generated_files use LLVM_TARGETS to determine which folders to copy. * Other minor cleanup/refactoring. Bug: b/152339534 Change-Id: I18c6e658688e487a83eb7b6bbbe4990029d47f8f Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46269Tested-by:
-
- 09 Jul, 2020 2 commits
-
-
Nicolas Capens authored
ASTC HDR formats are not enabled, and it's unlikely we'll have a need for them, so remove them to detect attempted uses and declutter the code a bit. Bug: b/150130101 Change-Id: Ice39945dea4c0aeca027bf533253ae1915cb1170 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46228 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
-
Sylvain Defresne authored
GN recently added support for Apple frameworks to link, rather than overloading the libs lists. This pulls .frameworks out of the libs lists, so that GN can stop supporting .frameworks in libs in the future. Bug: chromium:1052560 Change-Id: Ief11c081d55b07e61252a3c66c315ceaf79de0b7 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46108 Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
-
- 08 Jul, 2020 5 commits
-
-
Antonio Maiorano authored
Ran 'python3 third_party/llvm-10.0/scripts/update.py darwin' to regenerate new linux configs that use options specified in the script. * Removes targets we don't need to support, since the update.py script specifies the exact targets we want to build. When Ben first added LLVM 10 configs, he ran the default build, which built all targets. * It also removes defines for certain options that were in update.py. Again, Ben's initial run was not done with update.py, which explains the differences. Bug: b/152339534 Change-Id: Ie09972a0ba493508884bcfd08e418ca456a8e4cc Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46268 Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
-
Antonio Maiorano authored
Ran 'python3 third_party/llvm-10.0/scripts/update.py linux' to regenerate new linux configs that use options specified in the script. * Removes targets we don't need to support, since the update.py script specifies the exact targets we want to build. When Ben first added LLVM 10 configs, he ran the default build, which built all targets. * It also removes defines for certain options that were in update.py. Again, Ben's initial run was not done with update.py, which explains the differences. * Finally, and as discussed in chat, there's a MIPS header in the "common" folder that shows diffs. This diff is between the version of this file generated from a Windows build vs a Linux build. This implies that perhaps this shouldn't be considered "common" afterall; however, since the original MIPS target was built from Linux, let's keep this version. I'll make sure to document this in the LLVM update doc I will write. Bug: b/152339534 Change-Id: I2bac0f2e6d79e84332383df8c49fda92661298fb Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46248 Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
-
Antonio Maiorano authored
Bug: b/152339534 Change-Id: Ia5a05a77bc6150b02bd467dda2d5c090181fc8c0 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46209 Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
-
Antonio Maiorano authored
Generated by running third_party/llvm-10.0/scripts/update.py Bug: b/152339534 Change-Id: Id64dac712ebf7607ea4108972ff3295ba3e35ef4 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46208Reviewed-by:
-
Antonio Maiorano authored
Modifications to update.py: * The script now clones and builds llvm in a temporary location based on the LLVM_BRANCH and LLVM_COMMIT variables in the script. * Added logging, including for execution of commands * Now setting LLVM_ENABLE_THREADS=ON as we recently manually enabled multithreading for the LLVM backend. Change-Id: I53bed46d890c0da234c4245d456c83280bf7b370 Bug: b/152339534 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46188Reviewed-by:
-
- 07 Jul, 2020 4 commits
-
-
SwiftShader Regression Bot authored
Reactor backend: Subzero Change-Id: Idc395e760ee232b6d21a3f62534b307a3df0f7b5 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45028Tested-by:
Sean Risser <srisser@google.com> Reviewed-by:
-
Nicolas Capens authored
Bug: b/146579770 Tests: dEQP-VK.* Change-Id: Ibd383e01c9fce41faf3c26deb4aefa6bc056cfdb Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46068 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
-
Nicolas Capens authored
Fixes out-of-bounds reads/writes and also avoids unaligned accesses. This is a generic reference implementation. Future optimizations could use unaligned 4-byte accesses if they're known to be safe (e.g. due to padding) and efficient. We can also eliminate if we know we're in a basic block post-dominated by the entry block and the number of active invocations is a multiple of the SIMD width. Bug: b/160531165 Change-Id: I892cfd3c7da8d8891cabe80695e5f35c57da73b4 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46168 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
-
Nicolas Capens authored
The Reactor code in floatToHalfBits() did not match the reference implementation of the sw::half type, leading to failures in dEQP tests which are enabled by the shaderStorageImageExtendedFormats feature. The previous code was based on https://gist.github.com/rygorous/2156668. It doesn't round to nearest even in case of a tie, but that's not demanded by Vulkan. It merits a closer look to see whether there was a bug, or whether dEQP-VK is too strict. Dawn also found the previous implementation to not handle infinity correctly, so a bug seems likely. In any case, it's good to use a reference implementation for now, and look for optimization opportunities later. Bug: b/147900455 Bug: swiftshader:147 Tests: dEQP-VK.image.format_reinterpret.buffer.*_b10g11r11_ufloat_pack32 Change-Id: Id817a012ff38af814907c2de2914ec24565622f3 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46148 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
-
- 06 Jul, 2020 4 commits
-
-
Nicolas Capens authored
Images with dimensions of 65536 texels or more exceed the 16-bit logic used by our 'low' precision sampler code. Thus we were treating them differently and forced them to use our 32-bit code path. However, ordinary images can't have such large dimensions. Only texel buffers must support 65536 or more texels. Those can only be accessed by OpImageFetch, OpImageRead, and OpImageWrite instructions, and the latter two already use custom 32-bit addressing logic. Thus we can simply specify all Fetch operations to use the 32-bit sampler code path instead of differentiating based on resource dimensions. This fixes dEQP robustness tests which are enabled by the shaderStorageImageExtendedFormats feature, because the 16-bit code path does not bounds check fetch coordinates correctly. Note that fetch does not perform filtering, and thus there is no excess from using 32-bit filtering code. Bug: b/152224843 Tests: dEQP-VK.robustness.buffer_access.*.texel_copy.a2b10g10r10_unorm_pack32.oob_uniform_read.* Change-Id: Ie658e0fc9da05cad8efec58bac3238fb498ff10b Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46131 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
-
Nicolas Capens authored
- Removed unnecessary Min() for R8G8B8A8_SNORM (see https://www.khronos.org/registry/vulkan/specs/1.1/html/vkspec.html#fundamentals-fixedfpconv) - Removed redundant parenthesis. - Used hexadecimals for the normalization factor (to match mask). - Used uppercase for hexadecimals. - Used decimal point for floating-point constants. Bug: b/159561781 Change-Id: I4eed4be3ec9b58bb43652de396bd3a34813eb283 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46010 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
-
Nicolas Capens authored
VK_FORMAT_R8_SNORM, R8G8_SNORM, and A8B8G8R8_SNORM_PACK32 are mandatory uniform texel buffer formats, which we claimed support for, but their implementation was missing. Bug: b/159561781 Change-Id: Ia66d14cd8189a664bf41af7d918260d2524aa63a Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46009 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
-
Nicolas Capens authored
VK_FORMAT_B10G11R11_UFLOAT_PACK32 is a mandatory uniform texel buffer format, which we claimed support for, but the implementation was missing. Bug: b/159561781 Change-Id: I47a1aa3d4f371603e4d97e85526e10677753b9ca Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46008 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
-
- 02 Jul, 2020 2 commits
-
-
Alexis Hetu authored
A few struct members were only ever written to and never read, which means these were encoder only struct members. Since we only need the ASTC decoder, these encoder only struct members were removed. The gains in memory allocation sizes are substantial: block_size_descriptor Initial size: 3469056 B (~3.3 MB) After this cl: 693168 B (~677 kB) decimation_table Initial size: 364896 B (~356 kB) After this cl: 1948 B (~1.9 kB) Change-Id: Id86c993331d2602a1106f6aaa729d1047e2ebc27 Tests: dEQP-VK.*astc* Bug: b/150130101 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46128 Presubmit-Ready: Alexis Hétu <sugoi@google.com> Reviewed-by:
Alexis Hétu <sugoi@google.com>
-
Nicolas Capens authored
It was being set as a C++ compile flag, while it's an MSVC linker flag. The /D was interpreted as a macro definition, which caused an IntelliSense error. Also fix the set_linker_flag CMake macro to correctly append the build configuration. Bug: b/147735529 Change-Id: I0e4473a07c224b64ad0aeb54390bced087eea3d8 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46088Reviewed-by:
-
- 01 Jul, 2020 1 commit
-
-
Peter Collingbourne authored
This is a cherry pick of upstream LLVM r340889. Bug: b/74603866 Change-Id: I9d0fd16d20d690b5c930e0a915dad8247890fc38 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46048Tested-by:
Peter Collingbourne <pcc@google.com> Presubmit-Ready: Peter Collingbourne <pcc@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
-
- 30 Jun, 2020 1 commit
-
-
Sean Risser authored
The original fix for b/139528538 didn't differentiate between release and debug builds properly. It just just checked to see if a debugger was attached. Now the assert will only happen when a debugger is attached and in a debug build. Bug: b/159733084 Change-Id: I9a6407685225c662aeb378be3296b8e4640b279d Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46028 Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
-
- 28 Jun, 2020 1 commit
-
-
Nicolas Capens authored
Extend Blitter::fastClear(), which is based on memset() instead of using Reactor routines, to also handle D32_SFLOAT and S8_UINT formats. Benchmark results: Run on (48 X 2594 MHz CPU s) CPU Caches: L1 Data 32 KiB (x24) L1 Instruction 32 KiB (x24) L2 Unified 256 KiB (x24) L3 Unified 30720 KiB (x2) -------------------------------------------------------------------------- Benchmark Time CPU Iterations -------------------------------------------------------------------------- (LLVM, before) ClearImage/VK_FORMAT_D32_SFLOAT 3.74 ms 0.016 ms 1000 (LLVM, after) ClearImage/VK_FORMAT_D32_SFLOAT 1.08 ms 0.044 ms 10000 (Subzero, before) ClearImage/VK_FORMAT_D32_SFLOAT 4.51 ms 0.063 ms 1000 (Subzero, after) ClearImage/VK_FORMAT_D32_SFLOAT 0.963 ms 0.040 ms 7467 This change re-implements https://swiftshader-review.googlesource.com/c/SwiftShader/+/45888 which was reading 'clearValue' out of bounds when accessing color[1] when it's only a single depth or stencil value. Bug: b/159455503 Bug: chromium:1097740 Change-Id: Id3e74b4fa28ee0422540a8480814f8c9988f402a Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45949 Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
-
- 26 Jun, 2020 1 commit
-
-
Nico Weber authored
Bug: chromium:1098899 Change-Id: Iad5cd599e7e90f29249d0e4129ca1fe4a10d77c6 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/46029 Presubmit-Ready: Nico Weber <thakis@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Nico Weber <thakis@google.com>
-
- 23 Jun, 2020 3 commits
-
-
Antonio Maiorano authored
This will help ensure we don't break these configs. Bug: b/159633249 Change-Id: Ida7074a649c10a1a5b35ce82b4f8438b65bdb3eb Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45970 Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
-
Antonio Maiorano authored
Also simplify code so that emitPrintLocation is called, but does nothing if ENABLE_RR_EMIT_PRINT_LOCATION isn't defined. Bug: b/159633249 Change-Id: I0e207baf6a0e2eb144e026904357664e1277ebf1 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45969 Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
-
Antonio Maiorano authored
This is as close as we'll get to "set -e" from bash. Makes the script less verbose, and closer to the Linux and MacOS ones. Bug: b/159633249 Change-Id: Ied7cdb5ab11b737fb21379be912393bbd838a40a Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45968 Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
-
- 22 Jun, 2020 1 commit
-
-
Corentin Wallez authored
This reverts commit af1f2159. Reason for revert: Fails tests with ASAN crbug.com/1097740 Bug: chromium:1097740 Change-Id: I48d3d1129ad3ea314df29d1f40b595ad6fa169ce Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45928Reviewed-by:
Corentin Wallez <cwallez@google.com> Tested-by:
-
- 20 Jun, 2020 2 commits
-
-
Nicolas Capens authored
The Vulkan spec states that "blendEnable [...] must be VK_FALSE if the attached image’s format features does not contain VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT" Previously we would silently ignore blending of integer formats. It was determined to be undefined behavior in https://gitlab.khronos.org/vulkan/vulkan/issues/2098 Bug: b/155147929 Change-Id: I01500d8c39d7f2c9a484944b4a93c6004e938c05 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45708 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
-
Nicolas Capens authored
A highly generic Blitter::blitToBuffer() method was used for copying pixels without requiring any format conversion or scaling. This change removes Blitter::blitToBuffer() and the unused blitFromBuffer() methods and implements a copyTo() method which does straightforward memcpy() of the data. Also consistently add 'To' and 'From' to the Image class's copy, blit, and resolve methods to avoid any confusion about which direction the transfer happens. Benchmark results: Run on (48 X 2594 MHz CPU s) CPU Caches: L1 Data 32 KiB (x24) L1 Instruction 32 KiB (x24) L2 Unified 256 KiB (x24) L3 Unified 30720 KiB (x2) --------------------------------------------------------- Benchmark Time CPU Iterations --------------------------------------------------------- (LLVM, before) Triangle/Hello 8.69 ms 7.39 ms 112 (LLVM, after) Triangle/Hello 0.878 ms 0.454 ms 2133 (Subzero, before) Triangle/Hello 26.2 ms 24.8 ms 41 (Subzero, after) Triangle/Hello 1.11 ms 0.432 ms 1339 Bug: b/147967959 Change-Id: I76a103bbb6e582f987ef1c3cc39d17779ae4ac99 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45650 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
-
- 19 Jun, 2020 1 commit
-
-
Nicolas Capens authored
Extend Blitter::fastClear(), which is based on memset() instead of using Reactor routines, to also handle D32_SFLOAT and S8_UINT formats. Benchmark results: Run on (48 X 2594 MHz CPU s) CPU Caches: L1 Data 32 KiB (x24) L1 Instruction 32 KiB (x24) L2 Unified 256 KiB (x24) L3 Unified 30720 KiB (x2) -------------------------------------------------------------------------- Benchmark Time CPU Iterations -------------------------------------------------------------------------- (LLVM, before) ClearImage/VK_FORMAT_D32_SFLOAT 3.74 ms 0.016 ms 1000 (LLVM, after) ClearImage/VK_FORMAT_D32_SFLOAT 1.08 ms 0.044 ms 10000 (Subzero, before) ClearImage/VK_FORMAT_D32_SFLOAT 4.51 ms 0.063 ms 1000 (Subzero, after) ClearImage/VK_FORMAT_D32_SFLOAT 0.963 ms 0.040 ms 7467 Bug: b/159455503 Change-Id: Ib1b0ad38417c516267d6addd835076a933e22dba Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45888 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
-
- 18 Jun, 2020 3 commits
-
-
Nicolas Capens authored
The spec for VkDescriptorSetLayoutBinding states that "If descriptorCount is zero this binding entry is reserved and the resource must not be accessed from any stage via this binding within any pipeline using the set layout." This restores the debug validation that existed at https://swiftshader-review.googlesource.com/c/SwiftShader/+/44308/4/src/Pipeline/SpirvShaderMemory.cpp#b405 Bug: b/157915024 Change-Id: I5e6798b0cc87f564a3c6f13963995822660b5111 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45468Tested-by:
-
Nicolas Capens authored
Also separate the out-of-bounds handling from the offset calculations. Bug: b/155862459 Change-Id: Ib6c5ea029d16fc411d792e6c129b37386d48fc1d Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45092Tested-by:
-
Nicolas Capens authored
Adding large values can overflow the already out-of-bounds offsets to become negative. Negative offsets are not detected as out-of-bounds, so it would result in an out-of-bounds access. This can also happen when they were already large negative values and remain negative after the addition. Or, when they're small negative values, they can become in bounds and thus not trigger the desired out-of-bounds behavior. Just replace the offsets with the out-of-bounds values. Bug: b/155862459 Change-Id: I38a45832bfea3a13a66f133ee7c2162855f02c61 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45091 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
-
- 17 Jun, 2020 4 commits
-
-
Nicolas Capens authored
This refactors the benchmarks to use static functions which support passing arbitrary arguments, instead of fixtures: https://github.com/google/benchmark#passing-arbitrary-arguments-to-a-benchmark This makes it easier to have a variant with and without multisampling, and avoids using state.counters[] as a hack to display clear formats. Bug: b/158231104 Change-Id: Icf0eed254dc942af8f2bcfc975a1e5e581b6e786 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45790 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
-
Nicolas Capens authored
Adds a Framebuffer class to encapsulate and abstract framebuffer creation with or without multisampling. Bug: b/158231104 Change-Id: I4198f53f872aae76955ba13f1f2372067b91a07c Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45789 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
-
Nicolas Capens authored
For now, this has to be enabled manually using TriangleBenchmark::multisample Bug: b/158231104 Change-Id: I929da4bf72e6f354aeb089e19fdd6a749f839d3f Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45689 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
-
Nicolas Capens authored
Initialization of thread_local variables in shared libraries might be implementation dependent. Just keep the assert for Win32. https://docs.microsoft.com/en-us/cpp/cpp/thread?view=vs-2019 states that "Thread-local variables that are initialized statically with constant values are generally initialized properly on all threads." Bug: b/157525646 Change-Id: Ifb6a77e085c0f21f13af58c89050868992928300 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/45809 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
-
