Forums - Adreno Profiler: Scrubber Output VS Actual Output

6 posts / 0 new
Last post
Adreno Profiler: Scrubber Output VS Actual Output
jkircher90
Join Date: 31 May 11
Posts: 5
Posted: Mon, 2012-04-16 01:10

Hello

I am using the latest version of Adreno Profiler to analyze a rendering which does a shadow mapping technique. The output I see on my phone is quite different than what I see in the scrubber. This is very interesting to me because the output of the scrubber is actually giving me the desired shadow effect, but the output on the phone is far from correct. 

I assume the scrubber is using my laptops graphics card to reproduce the frame. In which case my graphics card is an ATI Mobility Radeon HD 4250. The phone I am using is an EVO 3D which I beleive has an Adreno 220.

What would the reason for this difference in output be? I would like to think it might be a precision issue, but it seems the rendering on the phone is decidely incorrect, not just less precise. Are there some OpenGL or GLSL functions that the Scrubber would use which would be implemented differently on the HD 4250 in comparison to the Adreno 220?

I can attach pictures, api calls, shaders, etc, if needed.

Best

  • Up0
  • Down0
jkircher90
Join Date: 31 May 11
Posts: 5
Posted: Wed, 2012-04-18 00:05

So, I was able to make the shadowing technique work on my phone. I'll explain what I had to change. Keep in mind, this worked all along in the scrubber.

The shader is performing a percentage closer filtering technique (PCF) for soft shadows. So, I was using a for-loop to do 9 texture look ups in a locally declared array of texture coordinates (vec2). For whatever reason, I decided to unroll the for-loop and get rid of the texture coordinate array entirely... This did the trick. It gave me the expected rendering. Based on the change I made to get it working, I believe the issue was reading from the array of vec2 texture coordinates. For some reason, the values were not correct coming out of the array.  This seems strange to me if that was indeed the issue. 

And as I said before, the original shader with the texture coordinate array was working for the scrubber all along, giving the desired effect even when the phone was not. It makes me think there is something amiss in the glsl implementation on the phone. 

 

 

 

 

  • Up0
  • Down0
dastle@qualcomm.com (not verified)
Posted: Wed, 2012-06-13 12:02

Hi Brian,

I'm glad you were able to find a workaround. It sounds like you may have encountered a driver bug, though it's hard to say with certainty. Profiler does use our OpenGL ES emulator, which wraps the desktop OpenGL 2 implementation, so what you see there may differ substantially to what's going on in our hardware/driver.

  • Up0
  • Down0
Flamaros
Join Date: 6 May 14
Posts: 17
Posted: Wed, 2014-05-07 02:00

I have the same issue, it's really perturbing. There is no way to force Profiler collecting results of draw calls from the device instead of the simulated driver running on our PC?

I am not sure it's a driver issue, cause I have the same graphical issue on different devices (different graphical chip : adreno and powervr,...) The only device don't produce the issue is the Nvidia shield that why I suspect an issue with tiling based GPU.

  • Up0
  • Down0
Flamaros
Join Date: 6 May 14
Posts: 17
Posted: Wed, 2014-05-07 03:00

I found my issues, we need had glFlush before using a FBO in a shader.

Is it normal? May exist a way to determine more precisely when we need had glFlush to integrate this correctly in our engine?

  • Up0
  • Down0
Flamaros
Join Date: 6 May 14
Posts: 17
Posted: Wed, 2014-05-07 06:08

When I run the profiler, I have some messages I don't know printed by my application :

W/Adreno-GSL( 3688): <os_lib_map:1302>: os_lib_map error: dlopen failed: library "/libOpenVG.so" not found, on '/libOpenVG.so'

E/Adreno-EGL( 3688): <egliLoadLibrary:602>: OpenVG11 lib failed to load

W/Adreno-EGL( 3688): <qeglDrvAPI_eglQuerySurface:1934>: EGL_BAD_ALLOC

  • Up0
  • Down0
or Register

Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries (“Qualcomm”). The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.