xorg Digest, Vol 25, Issue 89
alexdeucher at gmail.com
Thu Aug 23 11:48:48 PDT 2007
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
> 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.
More information about the xorg