Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
From Roland Scheidegger
51a82ec3e437d1d2dc4c688578640d25b3e7f0a2 in mainline Mesa
|
|
From Jan Zielinski
52aa730d07618513d6c055618069b2f4680974cc in mainline Mesa
Encountered by naddy@ when doing a clang 11 build. This commit
suggested by patrick@
|
|
From Vinson Lee
ff8daa013621019f1606dc0c188b16f1ce34fea7 in mainline Mesa
fixes clang 11 build
mortimer@ had almost the same diff
|
|
|
|
With Mesa 20.1 even after the kernel change to do wbinvd on all cpus
sthen@ reported that hard hangs still occurred on his Haswell system
with inteldrm.
Mark Kane also reported seeing hangs on Ivy Bridge on bugs@.
Some systems/workloads seem to be more prone to triggering this than
others as I have not seen any hangs on Ivy Bridge and the only hangs
I saw on Haswell when running piglit went away with the wbinvd change.
It seems something is wrong with drm memory attributes or coherency in
the kernel and newer Mesa versions expect behaviour we don't have.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
On mips64, the compiler does not allow use of non-zero argument with
__builtin_frame_address(). However, the returned frame address is only
used when PIPE_ARCH_X86 is defined. The compile error can be avoided
by making #ifdef PIPE_ARCH_X86 cover the getting of frame address too.
The argument checking of __builtin_frame_address() has been present
as a debug assert in clang 8. In clang 10, there is a proper runtime
check for the argument. This is why the build has not failed before.
OK jsg@
|
|
distfiles when upstream removed autotools
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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@
|
|
|
|
committed upstream as 7bea40e56652a1ded4374d92fb340b454fbac475
clock_nanosleep() isn't available yet so the usleep() path stays for
os_time_sleep()
|
|
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.
|
|
|
|
|
|
|
|
|
|
people have reported with xpdf/fvwm on ivy bridge with modesetting driver.
|
|
|
|
|
|
|
|
|
|
|
|
|