Compiles and links shaders that perform deep nesting of control blocks and calls.

Bug: b/123587120
Change-Id: I8f19611cbe6d36990ad368a600d2d5be20b1ea07
Reviewed-on: https://swiftshader-review.googlesource.com/c/24728Tested-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

Not longer needed after https://swiftshader-review.googlesource.com/c/SwiftShader/+/24668

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

Perform whole-shader analysis to determine usage limits.
Use these limits to allocate compile time and runtime arrays.

Removes the constants:
	MAX_SHADER_NESTED_LOOPS
	MAX_SHADER_NESTED_IFS
	MAX_SHADER_CALL_STACK_SIZE

Also switched to using dynamic containers to remove the MAX_SHADER_CALL_SITES limit, which I believe to have been buggy and broken.

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

This makes WalkAccessChain slightly easier on the backend -- there is
less constant folding to do.

Bug: b/124388146

Change-Id: I4e76c3e494278e1399b8a86134b652c2a6d96d8c
Reviewed-on: https://swiftshader-review.googlesource.com/c/24988Tested-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

There was an optimization that skipped a [0, 1] clamp for a particular sampling mode as it assumed
the input coordinates were always within these bounds.

However, if the texture sample coordinates were inf or NaN, this assumption broke, causing the
returned address to be outside the bounds of the image data.

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

Don't hold a pointer to the structure - there's no guarantees it'll still be vaild by command buffer execution time.

Fixes flakiness of the dEQP-VK.memory.pipeline_barrier.transfer_dst_storage_image.* tests

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

There's no reason to have any limitation on granularity in
SwiftShader, so the granularity is always 1 pixel.

Passes all tests in:
dEQP-VK.api.granularity

Bug b/119620965

Change-Id: Ie2f09737c0054da1b6806b9572e515446a8b1263
Reviewed-on: https://swiftshader-review.googlesource.com/c/24890Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>

When constructing a Graphics pipeline, some structures may or may
not exist, depending on what will be used by the render pass. These
structures (viewportState, multisampleState, depthStencilState and
colorBlendState) are now checked before being used, since it is
allowed for these to be null.

Bug b/118386749

Change-Id: If2759ae2554a98143b30e70624a0dc8d88c5bd43
Reviewed-on: https://swiftshader-review.googlesource.com/c/24911Tested-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Bug: b/124388146
Change-Id: I2c422dc2f85730f4c4bef45388e77028465ea9ba
Reviewed-on: https://swiftshader-review.googlesource.com/c/24828Tested-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

- Provides a point to complain if something is not yet defined.
- Allows avoiding ugly syntax from use of unique_ptr

Bug: b/124388146
Change-Id: Ib55023fff5c90b71a41c5f558544be65250bb67d
Reviewed-on: https://swiftshader-review.googlesource.com/c/24791Tested-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>

Bug: b/124388146
Change-Id: I948ad5607c1e41be920006aaa4b7d18d210af4a3
Reviewed-on: https://swiftshader-review.googlesource.com/c/24790Tested-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Bug: b/124388146
Change-Id: Ia3c4e6c81432dcfbca5bdd21c857108ee14bda9b
Reviewed-on: https://swiftshader-review.googlesource.com/c/24788Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Bug: b/124388146
Change-Id: I79b4c3bc59631332f4748394a166612ad5d975de
Reviewed-on: https://swiftshader-review.googlesource.com/c/24600Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

I need to also walk interface objects in shader prolog & epilog; will
reuse this logic.

Bug: b/124388146
Change-Id: Ida735f58aa1bc36d83e4a6ea3c16925a9c5656b0
Reviewed-on: https://swiftshader-review.googlesource.com/c/24808Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Bug: b/124388146
Change-Id: I17531e47fc6fc4b296f893f94beb75f471847fd3
Reviewed-on: https://swiftshader-review.googlesource.com/c/24789Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Bug: b/124388146
Change-Id: Id528368106eb0d09930ff4fccbe94704b585a531
Reviewed-on: https://swiftshader-review.googlesource.com/c/24599Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>

These are our first instructions which yield ssavalues.
For OpAccessChain, also track the base pointer (which we always know at
compile time, until we do full variable pointers support).

