User:DanielDrake/X hacking: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
No edit summary
 
Line 1: Line 1:
= EXA =
= EXA =

(thanks to Mart Raudsepp for getting me started with much of the info below)


== Core reading list ==
== Core reading list ==
* [http://keithp.com/~keithp/porterduff/ Porter-Duff academic paper] defines the fundamentals of compositing
* [http://keithp.com/~keithp/porterduff/ Porter-Duff academic paper] defines the fundamentals of compositing
* [http://cgit.freedesktop.org/xorg/proto/renderproto/tree/renderproto.txt The render spec] implements porter-duff fundamentals
* [http://cgit.freedesktop.org/xorg/proto/renderproto/tree/renderproto.txt The render spec] implements porter-duff fundamentals
* exa/exa.h defines a layer that allows drivers to hardware-accelerate the render extension
* [http://cgit.freedesktop.org/xorg/xserver/tree/exa/exa.h exa.h] defines a layer that allows drivers to hardware-accelerate the render extension

== Measure ==

To find code paths that aren't being accelerated that would potentially be worth accelerating, look at the CheckComposite/PrepareComposite calls in the driver that return FALSE. The geode driver has some optional logging here, skimming the logs will give an idea.

Also, in the xserver EXA code there is a macro which can be enabled to report fallback cases in a driver-independent manner. EXA also has some helper functions which can be used to print details of the operation.

Some CheckComposite/PrepareComposite failures won't directly result in software rendering - sometimes EXA will then break the operation into multiple operations and see if the driver can accelerate those.


== Other resources ==
== Other resources ==

Latest revision as of 15:25, 5 October 2012

EXA

(thanks to Mart Raudsepp for getting me started with much of the info below)

Core reading list

Measure

To find code paths that aren't being accelerated that would potentially be worth accelerating, look at the CheckComposite/PrepareComposite calls in the driver that return FALSE. The geode driver has some optional logging here, skimming the logs will give an idea.

Also, in the xserver EXA code there is a macro which can be enabled to report fallback cases in a driver-independent manner. EXA also has some helper functions which can be used to print details of the operation.

Some CheckComposite/PrepareComposite failures won't directly result in software rendering - sometimes EXA will then break the operation into multiple operations and see if the driver can accelerate those.

Other resources