src/libANGLE/BlendStateExt_unittest.cpp


Log

Author Commit Date CI Message
Charlie Lao 2269011c 2025-06-30T14:08:11 Remove BitSet::to_ulong and BitSetArray::to_ulong BitSet::to_ulong() is a bit redundant with bits(), and has a risk of losing upper bits on windows platform where unsigned long is 32 bit. This CL removes the usage of it and replaced with bits(). BitSetArray::to_ulong() method only captures up to 64 bits, all other bits are dropped silently which is wrong. This CL fix this and serialize it as a vector of uint64_t. BitSetArray::to_ulong() is removed in this CL. Bug: angleproject:42264163 Change-Id: I663b2cdacc0e930ee616e333131e831ec124a9d4 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6691283 Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Cody Northrop <cnorthrop@google.com> Commit-Queue: Charlie Lao <cclao@google.com>
Roman Lavrov 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>
Alexey Knyazev 8b0af482 2023-08-21T00:00:00 Validate active draw buffers for dual-source blending Fail if more than MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT draw buffers are enabled when dual-source blending is used. Drive-by: Do not invalidate draw state on changing blend equations if KHR_blend_equation_advanced is not enabled. Bug: angleproject:1085 Bug: angleproject:7177 Change-Id: Ieff80ce777c53b1d8183e1d0a52b7d2224347448 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4823164 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Alexey Knyazev <lexa.knyazev@gmail.com>
Shahbaz Youssefi 1328f2f3 2023-04-17T16:43:12 Vulkan: Destroy the surface without holding the EGL lock This change defers surface destruction to the end of the entry point that causes it so that it is done without holding the EGL lock. This works around a specific deadlock in Android. On this platform: - For EGL applications, parts of surface creation and destruction are handled by the platform, and parts of it are done by the native EGL driver. Namely, on surface destruction, native_window_api_disconnect is called outside the EGL driver. - For Vulkan applications, vkDestroySurfaceKHR takes full responsibility for destroying the surface, including calling native_window_api_disconnect. Unfortunately, native_window_api_disconnect may use EGL sync objects and can lead to calling into the EGL driver. For ANGLE, this is particularly problematic because it is simultaneously a Vulkan application and the EGL driver, causing `vkDestroySurfaceKHR` to call back into ANGLE and attempt to reacquire the EGL lock. Since there are no users of the surface when calling vkDestroySurfaceKHR, it is safe for ANGLE to destroy it without holding the EGL lock. Note that only eglDestroySurface and eglMakeCurrent may lead to the destruction of a window surface. Bug: b/275176234 Bug: angleproject:8127 Change-Id: I02dc52e53e150943457e3f503e7ef30469f96b05 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4428754 Reviewed-by: Charlie Lao <cclao@google.com> Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>