|
cc52e7cd
|
2021-04-19T21:37:20
|
|
Prevent separable programs from relying on attached shaders
Previously, several linking functions were reliant on the
HasAttachedShaders interface. The information stored there has been
moved to ProgramExecutable.
Linking information such as uniforms and uniform blocks from
attached shaders is now also stored in temporary pending variables
inside ProgramExecutable.
Bug: angleproject:5506
Test: ProgramPipelineTest31.VaryingLocationMismatch*
Test: GeometryShaderTest.RecompileSeparableVSWithVaryings*
Test: ProgramBinaryES31Test.SeparableProgramLinkedUniforms*
Change-Id: I93591431959c1c4c547ada92ec358369a3417723
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2909760
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Commit-Queue: Brandon Schade <b.schade@samsung.com>
|
|
|
c664601d
|
2021-04-26T17:08:06
|
|
Allow drawing if a fragment shader isn't present
According to the OpenGL ES 3.1 spec:
7.3 PROGRAM OBJECTS
If there is no active program for the vertex or fragment shader
stages, the results of vertex and fragment shader execution will
respectively be undefined.
If there isn't an active program for only one of these shader
stages, the results of the other shader stage are still defined.
To handle this, we no longer no-op the draw call if one of these
is missing. We only no-op the draw if there's no vs.
This allows for transform feedback to be captured when there's only
a geometry and vertex shader.
Tests: KHR-GLES32.core.geometry_shader.api.program_pipeline_vs_gs_capture
Tests: KHR-GLES32.core.separable_programs_tf.geometry_active
Tests: ProgramPipelineTest31.PipelineWithoutVertexShader*
Tests: ProgramPipelineTest31.PipelineWithoutShaders*
Bug: angleproject:5579
Change-Id: If9849cc398c307232435b167ab12431fa4258201
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2906723
Commit-Queue: Brandon Schade <b.schade@samsung.com>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
5aa5de76
|
2021-04-16T11:22:15
|
|
Vulkan: Keep the output variable of TCS active for barrier
OpControlBarrier implicitly synchronizes 'Output' storage class.
If TCS has an out varying it should be considered active because
TCS invocations themselves can read each others' outputs.
Bug: angleproject:5557
Tests: KHR-GLES32.core.tessellation_shader.tessellation_shader_tc_barriers.barrier_guarded_*_calls
Change-Id: Ic252c0afff43a68828ee4cf5f4ba890b1b67731e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2770679
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
|
|
|
f92eb43c
|
2021-03-25T18:33:19
|
|
Vulkan: All builtins of gl_out needs to be considered as active
All builtins of gl_out, like gl_out[].gl_Position need to be
considered active as well.
Bug: angleproject:5557
Test: dEQP-GLES31.functional.tessellation.shader_input_output.gl_position_tcs_to_tes
Change-Id: I74aeef86be573dc8df17472b88acd521032d7921
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2786630
Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
fe3a9ffb
|
2021-03-17T18:05:40
|
|
Support linking PPOs without attached Shaders
The application "Command & Conquer: Rivals" uses the following pattern:
// Create and link VS, save binary data
glCreateProgram()
glAttachShader()
glLinkProgram()
glGetProgramBinary()
// Create and link FS, save binary data
glCreateProgram()
glAttachShader()
glLinkProgram()
glGetProgramBinary()
...
// Create VS, load binary data
glCreateProgram()
glProgramBinary()
// Create FS, load binary data
glCreateProgram()
glProgramBinary()
...
glUseProgramStages(GL_VERTEX_SHADER_BIT)
glUseProgramStages(GL_FRAGMENT_SHADER_BIT)
glBindProgramPipeline()
Later, when issuing the draw command that uses the PPO, the PPO must be
linked with the Programs that were loaded via binary data. Those
Programs don't have any Shaders attached, just linked. This CL adds
support for linking Programs without attached Shaders.
Bug: b/182409935
Test: ProgramPipelineTest31.ProgramBinary
Change-Id: Ic5a4776e1374322665f45fbbcbf955838d093d02
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2770685
Commit-Queue: Tim Van Patten <timvp@google.com>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
2be71410
|
2021-03-19T14:07:02
|
|
Handle inactive structure type varyings correctly
Correctly handle inactive varyings of structure type when collecting
transform feedback varyings. Previously, all varyings of structure type
were marked as active by mistake.
Bug: angleproject:5557
Test: TransformFeedbackTest.InactiveStructureVarying*
Change-Id: Ica1cbce5c551cdbb97999eeac59d09a961937615
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2770680
Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
44b9579c
|
2021-03-10T08:10:33
|
|
Vulkan: Treat varyings in a separable program as active
When separable programs are linked, varyings at the separable program's
boundary need to be treated as active.
Bug: angleproject:5557
Test: ProgramPipelineTest31.VaryingIOBlockSeparableProgram*
Change-Id: I28af2bdf6478a408b3a7155ab4376ed6a19192f4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2742659
Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
c935ba5b
|
2021-03-09T08:40:22
|
|
Vulkan: Collect inactive varyings by block name for I/O blocks
ANGLE only collects inactive varyings by instance name. The SPIR-V
transformer expects I/O blocks to be identified by block name. If an I/O
block is inactive, an assertion would fire because the block name is not
in the shader variable info map.
Bug: angleproject:5676
Test: GLSLTest_ES31.VaryingIOBlockNotDeclaredIn*Shader*
Change-Id: I40e51c9770b03457e3896dcb2afa4e9525b098d8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2742658
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
|
|
bb3adfa4
|
2020-12-01T15:43:13
|
|
Rename ShaderVariable::structName to structOrBlockName
Bug: angleproject:3580
Change-Id: Ic53a5267972f153dad2e20948e493e9767a45d16
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2568247
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
b912eec5
|
2020-11-27T11:08:41
|
|
Vulkan: Support GL_EXT_tessellation_shader.
Shader translator changes done in http://crrev.com/c/2633936
Adds a new DIRTY_BIT_PATCH_VERTICES state to Context.
Supportes state query and transform feedback.
4 test suppressions remain as follow-up fixes.
Adds a new varying packing mode for a simple Vulkan rule set.
Based on work by Mohan Maiya (m.maiya@samsung.com).
Test: dEQP-GLES31.functional.tessellation.*
Bug: angleproject:3572
Change-Id: I4cad2cca30adb754fd12c83027673906541f566a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2568234
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Mohan Maiya <m.maiya@samsung.com>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
d654ac9b
|
2020-12-30T12:28:41
|
|
Program: Support multiple varying packings.
Instead of using a single varying packing for all program stages,
we switch to using a varying register packing for each pair of
input/output shaders. This allows several valid use cases that use
many varying to succeed. For instance Geometry Shaders have both
an input and output varying packing. With tessellation shaders the
upper bound of valid varying packings in one Program goes up even
more.
We keep multiple varying packings at once inside a new
"ProgramVaryingPacking" class. Internally the class keeps a unique
varying mapping for each input/output interface in the program.
Separable programs with "open" interfaces are handled specially.
Fixes a bug where varying counting was artificially limited for
programs with more than two shaders.
This CL also disables GS support when we're emulating line raster
so we don't have to figure out the details on how to place the
special position varying.
Bug: angleproject:5496
Change-Id: I1f9a327c4750caef570c608d86953e9d0cc5eea3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2606532
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
3e33db95
|
2020-12-30T17:17:17
|
|
Merge Program/ProgramPipeline::getMergedVaryings().
This merges two very similar pieces of code into one simpler function.
The function doesn't use any maps or indirection to build the merged
varyings list. It also fixes a potential bug with IO blocks and name
matching due to the code bifurcation.
Bug: angleproject:5496
Change-Id: Ibf54faeeb01d1940570b366ed153fff7c9135c52
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2606533
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
d9669322
|
2020-12-30T14:33:02
|
|
Remove "init" from VaryingPacking.
Instead we can pass the pack mode and size to the collectAndPack
method. This cleans up the interface and also allows us to merge
two separate code blocks in Program and ProgramPipeline.
Bug: angleproject:5496
Change-Id: I390b5d2e8a3b033374ccc5a250597be1f03dec96
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2606531
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
d33ffb22
|
2020-12-30T11:14:00
|
|
Organize VaryingPacking methods.
This clarifies the difference between "collect" and "pack" methods.
Previously the naming was overlapping between the two. Also makes
the "packUserVaryings" method private.
Refactoring change only. Will enable further improvements for
capturing varyings with multiple shader stages.
Bug: angleproject:5496
Change-Id: I854590ceab39f3a0e7a785516e0d1fd44e4ccc98
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2606529
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
92e7bc89
|
2020-12-23T15:18:42
|
|
Remove ProgramLinkedResources from ProgramExecutable.
Instead of storing the entire LinkedResources struct, we can keep it
only for the duration of the linking calls. Refactoring change only.
It sets the stage for more refactoring. This change also switches the
link call to use LinkingState's ProgramLinkedResources directly to
avoid the need to copy the varying packing or use a pointer.
Bug: angleproject:4514
Bug: angleproject:5496
Change-Id: Iefea3c16a33213dc338cc54efaa7c3064ea6ae08
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2601403
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
eeb14308
|
2020-12-23T01:45:35
|
|
Vulkan: Support xfb capture of I/O block fields
In the emulation path, it's ensured that the generated code references
the I/O block field correctly (using the instance name if provided, and
without it otherwise).
In the extension path, the info map is augmented with an array of xfb
decorations for its fields. Then when `OpDecorate %IOBlockId Block` is
encountered, the transform feedback decorations on the fields are
inserted:
OpMemberDecorate %IOBlockId MemberN XfbBuffer buffer
OpMemberDecorate %IOBlockId MemberN XfbStride stride
OpMemberDecorate %IOBlockId MemberN Offset offset
Future work includes removing the duplicate varying added for
gl_PointSize and use this mechanism to decorate gl_PerVertex directly.
Bug: angleproject:3606
Change-Id: I6fed0b1ee7245fe695337043b40b281fb01a1fb0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2599953
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
8065aa82
|
2020-12-22T23:38:42
|
|
Front-end support for xfb capture of I/O block members
Validation and generation of transform feedback varyings that specify an
I/O block member are implemented in this change. The GL backend is able
to pass the added tests.
Bug: angleproject:3606
Change-Id: I66d02bed8ca9161555d0d1e7a32ae9ef4d9e813f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2599952
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
4e2b6d6b
|
2020-12-21T10:48:12
|
|
Fix PackedVarying's move constructor
The move constructor was calling the move assignment operator, which
used std::swap on the members. However, `this` was not constructed, so
std::swap was operating on uninitialized values. Caught by UBSAN.
Bug: chromium:1159444
Change-Id: I65f2f0affd1461f880c59780f31a368779411f24
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2599936
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Ian Elliott <ianelliott@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
8789457d
|
2020-12-09T00:21:08
|
|
Fix varying packing of I/O block fields
The sorting algorithm didn't keep the fields in order, which made them
receive arbitrary locations. The SPIR-V transformer assigns the
location on the whole block instead of individual members, which was
incorrect in this situation.
The SPIR-V transformer could have been modified to decorate each field
of the I/O block with a location. This change instead sorts the fields
in such a way that I/O block fields are allocated contiguously, which
allows the SPIR-V transformer to function unchanged.
Bug: angleproject:3580
Change-Id: I27df9e8122dd4207835bad448ffb8015692a1635
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2581076
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
8797714c
|
2020-12-01T11:39:25
|
|
Vulkan: Support OES_shader_io_blocks
Enables OES/EXT_shader_io_blocks extensions in Vulkan backends.
With shader I/O blocks, the varyings can now be an array of struct (the
block itself) of struct (nested in the block).
This change is missing a number of features. In particular, if the
shader I/O block has a location decoration in the middle of the block,
that is not handled yet.
Based on changes from m.maiya@samsung.com and jmadill@chromium.org.
Bug: angleproject:3580
Tests: dEQP-GLES31.functional.shaders.linkage.es31.io_block.*
dEQP-GLES31.functional.separate_shader.validation.es31.io_blocks.*
dEQP-GLES31.functional.program_interface_query.program_input.*
dEQP-GLES31.functional.program_interface_query.program_output.*
Change-Id: I593840475d2365ff6c9ce7b2290f5ee462a30dfb
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2567645
Reviewed-by: Mohan Maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
06c39376
|
2020-11-27T12:45:33
|
|
Vulkan: Minimize gl_PerVertex members
As ANGLE doesn't redeclare gl_PerVertex, glslang always defines it with:
gl_Position
gl_PointSize
gl_ClipDistance
gl_CullDistance
The unused members here contribute to varying component limits. The
last two are unlikely to be used, and the second member is rarely used
as well.
This change keeps it simple and strips the trailing inactive members,
which for all intents and purposes accurately minimizes this struct.
Bug: angleproject:5405
Change-Id: I59c22af4988a3da7b1e428913d0ea13be9031cea
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2562754
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
9515707b
|
2020-05-29T11:23:44
|
|
Move ShaderVariable utility function from utilities.cpp ShaderVars.cpp.
Fixes an implied dependency cycle between translator and angle_common. This will also allow us to be more strict about declaring dependencies on GLSLANG headers.
Tested by building and running angle_unit_tests on Linux.
Bug: angleproject:4672
Change-Id: I331230d2cf179ccea140ee7a0d5a3c8768c58cb1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2222682
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
405f8e7b
|
2020-02-24T17:38:10
|
|
Vulkan: Support Program Pipeline Objects
Add support for PPOs to the Vulkan back end.
Bug: angleproject:3570
Change-Id: I5403456929847c185467b008d810f31ecfcb60cc
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2072652
Commit-Queue: Tim Van Patten <timvp@google.com>
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
|
|
|
e5385ea9
|
2020-01-27T13:40:18
|
|
Vulkan: Compile shaders at link time
Since line raster emulation was changed to use specialization constants,
it has been possible to compile shaders at link time. However, program
pipeline objects would have required keeping the shader sources around
for recompilation. Now that all necessary decorations are modified
directly in SPIR-V, it's possible to compile the shaders at link time
and forget about their sources. Program pipeline objects then simply
"reconfigure" the generated SPIR-V.
A next step could be to also create the Vulkan pipeline object at link
time. A number of failures due to gaps in CTS testing prevent that work
currently. In particular, in some situations the generated SPIR-V is
not per spec, for example it may contain vertex attributes with aliasing
locations, or have transform feedback capture of array elements
misconfigured.
Bug: angleproject:3394
Bug: angleproject:4253
Change-Id: I54c0884cf056b511a4a306225cc6ed2cef84d257
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2023186
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
f764fc02
|
2020-02-03T10:33:58
|
|
Fix varying linking by location
This change breaks the assumption everywhere that varyings can be
identified uniquely by name throughout all stages of the pipeline.
It further implements linking of varyings by location, if specified.
Bug: angleproject:4355
Change-Id: Ie45e48879008c3f0c22d1da3d0d26f37c655e54e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2030026
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
|
|
|
f1f082e1
|
2020-01-17T14:53:38
|
|
Vulkan: Set varying location & xfb decorations in SPIR-V
The shader translator outputs arbitrary location indices. Once compiled
by glslang, the SPIR-V transformer modifies these decorations. If the
transform feedback extension is used, it will also add the relevant
decorations to the varyings that are captured.
Bug: angleproject:3394
Change-Id: I5ecafd0536408612a5d4b920dbabbfabe650657c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2008468
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
6381d7f1
|
2019-12-10T23:19:23
|
|
Vulkan: Avoid linear search in shader on varying location assignment
Glslang wrapper was trying to identify whether the varying is declared
in each of the out/in shaders by looping through the macro symbols that
need replacement.
This change instead adds stage information to PackedVarying assigned
when collecting varyings. Glslang wrapper then simply tests the
bitfield for the stages of interest.
Bug: angleproject:3571
Change-Id: I29614e3e62d7df88e413c1732ac04e24243f167a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1954677
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
caa6eccd
|
2019-10-27T13:46:56
|
|
Vulkan: Implement Transform Feedback support via extension
Implemented transform feedback extension path. Where
VK_EXT_transform_feedback is supported, extension path will be taken
over an emulation path. Extension path has advantages in terms of
performance.
BUG=angleproject:3206
Test: dEQP-GLES3.functional.transform_feedback.*
angle_end2end_tests --gtest_filter=TransformFeedbackTest*
Change-Id: Ia07c23afb289d9c67073469a97b714ec96f5265a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1882767
Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
Reviewed-by: Mohan Maiya <m.maiya@samsung.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
|
|
a0159c03
|
2019-09-02T14:49:07
|
|
Vulkan: Implement basic geometry shader feature
Enable the default behavior of the geometry shader
Bug: angleproject:3571
Test: dEQP-GLES31.functional.geometry_shading.input.basic_primitive.points
dEQP-GLES31.functional.geometry_shading.input.basic_primitive.lines
dEQP-GLES31.functional.geometry_shading.input.basic_primitive.line_loop
dEQP-GLES31.functional.geometry_shading.input.basic_primitive.line_strip
dEQP-GLES31.functional.geometry_shading.input.basic_primitive.triangles
dEQP-GLES31.functional.geometry_shading.input.basic_primitive.triangle_strip
dEQP-GLES31.functional.geometry_shading.input.basic_primitive.triangle_fan
Change-Id: I65708d19bbfe6a0ad8ca392a1d6b3609b1410ef4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1793753
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
90a58622
|
2019-09-04T15:39:58
|
|
Refactor ShaderVariable to Remove Specializations
The following structs are being refactored and moved into the parent
struct ShaderVariable:
VariableWithLocation
Uniform
Attribute
OutputVariable
InterfaceBlockField
Varying
Bug: angleproject:3899
Test: CQ
Change-Id: I389eb3ab4ed44a360e09fca75ecc78d64a277f83
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1785877
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Courtney Goeltzenleuchter <courtneygo@google.com>
Commit-Queue: Tim Van Patten <timvp@google.com>
|
|
|
051b0896
|
2019-04-15T15:39:39
|
|
Vulkan: Fix layout substitution for struct varyings
If the shader contains code such as the following:
struct S {
vec4 field;
};
out S varStruct;
The layout qualifier macro is defined as @@ LAYOUT-varStruct @@.
However, the Vulkan backend was replacing @@ LAYOUT-field @@.
Bug: angleproject:3220
Change-Id: Iae15003867e0bed2cc939159a6653429c7a431e0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1571389
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
b980c563
|
2018-11-27T11:34:27
|
|
Reformat all cpp and h files.
This applies git cl format --full to all ANGLE sources.
Bug: angleproject:2986
Change-Id: Ib504e618c1589332a37e97696cdc3515d739308f
Reviewed-on: https://chromium-review.googlesource.com/c/1351367
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
da92a476
|
2018-07-02T15:55:19
|
|
Clean up VaryingPacking
This patch intends to clean up some issues in VaryingPacking
to implement geometry shader easiler.
1. Use emplace_back() instead of push_back() when necessary.
2. Remove unnecessary parameter in VaryingPacking::packUserVaryings().
3. Remove the assignment of semanticIndex and only handle them in D3D11
back-ends.
BUG=angleproject:1941
Change-Id: Ia09c07f01dc442ce95cb4984e4b768d0c79872c7
Reviewed-on: https://chromium-review.googlesource.com/1128576
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Jiawei Shao <jiawei.shao@intel.com>
|
|
|
aed1b56a
|
2018-04-17T11:47:46
|
|
Prerequisite code for simpler GlslangWrapper.
This makes two changes for the linking step:
* allows symbol names in TOutputGLSLBase::writeVariableType
* stores a list of inactive varying names in VaryingPacking
Bug: angleproject:2456
Change-Id: Id651721a008c049508303d18c45c6b96c76114d9
Reviewed-on: https://chromium-review.googlesource.com/1014707
Reviewed-by: Luc Ferron <lucferron@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
94bbed1e
|
2018-03-20T14:44:53
|
|
Collect static use information during parsing
We now collect metadata for variables in the symbol table. The
metadata is stored in a map using the variable unique id as a key, so
we can store the variables themselves as constexpr while still having
dynamic metadata.
For now we collect whether a variable is statically read or written.
This can be used to more accurately determine whether a variable is
statically used, but can also enable more optimizations in the future,
such as pruning variables that are never read or folding variables
that are never written after initialization. The collection is done
during parsing, so that nothing is pruned from the AST before the
static use is recorded.
Static writes are flagged in ParseContext::checkCanBeLValue, as that
function is already called for all variables that are written.
Static reads are flagged whenever there's an operation that requires
a variable to be read. This includes:
* Unary and binary math ops
* Comma ops
* Ternary ops
* Assignments
* Returning the variable
* Passing the variable as an in or inout argument to a function
* Using the variable as a constructor argument
* Using the variable as an if statement condition
* Using the variable as a loop condition or expression
* Using the variable as an index
* Using the variable as a switch statement init expression
In case there are statements that simply refer to a variable without
doing operations on it, the variable is being treated as statically
read. Examples of such statements:
my_var;
my_arr[2];
These are a bit of a corner case, but it makes sense to treat them as
static use for validation purposes.
Collecting correct static use information costs us a bit of compiler
performance, but the regression is on the order of just a few percent
in the compiler perf tests.
BUG=angleproject:2262
TEST=angle_unittests, angle_end2end_tests
Change-Id: Ib0d7add7e4a7d11bffeb2a4861eeea982c562234
Reviewed-on: https://chromium-review.googlesource.com/977964
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
|
|
|
107c7247
|
2018-03-20T15:45:35
|
|
ShaderVariable: separate fields for staticUse and active
Thus far the compiler has used the "staticUse" flag to mark variables
that should have rather been marked "active", meaning that the code
may actually execute in a way that accesses the variable. There's a
clear definition for this use of the term "active" in the GLES 3.0.5
spec, section 2.12.6, and in GLES 3.1 section 7.3.1.
Having separate fields for recording static use and "activeness" of a
variable is the first step to fixing this.
According to the spec, usually only active resources should be
considered when checking use against max limits. Also, only active
uniforms get assigned a location. libANGLE code now correctly checks
the active flag rather than the static use flag in these cases.
The static use field still mirrors the active field for now, since
some code in Chromium also needs to be fixed to use the active field
correctly before the two can diverge.
After Chromium is fixed, we can fix ANGLE so that static use
information is recorded earlier during compilation and will accurately
reflect whether variables are statically used. Currently the compiler
only records variables once some static use may already have been
pruned from the AST.
BUG=angleproject:2262
TEST=angle_unittests, angle_end2end_tests
Change-Id: I025bb71361246ae00c911a1f8b66ec045f665f29
Reviewed-on: https://chromium-review.googlesource.com/970962
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
|
|
|
61d5325e
|
2018-01-31T14:49:24
|
|
D3D9: Improve varying packing failure mode.
D3D9 has a special limitation on varying packing, where each
variable takes up a full register width, and cannot share space
with other packed varyings.
A bug was counting registers incorrectly on D3D9. Fix this by
introducing a new limitation exposed to the ANGLE front-end via
the gl::Limitations structure. Now varying packing will fail
correctly in the ANGLE linking front-end with a more descriptive
error message, as such:
"Could not pack varying blah"
"Note: Additional non-conformant packing restrictions are enforced on D3D9."
Also change the packing so that input built-in variables are
counted towards varying limits (e.g. gl_PointSize), except for
gl_Position. On D3D9 we don't pack gl_PointSize, since it is
used in a special extra PSIZE register.
Also update some tests to be more robust.
Bug: chromium:804799
Change-Id: I9027266a8b66a28626f038f259bff42ebf09dcd2
Reviewed-on: https://chromium-review.googlesource.com/889898
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
8225e73b
|
2017-11-14T16:29:03
|
|
Support struct varying for transform feedback
Capturing struct members is vague In ES 3.00. But the ES 3.10
explicitly says that base-level members of struct are feasible for
transform feedback capture. This implementation fills the gap.
TEST=angle_end2end_tests:TrasnformFeedbackTest*
BUG=angleproject:2241
Change-Id: Ibdf3ae6c2b8b28952e2f7fef1363545cbccad389
Reviewed-on: https://chromium-review.googlesource.com/768613
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
3c1da04e
|
2017-11-27T18:33:40
|
|
Isolate GlslangWrapper header from most of ANGLE.
Since we might want to use the ANGLE PoolAlloc in the Vulkan back-end,
we want to make completely sure that it doesn't show up in any header
that might be included with the Glslang headers, since this could
cause a conflict.
This change moves as much as possible to forward-declaring instead of
including headers directly in ProgramLinkedResources.h. This means
making several internal Program helper classes external. I.E. instead
of Program::Bindings, we have ProgramBindings.
It also redeclares a "using" in two places, since it isn't possible to
forward declare these, and it seemed overdesigned to put the using in
a separate header.
Bug: angleproject:2264
Change-Id: Idd08706580c927327dddf46e86acbcd2c4e3286f
Reviewed-on: https://chromium-review.googlesource.com/792270
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
465835d6
|
2017-09-26T13:34:10
|
|
Support arrays of arrays in the API
The ShaderVariable class that is used as an interface between the
compiler and the rest of the code gets arrays of arrays support.
Array of array variables are passed from the compiler just like any
other variables. However, when stored in Program state each innermost
array constitutes a separate variable. This is done to make the
implementation match the GLES specification for program interface
query APIs.
This will be tested more fully once support for parsing arrays of
arrays lands in the compiler.
TEST=angle_end2end_tests, angle_unittests
BUG=angleproject:2125
Change-Id: I0f7159000f039be92a87a52b3b68cd9a215a21cb
Reviewed-on: https://chromium-review.googlesource.com/684742
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
acf2f3ad
|
2017-11-21T19:22:44
|
|
Apply Chromium style fixes.
This addresses several minor code quality issues that are validated
in Chromium, but not yet applied to ANGLE:
* constructors and destructors must be defined out-of-line
* auto is not allowed for simple pointer types
* use override everywhere instead of virtual
* virtual functions must also be defined out-of-line
Slightly reduces binary size for me (~2k on Win, 150k on Linux).
Bug: angleproject:1569
Change-Id: I073ca3365188caf5f29fb28d9eb207903c1843e6
Reviewed-on: https://chromium-review.googlesource.com/779959
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
85c93c41
|
2017-11-12T15:36:47
|
|
Refactor VaryingPacking
Move all packing related logic from Program to VaryingPacking.
Do linkValidateTransformFeedback check first to simplify packing.
Make getPackedVaryings collect all required VaryingPackings in one
run pass, so that packUserVaryings can focus on packing merely.
BUG=angleproject:2241
Change-Id: I5e84e6e4688c80ba7a77a265b8ffaf79f4ddbb87
Reviewed-on: https://chromium-review.googlesource.com/764821
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
|
|
|
c853804c
|
2017-09-27T11:20:15
|
|
Add support for arrays of arrays to VariableLocation
Array indices are sorted so that the outermost index is in the back.
This is because we want to be consistent with future arrays of arrays
parsing code. In parsing we'll have a utility function to make a
TType object into an array, and there it's most natural to push the
new outermost sizes to the back of the vector.
Further patches will still be needed to parse arrays of arrays and
add support to arrays of arrays into the API.
BUG=angleproject:2125
TEST=angle_unittests, angle_end2end_tests
Change-Id: I6c88edabf68ae9dbd803ec6d20543016c408b702
Reviewed-on: https://chromium-review.googlesource.com/686414
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
|
|
|
6ee26d7a
|
2017-08-31T14:23:20
|
|
Fix linking of non-existent XFB varyings with gl_ prefix
Non-existent XFB varyings with the gl_ prefix used to pass linking on
the D3D11 backend. On a debug build they would cause an assert. Fix
these issues.
BUG=angleproject:2141
TEST=angle_end2end_tests
Change-Id: Iecc3d03823d02700d6b28c44d77df7a2f9e70a5b
Reviewed-on: https://chromium-review.googlesource.com/645747
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Olli Etuaho <oetuaho@nvidia.com>
|
|
|
a9042d3c
|
2017-03-17T08:50:45
|
|
ES31: Add array element transformfeedback
This enhances the PackedVarying to be either one element of array, or
whole array. Correspondingly the VaryingPacking is expanded to pack it
properly.
BUG=angleproject:1950
Change-Id: I0529d7ac4367d42b2b433410fbf08351412aada8
Reviewed-on: https://chromium-review.googlesource.com/459115
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
|
|
|
192745a7
|
2016-12-22T15:58:21
|
|
Add varying packing validation for WebGL.
This CL moves the varying packing from the D3D layer up to Program.
This is necessary for WebGL validation, and gives us consistency
for the various back-ends. There may be some additional cleanup work
on the VaryingPacking class, because it does some work that is D3D-
specific.
WebGL requires strict varying packing. Instead of allowing success
unconditionally, it's an explicit error to succeed to pack a set of
varyings that the sample algorithm would fail to pack.
Introduce a new packing mode option to the varying packing class to
handle this different packing style, while keeping our old more
relaxed packing method for ES code.
BUG=angleproject:1675
Change-Id: I674ae685ba573cc2ad7d9dfb7441efa8cb2d55fc
Reviewed-on: https://chromium-review.googlesource.com/423254
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Corentin Wallez <cwallez@chromium.org>
|