Closed kisvegabor closed 4 months ago
It is already supported in the current version of LVGL9. I have tested it on my side in an MDK project.
Using CMSIS-Pack is very simple; there is an auto-detection feature in LVGL9 cmsis-pack (as long as you installed the arm-2d cmsis-pack and the helium support is turned on in the compilation options, the LVGL9 Helium acceleration will be turned on automatically.)
For using cmake or makefile, to introduce arm-2d, please:
Bring Library/include
and Library/source
into the project.
Download the latest gcc compiler (13.2 rel1)/ or arm compiler 6. NOTE: GCC has feeble support for Helium in terms of performance. Arm recommends people using Arm Compiler 6 or LLVM to get the best performance. When using Arm Compiler 6, you can apply a community license.
Please use gnu11
If you have any questions, please let me know.
If you want, we can create a dedicated porting for the Renesas EK-RA8D1 board.
Hi @GorgonMeducer ,
Just want to confirm if the Please use gnu11
is required by lvgl
or arm-2d? LVGL should support gnu99 but not standard c99, there's an issue for lvgl to track it.
I'm sorry, I just saw that somehow the half of my initial comment was lost. In the lost part I explained that I copy pasted code from the Library folder but got many compiler errors.
I'm using E2 Studio from Renesas which is an Eclipse based IDE. I think CMSIS pack is not supported there as in MDK.
I'm using E2 Studio from Renesas which is an Eclipse based IDE. I think CMSIS pack is not supported there as in MDK.
You can add arm-2d manually as I mentioned in the previous answer. Renesas RA tool can generate MDK projects.
You can also use the template here:
https://github.com/GorgonMeducer/EK-RA8D1
Just want to confirm if the Please use gnu11 is required by lvgl or arm-2d?
Arm-2D. Using gnu99 should be OK.
I'm sorry, I just saw that somehow the half of my initial comment was lost. In the lost part I explained that I copy pasted code from the Library folder but got many compiler errors.
What kind of errors?
If it is about arm_2d_cfg.h
, you can copy one from the Library/Include/template/arm_2d_cfg.h
and place it in your application folder, and put a search path to this header file.
If it is about RTE_Components.h
, you can add an empty one and set the search path for it.
For GCC and LLVM, please add the following options:
-fms-extensions
-Wno-nonnull-compare
-Wno-unused-value
-Wno-maybe-uninitialized
-Wno-format
-Wno-unused-function
Here is the cmake: https://github.com/ARM-software/Arm-2D/blob/main/CMakeLists.txt
This is the part we would use for LVGL:
If you still have issue in compilation, we can have a zoom meeting for trouble shooting.
Thank you, Gabriel. I've tried again, and got a lot of errors similar to these:
I've added the CMSIS-DSP like this:
cc @jeremy-baker @renesasman
Can you please share with me a repo which contains this RA project? @kisvegabor
Which compiler do you use? If it is GCC, then which version of GCC do you use?
if using GCC, can you please kindly add the
-flax-vector-conversions
compile option ?
Thank you! -fms-extensions
and -flax-vector-conversions
really helped and it complied one step further. Now it with the errors below. I'm using gcc now, but I'm not sure what is the best way to change it to LLVM or AC6.
I've uploaded my E2 Studio project here.
Building file: ../ra/arm/CMSIS_5/CMSIS/DSP/Source/BasicMathFunctions/arm_xor_u8.c
/tmp/ccSZVsM9.s: Assembler messages:
/tmp/ccSZVsM9.s:158660: Error: garbage following instruction -- `vand q1,q1,s24'
/tmp/ccSZVsM9.s:158662: Error: garbage following instruction -- `vand q2,q2,s20'
/tmp/ccSZVsM9.s:158666: Error: garbage following instruction -- `vand q3,q3,s16'
/tmp/ccSZVsM9.s:158669: Error: lo register required -- `vstrh.32 q2,[ip],#8'
/tmp/ccSZVsM9.s:158840: Error: garbage following instruction -- `vand q1,q1,s20'
/tmp/ccSZVsM9.s:158842: Error: garbage following instruction -- `vand q2,q2,s16'
/tmp/ccSZVsM9.s:158844: Error: garbage following instruction -- `vand q3,q3,s20'
/tmp/ccSZVsM9.s:159328: Error: garbage following instruction -- `vand q1,q0,s24'
/tmp/ccSZVsM9.s:159336: Error: garbage following instruction -- `vand q0,q3,s20'
/tmp/ccSZVsM9.s:159340: Error: MVE vector register expected -- `vrmulh.u16 q2,q2,s16'
/tmp/ccSZVsM9.s:159341: Error: garbage following instruction -- `vand q1,q0,s24'
/tmp/ccSZVsM9.s:159342: Error: lo register required -- `vstrb.16 q2,[ip],#8'
/tmp/ccSZVsM9.s:159509: Error: garbage following instruction -- `vand q2,q0,s16'
/tmp/ccSZVsM9.s:159514: Error: garbage following instruction -- `vand q2,q0,s20'
/tmp/ccSZVsM9.s:159517: Error: garbage following instruction -- `vand q2,q0,s16'
/tmp/ccSZVsM9.s:159964: Error: cannot honor width suffix -- `add.n r0,#2'
/tmp/ccSZVsM9.s:159965: Error: cannot honor width suffix -- `add.n ip,#2'
/tmp/ccSZVsM9.s:160157: Error: cannot honor width suffix -- `add.n r0,#4'
/tmp/ccSZVsM9.s:160158: Error: cannot honor width suffix -- `add.n ip,#4'
/tmp/ccSZVsM9.s:160309: Error: lo register required -- `vldrb.u16 q0,[ip]'
/tmp/ccSZVsM9.s:160316: Error: lo register required -- `vldrb.u16 q2,[ip,#8]'
/tmp/ccSZVsM9.s:160318: Error: bad element type for instruction -- `vstrb.u16 q0,[ip],#8'
/tmp/ccSZVsM9.s:160322: Error: lo register required -- `vldrb.u16 q0,[ip,#8]'
/tmp/ccSZVsM9.s:160324: Error: bad element type for instruction -- `vstrb.u16 q2,[ip],#8'
/tmp/ccSZVsM9.s:160333: Error: lo register required -- `vldrb.u16 q0,[ip,#8]'
/tmp/ccSZVsM9.s:160334: Error: bad element type for instruction -- `vstrb.u16 q1,[ip],#8'
/tmp/ccSZVsM9.s:160453: Error: lo register required -- `vldrb.u16 q0,[ip]'
/tmp/ccSZVsM9.s:160460: Error: lo register required -- `vldrb.u16 q2,[ip,#8]'
/tmp/ccSZVsM9.s:160462: Error: invalid condition -- `vpt.u16 ne,q1,r10'
/tmp/ccSZVsM9.s:160463: Error: bad element type for instruction -- `vstrbt.u16 q0,[ip],#8'
/tmp/ccSZVsM9.s:160467: Error: lo register required -- `vldrb.u16 q0,[ip,#8]'
/tmp/ccSZVsM9.s:160469: Error: invalid condition -- `vpt.u16 ne,q1,r10'
/tmp/ccSZVsM9.s:160470: Error: bad element type for instruction -- `vstrbt.u16 q2,[ip],#8'
/tmp/ccSZVsM9.s:160479: Error: lo register required -- `vldrb.u16 q0,[ip,#8]'
/tmp/ccSZVsM9.s:160480: Error: invalid condition -- `vpt.u16 ne,q1,r10'
/tmp/ccSZVsM9.s:160481: Error: bad element type for instruction -- `vstrbt.u16 q2,[ip],#8'
/tmp/ccSZVsM9.s:160610: Error: invalid instruction shape -- `vmla.s16 q0,s12,r4'
/tmp/ccSZVsM9.s:160614: Error: bad element type for instruction -- `vstrb.u16 q0,[r2],#8'
/tmp/ccSZVsM9.s:160615: Error: invalid instruction shape -- `vmla.s16 q2,s12,r4'
/tmp/ccSZVsM9.s:160619: Error: bad element type for instruction -- `vstrb.u16 q2,[r2],#8'
/tmp/ccSZVsM9.s:160624: Error: invalid instruction shape -- `vmla.s16 q0,s12,r4'
/tmp/ccSZVsM9.s:160628: Error: bad element type for instruction -- `vstrb.u16 q2,[r2],#8'
/tmp/ccSZVsM9.s:160914: Error: garbage following instruction -- `vand q7,q4,s0'
/tmp/ccSZVsM9.s:160916: Error: garbage following instruction -- `vand q7,q5,s0'
/tmp/ccSZVsM9.s:160918: Error: garbage following instruction -- `vand q2,q2,s4'
/tmp/ccSZVsM9.s:160921: Error: garbage following instruction -- `vand q7,q7,s4'
/tmp/ccSZVsM9.s:160933: Error: garbage following instruction -- `vand q7,q4,s12'
/tmp/ccSZVsM9.s:161334: Error: garbage following instruction -- `vand q7,q4,s12'
/tmp/ccSZVsM9.s:161338: Error: garbage following instruction -- `vand q7,q2,s4'
/tmp/ccSZVsM9.s:161349: Error: garbage following instruction -- `vand q7,q4,s0'
/tmp/ccSZVsM9.s:161618: Error: garbage following instruction -- `vand q7,q4,s0'
/tmp/ccSZVsM9.s:161623: Error: garbage following instruction -- `vand q7,q5,s0'
/tmp/ccSZVsM9.s:161625: Error: garbage following instruction -- `vand q2,q2,s4'
/tmp/ccSZVsM9.s:161628: Error: garbage following instruction -- `vand q7,q7,s4'
/tmp/ccSZVsM9.s:161640: Error: garbage following instruction -- `vand q7,q4,s12'
/tmp/ccSZVsM9.s:161646: Error: garbage following instruction -- `vand q7,q4,s0'
/tmp/ccSZVsM9.s:161647: Error: invalid condition -- `vpt.u16 ne,q6,r9'
/tmp/ccSZVsM9.s:161922: Error: invalid instruction shape -- `vmov q2,s12'
/tmp/ccSZVsM9.s:162243: Error: garbage following instruction -- `vand q6,q4,s12'
/tmp/ccSZVsM9.s:162246: Error: garbage following instruction -- `vand q7,q5,s12'
/tmp/ccSZVsM9.s:162248: Error: garbage following instruction -- `vand q2,q2,s4'
/tmp/ccSZVsM9.s:162251: Error: garbage following instruction -- `vand q7,q7,s4'
/tmp/ccSZVsM9.s:162262: Error: garbage following instruction -- `vand q4,q7,s0'
/tmp/ccSZVsM9.s:162505: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:162508: Error: MVE vector register expected -- `vstrbt.u8 s4,[r1],#16'
/tmp/ccSZVsM9.s:162509: Error: instruction missing MVE vector predication code -- `letp lr,2b'
/tmp/ccSZVsM9.s:162567: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:162570: Error: MVE vector register expected -- `vstrbt.u8 s4,[r1],#16'
/tmp/ccSZVsM9.s:162571: Error: instruction missing MVE vector predication code -- `letp lr,2b'
/tmp/ccSZVsM9.s:162654: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:162657: Error: MVE vector register expected -- `vpsel q0,q0,s4'
/tmp/ccSZVsM9.s:162809: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:162865: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:162940: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:163115: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:163118: Error: MVE vector register expected -- `vstrbt.u8 s4,[r1],#16'
/tmp/ccSZVsM9.s:163119: Error: instruction missing MVE vector predication code -- `letp lr,2b'
/tmp/ccSZVsM9.s:163177: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:163180: Error: MVE vector register expected -- `vstrbt.u8 s4,[r1],#16'
/tmp/ccSZVsM9.s:163181: Error: instruction missing MVE vector predication code -- `letp lr,2b'
/tmp/ccSZVsM9.s:163264: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:163267: Error: MVE vector register expected -- `vpsel q0,q0,s4'
/tmp/ccSZVsM9.s:163458: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:163461: Error: MVE vector register expected -- `vpsel q0,s8,s4'
/tmp/ccSZVsM9.s:163513: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:163516: Error: MVE vector register expected -- `vpsel q0,s8,s4'
/tmp/ccSZVsM9.s:163597: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:163599: Error: MVE vector register expected -- `vpsel q0,s8,s4'
/tmp/ccSZVsM9.s:163781: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:163786: Error: MVE vector register expected -- `vpsel q1,s8,q1'
/tmp/ccSZVsM9.s:163838: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:163843: Error: MVE vector register expected -- `vpsel q1,s8,q1'
/tmp/ccSZVsM9.s:163924: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:163928: Error: MVE vector register expected -- `vpsel q1,s8,q1'
/tmp/ccSZVsM9.s:164108: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:164111: Error: MVE vector register expected -- `vstrht.u16 s4,[r1],#16'
/tmp/ccSZVsM9.s:164112: Error: instruction missing MVE vector predication code -- `letp lr,2b'
/tmp/ccSZVsM9.s:164170: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:164173: Error: MVE vector register expected -- `vstrht.u16 s4,[r1],#16'
/tmp/ccSZVsM9.s:164174: Error: instruction missing MVE vector predication code -- `letp lr,2b'
/tmp/ccSZVsM9.s:164260: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:164263: Error: MVE vector register expected -- `vpsel q0,q0,s4'
/tmp/ccSZVsM9.s:164417: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:164473: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:164551: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:164726: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:164729: Error: MVE vector register expected -- `vstrht.u16 s4,[r1],#16'
/tmp/ccSZVsM9.s:164730: Error: instruction missing MVE vector predication code -- `letp lr,2b'
/tmp/ccSZVsM9.s:164788: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:164791: Error: MVE vector register expected -- `vstrht.u16 s4,[r1],#16'
/tmp/ccSZVsM9.s:164792: Error: instruction missing MVE vector predication code -- `letp lr,2b'
/tmp/ccSZVsM9.s:164878: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:164881: Error: MVE vector register expected -- `vpsel q0,q0,s4'
/tmp/ccSZVsM9.s:165075: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:165078: Error: MVE vector register expected -- `vpsel q0,s8,s4'
/tmp/ccSZVsM9.s:165130: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:165133: Error: MVE vector register expected -- `vpsel q0,s8,s4'
/tmp/ccSZVsM9.s:165217: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:165219: Error: MVE vector register expected -- `vpsel q0,s8,s4'
/tmp/ccSZVsM9.s:165405: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:165410: Error: MVE vector register expected -- `vpsel q1,s8,q1'
/tmp/ccSZVsM9.s:165462: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:165467: Error: MVE vector register expected -- `vpsel q1,s8,q1'
/tmp/ccSZVsM9.s:165551: Error: garbage following instruction -- `vand q0,q0,s12'
/tmp/ccSZVsM9.s:165555: Error: MVE vector register expected -- `vpsel q1,s8,q1'
/tmp/ccSZVsM9.s:172441: Error: MVE vector register expected -- `vstrb.u8 s12,[r3],#16'
/tmp/ccSZVsM9.s:172543: Error: MVE vector register expected -- `vstrb.u8 s12,[ip],#16'
/tmp/ccSZVsM9.s:172645: Error: MVE vector register expected -- `vstrb.u8 s12,[ip],#16'
/tmp/ccSZVsM9.s:174176: Error: invalid instruction shape -- `vsub.i16 vecAlphaCompl,s16,q1'
/tmp/ccSZVsM9.s:174182: Error: bad element type for instruction -- `vstrb.u16 q3,[r4],#8'
/tmp/ccSZVsM9.s:175934: Error: MVE vector register expected -- `vmulh.u8 q1,q1,s16'
/tmp/ccSZVsM9.s:175939: Error: invalid instruction shape -- `vsub.i16 vecAlphaCompl,s20,q1'
/tmp/ccSZVsM9.s:175944: Error: MVE vector register expected -- `vmulh.u8 q1,q1,s16'
/tmp/ccSZVsM9.s:175946: Error: bad element type for instruction -- `vstrb.u16 q3,[r4],#8'
/tmp/ccSZVsM9.s:176122: Error: lo register required -- `vldrb.u16 q1,[ip,s16]'
/tmp/ccSZVsM9.s:176128: Error: invalid instruction shape -- `vsub.i16 vecAlphaCompl,s20,q1'
/tmp/ccSZVsM9.s:176132: Error: lo register required -- `vldrb.u16 q1,[ip,s16]'
/tmp/ccSZVsM9.s:176134: Error: bad element type for instruction -- `vstrb.u16 q3,[r3],#8'
/tmp/ccSZVsM9.s:176327: Error: lo register required -- `vldrb.u16 q1,[ip,s16]'
/tmp/ccSZVsM9.s:176328: Error: MVE vector register expected -- `vmulh.u8 q1,q1,s24'
/tmp/ccSZVsM9.s:176334: Error: invalid instruction shape -- `vsub.i16 vecAlphaCompl,s20,q1'
/tmp/ccSZVsM9.s:176338: Error: lo register required -- `vldrb.u16 q1,[ip,s16]'
/tmp/ccSZVsM9.s:176339: Error: MVE vector register expected -- `vmulh.u8 q1,q1,s24'
/tmp/ccSZVsM9.s:176341: Error: bad element type for instruction -- `vstrb.u16 q3,[r3],#8'
/tmp/ccSZVsM9.s:182104: Error: lo register required -- `vldrb.u16 q1,[ip,s12]'
/tmp/ccSZVsM9.s:182132: Error: lo register required -- `vldrb.u16 q1,[ip,s12]'
/tmp/ccSZVsM9.s:182576: Error: lo register required -- `vldrb.u16 q1,[ip,s12]'
/tmp/ccSZVsM9.s:182606: Error: lo register required -- `vldrb.u16 q1,[ip,s12]'
/tmp/ccSZVsM9.s:184779: Error: invalid instruction shape -- `vsub.i16 vecAlphaCompl,s20,q1'
/tmp/ccSZVsM9.s:184784: Error: bad element type for instruction -- `vstrb.u16 q3,[r5,s16]'
/tmp/ccSZVsM9.s:184789: Error: bad element type for instruction -- `vstrb.u16 q3,[r1,s16]'
/tmp/ccSZVsM9.s:184797: Error: bad element type for instruction -- `vstrb.u16 q3,[r4,s16]'
/tmp/ccSZVsM9.s:187146: Error: MVE vector register expected -- `vmulh.u8 q1,q1,s16'
/tmp/ccSZVsM9.s:187151: Error: invalid instruction shape -- `vsub.i16 vecAlphaCompl,s24,q1'
/tmp/ccSZVsM9.s:187156: Error: bad element type for instruction -- `vstrb.u16 q3,[r5,s20]'
/tmp/ccSZVsM9.s:187161: Error: bad element type for instruction -- `vstrb.u16 q3,[r1,s20]'
/tmp/ccSZVsM9.s:187168: Error: MVE vector register expected -- `vmulh.u8 q1,q1,s16'
/tmp/ccSZVsM9.s:187170: Error: bad element type for instruction -- `vstrb.u16 q3,[r4,s20]'
/tmp/ccSZVsM9.s:187383: Error: lo register required -- `vldrb.u16 q1,[ip,s16]'
/tmp/ccSZVsM9.s:187388: Error: invalid instruction shape -- `vsub.i16 vecAlphaCompl,s20,q1'
/tmp/ccSZVsM9.s:187393: Error: bad element type for instruction -- `vstrb.u16 q3,[r4,s16]'
/tmp/ccSZVsM9.s:187398: Error: bad element type for instruction -- `vstrb.u16 q3,[r3,s16]'
/tmp/ccSZVsM9.s:187404: Error: lo register required -- `vldrb.u16 q1,[ip,s16]'
/tmp/ccSZVsM9.s:187406: Error: bad element type for instruction -- `vstrb.u16 q3,[r1,s16]'
/tmp/ccSZVsM9.s:187637: Error: lo register required -- `vldrb.u16 q1,[ip,s20]'
/tmp/ccSZVsM9.s:187638: Error: MVE vector register expected -- `vmulh.u8 q1,q1,s16'
/tmp/ccSZVsM9.s:187643: Error: invalid instruction shape -- `vsub.i16 vecAlphaCompl,s24,q1'
/tmp/ccSZVsM9.s:187648: Error: bad element type for instruction -- `vstrb.u16 q3,[r4,s20]'
/tmp/ccSZVsM9.s:187653: Error: bad element type for instruction -- `vstrb.u16 q3,[r3,s20]'
/tmp/ccSZVsM9.s:187659: Error: lo register required -- `vldrb.u16 q1,[ip,s20]'
/tmp/ccSZVsM9.s:187660: Error: MVE vector register expected -- `vmulh.u8 q1,q1,s16'
/tmp/ccSZVsM9.s:187662: Error: bad element type for instruction -- `vstrb.u16 q3,[r1,s20]'
make: *** [src/Library/Source/subdir.mk:57: src/Library/Source/arm_2d_helium.o] Error 1
"make -r -j16 all" terminated with exit code 2. Build might be incomplete.
Thank you for the update and for the E2 Studio project. Can you please kindly confirm that you are using GCC version >= 13 ?
Yes, it's 13.2.1
I have run the benchmark on EK-RA8D1, here is the performance result:
I think I have found some performance bottlenecks in my lv_draw_sw_arm2d.h
I need to fix them.
Very impressive. I'll rerun my tests tomorrow and share the result.
What is your LV_DEF_REFR_PERIOD
? I think it's a good idea to set it to 33 to see the CPU usage too.
BTW, I measure the CPU usage from the idle task.
Very impressive.
I haven't enabled the Dave2D. And this probably is just the power of Cortex-M85 running at 480MHz.
I'll rerun my tests tomorrow and share the result.
The compilation issue you encountered might not be an easy one; we suspect this might be a known issue of the arm gcc compiler. (no conclusion yet).
We are working on this; if it is confirmed to be a GCC helium support issue, I probably need to disable GCC helium support in arm-2d until it is fixed. Using LLVM or Arm Compiler 6 is the recommended solution for now.
What is your LV_DEF_REFR_PERIOD? I think it's a good idea to set it to 33 to see the CPU usage too.
I am running in bare-metal env. The LV_DEF_REFR_PERIOD
is 16.
I am working on fixing the performance bottlenecks. Will have a try for LV_DEF_REFR_PERIOD
33
later.
Thank you Gabriel.
@jeremy-baker @renesasman Can we use LLVM or AC6 in E2 Studio?
We are working on a workaround for GCC Helium in arm-2d library. @kisvegabor I will let you know the result.
By the way, have you tried to run LVGL9 directly (without helium acceleration) in EK-RA8D1 board? What the benchmark result did you see?
Hi @kisvegabor, we have applied a temporary fix to arm-2d gcc support. Please get the latest version from the arm-2d repo and try again.
Please also use the latest arm-2d LVGL driver for solving a compilation issue #5466
I think it's a good idea to set it to 33 to see the CPU usage too.
@kisvegabor
This is what you wanted (i.e. LV_DEF_REFR_PERIOD
is 33ms):
We are getting very close. Now it fails with:
/home/kisvegabor/e2_studio/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: ./src/Library/Source/arm_2d_helium.o: in function `__arm_2d_impl_gray8_colour_filling_with_opacity':
/home/kisvegabor/e2_studio/workspace/lv_renesas/lv_ek_ra8d1/Debug/../src/Library/Source/arm_2d_helium.c:756:(.text.__arm_2d_impl_gray8_colour_filling_with_opacity+0x90): undefined reference to `__ARM_undef'
/home/kisvegabor/e2_studio/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: ./src/Library/Source/arm_2d_helium.o: in function `__arm_2d_impl_cccn888_tile_copy_opacity':
/home/kisvegabor/e2_studio/workspace/lv_renesas/lv_ek_ra8d1/Debug/../src/Library/Source/arm_2d_helium.c:1412:(.text.__arm_2d_impl_cccn888_tile_copy_opacity+0x8c): undefined reference to `__ARM_undef'
collect2: error: ld returned 1 exit status
make: *** [makefile:312: lv_ek_ra8d1.elf] Error 1
But I can't find __ARM_undef
anywhere.
That's crazy! The rendering time is half for you.
I din't understand these though:
For multiple labels with 5 ms render time the CPU usage should be 5/33 = 15% For screen sized text with 30 ms render time, the FPS should be 33.
It seems we are still missing something from the benchmark. Probably the waiting for flushing.
I have this benchmark results (CPU usage is coming from the idle task).
SW only:
Dave2D:
But I can't find
__ARM_undef
anywhere.
This is strange, I didn't introduce such thing called __ARM_undef
... I need to check
Update: it's an issue with the GCC compiler, i.e. an unsolved MVE polymorphic variant. We have to apply a patch to arm-2d for this.
Although the FPS and flush-time are strange to read, the render time is quite stable for now. I am using it for performance evaluation only.
Based on this. It looks like Helium acceleration gets a good result (the benefits of Arm Compiler 6 probably). I am really happy about this.
I am really happy about this.
It's really amazing! Congratulations!
In fact, I have addressed some performance issues in arm-2d, that's why I temporarily blocked the acceleration for some conditions. I plan to fix the issue in v1.1.6 and it might boost LVGL9 further.
The fix for __ARM_undef
has been pushed to arm-2d repo, please try again. @kisvegabor
It's working now, thank you. However with gcc it's really just a little bit faster than software rendering.
I've also found 2 rendering issues:
I can add photos tomorrow
However with gcc it's really just a little bit faster than software rendering.
@kisvegabor Yes, it depends on the pixel size, for RGB565, it is more obvious. This is because the vector size of Helium is only 128bits. For rgb565, it is capable to handle 8 pixels per vector and for RGBX888, it is only capable to handle 4 pixels per vector.
The Compiler also plays an important role. As I mentioned before, GCC has a very pool support for Helium in terms of performance, this is verified many times in different application realms. That's why I encourage you to try the LLVM which is the recommended free compiler from Arm.
I'll look into it and report back.
Here you can see the rendering issues I've mentioned:
Here you can see the rendering issues I've mentioned.
With Helium (arm-2d) acceleration?
I have just re-run the helium accelerated benchmark, I cannot replicate the issue you encountered.
Yes, it's with Helium. Maybe it's related to GCC as well.
This is what I have seen:
With GCC or LLVM?
Arm Compiler 6. @kisvegabor
Now I can use LLVM, it builds without Arm2D but when I add it I get:
../src/Source/arm_2d_helium.c:655:14: error: invalid instruction, any one of the following would fix this:
655 | " vldrb.u16 q1, [%[pSource]], #8 \n"
| ^
These are the extra compiler settings:
Do you know what could be the problem?
Hi @kisvegabor,
Please make sure you get the latest LLVM from Arm's repository:
https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm/releases
If the issue is still there, try to define the macro USE_MVE_INTRINSICS
in your project.
By the way, please select GNU99 as the language standard.
This is the latest benchmark result (with the fix you have applied):
The flushing time now is accurate. Thank you! đź‘Ť
I'm using LLVMEmbeddedToolchainForArm-17.0.1-Linux-x86_64
as according to Renesas this version is supported officially.
Adding USE_MVE_INTRINSICS
solved the issue, thank you!
There were an other error too but I could solve it by renaming __va_list
to va_list
.
Building file: ../ra/tes/dave2d/src/dave_memory.c
../src/Source/arm_2d.c:265:13: error: unknown type name '__va_list'; did you mean 'va_list'?
265 | __va_list ap;
| ^~~~~~~~~
| va_list
I can test the performance tomorrow.
BTW, I wonder if Arm2D can help with Cortex-M33 too.
Arm2D can help with Cortex-M33 too.
In General, Cortex-M33 has no Helium acceleration, so arm-2d brings no benefit. But since Cortex-M33 support ACI, If the target processor implements any ACI for 2D processing, arm-2d can help.
I'm using LLVMEmbeddedToolchainForArm-17.0.1-Linux-x86_64 as according to Renesas this version is supported officially.
Yes, this is the recommended one.
Still no luck :slightly_frowning_face: Yesterday I've just compiled Arm2D, but today when I enabled it in lv_conf.h the build process just stuck without any error. I saw that clang-17 is using a full CPU core. When I canceled the build I got a lot of similar logs:
../src/lvgl/src/draw/sw/blend/helium/lv_blend_helium.S:452:1: note: while in macro instantiation
export_set color, rgb565, 0, 16, normal
^
<instantiation>:1:1: error: invalid instruction
vsri.8 reg&_R, reg&_G, #5
^
<instantiation>:10:5: note: while in macro instantiation
conv_888_to_565 reg
^
<instantiation>:66:5: note: while in macro instantiation
ldst ld, dst_bpp, DST, D, S, 1, 0
^
<instantiation>:15:5: note: while in macro instantiation
blend_line src_bpp, dst_bpp, mask, 2, mode
^
<instantiation>:5:5: note: while in macro instantiation
blender src_bpp, dst_bpp, mask, opa, mode
^
<instantiation>:2:5: note: while in macro instantiation
export lv_&src&_blend_to_&dst&_helium, src_bpp, dst_bpp, 0, 0, mode
^
../src/lvgl/src/draw/sw/blend/helium/lv_blend_helium.S:452:1: note: while in macro instantiation
export_set color, rgb565, 0, 16, normal
^
<instantiation>:2:5: error: invalid instruction
vshr.u8 reg&_G, reg&_G, #2
^
<instantiation>:10:5: note: while in macro instantiation
conv_888_to_565 reg
^
<instantiation>:66:5: note: while in macro instantiation
ldst ld, dst_bpp, DST, D, S, 1, 0
^
<instantiation>:15:5: note: while in macro instantiation
blend_line src_bpp, dst_bpp, mask, 2, mode
^
<instantiation>:5:5: note: while in macro instantiation
blender src_bpp, dst_bpp, mask, opa, mode
^
<instantiation>:2:5: note: while in macro instantiation
export lv_&src&_blend_to_&dst&_helium, src_bpp, dst_bpp, 0, 0, mode
^
../src/lvgl/src/draw/sw/blend/helium/lv_blend_helium.S:452:1: note: while in macro instantiation
export_set color, rgb565, 0, 16, normal
^
<instantiation>:3:5: error: invalid instruction
vshr.u8 reg&_B, reg&_B, #3
^
<instantiation>:10:5: note: while in macro instantiation
conv_888_to_565 reg
^
<instantiation>:66:5: note: while in macro instantiation
ldst ld, dst_bpp, DST, D, S, 1, 0
^
It seems like a compiler bug to me. Does this say anything to you?
No idea at all… I am taking vacation, might check it later
@kisvegabor where is the reproducer? We need to check it. Thank you.
First of all happy new year!
Thank you for looking into it Gabriel. Here is my E2 Studio project: https://github.com/lvgl/lv_renesas/tree/llvm-with-arm2d
Hello, Would you have access to the offending compiler command line leading to the errors you reported ?
I can extract only the compiler flags from E2 Studio:
-std=c99 -flax-vector-conversions -fms-extensions -fshort-enums -fno-unroll-loops -I"/home/kisvegabor/projects/lvgl/e2_studio-workspace/lv_renesas/lv_ek_ra8d1/generate" -I"/home/kisvegabor/projects/lvgl/e2_studio-workspace/lv_renesas/lv_ek_ra8d1/src" -I"." -I"/home/kisvegabor/projects/lvgl/e2_studio-workspace/lv_renesas/lv_ek_ra8d1/ra/fsp/inc" -I"/home/kisvegabor/projects/lvgl/e2_studio-workspace/lv_renesas/lv_ek_ra8d1/ra/fsp/inc/api" -I"/home/kisvegabor/projects/lvgl/e2_studio-workspace/lv_renesas/lv_ek_ra8d1/ra/fsp/inc/instances" -I"/home/kisvegabor/projects/lvgl/e2_studio-workspace/lv_renesas/lv_ek_ra8d1/ra/fsp/src/rm_freertos_port" -I"/home/kisvegabor/projects/lvgl/e2_studio-workspace/lv_renesas/lv_ek_ra8d1/ra/aws/FreeRTOS/FreeRTOS/Source/include" -I"/home/kisvegabor/projects/lvgl/e2_studio-workspace/lv_renesas/lv_ek_ra8d1/ra/arm/CMSIS_5/CMSIS/Core/Include" -I"/home/kisvegabor/projects/lvgl/e2_studio-workspace/lv_renesas/lv_ek_ra8d1/ra_gen" -I"/home/kisvegabor/projects/lvgl/e2_studio-workspace/lv_renesas/lv_ek_ra8d1/ra_cfg/fsp_cfg/bsp" -I"/home/kisvegabor/projects/lvgl/e2_studio-workspace/lv_renesas/lv_ek_ra8d1/ra_cfg/fsp_cfg" -I"/home/kisvegabor/projects/lvgl/e2_studio-workspace/lv_renesas/lv_ek_ra8d1/ra_cfg/aws" -I"/home/kisvegabor/projects/lvgl/e2_studio-workspace/lv_renesas/lv_ek_ra8d1/ra/tes/dave2d/inc" -I"/home/kisvegabor/projects/lvgl/e2_studio-workspace/lv_renesas/lv_ek_ra8d1/src/lvgl" -D_RENESAS_RA_ -D_RA_CORE=CM85 -D_RA_ORDINAL=1
I could reproduce a similar issue when I enabled only LV_USE_DRAW_SW_ASM LV_DRAW_SW_ASM_HELIUM
. It adds some pure ASM snippets independent of Arm2D. So I it has something to do with the compiler.
It appears you are using c99 rather than gnu99 but this should have nothing to do with the issue you encountered.
Hi @kisvegabor This compilation issue has been addressed and a solution is proposed in the discussion of #5702
This compilation issue has been addressed
Was it addressed in the compiler or shall be addressed as described in #5702?
@GorgonMeducer could you send me the benckmark results with the latest LVGL, AC6 and Arm2D? I'm creating a presentation for the Embedded World and other conferences and I would like to show case how fast the rendering can be without GPU too.
@kisvegabor No problem. Will do it tomorrow.
Introduce the problem
Renesas RA8D1 has Cortex-M85 so it should be able utilize Arm2D Helium support.
I've tried to integrate
Proposal
No response