Hi,
Our GLES3 game released on GooglePlay is experiencing some specific crashes on a wide variety of devices that all happen to have either an Adreno 540 gpu (the most crashes) or an Adreno 530 gpu (fewer crashes).
Most of the crashes are on Android 8.0.0 for the 540 and Android 9 for the 530.
The crash is always reported in A5xContext::HwPatchForDirectRendering(), but the callstack, issued from a gl command can be different.
I am putting 2 examples of the callstack below.
I am suspecting this is a driver issue (given the game runs well on other adreno and non adreno gpus) and perhaps caused from a driver memory leak (just guessing as all callstack always end with the same GetMemory -> Flush -> ProcessAndSubmitRendering -> HwPatchForDirectRendering - Kaboom)
Can someone with driver knowledge confirm/infirm the issue?
Is the call to HwPatchForDirectRendering supposed to happen normaly, or is it more a situation like : "doh! no memory left, let's try to process what's been queued so far so we can free some mem?"
Any help or comment would be most welcome.
Thanks.
A5xContext::HwPatchForDirectRendering(EsxRenderBucket*, EsxLinkedList*, unsigned int)
EsxContext::ProcessAndSubmitRendering(EsxFlushReason)
EsxCmdMgr::Flush(EsxFlushReason)
EsxMemPoolGeneral::GetMemory(unsigned long long, EsxMemType, unsigned int, EsxMemPoolGeneralAllocation*)
EsxGfxMem::Init(EsxGfxMemCreateData*)
EsxGfxMem::Create(EsxGfxMemCreateData*)
EsxResource::PackRange(EsxContext*, EsxSubResourceRange const*)
EsxResource::RepackRange(EsxContext*, EsxSubResourceRange const*)
EsxResource::PreparePackedGpuAccess(EsxContext*, EsxSubResourceRange const*)
EsxTextureObject::PreRenderProcessing(EsxContext*)
EsxContext::ValidateProgramTexUnitBoundObjs(EsxProgram*, int)
EsxContext::ValidateTexUnitBoundObjs()
EsxContext::ValidateGfxState(EsxDrawDescriptor const*)
EsxContext::DrawElementsInstanced(EsxPrimType, unsigned int, EsxPixType, void const*, unsigned int, int)
EsxGlApiParamValidate::GlDrawElements(EsxDispatch*, unsigned int, int, unsigned int, void const*)
glDrawElements
A5xContext::HwPatchForDirectRendering(EsxRenderBucket*, EsxLinkedList*, unsigned int)
EsxContext::ProcessAndSubmitRendering(EsxFlushReason)
EsxCmdMgr::Flush(EsxFlushReason)
EsxMemPoolGeneral::GetMemory(unsigned long long, EsxMemType, unsigned int, EsxMemPoolGeneralAllocation*)
EsxGfxMem::Init(EsxGfxMemCreateData*)
EsxGfxMem::Create(EsxGfxMemCreateData*)
EsxResource::PackRange(EsxContext*, EsxSubResourceRange const*)
EsxResource::RepackRange(EsxContext*, EsxSubResourceRange const*)
EsxResource::PreparePackedGpuAccess(EsxContext*, EsxSubResourceRange const*)
EsxContext::UpdateRenderingLayout(EsxFramebufferObject*)
EsxContext::BucketProcessingSetup()
EsxContext::Clear(unsigned int, unsigned int, unsigned int, EsxClearValues*)
EsxGlApiParamValidate::GlClear(EsxDispatch*, unsigned int)
Can you provide the game name that is causing the crash?
Can you provide the game name that is causing the crash?
Same here.
We're developing a 3d game using Unity, Now I'm debugging this problem, hope you may provide any help.
crash on "HwPatchForDirectRendering " is mostly reproduced.
yet I got another new stack overflow crash:
Similar issue here: Adreno 530 on OnePlus 3T.
The game we're developing (with Unity) keeps crashing with this stack log:
I would venture to guess that this crash is simply caused by an OOM issue.
Most of our "gles driver" bugs have vanished after we fixed a number of memory issues: general memory leak, graphics resource memory leaks and other transcient low memory situation (like from temporary gpu geo/texture bake using temporary but large render resources).
We still have a few very rare GLES bugs (caught on Crashlytics from the retail clients) that I suspect are real driver bugs on some uncommon hardware.
To be noted that a gles driver running out of memory may report a different callstack based on the driver itself / exact gpu.
This can be misleading one into thinking the bug is specific to some driver when it is more "how the driver" reacts to that low/no memory situations caused by the game code that might differ.
It could be, but I find difficult to explain why another similar smartphone (OnePlus One), with Adreno 330 and half RAM and VRAM, has never crashed in today's tests, nor experienced any issues, while the OnePlus 3T, performing identical operations during the same time frame, has already crashed a dozen times.
Well I can only speak of our own experience. I am not excluding that some driver bugs exist (and we've seen some in the past).
We've also had a number of devices claiming to support certain GLES extensions yet misbehave with them (like SeparateShaderObject, VertexArrayObject, ...)
It is also not rare that some bug occurs on .0 version of Android and stops occuring after that (7.0, 8.0 only bugs), leading me to think some OS/Driver bugs was fixed between .0 and .1.
But it is often that different GPU run different back end rendering on the game side, based on available hardware performance.
For example, we had a situation with high end GPU running the deferred lit renderer while lower end GPU would run the forward lit renderer.
The first had a leak on the GBuffer so we had a bunch of low memory induced driver crashes only on devices with high end GPU.
You might also have different backend based on the GLES level (2.0, 3.0, 3.1...) using different GLES features...
For sure, these kind of driver crash bugs are a huge pain to deal with and can be an immense time sink.
So checking the fundamental (mem usage, mem leaks), disabling some rendeirng features and testing again (assuming you can somewhat reproduce the bug) can perhaps teach you something.