GitLab

Using VFP, we can load up to 128 bytes with a single VLDM instruction.
But before this patch, only NEON implementation was available. Just
because it showed better results on Allwinner A10 compared to VFP.
And this DDX driver used to primarily target just sunxi hardware.

But looks like it makes sense to also target other devices (at least
ODROID-X, which has the same Mali400 GPU and can use the same DRI2
integration for EGL and GLESv2 support). And on the other ARM devices,
VFP aligned reads generally work better than NEON. The benchmark
results are listed below:

            1280x720, 32bpp, testing "x11perf -scroll500"

== Exynos 5250, Cortex-A15, Non-cacheable streaming enhancement disabled ==

NEON : 10000 trep @   3.7101 msec (   270.0/sec): Scroll 500x500 pixels
VFP  : 10000 trep @   2.6678 msec (   375.0/sec): Scroll 500x500 pixels

== Exynos 5250, Cortex-A15, Non-cacheable streaming enhancement enabled ==

NEON : 15000 trep @   2.2568 msec (   443.0/sec): Scroll 500x500 pixels
VFP  : 15000 trep @   2.3016 msec (   434.0/sec): Scroll 500x500 pixels

== Exynos 4412, Cortex-A9 ==

NEON : 10000 trep @   4.5125 msec (   222.0/sec): Scroll 500x500 pixels
VFP  : 10000 trep @   2.7015 msec (   370.0/sec): Scroll 500x500 pixels

== TI DM3730, Cortex-A8 ==

NEON : 15000 trep @   2.2303 msec (   448.0/sec): Scroll 500x500 pixels
VFP  : 10000 trep @   3.0670 msec (   326.0/sec): Scroll 500x500 pixels

== Allwinner A10, Cortex-A8 ==

NEON : 10000 trep @   2.5559 msec (   391.0/sec): Scroll 500x500 pixels
VFP  : 10000 trep @   3.0580 msec (   327.0/sec): Scroll 500x500 pixels

== Raspberry Pi, BCM2708, ARM1176 ==

VFP  :  3000 trep @   8.7699 msec (   114.0/sec): Scroll 500x500 pixels

The benchmark numbers in this particular test setup roughly represent
memory copy bandwidth measured in MB/s (when doing overlapped blits
inside of a writecombine mapped framebuffer).

-----------------------------------------------------------------------

Note: the use of VFP two-pass overlapped copy instead of ShadowFB is
      still not enabled by default when running on Raspberry Pi
      because the performance results are not so great.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

This is my old ARM9E/ARM11 memcpy code from
    https://garage.maemo.org/projects/mplayer/


with some tuning for Raspberry Pi (aligned prefetch added).

Will be used by VFP optimized overlapped blt function.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

When source and destination coordinates allow it, a 16bpp screen-to-
screen blit is divided into up to three segments: two optional one
pixel wide edges and an  aligned middle segment that is copied in
32-bit mode.

This patch adds the low-level function sunxi_g2d_blit_r5g6b5_in_three
and adds logic to the general blit function to use it for 16bpp to
16bpp blits if the source and destination coordinates allow it. This
patch automatically enables the use of this optimization in the
sunxi G2D X driver. The area threshold for using G2D for
16bpp-to-16bpp blits was introduced in a previous patch.

Benchmarks:

1920x1080x16bpp@60Hz, ShadowFB disabled:

x11perf -scroll100
Before:
 350000 trep @   0.0881 msec ( 11400.0/sec): Scroll 100x100 pixels
After:
 350000 trep @   0.0819 msec ( 12200.0/sec): Scroll 100x100 pixels

x11perf -scroll500
Before:
  20000 trep @   1.3547 msec (   738.0/sec): Scroll 500x500 pixels
After:
  35000 trep @   0.8005 msec (  1250.0/sec): Scroll 500x500 pixels
Signed-off-by: Harm Hanemaaijer <fgenfb@yahoo.com>

Due to the overhead of G2D for small screen-to-screen blits, CPU blits
are faster for small areas. This patch introduces are threshold below
which CPU blits are triggered. It is currently set to 1000 for 32bpp
and 2500 for 16bpp based on test results.

Some benchmarks:

1920x1080x16bppx60Hz, ShadowFB disabled:

x11perf -scroll10

Before:
1500000 trep @   0.0239 msec ( 41800.0/sec): Scroll 10x10 pixels
After:
2500000 trep @   0.0110 msec ( 90900.0/sec): Scroll 10x10 pixels

x11perf -copywinwin10

