All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [RFC v2 2/3] drm/i915: duplicate i915_gem_ring_dispatch trace and add ctx parameter
Date: Fri, 18 Jul 2014 10:43:36 +0100	[thread overview]
Message-ID: <53C8EC48.3030806@intel.com> (raw)
In-Reply-To: <20140717162504.GB3452@nuc-i3427.alporthouse.com>

On 7/17/2014 5:25 PM, Chris Wilson wrote:
> On Wed, Jul 16, 2014 at 05:22:38PM +0100, daniele.ceraolospurio@intel.com wrote:
>> From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>>
>> The context used to execute a batchbuffer is becoming increasingly
>> important. Duplicating to avoid modifications to the original trace.
>
> I am sure we don't want both. The structure encoding is exposed to
> userspace so we are free to update the tracepoints within reason.

As you can see by the next patch in the series, I plan to add a callback 
inside the trace. My original patch modified the existing trace, but (if 
I've understood correctly) Daniel asked for a duplicated trace to avoid 
adding the callback into the existing one.

> I would also like a better ctx identifier than its pointer. Using the
> pointer for tracking objects makes it more difficult to read traces
> (although it is easy for scripts).

I use the VM pointer to track the ppgtt; that pointer is also printed by 
several other traces, including the ppgtt init/release ones that I've 
submitted for comments in this series. However, I don't mind changing 
the way we identify the ctx as long as I still have access to the VM 
pointer. I'll have a look at the possible ways of identifying the ctx 
and I'll try to find a better solution than the current one.

thanks,
Daniele

  reply	other threads:[~2014-07-18  9:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-16 16:22 [RFC v2 0/3] drm/i915: Trace point callbacks for kernel validation daniele.ceraolospurio
2014-07-16 16:22 ` [RFC v2 1/3] drm/i915: Add ppgtt init/release trace points daniele.ceraolospurio
2014-07-16 16:22 ` [RFC v2 2/3] drm/i915: duplicate i915_gem_ring_dispatch trace and add ctx parameter daniele.ceraolospurio
2014-07-17 16:25   ` Chris Wilson
2014-07-18  9:43     ` Ceraolo Spurio, Daniele [this message]
2014-07-18 13:23       ` Daniel Vetter
2014-07-30 12:34       ` Ceraolo Spurio, Daniele
2014-07-16 16:22 ` [RFC v2 3/3] drm/i915: Trace point callbacks for validation daniele.ceraolospurio

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=53C8EC48.3030806@intel.com \
    --to=daniele.ceraolospurio@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.