g2d and gal2d of i.MX6(YoctoBSP)

[宗標廖]

Hello Community

Patches for weston1.9 in linux BSP 4.1.15_1.1.0  and 4.1.15_2.0.0 are different.In L4.1.15_2.0.0, it added the following patches for westion1.9. And what these patches do is to use G2D API to replace Gal2D API.

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

0008-MGS-1668-xwld-System-can-not-boot-up-to-desktop.patch 
0009-MGS-1284-xwld-Re-implement-weston-2d-renderer-with-p.patch 
0010-MGS-1284-1-xwld-Re-implement-weston-2d-renderer-with.patch 
0011-MGS-1724-xwld-G2D-compositor-build-failed-in-slevk-b.patch 
0012-MGS-1783-xwld-Add-clone-mode-support-for-multi-displ.patch 
0013-MGS-1945-Use-common-API-to-support-G2d-compositor.patch 
0014-MGS-1987-Get-stride-from-the-FB-buffe.patch

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

My question:

1)G2D uses CPU to render and Gal2d uses GPU2D to render, is it right?

2)Comments of the 0009 patcth says 'Fix the errors in multi display mode.', so could you tell me what errors are fixed by these patches?

3)Can I apply these patches to L4.1.15_1.2.0 directly? Or need to do something else(If yes, what should I do?).

Thank you!

ZongbiaoLiao

[ponguru_s]

Hi there,

I'm using i.MX 6Q board with Yocto 4.1.15-2.0.0. I want to achieve graphic acceleration for Qt5 based applications using weston 1.9.0. I've tried running the Qt5 Cinematic Experience application with eglfs and wayland platforms, where I got only 19fps of frame rate. I've tried with the viv_sample applications also. As far as I understood these are with OpenGL support. But, I want Qt5 based applications with the same performance.

1. I want an improved framerate.

2. How to understand the patches mentioned above and apply them?

PS: I want an improvement in performance for Qt5 based custom applications.

Thanks. :smileyhappy:

[gusarambula]

Hello Zongbiao Liao,

1) Both G2D and Gal2d use the GPU2D, the difference is on how the libraries are handled as Gal2d has the libraries integrated. The newer Vivante drivers have moved from Gal2d to G2D.

2) There is no further publicly available information on what there multi display mode errors fixed by this patch (0009-MGS-1284) are. My apologies for the inconvenience.

3) Yes, you should be able to apply these patches directly. The patches are dependent on the Linux Kernel and Vivante driver.

I hope this information helps!

Regards,

[宗標廖]

gusarambula‌

Please answer my questions.

Thank you!

[gusarambula]

Hello Zongbiao Liao,

My mistake! Yes, the move was on the opposite direction from what I originally wrote, it should read from G2D to Gal2d.

Unfortunately we don’t have details on what specific changes were made from Vivante drivers from 5.0.11.p8.4 to 5.0.11.p8.6 but from nomenclature it should be a relatively small update. My recommendation would be using your current proven configuration as you already applied the latest drivers and since Kernel on both BSPs are 4.1.15 so it makes sense that the patches were applied correctly.

Regards,

[宗標廖]

Hello gusarambula

Thank you for your reply!

1)The newer Vivante drivers have moved from G2D to Gal2d.

What does this mean?

Vivante drivers for L4.1.15_2.0.0 is 5.0.11.p8.6 and for L4.1.15_1.2.0 is 5.0.11.p8.4, so it seems that the newer Vivante drivers have moved from Gal2D to G2D.Is it right?

2)My customer is now working on L4.1.15_1.2.0 with Weston graphics.And they found that the view rendered by gal2d flashes and this can be reproduced with the attached binaries on i.MX6DL Sabre boards according to the following steps.

A)killall weston

B)export FB_MULTI_BUFFER=2

C)openvt.kbd -s -- weston --log=/dev/console --use-gal2d=1 --idle-time=0

D)./weston-simple-shm &

E)./weston-simple-egl

After they applied those patches(0008-MGS ~ 0014-MGS) to L4.1.15_1.2.0, the problem did not reproduced on both i.MX6 sabre boards and their customized board.

Besides,after they applied those patches(0008-MGS ~ 0014-MGS) to L4.1.15_1.2.0, they also resolved the following error.

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

 [galcore]: AXI BUS ERROR

**************************

***   GPU STATE DUMP   ***

**************************

  axi      = 0x00000200

  idle     = 0x7FFFFFF8

FE not idle

DE not idle

PE not idle

  DMA appears to be stuck at this address:

0xFFFDA7F8

  dmaLow   = 0x48000000

  dmaHigh  = 0x00000701

  dmaState = 0x00000915

command state       = 21 (PAR_STALL_ST)

command DMA state   = 1 (CMD_START_ST)

command fetch state = 2 (FET_VALID_ST)

DMA request state   = 0 (REQ_IDLE_ST)

cal state           = 0 (CAL_IDLE_ST)

VE request state    = 0 (VER_IDLE_ST)

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

As you said The patches are dependent on the Linux Kernel and Vivante driver.

Althougth, the problems are resolved, my customer wants to know whether is it reliable and whether should they upgrade Vivante drivers to 5.0.11.p8.6 for L4.1.15_1.2.0.

Best Regards,

ZongbiaoLiao