| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
translations (#80)
|
|
changes in /en/ (#78)
|
|
Faster and simpler inventory category hashing.
|
|
As suggested in comments for previous commit.
|
|
keys (#70)
LLUUID and LLMaterialID already have an excellent entropy and value dispersion; there is therefore strictly no need to further (slowly) hash their value for use with std and boost libraries containers.
This commit adds a trivial getDigest64() method to both LLUUID and LLMaterialID (which simply returns the XOR of the two 64 bits long words their value is made of), and uses it in std::hash and hash_value() specializations for use with containers.
|
|
This commit changes inventory category hashing from slow LLMD5 to fast HBXX128 hashing, and allows to use a simple LLUUID for the hash, instead of an LLMD5 instance.
It also removes some old cruft dealing with unused baked texture hashing.
|
|
The viewer currently presents a startling "Grid emergency" warning if an
unrecognized error is returned from login. Let's tone this down a bit
and present the error as it is: an unrecognized login failure rather
than SLearth exploding.
|
|
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.
|
|
|
|
|
|
Viewer doesn't support web downloads, it should be safe to assume stream and play it
|
|
|
|
Polish directory; Fix localizability in various English XMLs
|
|
|
|
|
|
density_ctrl.xml file
|
|
|
|
Fix failures to update the TP states while the viewer is minimized.
|
|
|
|
following promotion of DRTVWR-565
|
|
|
|
|
|
|
|
SL-14399: Ditch overflow queue LLViewerAssetStorage::mCoroWaitList.
|
|
mCoroWaitList covers all assets not just landmarks
|
|
mCoroWaitList was introduced to prevent an assertion failure crash:
LLCoprocedureManager never expects to fill LLCoprocedurePool::mPendingCoprocs
queue. The queue limit was arbitrarily set to 4096 some years ago, but in
practice LLViewerAssetStorage can post way more requests than that.
LLViewerAssetStorage checked whether the target LLCoprocedureManager pool's
queue looked close to full, and if so posted the pending request to its
mCoroWaitList instead. But then it had to override the base LLAssetStorage
method checkForTimeouts() to continually check whether pending tasks could be
moved from mCoroWaitList to LLCoprocedureManager.
A simpler solution is to enlarge LLCorpocedureManager::DEFAULT_QUEUE_SIZE, the
upper limit on mPendingCoprocs. Since mCoroWaitList was an unlimited queue,
making DEFAULT_QUEUE_SIZE "very large" does not increase the risk of runaway
memory consumption.
|
|
This is a fix for: https://jira.secondlife.com/browse/BUG-230616
|
|
|
|
Cleaner reinit and termination.
|
|
LLViewerTexture::mNeedsCreateTexture needs to be an attomic bool since
it is written both in the main thread and in the GL image worker thread.
We can now enable threaded bump maps creation as a result of this fix.
I have read the CLA Document and I hereby sign the CLA
|
|
|
|
|
|
original fix by Beq Janus
|
|
size_t changes in base class
|
|
|
|
Due to udp texture fetching no longer being present
|
|
|
|
|
|
following promotion of DRTVWR-575
|
|
both reasons at the same time
|
|
|
|
following promotion of DRTVWR-574
|
|
|
|
|
|
following promotion of DRTVWR-548
|
|
|
|
Since the performance overhaul project, there should be essentially no difference between rigged meshes and non-rigged as far as vertex buffer management is concerned.
|
|
|
