Implementing Render acceleration in the siliconmotion driver

[Roland Scheidegger]

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

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

Roland