User:DanielDrake/X hacking: Difference between revisions
DanielDrake (talk | contribs) No edit summary |
DanielDrake (talk | contribs) 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
- Porter-Duff academic paper defines the fundamentals of compositing
- The render spec implements porter-duff fundamentals
- 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
- exa-driver.txt
- X11 composite tutorial
- How to handle out-of-source coordinates with compositing
- rendercheck as a render/EXA test suite