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>
Some flex/bison installs on windows include yacc and lex
as bash scripts that call bison/flex binaries. That creates
an extra layer of dependencies because those won't work from
plain cmd.exe/powershell. Lets switch the lookup order so that
by default we pickup vanilla binaries instead of scripts.
Reviewd-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7806>
If you dlclose your driver, the leak reports look like:
#0 0xffff9c7e5e7c in malloc (/lib/aarch64-linux-gnu/libasan.so.6+0x9ee7c)
#1 0xffff94aaaa48 (<unknown module>)
#2 0xffff94aa5ff4 (<unknown module>)
#3 0xffff94d1867c (<unknown module>)
#4 0xffff94d184f0 (<unknown module>)
#5 0xffff94c9a990 (<unknown module>)
#6 0xffff94c92e30 (<unknown module>)
#7 0xffff94c91d48 (<unknown module>)
#8 0xffff946eb800 (/home/anholt/src/mesa/build-aarch64-asan/src/egl/libEGL.so.1.0.0+0xfe800)
#9 0xffff94c72874 (<unknown module>)
#10 0xffff946ede68 (/home/anholt/src/mesa/build-aarch64-asan/src/egl/libEGL.so.1.0.0+0x100e68)
#11 0xffff94bf7134 (<unknown module>)
#12 0xffff9c686450 in dri2_create_screen ../src/egl/drivers/dri2/egl_dri2.c:1079
which is not terribly useful. Probe if we're building with asan and just
skip closing the driver in the happy path (which seems to be the standard
practice for loadable modules with this tool).
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7695>
Without this header-file, we can't build the driver. So let's verify
that it exists, and can be used by the C++ compiler.
This should make it a bit more clear what's wrong if someone attempts to
build this using MinGW or on Linux.
Fixes: 2ea15cd661 ("d3d12: introduce d3d12 gallium driver")
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7575>
This enables GL applications to be written without any involvement of
Xlib.
EGL X11 platform is actually already xcb-only underneath, so this commit
just add the necessary interface changes so eglDisplay can be created
from a xcb_connection_t.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6474>
loader_dr3_helper.c uses xcb_xfixes_create_region() that requires dep_xcb_xfixes to link. This is dependent on with_platform_x11 and with_dri3.
But the source meson file does not set this up dependent on with_dri3.
The build was initialsed using platforms=x11 and gallium-drivers=zink,swrast.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7164>
We already have the targets we care about doing this using
ld_args_gc_sections, and by adding it to project arguments we caused
warnings spam in the android clang build about the compile stage not using
the argument.
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6700>
Initial commit, mostly a import of the minimum from anv/radv to get a
skeleton to start to work with.
In includes:
* meson files
* Copy & adapt entrypoints ane extensions scripts from anv (that were
later used on radv)
This is a firt approach, but is is likely that we can remove/simplify
some things.
v2: fix copyright character at broadcom/vulkan/meson.build (Eric)
v3: no spaces inside arrays (Dylan)
v4: add gnu_symbol_visibility (detected by CI on first Merge attemp)
Reviewed-by: Eric Anholt <eric@anholt.net>
squash! v3dv: add v3d vulkan driver skeleton
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6766>
On some systems it is problematic to have the shader cache enabled
by default. This adds a build option to support the disk cache but
keep it disabled unless the environment variable
MESA_GLSL_CACHE_DISABLE=false.
For example, on Chrome OS, Chrome already has it's own shader
disk cache implementation so it disables the mesa feature. Tests
do not want the shader disk cache enabled because it can cause
inconsistent performance results and the default 1GB for the
disk cache could lead to problems that require more effort to
work around. The Mesa shader disk cache is useful for VMs though,
where it is easy to configure the feature with environment
variables. With the current version of Mesa, Chrome OS would need
to have a system-wide environment variable to disable the disk
cache everywhere except where needed. More elegant to just build
Mesa with the cache feature disabled by default.
Reviewed-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6967>
