标签:产生 bak 绘制 end sel 渲染 -- oppo ioc
在 PBR&IBL 的开发过程中,在 Linux 验证程序运行正常后,移植到 Android 平台,发现程序 crash. 程序的逻辑是,响应页面某按钮点击事件,在gl线程加载渲染模型以及做PBR和IBL的预计算工作,之后渲染模型以及场景。程序 crash 的地点在 IBL 的所有预计算结束后,在第一次渲染调用之前,而且与此同时没有任何的 OpenGL ERROR. 具体导致 crash 的函数是 SurfaceTexture.updateTexImage()
这个 SurfaceTexture 是从摄像头获取数据的,与主要的预计算以及渲染没有任何关系,看起来十分诡异。错误信息如下:
Adreno-GSL: <gsl_ldd_control:548>: ioctl fd 74 code (IOCTL_KGSL_DEVICE_WAITTIMESTAMP_CTXTID) failed: errno 35 Resource deadlock would occur
ioctl fd 60 code 0xc040094a (IOCTL_KGSL_GPU_COMMAND) failed: errno 35 Resource deadlock would occur
syncForReleaseLocked: error creating EGL fence: 0x3003
at android.graphics.SurfaceTexture.nativeUpdateTexImage(Native Method)
错误信息看了一头雾水吧。
调试:首先,Android 程序在没有 PBR 时运行一切正常,肯定是新增的代码导致的问题,而出错之前做的事情就是 IBL 的预计算,常规计算,主要分四个部分:
在调试中发现,如果只进行前面两个部分的计算,也就是天空盒纹理和 IBL irradiance map 的计算,后面的跳过,那么程序运行正常。(因为原先程序的出错是还没有走到 PBR 绘制的 shader 就退出了,所以不生成这几个纹理不影响,只是说后面的 shader 运行出错,产生 GL error, 最终屏幕显示的模型是黑色的)
另外,如果将预计算部分的调用时机改变,从gl渲染中间改到在onSurfaceChanged()
函数里面调用,也就是说在初始的渲染之前就做完所有的准备工作,然后在绘制每一帧,这样同样没有出错。
根据上述两个表现,基本猜测出错的原因是预计算部分耗费了太长的时间(具体数据见下),导致渲染线程卡死,驱动程序认为此时是 Resource deadlock
状态,但是我认为这个实际上是一个 timeout 的状态。
解决问题的思路是缩短预计算的时间。根据具体数据,单就上面的第3点就花费了整体一半的时间,达到了惊人的2.3秒,主要原因还是此处计算量太大:5级的 mipmap 的 cubemap, 解决方案是将此处的纹理大小设小一些,最后我设置的是 64x64 的 cubemap, 程序运行正常不再崩溃,不过耗时还是很长,需要1.5秒左右。
Time Profile:
----------------------------------------------------------------------------
|
|||||||||||||||||||||||||||||||||||||||||| 4278 Total PBR pre-baker time |
|
||||||||||||||||||||||||||||||||||||||| 3905 Shader running process time |
|
||||||||||||||||||||||| 2368 Only IBL Part 1 PrefilterMap process time |
|
---------------------------------------------------------------------------
Time in ms
Running on Oppo R17 Pro
(CPU: Qualcomm Snapdragon 710, 64-bit, octa-core processor 2.2GHz, GPU: Adreno 616)
Android GL deadlock timeout error
标签:产生 bak 绘制 end sel 渲染 -- oppo ioc
原文地址:https://www.cnblogs.com/psklf/p/10774096.html