xorg Digest, Vol 25, Issue 89

[Jarno Manninen]

On Thursday 23 August 2007 18:27:23 Michel Dänzer wrote:

> On Wed, 2007-08-22 at 20:41 +0300, Jarno Manninen wrote:
> > 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:
>
> The xf86-video-ati radeon driver handles this in the
> UploadTo/DownloadFromScreen and PrepareAccess hooks, didn't that work
> for you?

I wish that it was that easy. However SMI supports only such byte swap 
operations that direct access to the pixmaps is impossible. It only supports 
1234 <-> 4321 and 1234 <-> 3412 which makes is quite hard to implement direct 
access correctly. I would be happy if someone could tell me that I'm 
mistaken. 

One could try to make it with 32bits but the support in SMI is quite 
incomplete for that mode and the limited memory (8Mb) forced me to find 
alternatives == working 16bit. However with PPC and SMI byte swaps it is 
possible to do the correct swaps in the upload/download functions. 

One more problem with cards with limited capabilities is that some operations 
could be accelerated in render if we could represent for example A8 as A8X24
(8R8G8B8A) in the framebuffer memory. This would be especially usefull for 
SMI that doesn't support A8 textures but only C8. (Sigh... what is that 2 
lines in the VHDL code to bypass that index value to alpha directly...)

Well. University lessons start soon so I'll have more time to think about it, 
if not actually write any code. ,-)

> > - 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.
>
> There are some (mostly intermediate) operations not wrapped by the
> damage layer, see exaPixmapDirty() and its callers. We may still be
> using that in some cases where it isn't really necessary though, I fixed
> one such case recently.

That might be. I really haven't tested it very well so I most propably have 
missed some cases. However visually it seems to be ok.

Hmm. At some point I made some tweaks because of the glyph drawing. Are you 
referring to that?

> > - 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).
>
> I thought about that a bit recently, but it seemed complicated...

I'm using the following:

1. Intercept the damage area that the current operation is going to cause 
using the damage extension.

2. If the operation isn't opaque(like solid fill etc..) then calculate the 
intersection between the new damage area and the old damage area in the FB 
memory. Then download the area from the FB to SYS. This step can be skipped 
for operations that totally overwrite the whole area and do not require DST 

3. Mark pixmap as being in system scratch state.

4. Do the software operation.

5. Upload the new damage area and subtract it from the old FB damage area 
because that part of the pixmap is in sync between FB and SYS.

6. Move pixmap back to FB state.

> > 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?  :|
>
> I'd definitely be interested in looking at it.

I'll try to cleanup the code and put it on show somewhere.

- Jarno