Greetings,
I have just switched from Mali 2.2.1 to PowerVR SDK 3.5 gles libraries and suddenly my application crashes inside the draw functions (glDrawArrays, glDrawElements). A typical callstack looks like this:
atioglxx.dll!309dfa99() Unbekannt
[Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für atioglxx.dll]
atioglxx.dll!30928934() Unbekannt
atioglxx.dll!3198dc1a() Unbekannt
atioglxx.dll!31064272() Unbekannt
atioglxx.dll!31021aac() Unbekannt
libGLESv2.dll!02ba20bd() Unbekannt
atioglxx.dll!30b895e3() Unbekannt
atioglxx.dll!308ab4de() Unbekannt
libGLESv2.dll!02c0def7() Unbekannt
libGLESv2.dll!02bf867f() Unbekannt
libGLESv2.dll!02bc40b1() Unbekannt
libGLESv2.dll!02baa636() Unbekannt
libGLESv2.dll!02bc62d9() Unbekannt
libGLESv2.dll!02bc68b8() Unbekannt
libGLESv2.dll!02bda9bc() Unbekannt
< I had to cut off the rest for privacy reasons, it’s a glDrawElements call>
The arrays I try to draw have up to 50000 vertices.
The system is Window 7. The Visual Studio Version is 2012 with Update 4 and RelWithDebugInfo build mode. The graphics driver is Catalyst-Version 14.12 AMD Catalyst Omega Software.
Do you have any idea?
Regards
Hi Edgar,
From the information you have provided, I can’t see what the cause of the problem is. If you attach a binary that reproduces the issue to a confidential support ticket, we can investigate the issue for you: https://pvrsupport.imgtec.com/new-ticket
Well that will take some time.
By the way: Often the callstack includes a HeapFree.
Regards
Edgar, are you using client arrays? If so, watch your process’s CPU memory consumption in the resource monitor. What do you see when it crashes?
(The theory I’m exploring: The PVRVFrame emulation of client arrays triggers unbounded memory growth on ATI GL drivers. We see that here on our ATI GPUs. This may or may not explain what you’re seeing.)
You mean GL_VERTEX_ARRAY? No, Only VBOs.
And memory consumption of the application is < 400 mb.
No, I mean rendering with no buffer bound to GL_ARRAY_BUFFER (and/or GL_ELEMENT_ARRAY_BUFFER if using glDrawElements*) and providing a CPU memory buffer pointer for one or more vertex attribute arrays via glVertexAttrib*Pointer (and/or the pointer argument of glDrawElements*).
I used glGetIntegerv with GL_ARRAY_BUFFER and GL_ELEMENT_ARRAY_BUFFER to verify that both are set. The pointer argument of glDrawElements is supposed to be an index in this case right? Anything else I should look out for?
Oh, and the VertexAttribPointer is set too.
Edgar, it sounds like you are not using client arrays, so we can scratch that as a possible cause of your draw call crashes.
Besides getting the ImgTech folks a trace with your crash, you might make very sure that you don’t have some “rogue” vertex attributes you’ve inadvertently left enabled and/or have indices in your DrawElements calls which access outside the bounds of any of the vertex attribute array buffers (either of which would cause bogus reads in the driver and a possible crash). You also might check for GL errors in your code.
For a test I replaced all the glDrawElements calls by glDrawArrays calls with otherwise exactly the same input. Looks funny but it doesn’t crash.
I might have successfully reproduced the problem with the ChameleonMan example from the SDK:
C:\Imagination\PowerVR_Graphics\PowerVR_SDK\SDK_3.4\Examples\Advanced\ChameleonMan\OGLES2\
atioglxx.dll!68b709d9() Unbekannt
[Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für atioglxx.dll]
atioglxx.dll!68ab7844() Unbekannt
atioglxx.dll!69c0e086() Unbekannt
atioglxx.dll!69c0e00b() Unbekannt
atioglxx.dll!6935342c() Unbekannt
atioglxx.dll!69c0e086() Unbekannt
atioglxx.dll!6928f78e() Unbekannt
atioglxx.dll!6929034d() Unbekannt
atioglxx.dll!692906ac() Unbekannt
atioglxx.dll!69207f83() Unbekannt
atioglxx.dll!693c7953() Unbekannt
atioglxx.dll!693c2904() Unbekannt
atioglxx.dll!68d1de03() Unbekannt
atioglxx.dll!68a3f0ce() Unbekannt
libGLESv2.dll!0f6fdef7() Unbekannt
libGLESv2.dll!0f6e867f() Unbekannt
libGLESv2.dll!0f6b40b1() Unbekannt
libGLESv2.dll!0f69a636() Unbekannt
libGLESv2.dll!0f6b62d9() Unbekannt
libGLESv2.dll!0f6b68b8() Unbekannt
libGLESv2.dll!0f6ca9bc() Unbekannt
> OGLES2ChameleonMan.exe!OGLES2ChameleonMan::DrawSkinnedMesh(int i32NodeIndex) Zeile 837 C++
OGLES2ChameleonMan.exe!OGLES2ChameleonMan::RenderScene() Zeile 675 C++
OGLES2ChameleonMan.exe!PVRShellInit::Run() Zeile 1617 C++
OGLES2ChameleonMan.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Zeile 804 C++
OGLES2ChameleonMan.exe!__tmainCRTStartup() Zeile 238 C
OGLES2ChameleonMan.exe!WinMainCRTStartup() Zeile 164 C
kernel32.dll!@BaseThreadInitThunk@12() Unbekannt
ntdll.dll!___RtlUserThreadStart@8() Unbekannt
ntdll.dll!__RtlUserThreadStart@8() Unbekannt
[blockquote]Any more ideas?[/blockquote]
[blockquote]The pointer argument of glDrawElements is supposed to be an index in this case right?
[/blockquote]
- No, it’s a byte offset.
Other suggestions:
2. Update ATI GL driver
3. Check for GL errors
4. Capture a PVRTrace of your call, and look for clues in the trace with PVRTraceGUI
5. Run a memory debugger (e.g. Dr. Memory)
If DrawArrays works and DrawElements, and you “think” you are accessing the same vertex range, suspect a problem with your index list.
- Check all of the indices and verify that they are in the same range of vertices as you’re telling glDrawArrays about
- If you’re using the primitive restart index, ensure that primitive restart is enabled
- Verify the buffer you have bound to GL_ELEMENT_ARRAY is the one containing your indices
- Read the indices back from the buffer and verify that that all of them match what you think you uploaded
I issued a ticket now regarding the crash in the sdk example. Hopefully someone will look at it soon.
Hi Edgar,
I’ve reproduced the issue on a Windows 7 x86-64 machine with a Radeon HD 6670 (Catalyst driver version 15.7.1) using the 3.5 SDK’s OGLES2 ChameleonMan demo. The PVRVFrame lead is investigating the issue now to isolate the source of the problem and figure out if we can workaround the issue in our emulator.
The VFrame lead has confirmed the issue is due to a Catalyst driver bug. We’ve implemented a workaround for our upcoming 4.0 SDK release. If you would like to try a pre-release version of our emulator with a fix, let me know and I’ll upload a package to our support portal.
Hello,
although the crash with the chameleon man example has been resolved for me, it still persists with my main application.
Callstack below the glDrawElements call:
atioglxx.dll!692f0739() Unbekannt
[Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für atioglxx.dll]
atioglxx.dll!69237844() Unbekannt
atioglxx.dll!692a8d7b() Unbekannt
atioglxx.dll!6949de03() Unbekannt
atioglxx.dll!691bf0ce() Unbekannt
libGLESv2.dll!0450d0a7() Unbekannt
libGLESv2.dll!044f7e2f() Unbekannt
libGLESv2.dll!044bedd1() Unbekannt
libGLESv2.dll!044a30ab() Unbekannt
libGLESv2.dll!044c0d36() Unbekannt
libGLESv2.dll!0450d0a7() Unbekannt
libGLESv2.dll!044c0c8e() Unbekannt
libGLESv2.dll!044e355b() Unbekannt
libGLESv2.dll!044e34dd() Unbekannt
libGLESv2.dll!044c126f() Unbekannt
libGLESv2.dll!044d835c() Unbekannt
The libraries used are definitively those from the 4.0 sdk release.
I checked the number of vertices and indices multiple times, everything seems to be correct.
Note: The glDrawElements makes use of unsigned short indices.
Regards
