- 06 May, 2020 1 commit
-
-
Alexis Hetu authored
When the out of bounds behavior is defined and any of the image coordinates is out of bounds, this cl manually pushes the pointer out of bounds in order to trigger the out of bounds behavior even if the resulting pointer would still be within memory bounds. Bug: b/150464740 Change-Id: I685973dfac440a8bca830810cf974819cfbc0f33 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/43950 Presubmit-Ready: Alexis Hétu <sugoi@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
Alexis Hétu <sugoi@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com>
-
- 05 May, 2020 3 commits
-
-
SwiftShader Regression Bot authored
Reactor backend: LLVM Change-Id: Idacca75cfd2a18886dc9f86f3d9a60d9d40d8bd3 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/42930Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Alexis Hétu <sugoi@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com>
-
Ben Clayton authored
`runDailyTest()` calls `test.cleanup()` before returning, removing the entire checkout directory, along with coverage data, and the git repo. This breaks both `postDailyResults()` and `postCoverageResults()`. Instead use a callback to handle the daily results. This way we can keep the `defer` to clean up even in case of error. Change-Id: I9730d7dd8ac9c3a19d82d07a68325afdf38bfd40 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44748Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Alexis Hétu <sugoi@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
Ben Clayton <bclayton@google.com>
-
Ben Clayton authored
turbo-cov can only process clang coverage information, so there's no point building it for other toolchains. turbo-cov depends on the llvm-10 libs and headers, and does not build against llvm-7. Bug: b/152192800 Change-Id: I522ecb3adfbd448aa47673c452a83083134a36ca Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44728 Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Tested-by:
Ben Clayton <bclayton@google.com>
-
- 04 May, 2020 1 commit
-
-
Nicolas Capens authored
This typeinfo was added for UBSan failures reported in crbug.com/737384, but it didn't address other 'Incorrect-function-pointer-type' failures for crbug.com/746914. We've suppressed sanitization for these functions with the NO_SANITIZE_FUNCTION macro, refactored interfaces used across library boundaries into purely abstract ones for crbug.com/732667, and use '-mllvm -asan-use-private-alias=1' to address b/128551743. It's unclear whether this typeinfo still serves ay purpose We shouldn't have to export typeinfo for objects used only inside the shared library, to avoid ODR violations. Remove it entirely for now. If this causes a regression and we still have to export any typeinfo, we should do so more selectively. For example to only export typeinfo for objects in the egl namespace: _ZTS*egl*; _ZTI*egl*; Alternatively, or in addition, we can try using '-mllvm -asan-use-private-alias=1' for more build systems. Bug: b/155441530 Change-Id: Ia966c40dfe45817f356d11725910afef1bb94d6e Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44688 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Alexis Hétu <sugoi@google.com> Reviewed-by:
Antonio Maiorano <amaiorano@google.com>
-
- 02 May, 2020 6 commits
-
-
Nicolas Capens authored
Bug: b/146166966 Bug: angleproject:4071 Change-Id: Ib2c69de7fb00ae1917b657840f7c456792f804f6 Tests: dEQP-VK.* Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44531Reviewed-by:
Alexis Hétu <sugoi@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com>
-
Nicolas Capens authored
Bug: b/146166966 Bug: angleproject:4071 Change-Id: Ifbfcf2d68c8789b0f91fef48db95bd9dc5a7576a Tests: dEQP-VK.* Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44530Reviewed-by:
Alexis Hétu <sugoi@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com>
-
Nicolas Capens authored
Bug: b/146166966 Bug: angleproject:4071 Change-Id: If5746fac41ba8890804819efd2f05b359e666b4f Tests: dEQP-VK.* Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44529Reviewed-by:
Alexis Hétu <sugoi@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com>
-
Nicolas Capens authored
Bug: b/146166966 Bug: angleproject:4071 Change-Id: I154e0fa9395e7bd10d82cc2564fa507af68d7497 Tests: dEQP-VK.* Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44528Reviewed-by:
Alexis Hétu <sugoi@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com>
-
Nicolas Capens authored
Bug: b/146166966 Bug: angleproject:4071 Tests: dEQP-VK.* Change-Id: I07008936fbb09f134283a21a6d3bba881f97fe09 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40668Tested-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Alexis Hétu <sugoi@google.com>
-
Nicolas Capens authored
Currently all conditional branches in SPIR-V shaders are 'flattened', resulting in the execution of all instructions in both code paths, even in the case where none of the SIMD lanes are active. If a logically never taken code path contains an image sampling instruction which accesses a sampler or image array out of bounds, this could lead to reading invalid descriptor data, or a page fault. This is fixed by checking if any SIMD lanes are active, and if not, jumping over the actual sampling operations which access the descriptor data. Bug: b/153380916 Change-Id: I8e0cf7ef855e1250ce6dce9ebf7a47e29da7814d Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/43549Tested-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Ben Clayton <bclayton@google.com>
-
- 01 May, 2020 2 commits
-
-
Nicolas Capens authored
Bug: b/154013190 Change-Id: I0a51912c3fad45f6ce0d04cbc7d4b56e1276d1dc Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44588 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Antonio Maiorano <amaiorano@google.com>
-
Antonio Maiorano authored
Use the Subzero backend instead of LLVM when running Regres per CL. Turnaround times should be faster, and since Chromium now uses SwiftShaderVK/Subzero, we'll know which CL breaks it, if any. Change-Id: If164d87c4946a1f7899c3407cc31fa2f1eba4931 Bug: b/152216043 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44628Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Tested-by:
Antonio Maiorano <amaiorano@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com>
-
- 30 Apr, 2020 8 commits
-
-
Ben Clayton authored
Changes: 3c643dd4c Reduce size of marl::ConditionVariable ffa88289a Pool::Loan::get(): Return nullptr if has no item. 6c9341313 Add a new test for 16-byte stack alignment for fibers. 924493413 Fix marl::parallelize race. Commands: ./third_party/update-marl.sh --squash Bug: b/140546382 Change-Id: Ie3d376ae9e80d5a40960aee07b664be2d75c69d5 -
Ben Clayton authored
3c643dd4c Reduce size of marl::ConditionVariable ffa88289a Pool::Loan::get(): Return nullptr if has no item. 6c9341313 Add a new test for 16-byte stack alignment for fibers. 924493413 Fix marl::parallelize race. git-subtree-dir: third_party/marl git-subtree-split: 3c643dd4c88d612a2622366074e029dca6a794d1
-
Ben Clayton authored
OpLine is produced for any line / column change. Column information may be useful for stack frame information (say two function calls on the same line), diagnosing a crash in a complex expression, or some other tooling. However, it's not so useful for IDE debugger stepping, unless you have a location for the span end (which we don't). Bug: b/155390706 Bug: b/148401179 Change-Id: Ic416c6e3c47044d707bfa36112e1153588669424 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44549Reviewed-by:
Antonio Maiorano <amaiorano@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
Ben Clayton <bclayton@google.com>
-
Ben Clayton authored
Fix warning treated as error that loop only iterates once. Bug: b/148401179 Change-Id: I8caf237ede034ba6802a6fbc8167140b27cc13cb Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44548Reviewed-by:
Antonio Maiorano <amaiorano@google.com> Tested-by:
Ben Clayton <bclayton@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com>
-
Ben Clayton authored
Instead of using raw pointers, use `std::unique_ptr`. Bug: b/126126820 Change-Id: Ia095f6aec1448c2153a0b0159f25a2946054e64b Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/43813Tested-by:
Ben Clayton <bclayton@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Chris Forbes <chrisforbes@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com>
-
Antonio Maiorano authored
Script runs a cmake command to generate and open a png with a dependency graph of currently enabled SwiftShader targets. Note that you should use CMake 3.17 to get the best looking graph, as many fixes and improvements were made to the graphviz support in 3.17. Bug: none Change-Id: Ie84eb18377b15f823bcdfe34612bf532502adf48 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/43748Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
Antonio Maiorano <amaiorano@google.com>
-
James Price authored
Applied same fix as done in 0e6a044d for the same macro in src/Common/Types.hpp (including copying the comment verbatim). Change-Id: I822db18f19a5473d9cf56ab57339ae91e96f458e Bug: b/155089897 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44508Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
James Price <jrprice@google.com>
-
Nicolas Capens authored
When JIT_IN_SEPARATE_THREAD is defined we generate Reactor routines on LLVM in a new thread. With Variable::unmaterializedVariables now a thread-local pointer, we have to avoid touching it from the separate thread. This is accomplished by moving the createRet() call out of the lambda which gets called on the separate thread. Note that while the 'jit' object is no longer needed after acquireRoutine(), that method may not be called since one may return early from Reactor code generation. Its deletion was removed from acquireRoutine() since Nucleus destruction follows quickly after and this keeps the object's explicit lifetime management simple. Note also that 'Variable' objects may still exist after acquireRoutine() has been called, so the earliest we can delete the set of unmaterialized variables is still at Nucleus object destruction when Function<> is destructed. Bug: b/153803432 Bug: b/149829034 Change-Id: Ic3940e5c52a3009e48fb1e1ff6137db6fd5ca96b Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44488 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>
-
- 29 Apr, 2020 1 commit
-
-
Nicolas Capens authored
Chrome supports Linux versions which don't come with a glibc library which supports __cxa_thread_atexit_impl. This function is required for destroying C++11 thread_local objects at thread exit. The 'jit' and 'unmaterializedVariables' thread-local objects used by Reactor are only needed between Function<> creation and Routine acquisition, so replace them by explicitly managed raw pointers. Bug: chromium:1074222 Bug: b/153803432 Change-Id: I0a92bdd30940048b9ce0c208d3a2c1a952091283 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44428 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Ben Clayton <bclayton@google.com> Reviewed-by:
Antonio Maiorano <amaiorano@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com>
-
- 28 Apr, 2020 5 commits
-
-
Antonio Maiorano authored
As per Khronos, these enums will no longer be available in future Vulkan headers: https://www.khronos.org/news/permalink/khronos-group-asking-for-feedback-on-removing-begin-range-end-range-range-size-tokens-from-headers This change now asserts that our Vulkan driver is built using a known version of the Vulkan headers (vk::SwiftShaderVulkanHeaderVersion), and when we update, the static assert will trip, reminding us to validate the range constants that we use, and must manually maintain. Bug: b/153337629 Bug: b/154215163 Change-Id: I319978e3979893a8a0cc44caf6cc79a584e518fb Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44388Tested-by:
Antonio Maiorano <amaiorano@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com>
-
Antonio Maiorano authored
Our script, src/clang-format-all.sh, applies only to .hpp, not .h files. Ran it again after renaming the Vulkan-source .h to .hpp. Bug: b/144825072 Change-Id: I2c6d11ec2285567155f207830bdf560431b927f4 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44390 Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
Antonio Maiorano <amaiorano@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com>
-
Antonio Maiorano authored
Also: * Replace angle-brackets around including VulkanPlatform.hpp with double-quotes. * Remove unused Reactor/SubmoduleCheck/gtest/gtest.h Bug: b/144825072 Change-Id: I2b68e7861355b30f93f23983e2cb97743a1bdf25 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44389Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Tested-by:
Antonio Maiorano <amaiorano@google.com>
-
Ben Clayton authored
Reduce number of threads and iterations. These tests were taking a long time. Should around ~16x faster. Bug: b/153803432 Change-Id: I3b0e6753852e7bb3a4ed44359e7d8446fd4120eb Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44408 Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com>
-
Nicolas Capens authored
Terminating the process should be done with extreme caution. Usually DABORT() is intended to be used instead. The ABORT() macro was making it too easy to write code that causes the application to terminate in relatively benign circumstances. If scenarios are encountered which demand process termination (as prescribed by the graphics API spec or as a platform requirement), we can still use ::abort(), or bring back this macro with a scarier name. Bug: b/154650520 Change-Id: I53780f72b22faadd62825d000661b605b77b597c Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44208 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Alexis Hétu <sugoi@google.com>
-
- 27 Apr, 2020 5 commits
-
-
Nicolas Capens authored
Previously we split it up into multiple commands to bind each descriptor set individually. This required knowing how many dynamic offsets buffers exist in each set, and some of the work happened at the time of the command execution. Now it's just a single simple data copying operation which doesn't need to know how the dynamic offsets are distributed between the sets. Bug: b/154522740 Change-Id: I0f094a7f91abc16e6bf971994426c104e8582c00 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44329Tested-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Alexis Hétu <sugoi@google.com>
-
Nicolas Capens authored
Descriptor set layout binding information needed by the pipeline layout has to persist after the descriptor set layout object has been destroyed. The spec states: "VkDescriptorSetLayout objects may be accessed by commands that operate on descriptor sets allocated using that layout, and those descriptor sets must not be updated with vkUpdateDescriptorSets after the descriptor set layout has been destroyed. Otherwise, a VkDescriptorSetLayout object passed as a parameter to create another object is not further accessed by that object after the duration of the command it is passed into." Bug: b/154522740 Change-Id: Ia6349383139ae0fceac328a685b06e2ec253a589 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44328 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Ben Clayton <bclayton@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com>
-
Nicolas Capens authored
Shader compilation requires access to the pipeline layout, but not to each of its descriptor set layout interfaces. This change ensures that all information is queried only through the pipeline layout interface. This facilitates refactoring the pipeline layout object to contain all this information, instead of depending on the descriptor set layout objects to remain alive after pipeline layout creation. The Vulkan spec states that "a VkDescriptorSetLayout object passed as a parameter to create another object is not further accessed by that object after the duration of the command it is passed into." Also consistently use "index" for values that index into an array, and "offset" for byte offsets. "descriptor" signifies an individual resource descriptor, while "binding" refers to the descriptor set binding which is an array (often of just one descriptor). Use "setNumber" and "bindingNumber" for the 32-bit identifiers used by SPIR-V, to distinguish them from the actual objects. Bug: b/154522740 Change-Id: If3f6e56b6769aae6ebbd49109e7dc1e78cf6558c Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44188 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Ben Clayton <bclayton@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com>
-
Nicolas Capens authored
The Vulkan spec states that for vkCmdBindDescriptorSets(): "If any of the sets being bound include dynamic uniform or storage buffers, then pDynamicOffsets includes one element for each array element in each dynamic descriptor type binding in each set. Values are taken from pDynamicOffsets in an order such that all entries for set N come before set N+1; within a set, entries are ordered by the binding numbers in the descriptor set layouts; and within a binding array, elements are in order." Using a direct-mapped array of bindings ensures we can easily compute which descriptor each dynamic offset applies to. This is also supported by the spec: "The above layout definition allows the descriptor bindings to be specified sparsely such that not all binding numbers between 0 and the maximum binding number need to be specified in the pBindings array. Bindings that are not specified have a descriptorCount and stageFlags of zero, and the value of descriptorType is undefined. However, all binding numbers between 0 and the maximum binding number in the VkDescriptorSetLayoutCreateInfo::pBindings array may consume memory in the descriptor set layout even if not all descriptor bindings are used, though it should not consume additional memory from the descriptor pool. The maximum binding number specified should be as compact as possible to avoid wasted memory." In addition, the spec states that for vkUpdateDescriptorSets(): "If the dstBinding has fewer than descriptorCount array elements remaining starting from dstArrayElement, then the remainder will be used to update the subsequent binding - dstBinding+1 starting at array element zero." Which also demands that the bindings in the descriptor set are sorted by binding number. Bug: b/154241029 Change-Id: Iae550a02bc9fa1132473c6ba4c5840440f970155 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44308 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Alexis Hétu <sugoi@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com>
-
Ben Clayton authored
These had no documentation and it took me a while to figure out what the distinction was between them. I've also added the currently unused activeStoresAndAtomicsMask() method. While I'm not keen on adding dead code, the other two methods make reference to the fact this is the method you probably want to use if you are doing something that has side effects. Given that it's inline, it should have no bloat to the final binary while it is currently unused. Bug: b/140294254 Change-Id: I0f1517aef86679f277d998f2a3fb301cf657f03a Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44369 Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Tested-by:
Ben Clayton <bclayton@google.com>
-
- 24 Apr, 2020 5 commits
-
-
Nicolas Capens authored
Bug: b/154914395 Change-Id: Ib90d86d83e3f8b17749f9eeecaedd320f991bd86 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44348 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Antonio Maiorano <amaiorano@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com>
-
Ben Clayton authored
Currently stack frames are still WIP (inlined at is still unimplemented). The current implementation can leak stack frames, which collect between shader invocations. Ensure the stack frame depth is the same on exit as it was on entry. Bug: b/148401179 Change-Id: I95fb0739dd9691942826cf22eb097708762b72e5 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44289 Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
Ben Clayton <bclayton@google.com> Reviewed-by:
Antonio Maiorano <amaiorano@google.com>
-
Ben Clayton authored
Bug: b/148401179 Change-Id: Ic432d5e82793a1a4395365846d3c3c4205fdf7ba Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44288 Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
Ben Clayton <bclayton@google.com> Reviewed-by:
Antonio Maiorano <amaiorano@google.com>
-
Ben Clayton authored
Spits out a graphviz .dot file describing the control flow of the shader. This is very similar to the output of the spirv-cfg tool in SPIRV-Tools. This is just much easier to use, and allows us to add more bespoke information to the graph in the future. Bug: b/140287657 Change-Id: Id90b065a3599b941b192a5e8105dffac9ba8f566 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32952 Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Tested-by:
Ben Clayton <bclayton@google.com>
-
Peter Collingbourne authored
In some Android gralloc implementations (e.g. minigbm), the lock operation corresponds to mmap, and unlock corresponds to munmap. This means that this code was previously returning an unusable buffer in the case where lockInternal is called passing LOCK_UNLOCKED (e.g. the mipmap buffer initializer in Sampler.cpp), resulting in segfaults later on. To prevent this from happening, don't unlock the native buffer and just leak the reference. Bug: b/142352330 Change-Id: I553801f32978c1d0af4597baad374381585e78ad Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44168Reviewed-by:
Lingfeng Yang <lfy@google.com> Reviewed-by:
Chris Forbes <chrisforbes@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Presubmit-Ready: Peter Collingbourne <pcc@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com>
-
- 23 Apr, 2020 3 commits
-
-
David 'Digit' Turner authored
As described in full details in the associated bug, LLVM will map read-only data sections with READ+EXECUTE permissions by default. Unfortunately, this makes certain tests fail on Fuchsia, because this platform is very strict regarding the EXECUTE mapping flag. This CL fixes the issue by ensuring that non-code sections are only mapped with the READ permission instead. An upstream LLVM bug has been sent to https://reviews.llvm.org/D78574 Bug: b/154586551 Change-Id: I0b5bb871f1a305bbfe8a244f7fbcb664b70c209b Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44128 Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
David Turner <digit@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com>
-
David 'Digit' Turner authored
This entry point is a private implementation detail between the Fuchsia Vulkan loader and the Vulkan ICDs on this platform. It is called by the loader early on to pass the address of a global function pointer, that can later be used by extensions to connect to Fuchsia FIDL services. This is equivalent to the Fuchsia fdio_service_connect() function, except that this scheme prevents adding libfdio as a dependency into the ICD shared library. Bug: fxb/13095 Bug: fxb/13074 Change-Id: Idd2a0a9b78495fff4bdb17d9f6afc446b067d7e0 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44019Tested-by:
Nicolas Capens <nicolascapens@google.com> Presubmit-Ready: David Turner <digit@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com>
-
Antonio Maiorano authored
When the CMake option "LESS_DEBUG_INFO" was remamed to "SWIFTSHADER_LESS_DEBUG_INFO", we forgot to rename it in the Kokoro scripts. Change-Id: I706be61af3a959cf99294491437fb9a968a6164b Bug: none Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44268Reviewed-by:
Ben Clayton <bclayton@google.com> Presubmit-Ready: Antonio Maiorano <amaiorano@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
Antonio Maiorano <amaiorano@google.com>
-