|
25390156
|
2025-08-21T00:13:19
|
|
Suppress unsafe buffers on a file-by-file basis in src/ [1 of N]
In this CL, we suppress many files but stop short of actually
enabling the warning by not removing the line from the
unsafe_buffers_paths.txt file. That will happen in a follow-on
CL, along with resolving any stragglers missed here.
This is mostly a manual change so as to familiarize myself with
the kinds of issues faced by the Angle codebase when applying buffer
safety warnings.
-- Re-generate affected hashes.
-- Clang-format applied to all changed files.
-- Add a few missing .reserve() calls to vectors as noticed.
-- Fix some mismatches between file names and header comments.
-- Be more consistent with header comment format (blank lines and
trailing //-only lines when a filename comment adjoins license
boilerplate).
Bug: b/436880895
Change-Id: I3bde5cc2059acbe8345057289214f1a26f1c34aa
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6869022
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
d8dc3cc2
|
2025-08-02T12:02:20
|
|
Remove shared context lock from glVertexAttrib{I}Format
This CL removes shared context lock from glVertexAttribFormat() and
glVertexAttribIFormat() APIs, since they no longer access anything
outside VertexArrayPrivate. The main problem I had run into is
validation code. Before this CL, ValidateIntegerVertexFormat() needs
context's mStateCache for mCachedVertexAttribTypesValidation and
mCachedIntegerVertexAttribTypesValidation. Given these two cached value
are constant after initialization, in this CL, I have moved them to
PrivateStateCache. PrivateStateCache argument is added to
ValidateVertexAttribFormat() and ValidateVertexAttribIFormat() to get
them access to mCachedIntegerVertexAttribTypesValidation.
Bug: b/433331119
Change-Id: Ifc3fbed32b4d3722c335dd2c393bc6519ed0b544
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6822032
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
ae4aead5
|
2025-07-24T16:35:38
|
|
Remove sharedContextLock from glVertexAttrib{Divisor|Binding}
With prior CLs all the functions used by glVertexAttribDivisor*,
glVertexBindingDivisor and glVertexAttribBinding only access
VertexArrayPrivate. This CL removes shared context lock from these APIs.
Bug: b/433331119
Change-Id: Ib1632797c53d2cd7a31c21e93c0e69385c71a27f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6814157
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
394df705
|
2025-08-01T14:03:17
|
|
Cache per bufferIndex buffer properties in VertexArrayPrivate
This is another preparation CL. This CL caches per bindingIndex buffer
properties in VertexArrayPrivate: mCachedBufferPropertyMapped and
mCachedBufferPropertyMutableOrImpersistent. The only difference between
these and mCachedMappedArrayBuffers /
mCachedMutableOrImpersistentArrayBuffers is that one indexed by
attribIndex and another is indexed by bindingIndex. With this, when
attribute binding changes, we no longer need to make buffer access. With
this, we can move setVertexAttribBinding and setVertexBindingDivisor
from VertexArray into VertexArrayPrivate class and Context argument is
also removed.
Bug: b/433331119
Change-Id: I666544ee0585727ca92d640f372f5a64d1d85576
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6814156
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
fa29f604
|
2025-07-02T13:23:31
|
|
Remove sharedContextLock from {Enable|Disable}VertexAttribArray
VertexArray objects are per context objects. In theory they do not need
to protected by shared context lock. The reason we are taking locks
because all these functions end up accessing Buffer object which are
shared. In prior CLs we have removed subject observer usage from
VertexArray which means VertexArray no longer accessed from other
thread. In prior CLs we also split VertexArray into two classes:
VertexArrayPrivate which has no buffer, and VertexArray which is
subclass from VertexArrayPrivate and owns buffer. In this CL,
glEnableVertexAttribArray and glDisableVertexAttribArray calls no longer
take shared context lock. ContextPrivateEnableVertexAttribArray and
ContextPrivateDisableVertexAttribArray are called from these two APIs
and they only have access to StatePrivate. State Private holds a
VertexArrayPrivate pointer, which means they do not have anyway to
access buffer objects. The main challenge I run into here is
mCachedActiveClientAttribsMask, mCachedActiveBufferedAttribsMask,
mCachedActiveDefaultAttribsMask, mCachedHasAnyEnabledClientAttrib,
mCachedNonInstancedVertexElementLimit,
mCachedInstancedVertexElementLimit. These StateCache variable needs to
be updated when these two APIs are called, and calculating these
variable needs access to buffer object. The solution here is adding a
bool mIsCachedActiveAttribMasksValid in the PrivateStateCache so that
instead of immediately update these mCached* variable, we just set
mIsCachedActiveAttribMasksValid to false. Then whenever any of these
mCached* variable is needed, we will check
mIsCachedActiveAttribMasksValid and calculate these cached variables. It
adds one if check when accessing these caches, but the other benefit is
that we may have avoided duplicated calculation when multiple states
changed.
Bug: b/433331119
Change-Id: I3227c72bc40501712db93fb3d540b835f07150b5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4514436
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
2ef85c24
|
2025-07-09T17:13:52
|
|
Vulkan: Add support for GL_EXT_fragment_shading_rate
Add support for GL_EXT_fragment_shading_rate.
Bug: angleproject:420310117
Change-Id: I7b368afc45baf8551c222b2569991269117d385b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6726817
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Panfeng Hou <panfeng.hou@arm.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
b4d84458
|
2025-05-23T18:08:19
|
|
Move Buffer from VertexBinding to VertexArray
In later CL we will not taking shared context lock for certain
VertexArray API calls. VertexArray itself is per context, so this sounds
reasonable to do. The main challenge here is a lot of VertexArray
function end up accessing gl::Buffer object, which could be modified by
other shared contexts. In order to safely not taking the shared context
lock, we need to separate out Buffer object out of VertexArray itself so
that these lockless APIs will take VertexArray that does not have access
to buffer.
In this CL, VertexArray is split into two classes: VertexArrayPrivate is
everything in VertexArray except buffers. VertexArray is a subclass of
VertexArrayPrivate and owns all the buffers. Buffer is removed from
gl::VertexBinding class. In order to let back end access to buffers,
VertexArrayImpl holds a weak reference to
VertexArray::mVertexArrayBuffers (which is a vector of buffers).
Further, VertexArrayBufferBindingMask mBufferBindingMask is moved from
VertexArrayState into VertexArray class well, since it tracks which
index has a non-null buffer. The bulk of change are due to the
VertexARrayImpl constructor change, since it now takes
vertexArrayBuffers argument. Other bulk of changes are due to
VertexBinding no long has the buffer, but you need to get it directly
from VertexArray or VertexArrayImpl.
This CL also reverts some of the change in crrev.com/c/6758215 that
mVertexBindings no longer contains kElementArrayBufferIndex.
BYPASS_LARGE_CHANGE_WARNING
Bug: b/433331119
Change-Id: I15f4576f7c5c8d8f4d9c9c07d38a60ce539bfeea
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6774702
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
b7582680
|
2025-02-24T18:04:32
|
|
Reland: GL: Allow untranslated shaders to pass through on GLES
Add an EGL extension EGL_ANGLE_create_context_passthrough_shaders which
uses the NULL translator and passes the original shader to the driver.
The parser is still used for shader reflection.
Always enable the null compiler backend. It has almost no binary size
cost and is now potentially used when the null ANGLE backend is not
enabled.
Bug: angleproject:398857482
Change-Id: Id528189ccbbacb1c444eacb151baadfda9fcc04b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6488609
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
|
|
30a1cbc9
|
2025-07-03T13:00:05
|
|
Vulkan: Separate out descriptor set for uniform buffers
Bug: angleproject:426412564
Change-Id: Icdbb1e634fc543714d1e3b9cdba0530d400cb153
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6705153
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
2ac49bb6
|
2025-07-01T12:11:12
|
|
Reland "Vulkan: Move VertexArray::ElementBuffer away from observer"
This reverts commit 79ac1a8cd767a32cce6401203e20c4bd4ca4d539.
Reason for revert: the regression bug is fixed in PS6
The regression bug with the original CL is caused by when we bind a
vertex array without element buffer rebind, we missed to reset
mIndexRangeInlineCache. The other bug is that VertexArray::mDiryBits is
64 bit but VertexArrayBufferBindingMask is 16 bit, in
VertexArray::setDependentDirtyBits(), bufferBindingMask.to_ulong() <<
DIRTY_BIT_BUFFER_DATA_0 is only producing the 32 bit value on windows
platform due to unsigned long is 32 bit value. bits() is used and bit
shift is operated on to uint64_t here to avoid dropping high bits on
windows.
Two tests are added that reproduce the regression bug caused by
the original CL.
Bug: angleproject:400711938
Original change's description:
> Revert "Vulkan: Move VertexArray::ElementBuffer away from observer"
>
> This reverts commit 3f012a43ee2c101543785720eedfeaa80708479d.
>
> Reason for revert: https://issues.chromium.org/427064102
>
> Bug: angleproject:400711938
> Original change's description:
> > Vulkan: Move VertexArray::ElementBuffer away from observer
> >
> > Right now, VertexArray's element buffer is always observing buffer's
> > change. In previous CLs, we have moved vertex array away from
> > subject/observer usage. This CL moves element buffer away from
> > subject/observer as well. Since the gl::Buffer tracks buffer's binding
> > to each context's current vertex array's binding point,
> > kElementArrayBufferIndex is added to VertexArrayBufferBindingMask bits
> > so that the element buffer is tracked exactly the same as other vertex
> > array buffer bindings. The VerextArray code has been modified to handle
> > this special bit, since element buffer has its own binding point
> > VertexArrayState::mElementArrayBuffer as opposed to
> > VertexArrayState::mVertexBindings. After this CL, VertexArray object
> > should be completely off subject/observer usages.
> >
> > Bug: angleproject:400711938
> > Change-Id: I662ddfabc95034bdc7734939c944ab033f41801c
> > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6552160
> > Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> > Reviewed-by: Geoff Lang <geofflang@chromium.org>
> > Commit-Queue: Charlie Lao <cclao@google.com>
>
> Bug: angleproject:400711938
> Change-Id: I9487ba8b108baaeda1c8a27189dba64f77616774
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6663539
> Commit-Queue: Charlie Lao <cclao@google.com>
> Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Bug: angleproject:400711938
Change-Id: I3f47ad1238c41f12b5cbd7a59b84be3fce1e9562
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6664004
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
d5babf99
|
2025-06-23T12:46:51
|
|
Vulkan: Fix unhandled deferred clears after glGetMultisamplefv
Issue was introduced in the commit that implemented deferred clears.
The `glGetMultisamplefv()` synchronizes draw framebuffer which defers
possibly staged clears. Since API is not handling deferred clears they
are left untouched, causing the ASSERT.
This change fixes the issue by not deferring clears for the
`glGetMultisamplefv()` command during flushing staged updates of dirty
framebuffer attachments.
Changes:
- Add `gl::Command::GetMultisample` enumeration for clarity.
- Add `gl::CommandBlitBuffer::CommandBlitBufferDepthStencil` enumeration
to improve code readability.
- Add `command` parameter into `gl::State::syncDirtyObject()` method to
use actual command enum instead of `Other`.
- Remove `previousDeferredClears` local variable and update ASSERT in
the `FramebufferVk::syncState()` method. New assert ensures empty
`mDeferredClears` instead of just checking dirty attachments, since
it is easy to make all attachments dirty making old and new assertions
act the same.
- Replace logic in `FramebufferVk::syncState()` that decides whether
need to defer attachments or not with switch-case. This makes the
logic more clear regarding handling individual commands and simplify
updating this handling in the future. Except of the bug fix with
`GetMultisample` command, handling of other command is uncached.
- Remove `flushDeferredClears()` from `FramebufferVk::readPixels()`
because `mDeferredClears` are not expected (now it's more clear after
the refactoring). And even if there are `mDeferredClears` (in case of
a bug or after API failure), `flushDeferredClears()` only flushes
clears for the draw framebuffer, while checking `mDeferredClears` of
the read framebuffer. This is a problem in case if read and draw
framebuffers are not the same.
Bug: angleproject:40644727
Test: angle_end2end_tests --gtest_filter=TextureMultisampleTest.GetMultisamplefvAfterClear/*
Test: angle_end2end_tests --gtest_filter=EGLSurfaceTest.GetMultisamplefvAfterClear/*
Change-Id: I376a62de52de5e17dbc63cc7ddb0506741a69266
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6661958
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
79ac1a8c
|
2025-06-23T11:11:10
|
|
Revert "Vulkan: Move VertexArray::ElementBuffer away from observer"
This reverts commit 3f012a43ee2c101543785720eedfeaa80708479d.
Reason for revert: https://issues.chromium.org/427064102
Bug: angleproject:400711938
Original change's description:
> Vulkan: Move VertexArray::ElementBuffer away from observer
>
> Right now, VertexArray's element buffer is always observing buffer's
> change. In previous CLs, we have moved vertex array away from
> subject/observer usage. This CL moves element buffer away from
> subject/observer as well. Since the gl::Buffer tracks buffer's binding
> to each context's current vertex array's binding point,
> kElementArrayBufferIndex is added to VertexArrayBufferBindingMask bits
> so that the element buffer is tracked exactly the same as other vertex
> array buffer bindings. The VerextArray code has been modified to handle
> this special bit, since element buffer has its own binding point
> VertexArrayState::mElementArrayBuffer as opposed to
> VertexArrayState::mVertexBindings. After this CL, VertexArray object
> should be completely off subject/observer usages.
>
> Bug: angleproject:400711938
> Change-Id: I662ddfabc95034bdc7734939c944ab033f41801c
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6552160
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Reviewed-by: Geoff Lang <geofflang@chromium.org>
> Commit-Queue: Charlie Lao <cclao@google.com>
Bug: angleproject:400711938
Change-Id: I9487ba8b108baaeda1c8a27189dba64f77616774
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6663539
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
2fd033d0
|
2025-05-22T04:21:11
|
|
Vulkan: Optimize updates to uniform buffers
... when only the offset is modified. Most of the work done when
handling dirty uniforms can be skipped since the buffer bindings
haven't changed
Bug: angleproject:386749841
Tests: UniformBufferTest31.UniformBufferBindingRangeChange*Vulkan
Change-Id: Ic811bd71f0f2993f88ce9bcf93f9e8e46dfc6d99
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6581359
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
9a436772
|
2025-06-04T16:47:51
|
|
Vulkan: Add entry points for GL_EXT_fragment_shading_rate
Bug: angleproject:420310117
Change-Id: I8a8efad6cad810b2cb0b600106f6496070495605
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6620340
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
8c48b502
|
2025-06-05T02:09:54
|
|
Vulkan: Fix deferred clear vs robust init vs invalidate
The DIRTY_OBJECT_DRAW_ATTACHMENTS bit, when handled, goes over
framebuffer attachments and requests that they be cleared. This is done
only with robust init.
The DIRTY_OBJECT_DRAW_FRAMEBUFFER bit, when handled, results in staged
updates to be applied to the attachments.
When syncDirtyObjects is called, the above bits are handled. If we end
up in a situation where DIRTY_OBJECT_DRAW_ATTACHMENTS is set, but not
DIRTY_OBJECT_DRAW_FRAMEBUFFER, the following happens with Vulkan:
- Handle DIRTY_OBJECT_DRAW_ATTACHMENTS
- TextureVk::initializeContents
- ImageHelper::stageResourceClearWithFormat
- Observer message to TextureVk->Texture->Framebuffer->Context
- Context sets DIRTY_OBJECT_DRAW_FRAMEBUFFER
- However syncDirtyObjects does not notice this bit, as it has cached
the dirty objects and is in the middle of looping over them
In the above scenario, the call that results in syncDirtyObjects does
not process the draw framebuffer (if not already dirty for some other
reason), meaning the clear is not applied _before_ the current operation
but after it (whenever framebuffer is synced next).
In this change, I attempted to ensure that if
DIRTY_OBJECT_DRAW_ATTACHMENTS is ever dirty,
DIRTY_OBJECT_DRAW_FRAMEBUFFER is also dirty. There were a few
operations that could theoretically lead to this which are fixed by this
change. The particular one that revealed the bug was
State::syncDirtyObject syncing only the FRAMEBUFFER bit and leaving the
ATTACHMENTS bit for the unsuspecting following operation.
The aforementioned assertion is not included in this change however, as
it revealed one unresolved issue with the d3d backend where
DIRTY_OBJECT_DRAW_ATTACHMENTS is not set, but processing
DIRTY_OBJECT_DRAW_ATTACHMENTS sets it while dirty bits are being
processed.
Bug: b/381284577
Change-Id: If3c35fbade069ae75f66dd6d4df5d73882a08a93
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6621059
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
3f012a43
|
2025-05-14T17:11:06
|
|
Vulkan: Move VertexArray::ElementBuffer away from observer
Right now, VertexArray's element buffer is always observing buffer's
change. In previous CLs, we have moved vertex array away from
subject/observer usage. This CL moves element buffer away from
subject/observer as well. Since the gl::Buffer tracks buffer's binding
to each context's current vertex array's binding point,
kElementArrayBufferIndex is added to VertexArrayBufferBindingMask bits
so that the element buffer is tracked exactly the same as other vertex
array buffer bindings. The VerextArray code has been modified to handle
this special bit, since element buffer has its own binding point
VertexArrayState::mElementArrayBuffer as opposed to
VertexArrayState::mVertexBindings. After this CL, VertexArray object
should be completely off subject/observer usages.
Bug: angleproject:400711938
Change-Id: I662ddfabc95034bdc7734939c944ab033f41801c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6552160
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
f5f6704c
|
2025-03-27T13:58:14
|
|
Vulkan: Remove mArrayBufferObserverBindings
Right now VertexArray observes gl::Buffer change. Buffer change will end
up with many virtual function calls on VertexArray. GL spec says that
when buffer changes, only the current context's vertex array have to
pick up the changes without any GL API call. All other context's vertex
array must issue bind calls to pick up the buffer's state change. This
CL removes VertexArray::mArrayBufferObserverBindings as gl::Buffer's
observer. The Buffer's change is directly applied to current context's
vertexArray (Note that gl::VertexArray still have mContentsObservers
which is not touched in this CL. Once the content observer also removed,
there will be no observer calls into gl::VertexArray which allows us to
do further optimizations on vertex arrays.)
In order to further reduce the overhead, we also tracks vertex array's
binding index in the buffer. When a buffer is bound to current vertex
array, the bit is set at that index and bit is removed when buffer is
unbound. When vertex array becomes un-current, all bits are cleared.
Since a buffer could be bound to multiple context's current vertex
array, that bitmask is tracked for multiple contexts with the contextID.
Bug: angleproject:400711938
Change-Id: I9ad91573e101d7bf11a742a3d823bd8965f43395
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6419663
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
3b77a177
|
2025-04-23T15:47:07
|
|
Optimize vertex attribute and buffer state change
Bug: angleproject:386749841
Change-Id: I25968902282f6a201510e2ee17ea85fd71ef57c7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6483915
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
408f5853
|
2025-04-04T00:00:00
|
|
Make gl::Version data members private
* Further simplified gl::Version implementation by
making data members private and merging them.
* Used proper version struct comparisons instead
of accessing individual version components.
* Moved known version constants to Version.h
for broader availability.
* Removed no longer used helpers:
* PrivateState::getClientMinorVersion()
* State::getClientMinorVersion()
* Context::getClientMinorVersion()
Bug: angleproject:408843436
Change-Id: I3ae8f495269d649253fa2381ecbfc018a184fa20
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6460787
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
5dd05578
|
2025-04-14T07:34:57
|
|
Revert "GL: Allow untranslated shaders to pass through on GLES"
This reverts commit 4e77552b86a89b449ada6d6c18f84285f5812b1d.
Reason for revert: breaks ChromeOS and fuzzers
Bug: angleproject:398857482
Original change's description:
> GL: Allow untranslated shaders to pass through on GLES
>
> Add an EGL extension EGL_ANGLE_create_context_passthrough_shaders which
> uses the NULL translator and passes the original shader to the driver.
> The parser is still used for shader reflection.
>
> Bug: angleproject:398857482
> Change-Id: I7c5fcc318c7e11931f78c08dcbf4764bf77d397d
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6297527
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Commit-Queue: Geoff Lang <geofflang@chromium.org>
Bug: angleproject:398857482, angleproject:410423936
Bug: chromium:410114655, chromium:410100607, chromium:410121218
Bug: chromium:410052365, chromium:410290507, chromium:410178288
No-Presubmit: true
Change-Id: I45b01960637a1cda05d21a7df6d07465f6a8f5e9
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6448984
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Yuly Novikov <ynovikov@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Yuly Novikov <ynovikov@chromium.org>
|
|
|
4e77552b
|
2025-02-24T18:04:32
|
|
GL: Allow untranslated shaders to pass through on GLES
Add an EGL extension EGL_ANGLE_create_context_passthrough_shaders which
uses the NULL translator and passes the original shader to the driver.
The parser is still used for shader reflection.
Bug: angleproject:398857482
Change-Id: I7c5fcc318c7e11931f78c08dcbf4764bf77d397d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6297527
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
|
|
|
f56c8e02
|
2025-03-28T00:00:00
|
|
Fix & cleanup advanced blend equations support
* Made advanced blend equation extensions
enableable to facilitate better testing.
* Made initial BLEND_ADVANCED_COHERENT state to be
unconditionally true regardless of the extension
support. If the coherent extension is unsupported,
that state must not be observable anyway.
* Ensured that advanced blend equation functionality
is supported on unextended OpenGL ES 3.2 contexts.
* Removed redundant ES 2.0+ context version checks
because these extensions must never be enabled
on ES 1.x contexts.
* Fixed ValidateBlendBarrierKHR to set the correct
error code and properly mark invalid calls.
* Added more negative test cases and enabled
tests on OpenGL ES 3.0 contexts.
Bug: angleproject:42262258
Bug: angleproject:406922380
Change-Id: I709376ad40b09972a31a691ca3813e87dd2c8165
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6421857
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
c2679dbc
|
2025-03-10T12:15:08
|
|
Key vertex array index range cache on restart
Key vertex array index range cache on primitive restart enablement.
Add the test to WebGLCompatibilityTest as otherwise the
VertexArray::getIndexRange() is not testable. Currently WebGL
compatibility contexts allow changing primitive restart.
Bug: angleproject:401284933
Change-Id: I48a53770d7dcb2276b89fd743f4834c53c8d8d1e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6333538
Auto-Submit: Kimmo Kinnunen <kkinnunen@apple.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
|
|
292bb458
|
2025-03-14T12:17:49
|
|
Cut MAX_COLOR_ATTACHMENTS_WITH_ACTIVE_PIXEL_LOCAL_STORAGE_ANGLE
Since the number of real devices that support framebuffer fetch, but do
not support draw_buffers_indexed, is effectively zero,
MAX_COLOR_ATTACHMENTS_WITH_ACTIVE_PIXEL_LOCAL_STORAGE_ANGLE is an
unnecessary complication. These hypothetical devices can fall back on
shader images or just not support pixel local storage at all.
This closes the door for WEBGL_shader_pixel_local_storage to ever be
implemented on top of the ES2 extension that inspired it all,
EXT_shader_pixel_local_storage, but WebGL can just use framebuffer fetch
instead, or maybe even EXT_shader_pixel_local_storage2 some day.
This dramatically simplifies the WEBGL_shader_pixel_local_storage
extension.
Bug: angleproject:40096838
Change-Id: I9c51f2ce000620f883cb7917d4e8618c8e9ee803
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6354657
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Chris Dalton <chris@rive.app>
|
|
|
ae71cc1c
|
2025-03-11T16:36:52
|
|
Don't destroy blend or color mask state in PLS
The browser caches this state, so conditionally destroying it would
invalidate the browser's cache. Instead, cache modifications to
overridden PLS blend & color mask state in ContextPrivateState, and
restore it upon ending PLS.
Also update the spec to specify that FRAMEBUFFER_DEFAULT_WIDTH and
FRAMEBUFFER_DEFAULT_HEIGHT may be overridden during PLS in ES 3.1.
Bug: angleproject:40096838
Change-Id: Ic2c0aa6dc33ada7350e15e27bef22c79ca5f6c7f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6350727
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Alexey Knyazev <lexa.knyazev@gmail.com>
Commit-Queue: Chris Dalton <chris@rive.app>
|
|
bdff6ade
|
2025-03-10T17:49:35
|
|
Correct glGet* values for stencil masks
Using CastMaskValue for GL_STENCIL_VALUE_MASK,
GL_STENCIL_BACK_VALUE_MASK, GL_STENCIL_WRITEMASK and
GL_STENCIL_BACK_WRITEMASK would cast them from 0xFFFFFFFF
to 0x7FFFFFFF, which makes glGetInteger* and glGetFloat*
return wrong value for them. CastMaskValue is not
needed now, so we should delete it. Also, glGetFloat*
return value should be positive, so additional cast
is added for those masks.
Bug: angleproject:399774386
Change-Id: Ibc2a5fd232be25c854b33df513e3cc0c74cfe8a4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6342590
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
1ead4cbd
|
2025-03-07T09:49:21
|
|
Allow texture modification commands while PLS is active
Just do a little extra validation and bounce modifications if they would
modify an active PLS plane.
Bug: angleproject:40096838
Change-Id: I6f27951f5d0ef5dfaf23b5a005a2d94a749e2c4f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6337703
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Alexey Knyazev <lexa.knyazev@gmail.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Chris Dalton <chris@rive.app>
|
|
87d891dc
|
2024-12-13T19:51:42
|
|
Inline more tiny functions on hot path
Similar to https://crrev.com/c/6094283, not as hot but broader.
Highlighted by PGO profile of driver_overhead_2 trace combined with size
and offset of the corresponding .so sections to maximize reduction in
TLB misses.
Improves driver_overhead_2 performance by 1~2% on Pixel 8. Almost no
change in .so size as functions are tiny.
Bug: b/383305597
Change-Id: Ib1c021d4635141b879667b59305e4d45de7b8aef
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6088958
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Roman Lavrov <romanl@google.com>
|
|
100c0b8c
|
2024-11-04T13:58:00
|
|
Preserve mMinSampleShading value when SAMPLE_SHADING enable is toggled
Preserve mMinSampleShading value when SAMPLE_SHADING enable is toggled.
Initial value of MIN_SAMPLE_SHADING_VALUE is zero and that value
should not be changed during glEnable(SAMPLE_SHADING_OES).
Bug: angleproject:376174077
Change-Id: Iea06d7480167eff5722c2d5eef23287e8bb956f8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5981462
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Alexey Knyazev <lexa.knyazev@gmail.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
0bb109aa
|
2024-11-28T00:00:00
|
|
Fix validation for 2D multisample array textures
* Fixes:
* TEXTURE_BINDING_2D_MULTISAMPLE_ARRAY query must
be rejected if the functionality is not enabled.
* GetInternalFormativ must accept TEXTURE_2D_MULTISAMPLE_ARRAY
on unextended OpenGL ES 3.2 contexts.
* Added validation to the OpenGL ES 3.2 TexStorage3DMultisample
entry point.
* Cleanups:
* Removed OES suffix from the enum conversion.
* Incorrect extension name in the error message.
* Do not create a 2D multisample array zero texture object
if the backend does not support the functionality.
* Replaced redundant FramebufferTexture validation with an assertion.
* Do not allocate texture binding vectors for 2D multisample array
textures if the backend does not support the functionality.
* Aligned the 2D multisample array texture target assert in
RecordBindTextureTypeError with the actual error condition.
Fixed: angleproject:381270278
Change-Id: Idbbc86e2efe1bbc25d9570d515b67c1a32255d99
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6063068
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
7070a9e9
|
2024-11-20T00:21:16
|
|
Remove draw buffer validation clauses from PLS
It was cumbersome to implement all this validation browser side for
WebGL.
Rather than making it an error to update blend and color mask on
reserved PLS draw buffers, glBeginPixelLocalStorageANGLE() can just
implicitly disable blend, and enable the color mask on overridden draw
buffers. Later calls to enable blend or change the color mask on
overridden planes are silently ignored until
glEndPixelLocalStorageANGLE().
Bug: angleproject:40096838
Change-Id: Ic7e1c5113e7d3fad3b80d0178075df646540d743
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6045421
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Chris Dalton <chris@rive.app>
|
|
|
166b72c9
|
2024-09-30T19:07:26
|
|
GL_ANGLE_blob_cache implementation.
Bug: chromium:370538323
Change-Id: Ic51a951e78b48b315e36f518bcc39ff2d54660a6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5900761
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
|
|
|
b16d105f
|
2024-10-03T10:25:32
|
|
Remove Desktop GL front-end support
For Desktop GL applications, please use Zink!
Bug: angleproject:370937467
Change-Id: Ie734634bb62a2e98c80e1b32d8b3d34624da3c04
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5905428
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
da572160
|
2024-07-23T16:36:10
|
|
Reland: GL: Forward client-side arrays to the driver when possible
The OpenGL driver can handle client-side arrays when the context is
OpenGL ES or a desktop GL compatibility profile. When in these
situations, use the driver default VAO for all frontend context VAOs
and forward client-side data directly to the driver.
Fix synchronizing the default VAO state for external contexts. There
is no valid VertexArrayStateGL for external VAOs so make sure it's
nulled and the VAO dirty bits are set so the correct VAO state is
reapplied.
Disable syncing to the default VAO for external contexts. The only
VAO that they can share with ANGLE's internal state is the default
VAO so avoid having to save and restore its state.
Bug: angleproject:355034686
Change-Id: I015bbbc854938fe4bc1e92d0ca8fe04628d0db16
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5743284
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
|
|
e86ba9ab
|
2024-06-26T13:38:18
|
|
Vulkan: Fix querying support of prim restart patch
* Added a cap to reflect support for primitive restart for patches.
* primitiveRestartForPatchesSupported
* In Vulkan, it is determined through the following component from
the existing related device feature:
* primitiveTopologyPatchListRestart
* Updated querying PRIMITIVE_RESTART_FOR_PATCHES_SUPPORTED via glGet().
* Now it is only available on ES 3.2 or if tessellation shaders are
supported. Otherwise, there will be a validation error.
* It returns primitiveRestartForPatchesSupported.
* Added a unit test that queries this value and ensures that it remains
the same regardless of whether primitive restart is enabled.
Bug: angleproject:349610458
Change-Id: If43a5326f0886cf10e38b4e73a868f46b1052533
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5661108
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
48969c95
|
2024-05-31T16:34:07
|
|
GL: Implement QCOM_tiled_rendering
Bug: angleproject:343900918
Change-Id: I01612e11795d7aa8ee20f6e9bd5ef62fe40e2910
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5588630
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
|
|
|
3f572905
|
2024-06-19T17:46:38
|
|
Add basic begin/end support for perf counters
The AMD_performance_monitor extension has explicit begin/end calls to
capture counters. This was not implemented in ANGLE and the tests were
relying on ANGLE always capturing counters (incurring a small overhead).
This change does not complete the implementation of that extension, but
does add basic support for starting and stopping perf counter
measurements. While inactive, most counters are not updated.
Bug: angleproject:42267038
Change-Id: I3ff6448b22ca247c217401cb2d76ef4142c9d759
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5639343
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
|
|
|
a1dea207
|
2024-06-13T11:40:39
|
|
Implement KHR_blend_equation_advanced_coherent
* Updated the validation for glBlendBarrier() and ~KHR().
* GL state now includes mBlendAdvancedCoherent.
* Updated glEnable() to accept GL_BLEND_ADVANCED_COHERENT_KHR.
* It can be queried via glGetIntegerv(), etc.
* EXTENDED_DIRTY_BIT_BLEND_ADVANCED_COHERENT added.
* Added a corresponding bit to ExternalContextState.
* If coherence is supported, there should be no need to use blend
barriers, as, based on the spec, the advanced blend ops should
then follow order like the basic blend ops.
* Relevant tests: *GLES31.functional.blend_equation_advanced.coherent*
* On Linux/NVIDIA: From "Not supported" to "Passed"
Bug: angleproject:42262258
Change-Id: I7e0e43bdc71524eec111c2d3b024fe73c9795e55
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5634381
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
d193d51b
|
2024-06-17T22:46:08
|
|
Replace issue ids post migration to new issue tracker
This change replaces anglebug.com/NNNN links.
Bug: None
Change-Id: I8ac3aec8d2a8a844b3d7b99fc0a6b2be8da31761
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637912
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
ebb56cee
|
2024-05-31T15:10:37
|
|
Implement OES_tessellation_shader
Based on the specs, there are no functional differences between
OES and EXT.
* Added validation for glPatchParameteriOES() and the core
glPatchParameteri().
* Added the extension support for GLSL.
* EXT_shader_io_blocks is implicitly enabled for the EXT geometry
and tessellation shader extensions.
* OES_shader_io_blocks is implicitly enabled for the OES versions
of said extensions.
* Added a test to make sure using this extension works instead of EXT.
* Turned the repeated test code into a function:
* testTessellationTextureBufferAccess
* Skipped the tests that fail on various platforms.
* It seems that these tests were being skipped before enabling
this extension ("Not supported").
Bug: b/344030760
Bug: angleproject:345306326
Bug: angleproject:345304850
Bug: angleproject:345312771
Change-Id: I905da0132bf6525cb453dcaa613e4deb3155c4dd
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5595611
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
|
|
|
c41cbb3d
|
2024-06-03T18:59:27
|
|
Fix binary is not cached after isBinaryReady() is true
Backend may wait and clear `mPostLinkSubTasks`. The `isBinaryReady()`
will check, that there are no tasks, and will skip the caching.
This change renamed `cacheProgramBinaryIfNotAlready()` to more general
`cacheProgramBinaryIfNecessary()`, because it skips caching if there
are post link tasks.
The `cacheProgramBinary()` renamed to
`cacheProgramBinaryIfNotAlready()`, to better reflect it's behavior.
Call `cacheProgramBinaryIfNotAlready()` from `isBinaryReady()` if there
no post link tasks to ensure binary is cached.
Removed check for empty `mPostLinkSubTasks` before calling executable's
wait, because same check already performed internally. The
`waitForPostLinkTasks()` is not on hot path and does not require
avoiding no-op method call.
Bug: angleproject:8297
Change-Id: I2bd78c15231805cda4b62a9889287d8cf780cd1e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5593928
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
|
|
|
0508fc9b
|
2024-04-23T15:32:52
|
|
Reland "Cleanup: replace DirtyObjectType check with constexpr generator"
Avoid using lambdas with member function pointers which caused issues
on MSVC C++17.
This is a reland of commit 89caa0e1d99e45f3d6f355f6e14c147f8de3e0e5
Original change's description:
> Cleanup: replace DirtyObjectType check with constexpr generator
>
> Static assert was meant to avoid kDirtyObjectHandlers getting out of
> sync, but it doesn't achieve that goal as it's just comparing values
> with ints which is confusing.
>
> Replacing with constexpr generated std::array. C++20 allows to easily
> validate that all values are set by _not_ default-initializing
> `handlers`. C++17 makes it trickier, addeded static_assert on an
> additional static constexpr bool (silly but I can't find a more concise
> way)
>
> Bug: angleproject:8666
> Bug: b/335295728
> Change-Id: Idf9bbd087d09d5ba253a7587ce0503cae3fcf3a7
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5478231
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Commit-Queue: Roman Lavrov <romanl@google.com>
Bug: angleproject:8666
Bug: b/335295728
Change-Id: I62e66b700512e072ef10cc57a17e8837a534c0d5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5589285
Commit-Queue: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
073b7628
|
2024-05-21T21:49:37
|
|
Revert "Cleanup: replace DirtyObjectType check with constexpr generator"
This reverts commit 89caa0e1d99e45f3d6f355f6e14c147f8de3e0e5.
Reason for revert: compile errors on gcc and msvc c++17
Original change's description:
> Cleanup: replace DirtyObjectType check with constexpr generator
>
> Static assert was meant to avoid kDirtyObjectHandlers getting out of
> sync, but it doesn't achieve that goal as it's just comparing values
> with ints which is confusing.
>
> Replacing with constexpr generated std::array. C++20 allows to easily
> validate that all values are set by _not_ default-initializing
> `handlers`. C++17 makes it trickier, addeded static_assert on an
> additional static constexpr bool (silly but I can't find a more concise
> way)
>
> Bug: angleproject:8666
> Bug: b/335295728
> Change-Id: Idf9bbd087d09d5ba253a7587ce0503cae3fcf3a7
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5478231
> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
> Commit-Queue: Roman Lavrov <romanl@google.com>
Bug: angleproject:8666
Bug: b/335295728
Change-Id: Ie272f09f0e21498848ac3ed6477dabf28aa3da42
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5554615
Commit-Queue: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
89caa0e1
|
2024-04-23T15:32:52
|
|
Cleanup: replace DirtyObjectType check with constexpr generator
Static assert was meant to avoid kDirtyObjectHandlers getting out of
sync, but it doesn't achieve that goal as it's just comparing values
with ints which is confusing.
Replacing with constexpr generated std::array. C++20 allows to easily
validate that all values are set by _not_ default-initializing
`handlers`. C++17 makes it trickier, addeded static_assert on an
additional static constexpr bool (silly but I can't find a more concise
way)
Bug: angleproject:8666
Bug: b/335295728
Change-Id: Idf9bbd087d09d5ba253a7587ce0503cae3fcf3a7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5478231
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Roman Lavrov <romanl@google.com>
|
|
|
e41286e1
|
2024-04-10T11:05:09
|
|
Vulkan: Fix internal caching missing
Since the backend wait for post-link tasks was made possible [1], the
front-end may never get a chance to internally cache its binary. This
is because the decision to cache the binary was based on the existence
of post-link tasks, and the backend clearing that list made the
front-end confused.
In this change, a specific bool tracks whether binary is cached, and
that is checked at various times to make sure the binary cache is
eventually done.
[1]:https://chromium-review.googlesource.com/c/angle/angle/+/5427001
Bug: angleproject:8297
Change-Id: Iceefd0bca79d570d4910983be3660d6e725684a0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5445484
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: mohan maiya <m.maiya@samsung.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
d9943e44
|
2024-04-09T23:53:48
|
|
Remove Program::syncState
The last bit of responsibility still left in Program::syncState was to
wait for post-link tasks for the sake of EGLBlobCacheTest tests. A new
extension, GL_ANGLE_program_binary_readiness_query is created so that
the wait can be done in the test itself.
This extension is ultimately useful for applications as well, so they
can avoid blocking the CPU by calling glGetProgramBinary prematurely.
Bug: angleproject:8297
Change-Id: Ied6b755cb9b060198f82c7948bfd03441435a578
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5440302
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
ecc35205
|
2024-01-25T23:58:25
|
|
Move uniform block dirty bits to State
When glUniformBlockBinding changes the mapping from a program uniform
block to a buffer binding, all contexts in the share group need to
reprocess the affected block index. Prior to this change, the dirty
bits that indicated which blocks have their mapping redefined were
placed in the program executable, and were reset by the first context
that processed them. As a result, the other contexts in the share group
where not aware of such modifications.
Similarly, when a buffer changed in one context, the mapped program
blocks were marked dirty, with similar cross-context issues.
In this change, the dirty bits are moved to State, so every context
would react to these changes.
Bug: angleproject:8493
Change-Id: I5712002224cbc4a576bf2ac46e8e75f26ebc5b2a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5238991
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
0c4d6446
|
2024-01-24T10:38:45
|
|
Rework uniform block <-> uniform buffer mapping
In GLES, the shader declares which buffer binding a block (uniform,
storage or atomic counter) is bound to. For example:
layout(binding = 1) uniform ubo0 { ... };
layout(binding = 2) uniform ubo1 { ... };
layout(binding = 1) uniform ubo2 { ... };
In the above, ubo0 and ubo2 use data from the buffer bound to index 2
(through glBindBufferRange), while ubo1 uses data from the buffer bound
to index 1. For uniform blocks in particular, omitting the binding
is allowed, in which case it is implicitly bound to buffer 0.
GLES allows uniform blocks (and only uniform blocks) to remap their
bindings through calls to glUniformBlockBinding. This means that the
mapping of uniform blocks in the program (ubo0, ubo1, ubo2) to the
buffer bindings is not constant. For storage blocks and atomic counter
buffers, this binding _is_ constant and is determined at link time.
At link time, the mapping of blocks to buffers is determined based on
values specified in the shaders. This info is stored was stored in
gl::InterfaceBlock::binding (for UBOs and SSBOs), and
gl::AtomicCounterBuffer::binding. For clarity, this change renames
these members to ...::inShaderBinding.
When glUniformBlockBinding is called, the mapping is updated. Prior to
this change, gl::InterfaceBlock::binding was directly updated, trumping
the mapping determined at link time. A bug here was that after a call
to glProgramBinary, GL expects the mappings to reset to their original
link-time values, but instead ANGLE restored the mappings to what was
configured at the time the binary was retrieved.
This change tracks the uniform block -> buffer binding mapping
separately from the link results so that the original values can be
restored during glProgramBinary. In the process, the support data
structures for tracking this mapping are moved to ProgramExecutable and
the algorithms are simplified. Program Pipeline Objects maintain this
mapping identically to Programs and no longer require a special and more
costly path when a buffer state changes.
This change prepares for but does not yet fix the more fundamental bug
that the dirty bits are tracked in the program executable instead of the
context state, which makes changes not propagate to all contexts
correctly.
Bug: angleproject:8493
Change-Id: Ib0999f49be24db06ebe9a4917d06b90af899611e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5235883
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
073b6510
|
2024-01-11T07:40:32
|
|
Add missing GLES1 glGetBooleanv() enums
In OpenGL ES 1, capabilities that can be queried using glIsEnabled() can
also be queried using glGetBooleanv().
As such, some valid glGetBooleanv() calls were returning "Invalid pname"
error.
Added support for the missing enums in glGetBooleanv().
Bug: angleproject:8481
Tests: GLES1 - QueryTest*
Change-Id: Ic3a50eda4eae5855cd9491dbf217b5f69c1669b4
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5188456
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
c51259ec
|
2023-12-14T15:58:56
|
|
Vulkan: Ignore tex coord at draw if tex disabled
In GLES1, it is possible to disable texture rendering in some cases.
It is done using glDisable(GL_TEXTURE_2D).
In that case, if TexCoordPointer has been enabled in the client state
prior to disabling the texture, its data should no longer be used,
especially if the primitive changes to use more vertices. In that case,
there is a risk of unauthorized memory access.
In this CL, the active vertex attributes are updated accordingly if
texture is disabled using the aforementioned API call.
* Updated GLES1 renderer to ignore TexCoordPointer if texture has been
disabled.
* Added GLES1 tests for tex coord pointer, including tests to make sure
that tex coord pointer is no longer used if the texture is disabled
using glDisable(), and that it is used again when texture is enabled
using glEnable().
* To ensure that tex coord pointer is not used, the test draws using
enough vertex data that would exceed the texcoord array size, which
can trigger segfault if accessed.
Bug: b/310688730
Change-Id: I5d259c83a172cc1a11733c0b42c2f9b02c9b2967
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5124259
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
fb6b960c
|
2023-11-27T14:24:28
|
|
Remove GL_CHROMIUM_texture_filtering_hint
This was using an unregistered Vulkan extension to set the precision of
SwiftShader's internal filtering for the sake of Chrome. That's baked
in at build instead.
Bug: angleproject:8349
Bug: chromium:726075
Change-Id: I12849d2d29d99626f22a92ee9d74366f78658476
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5063344
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
3680a5dc
|
2023-11-17T13:51:07
|
|
Vulkan: Let program warmup continue passed link
The warmup task does not actually affect the link results, so there is
no reason to wait for it when the application queries the link status.
This change allows the warm up task to continue in parallel until the
program is used at draw time. This allows the warm up to be more
efficient when the link itself is not parallelized.
For applications that create programs in the middle of every frame, it's
still likely best to disable warm up (as the following immediate draw
will already effectively do the warm up).
Note that currently the warm up code in the Vulkan backend is not
completely thread-safe, and so the program still blocks on that task
before the first draw can happen (or the program is modified in any
way).
Bug: angleproject:8417
Change-Id: I0877fef39a0585c3279e32699ce817d4643d7cd6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5037538
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
2155534b
|
2023-11-06T11:49:20
|
|
Don't set dirty bits for attribs that are out of range.
PrivateState::setAllDirtyBits sets all bits in mDirtyCurrentValues.
When the context has fewer max attibutes than MAX_VERTEX_ATTRIBS, this
can cause out-of-bounds access to
PrivateState::mVertexAttribCurrentValues if the dirty bits are iterated
over without range validation.
Bug: chromium:1496378
Change-Id: I65481c432263a6e353a9361bba741b97dc5e20b1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5008034
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
|
|
|
8b4901d0
|
2023-11-06T10:43:14
|
|
Avoid GLenum conversion in BlendStateExt blend and equation
The following functions now return value as is without ToGLenum
conversion (that is often unnecessary):
getEquationColorIndexed
getEquationAlphaIndexed
getSrcColorIndexed
getDstColorIndexed
getSrcAlphaIndexed
getDstAlphaIndexed
(at least) getEquationColorIndexed is on the hot path with noticeable
performance impact; this CL also moves the implementation to the
header to allow inlining.
Bug: b/300968773
Change-Id: Ie223abe14b12afd7844686863ee5806945d10e45
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5008031
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Roman Lavrov <romanl@google.com>
|
|
1ea49a22
|
2023-10-13T11:28:41
|
|
Move uniform dirty bits to ProgramExecutable
Rather than try to funnel them through Program and ProgramPipeline to
the executable in the backend, just move them to ProgramExecutable in
the front end.
This fixes Dota Underlords at the same time due to not needing to set
the Program dirty to propagate bits.
Test: Dota Underlords
Test: ProgramPipelineTest31.ProgramPipelineBindBufferRange
Bug: b/299532942
Change-Id: Ic73c45608e22f89ca400ebf684f8cd287ed2f43a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4922969
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Cody Northrop <cnorthrop@google.com>
|
|
|
ca4dc52e
|
2023-06-22T15:20:12
|
|
Replace (Single/Shared)ContextMutex classed with ContextMutex
This CL removes `SingleContextMutex` class and not 100% safe
`Context::lockAndActivateSharedContextMutex()` method.
`SharedContextMutex<>` was replaced with `ContextMutex` with static
mutex type which is defined in "SharedContextMutex.h":
- ContextMutexType = std::mutex
Above refactoring also allows storing `State::mContext` by value,
instead by pointer. Actual mutex is referenced by `ContextMutex::mRoot`
member. This removes extra pointer indirection and slightly improves
performance.
If newly created Context uses shared textures/samplers, then it uses
`Display::mManagersMutex` root as its root.
Performance in Single/Shared cases now will be the same, and it should
be slightly faster then old Shared case (because of the reduced
complexity).
Bug: angleproject:8226
Change-Id: I7ca4d9ea008c665cbea98ace1c6e7bbc544f54b5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4632729
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
7b0bb0f6
|
2023-09-01T13:52:28
|
|
Properly "install" program executables
According to GL:
- The program has an executable
- The executable is overwritten during link.
- After a failed link, queries of the executable may return
half-linked information
- On glUseProgram, the executable is installed in the context
- On glUseProgramStages, the executable is installed in the program
pipeline
- After a successful link, the executable is updated wherever the
previous executable of the program was installed.
This change implements exactly the above:
- The program's and the program pipeline's executables are now
shared_ptr. References to an executable in the context and PPO are
also through a shared_ptr. Installing an executable thus translates
to sharing the executable.
- The context and PPOs are made to not reference the program directly,
but work solely through the executable. As a result, the program is
free to create a new executable for link.
With this change, the link job will be free to modify the executable as
necessary because that will not be accessed until the link is done.
Note that previous changes made the backend executable accessed through
the frontend one, and moved all link results to the frontend and backend
executables as appropriate.
Bug: angleproject:6358
Bug: angleproject:8297
Change-Id: Ie636b23ff7420ad284d18b525ec4f5fb559dd9d1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4823089
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
40111c68
|
2023-07-11T14:21:21
|
|
Rename context-local to context-private state
Bug: angleproject:8224
Change-Id: I1bb39475043f8fb14d683d11a038b4850692a8c6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4678781
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
732a8f07
|
2023-07-05T17:03:46
|
|
Move max-shader-compile-threads state out of LocalState
While this state is indeed context-local, setting it calls into the
backend (GL backend specifically, where it forwards the call to the
driver). The call to set this state is rare and now worth the risk
associated with making it lockless.
Bug: angleproject:8224
Change-Id: I3af395721fa18b9345698870c0da63e8cac83610
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4666355
Reviewed-by: Igor Nazarov <i.nazarov@samsung.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
ccf8530b
|
2023-06-27T16:01:58
|
|
Split context state by locality of get/set effect
Some state are purely local to the context when get or set. For
example, the state of depth test does not affect and is not affected by
any other state.
Some state on the other hand may affect other contexts. In particular,
some objects are shared between contexts of a share group, and may
affect each other through the observer interface.
These sets of state are separated to create a clear boundary between
state that can and cannot be accessed without holding the share group
lock. A follow up change removes locking from the entry points that
purely access the former set of states.
For the latter state, it is likely possible to access most if not all of
them without holding a lock, but careful inspection is required before
that can be considered. In particular, most entry points that simply
bind an object are likely harmless if the ref counter is turned atomic.
Bug: angleproject:8224
Change-Id: I91c3fa9de870c13d48012a5e06c177dab4010907
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4651375
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
2e209516
|
2023-06-26T11:58:50
|
|
Move state dirty bits definitions out of the class
This is in preparation for a follow up change that splits the state
class.
Bug: angleproject:8224
Change-Id: Ic9b253583e40fcc93ff37605b6b6e1deb55a6e55
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4631843
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
36c3e0f5
|
2023-01-17T17:42:59
|
|
Implement "Shared Context Mutex" functionality.
Existing implementation uses single `GlobalMutex` for
- EGL calls
- GL calls for Contexts with concurrent access.
This CL introduces abstract `egl::ContextMutex` with two
implementations:
- SingleContextMutex;
- SharedContextMutex<Mutex>;
Note:
`std::mutex` is used in this commit. It is very easy to change mutex
type either at compile-time or at run-time (single type per Display).
When Context:
- is not Shared;
- does not use `EGLImage`s;
- does not use EGL_DISPLAY_TEXTURE_SHARE_GROUP_ANGLE
- does not use EGL_DISPLAY_SEMAPHORE_SHARE_GROUP_ANGLE
then it will be using `SingleContextMutex` with minimal overhead.
Before such Context is used as `shareContext` or uses `EGLImage`
its mutex replaced by `SharedContextMutex<Mutex>`.
The `GlobalMutex` is only used for EGL calls, while `egl::ContextMutex`
implementations for GL calls. Because some EGL calls use Context,
explicit `egl::ContextMutex` lock is required. This is implemented by
generating "egl_context_mutex_autogen.h" header, and insertion of
`ANGLE_EGL_SCOPED_CONTEXT_LOCK()` macro before `ANGLE_EGL_VALIDATE()`
in each EGL entry point. Implementation in "egl_context_lock_impl.h"
returns lock for required APIs. Special cases of `egl::ContextMutex`
lock handled separately. `std::unique_lock<>` is not used for
performance reasons.
`egl::ContextMutex` explicitly locked when capturing EGL calls.
Fixes EGLImage problem:
https://chromium.googlesource.com/angle/angle/+/e18240d136d15e5cdfa4fa4a6355ca21c8d807b6
Mark contexts as shared when importing EGL images.
Details:
- EGLImage inherits Context's mutex when created.
Mutex is used when the EGLImage accessed or destroyed.
- When EGLImage is used in Context with other `egl::ContextMutex`,
two mutexes are merged into one.
- After the mutex merge, Context Groups will remain separate,
but will not be able to run in parallel.
Fixes race when checking `context->isShared()` in the
`SCOPED_SHARE_CONTEXT_LOCK()` macro. One Context may start executing GL
call while not "Shared", but become "Shared" inside the call. New
(second) "Shared" Context may immediately start using GL and potentially
corrupt some "Shared" state.
Possible performance benefit: allows parallel execution in some cases,
when single `GlobalMutex` would block.
Important note:
Process of replacing the `SingleContextMutex` by
`SharedContextMutex<Mutex>` is not 100% safe. This mean that
original Context may still be using `SingleContextMutex` after
activating `SharedContextMutex<Mutex>`. However, this was always
the case before introduction of this CL. Old `Context::mShared`
member update was not synchronized in any way at all. In other
words, this solution does not 100% fix the original problem.
For 100% safe solution `SingleContextMutex` should not be used
(always pass `SharedContextMutex<Mutex>` to the `gl::Context`
constructor). See `lockAndActivateSharedContextMutex()` for more
details.
CL adds new build option:
angle_enable_shared_context_mutex = true
Behavior with other build options:
- When:
`angle_enable_shared_context_mutex` is disabled or
`angle_enable_share_context_lock` is disabled or
`angle_force_context_check_every_call` is enabled,
Contexts will always have `SingleContextMutex`, however it will be
only used in special cases. `SCOPED_SHARE_CONTEXT_LOCK()` will use
`GlobalMutex` when applicable.
- Otherwise, `SCOPED_SHARE_CONTEXT_LOCK()` will use `egl::ContextMutex`.
Some GFXBench "1080p Driver Overhead 2 Offscreen" performance numbers.
Tested on S906B (Samsung Galaxy S22+) on old ANGLE base:
https://chromium.googlesource.com/angle/angle/+/807c94ea85e046c6f279d081d99f0fb1bcf1191a
Capture/Replay: Adjust tests do adhere to capture limits
Each test result is an average frame number from 6 runs.
SingleContextMutex 6579 ( +0.13%)
(old) GetContextLock() (mShared is false) 6570
Forced `mShared = true` or NOT using `SingleContextMutex`.
SharedContextMutex<std::mutex> FORCE 5061 (-22.97%)
(old) GetContextLock() FORCE 4766 (-27.46%)
Bug: angleproject:6957
Bug: chromium:1336126
Change-Id: Idcd919f9d4bf482b9ae489bd8b4415ec96048e32
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4374545
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
e21ecd1b
|
2023-05-26T14:06:46
|
|
Vulkan: Add dirty bit processing for uniform buffer change
When app calls glBufferData for the uniform buffer, we may end up
reallocate the storage. This will set DIRTY_BIT_UNIFORM_BUFFER_BINDINGS
on the context, but the exact uniform block index gets lost along the
way. This CL sets mDirtyBits on the program for the corresponding block
index and then changed vulkan backend to utilize the program's
mDirtyBits and only update the buffer if it is dirty, instead of always
update all uniform buffers even if only one of the buffer is dirty. In
order to make this work, this CL also adds the reverse tracking from
buffer binding to uniform blocks. Previously we already have the
tracking of which buffer binding index is used for which buffer block
index. This CL adds mUniformBlockBindingMasks which is an array of
BitSets. Each array element tracks all the uniform block index that is
using this buffer binding index (you can have the same buffer bound to
multiple uniform block index). Then when a buffer binding index is
dirty, that BitSet gets added into program's uniform block dirty bits.
This CL and previous CL improves GfxBench gl_driver2_off score 1.8%
(from average 6797 to average 6919) on pixel 7 pro.
Bug: b/282194402
Change-Id: Ic5002643a5297907276fc9b20ca7d21af9bdc4fe
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4553136
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
7d4c6d1d
|
2023-05-09T12:19:54
|
|
Allow glDelete* while PLS is active
Banning glDelete* is extremely dangerous. It will almost definitely
cause memory leaks in client code, and it makes JS garbage collection
needlessly complex.
Instead, specify that PLS is implicity deactivated if the client deletes
anything that is attached to the current draw framebuffer during a PLS
rendering pass.
Bug: chromium:1421437
Change-Id: I3a18ee6b5d5567431e6fa3eccea58cb049845502
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4521436
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Chris Dalton <chris@rive.app>
|
|
|
80dd54f9
|
2023-05-17T22:16:59
|
|
Vulkan: Enable VK_EXT_image_2d_view_of_3d and set flag
Based on a change by Yiwei Zhang <zzyiwei@chromium.org>
Enabling the extension was missed from
https://chromium-review.googlesource.com/c/angle/angle/+/3648586, and
some implementations do rely on the feature enablement (e.g. RADV). This
also fixes the VVL violations on satisfied implementations.
Additionally, the VK_IMAGE_CREATE_2D_VIEW_COMPATIBLE_BIT_EXT flag is
always set on 3D images when this extension is supported; it is
needed for both sampled and storage images, not just storage images.
Bug: b/274478146
Change-Id: Ibc210275e2d39ac0c54d1ae4c2451a5402360972
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4544762
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
73f9cf00
|
2023-03-31T00:00:00
|
|
GL: Implement polygon mode extensions
* Implemented polygon mode extensions
on the OpenGL backend
* Supported capture and serialization
of the new commands and state
* Added PolygonModeTest end2end tests
Bug: angleproject:1791
Bug: angleproject:8132
Change-Id: I3bc08546a02f110dd739950129bee25ccc507bf6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4492683
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
1810995c
|
2023-04-25T13:09:27
|
|
Capture/Replay: Initialize MEC alpha test state
Fixes Street Fighter IV CE rendering issues when capturing.
Test: angle_trace_tests --gtest_filter="*street_figher_iv_ce*"
Bug: b/278606770
Change-Id: Ifb44c45b19514e4cabed1e81be99bce5706ac4d3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4475732
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Mark Łobodziński <mark@lunarg.com>
|
|
|
c6ec59dc
|
2023-03-27T11:15:48
|
|
Explicitly pass the extended dirty bits to syncState.
Add a the extended dirty bits and bit mask to syncState instead of
calling gl::State::getAndResetExtendedDirtyBits when encountering
DIRTY_BIT_EXTENDED. It disallowed us from masking the extended dirty
bits and feels like an anti-pattern to modify the extended dirty bits
in gl::State from the backend.
This is a refactor only.
Bug: chromium:1410191
Change-Id: I66fdec3eb57e3426cf0fda9ccb759700eafdda14
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4374100
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
|
|
|
e809e7bd
|
2023-03-13T00:00:00
|
|
Reland "Implement EXT_depth_clamp"
This is a reland of commit f8c1418319ac2aef4b3101e322005b1d0f73120f
Host GPU bugs are observable in iOS Simulator
Original change's description:
> Implement EXT_depth_clamp
>
> * Added depthClamp to the RasterizerState
> * Added DepthWriteTest end2end tests covering
> both clipped and clamped depth writes
>
> Capture
> * Updated serialized rasterizer state
> * Updated CaptureMidExecutionSetup
>
> OpenGL
> * Requires GL 3.2 or ARB_depth_clamp
> on desktop contexts
> * Maps to EXT_depth_clamp on ES
>
> D3D11
> * Maps to the opposite of
> D3D11_RASTERIZER_DESC.DepthClipEnable
> * The new tests uncover several edge cases where
> a workaround is needed to implement unextended
> OpenGL semantics on top of D3D
>
> Metal
> * Maps to the setDepthClipMode command
>
> Bug: angleproject:8047
> Bug: angleproject:8077
> Change-Id: I1b3448e5b84443e4be18af9bc22d2f8495ac8267
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4347753
> Reviewed-by: Geoff Lang <geofflang@chromium.org>
> Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Bug: angleproject:8047
Bug: angleproject:8077
Change-Id: I8c5f8304276c97c51b2c3382cd2764592ee0c3fe
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4349938
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
4a77b0f5
|
2023-03-18T00:16:24
|
|
Revert "Implement EXT_depth_clamp"
This reverts commit f8c1418319ac2aef4b3101e322005b1d0f73120f.
Reason for revert: This change breaks angle_end2end_tests on Metal backend: https://ci.chromium.org/ui/p/chromium/builders/ci/ios-angle-intel/26035/overview
Original change's description:
> Implement EXT_depth_clamp
>
> * Added depthClamp to the RasterizerState
> * Added DepthWriteTest end2end tests covering
> both clipped and clamped depth writes
>
> Capture
> * Updated serialized rasterizer state
> * Updated CaptureMidExecutionSetup
>
> OpenGL
> * Requires GL 3.2 or ARB_depth_clamp
> on desktop contexts
> * Maps to EXT_depth_clamp on ES
>
> D3D11
> * Maps to the opposite of
> D3D11_RASTERIZER_DESC.DepthClipEnable
> * The new tests uncover several edge cases where
> a workaround is needed to implement unextended
> OpenGL semantics on top of D3D
>
> Metal
> * Maps to the setDepthClipMode command
>
> Bug: angleproject:8047
> Bug: angleproject:8077
> Change-Id: I1b3448e5b84443e4be18af9bc22d2f8495ac8267
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4347753
> Reviewed-by: Geoff Lang <geofflang@chromium.org>
> Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Bug: angleproject:8047
Bug: angleproject:8077
Change-Id: I829add68c006c72b7b4acf03aee3efa8a9a16fac
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4350876
Reviewed-by: Alexis Hétu <sugoi@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
|
|
|
f8c14183
|
2023-03-13T00:00:00
|
|
Implement EXT_depth_clamp
* Added depthClamp to the RasterizerState
* Added DepthWriteTest end2end tests covering
both clipped and clamped depth writes
Capture
* Updated serialized rasterizer state
* Updated CaptureMidExecutionSetup
OpenGL
* Requires GL 3.2 or ARB_depth_clamp
on desktop contexts
* Maps to EXT_depth_clamp on ES
D3D11
* Maps to the opposite of
D3D11_RASTERIZER_DESC.DepthClipEnable
* The new tests uncover several edge cases where
a workaround is needed to implement unextended
OpenGL semantics on top of D3D
Metal
* Maps to the setDepthClipMode command
Bug: angleproject:8047
Bug: angleproject:8077
Change-Id: I1b3448e5b84443e4be18af9bc22d2f8495ac8267
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4347753
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
|
1174582a
|
2023-03-06T00:00:00
|
|
GL: Implement EXT_clip_control
The extension is trivially exposed
if the current context supports it.
* Added packed clip control enums
* Removed unused state query code
* Aligned symbol names with the specs
Bug: angleproject:8066
Change-Id: I9d106f39800658ecc75f4525ee93cb534dc49f9e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4306770
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
1148a662
|
2023-02-15T08:25:51
|
|
Update GL_ARM_shader_framebuffer_fetch token support
These were missed during initial implementation because the target app
doesn't use them, and there are no tests for vendor extensions.
The implementation is basically a noop, but allows setting and
querying state, unblocking apps.
Also add a test that has basic usage.
Test: FramebufferFetchES31.BasicTokenUsage_ARM
Bug: b/269233744
Bug: angleproject:8025
Change-Id: Ic107150d4afd9c4c4984c58a1dafb1c18e608997
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4255965
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Cody Northrop <cnorthrop@google.com>
|
|
|
ef0fe638
|
2023-01-16T00:00:00
|
|
Implement EXT_polygon_offset_clamp
* Added polygonOffsetClamp to the RasterizerState
* Adjusted State::setPolygonOffsetParams
* Added PolygonOffsetClampTest end2end tests
* Added StateChangeTestES3.PolygonOffsetClamp test
* Suppressed the affected dEQP test as it has a bug
Capture
* Updated serialized rasterizer state
* Updated CaptureMidExecutionSetup
OpenGL
* Rely on the EXT extension defined both
for desktop and ES contexts
* On desktops, might as well use the ARB extension
or GL 4.6 once ANGLE supports them
D3D11
* Requires FL10_0 or higher
* Maps to D3D11_RASTERIZER_DESC.DepthBiasClamp
* Drive-by cleanup of extensions init code
Vulkan
* Requires depthBiasClamp physical device feature
* Maps to the depthBiasClamp parameter
of the vkCmdSetDepthBias command
Metal
* Maps to the clamp parameter
of the setDepthBias command
Bug: angleproject:7957
Change-Id: If6b28df4084f0a81db29f75fb434e75d394c8730
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4169945
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
|
8f1a7190
|
2022-12-23T00:00:00
|
|
Accept clip distance enums for simple queries
State variables for which IsEnabled is listed as
the query command can also be obtained using any
of the simple queries.
Bug: angleproject:4452
Change-Id: I075db600b772e5370c72c0f4de9b35e007259987
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4158331
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
067ace47
|
2022-12-21T00:00:00
|
|
Add ANGLE_clip_cull_distance extension
Added an extension spec.
Trivially exposed it on GL, Vulkan, and D3D11.
Adjusted tests and validation to allow no cull
distance support for this extension string.
Removed extra built-in variable definitions.
Bug: angleproject:7904
Change-Id: Ic60772dfe28132c316eaa29aadc1afd66e3b0fa7
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4114290
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
|
8ee1b89f
|
2022-11-04T13:10:37
|
|
Refactor pixel local storage options
The various different PLS options were getting scattered and unruly. We
are also in need of more backend-specific PLS options that would be
difficult to add as-is. This CL refactors them into a single
"ShPixelLocalStorageOptions" struct that gets initialized all in one
place, and shared between the compiler and the backends.
Bug: angleproject:7279
Change-Id: Ic58dccb8d1ba350a0b6cc5848ce15bd687e30fad
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4006715
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Chris Dalton <chris@rive.app>
|
|
66fda678
|
2022-11-14T11:10:54
|
|
Capture/Replay: Delete buffer after test support for coherent
The buffer created to test coherent and persistzent mapping is
not used later, so it should be deleted.
Since this buffer is created and deleted before any VAO is created,
we also have to check whether a VAO exists before the buffer may
be detached from it.
Bug: angleproject:7814
Change-Id: I875f845e592325093dd90b48ba9cd3c7228fad47
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4023047
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Commit-Queue: Cody Northrop <cnorthrop@google.com>
|
|
|
44d8fef8
|
2022-11-01T00:00:00
|
|
Add ANGLE_provoking_vertex spec
Renamed provoking vertex enums to use _ANGLE suffix.
The newly defined enums alias those from the
desktop OpenGL extensions.
Updated tests to use the new enum names.
Bug: angleproject:2829
Change-Id: I72b686773536d3d54a653114cee5292007510a55
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4013700
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
|
|
|
9bda9a79
|
2022-10-22T22:05:11
|
|
Add Store Ops to pixel local storage
Browsers will need the ability to pre-empt pixel local storage, which
means every plane will need a backing store to dump to. Store Ops allow
the app to still avoid memory transactions at the end of PLS even if
their plane has a backing texture.
Bug: angleproject:7279
Change-Id: I3a3efa21773f87c03cd346a996e3c638028c68ab
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3974652
Commit-Queue: Chris Dalton <chris@rive.app>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
|
|
|
3605b399
|
2022-10-20T17:00:02
|
|
Move PLS clear values back into context state
The API that required packing raw data into a buffer was un-ergonomic
for developers and difficult to implement for WebGL vendors.
Bug: angleproject:7279
Change-Id: If7c98908c285462c5775e8e2d8811883be139f64
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3972376
Commit-Queue: Chris Dalton <chris@rive.app>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
9f693aa3
|
2022-10-22T14:45:59
|
|
Implement an allow list for PLS
In order to guarantee no data is lost while using the
EXT_shader_pixel_local_storage extension, we need to restrict
applications to a small subset of commands while pixel local storage is
active. This CL implements the allow list for GL entrypoints using
wildcard matching inside the code generator, and adds custom validation
for the more specific restrictions that go into effect when PLS is
active.
Bug: angleproject:7279
Change-Id: I5dd48bd93c10e8775f32be32a4fcf17855eb2f0e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3932552
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Chris Dalton <chris@rive.app>
|
|
9b9d8032
|
2022-10-19T14:57:03
|
|
Avoid mExtensions for initializing
mExtensions tracks the currently enabled extensions, while
nativeExtensions tracks which extensions are available on a platform.
This makes nativeExtensions more suitable for initializing data, as
extensions may be disabled at initialization and enabled later.
Bug: angleproject:7769
Change-Id: I9ee821a931045fc89091473f35e2b306ee653613
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3965610
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Commit-Queue: Sean Risser <srisser@google.com>
|
|
|
135022e4
|
2022-10-11T00:03:11
|
|
Vulkan: Create robust pipelines based on context state
Previously, pipelines were made robust based on whether any context in
the share group has so far been made robust. This means that pipelines
created on non-robust contexts would still be compiled as robust.
Inefficiency aside, this was buggy because robustness was not part of
the pipeline cache key, so if a pipeline was created as non-robust
first, then recreated in a robust context, it would reuse the non-robust
variant.
With VK_EXT_pipeline_protected_access, a similar situation arises for
context protected-ness. However, it is incorrect in that case to create
pipelines as protected unnecessarily.
This change makes pipeline robustness a part of the pipeline cache key,
in preparation for protectedness to be added similarly. Compute
programs may now generate multiple pipelines as a result too.
Bug: angleproject:7629
Change-Id: Ie95f10eff878f8c8b221c1018da44385c7aad15e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3943534
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
|
|
|
b5514bb2
|
2022-09-21T20:47:00
|
|
Support pixel local storage on ES 3.0
Now that the application-facing API is implemented, we don't have to
rely on ES 3.1 anymore. Expose and test the extension on ES 3.0.
Bug: angleproject:7279
Change-Id: I5635620b9088201c20bafd283813092a329225d6
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3915327
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Chris Dalton <chris@rive.app>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Chris Dalton <chris@rive.app>
|
|
|
8b2aff28
|
2022-09-12T10:27:28
|
|
Implement the ANGLE_shader_pixel_local_storage API
Implements the OpenGL ES API for ANGLE_shader_pixel_local_storage and
adds thorough validation and testing as outlined in the spec. This
feature is still implemented entirely in the frontend, but the extension
now works end-to-end with a passing test suite, and can be used
externally. Over time we can start gradually moving the implementation
into backends as appropriate.
Bug: angleproject:7279
Bug: angleproject:7647
Change-Id: I1c861a0fca96423be02e17bbe1fb7f57b99ea63f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3886462
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Chris Dalton <chris@rive.app>
|
|
|
2796cbfd
|
2022-09-15T16:18:47
|
|
GLES1: Implement logic op through ANGLE_logic_op
Bug: angleproject:7654
Change-Id: I88c784d87c1cb7cb7e5ccf8f020203553513bbb3
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3899381
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
|
|
|
97926f80
|
2022-09-15T00:10:49
|
|
GL: Implement GL_ANGLE_logic_op
Enabled only on Desktop GL where logic op is available.
Bug: angleproject:7654
Change-Id: I3c17ffb5b21abf31aec247319a625526f1bec37d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3898316
Reviewed-by: Jonah Ryan-Davis <jonahr@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
|
|
|
d375547c
|
2022-08-12T15:54:39
|
|
Do not link program pipeline in glUseProgramStages
1. The commit 3a9f18f135fe82 caused a link to occur everytime
glUseProgramStages is called. This is redundant since the program
pipeline can be linked just before usage, thus allowing for multiple
stages to be bound before linking the executable.
2. Mark PPO as a dirty object and link the PPO in dirty object handler
3. Early return if the same program is being bound to the same stage
of the pipeline.
4. Added ProgramPipelineObjectBenchmark perf test that switches programs
before a draw and observed following data -
1. vulkan profile -
1. wall_time before patch - 102000 ns
2. wall_time after patch - 38000 ns
2. vulkan_null profile -
1. wall_time before patch - 125000 ns
2. wall_time after patch - 52000 ns
Bug: angleproject:5102
Bug: angleproject:6566
Test: ContextNoErrorPPOTest31.*Vulkan
Test: ProgramPipelineTest31.*Vulkan
Test: ProgramPipelineObjectBenchmark*
Change-Id: Idbc2fcb4875bbd040e9ec847eb2a8f96f287173c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3830170
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
c517463a
|
2022-07-28T00:00:00
|
|
Add NoUnclampedBlendColor limitation
Although ES 3.0 and ES 2.0 with floating-point color
buffer extensions must support unclamped constant
blend color, some drivers clamp it anyway.
To let applications know the effective behavior, ANGLE
state management has been expanded to simulate what
the OpenGL ES driver is doing.
So far, this bug has been confirmed only on Adreno GPUs.
Unconditionally enabled this limitation on D3D9 as it
cannot support unclamped blend color by design.
Bug: angleproject:7536
Change-Id: I7e28a5553e79669d8482d48c6e79bdd811971ade
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3791350
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
|
925ec6b5
|
2022-07-07T00:00:00
|
|
Clamp viewport dimensions on store
Bug: angleproject:7486
Bug: chromium:1130759
Change-Id: I6131baacc940b5df7e33ba10fca8e6e148cb8670
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3751056
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
|
785353fd
|
2022-05-24T12:40:16
|
|
Support Desktop OpenGL context creation in end2end tests
Validation of Desktop GL versions and profile masks is unimplemented.
Bug: angleproject:7360
Change-Id: Ifae94215b6aada895c2b02318a1d05c9515e9b96
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3664916
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
|
|
|
b186991a
|
2022-05-26T11:50:56
|
|
Vulkan: Remove non-current vertex array from buffer's observer list
When app binds a buffer to many VAOs, any buffer modification have to
loop over all VAOs that uses that buffer, even though all these VAOs are
not current except one VAO. That causes significant CPU overhead.
black_desert_mobile has this type of usage. This CL checks number of
observers on each binding and if there are excessive observers, it
removes VAO from the buffer's observer list when it becomes non-current
and adds back to observer list when it becomes current.
This CL reduces CPU overhead of black_desert_mobile (as measured with
--offset --minimumgpuwork) from 21ms to 3.69ms, on par with native GLES
driver. Note that this CL only touches glBindVertexArrayObject call code
path, so no impact to apps not using VAOs. There is also no measurable
CPU time regression on a few other app traces that uses VAOs.
Bug: angleproject:6371
Change-Id: I6b1589f3e3c768d56c1c95cebdb577e3e256737f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3669603
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Charlie Lao <cclao@google.com>
|
|
|
84a0b462
|
2022-05-20T15:51:11
|
|
Vulkan: Bug fix in GL_QCOM_shading_rate
A default value of _1x1 for mShadingRate interacts badly with sample
shading state on some vendors. Instead set the default to Undefined
and return early in such cases.
Bug: angleproject:7172
Change-Id: If0a280090e6611817d2f5d75929ef2b654ddb186
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3658245
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
2fdd7bfd
|
2022-05-17T13:31:58
|
|
Vulkan: Support binding 2D slice of a 3D texture to an image unit
Support binding a 3d texture as a 2d texture by specifying that it is
non-layered during glBindImageTexture and expose support for
EGL_KHR_gl_texture_3D_image when VK_EXT_image_2d_view_of_3d vulkan
extension is supported.
Tests: ComputeShaderTest.BindImageTexture3D
dEQP-GLES31.functional.image_load_store.3d.*single_layer
Bug: angleproject:7320
Change-Id: Ie2f0dfcdf302a4aa58990f74329ca36e62cd3902
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3648586
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
|
|
|
02b96848
|
2022-04-21T16:32:31
|
|
Vulkan: Add support for GL_QCOM_shading_rate
Layer GL_QCOM_shading_rate over VK_KHR_fragment_shading_rate
Test: ShadingRateQcomTest*
Bug: angleproject:7172
Change-Id: I3f040dbfad3906facd4349937fed2ce9a464b824
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3599874
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: mohan maiya <m.maiya@samsung.com>
|
|
|
62ca6449
|
2022-04-13T09:36:40
|
|
Reland "Fix BlendStateExt::mMaxColorMask initialization"
This is a reland of commit 50d008a7efcab80f34eb742148d05389b2ed247e
Besides fixing the BlendStateExt color mask initialization bug,
the following changes were made:
* All fields were made private with accessor functions.
* A new assertion was added that ensures 64-bit storage for factors
and equations. This allowed dropping one redundant mask.
* Two new helper functions were added.
* BlendStateExt::mMaxDrawBuffers was renamed to mDrawBufferCount.
* The BlendStateExt class is now aligned to 8 bytes with an assertion.
* Expanded test coverage.
Also fixed incorrect usage of BlendStateExt fields in:
* StateManagerGL::syncBlendFromNativeContext
* StateManagerGL::restoreBlendNativeContext
Original change's description:
> Fix BlendStateExt::mMaxColorMask initialization
>
> This variable should not have its unused bits set.
>
> To avoid confusion with other masks of the same class,
> the variable was renamed to mAllColorMask.
>
> Bug: angleproject:7200
> Change-Id: I72542d49ff8da3dbb8d61c5034ce37c1e8fcc6e1
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3581990
> Reviewed-by: Jamie Madill <jmadill@chromium.org>
> Reviewed-by: Geoff Lang <geofflang@chromium.org>
> Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Bug: angleproject:7200
Change-Id: I87a5fe0f9dfbbf5e525b9120f772aa9adb39ce5f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3593234
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|
|
4efc4ee6
|
2022-04-19T17:01:20
|
|
Fix validate state cache after XFB buffer deleted.
Bug: chromium:1317650
Change-Id: Iec9f1167c3b2957091dd0f4ef3efcfcd7c4bf3c0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3594250
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Jamie Madill <jmadill@chromium.org>
|
|
|
f4fc8e16
|
2022-04-20T04:32:48
|
|
Revert "Fix BlendStateExt::mMaxColorMask initialization"
This reverts commit 50d008a7efcab80f34eb742148d05389b2ed247e.
Reason for revert: Causes the win-trace bot to fail
Original change's description:
> Fix BlendStateExt::mMaxColorMask initialization
>
> This variable should not have its unused bits set.
>
> To avoid confusion with other masks of the same class,
> the variable was renamed to mAllColorMask.
>
> Bug: angleproject:7200
> Change-Id: I72542d49ff8da3dbb8d61c5034ce37c1e8fcc6e1
> Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3581990
> Reviewed-by: Jamie Madill <jmadill@chromium.org>
> Reviewed-by: Geoff Lang <geofflang@chromium.org>
> Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Bug: angleproject:7200
Change-Id: Ib9a0927ba4e152d5b4ae4c034e6748faf6b5aa87
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3594802
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
50d008a7
|
2022-04-13T09:36:40
|
|
Fix BlendStateExt::mMaxColorMask initialization
This variable should not have its unused bits set.
To avoid confusion with other masks of the same class,
the variable was renamed to mAllColorMask.
Bug: angleproject:7200
Change-Id: I72542d49ff8da3dbb8d61c5034ce37c1e8fcc6e1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3581990
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
|