All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomeu Vizoso <tomeu.vizoso@collabora.com>
To: alyssa.rosenzweig@collabora.com, dri-devel@lists.freedesktop.org
Cc: airlied@linux.ie, steven.price@arm.com
Subject: Re: [PATCH 0/4] drm/panfrost: Plumb cycle counters to userspace
Date: Fri, 28 May 2021 08:07:00 +0200	[thread overview]
Message-ID: <997658d4-ba30-f150-7b15-183403d7ae94@collabora.com> (raw)
In-Reply-To: <20210527203804.12914-1-alyssa.rosenzweig@collabora.com>

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 instead.

Regards,

Tomeu

On 5/27/21 10:38 PM, alyssa.rosenzweig@collabora.com wrote:
> From: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
> 
> 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 the LD_GCLK.u64 instruction
> 
> These form building blocks for profiling features, for example the
> ARB_shader_clock extension which accesses the counters from an
> application's shader.
> 
> The counters consume power, so it is recommended to disable the counters
> when not in use. To do so, we follow the strategy from mali_kbase: add a
> counter requirement to the job, start the counters only when required,
> and stop them as quickly as possible.
> 
> The new UABI will be used in Mesa. An implementation of ARB_shader_clock
> using this UABI is available as a pending upstream merge request [1].
> The implementation passes the relevant piglit test, validating both the
> kernel and mesa.
> 
> 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 the same mechanism is required for GPU timestamps. This
> bit of bikeshedding aside, I'm pleased with the patches.
> 
> [1] https://gitlab.freedesktop.org/mesa/mesa/merge_requests/11051
> 
> Alyssa Rosenzweig (4):
>    drm/panfrost: Add cycle counter job requirement
>    drm/panfrost: Add CYCLE_COUNT_START/STOP commands
>    drm/panfrost: Add permon acquire/release helpers
>    drm/panfrost: Handle PANFROST_JD_REQ_PERMON
> 
>   drivers/gpu/drm/panfrost/panfrost_device.h |  3 +++
>   drivers/gpu/drm/panfrost/panfrost_drv.c    | 10 +++++++---
>   drivers/gpu/drm/panfrost/panfrost_gpu.c    | 20 ++++++++++++++++++++
>   drivers/gpu/drm/panfrost/panfrost_gpu.h    |  3 +++
>   drivers/gpu/drm/panfrost/panfrost_job.c    |  6 ++++++
>   drivers/gpu/drm/panfrost/panfrost_regs.h   |  2 ++
>   include/uapi/drm/panfrost_drm.h            |  3 ++-
>   7 files changed, 43 insertions(+), 4 deletions(-)
> 

  parent reply	other threads:[~2021-05-28  6:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-27 20:38 [PATCH 0/4] drm/panfrost: Plumb cycle counters to userspace alyssa.rosenzweig
2021-05-27 20:38 ` [PATCH 1/4] drm/panfrost: Add cycle counter job requirement alyssa.rosenzweig
2021-06-02 11:50   ` Steven Price
2021-05-27 20:38 ` [PATCH 2/4] drm/panfrost: Add CYCLE_COUNT_START/STOP commands alyssa.rosenzweig
2021-06-02 11:50   ` Steven Price
2021-05-27 20:38 ` [PATCH 3/4] drm/panfrost: Add permon acquire/release helpers alyssa.rosenzweig
2021-06-02 11:50   ` Steven Price
2021-05-27 20:38 ` [PATCH 4/4] drm/panfrost: Handle PANFROST_JD_REQ_PERMON alyssa.rosenzweig
2021-06-02 11:50   ` Steven Price
2021-05-27 21:14 ` [PATCH 0/4] drm/panfrost: Plumb cycle counters to userspace Alyssa Rosenzweig
2021-05-28  6:07 ` Tomeu Vizoso [this message]
2021-05-28 13:31   ` Alyssa Rosenzweig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=997658d4-ba30-f150-7b15-183403d7ae94@collabora.com \
    --to=tomeu.vizoso@collabora.com \
    --cc=airlied@linux.ie \
    --cc=alyssa.rosenzweig@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=steven.price@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.