-
Notifications
You must be signed in to change notification settings - Fork 1.7k
[OpenVG] Providing capacity hints during font creation increases GPU memory fragmentation #406
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I noticed that providing hints even for simple paths creates "vg_stem" objects. I use the VGU library to generate simple paths and I was providing some hints in vgCreatePath() |
@reufer @paolosabatino can you please provide a testcase for this issue? Or has it been resolved by the firmware update on 31 Mar 2015 ? |
I will be able to check in a couple of weeks, for the moment I can't say anything about. |
my test case is the code mentioned above. since I now convert the required glyphs on demand instead of the entire font, this is not an issue anymore for me. but if you want me to test, I could do that after my holidays... |
Ok, sorry for "couple of weeks" becoming 15 months... by the way here there is a little demo which create paths providing hints via vgCreatePath() and then appending data with vgAppendPathData() simulating glyph loading. There is lot of boilerplate code to create the dispmanx, egl and openvg things, like a real case scenario. |
@Ruffio do you have any time to check this issue? It looks to me the free space is a small storage reservation area left there by the firmware when a new path is created. Providing capacity hints by the client should avoid the storage reservation, shouldn't it? |
I'm not a developer, so I can't help you :-( I'm just pinging people so issues that are unnecessary open get closed. |
According OpenVG Spec V1.1, providing capacity hints when creating OpenVG fonts should reduce GPU memory fragmentation. I do this for vgCreateFont() by providing the total number of glyphs and for vgCreatePath() by setting the correct number of segments and coordinates. Giving these numbers to OpenVG improves the total conversion time, but surprisingly seems to fragment the GPU memory more than setting them to 0.
The fragmentation is expressed by a lot of free segments shown between the VG-Path printed with "vcdbg reloc". There's also a huge number of "vg_stem" objects, which looks a bit suspect to me.
The code can be found here: http://projects.vdr-developer.org/git/vdr-plugin-rpihddevice.git/tree/ovgosd.c?id=35462805b9f876c38cfa681623b9cd426028a2c7#n184
The text was updated successfully, but these errors were encountered: