G2D on A20

[Patrick Wood]

As an astute observer noted on cubieforums.com, the Kconfig for G2D depends on SUN4I.  This change enables it:

 config SUN4I_G2D

-       depends on ARCH_SUN4I

+       depends on (ARCH_SUN4I || ARCH_SUN5I || ARCH_SUN7I)

        tristate "SUN4I G2D"

The driver starts up and creates a /dev/g2d file; but how do we know if it's working properly?  Are there specific g2d tests?

[Arokux X]

On Tue, Sep 10, 2013 at 4:57 PM, Patrick Wood <patric...@gmail.com> wrote:

As an astute observer noted on cubieforums.com, the Kconfig for G2D depends on SUN4I.  This change enables it:

 config SUN4I_G2D

-       depends on ARCH_SUN4I

+       depends on (ARCH_SUN4I || ARCH_SUN5I || ARCH_SUN7I)

        tristate "SUN4I G2D"

You also need to change SUN4I_G2D to SUNXI_G2D.

[Siarhei Siamashka]

You can try "sunxi_g2d_bench" program from

https://github.com/ssvb/xf86-video-sunxifb/tree/master/test

It gets built as part of the xf86-video-sunxifb build process:

https://github.com/ssvb/xf86-video-sunxifb/wiki/Installation

If you run this "sunxi_g2d_bench" test program and it works (no X
required to run it), then G2D is likely fine.

--
Best regards,
Siarhei Siamashka

[Patrick Wood]

Yes, and that'll require changes to plat-sunxi/core.c, drivers/char/sun4i_g2d/Makefile, and drivers/char/Makefile.

[Arokux X]

On Tue, Sep 10, 2013 at 5:11 PM, Patrick Wood <patric...@gmail.com> wrote:

Yes, and that'll require changes to plat-sunxi/core.c, drivers/char/sun4i_g2d/Makefile, and drivers/char/Makefile.

Send us a patch please, as you are already familiar with the code base.

Thanks,
Arokux

[Patrick Wood]

It seems to work, but I get a ton of "wait g2d irq pending flag timeout" messages during the first two tests.

<4>[DISP] layer allocated: 0,101

disp->xres=1920, disp->yres=1080, disp_bits_per_pixel=32, g2d_accel=yes

Running G2D benchmarks for framebuffer (typically writecombine mapped)

wait g2d irq pending flag timeout

<snip>

G2D blit performance: 41.14 MPix/s (164.56 MB/s)

wait g2d irq pending flag timeout

<snip>

G2D fill performance: 40.92 MPix/s (163.69 MB/s)

Running pixman benchmarks for framebuffer (typically writecombine mapped)

pixman blit performance: 9.71 MPix/s (38.85 MB/s)

pixman fill performance: 226.95 MPix/s (907.79 MB/s)

Running pixman benchmarks for normal RAM (typically mapped as WB cached)

pixman blit performance: 110.50 MPix/s (441.99 MB/s)

pixman fill performance: 320.38 MPix/s (1281.53 MB/s)

[Patrick Wood]

I will as soon as I've verified it's working.

Pat

[Patrick Wood]

Patch submitted.

On Tuesday, September 10, 2013 11:12:46 AM UTC-4, Arokux wrote:

[Siarhei Siamashka]

On Tue, 10 Sep 2013 08:19:24 -0700 (PDT)
Patrick Wood <patric...@gmail.com> wrote:

> It seems to work, but I get a ton of "wait g2d irq pending flag timeout"
> messages during the first two tests.
>
> <4>[DISP] layer allocated: 0,101
> disp->xres=1920, disp->yres=1080, disp_bits_per_pixel=32, g2d_accel=yes
>
> Running G2D benchmarks for framebuffer (typically writecombine mapped)
> wait g2d irq pending flag timeout
> <snip>
> G2D blit performance: 41.14 MPix/s (164.56 MB/s)
> wait g2d irq pending flag timeout
> <snip>
> G2D fill performance: 40.92 MPix/s (163.69 MB/s)
>
> Running pixman benchmarks for framebuffer (typically writecombine mapped)
> pixman blit performance: 9.71 MPix/s (38.85 MB/s)
> pixman fill performance: 226.95 MPix/s (907.79 MB/s)
>
> Running pixman benchmarks for normal RAM (typically mapped as WB cached)
> pixman blit performance: 110.50 MPix/s (441.99 MB/s)
> pixman fill performance: 320.38 MPix/s (1281.53 MB/s)

This definitely does not look good.

The reported G2D performance is way too low. Maybe the G2D clock is
wrong? Or more likely it tries to use the wrong IRQ, which never
arrives. So all the completion waits only bail out on a timeout.

G2D worked fine with the 3.3 kernel, so I believe fixing it should not
be too difficult for 3.4

[Patrick Wood]

It was using a hard-coded 46 as the IRQ instead of an abstraction (it needed to be offset by 32 on the A20, like everything else).  I submitted another patch.

Now all the speeds seem reasonable except for this one:

pixman blit performance: 9.59 MPix/s (38.37 MB/s)

There are no warnings from the driver, so one question is how can I tell if this test is successful but slow or just screwed up?

Pat

[Patrick Wood]

Does anyone know of a regression test for the G2D driver?  I've merged the sun7i G2D driver code (which has some optimizations and bug fixes for corner cases) with the sunxi driver, but have no idea how to test it for correctness.  sunxi_g2d_bench runs, and X11 is fine, but other than surfing for lots of images on the web, how can I verify that G2D is copying/scaling/rotating bits/bytes properly?

Pat

[Siarhei Siamashka]

On Thu, 12 Sep 2013 21:19:36 -0700 (PDT)
Patrick Wood <patric...@gmail.com> wrote:

> Does anyone know of a regression test for the G2D driver? I've merged the
> sun7i G2D driver code (which has some optimizations and bug fixes for
> corner cases) with the sunxi driver, but have no idea how to test it for
> correctness.

Most of the G2D functionality is currently only used in Android. So
nobody can tell if the sun7i fixes are doing anything good or not in
practice. Only https://github.com/amery/linux-sunxi/commit/7015bbb75ac57b
seems to be interesting. But it sets the undocumented bits of
G2D_SCAN_ORDER_REG register (also known as MP_IDMAGLBCTL_REG
in the documentation). It would be nice to know what kind of
practical problem is solves and how to interpret this magic number.

> sunxi_g2d_bench runs, and X11 is fine, but other than surfing
> for lots of images on the web, how can I verify that G2D is
> copying/scaling/rotating bits/bytes properly?

The only G2D part that is used for X11 right now is just the
"mixer_simple_blt" code. This is simple copy (with overlapping
source/destination support) and conversion between formats.

Even though this functionality is supposed to be very simple, I had
to fix two bugs in it (data corruption for RGB565 -> RGB565 copy and
redundant input DMA channel setup which was reducing performance).
I used the "sunxi_g2d_bench" test for the performance fix verification.
Another test was used for checking correctness, but I did not push it
to any public repository yet.