- 11 Sep, 2020 1 commit
-
-
Nicolas Capens authored
In GLSL ES 3.00, float literals are allowed to have an 'f' or 'F' suffix, but they don't change the parsing process since they're always interpreted as single-precision IEEE-754 floating-point values. The std::istringstream used for parsing the literal's string can have implementation dependent behavior depending on the presence of the suffix, so this change removes it. This matches what ANGLE does. Fixes: b/168250854 Change-Id: I203833a2e817ca698894db5669941fb435b97868 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/48388 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Antonio Maiorano <amaiorano@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com>
-
- 10 Sep, 2020 1 commit
-
-
Jaebaek Seo authored
Based on OpenCL.DebugInfo.100 spec, if the function has no return value, 'Return Type' operand of DebugTypeFunction is OpTypeVoid. Bug: b/148401179 Change-Id: Ib29c7a569ff2ec24ba4667523766b0bdb0d6f260 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/48128 Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Ben Clayton <bclayton@google.com> Tested-by:
Jaebaek Seo <jaebaek@google.com>
-
- 09 Sep, 2020 4 commits
-
-
Alexis Hetu authored
A VulkanGlass synchronization fix now allows us to run it in debug without asserting on a validation layer error, so updating to ToT. Bug: b/141361933 Change-Id: I8b2ebff6b5d822370d7b62afdf6845d1736c1a1b Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/48289 Presubmit-Ready: Alexis Hétu <sugoi@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Tested-by:
Alexis Hétu <sugoi@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com>
-
Nicolas Capens authored
Constant arrays are allocated in the same 'register file' as the one for per-program uniforms, to support dynamic indexing. While we had a special case for that in OutputASM::registerType(), in registerIndex() we were actually allocating them in the temporaries register file. This led to assigning the same register index range twice, leading to overwriting the per-program uniforms with constant array data in the shader. Bug: b/168060171 Change-Id: If42944d186ed1c1328a8d477edca4662aa1e8e54 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/48248 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>
-
Nicolas Capens authored
Unlike image views, buffer views don't have a component mapping field, so we were setting the mapping to identity swizzles for uniform texel buffers. However, we also use the component mapping for assigning 0 or 1 to components not provided by the texel format: https://swiftshader-review.googlesource.com/c/SwiftShader/+/31388 This change ensures we still get the 0 and 1 in the desired channels for uniform texel buffers. Bug: b/168052622 Test: dEQP-VK.texture.texel_buffer.uniform.packed.b10g11r11-ufloat-pack32 Change-Id: I40885f998a53e371e1e2358ed197fc3446916d8c Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/48268Tested-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Alexis Hétu <sugoi@google.com>
-
Alexis Hetu authored
Added missing case for a single sample with alphaToCoverage enabled Change-Id: Iad9234fdd30d64c60ae189c123564a0423ab12df Tests: dEQP-VK.rasterization.frag_side_effects.color_at_* Bug: b/168046415 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/48209 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>
-
- 07 Sep, 2020 1 commit
-
-
Nicolas Capens authored
Commit "Merge vk-gl-cts/vulkan-cts-1.2.4 into vk-gl-cts/master" Revision https://chromium.googlesource.com/external/github.com/KhronosGroup/VK-GL-CTS/+/5e85f689b91102b012ab4c4278f46efeb6214381 Branch https://chromium.googlesource.com/external/github.com/KhronosGroup/VK-GL-CTS/+/refs/heads/master Includes fix for flaky failure of dEQP-VK.wsi.*.swapchain.acquire.too_man*: * Fix creation of signaled fences in swapchain tests https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2505 New notable test coverage: * Add coverage for negative float to clear color values https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2360 * Execute the graphics/compute pipeline https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2325 * Add tests for shader reuse with differing layout https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2324 * Enable random writes for dynamic storage buffers https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/1973 * Check per-sample copy results in multisample copy tests https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2448 * 1D and 3D image copy and blitting tests https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2391 * Support for VkPhysicalDeviceVulkan1{1,2}Properties in framework https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2425 * Test 3D image blit with differing depth https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2263 Bug: b/167692239 Fixes: b/162249856 Change-Id: I9d8933999e29a2702ce0990c7f426f6350c9ed3d Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/48149Tested-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Alexis Hétu <sugoi@google.com>
-
- 04 Sep, 2020 1 commit
-
-
Nicolas Capens authored
https://gitlab.khronos.org/vulkan/vulkan/-/merge_requests/3399 clarified that when identity component swizzle is expected, one can also use the corresponding component enum. Fixes: b/167706626 Change-Id: I2c94f6ac108be5269d56f397ecf3da58cd310e5e Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/48168Tested-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Sean Risser <srisser@google.com> Reviewed-by:
Alexis Hétu <sugoi@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com>
-
- 03 Sep, 2020 3 commits
-
-
Nicolas Caramelli authored
Bug: b/162351826 Change-Id: Idd8e6c869ffa99945e7a6bc7701a7ab854f18432 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47188 Kokoro-Result: kokoro <noreply+kokoro@google.com> Presubmit-Ready: Alexis Hétu <sugoi@google.com> Reviewed-by:
Alexis Hétu <sugoi@google.com> Tested-by:
Alexis Hétu <sugoi@google.com>
-
Alexis Hetu authored
DescriptorPool::computeTotalFreeSize() was adding the size of the last element to its available memory size, rather than subtracting it, which was causing the DescriptorPool to return the wrong error (VK_ERROR_FRAGMENTED_POOL instead of VK_ERROR_OUT_OF_POOL_MEMORY). Bug: b/167617619 Change-Id: Ie60c2fe521b0d233b32504b446af1715361f5c21 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47549Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
Alexis Hétu <sugoi@google.com>
-
Alexis Hetu authored
This cl fixes GCC warnings caused by using clang specific directives. Also ran git cl format on modified files. Bug: chromium:1122889 Change-Id: Ibdaa84ab8162228ae40934fc9be14379ba89ca59 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/48148 Presubmit-Ready: Alexis Hétu <sugoi@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Tested-by:
Alexis Hétu <sugoi@google.com>
-
- 02 Sep, 2020 2 commits
-
-
Nicolas Capens authored
The SPIR-V spec states that the Sample operand of OpImageTexelPointer "must be a valid <id> for the value 0 if the OpTypeImage has MS of 0." This change optimizes for this common case by no performing texel address sample offset and bounds check calculations. Bug: b/163142358 Change-Id: I75932c264d45df1012fa8451fc4c57671191b59b Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47808 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>
-
Sean Risser authored
Due to a defect in older versions of libstdc++, the std library could not support hashing of enums. So each enum used in a hash is now explicitly used as a uint32_t. Bug: b/166302706 Change-Id: Id7de96f97bef0e6f104dc783115a416e3aa47b7c Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/48108 Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
Sean Risser <srisser@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com>
-
- 01 Sep, 2020 5 commits
-
-
Nicolas Capens authored
Shifting a 32-bit value by 32 or more is undefined behavior in C++. This previously happened in this code when converting a 32-bit float value to an 11- or 10-bit minifloat which is too small to be represented as a denormal, and should produce 0 instead. Instead of going through this arithmetic for denormals, just test whether the input value is too small to produce a valid denormal, and return 0 instead. Bug: chromium:1117433 Change-Id: I8149996fb6d66d328db45725c4cdb81dc7826a10 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/48069 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>
-
Nicolas Capens authored
The reference code for conversion from 32-bit floating-point to 11- and 10-bit minifloat formats supports producing denormals for values smaller than what can be represented as normalized representations. The arithmetic can underflow to produce zero for values too small to be represented as denormals. This arithmetic contains a 32-bit shift operation which can shift by an amount greater than 32, which has undefined behavior in C++ but produces zero on x86 processors. This change adds unit tests for the intended behavior around the cutoff between the smallest denormal, and zero, to help validate the fix for the UB in a future change. Bug: b/147900455 Bug: chromium:1117433 Change-Id: Ic5e495dd822231d52a5551ee12733a616728d486 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/48068Reviewed-by:
Antonio Maiorano <amaiorano@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com>
-
Nicolas Capens authored
While our generic Blitter routine can handle resolving any multisample format into any other format, the 'fastResolve()' method performs simple per-component sample averaging, thus assuming the input and output formats are identical. This is also demanded by the Vulkan specification: - vkCmdResolveImage: "srcImage and dstImage must have been created with the same image format." - VkSubpassDescription: "each resolve attachment that is not VK_ATTACHMENT_UNUSED must have the same VkFormat as its corresponding color attachment." This change adds an assert which would catch violations of that. Bug: b/147802090 Change-Id: I23d2d463efbbaed04a782a0cf61b255bf1c25b03 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/48088 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>
-
Jaebaek Seo authored
Bug: b/148401179 Change-Id: I24879b32d65bed5a4380a444bbcaa5794cfd6d85 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47929 Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
Jaebaek Seo <jaebaek@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com>
-
Jaebaek Seo authored
Bug: b/148401179 Change-Id: I89023b33b01bca848f44bda1f77c49496a9419af Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47931 Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
Jaebaek Seo <jaebaek@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com>
-
- 28 Aug, 2020 4 commits
-
-
Nicolas Capens authored
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 0.845 ms 0.439 ms 1673 Triangle/Multisample 6.95 ms 0.781 ms 1000 (LLVM, after) Triangle/Hello 0.861 ms 0.450 ms 1493 Triangle/Multisample 4.03 ms 0.753 ms 747 (Subzero, before) Triangle/Hello 1.19 ms 0.474 ms 1120 Triangle/Multisample 11.8 ms 0.920 ms 747 (Subzero, after) Triangle/Hello 0.907 ms 0.486 ms 1673 Triangle/Multisample 4.62 ms 0.781 ms 1000 Bug: b/147802090 Change-Id: Iea8498f2b745c86cf578db5c0f7ef2329b73c736 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47970 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>
-
Nicolas Capens authored
For whole-image 4x8-bit normalized format multisample resolves, use a specialized code path instead of a generic blit routine. 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 1.02 ms 0.500 ms 1000 Triangle/Multisample 19.3 ms 0.984 ms 1000 (LLVM, after) Triangle/Hello 0.845 ms 0.439 ms 1673 Triangle/Multisample 6.95 ms 0.781 ms 1000 (Subzero, before) Triangle/Hello 1.15 ms 0.516 ms 1120 Triangle/Multisample 40.3 ms 0.469 ms 100 (Subzero, after) Triangle/Hello 1.19 ms 0.474 ms 1120 Triangle/Multisample 11.8 ms 0.920 ms 747 Bug: b/147802090 Change-Id: I15729552f01a509a5cfce20cd7de06d0b764cf0a Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47969 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Alexis Hétu <sugoi@google.com>
-
Nicolas Capens authored
The Vulkan spec explicitly states that "vkCmdBlitImage must not be used for multisampled source or destination images. Use vkCmdResolveImage for this purpose." And the only other way to obtain resolve multisample results is by using resolve attachments as part of a subpass. This split between blit operations and resolve operations should be reflected by the Blitter interface so we have less confusion about its blit() method being used to perform resolves. It will also facilitate adding a fast path for common resolve operations. Bug: b/147802090 Change-Id: I2549a5e7acd7ef9ec3f70f8ceb88ff5fc65a0d17 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47988 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>
-
Nicolas Capens authored
Microsoft Visual Studio Community 2019 Version 16.7.1 produced the following errors: C2976 'llvm::SmallVectorTemplateBase': too few template argument SwiftShader\third_party\llvm-10.0\llvm\include\llvm\ADT\SmallVector.h:315 C2338 inconsistent behavior between llvm:: and std:: implementation of is_trivially_copyable SwiftShader\third_party\llvm-10.0\llvm\include\llvm\Support\type_traits.h:181 Not defining LLVM's HAVE_STD_IS_TRIVIALLY_COPYABLE config makes it fall back to code which doesn't use std::is_trivially_copyable and avoids the issue. Note this may hide a potentially serious MSVC compiler bug since C2338 is produced by a static_assert. Without that static assert we may not have known about the unexpected std::is_trivially_copyable behavior until run-time issues are caused by it. Bug: swiftshader:153 Change-Id: I04ab6d8ae725ecab45ac27fd89a37213baa86943 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47930 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>
-
- 27 Aug, 2020 1 commit
-
-
Sean Risser authored
This function reports on a Vulkan driver's fine grained capabilities. A previous change broke some functionality in ANGLE. This is an update to that reverted patch. Bug: b/162404391 Change-Id: Ief91bac28e3ee9a7d775616c1663650e70c49b3e Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47891Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
Sean Risser <srisser@google.com>
-
- 26 Aug, 2020 3 commits
-
-
Nicolas Capens authored
Previously Image::getMipLevelExtent() was the only way to retrieve the extent of an image, which didn't make sense for images for which we're not accessing the mipmaps, like framebuffer attachments. A getExtent() method was added for these cases where we only need the full extent. Bug: b/162315264 Change-Id: I9c2b8ed42cbbd573e5a08f4bfafc4653ad377f7f Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47928 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Antonio Maiorano <amaiorano@google.com>
-
Nicolas Capens authored
Image views are only accessed by shaders, and we've previously ensured descriptors only have one field for holding either the depth of a 3D texture or the array layer count. This value is accessed through the getDepthOrLayerCount() method, and so the getMipLevelExtent() of the ImageView class only has to return the 2D extent. Bug: b/162315264 Change-Id: I93dd5bbabcd7efc8aa174beb38204e900c8be614 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47789 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Antonio Maiorano <amaiorano@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com>
-
Nicolas Capens authored
OpImageQuerySize[Lod] SPIR-V instructions were previously implemented by storing both the image depth and layer count in the descriptor. Since 3D textures can't be arrayed, we only need one field. Also avoid the division by 6 for cube array layers in the instruction implementation, by performing it during the descriptor update instead. This reflects a similar change made by https://swiftshader-review.googlesource.com/c/SwiftShader/+/47388 Bug: b/162315264 Change-Id: Iaa787e6c131eec2da7e4a404743ef722423305d5 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47688 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>
-
- 21 Aug, 2020 3 commits
-
-
Sean Risser authored
This reverts commit 44e1791f. Reason for revert: Broke ANGLE, need to patch Change-Id: I98cb807b0e18bf7df2d9ba51893d65ad5a8eba6d Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47890Reviewed-by:
Alexis Hétu <sugoi@google.com> Tested-by:
Sean Risser <srisser@google.com>
-
Maksim Sisov authored
We're making a new config in the Chromium project for Linux builds - USE_X11 && USE_OZONE. The idea of that is to ease migration from non-Ozone/X11 to Ozone. It will be possible to choose between Ozone and non-Ozone path on runtime by supplying the --enable-features=UseOzonePlatform flag. However, SwiftShader doesn't support such a build and always uses FrameBufferOzone. This is not correct when the browser is run without the Ozone feature enabled aka using old non-Ozone/X11 path. Basically, it results in crashes during swap buffers call. The very naive solution is to try to test the display. If we can cast it to XDisplay and its valid, use X11 framebuffer. Otherwise, use Ozone. Though, I'm not 100% sure about the safiness of this check. Thus, we must be careful about that. This is one of the last patches that blocks enabling both use_x11 && use_ozone in Chromium. Bug: chromium:1119303 Change-Id: I969798abd4d0bbacaffb7704161eac38e77d9311 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47868Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Tested-by:
Maksim Sisov <msisov@igalia.com>
-
Nicolas Capens authored
Previously we were checking whether all attachments have a format which requires clamping. We now support the independentBlend feature, and independent clamping, so we can optimize the blend state more granularly and not miss opportunities. Bug: b/140193782 Change-Id: I7e663fd8ebc6a7a6e35133c0c4c5cad84278eeb3 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47828 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>
-
- 20 Aug, 2020 1 commit
-
-
Sean Risser authored
This function reports on fine-grained Vulkan features and extensions. Bug: b/162404391 Change-Id: Ifbb423a6fcb9134801eed112117a602f231e6685 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47349Reviewed-by:
Alexis Hétu <sugoi@google.com> Tested-by:
Sean Risser <srisser@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com>
-
- 18 Aug, 2020 1 commit
-
-
Alexis Hetu authored
The cfi bot is throwing an error because an object is being assigned with memory containing an invalid vtable. This is caused by assigning a chunk of memory to an object before calling placement new using that memory. This cl assigns the pointer after the object has been constructed to avoid triggering this error. Bug: chromium:1116053 Change-Id: I541d7dc0e884aed7470b97d7d1d91a9bb67edb2d Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47788Tested-by:
Alexis Hétu <sugoi@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com>
-
- 17 Aug, 2020 2 commits
-
-
Antonio Maiorano authored
Change-Id: Icd01356c6bfaf644112a6ca9cb92b8fc62be5291 Bug: b/149490161 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47769Tested-by:
Antonio Maiorano <amaiorano@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com>
-
Nicolas Capens authored
LLVM 11 deprecates the default boolean parameter which indicates whether vector types are variable-length. Explicitly pass 'false'. LLVM 11 introduces a FixedVectorType for this as well, which would help readability, but we're still at LLVM 10. Bug: b/165000222 Change-Id: I5404cfc8eea9553e15bfb54b2d3278bdf079612f Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47768 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>
-
- 13 Aug, 2020 2 commits
-
-
SwiftShader Regression Bot authored
Reactor backend: Subzero Change-Id: I588fa875260f29e32441ac8943f4cff5a4466541 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47670Reviewed-by:
Alexis Hétu <sugoi@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com>
-
Nicolas Capens authored
This fixes a bug in the descriptor data where the sample pitch was set to the layer pitch for array images (it should always be the slice pitch), and the descriptor's slice pitch (which stores the layer pitch in case of array images), was taking the sample count into account twice. Note that while the image robustness extensions still allow read operations to return undefined values "if only the sample index was invalid", so clamping that value would suffice (as currently done in our OpImageFetch implementation), write operations always have to be no-op. This change also 'nullifies' the OpImageRead instructions for invalid sample indices. Bug: b/163142358 Tests: dEQP-VK.* Change-Id: I9d816c249e14a17722d29f56015c8dc8cc7d51d4 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47548 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Reviewed-by:
Alexis Hétu <sugoi@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com>
-
- 12 Aug, 2020 3 commits
-
-
Alexis Hetu authored
Cubemap textures are created with a border, which means that their size is larger. Their range is also different. Instead of [0, dim-1], they have a [-1, dim] range. This means that if we copy them starting at [0, 0] for their full size, we'll overflow at the end, since the buffer starts at [-1, -1]. This cl prevents going through the fast copy path when we have a border. Bug: chromium:1115345 Change-Id: I333acfd6094645231eb111634359d82ed3d5c787 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47668 Presubmit-Ready: Alexis Hétu <sugoi@google.com> Reviewed-by:
Corentin Wallez <cwallez@google.com> Reviewed-by:
Chris Forbes <chrisforbes@google.com> Tested-by:
Alexis Hétu <sugoi@google.com>
-
SwiftShader Regression Bot authored
Reactor backend: Subzero Change-Id: I1e324936838183d91c0f715fe352ab9413b71e79 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47568Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Alexis Hétu <sugoi@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com>
-
Alexis Hetu authored
Block members were getting decorations applied from all previous block members. For example, in this case: in InterfaceBlock { layout(location = 0) in vec4 in_color_smooth; layout(location = 1) in flat vec4 in_color_flat; layout(location = 2) in noperspective vec4 in_color_noperspective; layout(location = 3) in centroid vec4 in_color_centroid; } - the member at location 2 would get decorated with both flat and noperspective - the member at location 3 would get decorated with both flat, noperspective and centroid I added a local variable for the member decorations in order to not bleed information between block members. Bug: b/163600604 Change-Id: I6b79609f19ae2f2f48909af929f798a48b4cde34 Tests: dEQP-VK.draw.multiple_interpolation.structured.* Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47649 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>
-
- 11 Aug, 2020 2 commits
-
-
Alexis Hetu authored
With the assertion for these tests fixed here: https://gerrit.khronos.org/#/c/6075/ The *.too_many test passed locally, but not the *.too_many_timeout test. The reason is that, when a timeout is provided, the acceptable return value for failing to acquire an image is VK_TIMEOUT, not VK_NOT_READY. Returning VK_TIMEOUT when a timeout is provided solves the issue. Bug: b/162249856 Change-Id: Id2733fec8422aad93a1aa351b481691c69692168 Tests: dEQP-VK.wsi.*.swapchain.acquire.* Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47648 Presubmit-Ready: Alexis Hétu <sugoi@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
Alexis Hétu <sugoi@google.com>
-
Nicolas Capens authored
This extension allows the viewport's minimum and maximum depth to be outside of the 0.0 to 1.0 range: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_EXT_depth_range_unrestricted.html Note that while most extensions don't change the behavior of the logical device whether they're enabled or not (since they just allow new calls, enums, or values which are otherwise undefined behavior and implementing the functionality of the extension is valid as "undefined" behavior), enabling/disabling this extension does cause an observable difference. Bug: b/163135814 Tests: dEQP-VK.*depth_range_unrestricted* Change-Id: I418a2e7226140719af08601d8919f4cdbc7a237c Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47608 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>
-