In ANGLE, when an unindexed lvalue was passed as an out parameter to a
function, SPIR-V was generated such that the lvalue is passed in
directly. A Skia test revealed a difference in SPIR-V and GLSL
semantics where aliasing out parameters are expected to work on local
copies until the end of the function.
Bug: b/226904235
Change-Id: I476af01eb7d065272825967111cd208faf88c275
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3561278
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Some border color tests used to fail due to either unclamped color
values or not accounting for depth, stencil or luma formats. We now
adjust the border color value according to the sampler's format.
Test: dEQP-GLES31.functional.texture.border_clamp.*
Bug: angleproject:3577
Bug: angleproject:6213
Change-Id: Ib38ce2374622bfafde69fe3fa2d7227d60043954
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3551895
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Remove GL_UNSIGNED_INT_24_8 from the supported types in
ValidReadPixelsTypeEnum.
Run the format/type validation before the check for missing
attachment.
Bug: angleproject:7119
Change-Id: Ie788084d0f41fef6847791de8c53be830eba7564
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3546723
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Instead of using vkCmdClearAttachments, if the color attachment has not
been written to, modify the loadOp of the currently open renderpass to
CLEAR.
This is an adaptation of
commit cfe5a1735a
The difference with that commit is that, with the prior changes that
added tracking of color attachment access in the render pass, this
change is greatly simplified by being able to immediately know if clear
can be moved to the beginning of the render pass.
Bug: angleproject:5048
Change-Id: I72b3613ad08ff869b71aced7e1f4e9be916d7b49
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3557815
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
To roll into Chromium, this needs a rebaseline. Two oopr-canvas2D tests
show a minor diff with this extension enabled.
Bug: angleproject:6947
Change-Id: I19c285ec544fef3622cce805322093ccffbcb728
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3561280
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
First I added a check that CommandBuffers are committed in order
as the design requires that they are. This showed several tests
asserting including the angle end2end test,
OcclusionQueriesNoSurfaceTestES3.SwitchingContextsWithQuery/ES3_Metal
and also several others. The check is cheap and helps catch bugs so
it seems prudent to have it.
Unfortunately, AFAICT, there is no trival fix. The issue is
ContextMtl::flushCommandBuffer commits the outstanding commandbuffers
but then, if there is/was a query in progress, more work needs
to be done. That work calls ContextMtl::getBlitCommandEncoder which
calls ContextMtl::ensureCommandBufferReady which calls
ProvokingVertexHelper::ensureCommandBufferReady which ends up making
a new command buffer. That command buffer should be committed
before switching to a new context but the code that would commit it
has already executed. It's not at all clear to me how to refactor
the code to do this correctly. The simplest solution is to call
ContextMlt::flushCommandBuffer twice which I know is gross but at
least it fixes the bug and optimizing and/or refactoring can be done
separately.
Bug: angleproject:7131
Change-Id: Idb11efb35f6ad2fd890a5db15d3791c07586bf34
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3553939
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Gregg Tavares <gman@chromium.org>
Previously, storeOp=None was used when the attachment was in "read-only
mode" and storeOp=Store. With this change, storeOp=None is used more
opportunistically when it's deemed that the attachment was not written
to, regardless of if it was put in "read-only mode" (a construct added
to support read-only depth/stencil feedback loops).
Bug: angleproject:5048
Change-Id: I10832d4e2b97793ea1347a47175cbf8ce9af57d6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3556368
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
The OpenGL ES extension GL_EXT_texture_type_2_10_10_10_REV
requires RGB and RGBA formats to be supported but Desktop OpenGL
does not support RGB. Emulate it with the existing
emulatedAlphaChannel path in TextureGL.
Bug: chromium:1300575
Change-Id: I5efea52d3da628cf82b43fece23894e6f47df650
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3533141
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Two tests, to ensure that:
- Clear gets treated as a LoadOp instead of as an out-of-renderpass
clear, even if draws don't touch color buffers.
- Invalidated image gets contents marked as defined after
invalidate+clear, so draws to it get a renderpass with LoadOp=Load
Bug: angleproject:7127
Change-Id: I78a8bd2100ba941a74755402649ae8edc7978026
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3552090
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Auto-Submit: Steven Noonan <steven@valvesoftware.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
I had a situation which was like this:
- glBindFramebuffer(fbo)
- glClear(color + depth)
- series of depth-only draws:
- glDrawBuffers() - disable all color buffers
- glColorMask() - all false
- glDrawElements/glDrawArrays
- glBindFramebuffer(0)
Even though the glClear happened before glDrawBuffers/glColorMask, it
only got executed on the first glDraw* call. And since the draw buffers
got disabled before it decided to act on the Clear, it thought it
couldn't touch the color buffer in the render pass.
So it ended up doing:
vkCmdClearColorImage() on the color buffer
vkCmdBeginRenderPass() with LoadOp C=Load, D=Clear before the draw
instead of:
vkCmdBeginRenderPass() with LoadOp C=Clear, D=Clear
Bug: angleproject:7127
Change-Id: Ibc3b55b0c7815defcf6d711fa876eff43ba29d40
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3551298
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
The tessellation stages were missing from a helper, which was silently
returning an invalid value.
Add a test and an assert, which fires before the fix.
Test: GFXBench Car Chase
Test: GLSLTest_ES31.TessellationTextureBufferAccess
Bug: angleproject:7135
Bug: b/218314686
Change-Id: I2bc8d374300fc1470e52affabab7491698c99cee
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3554575
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Cody Northrop <cnorthrop@google.com>
The backend was ignoring "repeated clears" with an Invalidate between
them, which marked the image contents as undefined. When a clear happens
after invalidate, verify that the clear parameters were the same, and
simply mark the image contents defined if they aren't already.
For example, in this scenario:
- glBindFramebuffer(fbo)
- glInvalidateFramebuffer(color + depth)
- glClear(color + depth)
- depth only render
- glInvalidateFramebuffer(depth)
- glBindFramebuffer(0)
The color clear got skipped entirely because it was cleared with that
color in a previous frame and no other color draws happened since. This
caused sampling from the FBO's texture to return garbage data.
Bug: angleproject:7127
Change-Id: I4ffe65c67375931ab63f07f27fa59ed0a4b90cd9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3551297
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Passes on pre-release Android T drivers, but fails on the Android S
drivers.
Bug: b/224537784
Change-Id: Idc631d13b1666f0f0b4bf1c5bbfa9e9343af4d75
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3554360
Auto-Submit: Ian Elliott <ianelliott@google.com>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Commit-Queue: Yuly Novikov <ynovikov@chromium.org>
Recent Clang versions have enhanced -Wunused-but-set-variable which now
warns about this.
Bug: chromium:1309955
Change-Id: Ic62427ab3129838d03878c308c6260993ae9fa57
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3550204
Auto-Submit: Hans Wennborg <hans@chromium.org>
Reviewed-by: Stephen White <senorblanco@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Scoped* classes provide an RAII way of adding cleanup/restore state/etc
in a robust way. Unfortunatley, it's very easy to mistakenly leave the
variable name, leading to the destructor being called immediately
instead of at the end of the scope:
{
ScopedX(parameters); // instead of ScopedX x(parameters);
// Code here is run after destructor
}
The [[nodiscard]] attribute, if specified on the ScopedX class would
lead to a warning (turned to error with -Werror). This change does
that for classes named *Scoped* in ANGLE.
Bug: chromium:1103817
Change-Id: I65c9922c9b4eba1f9c033e093fe8fe534648ab62
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3552092
Reviewed-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
The Caps::maxImageUnits are limited, but that's only the value that is
checked when compiling shaders, we have also limit the values that are
returned when using the GL interface.
In addition print out the error log when compiling a shader fails in the
Pipeline tests.
Bug: angleproject:7094
Change-Id: I19f69afe2cece4841a395543c1e35785bc6bd698
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3516078
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Commit-Queue: Gert Wollny <gert.wollny@collabora.com>
Include the following GN arg to print all GLES and EGL commands:
angle_enable_trace_events = true
Bug: angleproject:7126
Change-Id: I78eb061c10ed519d6a0b0357eea11567d1cfb518
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3551656
Reviewed-by: Ian Elliott <ianelliott@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Cody Northrop <cnorthrop@google.com>
GFXBench Car Chase binds a cube map array as a default texture,
then immediately samples from it without setting it up. This
ends up treating the cube map array as incomplete.
On the Vulkan backend, this is resulting in multiple validation
errors, followed by a crash in the driver. There are a number of
errors, but a telling one is this:
vkCreateImage(): pCreateInfo->flags contains
VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT, but pCreateInfo->arrayLayers (=1)
is not greater than or equal to 6. The Vulkan spec states: If
imageType is VK_IMAGE_TYPE_2D and flags contains
VK_IMAGE_CREATE_CUBE_COMPATIBLE_BIT, extent.width and extent.height
must be equal and arrayLayers must be greater than or equal to 6
This corresponds to language in the GLES 3.2 spec:
8.18. IMMUTABLE-FORMAT TEXTURE IMAGES
TexStorage3D Errors
An INVALID_OPERATION error is generated if any of the following
conditions hold:
* target is TEXTURE_CUBE_MAP_ARRAY and depth is not a multiple of 6
Since ANGLE treats incomplete textures as immutable, we need to update
the dimensions of the backing image for CUBE_MAP_ARRAY.
Also add a new test that exposes the problem.
Test: IncompleteTextureTestES31.IncompleteTextureCubeMapArray
Bug: b/218314686
Change-Id: Ibef41e15a7cfccb05e6039bfb8504d237bc42cd4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3546290
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Cody Northrop <cnorthrop@google.com>
That is in preparation for optimizing mid-render-pass clears, which
requires an answer to the following query: "has this color image been
read from / written to so far in the render pass?"
With this change, a future CL will also be able to optimize color
attachment invalidates, which currently break the render pass
unconditionally, the same way depth/stencil is optimized.
Bug: angleproject:5048
Change-Id: I3d3ee40d8444e6861c06340d5d52b17f5ee895b4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3542989
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
This is a reland of 0455f356ed
Original change's description:
> Remove unnecessary suppressions for Pixel6 dEQP tests
>
> Bug: b/224537784
> Change-Id: If7befe0279a06cddb79c67fdd34a62b4cb51c6e0
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3551658
> Reviewed-by: Yuxin Hu <yuxinhu@google.com>
> Commit-Queue: Ian Elliott <ianelliott@google.com>
The previous CL was based on the pre-release Android T Pixel 6
drivers. The Chromium bots are running released Android S Pixel 6
drivers. This CL updates the expectations with the observed status,
and still removes some expectations that are now unnecessary.
Bug: b/224537784
Change-Id: I4f4041e015824fd1d8211d6d7d0adedbccaa3ddb
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3552544
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Ian Elliott <ianelliott@google.com>
In preparation for doing the same for color, the depth/stencil render
pass access and feedback loop modes are now updated with ContextVk dirty
bits.
This change also fixes clear after read-only depth/stencil feedback
loop. The render pass wasn't broken in that case.
Bug: angleproject:5048
Change-Id: I40f9b49593f9e6f35f42408e41c9d6267edb375e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3542988
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
This CL contains two fixes:
* Add GL_PATCHES to list of PrimitiveMode names
* Use FramebufferTextureLayer for 3D and Cube textures
Bug: angleproject:3662
Bug: angleproject:7125
Bug: b/218314686
Change-Id: Ia97d8221cb78ef6e895156b5a474483d570d6ab5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3551096
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Cody Northrop <cnorthrop@google.com>
Mapify them so they can handle all shader types.
Bug: angleproject:7121
Change-Id: Ia80d46200bf30509e1484f1e198e1edfe6344207
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3550542
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Stephen White <senorblanco@chromium.org>
Recent Clang versions have enhanced the warning, causing it to fire in
preprocessor_tab_autogen.cpp and glslang_tab_autogen.cpp. Since those
are generated by Bison, we can't fix the code and instead should
suppress the warning there.
Bug: chromium:1309955
Change-Id: I31aa83571162310bef47a7ce84841446713a2d04
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3550200
Commit-Queue: Hans Wennborg <hans@chromium.org>
Auto-Submit: Hans Wennborg <hans@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
Mapify this variable so it can accommodate other shader types.
Bug: angleproject:7121
Change-Id: If6893a5fceaf50db87c42176c58319ce17d23d54
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3550539
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Stephen White <senorblanco@chromium.org>
This allows all shader types to use these Image2D calls.
Bug: angleproject:7121
Change-Id: I95f9e8a2fd206bcc3ff2ef7e06875d093d73dcd6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3550538
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Stephen White <senorblanco@chromium.org>
This is a reland of 1099b5ef22.
Original change's description:
> Vulkan: Fix invalid access with display texture share group.
> Create bufferpool that owns by RendererVk.
> If we are using EGL_ANGLE_display_texture_share_group
> extension, use the bufferpool owned RendererVk,
> otherwise, use the bufferpool owned by EGL::ShareGroup.
> The bufferpool lifetime will remain consistent with
> texture lifetime.
> Bug: chromium:1299211
> Change-Id: Ie4e87cea1dfd20dabab24e2afed6ddd92e469888
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3531155
> Reviewed-by: Charlie Lao <cclao@google.com>
> Reviewed-by: Geoff Lang <geofflang@chromium.org>
> Commit-Queue: Geoff Lang <geofflang@chromium.org>
Bug: chromium:1299211
Change-Id: I4b8f5bcb30297f2c5f24e02404fd96011f9d843b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3550038
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Shahbaz Youssefi
angle-autoroll
Mohan Maiya
John Cunningham
Gregg Tavares
Lubosz Sarnecki
mark a. foltz
Arthur Eubanks
Geoff Lang
Steven Noonan
Zequan Wu
Cody Northrop
Ian Elliott
Hans Wennborg
Gert Wollny
Stephen White
Roman Lavrov
Yuxin Hu