- 20 Jun, 2019 4 commits
-
-
Ben Clayton authored
Reduces the amount of LLVM IR produced when the limits are compile-time known. Reduces full test execution time of dEQP-VK.ubo.random.all_out_of_order_offsets.45 by about half. For dEQP-VK.ubo.random.all_shared_buffer.48: • Reduces number of pre-opt LLVM IR instructions by about 40%. • Reduces full test execution time by about 30% Bug: b/135609394 Change-Id: I3c46d56910bb8373a355ab8d570d3093944afc84 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33053Reviewed-by:
Chris Forbes <chrisforbes@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Tested-by:
Ben Clayton <bclayton@google.com> Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
-
Ben Clayton authored
Currently does not do anything differently, but is a stepping stone to optimizations. Bug: b/135609394 Change-Id: I9020d4819b0e6f4bdd9564c2407c1903b7f33f4f Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33052Reviewed-by:
-
Ben Clayton authored
This should have been true for the constructor that takes a dynamic offset. Surprising that this hadn't caused any tests to fail. Bug: b/131224163 Change-Id: I00fcfb99e265c7a378c40817ae8f84104e4a2a3d Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33051Reviewed-by:
-
Jose Dapena Paz authored
Swiftshader is failing to compile in GCC with ARM32. There are several build units mising. ../../../chromium-77.0.3824.6/third_party/swiftshader/third_party/llvm-7.0/llvm/lib/Target/ARM/ARMParallelDSP.cpp:296: error: undefined reference to 'llvm::isConsecutiveAccess(llvm::Value*, llvm::Value*, llvm::DataLayout const&, llvm::ScalarEvolution&, bool)' ../../../chromium-77.0.3824.6/third_party/swiftshader/third_party/llvm-7.0/llvm/lib/Target/ARM/ARMParallelDSP.cpp:192: error: undefined reference to 'llvm::LoopAccessInfo::LoopAccessInfo(llvm::Loop*, llvm::ScalarEvolution*, llvm::TargetLibraryInfo const*, llvm::AAResults*, llvm::DominatorTree*, llvm::LoopInfo*)' ../../../chromium-77.0.3824.6/third_party/swiftshader/third_party/llvm-7.0/llvm/lib/Target/ARM/ARMTargetMachine.cpp:386: error: undefined reference to 'llvm::createLowerAtomicPass()' collect2: error: ld returned 1 exit status Bug: chromium:972766 Change-Id: I639ea516de0fbfe43697c84aac1a67c40b9c4838 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33210Tested-by:
José Dapena Paz <jose.dapena@lge.com> Reviewed-by:
-
- 19 Jun, 2019 5 commits
-
-
Nicolas Capens authored
We were creating SpirvShader objects for every shader stage of the pipeline, each with their own unique serial ID. This caused us to compile the same SPIR-V code over an over again when multiple pipelines are created from the same shader module(s). This change essentially moves the serial ID to the shader module. Things that still require us to recompile code from the same shader module are the entry point specification, and specialization constants. The former is taken into account by using a 64-bit ID consisting of the module ID and entry point ID. For the latter we assume any use of specialization constants will result in a unique SPIR-V binary. This is conservative and may still lead to unnecessary recompiles. This change also minimizes the state passed to SpirvShader, to prevent specialization on state not taken into account by the routine caches. Bug: b/135609394 Tests: dEQP-VK.pipeline.render_to_image.core.*.huge.* Change-Id: I204e812265067462f8019af9f6b7b3067ef5dc7f Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33109 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Kokoro-Presubmit: kokoro <noreply+kokoro@google.com> Tested-by:
Alexis Hétu <sugoi@google.com>
-
Alexis Hetu authored
A few things: - The library wasn't located in the provided path - The function pointers weren't using the convention call - The libraries built from Visual Studio weren't taken into account (probably only those generated from the CMake generated project were loadable) Change-Id: I7f9cc9aee920747b4bab77286ba811b33982cece Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33128Tested-by:
-
Alexis Hetu authored
Change-Id: Ide85746f57ff8b37aebd5d17fba4ad0fffc762ce Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33108Tested-by:
-
Alexis Hetu authored
Modified VkNonDispatchableHandle so that it's a plain old data type. By making sure VkNonDispatchableHandle is POD, it may benefit from the same rules and register usage as the default object handles. Bug b/129979580 Change-Id: I8aea419df8a6ee2ff95717424f3344e1c317fb28 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32989Tested-by:
-
SwiftShader Regression Bot authored
Change-Id: Ibd89bd79fec1e9e83c1f4201f1e789e90f773f08 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33049 Kokoro-Presubmit: kokoro <noreply+kokoro@google.com> Reviewed-by:
-
- 18 Jun, 2019 5 commits
-
-
Ben Clayton authored
The previous traversal could create huge pending lists of duplicate-blocks, to just skip over them. This was due a couple of factors, including BFS traversal and always appending the downstream blocks to the queue. There's no particular reason to do BFS traversal, so perform DFS traversal instead, and check the downstream blocks haven't been processed already before enquing. Fixes pending lists reaching counts as high as 1e7 for tests such as dEQP-VK.spirv_assembly.instruction.compute.opphi.nested - making these tests much faster to pass and drastically reducing peak memory usage. Bug: b/135512559 Change-Id: Ibbfa03e582f08d6b41e6c8496d05b8b4027b31b6 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32951Reviewed-by:
-
Stuart Morgan authored
Change-Id: I07234873cb8b64a158cd777d231367d56daf4255 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33069Reviewed-by:
Stuart Morgan <stuartmorgan@google.com>
-
Ben Clayton authored
We the WARNINGS_AS_ERRORS CMake flag to treat all warnings as errors. This change demotes the cherry-picked warnings-as-errors to just regular warnings, which can be optionally treated as errors like every other warning (WARNINGS_AS_ERRORS defaults to enabled). Based on the discussions: https://swiftshader-review.googlesource.com/c/SwiftShader/+/29810/6#message-de0432365b25c83372bac2f6528c79174aef0f6b and https://swiftshader-review.googlesource.com/c/SwiftShader/+/30191/2/CMakeLists.txt#248 Bug: b/135472272 Change-Id: I8aa37d79b9263560f9ff55ad4817f66ded6960ee Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32953 Kokoro-Presubmit: kokoro <noreply+kokoro@google.com> Tested-by:
-
Alexis Hetu authored
Only use the upper 8 bits of the 16 bit fields when reading and outputting 8 bit values in order to get exact representations of x/255 for each possible 8 bit value. Bug: swiftshader:122 Bug: b/129523279 Change-Id: I0cd54eb325c24f2fc5a53f12a0b90696024ca9d1 Tests: dEQP-VK.memory.pipeline_barrier.all.* Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/33028Tested-by:
-
Nicolas Capens authored
Clang 4.0.1 is less than two years old and still in widespread use. It doesn't support some of the more recent diagnostic warnings. Bug: b/130335507 Change-Id: I68c6270c2e90c50b1de1657e16e914c89b336952 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/30191Tested-by:
-
- 17 Jun, 2019 5 commits
-
-
Chris Forbes authored
Bug: b/135298866 Change-Id: Ic8d2375ae7e7ee8c521f8c4c1ca6ec44db9fb8be Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32988Tested-by:
-
Ben Clayton authored
This should disable code generation of exception handling, which we do not require. Bug: b/135298866 Change-Id: I081d4317d7cdad6a9101db026bb72e4a09fb874c Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32949 Kokoro-Presubmit: kokoro <noreply+kokoro@google.com> Tested-by:
-
SwiftShader Regression Bot authored
Change-Id: I90295a7fae4a22572fc3abd551f7bf0371a72603 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32950Reviewed-by:
-
Alexis Hetu authored
- Simplified VkNonDispatchableHandle as much as possible so that it's just a wrapper over a uint64_t - Centralized casting logic in vkObject.hpp - Explicitly changed "Cast" to "vk::Cast" to differentiate from vk::<object>::Cast - Moved VkDescriptorSet operators from VulkanPlatform.h to VkDescriptorPool.cpp Bug b/129979580 Change-Id: I4fe5fcfe56029c21594088d274bae862999597ad Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32928Tested-by:
-
SwiftShader Regression Bot authored
Change-Id: I794938bed33ea09cee733b34b55b29f04ca2751d Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32948Reviewed-by:
-
- 14 Jun, 2019 9 commits
-
-
Alexis Hetu authored
Fixes most warnings using the Visual Studio C++ 64 bit compiler. Should be noop Bug b/132445520 Change-Id: I7844062244478b39299729cf4e4c0b647e2f5b14 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/31150Tested-by:
-
Nicolas Capens authored
Bug: b/125909515 Change-Id: I35e1c54590fadfe5fa49d33552e0a4b4f8c892ee Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32849 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Kokoro-Presubmit: kokoro <noreply+kokoro@google.com> Tested-by:
-
Nicolas Capens authored
OpImageFetch/Read/Write can have an optional 'Sample' operand which indicates the sample index to operate on. It is orthogonal to other operands so it is indicated by a new Boolean field in sw::SamplerFunction and SpirvShader::ImageInstruction. The offset operand was also turned into a Boolean field / component count. The sample index is not wired up to be taken into account by the Fetch sampling routine yet. OpImageRead already had support for the Sample operand, but OpImageWrite does not. Bug: b/135265531 Tests: dEQP-VK.pipeline.multisample.sampled_image.* Change-Id: I20f50a888436775b996221e8283a4c4ab7f28e17 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32908Tested-by:
-
Colin Samples authored
This updates LLVMReactor to provide for PPC64 little endian support. It also adds an #ifdef condition to an assert macro, since llvm::sys::getHostCPUFeatures will always return false on non-x86 and ARM Linux platforms per 'third_party/llvm-7.0/llvm/lib/Support/Host.cpp'. Bug: b/135175069 Signed-off-by:
Colin Samples <colin.samples+git@gmail.com> Change-Id: Idcdafe2f1bd934317ca9da09c99132f814fcf160 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32811 Kokoro-Presubmit: kokoro <noreply+kokoro@google.com> Tested-by:
-
Colin Samples authored
Adds support for PPC64 LLVM build to CMake and gn Bug: b/135175069 Signed-off-by:
-
Colin Samples authored
Regenerate LLVM sources for Linux by running `third_party/llvm-7.0/scripts/update.py linux` Bug: b/135175069 Signed-off-by:
-
Colin Samples authored
Update third_party/llvm-7.0/scripts/update.py to pull in PPC64 LLVM sources. Bug: b/135175069 Change-Id: I2d5d61a18b822d3a10d958e3d20d314f62d51226 Signed-off-by:
-
Alexis Hetu authored
We should be changing to the internal object representation ASAP in the API and not carry around handles when it's trivial not to. Bug: b/116336664 Change-Id: I21de3421fd3e72f3402f2d7cefe1a3dd22c87045 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32850 Kokoro-Presubmit: kokoro <noreply+kokoro@google.com> Tested-by:
-
SwiftShader Regression Bot authored
Change-Id: If91d79f432af80af266feceaa85e52dc82bc09ab Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32828 Kokoro-Presubmit: kokoro <noreply+kokoro@google.com> Reviewed-by:
-
- 13 Jun, 2019 5 commits
-
-
Sean Risser authored
From the SPIR-V spec: OpSMod's result is the remainder r of Operand 1 divided by Operand 2 where if r != 0, the sign of r is the same as the sign of Operand 2. The less than comparison here was trying to correct the cases where C's modulo had a different sign than SPIR-V's modulo. We can solve this by directly comparing the sign of the C modulo against Operand 2's sign. Bug chromium:973848 Change-Id: I27c88b7aaed35db5ba4df2cc0aac6061098f32c4 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32868Tested-by:
Sean Risser <srisser@google.com> Presubmit-Ready: Sean Risser <srisser@google.com> Reviewed-by:
-
shrekshao authored
Expose EXT_float_blend in Swiftshader without actually doing validation. Also fix some missing instructions in dEQP.md. dEQP test results: there are quite a lot failures from my locally run tests. Not sure if they used to be there, or is introduced by my change. 16/16 of the blend tests passed. Bug: chromium:968830 Change-Id: Ifa2bb09788899b004d62388311aa7d2aa6ad6df3 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32888Reviewed-by:
Shrek Shao <shrekshao@google.com>
-
Nicolas Capens authored
Previously, vertices would be processed in consecutive groups of four (for SSE/NEON). Now four indices are read from the index buffer. Reading the input was already a gather operation, but with constant stride. The vertex cache now performs a scatter. The vertices are written in reverse order so that the first vertex in a group is always present in the cache. Also use 2^32-1 as invalid vertex cache index (corresponds with the primitive restart index) instead of 0x80000000, since maxDrawIndexedIndexValue is UINT32_MAX. Bug: b/27351835 Test: dEQP-VK.glsl.loops.special.do_while_dynamic_iterations.dowhile_trap_vertex Change-Id: Ic69dbf53c67cbda50e44913ccae91aaca2b86e21 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32609 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Kokoro-Presubmit: kokoro <noreply+kokoro@google.com> Tested-by:
-
Nicolas Capens authored
Also reorder fields to reduce space wasted on alignment padding, and shuffle writing them to the vertex cache in the same order for consistency. Bug: b/27351835 Change-Id: I06ca0c836aabd9d095893762d973c098f694ee30 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32788 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
-
Alexis Hetu authored
The blitter was not doing the sRGB conversion on the first of N source samples when accumulating samples for doing an sRGB resolve. This cl also includes Chris' initial fix for PixelRoutine and SpirvShader. See: https://swiftshader-review.googlesource.com/c/SwiftShader/+/31928 Change-Id: I97ce06fb39788fd623eb9b5c0203e45fd911c1dd Tests: dEQP-VK.renderpass.suballocation.multisample.*.samples_4 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32848Tested-by:
-
- 12 Jun, 2019 7 commits
-
-
Chris Forbes authored
- It is acceptable to pass a larger array to these functions than you actually need. The functions are specified to overwrite the `count` parameter with the number of elements actually written. Previously we would assert in debug, or in release we would leave the input count unmodified, which would lead an app which uses this pattern to consider uninitialized junk to be valid elements. - It is acceptable to provide a pointer to a result buffer *and* a count of zero. This should return VK_INCOMPLETE if there are any elements. We mishandled this in physical device and physical device group queries. Bug: b/117974925 Test: dEQP-VK.api.info.* Change-Id: I2764831726bb4911ba4cab847fa4b404817508c5 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32749Reviewed-by:
-
Sean Risser authored
Currently we don't restrict any of the parameters (x, y, width, height) to glScissor aside from forcing width and height to be non-negative. This means large parameters can cause overflows during the scissor test. So we change width/height in the cases where an overflow will happen. Bug chromium:969071 Change-Id: Icb6992551aed6e3e086f96d89931eae0e99899a4 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32608 Presubmit-Ready: Sean Risser <srisser@google.com> Kokoro-Presubmit: kokoro <noreply+kokoro@google.com> Tested-by:
-
Nicolas Capens authored
The output registers and memory clobber were not being properly specified, which can cause incorrect compiler transformations when these functions are inlined cross-module via ThinLTO. Bug: b/135066502 Change-Id: I7031d5df2d9fe0f2712e65b98cfdf5b0990db598 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32748 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Kokoro-Presubmit: kokoro <noreply+kokoro@google.com> Tested-by:
-
Alexis Hetu authored
The code was using the LSB instead of the MSB. Added shifts to fix the issue. Change-Id: I6bdfc367c6daea98b0dd8878ea9c0076574206f5 Tests: dEQP-VK.renderpass.suballocation.multisample.a2b10g10r10_unorm_pack32.samples_4 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32789 Presubmit-Ready: Alexis Hétu <sugoi@google.com> Reviewed-by:
-
Tom Anderson authored
Needed to fix this build error with ToT gn: https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket.appspot.com/8911014495686240880/+/steps/analyze/0/stdout Gn does not know how to add a "*.lds" file in sources, and adding "libvk_swiftshader.lds" to sources does not have any effect on the generated ninja files. With ToT gn, this becomes an error. This CL changes the file to be added to inputs, which will cause the target to get relinked when the file changes. BUG=chromium:964411 R=capn Change-Id: Ib931f3ec886f06ad53cdc3b89d78e973e6b0aae3 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32628Tested-by:
Thomas Anderson <thomasanderson@chromium.org> Reviewed-by:
-
Nicolas Capens authored
The spec states that "Applications must not pass any other values than VK_TRUE or VK_FALSE into a Vulkan implementation where a VkBool32 is expected." So we should avoid the use of C++ true/false and literal 0/1 when dealing with VkBool32 values. Note that we test for 'condition != VK_FALSE' to evaluate whether the condition should be interpreted as true. This is both more efficient than testing for 'condition == VK_TRUE' and follows the principle of least surprise in the event an application does provide another value. Bug: b/134584057 Change-Id: I219172a2c538b0f0cb3f173ffd905adb8814b932 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32408 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Kokoro-Presubmit: kokoro <noreply+kokoro@google.com> Reviewed-by:
-
Sean Risser authored
Prior to this change, the OpenGL compiler accepted all "non-struct" "non-array" types for unary operations (++, --, and -). This ignored the existence of sampler objects. If someone tried to negate a sampler, then the compiler would tell the assembler to negate a non- numerical type. This change makes it so the GSL compiler only accepts unary operations on numerical types (including vectors and matrices). Also added a unittest that makes sure we gracefully fail to compile bad unary operations. Bug chromium:910883 Change-Id: Ia69056b31664900c3126cab42ecb8603d1a5d7db Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/32448Tested-by:
-
