Change-Id: Iff9400cabd5cbf8e7fcffb042c993e29a3acfdc7
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40608
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

Coroutines are emulated by using fibers.

Bug: b/145754674
Change-Id: I3f4bf29d26a75a2386ed812dd821d8a7a8276305
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40548Tested-by: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Previously, the builtins were only exposed in the SPIR-V scope.
This change utilizes the new `VariableContainer::extend()` functionality so that a single `VariableContainer` is created to hold all the builtins, and this is used as a base for the SPIR-V locals VC, as well as the high-level local scope VCs.

As part of this change, I've ditched the concept of non-per-lane builtins.
While some builtins are uniform across all lanes, having some at the top level of the watch tree, and others in the `Lane N` tree was just messy and complex to test.

Finally, a handful of builtins are also exposed for vertex shaders.

Bug: b/148401179
Change-Id: I53fedb716ab9337b0aca515768e114a8eef20f28
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40533
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

This allows VariableContainer to 'inherit' from one another.
Variables traversed and searched will try the direct VariableContainer, before falling back to searching the extended VariableContainers.

This allows for variable scopes to nest one another.

Bug: b/148401179
Change-Id: I58b317386d74ec54b9c1cc4fa223ef9cc50b160c
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40532
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

Bug: b/139412871
Change-Id: I7c6b59a19b6f2fdc6feb7420605c9e7935790a90
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40588
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

See b/148445528 for more information.

Fixes: b/148445528
Change-Id: I0740a5b0ce18db4c3ef0a55a9c679e1b64395b46
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40536Tested-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

This reverts commit 23b26ef1.

Reason for revert: Suspecting this cl of breaking the roll

Change-Id: I8a1c0e474de6bf0b04e37c0c3c15febf9ee137da
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40569Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

The sample locations were reordered "for fragment offset
computation". The reordering was causing some sample location tests
to fail.

Fixes SwANGLE tests:
dEQP.GLES31/functional_texture_multisample_samples_*_sample_position

Bug: b/147387937 b/139793135
Change-Id: I1a62d96517f2be0d625b9e9f8082d6f9e4c6a3f2
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40508Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

Unsuccessful routine creation is a bug that must be caught instead of
being silently ignored.

Bug: b/148295813
Change-Id: Ic718f0420d6833362944c96a3d172813eba3c207
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40568Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

Add Swizzle() intrinsics for Byte16, Byte8, and Byte4, and add Byte4
constructors and assignment operators. Also move LLVM-specific
implementations to the generic Reactor.cpp source file.

On x86 these all translate to a pshufb instruction, which is very
efficient.

Bug: b/148295813
Change-Id: Icf88fe1621623f8104c4a642d560643a01b9ef55
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40549
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>

Gives an overview of how to build and use the shader debugging functionality.

Bug: b/148373999
Change-Id: Ia884379aac03bf40b27c298a909ea2961fe643aa
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40531Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

VK_EXT_shader_stencil_export is a trivial extension to implement in
SwiftShader. Added PixelRoutine::stencilReplaceRef(), which can be trivially
modified to output Byte4 instead of Byte8, should the stencil code be
refactored.

Verified that these tests still pass with SwANGLE
dEQP-GLES3.functional.fbo.blit.depth_stencil.depth32f_stencil8_basic
dEQP-GLES3.functional.fbo.blit.depth_stencil.depth32f_stencil8_stencil_only
dEQP-GLES3.functional.fbo.blit.depth_stencil.depth24_stencil8_basic
dEQP-GLES3.functional.fbo.blit.depth_stencil.depth24_stencil8_stencil_only

Change-Id: I0cd8ca7310fc5a5130e05fdb546370fc7f31210b
Tests: dEQP-VK.pipeline.shader_stencil_export.op_replace
Bug: b/148175198
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40488
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

VK_SUBOPTIMAL_KHR is a success code so it should not override failure
codes, but should not get replaced by a VK_SUCCESS result itself.

Bug: b/144766511
Change-Id: Ie7721fb3afc36f0b15579deff79dc9bdc9146cd0
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40308
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Bug: b/144766511
Change-Id: I83da9b20422ef546fcc8fa27cd8d17399b275345
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40290
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Nucleus::createConstantVector was implemented in terms of Subzero's
globals API; however, once we generate multiple functions, these globals
end up with incorrect addresses in the jitted code. For now, replacing
this usage of globals with using externally provided (and allocated)
memory via Routine::addConstantData.

We can go back to using globals once we fix the problem (b/148086935).

