<br><br><div class="gmail_quote">On Fri, Aug 26, 2011 at 2:24 PM, Siarhei Siamashka <span dir="ltr"><<a href="mailto:siarhei.siamashka@gmail.com" target="_blank">siarhei.siamashka@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div></div><div>On Fri, Aug 26, 2011 at 2:21 PM, Marko Katić <<a href="mailto:dromede@gmail.com" target="_blank">dromede@gmail.com</a>> wrote:<br>
> Hi there!<br>
> I'm trying to optimise shadow copies from landscape oriented 16bit shadowfb<br>
> to portrait 16bit fb proper. This is done in shadowUpdateRotate16_270YX<br>
> which is located in miext/shadow/shrotpackYX.h. My optimisation is aimed at<br>
> pxa27x and xscale3 arm processors only since it uses iwmmxt asm code. I<br>
> guess it could easily be ported to x86 mmx code too.<br>
> As I understand, the current implementation copies a single pixel at a time,<br>
> like this:<br>
> *win = *sha++;<br>
> win += WINSTEPX(winStride);<br>
> This also means that we're stepping over entire cachelines since every pixel<br>
> of a single shadowfb line has to be copied to a new line of fb proper.<br>
> My patch tries to copy 4x4 pixel blocks prerotated to portrait orientation.<br>
> Basically, it takes 4 lines of shadowfb and divides it into 4x4 blocks.<br>
> Then it rotates them and copies them to fb proper. This way, instead of<br>
> copying a single pixel per fb proper line, it copies four. The rotation code<br>
> is<br>
> done in iwmmxt asm and takes about 0.9 instructions per pixel (assuming the<br>
> 4x4 block is already in iwmmxt registers). 4x4 blocks imply that the<br>
> rectangle<br>
> to be copied is width and height aligned to 4 pixels. If not, the patch<br>
> reduces the rectangle to proper alignment with single pixel copies for width<br>
> and height.<br>
> It doesn't really work and i can't find a reason why. The inital Xfbdev<br>
> screen is looking fine, but when i start moving the pointer or windows, all<br>
> i get is garbage.<br>
> The patch was tested on kdrive 1.3.0.0 running in qemu and on a Zaurus<br>
> C-1000.<br>
> If anyone has any suggestions, please do tell.<br>
<br>
</div></div>To get the best performance, it is important to take cache and TLB<br>
misses into account. The 4x4 pixel blocks may be a bit too small.<br>
<br>
I think it may be interesting to integrate iwmmxt optimizations into<br>
pixman and then use pixman for doing these rotations in xserver. Right<br>
now there is more or less cache friendly C implementation for rotation<br>
in pixman:<br>
<a href="http://cgit.freedesktop.org/pixman/tree/pixman/pixman-fast-path.c?id=pixman-0.22.2#n1620" target="_blank">http://cgit.freedesktop.org/pixman/tree/pixman/pixman-fast-path.c?id=pixman-0.22.2#n1620</a><br>
<br>
Rotation is at least partially covered in the pixman test suite ('make<br>
check'), so detecting and fixing the most obvious bugs could be a bit<br>
easier than watching for image corruption on real use. Also the<br>
'affine-test' program from the test suite can be used as an example of<br>
doing rotations on memory buffers with pixman:<br>
<a href="http://cgit.freedesktop.org/pixman/tree/test/affine-test.c?id=pixman-0.22.2" target="_blank">http://cgit.freedesktop.org/pixman/tree/test/affine-test.c?id=pixman-0.22.2</a><br>
<br>
--<br>
Best regards,<br>
<font color="#888888">Siarhei Siamashka<br>
</font></blockquote></div>I chose 4x4 block size for my initial implementation. First i wanted to get it working. The block size could easily be resized to 8x4, 8x8 or even 12x4 maybe. TLB misses could be completely avoided or at least cut in less than half, i'm also working on an improved pxafb driver that splits the framebuffer between internal sram (256K on a pxa270) and ram. The ram part is placed in a section mapping, greatly reducing the number of TLB entries. It may be possible to place the internal sram in a section mapping too, i have to try this. If it's possible, the fb proper and the shadowfb would only need 2 tlb entries. <div>
<br></div><div>Please understand that I could barely write my own name in C (or any other language) less than a year ago. Pixman sources look very scary to me and i dont think i'm up to the task of reimplementing or optimising anything in pixman. Also, it seems to me that armv5te or older architectures aren't the main targets for optimisations in pixman. My main objective is to create a decent performing Kdrive for my Zaurus. To this end, i have written some patches and also, adapted some of your own armv6 code which you wrote for the Maemo Kdrive.</div>
<div><br></div><div>But i digress...</div><div><br></div><div>Could alignment be the problem with my patch? The shadowfb and fb proper lines are probably not 64 bit aligned before calling iwmmxt_rotate_copy...</div><div><br>
</div><div> </div>