|
49317d73
|
2024-05-10T16:11:59
|
|
Prepare resource map for being potentially thread-safe
Resource maps are used for both shared and context-private resources.
Context-private resource maps do not need any locking. Once glBind* and
similar commands are made free of the share group lock, the resource map
of the corresponding type must be made thread safe, especially for look
up.
This change adds the ability to the resource map to be either thread
safe or not, based on the type of the resource it contains. Currently,
only a test type (unsigned int) is thread safe (used in unit tests).
This is achieved by a combination of the following:
- For resource maps that need a lock, the flat part of the map has an
initially reasonable size, but is _never_ reallocated. This makes
access to that part of the map lockfree.
- The hash-map that contains large ids is always protected by a mutex.
Follow up changes will start enabling thread-safety for resources as
their corresponding glBind command is made lockless.
Bug: angleproject:8667
Change-Id: Ia4ffffee41f021d833d31f296bc883bf12f1135f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5527771
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
00fa9af9
|
2024-04-18T10:55:34
|
|
Disable the BasicNoOpMutex test
It's flaky by nature, and the flake rate turned out to be much higher
than anticipated (i.e. it cannot be ignored).
Bug: b/335541479
Change-Id: Ic29c549aa761230e1d8aa8156c66e78aae939e53
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5463920
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Roman Lavrov <romanl@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
d9d583bf
|
2024-04-15T00:24:47
|
|
Implement a lock/unlock-only mutex based on futex
Pthread mutexes are expensive due to their numerous features. When a
mutex only needs to support lock and unlock, its implementation can be
much simpler. The implementation in this change is "inspired" by a
similar mutex in mesa.
Expected uses of this mutex are:
- Allowing some OpenGL calls to avoid the share group lock and instead
lock the specific shared object they operate on.
- Replacing SpinLock in the OpenCL implementation (spin-lock in user
space is a bad idea [1])
- Generally anywhere we use std::mutex just to do lock/unlock
Tests based on patch authored by Igor Nazarov <i.nazarov@samsung.com>
[1]:https://www.realworldtech.com/forum/?threadid=189711&curpostid=189723
Bug: angleproject:8667
Change-Id: I52278c9d19616338c499bbcef6684746caead6ca
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5446558
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|