lp:~thopiekar/arm-mali/+git/xf86-video-fbturbo-ssvb

Author: Siarhei Siamashka
Author Date: 2017-02-18 02:35:45 UTC

new coverity key try2

Author: Siarhei Siamashka
Author Date: 2017-02-18 02:17:42 UTC

gcc

Author: Adam Jackson
Author Date: 2017-01-05 19:36:51 UTC

Use shadowUpdate32to24 at 24bpp

Signed-off-by: Adam Jackson <ajax@redhat.com>

Author: Siarhei Siamashka
Author Date: 2016-04-04 04:04:45 UTC

Framebuffer readback assembly code for AArch64

On a PINE64 board (ARM Cortex-A53), this provides ~180 MB/s
speed for the framebuffer readback. For comparison, the normal
memcpy operation in cached buffers runs at around ~1200 MB/s.

Such read back speed is actually not very fast and is borderline
usable. With a 1920x1080 32bpp screen resolution, this results in
something like ~20 FPS scrolling.

Benchmark vs. shadow framebuffer (1920x1080 32bpp):

  == Shadow framebuffer in xf86-video-fbdev ==

     $ wget http://mirror.its.dal.ca/gutenberg/3/2/0/3/32032/32032.txt
     $ time DISPLAY=:0 xterm +j -maximized -e cat 32032.txt

     real 0m43.909s
     user 0m0.820s
     sys 0m0.300s

     $ DISPLAY=:0 x11perf -scroll500 -copywinwin500 -copypixwin500 -copywinpix500

     15000 trep @ 1.8460 msec ( 542.0/sec): Scroll 500x500 pixels
     12000 trep @ 2.2629 msec ( 442.0/sec): Copy 500x500 from window to window
     12000 trep @ 2.2096 msec ( 453.0/sec): Copy 500x500 from pixmap to window
     14000 trep @ 1.9740 msec ( 507.0/sec): Copy 500x500 from window to pixmap

  == Direct framebuffer readback in xf86-video-fbturbo ==

     $ wget http://mirror.its.dal.ca/gutenberg/3/2/0/3/32032/32032.txt
     $ time DISPLAY=:0 xterm +j -maximized -e cat 32032.txt

     real 2m5.741s
     user 0m0.390s
     sys 0m0.190s

     $ DISPLAY=:0 x11perf -scroll500 -copywinwin500 -copypixwin500 -copywinpix500

      4500 trep @ 5.9201 msec ( 169.0/sec): Scroll 500x500 pixels
      6000 trep @ 5.9211 msec ( 169.0/sec): Copy 500x500 from window to window
     18000 trep @ 1.5341 msec ( 652.0/sec): Copy 500x500 from pixmap to window
      4000 trep @ 6.4657 msec ( 155.0/sec): Copy 500x500 from window to pixmap

  ==

The direct framebuffer access without the shadow framebuffer layer
makes scrolling and moving windows slower. But copying from pixmaps
to windows becomes faster. In the real world, copying from offscreen
pixmaps to windows is much more important, because it is one of the
performance bottlenecks for almost every X11 application. While
reading back from the framebuffer is only used for a few very
specialized tasks (scrolling/moving windows and making screenshots).

On 32-bit ARM systems, the uncached framebuffer readback used to
perform better. Even the Cortex-A53 running in 32-bit mode can
do framebuffer readback at more than 300 MB/s:
    https://github.com/ssvb/tinymembench/wiki/PINE64-(Allwinner-A64)

Scrolling/moving windows still can be accelerated by the kernel
(via DMA, a dedicated 2D accelerator or some other method) and
hooked into xf86-video-fbturbo.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Author: Siarhei Siamashka
Author Date: 2015-10-06 22:08:01 UTC

Merge pull request #45 from jacmet/drop-dri2-include

sunxi_x_g2d: drop unused dri2 include

Author: Siarhei Siamashka
Author Date: 2014-09-20 21:25:42 UTC

Check if the kernel framebuffer driver returns errors on bad ioctls

When probing for the copyarea ioctl, we want to be sure that the
kernel just does not return 0 (success) for any unsupported ioctls.
The rockchip vendor kernels have been reported to have this issue.

In the case if the support for the Raspberry Pi specific copyarea
ioctl was detected by mistake, moving windows or scrolling was
broken.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Author: Siarhei Siamashka
Author Date: 2014-05-03 16:10:09 UTC

HACK: Enforce the use of scaler hardware (DEFE) for all layers

To workaround FullHD desktop resolution support issues on A10-Lime
and test how all of this works.

https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg04085.html
https://github.com/linux-sunxi/u-boot-sunxi/commit/4e1532df5ebc6e0d

Author: Siarhei Siamashka
Author Date: 2014-01-12 02:42:36 UTC

vdpau: report DRI2 VDPAU driver name as 'sunxi'

Try to load the sunxi cedar kernel module. And if it loads successfully,
then report the DRI2 VDPAU name as 'sunxi'. This allows to use
libvdpau-sunxi without setting the VDPAU_DRIVER environment variable.

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Author: Siarhei Siamashka
Author Date: 2013-10-20 00:10:00 UTC

Ensure that r3p2 blob does not request dri2 buffers for each frame

Now even without using the hardware overlay, ordinary ump buffers
allocated in normal memory don't trigger excessive dri2 buffer
requests from the mali blob.

TODO:
* check for any possible memory leaks, ensure correct refcounting
* test windows resize behavior for both r3p0 and r3p2 blobs
* check if the EVEN/ODD frame order enforcing is still necessary for
  r3p2 (it could be just one more r3p0 quirk that is already gone)

Author: Siarhei Siamashka
Author Date: 2013-06-17 15:28:13 UTC

HACK: test for DMA optimized fb_copyarea in the Raspberry Pi kernel

Author: Siarhei Siamashka
Author Date: 2013-03-10 23:25:08 UTC

Added empty hooks for EXA (borrowed from xf86-video-omapfb)

Just use this stuff for testing performance and EXA overhead.