The value representation for OpAccessChain's result has two parts:
- per-lane Int offset into whatever the thing is
- shared (and statically known) base reference.

Bug: b/124388146
Change-Id: I364375719b6e396b802de06093454c8f0e76adb6
Reviewed-on: https://swiftshader-review.googlesource.com/c/24598Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>

Most of these are "we know we can just ignore this instruction", but
also sanity check for the lowering passes applied before this -- if any
of those instructions remain, then we're very likely to do the wrong
thing.

Bug: b/124388146
Change-Id: I3f8f66121f57f20cc93abdbd26c575baf03d9c94
Reviewed-on: https://swiftshader-review.googlesource.com/c/24597Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>

Bug: b/124177079
Change-Id: Ibe657d802c38b84bf2017a8aeaf38f887910bc60
Reviewed-on: https://swiftshader-review.googlesource.com/c/24596Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>

This can be queried directly from the shader

Bug: b/124177079
Change-Id: I08aac7f77fb59f005295de3d417d24bf61fb3906
Reviewed-on: https://swiftshader-review.googlesource.com/c/24595Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>

Bug: b/124177079
Change-Id: I20132ffd5f73c19715393740c27f77e71a3c3c88
Reviewed-on: https://swiftshader-review.googlesource.com/c/24594Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Bug: b/124177079
Change-Id: I8dac28d2c55ce1c4eb9a815bfad56ba917be32c5
Reviewed-on: https://swiftshader-review.googlesource.com/c/24593Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Bug: b/124177079
Change-Id: I5293ed6c564219f7a47baea7b62240b3104bd1f9
Reviewed-on: https://swiftshader-review.googlesource.com/c/24592Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Bug: b/124177079
Change-Id: Idd7ae86fc2d4e79a8d4b8e395eb0e547a0ba6470
Reviewed-on: https://swiftshader-review.googlesource.com/c/24591Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Bug: b/124177079
Change-Id: Ie51c9e8865f12583ece35a1d1d6c558d2ed1281b
Reviewed-on: https://swiftshader-review.googlesource.com/c/24590Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Very incomplete, but let's at least call the right things

Bug: b/124177079
Change-Id: I0592460f4be3327bdb8290a16739c5c7dfca19be
Reviewed-on: https://swiftshader-review.googlesource.com/c/24589Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Vulkan has no purpose for this

Bug: b/124177079
Change-Id: If2a3c824fac2645386091f6104c89a079f242d22
Reviewed-on: https://swiftshader-review.googlesource.com/c/24588Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

- Remnants of old fixed function attributes all gone
- Initial support for some builtins to prove the model
- Setup now driven by correct shader state
- VS->FS intermediate structure matches SPIRV model -- builtins are not
in location space; location space itself is flat scalars rather than
vec4-oriented.

There are still some vertex pipe features which are not supported, as
ES3 didn't have them -- proper handling of noperspective, etc.

Change-Id: Ia8e3c72af54c4d1cbcc18482a741daa5e8e7c053
Bug: b/120799499
Reviewed-on: https://swiftshader-review.googlesource.com/c/24376
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>

- Introduce (perhaps poorly named) SpirvRoutine type for
routine-emit-time state (reactor objects).
- Add SpirvShader::emitEarly (intended for definitions that are needed
in shader preamble) and SpirvShader::emit (intended for general actual
code generation) passes.
- Wire up new passes to VertexProgram/VertexRoutine

Change-Id: Iac42eae7dc04adfd4163fd74ba407b613551d14e
Bug: b/120799499
Reviewed-on: https://swiftshader-review.googlesource.com/c/24375Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Tested-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Bug: b/124265819

Change-Id: I4a1d32e38219171c7b9094335af9a6deef7f8dd8
Reviewed-on: https://swiftshader-review.googlesource.com/c/24568Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Tested-by: Hernan Liatis <hliatis@google.com>

vulkan_core.h only includes 'core' Vulkan declarations, while vulkan.h
consists of vulkan_core.h plus platform-specific headers.

Only Window System Integration (WSI) and closely related source files
should have a need to include vulkan.h. Everything else, in particular
our back-end, should not require anything Vulkan platform-specific.

