RPi 4 OpenVG Support?

[g8gkq]

I support about 400 users worldwide using an open source Digital Amateur Television application suite which runs on a Raspberry Pi 3B or 3B+ with a touchscreen https://github.com/BritishAmateurTelevi ... /portsdown.

The "Portsdown" suite of programs run on Stretch Lite (and will migrate to Buster Lite) and make extensive use of OpenVG for the touchscreen control. Reading the RPi 4 spec and this forum, I get the impression that the RPi 4 does not support OpenVG.

For the avoidance of doubt, please could 6by9 or jamesh state whether the RPi 4 supports OpenVG?

If not, is there any alternative way ahead apart from telling prospective users not to buy an RPi 4?

Thanks

Dave, G8GKQ

[jamesh]

Legacy OpenVG is not supported on the Pi4.

Sorry.

[SimonHyde]

OpenVG is not supported on the Pi4.

Sorry.

Is there any plans/thoughts that it might be supported in the future? Or will the Pi4 never support it?

[jamesh]

OpenVG is not supported on the Pi4.

Sorry.

Is there any plans/thoughts that it might be supported in the future? Or will the Pi4 never support it?

Probably never. The OpenVG group was disbanded in 2011 so its rather an outdated API.

[incognitum]

If not, is there any alternative way

Recall there are some semi-accelerated software OpenVG implementations, that call OpenGL to do the actual work.
Tried if your software works with any of those?

[dom]

I found this: https://www.amanithvg.com/
but it's not open source and may require licensing (depending on usage).

Looks like libs are available for arm. But it's not quite a plug in replacement.
It renders VG to a memory buffer, which you presumably display as a GL texture.

[6by9]

https://en.m.wikipedia.org/wiki/OpenVG

On May 1, 2009 Zack Rusin from Tungsten Graphics added OpenVG state tracker to Mesa, which enables SVG vector graphics to be hardware accelerated by any Gallium3D-based driver. It was removed again in Mesa 10.6 on June 15, 2015.

On September, 2011 OpenVG working group decided not to make any regular meeting for further standardization. However, working group decided to continue maintenance and promotion of OpenVG 1.1 specification

Implementations
On OpenGL, OpenGL ES

Hooked OpenVG - Hooked Wireless OpenVG complete implementation of both OpenVG 1.01 and OpenVG 1.1, implemented on top of OpenGL ES, and is fully conformant. Claim “It leverages proprietary technology from Hooked in the areas of tessellation and triangulation for shapes and curve.” First released in Feb/2008.[18]
HuOne AlexVG-forge - An OpenVG engine which is 2D vector graphic standard by using the graphic chip that supports OpenGL/OpenGL ES.
Mazatech AmanithVG GLE - commercial. Built on top of OpenGL 1.1+ and OpenGL ES 1.x. Claim “achieving better performance than software rasterizers in terms of high resolution animations and complex special effects (transparencies, fading, realtime rotoscaling and many others).”[19]
MonkVG (only "OpenVG like")[20] - open source (BSD)
ShivaVG - open source (LGPL)

[incognitum]

I found this: https://www.amanithvg.com/
but it's not open source and may require licensing (depending on usage).

LGPL licensed on top of standard OpenGL: https://github.com/ileben/ShivaVG
BSD licensed on top of OpenGL ES: https://github.com/micahpearlman/MonkVG

Neither are full implementations, but may be good enough.

[Gavinmc42]

Does the VC6 still have the GL/NV/VG modes?
VG would still work in baremetal, if the new mmu can be figured out?

There does not seem much difference between the VC4 and V3D code apart from that.
No idea if the startx4.elf is needed for OpenVG?

[SteveA]

I have just seen this post and have come across the same problem after buying a couple of RPI4 to start replacing the older RPI units in equipment. I use a derivative of A J Starks OpenVG library (runs over openvg) and unfortunately all projects have now come to a complete standstill.

All applications are written in C and I wondered if anyone had come up with a solution or workaround. Is there a method of implementing the openvg libs in the RPI4 or has this excellent and working graphics lib been written off completely without first inserting a substitute to handle text, fonts, lines, panels, etc.

Any tips or pointers gratefully received.
Thanks, Steve

[jamesh]

From above

LGPL licensed on top of standard OpenGL: https://github.com/ileben/ShivaVG
BSD licensed on top of OpenGL ES: https://github.com/micahpearlman/MonkVG

[jdonald]

There’s another good topic about this: https://www.raspberrypi.org/forums/view ... p?t=247586

Mainly suggesting nanovg. At first I thought it wasn’t a solution because the name sounds similar to nanosvg (CPU-only parser). It turns out nanovg has a GPU rendering backend. You’d have to modify your OpenVG programs to talk to a different API, but nanovg may be feature-complete unlike the two shims listed above.

[Gavinmc42]

FlightGear works on Pi4's.
it uses ShivaVG to convert SVG to OpenVG on OpenGL

OpenVG has been removed from Mesa in version 10.6.

Hmm wonder how it did it?
Grab the old code?

[petabeda]

