Age | Commit message (Collapse) | Author |
|
|
|
From Jordan Justen
f4c44444adfb93740363ba6f424ab5f9e673b470 in mainline Mesa
|
|
From Jordan Justen
6ca37aabfbb04a066d3d440aad3181c087fe3c6d in mainline Mesa
|
|
|
|
|
|
0cfc01fe835fe727e9ff7485fd6b5c8180bfd7b7 in mainline Mesa
|
|
0cfc01fe835fe727e9ff7485fd6b5c8180bfd7b7 in mainline Mesa
|
|
From Jordan Justen
d257494ec4d826aec8841845479215820e612917 in mainline Mesa
|
|
From Jordan Justen
4e0eca7dc34942759638ab00eb006ba40284a7c in mainline Mesa
|
|
From Jordan Justen
03cc5a8295e239b45623c89faac88030b33a4a14 in mainline Mesa
|
|
From Jordan Justen
fd646c2d2f8b3efed92630d548448a1bdd6ba2b1 in mainline Mesa
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
Grrr, sorry about that.
|
|
When not in c++ or c11 mode:
- check for _Static_assert support in clang with __has_extension
- gcc implements _Static_assert starting with 4.6.0
- as a fallback, use a forward decl instead of ((void)0) so that
static_assert can be used at file scope (scope issue pointed out by
guenther@)
ok jsg@
|
|
Temporary workaround while we find a better solution.
Linking errors in ports reported by cwen@, "Please commit" jsg@
|
|
|
|
|
|
From Anuj Phogat
82f6a746e8b47fb6e3f96d7f5f69973f50eec9ca in mesa master
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
people have reported with xpdf/fvwm on ivy bridge with modesetting driver.
|
|
|
|
|
|
|
|
|
|
|