I’ve got an application running successfully on the PandaBoard under certain configurations. However, in other configurations I get the following error messages (the last two are repeated multiple times). Does anyone know what these messages would be a symptom of so I know where to look in my code track down the problem?
PVR:(Warning): DoKickTA: Creating ZS buffer for overflow [1584, /sgxif.c]
PVR:(Error): PVRSRVAllocDeviceMem: Error 1 returned [934, /bridged_pvr_glue.c]
PVR:(Warning): CreateTextureMemory: Reaping active textures [761, /texmgmt.c]
When you say certain configurations, what are you changing? e.g. drivers, kernel, OS etc
Thanks,
Joe
No nothing like that. The configuration changes are within my code alone. For example, let’s say I’ve got databases ‘D1’ and ‘D2’ and I’ve got some post-processing effects ‘E’ designed to render the view in monochrome w/ noise like a CCTV. If I render D1 or D2 w/o E, I don’t get the errors. If I render D1 w/ E, I don’t get the errors. But if I render D2 w/ E, I do get the errors.
Note that w/ the effects I’m doing a glCopyTexSubImage2D to get the first pass into a texture so that I can generate the monochrome image. That’s the only thing that comes to mind that is different in the “with effects” configuration from an OpenGL perspective.
I’m still getting the first DoKickTA warning, but the other two errors do not appear now. It must have been related to something else I fixed.
Hi Deep,
Is there any reason you’ve chosen to use glCopyTexSubImage2D() instead of rendering to an FBO with a texture bound? glCopyTexSubImage2D() is a more costly operation.
The DoKickTA warning suggests that the driver has had to kick vertex processing work because the driver is running out of memory. Although the driver is able to complete the render correctly, it would be best to determine why your application is causing this limit to be hit. It’s usually occurs when a very large amount of vertex data has been submitted in a render. If you reduce the amount of vertices you are submitting to the driver (e.g. cull objects outside of the view frustum, reduce the poly count of your meshes etc), then you should be able to avoid this warning.
Have you tried using PVRTune to profile your target device?
Thanks,
Joe
Yes, I realize the glCopyTexSubImage2D is a more costly operation. If I were writing an application from scratch I’d use the approach you suggest. Unfortunately, this is a port of a rather large existing code base and it would take a lot of work to change things.
Can you elaborate on what “a very large amount of vertex data has been submitted in a render” means? Is there a specific limit on the number of vertices or the size of a VBO? We are already performing frustum culling, however, the size of the geometry may be larger than is typical for embedded / mobile devices.
Note that I do also get the following errors:
PVR:(Error): Index offset 13402 is larger than index buffer size 768 [1340, /drawvarray.c]
PVR:(Error): Index offset 107246 is larger than index buffer size 768 [1340, /drawvarray.c]
PVR:(Error): Index offset 69832 is larger than index buffer size 768 [1340, /drawvarray.c]
Setting breakpoints in the code, I can’t find any place where this condition is true, so I’m not sure if these numbers are accurate, but maybe they’re the symptom of something else. Can you shed any light on what might be causing this?
No, I have not used PVRTune. Note that I’m running on an ARM-based system. Do you have a build for PVRTune on ARM?
Hi Deep,
Sorry for the delayed response.
PVRTune is implemented with a client-server model. The client (PVRTune) runs on x86 Windows, Mac or Linux machines. The server (PVRPerfServer) can be used on a number of target device configurations, including ARM Android and Linux. For more information, please see our PVRTune description page and the PVRTune User Manual on our documentation page.
Appendix A of the PVRTune User Manual provides a description of all of the counters in the tool. Counters such as “On-screen vertices per frame” should help you understand how the number of vertices processed affect your render’s performance.
The number of vertices you can submit before this occurs is dependant on your target device’s driver configuration. It’s up to our customers to configure the size of the driver’s buffers.
I’m unsure what the cause of the driver error is. Can you use PVRTrace and send a recording of your application to our devtech@imgtec.com address? This will allow us to inspect your GL calls and replay the recording on other platforms to try and reproduce the issue.
Thanks,
Joe
