Not getting expected performance improvement after accelerating bitBlit through KAA

prudhvi raj prudhviraj.v at gmail.com
Mon Nov 9 03:21:23 PST 2009


Can anyone please answer the questions mentioned in the previous post?

I am stuck at this particular point and want your valuable suggessions to
proceed furthur in order to improve the performance by accelerating blit
operation.

your suggesions will be highly appreciated.

On Thu, Nov 5, 2009 at 2:55 PM, prudhvi raj <prudhviraj.v at gmail.com> wrote:

> Thanks a lot for your valuable inputs.
>
> According to your comments i understand that KDrive has been removed in
> recent release R7.5 because of the below reasons
> - no one is maintaining it
> - accelerated drivers developed using KAA architecture are not improving
> the performance as expected >>(Because the major tradeoffs made for kdrive
> (not building XKB and GLX,
>
> >>for example) are either generally recognized to be false economies, or
> >>are achievable with Xorg too.)
> Am i correst??
>
> Actually my requirement is to improve the performance of Xfbdev server by
> mapping the hardware accelerated APIs. After going through the XServer code
> i found the drivers for ATI, Mach64 cards which uses KAA to acheive hardware
> acceleration.
>
> I have developed my driver using KAA in the same lines as ATI and Mach64
> drivers, for example in order to implement hardware fillrect, i have
> implemented the corresponding hooks provided by kaa PrepareSolid, Solid and
> DoneSolid. In "Solid" hook i have placed my hardware fillrect api.For blit
> also i have placed the hardware blit call in  "Copy" hook of KAA.
>
> But even though some calls are getting called through these kaa hooks i am
> not getting much performance improvement.
>
> In this approach some calls of fillrect and blit are routed through kaa's
> solid and copy hooks, but when i compare the number of times they get routed
> to corresponding software hooks (fbPolyFillRect, fbCopyNtoN respectively for
> fillrect and blit) to kaa's hardware hooks, the software calls are very high
> in number than the hardware calls.
>
> So my queries are,
> 1. Am i placing my hardware API calls at right places in order to
> accelerate fillrect, blit operations?? As the number of hw calls are very
> fes compared to software calls i doubt whether the way to acheive hardware
> acceleration is this only or do i miss some more implementation??
>
> 2. If placing the harware calls in the hooks provided by kaa should be
> enough to attain acceleration, why is the performance is not getting
> improved?? As the 'blit' operation happens huge number of times, by
> accelerating blit the performace should be improved drasticly.
>
> 3. As per your comments, if the reason for not getting performance
> improvement lies inside KAA architecture itself, should i move to EXA to
> attain better performance improvement?? Using EXA would help to improve the
> performance??
>
> 4. Can you provide some sample drivers (as ATI, Mach64 in case of KAA) thst
> uses EXA for acceleration?? Please provide any documentation resources that
> explain the design and imeplementation details of KAA, EXA, XServer and how
> to acheive hardware acceleration in tinyx etc.
>
> It would be very much helpful for me if you answer the above queries. Thank
> you.
>
>
>
>
> On Mon, Nov 2, 2009 at 10:01 PM, Adam Jackson <ajax at nwnk.net> wrote:
>
>> On Fri, 2009-10-30 at 13:12 +0530, prudhvi raj wrote:
>> > Thanks for the response mr. Daniel.
>> >
>> > According to my understanding KDrive has been developed with more
>> > focus on embedded systems. So why do u want me to go for XOrg ( u mean
>> > XAA??) instead of KDrive??
>>
>> Because the major tradeoffs made for kdrive (not building XKB and GLX,
>> for example) are either generally recognized to be false economies, or
>> are achievable with Xorg too.  And because nobody is maintaining kdrive,
>> or wants to.
>>
>> > Do u have any ided why the mapping    pScreen->PaintWindowBackground =
>> > kaaPaintWindow; has been removed in the next versions??
>>
>> commit e4d11e58ce349dfe6af2f73ff341317f9b39684c
>> Author: Eric Anholt <eric at anholt.net>
>> Date:   Wed Sep 12 13:58:46 2007 +0000
>>
>>    Remove the PaintWindow optimization.
>>
>>    This was an attempt to avoid scratch gc creation and validation for
>> paintwindow
>>    because that was expensive.  This is not the case in current servers,
>> and the
>>    danger of failure to implement it correctly (as seen in all previous
>>    implementations) is high enough to justify removing it.  No performance
>>    difference detected with x11perf -create -move -resize -circulate on
>> Xvfb.
>>    Leave the screen hooks for PaintWindow* in for now to avoid ABI change.
>>
>> > and why is the function kaaFillRegionTiled() is left unimplemented and
>> > commented??
>>
>> Probably because it was only ever called from the PaintWindow screen
>> hook.
>>
>> As to your initial question:
>>
>> > > Can you provide more clarity why are most of the Blit calls are
>> > > routed through software fallbacks.
>>
>> fbBlt is called from more places than just the screen-to-screen copy
>> path.  In particular, it's called from the PutImage path (host to GPU
>> upload), which KAA does not (did not) accelerate.
>>
>> - ajax
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.x.org/archives/xorg-devel/attachments/20091109/02051906/attachment.html 


More information about the xorg-devel mailing list