BorreF wrote: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