xorg Digest, Vol 25, Issue 89

[Jarno Manninen]

Quoting Michel Dänzer <michel at tungstengraphics.com>:

> I suppose it can't combine the two modes to achieve 1234 <-> 2143?

Nope. Just only one port for conversion with one conversion type.

> Hmm, I guess the only thing preventing that is that EXA calculates
> pExaPixmap->fb_size assuming the bpp is the same as in system RAM...

That one is easy to fix, but real solution might require some  
additional field in the ExaPixmap struct to track the sys/fb  
depths/formats. Also any migration between sys and fb should take care  
of the correct transformation.

However I'm not sure if switching the format in picture struct would  
break something else. So hooking of the any Picture access might be  
required?

> Hmm, I think it might be possible to get at least some of the same
> benefits by just tracking damage for FB and SYS separately and only
> transferring regions between them that are actually needed for the
> operation at hand... interesting food for thought.

Obvious benefit over using only one damage area is that for off-screen  
pixmaps the drawing operations could be accumulated until the blit to  
visible area. Uploading after every operation (like I'm doing now)  
might cause unnecessary uploads.

At least it would be easy to calculate the area for migration.

   migrate(fb.damage UNION sys.damage)

   if (sw)
     fb.damage = fb.damage SUBTRACT (fb.damage UNION sys.damage)
   else
     sys.damage = sys.damage SUBTRACT (fb.damage UNION sys.damage)

Might be worth a try.

- Jarno