With the idea of branching classic device support in to its own tree now would be a good time to also raise the minimum
requirements to something that is more "modern" on x86.
SSE2 was introduced in 2000(!) by default let's make it the minimum spec now
All the old hardware that is moving to the maintenance branch will finally be out of the way.
For the 64-bit side of the discussion there isn't much changed.
* GCC already enables -msse and -msse2 by default
* Same with clang
* fpmath=sse might remove some extraneous x87 usage
** Clang implies fpmath=sse ALWAYS
For the 32-bit side of things is where the exciting details change
* GCC by default doesn't enable sse1 or sse2
** Does all `float`, `double`, and `long double` math with x87
** -msse2 enables sse2 and sse1, gcc still uses x87 even with those enabled
** -mfpmath=sse moves away from using x87 and instead uses sse1 and sse2
* Clang already default enables sse1/sse2 which then turns on their implied fpmath=sse
What does this mean for users?
On Linux raises the default minimum processor spec to SSE2 supporting CPUs
* Intel requirements raise from P5 (1993) to Netburst (2000)
* AMD requirements raise from Athlon(1999/2000) to Athlon 64 (2003)
* Via requirements raise from C3(2001) to C7 (2005)
What does it mean for package maintainers?
For x86-64 distributions that have i386/i686 multilib, then nothing changes. You're already on a platform guaranteed to support SSE2.
For i386/i686 distributions they will need to weigh their min spec against this. Not sure how many still support classic processors.
Who is left out in the cold?
* Intel Quark (2013)
** Embedded board, doesn't have a GPU, Technically has 1x PCIe 2.0 lane that someone could plug a GPU in to
* Some older transmeta CPUs, but they had a followup that also had SSE2.
** Anyone hacking on these with a modern GPU? I'm guessing they know how to turn this option off
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9868>
This new surface attribute can be supplied by the client to indicate
a list of modifiers that the driver can choose from for buffer
allocation. This is useful to make sure the buffers allocated via libva
are compatible with the intended usage (e.g. can be scanned out via KMS
or can be imported to EGL).
Introduce a new Gallium pipe_context.create_video_buffer_with_modifiers
hook that drivers can implement if they are modifiers-aware. Add a
modifiers argument to vlVaHandleSurfaceAllocate so that the
user-supplied list of modifiers can be passed down from vaCreateSurfaces
to the Gallium driver.
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10237>
LLVM's tools delayload some OS DLLs to improve process startup times,
but they put the delayload in the exported linker args that Meson picks
up and then applies to all libraries that link against LLVM. Since our
binaries don't link against the OS libs that are being delayloaded, that
generates a "useless delayload" warning.
Acked-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10157>
Fixes a build failure when building any Vulkan driver for the X11
platform with -Dxlib-lease=disabled. For example:
/usr/bin/ld: src/vulkan/wsi/libvulkan_wsi.a(wsi_common_x11.c.o): in function `wsi_x11_detect_xwayland':
src/vulkan/wsi/wsi_common_x11.c:123: undefined reference to `xcb_randr_query_version_unchecked'
Fixes: 1de2fd0cf2 "wsi/x11: Always link against xcb-xrandr"
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9972>
Automatically include it if we're building with a driver that depends on
it, and don't include it if we're not. Avoids a footgun (building
something like panfrost without kmsro) with minimal effect on code size
in the "kmsro possible but not used" case. (This case primarily affects
Freedreno, but the Freedreno maintainers suggested this, so I think it's
ok.)
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Suggested-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Dylan Baker <dylan.c.baker@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8893>
This adds a HAVE_COMPRESSION macro, which is undefined if neither zlib
nor zstd are present, and is used to no-op compress.h/c. This also has
a side effect of fixing SCons, since it won't define this macro.
Fixes: d7ecbd5bf8 ("util: create some standalone compression helpers")
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9689>
We'd like to use one Mesa build environment which builds our CL compiler
stack (which needs Clang/LLVM) and which builds our GL driver. The GL
driver doesn't really need LLVM support, and since we're statically
linking LLVM, removing it from the driver drastically reduces our DLL
size on disk.
Acked-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9259>
The classic OSMesa renders directly into user memory using
src/mesa/swrast, while gallium OSMesa renders using softpipe or llvmpipe
and copies out at glFlush() time. This would make gallium look like a
worse choice for OSMesa, except that swrast is:
1) Painfully slow to render compared to llvmpipe
2) Incorrect at derivatives
3) Limited to GL 2.1 instead of GL 4.6
In my survey of OSMesa users, debian was the remaining holdout with
classic OSMesa in use on hurd and some rare non-LLVM-supported
architectures (sh4, alpha, etc.). As of today, they've switched to
softpipe-based gallium OSMesa for them.
To prevent people from running the wrong OSMesa (to the extent that
running OSMesa can ever be the right thing), delete the classic
version.
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Closes: #320Closes: #877Closes: #2297
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1243>
This patch fixes this Meson build error.
$ meson builddir \
-Dshared-llvm=disabled
-Ddri-drivers=''
-Dbuild-tests=true \
-Dgallium-drivers=swrast \
-Dvulkan-drivers=''
[...]
/usr/bin/ld: src/gallium/auxiliary/libgallium.a(gallivm_lp_bld_misc.cpp.o): in function `llvm::InitializeNativeTarget()':
llvm/Support/TargetSelect.h:118: undefined reference to `LLVMInitializeX86TargetInfo'
/usr/bin/ld: llvm/Support/TargetSelect.h:119: undefined reference to `LLVMInitializeX86Target'
/usr/bin/ld: llvm/Support/TargetSelect.h:120: undefined reference to `LLVMInitializeX86TargetMC'
/usr/bin/ld: src/gallium/auxiliary/libgallium.a(gallivm_lp_bld_misc.cpp.o): in function `llvm::InitializeNativeTargetAsmPrinter()':
llvm/Support/TargetSelect.h:132: undefined reference to `LLVMInitializeX86AsmPrinter'
/usr/bin/ld: src/gallium/auxiliary/libgallium.a(gallivm_lp_bld_misc.cpp.o): in function `llvm::InitializeNativeTargetDisassembler()':
llvm/Support/TargetSelect.h:156: undefined reference to `LLVMInitializeX86Disassembler'
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7777>
