| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
QA found no difference performance wise, I see a decrease in performance.
|
|
|
|
|
|
|
|
Crash happens inside generateRemapMultiwith, no clear cause. Ideally we need the crashing model, but untill that, zero-initing remap. meshopt wants zero initialized paddings and since we are providing more space than nessesary, that might count as padding.
|
|
|
|
|
|
vertexBatchPreTransformed()
|
|
This allows removing #include "llerror.h" from llpointer.h.
Also remove #include "llmutex.h" as a heavy way to get
<boost/functional/hash.hpp>.
That requires adding #include "llmutex.h" to llimage.h, llnotifications.h,
llwatchdog.cpp and llvolumemgr.cpp, which were inheriting it from llpointer.h.
|
|
Signed-off-by: Rye <rye@alchemyviewer.org>
|
|
Clean up dead macos files
Clean up dead windows build files
Signed-off-by: Rye <rye@alchemyviewer.org>
|
|
|
|
# Conflicts:
# indra/llcommon/llprocessor.cpp
# indra/llcorehttp/_refcounted.h
# indra/llcorehttp/_thread.h
# indra/newview/llfeaturemanager.cpp
# indra/newview/llviewershadermgr.cpp
|
|
deleted operator and constructor
|
|
issues reported by ubsan/asan
Signed-off-by: Rye <rye@alchemyviewer.org>
|
|
Signed-off-by: Rye <rye@alchemyviewer.org>
|
|
Signed-off-by: Rye <rye@alchemyviewer.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Conflicts:
# indra/newview/llvoavatar.cpp
|
|
|
|
|
|
|
|
LLQuad is a typedef of __m128, which is already translated by
sse2neon to float32x4_t (I thought sse2neon wasn't taking effect
and I tried just replacing __m128 with float32x4_t to see that it
didn't make a difference), but then I searched using the keyword
float32x4_t this time and found that others have had a similar
problem:
https://developercommunity.visualstudio.com/t/static-initialization-arm64-neon-datatypes/1238406
https://stackoverflow.com/questions/54016821/error-c2078-when-initializing-uint32x4-t-on-arm
https://github.com/kcat/openal-soft/issues/494
Looking at the type definition, on arm64 it can be initialised
using a designator, the member with the float type and 4 array
elements.
I know it's an MSVC (arm64) problem, but since MSVC is also used
on x64 and only Windows arm64 is suffering from this one in our
case anyway (we only support Windows arm64 building using MSVC so
far), it's just simpler to use the _M_ARM64 preprocessor instead
of _MSC_VER.
|
|
|
|
|
|
I happen to be using just Git Bash for convenience for running the
commands on the Windows build instructions, hence the build folder
pattern to be ignored from the result of running `uname -s` there.
The instructions omit the part where you install vcpkg and set the
VCPKG_ROOT environment variable, cause it depends on where you install
vcpkg to your liking, but the next commands will rely on that variable
being set correctly.
The CMake used here is MS VS 2022 Community Edition's one, since it will
know where the C++ compiler is.
$VCPKG_ROOT/downloads/tools/msys2/21caed2f81ec917b/mingw64/bin is where
pkg-config.exe can be found.
$VCPKG_ROOT/installed/`uname -m|sed 's/86_//'`-windows/tools/libxml2 is
where xmllint.exe can be found (from libxml2[tools]).
PKG_CONFIG_LIBDIR and PYTHON environment settings are pretty
self-explanatory.
The flags set on LL_BUILD are now for Visual C++ and not MinGW(64)'s GCC
or Clang any more, and copied from most of the flags in the variables
file from LL's build-variables repo.
vcpkg's apr & apr-util packages don't seem to install their .pc files,
hence the manual target_include/link_directories/libraries settings,
relying on some automatically generated INTERNAL CMake variable called
prefix_result. vcpkg's Boost needs the same treatment, plus some suffix.
We still use LL's prebuilt libs for OpenSSL, libcurl and WebRTC.
Actually too for ColladaDOM for now, but we prepare Windows ColladaDOM
self-building for later.
For GLM and Meshoptimizer too, it's just the checking that's skipped
otherwise it would fail (but the vcpkg packages can be used).
Visual C++ doesn't recognise the no-deprecated-declarations compile
option.
On Visual C++, the macro to denote x86-64 seems to be _M_X64 (if not
added there, it would try to find sse2neon :))
We still aren't using Autobuild here for Windows either, hence the
FALSE-d viewer_manifest.py based file bundling.
|
|
|
|
but the fact that we keep on using as many system libraries as we
can (and only resort to other sources in certain cases), hasn't
changed, of course.
Also stop having to set USE_AUTOBUILD_3P to OFF.
Lines are reindented, and when a system library can be found for
a dependency, then that should be the way. If later we find out
that using some other way is better, than stick to that. So, one
option at a time, whichever is best for the situation.
GLEXT hasn't been used, and in order to be not having to hack its
.cmake file, we bypass it and refer to GLH (which is still used)
right away in LLWindow.
CMake commands that need to be bypassed, if it's a one-liner then
it's just commented out, but if it's multiple lines, then scope
them with if (FALSE) to minimise difference.
|
|
Pretty much similar to the previous commit (especially that the
the encapsulating directory, in cases where LL's prebuilt is used,
is already a searched directory by the last line in its .cmake file),
except there had never been any use of LL_USESYSTEMLIBS for this one,
so just replacing the single upstream lines would be the minimal
difference.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Conflicts:
# indra/llmath/v2math.cpp
# indra/llmath/v2math.h
# indra/llmath/v3math.h
# indra/llmath/v4math.h
|
|
* Make eligible functions constexpr
* Use constants for vector indices where applicable
* Reformat to match actual coding conventions
|
|
|
