| Age | Commit message (Collapse) | Author |
|---|
|
|
|
# Conflicts:
# indra/cmake/Copy3rdPartyLibs.cmake
# indra/cmake/FindOpenJPEG.cmake
# indra/cmake/OpenJPEG.cmake
# indra/integration_tests/llui_libtest/CMakeLists.txt
# indra/newview/CMakeLists.txt
|
|
|
|
DRTVWR-559
|
|
implementations must not change, but may add "fast" variants where appropriate in the future.
|
|
As it happens, the change in the LLUUID::combine() algorithm introduced by one
of my previous commits is causing invalid assets creation (seen with
some clothing items, such as Shape and Universal types); obviously, the server
is using the old algorithm for UUID validation purpose of these assets.
This commit reverts LLUUID::combine() code to use LLMD5.
|
|
|
|
|
|
|
|
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.
|
|
|
|
# Conflicts:
# autobuild.xml
# indra/newview/llagent.cpp
# indra/newview/llimview.cpp
# indra/newview/llimview.h
# indra/newview/llinventoryfunctions.cpp
# indra/newview/llpanelmediasettingsgeneral.cpp
# indra/newview/pipeline.cpp
|
|
|
|
Apparently Visual Studio and Xcode disagree on the intended lifespan of a
certain temporary expression. Capturing it in a named variable works.
|
|
|
|
|
|
# Conflicts:
# doc/contributions.txt
# indra/newview/app_settings/shaders/class1/deferred/materialF.glsl
# indra/newview/llfloater360capture.cpp
|
|
|
|
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.
|
|
|
|
Co-authored-by: Nat Goodspeed <nat@lindenlab.com>
|
|
Looks like pollTick tried to call an already dead process
|
|
reduce CPU usage of background threads.
|
|
abilities and remove some more fast timers.
|
|
|
|
DRTVWR-570-maint-Q
|
|
creating an empty LLSDMap type.
|
|
|
|
|
|
|
|
|
|
In theory it is fine to do that, in practice it does break gatekeeper in subtle ways
due to https://developer.apple.com/library/archive/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG207
Having bugsplat linked to all executables results in executables with an embedded rpath that is invalid for Gatekeeper. Luckily
it shows this is in the worst possible way. The viewer cannot be started with a non helpful message of teh viewer being unable to
verified. While at the same time spctl and codesign both show no errors at all.
|
|
# 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
|
|
# Conflicts:
# indra/newview/llnetmap.cpp
# indra/newview/llnetmap.h
|
|
|
|
|
|
This partially reverts commit 935c1362a222f192bf913270d01f6c31c16e175b.
Reporting seems to have stoped working, trying the same way mac works.
|
|
This still needs some work - I'm not super satisfied with the overall structure of the code. Will continue to iterate as I add in proper RenderDoc support.
|
|
Restore SSAO to release version.
|
|
|
|
|
|
|
|
DRTVWR-568_cmake
|
|
# Conflicts:
# indra/newview/llpanelface.cpp
# indra/newview/llpanelface.h
|
|
|
|
|
|
# Conflicts:
# indra/newview/llmodelpreview.h
|
|
|
|
picking support TBD.
|
