Implementing Render acceleration in the siliconmotion driver
currojerez at gmail.com
currojerez at gmail.com
Thu Aug 21 05:07:25 PDT 2008
On Wed, Aug 20, 2008 at 04:19:15PM -0400, Alex Deucher wrote:
> On Wed, Aug 20, 2008 at 2:34 PM, Roland Scheidegger
> <sroland at tungstengraphics.com> wrote:
> > On 20.08.2008 19:46, Alex Deucher wrote:
> >> On Wed, Aug 20, 2008 at 11:12 AM, <currojerez at gmail.com> wrote:
> >>> Hi,
> >>> I have been experimenting with the sm720 3d engine: I thought I
> >>> could implement EXA composite acceleration in this hardware but
> >>> it seems to have several drawbacks.
> >>> The triangle engine worked more or less as expected, but the texture
> >>> engine only works when fed with images arranged in 16B*8 tiles (this
> >>> isn't mentioned in the documentation provided by smi:
> >>> ftp://ftp.siliconmotion.com.tw/databooks/ . In fact, the word "tile"
> >>> doesn't appear a single time in the datasheet).
> >>> This wouldn't be a problem if the rest of graphic subsystems supported
> >>> tiled data, or if the conversion could be done in hardware, but it
> >>> isn't the case.
> >>> The sm722 seems to have the same problem. The sm731 (Cougar3DR) drawing
> >>> engine and video processor seem to support tiled pixmaps, but I don't
> >>> think I could implement it without access to the hardware.
> >> I wonder if there is some sort of aperture or surface control that
> >> will do the translation for you. That's how most hardware with tiled
> >> surfaces works.
> >>> The second texture engine would be useful to implement masks, but I
> >>> can't get it working, it has all the necessary registers, but I don't
> >>> think it really has two texture engines ( From the manual: "Trilinear
> >>> mip-mapping and texture compositing (multiple texture map) are done in
> >>> 2 passes.").
> >> As Roland noted the hw probably handles this internally.
I'm setting the "Two Texture" bit in the "vertex go" register, but all
the second texture stuff seems to be ignored: the second pass doesn't
get enabled. Maybe I'm missing something, another latch somewhere else...
> >>> Moreover, it doesn't support any texture format like PICT_a8, I think
> >>> (please, correct me if i'm wrong) it is used intensively for things
> >>> like antialiased fonts, and it would be one of the main things
> >>> composite would accelerate.
> >> Seems to support a CI8 texture format.
> > I don't think you can abuse the color index format for this. I briefly
> > looked in the spec, unfortunately it doesn't mention the format the
> > lookup values are in, but it mentions there are 256 16-bit values, which
> > makes me believe those are rgb565 values with no alpha component. Well I
> > guess they could be argb4444 instead, but that still would give you only
> > 4 bits of alpha.
I tried it: it is rgb565 so we would get 5 bits of alpha.
In the sm731, the case seems worse, as it doesn't support any 8 bit
A rather hackish workaround could be to do the conversion to ARGB32
during the upload, allocating a bigger offscreen area and disobeying
the pixmap format specified by exa. We could convert it back (or
fail) in case PrepareAccess was called (this would be unlikely,
wouldn't it?). Is it possible?
> >>> Probably PICT_a8 masks could be converted in hardware to ARGB, but I
> >>> don't think anymore an efficient composite implementation could be
> >>> written for this hardware.
> >>> Any ideas?
> >> the mach64 driver has similar hardware limitations and has a certain
> >> degree of render accel:
> >> http://cgit.freedesktop.org/xorg/driver/xf86-video-mach64/tree/src/atimach64render.c
> > Right, this would be the exception :-). It also doesn't support a a8
> > format neither. But, of course, it can accept non-tiled textures, so if
> > there's indeed some possibility that the smi chip can be programmed to
> > work with tiled data it might be possible to get some support for render
> > acceleration (I wouldn't know how often mach64 hits a fallback).
> yeah. I wonder if perhaps the DMA engine can perhaps handle the tiled
> format conversion. I don't really see anything specifically in the
> DMA spec, but the documentation on these chips is pretty lacking.
I don't understand... You mean to use the DMA engine to convert it
e.g. in PrepareComposite?
Maybe the conversion could be done by scheduling repeated bitblts to
the drawing engine, but we would probably need interrupt handling.
I have had a look at the motion compensation engine... do you think it
would be a good idea to program it to do the conversion?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: Digital signature
More information about the xorg