xorg Digest, Vol 25, Issue 89

[Michel Dänzer]

On Thu, 2007-08-23 at 20:28 +0300, Jarno Manninen wrote:
> 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. 

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

> 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. 

Right, and the driver PrepareAccess hook can fail, forcing a download.

> 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.

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...


> > > - 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.

It was mostly okay for me as well before I realized the problem, but
there was occasional corruption. Probably more noticeable with migration
scheme "always" than the others.

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

I don't remember all the cases specifically. That's probably one of
them, but definitely not the only one.


> > > - 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.

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.


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer