Thanks a lot for your valuable inputs.<br><br>According to your comments i understand that KDrive has been removed in recent release R7.5 because of the below reasons<br>- no one is maintaining it<br>- 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,<br> >>for example) are either generally recognized to be false economies, or<br>>>are achievable with Xorg too.)<br>Am i correst??<br><br>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. <br> <br>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.<br> <br>But even though some calls are getting called through these kaa hooks i am not getting much performance improvement.<br><br>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.<br> <br>So my queries are,<br>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??<br> <br>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.<br> <br>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??<br> <br>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.<br> <br>It would be very much helpful for me if you answer the above queries. Thank you.<br><br> <br><br><div class="gmail_quote">On Mon, Nov 2, 2009 at 10:01 PM, Adam Jackson <span dir="ltr"><<a href="mailto:ajax@nwnk.net">ajax@nwnk.net</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Fri, 2009-10-30 at 13:12 +0530, prudhvi raj wrote:<br> </div><div class="im">> Thanks for the response mr. Daniel.<br> ><br> > According to my understanding KDrive has been developed with more<br> > focus on embedded systems. So why do u want me to go for XOrg ( u mean<br> > XAA??) instead of KDrive??<br> <br> </div><div class="im">Because the major tradeoffs made for kdrive (not building XKB and GLX,<br> for example) are either generally recognized to be false economies, or<br> are achievable with Xorg too. And because nobody is maintaining kdrive,<br> or wants to.<br> <br> </div><div class="im">> Do u have any ided why the mapping pScreen->PaintWindowBackground =<br> > kaaPaintWindow; has been removed in the next versions??<br> <br> </div><div class="im">commit e4d11e58ce349dfe6af2f73ff341317f9b39684c<br> Author: Eric Anholt <<a href="mailto:eric@anholt.net">eric@anholt.net</a>><br> Date: Wed Sep 12 13:58:46 2007 +0000<br> <br> Remove the PaintWindow optimization.<br> <br> This was an attempt to avoid scratch gc creation and validation for paintwindow<br> because that was expensive. This is not the case in current servers, and the<br> danger of failure to implement it correctly (as seen in all previous<br> implementations) is high enough to justify removing it. No performance<br> difference detected with x11perf -create -move -resize -circulate on Xvfb.<br> Leave the screen hooks for PaintWindow* in for now to avoid ABI change.<br> <br> </div><div class="im">> and why is the function kaaFillRegionTiled() is left unimplemented and<br> > commented??<br> <br> </div><div class="im">Probably because it was only ever called from the PaintWindow screen<br> hook.<br> <br> As to your initial question:<br> <br> </div><div class="im">> > Can you provide more clarity why are most of the Blit calls are<br> > > routed through software fallbacks.<br> <br> </div><div><div></div><div class="h5">fbBlt is called from more places than just the screen-to-screen copy<br> path. In particular, it's called from the PutImage path (host to GPU<br> upload), which KAA does not (did not) accelerate.<br> <br> - ajax<br> <br> </div></div></blockquote></div><br>