This reverts commit 9f7b6babe1.
Reason for revert: No longer appears needed as 1) number of diffs was greatly reduced via cc_default 2) build configs got simpler with switching to platform zlib. No recent conflicts introduced by build scripts
Original change's description:
> Add minimal setup for Go codegen in Android.bp.
>
> Based on Cody's http://ag/19603310.
>
> Only adds libEGL_angle_codegen to libEGL_angle and is a no-op.
>
> Tested in an aosp checkout. Hopefully this doesn't cause merge conflicts
> with internal master as all diffs are close to the top of the file.
>
> Android.bp diff: https://paste.googleplex.com/6626641357832192
>
> Bug: b/242929755
> Change-Id: I6d7ac9f3dd502074c41838bd1aa10075a8c99145
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3876890
> Commit-Queue: Roman Lavrov <romanl@google.com>
> Reviewed-by: Cody Northrop <cnorthrop@google.com>
> Reviewed-by: Geoff Lang <geofflang@chromium.org>
Bug: b/242929755
Change-Id: Id4cbdf68e9704138396ee1bef7a4f1edef3f50cf
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4685320
Commit-Queue: Roman Lavrov <romanl@google.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
If the underlying driver changes, reject program binaries from the old
versions. The driver is supposed to do this for us (on OpenGL, at
least) but this adds some extra protection.
Bug: angleproject:4981
Change-Id: Id9486d8e6f9136970c0d7c37d59dea5d43b0a50e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4685317
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
If the backend requires that a framebuffer is synchronized before
checking backend completeness, make sure all attachments are
synchronized too.
GL has completeness rules based on GL_BASE_LEVEL and
GL_MAX_LEVEL of texture attachments which are not syncrhonized until
the textures are. If they are left un-sychronized during completeness
checks, the driver will tell us that the framebuffer isn't complete.
Bug: chromium:1455725
Change-Id: I7c3bf6a38f63feaa863f4d8914c3655e286dd768
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4678286
Reviewed-by: Brian Ho <hob@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
This ensures that any resources that were partially initialized are
cleaned up.
This is a speculative fix for dual GPU macs not falling back to the
low power GPU. DisplayMtl leaks the metal device if it fails to
initialize due to unsupported GPU families or vendors.
Bug: chromium:1322521
Change-Id: I93930de8c07bb94318ac41c67513a3b1c8bd3bf0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4681842
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
This test uses narrow range encoding (as can be seen from the
color value for black) but the Cr component for red is greater
than 240. On some platforms with different clamping logic the
output color after conversion ends up not being red. Update the
input colors to account for different implementations.
Bug: b/210526871
Test: ImageTestES3.SourceYUVAHBTargetExternalYUVSampleLinearFiltering*
Change-Id: Ib9b76c9433b07f5ce8a129779e77bc682bb341ac
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4684018
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Per-channel write operations to shared exponent
color buffers are loosely defined and may cause
driver validation errors.
Restricted the set of allowed color writemasks
for RGB9_E5 color buffers so that RGB channels
must be either all enabled or all disabled.
Added a Metal-specific adjustment to ignore
alpha writemask for RGB9_E5 color buffers.
Removed an unused function from
RenderPipelineColorAttachmentDesc.
Bug: angleproject:8043
Change-Id: I902c3b70ddc6d8e65069d98a4a02a82122f413a5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4685566
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Right now the tracking of depth stencil buffer readOnly or feedback loop
is in FramebufferVk class. This really belongs to ContextVk, since it is
not a permanent state of framebuffer, but current state of context. This
CL moves it to ContextVk and changes to use BitSet instead of four
boolean.
Bug: b/289436017
Change-Id: I955c439259935f82eff30ddfff776a69723e5d0d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4679886
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
This is first clean up effort for depth stencil feedback loop
implementation. This CL moves updateRenderPassStencilReadOnlyMode and
updateRenderPassDepthReadOnlyMode methods from FramebufferVk to
RenderPassCommandBufferHelper class. The method is actually updating
renderPass's state, not FramebufferVk's state. In the next CL,
FramebufferVk will be removed from the argument as well. With this
change, I also removes updateStartedRenderPassWithDepthMode() and
updateStartedRenderPassWithStencilMode() to use
updateStartedRenderPassWithDepthStencilMode() directly.
This CL is mechanical changes only, no behavior chnage is expected.
Bug: b/289436017
Change-Id: Id3960f973a7115c05ebea199cb8ef802e995941a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4679365
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
... by removing it altogether. This macro was only available when
features.h was included. If that header was not included, the
preprocessor would automatically consider it 0, which has the opposite
effect from what was desired.
Bug: angleproject:8256
Change-Id: Ia141573c0c8b44eef1388f4c3ec73ef770cd2854
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4685226
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
The WorkerPool was created on the first postTask and could create
a number of threads. We were seeing this on blink for iOS where
we would have expected using the delegate's worker pool. However
ANGLE_ENABLED was undefined because it wasn't included. This
caused the comparison of ANGLE_DELEGATE_WORKERS to not work.
Instead of including the header for ANGLE_ENABLED since that would
cause a dependency on libAngle, just use #if X instead, while
this also isn't the best because X can be undefined its a solution
for now.
Bug: angleproject:8256
Change-Id: I5aeb686dcc117feaba884cdea5c89e4b146cb57f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4679894
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
The various RenderUtils classes created hundreds of RenderPipelineCache
objects which did not reliquish their pipelines for the life of the
Display. Hook them into the per-context PipelineCache so that they
share the total pipeline limit with programs.
Make RenderUtils fully RAII and store it in a unique_ptr in DisplayMtl.
Remove RenderPipelineCache.
Bug: chromium:1329376
Change-Id: I265e4e05fd3fd1da34932de36803cfe977f1f6a0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4607153
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Quyen Le <lehoangquyen@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
This reverts commit 43ef50f389
Reason for revert: LLVM bug is fixed upstream.
Fix:
https://reviews.llvm.org/rG92fbb602f3b635110417e40e2f774b31798b0b1d
LLVM Roll:
243d4473a3
CLs in the roll:
7586aeab..0c545a44
Original change's description:
> Android: Assert that CFI is disabled
>
> There appears to be a bug in the interaction of CFI and
> relative vtables. On armv9 it results in a crash with SIGILL
> when loading traces.
>
> Since we can't overwrite the flags used to control this
> just assert that it is correct in GN args.
>
> To avoid the assert, add the following to your GN args:
>
> arm_control_flow_integrity = "none"
>
> Test: Build and run traces on armv9 devices
> Bug: b/278955379
> Bug: chromium:1441148
Test: angle_trace_tests on ARM v9 device with flag removed from GN
Bug: b/278955379
Bug: chromium:1441148
Change-Id: Ib90405a143503896041c2522f484c234a943a6fb
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4684008
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Auto-Submit: Cody Northrop <cnorthrop@google.com>
Commit-Queue: Roman Lavrov <romanl@google.com>
Commit-Queue: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Roman Lavrov <romanl@google.com>
... and avoid going through the context (just to get a const cast).
This change is also in preparation for an follow up where some entry
points directly use ErrorSet and don't access context at all.
Bug: angleproject:8224
Change-Id: Idef0a88d9407870e7a84b4fe6967fbff175c269b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4678350
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
This reverts commit ebaadc6c2c.
Reason for revert: Breaking some Chrome/Dawn tests that use the VK backend
Original change's description:
> Terminate the display if initialization fails.
>
> If DisplayImpl::initialize fails, call terminate to ensure no resources
> are leaked.
>
> This is a speculative fix for dual GPU macs not falling back to the
> low power GPU. DisplayMtl leaks the metal device if it fails to
> initialize due to unsupported GPU families or vendors.
>
> Bug: chromium:1322521
> Change-Id: Ie227216bc92ef2834ec50190fbb78bec45e9c053
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4641107
> Commit-Queue: Geoff Lang <geofflang@chromium.org>
> Reviewed-by: Kenneth Russell <kbr@chromium.org>
Bug: chromium:1322521
Change-Id: I379521130071623a8d050d2cadf2059c0b696d32
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4678359
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
This state can be set by other threads, including those without a
context in the share group; context loss can originate from the Display
and is propagated to all contexts.
This change makes the relevant flags atomic which are read with relaxed
memory order to minimize their impact on performance.
Bug: angleproject:8224
Change-Id: I1f0a29210e07cd153db79fdc01d551cf96df4143
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4678784
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
There is a bit terminology confusion here that will be fixed in next CL.
If a depth attachment is read only, then there is no feedback loop, we
should not call feedback loop for read only depth attachment. The real
depth render feedback loop mode is formed when we write to depth and
sample from depth at the same time. In this condition, the content is
undefined per OpenGLES spec section 9.3.1
(https://registry.khronos.org/OpenGL/specs/es/3.2/es_spec_3.2.pdf). The
shouldSwitchToReadOnlyDepthStencilFeedbackLoopMode() implementation
handles the usage case that the same render pass has depth write and
then switch to read only. Under this usage there is no actual feedback
loop, and we should still work properly by end current render pass and
start a new render pass with read only depth attachment. This
implementation also treating the actual feedback loop case exactly the
same way by ending render pass first, even though this is undefined
behavior. gangstar_vegas has the exact this undefined behavior usage
case, where it write and sample from depth buffer at the same draw call.
Native driver is not ending the render pass but ANGLE currently does.
This puts ANGLE into worse performance. Since this is undefined
behavior, either way is correct. This CL checks if there is an actual
feedback loop in the current render pass and if yes, we adopt the native
driver's behavior that keep the current render pass going. This improves
gangstar_vegas frame time from 4.365ms to 3.89ms, and interestingly,
yield the same golden image.
Bug: b/289436017
Change-Id: Ifc04ecd8ad6455a88e8615bd5452b9cce88c6687
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4679361
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
When we switch to read only depth stencil mode, right now we always call
flushCommandsAndEndRenderPass, even though the started render pass is
empty and loadOp is load. This flush will cause render pass actually
submitted and color attachment being cleared and then color attachment
gets loaded in the subsequent render pass. In this CL, we only flush if
the depthStencil attachment has clear or written This CL save one
renderPass for the following app traces: antutu_refinery, aztec_ruins,
manhattan_10, manhattan_31.
Bug: b/290833623
Change-Id: I13b7a968d797b4c913f1cfbe9677d9b8abe791d2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4674087
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
