[PATCH 00/12] Rework intel 2D driver glamor support

Keith Packard keithp at keithp.com
Thu Jul 24 16:18:16 PDT 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 xorg-devel mailing list