This avoids issues such as Xlib defining global macros which clash with
C++ type and variable names.

Bug b/124265819

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

SPIRV-Tools include directory was missing, and all projects should link
using the static runtime library.

Bug b/123642959

Change-Id: I8ab915270115c810a91ff013d56a5bbb0a01d4a1
Reviewed-on: https://swiftshader-review.googlesource.com/c/24708Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Alexis Hétu <sugoi@google.com>

The root cause of a shader call stack overflow was fixed in
https://swiftshader-review.googlesource.com/c/SwiftShader/+/24628
All shaders should now be validated not to exceed our call stack size
before reaching this lowering stage of compilation. Thus the run-time
checks can be removed.

This partially reverts
https://swiftshader-review.googlesource.com/c/SwiftShader/+/23568

Bug b/123587120

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

https://swiftshader-review.googlesource.com/c/SwiftShader/+/16328
increased the maximum call depth validated by the GLSL ES compiler,
without increasing the stack size supported by our back-end.

The sw::MAX_SHADER_CALL_STACK_SIZE of the back-end is now statically
passed to an es2::MAX_SHADER_CALL_STACK_SIZE (has to remain equal or
smaller) and then passed to the GLSL compiler's resources limits.

Bug b/123587120

Change-Id: I9a56d5b4e980dc0881c238669d2b786bb3c855e3
Reviewed-on: https://swiftshader-review.googlesource.com/c/24628Tested-by: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Ben Clayton <bclayton@google.com>
Reviewed-by: Chris Forbes <chrisforbes@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Run some optimization passes before lowering the code, to allow for a
simpler compiler.

Current passes:
- Exhaustively inline functions
- Apply and freeze specialization constants

I expect this set of passes will change somewhat as the
compiler evolves. We may want to stop inlining at some point.

Bug: b/124058197
Bug: b/124056625

Change-Id: Ib2a3dc2d2599449d45ac7ebb1de107deba8eb2c3
Reviewed-on: https://swiftshader-review.googlesource.com/c/24288Tested-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Also deletes tons of fixed-function-centric stuff that will never be
used by the Vulkan backend. Very little of the SPIRV integration
actually does anything interesting yet (we don't generate code) but this
wires on the new shader representation.

Bug: b/120799499

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

Change-Id: I4750715a635ca3f929ae8d282c6cbaedfd4186f3
Reviewed-on: https://swiftshader-review.googlesource.com/c/23490Tested-by: Chris Forbes <chrisforbes@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>

Bug b/116336664
Change-Id: I1df29a8ef6b2700089ee5cc104b28ed898ccec1b
Reviewed-on: https://swiftshader-review.googlesource.com/c/24470Reviewed-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>

• Update to the latest config version
• Change the build folder to "${workspaceRoot}/build"
• Add option to control cmake build type
• Add new task to push current branch to gerrit

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

This fixes an issue where es2::Context::drawElements would still try to
read draw data even when there are 0 elements to draw, causing a buffer
overflow on draw data.

This was found by running Android ES3 dEQP under ASAN. The failing tests
are EQP-GLES3.functional.primitive_restart.[begin_restart,
begin_restart_duplicate_restarts, begin_restart_end_restart,
begin_restart_end_restart_duplicate_restarts,
end_restart_duplicate_restarts, duplicate_restarts].*

The crashing dEQP tests cover glDrawElementsInstanced,
glDrawRangeElements, and glDrawElements. These all converge onto
es2::Context::drawElements.

Bug: b/123716871
Change-Id: I4bca0616eb9f92bf18a3331459f3dcd06b8ac9a9
Signed-off-by: Cody Schuffelen <schuffelen@google.com>
Test: cts-tradefed run commandAndExit cts -m CtsDeqpTestCases --module-arg 'CtsDeqpTestCases:include-filter:dEQP-GLES3.functional.primitive_restart.*'
Reviewed-on: https://swiftshader-review.googlesource.com/c/24548
Kokoro-Presubmit: kokoro <noreply+kokoro@google.com>
Reviewed-by: Nicolas Capens <nicolascapens@google.com>