Before:
1200000 trep @   0.0247 msec ( 40500.0/sec): Copy 10x10 from window to window
After:
1800000 trep @   0.0146 msec ( 68600.0/sec): Copy 10x10 from window to window
Signed-off-by: Harm Hanemaaijer <fgenfb@yahoo.com>

Should be useful for better performance when moving windows
and scrolling on the devices without a dedicated 2D hardware
accelerator (Allwinner A13).
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Just use "/dev/fb0" by default.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

The sunxi_x_g2d.c file contains the midlayer code for hooking the
G2D optimized blit into xserver. But in fact it does not strictly
need to depend on anything sunxi specific.

So now we introduce a simple "blt2d_i" interface struct which
specifically provides a pointer to the accelerated blit function.
And just use this interface struct instead of the whole "sunxi_disp_t".
This allows to easily reuse the same code for other non-G2D or even
non-sunxi blit implementations in the future.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

The 'main' function got there by accident and was not spotted
earlier because the driver itself is a shared library.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

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

This is still not perfect, because G2D can't saturate memory bandwidth
for this color depth (it is fillrate limited). We should emulate 16bpp blits
with 32bpp blits whenever it is possible.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

It might be not statically compiled into kernel (for example in Fedora),
so we should try to explictly load it.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Now source and destination pixmaps don't need to be the same for
using G2D acceleration (as long as both of them are allocated in
the framebuffer). This allows using G2D to copy pixels from DRI2
buffers to the framebuffer on the fallback path (when the window
of an OpenGL ES application is partially overlapped by some other
windows). Though it only works when composite extension is
disabled, for example by adding the following to xorg.conf:

    Section "Extensions"
        Option "Composite" "Disable"
    EndSection

If composite extension is enabled, windows have backing pixmaps, and
we have a longer chain of copies:

   DRI2 buffer -> backing pixmap -> framebuffer

Because backing pixmap is not allocated in a physically contiguous
memory, it can't be copied using G2D yet.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

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

Wrap CreateGC function to add a hook for CopyArea operation, which
can be accelerated using G2D for the buffers inside of the visible
part of the framebuffer. In the future we may try to also ensure
that DRI2 buffers are copied using G2D instead of CPU in the case
if we hit the fallback path and can't avoid this copy.

Benchmark using "x11perf -scroll500 -copywinwin500":

=== ShadowFB (software rendering) ===

   3000 reps @   2.0308 msec (   492.0/sec): Scroll 500x500 pixels
   3000 reps @   1.9741 msec (   507.0/sec): Scroll 500x500 pixels
   3000 reps @   1.9826 msec (   504.0/sec): Scroll 500x500 pixels
   3000 reps @   1.9830 msec (   504.0/sec): Scroll 500x500 pixels
   3000 reps @   1.9965 msec (   501.0/sec): Scroll 500x500 pixels
  15000 trep @   1.9934 msec (   502.0/sec): Scroll 500x500 pixels

   1600 reps @   3.3054 msec (   303.0/sec): Copy 500x500 from window to window
   1600 reps @   3.3179 msec (   301.0/sec): Copy 500x500 from window to window
   1600 reps @   3.2263 msec (   310.0/sec): Copy 500x500 from window to window
   1600 reps @   3.2491 msec (   308.0/sec): Copy 500x500 from window to window
   1600 reps @   3.2357 msec (   309.0/sec): Copy 500x500 from window to window
   8000 trep @   3.2669 msec (   306.0/sec): Copy 500x500 from window to window

=== G2D (hardware acceleration) ===

   3000 reps @   2.1949 msec (   456.0/sec): Scroll 500x500 pixels
   3000 reps @   2.1929 msec (   456.0/sec): Scroll 500x500 pixels
   3000 reps @   2.1923 msec (   456.0/sec): Scroll 500x500 pixels
   3000 reps @   2.1889 msec (   457.0/sec): Scroll 500x500 pixels
   3000 reps @   2.1941 msec (   456.0/sec): Scroll 500x500 pixels
  15000 trep @   2.1926 msec (   456.0/sec): Scroll 500x500 pixels

   2800 reps @   1.8114 msec (   552.0/sec): Copy 500x500 from window to window
   2800 reps @   1.8103 msec (   552.0/sec): Copy 500x500 from window to window
   2800 reps @   1.8160 msec (   551.0/sec): Copy 500x500 from window to window
   2800 reps @   1.8099 msec (   553.0/sec): Copy 500x500 from window to window
   2800 reps @   1.8126 msec (   552.0/sec): Copy 500x500 from window to window
  14000 trep @   1.8120 msec (   552.0/sec): Copy 500x500 from window to window