Also, this change fixes a problem with loading from a constant pointer,
which Subzero interprets as a load with offset. We fix this by casting
to a non-const variable when loading.

Bug: b/145754674
Change-Id: I6e15385de134d385036eef3e9a255bf0738e4d44
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40451Tested-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>

* Most use Subzero intrinsics, except for Min/MaxAtomic, which are
emulated.
* Added unit tests for each implemented function, but am not really
testing that they behave as atomic functions. Only that they perform the
expected operation.

Bug: b/145754674
Change-Id: Ie3ec6e473ee8b448b28bf440da094ac03ac0005b
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/39829Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>

This uses regres' test runner, without all the Gerrit functionality.
A faster, less frustrating version of dEQP's --deqp-caselist-file.

Kudos to paulthomson@ who did all the work here.

Change-Id: I1de26e731b197af64aeb60c79da0b75fe13cb338
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40529Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

A directory should only contain either library code, or contain a single `main`.

Attempting to have two main packages upsets the go tools.

Add a `run.sh` bash script in the root regres folder to `go run` the `cmd/regres/main.go` file, to keep usage simple for non-go people.

Change-Id: Ia37ce9a64e1e1a7e23ee3336e6e312cef9e63a9f
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40528
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

Subzero emits incorrect code for FRem operations on vectors. Replace
with an emulated version that calls fmodf on each component for now.

Bug: b/148139679
Change-Id: Ib541370b71b99649f8c73f982fd12cb3cde25e7f
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40450
Presubmit-Ready: Antonio Maiorano <amaiorano@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

The parent change replaced all UNIMPLEMENTED() with UNSUPPORTED(), since
we are now Vulkan 1.1 conformant and the majority of these
UNIMPLEMENTED() uses was for functionality that is not mandatory to
still implement and is instead part of a currently unsupported feature.

This change conservatively restores uses of UNIMPLEMENTED() for things
that we might hit with correctly behaving apps. Bugs will be filed for
each of these and tests will be added where necessary to provide
coverage of these code paths.

Bug: b/131243109
Change-Id: Iaf547983c8495ad8d6d0c783a4c656273d8c0195
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40409
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Most cases of UNIMPLEMENTED() are actually for functionality that we do
not support, and correctly advertise as such. It's expected to be an
application bug if these asserts are hit, and not an indication of
something we must still implement to be a compliant Vulkan
implementation.

This change will be immediately followed up by one which restores
UNIMPLEMENTED() where it was used correctly. This two-change approach
makes it much easier to see what still needs to get done.

Bug: b/131243109
Change-Id: Id09b5de5bc73fabfdc3199dcd3091cb72283be65
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40408
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Change-Id: I1ac2376f37c4562fa1e7bdfc86663ac9d09cbf27
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40428
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolas.capens@gmail.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

Bug: b/142965928
Change-Id: I0c2e7054d51a1dd3d1e0915384b5cfbdaffda178
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40349
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Previously the rasterizer was just using sample location 0. The Vulkan
1.1.130 spec states that "When VK_LINE_RASTERIZATION_MODE_BRESENHAM_EXT
lines are being rasterized, sample locations may all be treated as being
at the pixel center". And also "Do we need to support Bresenham-style
and smooth lines with more than one rasterization sample? RESOLVED: Yes.
For simplicity, Bresenham line rasterization carries forward a few
restrictions from OpenGL, such as not supporting per-sample shading,
alpha to coverage, or alpha to one."

Bug: b/142965928
Change-Id: I586ffbaa92d506595d6fecfa2dbd64f10bdee0c8
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40188
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

As with 888 and 1010102, 565 and 5551 need to be rounded before being written.

Bug: b/146633956
Change-Id: Ifea2e8f187a276a1f49effedc377612dbe338057
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40368
Presubmit-Ready: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Alexis Hétu <sugoi@google.com>

Only use the condition in the `endif()` if:
• The opening `if()` is more than 20 lines away.
• The `endif()` doesn't belong to an `elif()`.

Also remove redundant sequences of `endif(SWIFTSHADER_BUILD_TESTS)` `if(SWIFTSHADER_BUILD_TESTS)`

Bug: None. Style bikeshedding
Change-Id: I967948a2afdedbd503add5addffc666c698eb885
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40468
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

Only wait when the `VK_WAIT_FOR_DEBUGGER` env var is set.
Long term I want to move away from relying on environment variables, but this is currently consistent with the `VK_DEBUGGER_PORT` env var which also enables the debugger.

