upsteam code.
Backporting keeping UMS changes by me, some bugfixes from kettenis@.
Has been in snapshots for a while, committed on request so we can be
sure what people are running. This is a prerequesite for sandybridge
support but has those chipsets disabled for now until the correct code
has been added.
It is missing a few commits that I have yet to verify (ones that try and
continue if we lock the gpu rendering engine and can't reset it, for
example) taht will be verified and sent out for extra testing soon.
Should contain a bunch of speedups and some correctness improvements
(though rendercheck still gives some errors that I am looking into).
This has been in snaps since the first day of c2k10, any known issues
with just this driver have (to my knowledge) been fixed since. A problem
with macbooks pointed out by otto happens with both this and the in-tree
driver and thus doesn't stop this moving forward.
As well as the 2.12 improvements, this driver also has a backport
(partially aided by the backports in RHEL 5 kindly provided by Dave
Airlie) from the kms code of modesetting support for ironlake (arrandale
and clarkdale: the IGDs build into intel nehalem cpu dies) which has
been tested on a number of chipsets. Note that Display port and eDP
displays have not yet been worked on (and probably won't until I can
find a displayport monitor), but VGA and lvds at least are known to
work, sure beats vesa.
"no objection on my side" matthieu@, prodding (as always) from princess
marco.
changes from later intel versions (after the UMS removal). 95% of this
is the xvmc reworks that makes that code even halfway sane. xvmc is now
enabled by default on 965+.
Tested by many on tech@, thanks!
ok matthieu@
2.9.1 is the last version of the intel DDX that supports UMS (User
modesetting), with 2.10 onwards being purely KMS only. As such, this
driver contains backports of almost every correctness or performance
related fix to the rendering layer in later intel drivers. This driver
*REQUIRES* a GEM enabled kernel. it claims to support non-gem mode but
this is essentially unmaintained and due to the way the abstraciton
works is slow, if it works at all (it often does not). You have been
warned.
tested by many many people on tech over the last few weeks.
software rasterise them THEN put them into buffer objects.
read-modify-write of graphics memory is expensive.
2.5x speed increase under heavy trap rendering measured.
Another upstream backport. ok matthieu@