Legacy OpenVG is not supported on the Pi4.

Sorry.

Please, can you explain, how you know that?

I have Raspberry Pi 4 Model B (rasbian kernel 4.19.81-v7l+) (bullseye/sid) with this, Broadcom closed source, start4x.elf version:

Code: Select all

vcos_build_version     = d1843b82bb73db6d518b8fda432261e47a45a512 (clean)
vcos_build_branch      = bcm2711_2
vcos_build_date        = Mar 26 2020
vcos_build_time        = 17:19:59
vcos_build_user        = dom
vcos_build_hostname    = buildbot

When I run this (linked with -pthread -lrt -lvchostif -lvchiq_arm -lvcos -lbcm_host -lbrcmEGL -lbrcmGLESv2)

Code: Select all

    VGPath testPath = VG_INVALID_HANDLE;
    VGubyte cmds[] = {VG_MOVE_TO_ABS,VG_LINE_TO_ABS,VG_CLOSE_PATH};
    VGfloat data[] = {0.0f,0.0f,1.0f,1.0f};
    int segs = 2;

    testPath = vgCreatePath(
        VG_PATH_FORMAT_STANDARD,
        VG_PATH_DATATYPE_F,
        1.0f,
        0.0f,
        0,
        0,
        VG_PATH_CAPABILITY_APPEND_TO | VG_PATH_CAPABILITY_PATH_LENGTH);
    
    vgAppendPathData(testPath, segs, cmds, data);
    int callCount = 0;
    while (active) {
        int numSegments = vgGetParameteri(testPath,VG_PATH_NUM_SEGMENTS);
        float pathLength = vgPathLength(testPath,0,numSegments);
        fprintf(stderr,"#%d numSegments: %d pathLength: %.2f eglerr: 0x%04x vgerr: 0x%04x\n",callCount, numSegments, pathLength, eglGetError(), vgGetError());
        vgAppendPathData(testPath, segs, cmds, data);
        callCount++;
        usleep(10000);
    }

at "legacy" EGL context on dispmanx_window EGL surface, it will prints this:

Code: Select all

#0 numSegments: 2 pathLength: 1.41 eglerr: 0x3000 vgerr: 0x0000
#1 numSegments: 4 pathLength: 2.83 eglerr: 0x3000 vgerr: 0x0000
#2 numSegments: 6 pathLength: 4.24 eglerr: 0x3000 vgerr: 0x0000
#3 numSegments: 8 pathLength: 5.66 eglerr: 0x3000 vgerr: 0x0000
#4 numSegments: 10 pathLength: 7.07 eglerr: 0x3000 vgerr: 0x0000
#5 numSegments: 12 pathLength: 8.49 eglerr: 0x3000 vgerr: 0x0000
#6 numSegments: 14 pathLength: 9.90 eglerr: 0x3000 vgerr: 0x0000
#7 numSegments: 16 pathLength: 11.31 eglerr: 0x3000 vgerr: 0x0000
#8 numSegments: 18 pathLength: 12.73 eglerr: 0x3000 vgerr: 0x0000
#9 numSegments: 20 pathLength: 14.14 eglerr: 0x3000 vgerr: 0x0000
#10 numSegments: 22 pathLength: 15.56 eglerr: 0x3000 vgerr: 0x0000
#11 numSegments: 24 pathLength: 16.97 eglerr: 0x3000 vgerr: 0x0000
#12 numSegments: 26 pathLength: 18.38 eglerr: 0x3000 vgerr: 0x0000
#13 numSegments: 28 pathLength: 19.80 eglerr: 0x3000 vgerr: 0x0000
#14 numSegments: 30 pathLength: 21.21 eglerr: 0x3000 vgerr: 0x0000
#15 numSegments: 32 pathLength: 22.63 eglerr: 0x3000 vgerr: 0x0000
#16 numSegments: 34 pathLength: 24.04 eglerr: 0x3000 vgerr: 0x0000
#17 numSegments: 36 pathLength: 25.46 eglerr: 0x3000 vgerr: 0x0000
#18 numSegments: 38 pathLength: 26.87 eglerr: 0x3000 vgerr: 0x0000
#19 numSegments: 40 pathLength: 28.28 eglerr: 0x3000 vgerr: 0x0000
#20 numSegments: 42 pathLength: 29.70 eglerr: 0x3000 vgerr: 0x0000
#21 numSegments: 44 pathLength: 31.11 eglerr: 0x3000 vgerr: 0x0000
#22 numSegments: 46 pathLength: 32.53 eglerr: 0x3000 vgerr: 0x0000
#23 numSegments: 48 pathLength: 33.94 eglerr: 0x3000 vgerr: 0x0000
#24 numSegments: 50 pathLength: 35.36 eglerr: 0x3000 vgerr: 0x0000
#25 numSegments: 52 pathLength: 36.77 eglerr: 0x3000 vgerr: 0x0000

If I look to vg client implementation source at
https://github.com/raspberrypi/userland ... g_client.c
I get, that value of numSegments is calculated on ARM side, but
vgPathLength is doing RPC to vchiq !