Bug: b/148135662
Change-Id: I990d907d7570569e9d6716cf5d13e9846f4a5c02
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40429Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Outer projects may already build this target, in which case we don't want to build it again.

Bug: b/148010928
Change-Id: I19eea95eb81f13495268f5109d5554ef16033598
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40330Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

This allows outer projects to force-set these build options without exposing them in CMakeCache.txt

Bug: b/148010928
Change-Id: Ib7d3965c04cf9822566ed569af9832db30f133b1
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40329
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

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." However, in case applications do use other values, the
least surprising behavior is for non-0 values to be interpreted as true.

Bug: b/134584057
Change-Id: I861691442683d534b4e34bd55deb18643adb3a99
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40448
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Vertex input buffers only support VK_FORMAT_A2B10G10R10_UNORM_PACK32.
This cl adds all the signed and integer variants of that format.

This cl also removes StreamType and replaces it with VkFormat.

Tests: dEQP-VK.*r10*
Bug: b/142661203
Change-Id: I996705395cbb493c599e1a460a6368a7e00d5a55
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40348Tested-by: Alexis Hétu <sugoi@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

The pipeline code doesn't need to know whether we're drawing Bresenham
lines or anything else. It just needs to know whether or not to enable
multisample rasterization for a multisample render target.

Also rename multiSample to multiSampleCount.

Bug: b/142965928
Change-Id: I34395e90d502c49cd13e0087d4b323d222cb2064
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40169
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Just a refactoring to improve syntax and avoid non-const references.

Also don't assume SIMD types are 4-wide.

Also add [[fallthrough]] cases found in the process.

Bug: b/143351714
Bug: b/142661203
Change-Id: I12a0178338ce4c711bcbf62825d230580f3e92f0
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40288
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

This is widely supported by other Vulkan drivers, and there's no reason
these formats should be different from other ones when it comes to
linear filtering.

Bug: b/147586576
Change-Id: I43c8e4a65ab001c85f6c3621487a634f302d21a1
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40250Reviewed-by: Alexis Hétu <sugoi@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>

To be consistent with https://swiftshader-review.googlesource.com/39050

Bug: b/145746360
Change-Id: I153999887e833da5c0e44277ccc71f529a412299
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40289Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

This is a first, rough, implementation of the OpenCL.Debug.100 extension instruction set.

This is incomplete, and likely buggy.

It does however implement enough to perform single line stepping through hand-crafted HLSL, with basic variable inspection.

Many tests and fixes to come...

Bug: b/145351270
Change-Id: Ia570f5b22a8b3ce39df0438ca3c6700d1a00d014
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40268Reviewed-by: Antonio Maiorano <amaiorano@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Ben Clayton <bclayton@google.com>

Remove it root and stem to ensure there can't be any usage of it, since
it cannot be efficiently supported by ANGLE with SwiftShader Vulkan
without major changes.

Bug: b/147536183
Bug: b/147762087
Change-Id: Ib413e7c7f8d13ee22a5201e34163f592db572d86
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40112
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Warning for a switch statement with 'default' but no 'case labels.
This warning is triggered in the ANGLE CQ and blocking a sws roll.

Bug: angleproject:4299
Change-Id: Id8d98c124e19b6a6834beb9a643b182e2d5876e7
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40248Tested-by: Jonah Ryan-Davis <jonahr@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

Optimization passes are likely to damage debug information, and reorder instructions. We will likely never want to optimize shaders inside the driver when debugging.

SPIR-V tools currently has a number of issues consuming shaders that use the OpenCL.Debug.100 extension instructions which need to be fixed before these instructions can be passed to it. For now, just disable shader pre-processing when we are debugging.

Bug: b/145351270
Change-Id: I71827c2bb7cf34ecfd7e55b0ca8b3189e460b150
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40130
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

On a 4-core Linux VM it has the following effect:

LESS_DEBUG_INFO=0
real	20m13.051s
user	63m45.648s
sys	6m51.636s
745.8 MB libvk_swiftshader.so
13 GB build dir

LESS_DEBUG_INFO=1
real	15m2.821s
user	51m8.659s
sys	5m17.466s
197.8 MB libvk_swiftshader.so
3.1 GB build dir

Also use /DEBUG:FASTLINK on Visual Studio. It disables producing a
single .pdb which can be relocated.

Specifying LESS_DEBUG_INFO=1 has no effect on Windows currently, but is
done for consistency and in case we start using Clang on Windows.

Also color errors in presubmit consistently.

Bug: b/147735529
Change-Id: Ieb5c84c192178653f74043daf3d8ee599d3ecf6b
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/40228
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>