Closed Bug 908033 Opened 11 years ago Closed 2 years ago

[META] Render profiler suite

Categories

(Core :: Graphics, defect, P3)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: u459114, Unassigned)

References

Details

(Keywords: meta)

Have a profiling suite to address rendering performance issue 1. GPU bound or CPU bound GPU bound - pixel shader bound/ vertex shader bound/ draw call bound. For more detailed GPU benchmark, we should enable platfrom profiler, such as Andreno or PerfHud. CPU bound: has a high level semantic to tell user that where our render process spend time on. Such as layout/ raterize image/ buffer lock. 2. Conent process bound or compositor bound We need to tell where is the problem of slow rendering. At content side or compositor side. *: One biggest challenge for this task is how to keep these tool work while rendering flow change so freqenctly in gecko.
Depends on: 907109
Depends on: 909176
Depends on: 909182
Depends on: 909192
Depends on: 909204
Depends on: 909205
To identify bottleneck in rendering pipeline, we should address which stage is the bottleneck first. 1. Application stage 2. Geometry stage 3. Rasterizer stage Except webGL app, most app is block at stage #1 or #3. We should have tools to figure out the following perf issue. a. Understand the bottleneck is in #1 or in #3. b. Block in #1: block in which sub stage, restyle/ generate display list c. Block in #3: block in which sub stage, rasterizer/ pixel shader/ merge. Any suggestion is welcome. Which kind of tool that you wish to have, which kind of bottleneck which you spend a lot of time because lack to tool.
Component: Video/Audio → Graphics
We might show a small icon in screen to represent what mode we have entered. "T" means tiny texture mode and "F" means compositor force update mode.
(In reply to Jerry Shih[:jerry] from comment #2) > We might show a small icon in screen to represent what mode we have entered. > "T" means tiny texture mode and "F" means compositor force update mode. We need document for this.
Not sure this is the right place, but I could really use a tool that logs bad usage of opengl/gralloc APIs. Anything that could warn me about stuff like "hey you are trying to upload this texture while we are still rendering the previous frame asynchronously, forcing synchronization", etc.
(In reply to Nicolas Silva [:nical] from comment #4) > Not sure this is the right place, but I could really use a tool that logs > bad usage of opengl/gralloc APIs. Anything that could warn me about stuff > like "hey you are trying to upload this texture while we are still rendering > the previous frame asynchronously, forcing synchronization", etc. Hi Nicolas, my understand is you want to tool that can reveal time spend in each gl(gralloc) call, especially for block call, such as glteximage2d. I think it's good and have need to construct a trace tool to dump gl/egl/gralloc API execution time on demand.
There are many bad patterns hard to recognize. For example, some glGet calls may stall pipeline(depend on whether the driver caches state), some pipeline change such as program switch and glEnables/glDisables during rendering is bad. Most of them are hard to detect and neede some heuristic and may make it platform dependent. Then we will turn to PerfHUD or Adreno profiler directly, as they reveal the platform characteristics. The problem of PerfHUD and Adreno profiler is that the statistic values are usually take only GPU into consideration while you found pixel fill rate down, the system may get some memory bandwidth problem in fact. There is no problem with our fragment shader but the system just can not serve us at that time.
Is there any information we could get from the driver directly (rather than trying to guess/recognize bad patterns ourselves)?
We may have to enable platform profiler to get such information. For example there is no way to recognize which GPU part cause slowdown, rather than use those profiler. And to enable platform profiler, we may have to solve at least 2 questions: 1. Hook our window system with EGLWindow and use eglSwapBuffers.(Since most profiler recognize this function call as frame boundary) 2. Use GL to do content rendering to capture the content profile. Another possible problem is that each app can render to several ThebesLayer at same time, the profiler data can be scattered.
Severity: normal → S3

I think this exists now

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.