- 02 May, 2020 1 commit
-
-
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 4 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>
-
David 'Digit' Turner authored
Allow the Bug prefix fxb/ to be used to Fuchsia bug numbers in commit messages. These should be redirected to https://fxbug.dev/<number> Bug: None Change-Id: Ibdba2b22b15cc6851dccc60e64bea034b8be668a Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44129 Presubmit-Ready: David Turner <digit@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
David Turner <digit@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com>
-
- 22 Apr, 2020 9 commits
-
-
Nicolas Capens authored
Shader modules can be used by different pipelines, even with incompatible layouts. The generated code differs based on the layout, so we must use it as part of the cache key. This change conservatively assumes each pipeline layout to be unique, so a serial ID is used to differentiate between them. Bug: b/154660947 Change-Id: I65cce79d7780d8b9eab1752a5005202263dc3c1d Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44228 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Ben Clayton <bclayton@google.com>
-
Ben Clayton authored
The ENABLE_DBG_MSGS flag controls printing of verbose debug messages to stdout as each SPIR-V instruction is executed. This is very handy for performing text diffs when the thread count is reduced to 1 and execution is deterministic. Bug: b/140287657 Change-Id: I3b62f0f9f3017087cf7f2786e1c30497cfa05a20 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/31488Tested-by:
Ben Clayton <bclayton@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com>
-
Ben Clayton authored
There's no point writing these to disk, we just overwrite them with the next test. Unfortunately there's no way to actually disable writing these files. Think green! Save a SSD! Change-Id: Ib4f7f9417839acf491eac1828bbae7b067988e06 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44015Tested-by:
Ben Clayton <bclayton@google.com> Reviewed-by:
Antonio Maiorano <amaiorano@google.com>
-
Antonio Maiorano authored
I missed these when factoring out the root CMakeLists into multiple files. Bug: b/145758253 Change-Id: I9c5869b8bab01d823ae064ef7906566afe1e5933 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44108Tested-by:
Antonio Maiorano <amaiorano@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Ben Clayton <bclayton@google.com>
-
Antonio Maiorano authored
Replace set_target_properties(... LINK_FLAGS ...) with target_link_options. This allows us to keep our link flags variables. Note that this requires CMake 3.13. Bug: b/145758253 Change-Id: I8425f7a8e6db087d4000a721971a0dadfed6c3a5 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44110Tested-by:
Antonio Maiorano <amaiorano@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Ben Clayton <bclayton@google.com>
-
Antonio Maiorano authored
A future change will make use of target_link_options, which was added in CMake 3.13. Bug: b/145758253 Change-Id: Icac9609c5d2a9df6039a1d3defeb8db9d3cfd61d Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44109Tested-by:
Antonio Maiorano <amaiorano@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Ben Clayton <bclayton@google.com>
-
Antonio Maiorano authored
This is so that we can require CMake 3.13 in order to use target_link_options in a future change. Bug: b/145758253 Change-Id: Ia01743395453160ae658cc507499a68a79d4eede Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44088Tested-by:
Antonio Maiorano <amaiorano@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Ben Clayton <bclayton@google.com>
-
Ben Clayton authored
Going above this causes mayhem on my 3990x. Given that this is pretty much top end hardware, I don't think anything else in existance could cope with more than 100. Change-Id: I8b6e4ad09312655c59084aaf5185bb99ee459bdb Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44016Tested-by:
Ben Clayton <bclayton@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Antonio Maiorano <amaiorano@google.com>
-
Nicolas Capens authored
vk::DescriptorSet has a header which has a pointer to the descriptor set layout, which is needed for vkUpdateDescriptorSets. This information should not be available to shaders during execution. Bug: b/152227757 Change-Id: I088828a28ab4ed75ae84fb3f103455f70a8bc051 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/43968 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Ben Clayton <bclayton@google.com>
-