[Intel-gfx] [PATCH 00/12] Rework intel 2D driver glamor support
Keith Packard
keithp at keithp.com
Fri Jul 25 01:18:16 CEST 2014
I spent the day just cleaning up this patch series and testing. I
think it's ready for others to use and review. I've been running it on
two machines for a couple of days now and it's been solid.
I ran three different desktop environments (current Debian unstable versions):
XFCE 4.10
Gnome 3.12
KDE 4.13.3
I have not merged DRI2 support when running with Glamor; I've got that
working locally, but if you accidentally try indirect rendering,
you'll crash the X server with an assert failure. So, this is DRI3
only, at least for now.
This patch series also adds a "none" acceleration mode. It's different
from other unaccelerated drivers in offering DRI2 and DRI3 support so
that you can run direct rendering.
A brief synopsis of the series
1-4 cleanup patches
5 Identify and isolate UXA code; UXA-specific functions are
renamed and moved into uxa-specific files.
6 Remove UXA-based Glamor support. This pulls out all of the
Glamor calls from UXA rendering paths. This patch only builds
with glamor disabled; I didn't worry about the existing glamor
code or support for glamor within the rest of the driver.
7-9 Prepare for glamor support. Creates a couple of abstract
functions for accel-dependent functionality needed by the
initialization and modesetting code. Gets rid of the
glamor stubs in intel_glamor.h
10 Add glamor support back in, using the regular glamor
API.
11 Add an unaccelerated option ("none"). This offers fb-only
support and is always compiled in to the driver.
12 Delay initial mode set operation until the root window
is painted and the server is ready to go. This includes
potentially copying an existing fbcon frame buffer to the
root window in background none mode, providing support
for this in all three acceleration modes. The driver used
to support this by copying the fbcon buffer to the screen
buffer during early server initialization; this change allows
the driver to use regular GC-based CopyArea instead of needing
custom rendering code.
More information about the Intel-gfx
mailing list