Re: Implementing Render acceleration in the siliconmotion driver

["Alex Deucher" <alexdeucher@xxxxxxxxx>]

On Wed, Aug 20, 2008 at 2:34 PM, Roland Scheidegger
<sroland@xxxxxxxxxxxxxxxxxxxx> wrote:
> On 20.08.2008 19:46, Alex Deucher wrote:
>> On Wed, Aug 20, 2008 at 11:12 AM,  <currojerez@xxxxxxxxx> 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.
>

right.

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

Alex
_______________________________________________
xorg mailing list
xorg@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/xorg