- 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 3 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>
-
Alexis Hetu authored
This cl adds a verification before using the imageView stored within descriptor sets to make sure they still exist. These imageView objects are used to make sure images which require preprocessing (cubemaps and compressed images) are up to date. The device contains the list of active ImageView objects. Bug: b/163523811 Bug: b/152227757 Bug: chromium:1110549 Change-Id: I2e2190f2e61296ef3a2e4b699bda885d3a6595d9 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47588Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
Alexis Hétu <sugoi@google.com>
-
- 07 Aug, 2020 1 commit
-
-
SwiftShader Regression Bot authored
Reactor backend: LLVM Change-Id: I2bd569ebb5f74fd708e5d0f9598be1f6d445b863 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47468Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com>
-
- 06 Aug, 2020 6 commits
-
-
Nicolas Capens authored
Bug: b/162315264 Change-Id: I92cca44ad78aea9fcdcb8e0bc0f3c2c1ff28f19f Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47508 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
1D images were being treated as 2D ones with the second coordinate set to 0.0. It required other workarounds like moving the array layer coordinate and providing an addressing mode for the second coordinate. These have been removed, and the texel address calculation now ignores the second coordinate for 1D images. Note this doesn't specialize filtering for the 1D case yet, so the weights for filtering in the v-direction are explicitly zeroed out. Fixes: b/162858741 Bug: b/134669567 Change-Id: I4684ee0337ac500860e9939087045a953bad813a Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47428 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Chris Forbes <chrisforbes@google.com> Reviewed-by:
Alexis Hétu <sugoi@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com>
-
Nicolas Capens authored
Instead of reusing the 2D mipmap LOD calculation, this change adds a separate method for computing the LOD for 1D sampling operations. This also revealed that we would perform the anisotropic filtering calculations on 1D sampling operations if enabled, which makes no sense. This change limits it to 2D sampling only. Bug: b/134669567 Change-Id: I05dd3fe358eccfcd01ebcff35872f56c6f0b0b70 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47488 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Chris Forbes <chrisforbes@google.com> Reviewed-by:
Alexis Hétu <sugoi@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com>
-
Nicolas Capens authored
The array layer coordinate isn't subject to addressing modes like the other coordinates. There's just one selection computation: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#textures-unnormalized-to-integer This change eliminates the internally used ADDRESSING_LAYER mode, and avoids using the 'w' coordinate as the array layer coordinate for 2D array images (instead exclusively using it for 3D images). Also, the cube face index is combined with the array layer in case of cube array images. The division by 6 was eliminated by adjusting the descriptor 'depth' field instead. Bug: b/162315264 Change-Id: I4a541697ea265b3ad5b7d7c3a2420c045f46cbbe Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47388 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Chris Forbes <chrisforbes@google.com> Reviewed-by:
Alexis Hétu <sugoi@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com>
-
Nicolas Capens authored
- Sort the coordinates and operands in the same order as for the SPIR-V instructions. - Renamed 'q' to 'dRef'. - Used integer type for offset operands. - Renamed 'addressingModeY' to 'addressingModeA'. Note this is only used by cube array coordinates. 2D array coordinates use 'addressingModeW' at the moment. - Removed array layer coordinate parameter from 3D sampling. - Added 'dRef' operand for 3D sampling. Bug: b/162315264 Change-Id: Ia24aa22a57ba5507aa4c8cf617f49f18ccca59c5 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47097 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
This ensures that if the sample or layer coordinate were not forced to be in range but the 'valid' mask indicates whether they're in range, we sample texel 0 instead of potentially outside the image memory. Note this does not yet validate the sample coordinate. Bug: b/162419571 Change-Id: I08561862cbf371c1109c8949cd90557110d4ee24 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47228 Presubmit-Ready: Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Chris Forbes <chrisforbes@google.com> Reviewed-by:
Alexis Hétu <sugoi@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com>
-
- 04 Aug, 2020 3 commits
-
-
SwiftShader Regression Bot authored
Reactor backend: Subzero Change-Id: Ib5c1f626806c22e49be4e3cfb3286d87ad4bc749 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47448Tested-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Sean Risser <srisser@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com>
-
Dirk Pranke authored
I stumbled across this while bringing up the Chromium build under Python3. The change should allow the code to work under both 2 and 3 now. Bug: chromium:1112479 Change-Id: I5ae0cafdd453a12b53a0fa5392ad46cba60f4ed4 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47308Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com>
-
Nicolas Capens authored
This extension was never actually implemented. While it has been promoted to 'core' in Vulkan 1.1, the storageBuffer16BitAccess feature bit indicates whether or not the implementation supports the functionality. Bug: b/162742397 Test: dEQP-VK.info.device_mandatory_features Change-Id: I3e2871ce09975db3da2ad1f042d6955dbd565479 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47408 Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Sean Risser <srisser@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com>
-
- 03 Aug, 2020 1 commit
-
-
Nicolas Capens authored
Bug: docs update Change-Id: I0e0a596456d4c534adb6a8f57455d3cfb9cb65b9 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47289 Kokoro-Result: kokoro <noreply+kokoro@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Reviewed-by:
Sean Risser <srisser@google.com> Reviewed-by:
Nicolas Capens <nicolascapens@google.com>
-
- 02 Aug, 2020 1 commit
-
-
SwiftShader Regression Bot authored
Reactor backend: Subzero Change-Id: I25a37b74498d3a287ed8d78c6a16ca08c3973688 Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/47328Reviewed-by:
Nicolas Capens <nicolascapens@google.com> Tested-by:
Nicolas Capens <nicolascapens@google.com> Kokoro-Result: kokoro <noreply+kokoro@google.com>
-