Hi Tomeu,
> Will this be enough to implement GL_TIMESTAMP and GL_TIME_ELAPSED queries?
>
> Guess the DDK implements these as WRITE_VALUE jobs, and there's also a soft
> job BASE_JD_REQ_SOFT_DUMP_CPU_GPU_TIME that I guess is used for
> glGet*(GL_TIMESTAMP). Other DRM drivers use an ioctl for that
Hi Alyssa,
Will this be enough to implement GL_TIMESTAMP and GL_TIME_ELAPSED queries?
Guess the DDK implements these as WRITE_VALUE jobs, and there's also a
soft job BASE_JD_REQ_SOFT_DUMP_CPU_GPU_TIME that I guess is used for
glGet*(GL_TIMESTAMP). Other DRM drivers use an ioctl for that instea
> The main outstanding questing is the proper name. Performance monitoring
> ("PERMON") is the name used by kbase, but it's jargon-y and risks
> confusion with performance counters, an orthogonal mechanism. Cycle
> count is more descriptive and matches the actual hardware name, but
> obscures that
From: Alyssa Rosenzweig
Mali has hardware cycle counters (and GPU timestamps) available for
profiling. These are exposed in various ways:
- Kernel: As CYCLE_COUNT and TIMESTAMP registers
- Job chain: As WRITE_VALUE descriptors
- Shader (Midgard): As LD_SPECIAL selectors
- Shader (Bifrost): As t
