| Age | Commit message (Collapse) | Author |
|---|
|
speed matters. (#64)
This commit adds the HBXX64 and HBXX128 classes for use as a drop-in
replacement for the slow LLMD5 hashing class, where speed matters and
backward compatibility (with standard hashing algorithms) and/or
cryptographic hashing qualities are not required.
It also replaces LLMD5 with HBXX* in a few existing hot (well, ok, just
"warm" for some) paths meeting the above requirements, while paving the way for
future use cases, such as in the DRTVWR-559 and sibling branches where the slow
LLMD5 is used (e.g. to hash materials and vertex buffer cache entries), and
could be use such a (way) faster algorithm with very significant benefits and
no negative impact.
Here is the comment I added in indra/llcommon/hbxx.h:
// HBXXH* classes are to be used where speed matters and cryptographic quality
// is not required (no "one-way" guarantee, though they are likely not worst in
// this respect than MD5 which got busted and is now considered too weak). The
// xxHash code they are built upon is vectorized and about 50 times faster than
// MD5. A 64 bits hash class is also provided for when 128 bits of entropy are
// not needed. The hashes collision rate is similar to MD5's.
// See https://github.com/Cyan4973/xxHash#readme for details.
|
|
|
|
For work queues that don't need timestamped tasks, eliminate the overhead of a
priority queue ordered by timestamp. Timestamped task support moves to
WorkSchedule. WorkQueue is a simpler queue that just waits for work.
Both WorkQueue and WorkSchedule can be accessed via new WorkQueueBase API. Of
course the WorkQueueBase API doesn't deal with timestamps, but a WorkSchedule
can be accessed directly to post timestamped tasks and then handled normally
(e.g. by ThreadPool) to run them.
Most ThreadPool functionality migrates to new ThreadPoolBase class, with
template subclass ThreadPoolUsing<WorkQueue> or ThreadPoolUsing<WorkSchedule>
depending on need. ThreadPool is now an alias for ThreadPoolUsing<WorkQueue>.
Importantly, ThreadPoolUsing::getQueue() delivers a reference to the specific
queue subclass type, so you can post timestamped tasks on a queue retrieved
from ThreadPoolUsing<WorkSchedule>::getQueue().
Since ThreadPool is no longer a simple class but an alias for a particular
template specialization, introduce threadpool_fwd.h to forward-declare it.
Recast workqueue_test.cpp to exercise WorkSchedule, since some of the tests
are time-based. A future todo would be to exercise each applicable test with
both WorkQueue and WorkSchedule.
|
|
Deriving your tracked class T from LLInstanceTracker<T> gives you
T::getInstance() et al. But what about a subclass S derived from T?
S::getInstance() still delivers a pointer to T, requiring explicit downcast.
And so on for other LLInstanceTracker methods.
Instead, derive S from LLInstanceTrackerSubclass<S, T>. This implies that S is
a grandchild class of T, but it also recasts the LLInstanceTracker methods to
deliver results for S rather than for T.
|
|
# Conflicts:
# indra/llrender/llgl.cpp
# indra/llrender/llrendertarget.cpp
# indra/newview/VIEWER_VERSION.txt
# indra/newview/app_settings/shaders/class1/deferred/materialF.glsl
# indra/newview/llfloaterpreference.cpp
# indra/newview/llviewercontrol.cpp
# indra/newview/llviewermenu.cpp
# indra/newview/llviewertexturelist.cpp
# indra/newview/llvovolume.cpp
|
|
|
|
|
|
According to bugsplat get_thread_recorder was null
Replaced apr based LLThreadLocalPointer with thread_local
|
|
# Conflicts:
# doc/contributions.txt
# indra/newview/llviewercontrol.cpp
|
|
|
|
Introduce CommonControl, which in a running viewer (or any program containing
an LLViewerControlListener instance) gives access to LLViewerControl
functionality, e.g. getting, setting or enumerating control variables --
without introducing a link dependency on newview.
Make ThreadPool's constructor consult CommonControl to check for an override
for the width of the new ThreadPool in the Global (i.e. gSavedSettings)
setting ThreadPoolSizes, and honor that if found.
Introduce static ThreadPool methods getConfiguredWidth(), to query for such an
override on any particular ThreadPool name; and getWidth(), to ask for the
width of an instance if that instance already exists, else the width with
which it *would* be instantiated.
|
|
# Conflicts:
# autobuild.xml
# indra/cmake/LLCommon.cmake
# indra/llcommon/CMakeLists.txt
# indra/llrender/llgl.cpp
# indra/newview/llappviewer.cpp
# indra/newview/llface.cpp
# indra/newview/llflexibleobject.cpp
# indra/newview/llvovolume.cpp
|
|
|
|
Reverting a merge is sticky: it tells git you never want to see that branch
again. Merging the DRTVWR-546 branch, which contained the revert, into the
glthread branch undid much of the development work on that branch. To restore
it we must revert the revert.
This reverts commit 029b41c0419e975bbb28454538b46dc69ce5d2ba.
|
|
# Conflicts:
# indra/newview/llagentwearables.cpp
# indra/newview/llvoicevivox.cpp
|
|
|
|
This reverts commit 5188a26a8521251dda07ac0140bb129f28417e49, reversing
changes made to 819088563e13f1d75e048311fbaf0df4a79b7e19.
|
|
|
|
ThreadPool bundles a WorkQueue with the specified number of worker threads to
service it. Each ThreadPool has a name that can be used to locate its
WorkQueue.
Each worker thread calls WorkQueue::runUntilClose().
ThreadPool listens on the "LLApp" LLEventPump for shutdown notification. On
receiving that, it closes its WorkQueue and then join()s each of its worker
threads for orderly shutdown.
Add a settings.xml entry "ThreadPoolSizes", the first LLSD-valued settings
entry to expect a map: pool name->size. The expectation is that usually code
instantiating a particular ThreadPool will have a default size in mind, but it
should check "ThreadPoolSizes" for a user override.
Make idle_startup()'s STATE_SEED_CAP_GRANTED state instantiate a "General"
ThreadPool. This is function-static for lazy initialization.
Eliminate LLMainLoopRepeater, which is completely unreferenced. Any potential
future use cases are better addressed by posting to the main loop's WorkQueue.
Eliminate llappviewer.cpp's private LLDeferredTaskList class, which
implemented LLAppViewer::addOnIdleCallback(). Make addOnIdleCallback() post
work to the main loop's WorkQueue instead.
|
|
|
|
|
|
A typical WorkQueue has a string name, which can be used to find it to post
work to it. "Work" is a nullary callable.
WorkQueue is a multi-producer, multi-consumer thread-safe queue: multiple
threads can service the WorkQueue, multiple threads can post work to it.
Work can be scheduled in the future by submitting with a timestamp. In
addition, a given work item can be scheduled to run on a recurring basis.
A requesting thread servicing a WorkQueue of its own, such as the viewer's
main thread, can submit work to another WorkQueue along with a callback to be
passed the result (of arbitrary type) of the first work item. The callback is
posted to the originating WorkQueue, permitting safe data exchange between
participating threads.
Methods are provided for different kinds of servicing threads. runUntilClose()
is useful for a simple worker thread. runFor(duration) devotes no more than a
specified time slice to that WorkQueue, e.g. for use by the main thread.
|
|
ThreadSafeSchedule orders its items by timestamp, which can be passed either
implicitly or explicitly. The timestamp specifies earliest delivery time: an
item cannot be popped until that time.
Add initial tests.
Tweak the LLThreadSafeQueue base class to support ThreadSafeSchedule:
introduce virtual canPop() method to report whether the current head item is
available to pop. The base class unconditionally says yes, ThreadSafeSchedule
says it depends on whether its timestamp is still in the future.
This replaces the protected pop_() overload accepting a predicate. Rather than
explicitly passing a predicate through a couple levels of function call, use
canPop() at the level it matters. Runtime behavior that varies depending on
an object's leaf class is what virtual functions were invented for.
Give pop_() a three-state enum return so pop() can distinguish between "closed
and empty" (throws exception) versus "closed, not yet drained because we're
not yet ready to pop the head item" (waits).
Also break out protected tryPopUntil_() method, the body logic of
tryPopUntil(). The public method locks the data structure, the protected
method requires that its caller has already done so.
Add chrono.h with a more full-featured LL::time_point_cast() function than the
one found in <chrono>, which only converts between time_point durations, not
between time_points based on different clocks.
|
|
These functions allow prepending or removing an item at the left end of an
arbitrary tuple -- for instance, to add a sequence key to a caller's data,
then remove it again when delivering the original tuple.
|
|
|
|
|
|
|
|
# Conflicts:
# autobuild.xml
# indra/CMakeLists.txt
# indra/newview/CMakeLists.txt
# indra/newview/llappviewerwin32.h
# indra/win_crash_logger/llcrashloggerwindows.cpp
Cherry picked from DRTVWR-520
|
|
to tracy.lib
|
|
|
|
|
|
# Conflicts:
# autobuild.xml
# build.sh
# indra/CMakeLists.txt
# indra/newview/CMakeLists.txt
# indra/newview/llappviewermacosx.cpp
# indra/newview/llappviewerwin32.h
# indra/newview/viewer_manifest.py
# indra/win_crash_logger/llcrashloggerwindows.cpp
|
|
# Conflicts:
# doc/contributions.txt
# indra/newview/llappcorehttp.cpp
# indra/newview/llappcorehttp.h
|
|
Bring in Oz's tweaks to the way BugSplat is engaged and tested, plus a few
other miscellaneous goodies.
|
|
# Conflicts:
# indra/newview/lltoolpie.cpp
|
|
# Conflicts:
# autobuild.xml
|
|
|
|
|
|
|
|
|
|
|
|
Now that we have the Sync class to help construct unit tests that move forward
in a deterministic stepwise order, we can build suitable unit tests for
LLMainThreadTask.
|
|
|
|
The only usage of any of this was in test code.
|
|
|
|
Longtime fans will remember that the "dcoroutine" library is a Google Summer
of Code project by Giovanni P. Deretta. He originally called it
"Boost.Coroutine," and we originally added it to our 3p-boost autobuild
package as such. But when the official Boost.Coroutine library came along
(with a very different API), and we still needed the API of the GSoC project,
we renamed the unofficial one "dcoroutine" to allow coexistence.
The "dcoroutine" library had an internal low-level API more or less analogous
to Boost.Context. We later introduced an implementation of that internal API
based on Boost.Context, a step towards eliminating the GSoC code in favor of
official, supported Boost code.
However, recent versions of Boost.Context no longer support the API on which
we built the shim for "dcoroutine." We started down the path of reimplementing
that shim using the current Boost.Context API -- then realized that it's time
to bite the bullet and replace the "dcoroutine" API with the Boost.Fiber API,
which we've been itching to do for literally years now.
Naturally, most of the heavy lifting is in llcoros.{h,cpp} and
lleventcoro.{h,cpp} -- which is good: the LLCoros layer abstracts away most of
the differences between "dcoroutine" and Boost.Fiber.
The one feature Boost.Fiber does not provide is the ability to forcibly
terminate some other fiber. Accordingly, disable LLCoros::kill() and
LLCoprocedureManager::shutdown(). The only known shutdown() call was in
LLCoprocedurePool's destructor.
We also took the opportunity to remove postAndSuspend2() and its associated
machinery: FutureListener2, LLErrorEvent, errorException(), errorLog(),
LLCoroEventPumps. All that dual-LLEventPump stuff was introduced at a time
when the Responder pattern was king, and we assumed we'd want to listen on one
LLEventPump with the success handler and on another with the error handler. We
have never actually used that in practice. Remove associated tests, of course.
There is one other semantic difference that necessitates patching a number of
tests: with "dcoroutine," fulfilling a future IMMEDIATELY resumes the waiting
coroutine. With Boost.Fiber, fulfilling a future merely marks the fiber as
ready to resume next time the scheduler gets around to it. To observe the test
side effects, we've inserted a number of llcoro::suspend() calls -- also in
the main loop.
For a long time we retained a single unit test exercising the raw "dcoroutine"
API. Remove that.
Eliminate llcoro_get_id.{h,cpp}, which provided llcoro::get_id(), which was a
hack to emulate fiber-local variables. Since Boost.Fiber has an actual API for
that, remove the hack.
In fact, use (new alias) LLCoros::local_ptr for LLSingleton's dependency
tracking in place of llcoro::get_id().
In CMake land, replace BOOST_COROUTINE_LIBRARY with BOOST_FIBER_LIBRARY. We
don't actually use the Boost.Coroutine for anything (though there exist
plausible use cases).
|
|
If already running on the main thread, LLMaintThreadTask simply runs the work
inline. Otherwise it queues it for the main thread using LLEventTimer, using
std::future to retrieve the result.
|
|
The pattern of requiring a lock to permit *any* access to a static instance of
something seems generally useful. Break out lockstatic.h; recast
LLInstanceTracker to use it.
Moving LockStatic to an external template class instead of a nested class in
LLInstanceTrackerBase leaves LLInstanceTrackerBase pretty empty. Get rid of it.
And *that* means we can move the definition of the StaticData used by each
LLInstanceTracker specialization into the class itself, rather than having to
define it beforehand in namespace LLInstanceTrackerStuff.
|
|
|
|
|
