The intel driver can be used with inteldrm on ivy bridge or newer.
The radeon driver only works with amdgpu not radeondrm.
As we can't use python in xenocara add phony targets to create the
same output as python scripts which create json files for the loader.
This is just the ICDs, to use vulkan the loader and additional ports
are required.
ok mpi@ on an earlier version. Changed to call shm_unlink()
directly after shm_mkstemp() as suggested by kettenis@
shared libLLVM are in base. And now we can finally build the radeonsi
Mesa driver adding accelerated support for radeon parts based on the
Graphics Core Next (GCN) architecture which is everything since
GFX6 / Southern Islands.
This can later be expanded to other architectures which build libLLVM
and have clang as the default compiler (to handle LLVM's c++11 headers).
Mesa 18.x needs an ld with build-id for at least the intel code
Mesa 18.2 assumes linux only memfd syscalls in intel code
Tested by matthieu@, kettenis@ and myself on a variety of hardware and
architectures. ok kettenis@
Corruption has again been reported on Intel hardware running Xorg with
the modesetting driver (which uses OpenGL based acceleration instead of
SNA acceleration the intel driver defaults to).
Reported in various forms on Sandy Bridge (X220), Ivy Bridge (X230) and
Haswell (X240). Confirmed to not occur with the intel driver but the
xserver was changed to default to the modesetting driver on >= gen4
hardware (except Ironlake).
One means of triggering this is to open a large pdf with xpdf on an
idle machine and highlight a section of the document.
There have been reports of gpu hangs on gen4 intel hardware
(T500 with GM45, X61 with 965GM) when starting Xorg as well.
require python/bison a configure flag instead of the previous way of
testing whether python was found (which shouldn't be the case in
xenocara even with ports packages installed).
This is required when timestamps change on files causing targets to be
invoked that will break if python and bison aren't available and found
in path by the configure script.
atomic builtins on a 64 bit integer which is not supported on 32 bit powerpc.
Makes 3D work again on a PowerBook G4 with an ATI RV350 video card.
tweak and ok jsg@
mpi found where the r300 driver would not load on macppc due to an
undefined drisw_create_screen symbol.
The code related to that symbol was removed sometime after Mesa 11.0
branched.
Initial diff from and ok mpi@
operations and older CPUs lack the needed instructions. The hardware
supported by that driver will never be used together those older CPUs.
This might mean that even the software rasterizer doesn't work anymore on
those. But they're so slow that you probably wouldn't want to anyway.
ok jsg@
