Call for review: fixing OpenVG wrapper library reliability

[ajstarks]

This note is a call for review by Raspberry Pi OpenVG, and EGL experts to try to track reliability bugs in my OpenVG library:

https://github.com/ajstarks/openvg

Some users of the library have reported crashes and hangs especially under load where graphics shapes are created repeatedly, or during long-running operations.

My intention is to find out if the fault is in my library or the underlying code shipped with the Raspi.

I have reopened Bug 22: https://github.com/ajstarks/openvg/issues/22
Please post programs, reproducers, discussions, etc. there.

Many thanks.

[BorreF]

Good initiative!

I've been using OpenVG since the launch of the first Pi and GPU memory corruption was an issue then and now (Jessie Lite - RPi-2). My approach is similar to yours with a thin C++ wrapper library (including vector fonts) on top of the OpenVG API. Errors show up as damaged fonts (overwritten within the GPU), OUT_OF_MEMORY_ERROR (irrespective of GPU memory available) or the application will deadlock against the OpenVG library support threads. Applications may run fine for hours and sometimes even weeks, but will eventually go bad.

Reducing GPU dynamic memory allocation (pre-allocate paths and so-forth) helps, but is only practical for the most trivial applications. It's hard to convince others (myself included) there are bugs in the graphics core, but after countless of hours debugging these issues, I'm sure this is the case.

My conclusion is clear - the graphics core / memory management (as used by the OpenVG API) is buggy.

[ajstarks]

Perhaps I should file an official bug against the Raspi kernel/firmware repo.
Is there an existing bug for this issue?

[ajstarks]

Looks like there is an existing bug: https://github.com/raspberrypi/linux/issues/943
Anyone care to comment on this bug with a pointer to a reproducer?

[blackshard83]

Good initiative!

I've been using OpenVG since the launch of the first Pi and GPU memory corruption was an issue then and now (Jessie Lite - RPi-2). My approach is similar to yours with a thin C++ wrapper library (including vector fonts) on top of the OpenVG API. Errors show up as damaged fonts (overwritten within the GPU), OUT_OF_MEMORY_ERROR (irrespective of GPU memory available) or the application will deadlock against the OpenVG library support threads. Applications may run fine for hours and sometimes even weeks, but will eventually go bad.

Reducing GPU dynamic memory allocation (pre-allocate paths and so-forth) helps, but is only practical for the most trivial applications. It's hard to convince others (myself included) there are bugs in the graphics core, but after countless of hours debugging these issues, I'm sure this is the case.

My conclusion is clear - the graphics core / memory management (as used by the OpenVG API) is buggy.

Never had problems with memory corruption with the GPU, even after running days and days of digital signage software (mine) that does modest use of openvg (fonts, simple shapes, images, transforms, blending, ...) and plays h264 videos through omxplayer. The only sublte bug I can recall of was vgDrawGlyph/vgDrawGlyphs not handling paintModes parameter with vgImage based glyphs: it always draws, even if paintModes is 0

[Thaddy]

I just noticed - when updating my old code to reflect Pi2-3 - that the current binary is far less stable than the initial one.
I can query information but the real demo (my pascal sourcecode) doesn't work anymore. It works with the old code and the provided pascal binary in my original package for the demo simply runs on all types of Pi. I'll have to investigate further. But I will narrow it down to the changes. Because I suspect a memory issue.

[Thaddy]

I found out that I forgot to update a structure.
A new version of the FreePascal bindings will be available either today or tomorrow.
There are some intermittant hangs, like with the C code, but overall quite stable.