xorg Digest, Vol 25, Issue 89

[Jarno Manninen]

> I have implemented a  KAA driver for my graphics card.Will I get any
> performance gain if I migrate to EXA? I know EXA is based on KAA but will
> EXA give better performance in case of Fill and Copy operations?Pl comment.

Hello,

I've hacked X.Org 7.1 Kdrive to use EXA from X.org 7.2, so it is doable. One 
problem with drivers is that Kdrive and X.org store the HW related data 
differently. But I was only interested in one particular driver so it wasn't 
such a problem then. Maybe one could create one more struct to contain the 
necessary HW related data, such as video memory pointers etc. Then it might 
be possible to move most of the driver code under shared exa/drivers or 
something similar. Of course X.org and Kdriver & co do initialization stuff 
differently, but the major parts could be shared, right?

But to the point. Yes. EXA could improve some operations, like tiled fills, 
but also it also increases the overhead for operation due to PrepareAccess & 
co. Also the off-screen memory management is better I think.

However I've hacked my copy of EXA beyond recognition in order to make bytes 
swap correctly on my PPC+SMI722 combination. For this I tried to:

- Damage inflicted on pixmaps is recorded using damage extension, similar to 
Damage Track in GIT. I haven't checked the latest but the difference is that 
I just pull in the regions from the Damage extension. Seems to work OK.

- I tried to separate the data transfer path and pixmap handling policy from 
each other in such way that different types of pixmap can have different 
policy applied depending on the type.

	action = pExaPixmap->policy->actionOnFallback(&pixmaps[i]);
	switch (action) {
		case ExaScratchCache:
		case ExaMigrate:
		case ExaDirectAccess:
		....
	}

- Tried to make it in such way that unaccelerated operations do not required 
full migration from the FB by temporarily downloading region (Damaged area 
INTERSECT area that is being modified). 
 
- Tried to make pixmap state more definite/available.

	http://www.students.tut.fi/~manninej/misc/exa_pixmap_state.jpg

- Combined Prepare/Finish-Access and migration calls in to "one" package.

	#define EXA_OPERANDS(count) 
	#define EXA_DEFAULT_DST_OPERAND(pDrawable, opq) 
	#define EXA_DST_OPERAND(pDrawable, _area, opq) 
	#define EXA_SRC_OPERAND(pDrawable, _area) 
	#define EXA_GC_OPERAND(pGC) 

	#define EXA_PREPARE_FALLBACK()
	#define EXA_FINISH_FALLBACK()
	#define EXA_PREPARE_ACCELERATION()
	#define EXA_FINISH_ACCELERATION()

	Like:
	
		if (!EXA_PREPARE_ACCELERATION()) {
			EXA_PREPARE_FALLBACK()
			doSw();
			EXA_FINISH_FALLBACK()			
		} else {
			doHw();
			EXA_FINISH_ACCELERATION()
		}

Well.. Lot of incoherent ideas. Unfortunately I don't have that much time to 
finish the code in to form that I would dare to publish. Most of that I have 
working in code but the base is dated and I don't think that I have time to 
bring it up to HEAD anytime soon. Maybe someone can take a look if there's 
anything usable?  :|

- Jarno