Run

Code: Select all

vcdbg reloc

and you will see:

Code: Select all

'VG_PATH_T.segments'

'VG_PATH_T.coords'

'KHRN_IMAGE_T.storage'
'KHRN_IMAGE_T.storage'
'KHRN_IMAGE_T.storage'
'EGL_SERVER_SURFACE_T'
'VG_SERVER_STATE_T'
'KHRN_MAP_T.storage'
'khdispatch_readahead'
'khdispatch_workspace'
'khrn_hw_null_render'
'KHRN_MAP_64_T.storage'
'KHRN_MAP_T.storage'
'KHRN_PID_MAP_T.storage'
'KHRN_MAP_T.storage'
'KHRN_MAP_T.storage'
'KHRN_MAP_T.storage'
'dispmanx_resource'
'ILCS VC buffer pool'
'ARM FB'
'audioplus_tmp_buf'
'camera fast alloc arena'

Really is OpenVG not supported? Where is length of path calculated if OpenVG is not supported?
vchiq will freeze after egSwapBuffers or vgClear...it is possible to ask Broadcom people directly?

Take care!

[liz]

See the little green flag on the right of JamesH's post? And his sig? They both mention that he's an engineer at Raspberry Pi - that's how he knows!

[6by9]

If running on a Pi4 then do NOT link against -lbrcmEGL -lbrcmGLESv2, or try to use the calls in userland interface/khronos.
Those are the vchiq shims that send the requests over to the firmware, and the firmware on Pi4 has no idea what to do with them.

Use mesa-dev and the standard GL libraries.

[petabeda]

Thank you so much for answer.

So, where exactly the length of path is being calculated? On the ARM side?

[6by9]

https://en.wikipedia.org/wiki/OpenVG

On May 1, 2009 Rusin added OpenVG state tracker to Mesa, which enables SVG vector graphics to be hardware accelerated by any Gallium3D-based driver. It was removed again in Mesa 10.6 on June 15, 2015.

As you've already been told, OpenVG is not supported on the Pi4, at least not in the standard libraries.

If you read the rest of this thread you will find links to various other alternative implementations on top of OpenGL.

[petabeda]

Please believe me, but I already know that all. Trust me.

So, where exactly the length of VG path is being calculated on the Raspberry Pi 4 Model B? On the ARM side or VC side?

Can you please tell me or it is a secret? After I will be silenced forever.

And I know, that you are all engineers, but you don't answering what I am questioning at all.

Sincerely,

Petr Spilka

[jamesh]

Please believe me, but I already know that all. Trust me.

So, where exactly the length of VG path is being calculated on the Raspberry Pi 4 Model B? On the ARM side or VC side?

Can you please tell me or it is a secret? After I will be silenced forever.

And I know, that you are all engineers, but you don't answering what I am questioning at all.

Sincerely,

Petr Spilka

No idea. There's no VG hardware on the the VC6, so might be done by software either on the ARM or on the VC6 itself.

[6by9]

Please believe me, but I already know that all. Trust me.

So, where exactly the length of VG path is being calculated on the Raspberry Pi 4 Model B? On the ARM side or VC side?

Can you please tell me or it is a secret? After I will be silenced forever.

And I know, that you are all engineers, but you don't answering what I am questioning at all.

On a Pi4 it isn't computed at all. There is no OpenVG implementation on which to compute it.
If you attempt to use the userland interface/khronos calls then they will fail when it attempts to make the VCHIQ calls, and there are no ARM side implementations other than the alternatives that have already been linked to above.

On a Pi0-3 I believe it's computed on the VPU (VideoCore processor).
You can see for yourself the extent of the ARM side code of vgCreatePath at https://github.com/raspberrypi/userland ... nt.c#L2766, and for vgPathLength at https://github.com/raspberrypi/userland ... nt.c#L3292. They're both near immediate RPC calls.

(NB The followup will be a patch that just makes sure that any VG or GLES RPC call across to the firmware just fails early. There is absolutely no way that the firmware interface for OpenVG can be made to work on a Pi4).

[petabeda]

OK. I am sorry for my bad english, but at my first post, I mentioned that I am compiling that code on Rasberry Pi 4 Model B.
And it do not fail.

vgPathLength is called OK and returns total path length (RPC is called).

vcdbg reloc
prints allocated vg entities and

vcdbg vchiqdump
states increased after each vgPathLength call

Could you please look to my first post?

What am I not getting?

Output of
strings start4x.elf | grep -i VG
looks very promising

With Love,

Petr

[jamesh]

As above, there is NO OpenVG HW on the Pi4. So, if you are getting an accurate result, it's possible that that part of the API is implemented on the vector units in the GPU, rather than being implemented in HW. Since some of the libraries are still linked in to the firmware, hence the strings result (they will be removed eventually), it's possible that the implementation for that specific API is still there.

But this does not mean that OpenVG works, as I presume you have found. Some specific API's might, but not as a whole.

You need to use one of the libraries referenced above, not the Broadcom one.