xorg Digest, Vol 25, Issue 89

[Alex Deucher]

On 8/23/07, Jarno Manninen <jarno.manninen at tut.fi> 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.
>
> 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.

If you have any patches to the upstream smi driver, I'll be happy to
review and commit them.

Alex