CPU usage remains low when running this test with G2D acceleration enabled.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Reported-by: Maurice de la Ferté <kadava@gmx.de>
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Explain that AIGLX is normally expected to fail and the users should
not really worry about it. Also provide a warning in the case if the
driver has been compiled without libUMP support (it could be that
the user actually wanted 3D acceleration, but just has not installed
all the needed dependencies).
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

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

This initial G2D support code can speed up moving windows in XFCE. Currently
disabled by default, but can be enabled by editing /etc/X11/xorg.conf and
adding the following line to the "Device" section:

        Option          "AccelMethod" "G2D"
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Avoid creating a new mapping because that's a waste of the virtual address
space. Also we are going to use this xserver framebuffer mapping address
for testing whether window backing pixmaps are allocated in the framebuffer
and can be accelerated by G2D.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

The existing kernel driver from Allwinner for G2D accelerator
is quite bad because ioctls are synchronous and blocking the
caller thread, compromise security (basically it is a backdoor
for copying data in memory between any arbitrary physical
addresses) and have high overhead (each individual fill or
blit operation needs an ioctl). But we need to start with
something, so use this stuff as a placeholder.

The g2d_driver.h header file is taken from linux-sunxi-3.4
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

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

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

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

Actually they are converted to 32x32 with 256 color palette. In the
case if we have more than 256 unique colors, the color components
of the pixels are reduced from 8-bit to 7-bit, then to 6-bit if
necessary and so on (until we reduce the number of unique colors
so that they can fit the palette). In the worst case we may
theoretically end up with just 2 bits per A, R, G and B channels,
but in practice 7 or 6 bits seem to be enough.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

The modern desktops may use ARGB cursors. As the current
sunxi display controller support code can't handle this
type of cursor yet, the X server fallbacks to a software
cursor which is not visible under layers and ruining user
experience.

This patch adds empty implementations for "UseHWCursorARGB"
and "LoadCursorARGB" functions which just return error for
now (so that the X server still fallbacks to software cursor).
However we also introduce callback functions responsible for
notifying the DRI2 code about enabling/disabling the use of
hardware cursor. So that now hardware overlays are disabled
when switching to software cursor and re-enabled again when
switching back to hardware cursor.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Testing with gnome-shell revealed a problem. We need to migrate
pixmaps into UMP buffers in order to allow the GLESv2 based
compositing manager to actually access the content of redirected
windows, rendered by X11 applications into offscreen pixmaps.

Just to make sure that we don't add any unneeded overhead for 2D
(neither extra CPU cycles nor the increase for unrelated pixmaps
memory footprint), a hash table (currently uthash [1]) is used
for connecting DRI2-enabled pixmaps with UMP buffers. The lookups
are only performed on DRI2 buffer creation and pixmap destruction.

1. http://troydhanson.github.com/uthash/

Reported-by: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

The driver can use sunxi display controller layers for fully visible
windows, avoiding expensive memory copy.

Hardware cursor is necessary because it is also visible on
top of sunxi disp layers, while software cursor is not.

FIXME: there is one minor problem with negative cursor
positions. The hardware does not support them, so such
positions are just set to 0 for now. In the future this
can be solved better by changing the cursor picture and
showing only the parts which are visible on screen.

Note: the header file "sunxi_disp_ioctl.h" is GPL licensed. So until
it is gets a MIT/X11 replacement, the DDX driver is GPL licensed as
a whole. The individual source files still have their own license.
Also in order to avoid any possible confusion, the MIT/X11 license
header from COPYING has been added to "fbdev.c" and "fbdev_priv.h".

It is going to be included by multiple different source files.

As there is no way for the hardware specific bits to be accepted
in xf86-video-fbdev, we need a new driver with its own name.

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

Signed-off-by: Dave Airlie <airlied@redhat.com>

Generated using util/modular/x-driver-screen-scrn-conv.sh
Signed-off-by: Dave Airlie <airlied@redhat.com>

fbdev seems to be the only video driver without MOD_CLASS_VIDEODRV
Signed-off-by: Paulo Zanoni <pzanoni@mandriva.com>
Reviewed-by: Jesse Adkins <jesserayadkins@gmail.com>
Signed-off-by: Julien Cristau <jcristau@debian.org>

Use XV from server's xorg-server.h to determine whether to perform XV
initialization.
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Julien Cristau <jcristau@debian.org>

Signed-off-by: Cyril Brulebois <kibi@debian.org>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Julien Cristau <jcristau@debian.org>

Signed-off-by: Cyril Brulebois <kibi@debian.org>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Julien Cristau <jcristau@debian.org>

Fixes crash in CloseScreen().
Signed-off-by: Julien Cristau <jcristau@debian.org>
Tested-by: Cyril Brulebois <kibi@debian.org>