| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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.
|
|
|
|
The unsigned index arithmetic was problematic in that case.
|
|
|
|
Since LLSDSerialize::SIZE_UNLIMITED is negative, passing that through unsigned
size_t parameters could result in peculiar behavior.
|
|
and use it to replace dubious loops in asLLSD() and trimEmpty().
|
|
|
|
Close stale PRs
|
|
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
|
|
Update message template URL after move to GitHub
|
|
|
|
|
|
Various repo fixes
|
|
|
|
Add automatic PR labels
|
|
Add CLA bot
|
|
after 7 days.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Introduce LLSD template constructors and assignment operators to disambiguate
construction or assignment from any integer type to Integer, likewise any
floating point type to Real. Use new narrow() function to validate
conversions.
For LLSD method parameters converted from LLSD::Integer to size_t, where the
method previously checked for a negative argument, make it now check for
size_t converted from negative: in other words, more than S32_MAX. The risk of
having a parameter forced from negative to unsigned exceeds the risk of a
valid length or index over that max.
In lltracerecording.cpp's PeriodicRecording, now that mCurPeriod and
mNumRecordedPeriods are size_t instead of S32, defend against subtracting 1
from 0.
Use narrow() to validate newly-introduced narrowing conversions.
Make llclamp() return the type of the raw input value, even if the types of
the boundary values differ.
std::ostream::tellp() no longer returns a value we can directly report as a
number. Cast to U64.
|
|
|
|
size_t changes in base class
|
|
size_t conversions
|
|
conversions
|
|
llssize is for a function parameter that should accept a size or index
(derived from size_t, which is 64 bits in a 64-bit viewer) but might need to
go negative for flag values. We've historically used S32 for that purpose, but
Xcode 14.1 complains about trying to pass size_t to S32.
narrow() is a template function that casts a wider type (e.g. size_t or
llssize) to a narrower type (e.g. S32 or U32), with validation in
RelWithDebInfo builds. It verifies (using assert()) that the value being
truncated can in fact fit into the target type.
|
|
|
|
|
|
It's a little distressing how often we have historically coded S32 or U32 to
pass a length or index.
There are more such assumptions in other viewer subdirectories, but this is a
start.
|
|
Or rather, attempting to implicitly sign. On TeamCity we must explicitly sign
using viewer_manifest.py. On a developer system, without these changes, Xcode
produces many errors of the form:
error: An empty identity is not valid when signing a binary for the product
type 'Command-line Tool'. (in target 'INTEGRATION_TEST_lldir' from project
'SecondLife')
and refuses to compile anything at all.
Thanks to Rye Mutt and NickyD. Also thanks Geir Nøklebye for additional
settings to help tame Xcode 14.1 warnings.
|
|
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.
|
|
|
|
|
|
|
|
|
