All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Gordon <david.s.gordon@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	yu.dai@intel.com, intel-gfx@lists.freedesktop.org
Cc: daniel.vetter@ffwll.ch
Subject: Re: [PATCH 1/2] drm/i915/guc: Simplify code by keeping kmap of guc_client object
Date: Mon, 15 Feb 2016 14:39:31 +0000	[thread overview]
Message-ID: <56C1E323.5020804@intel.com> (raw)
In-Reply-To: <56BDD80C.40908@linux.intel.com>

On 12/02/16 13:03, Tvrtko Ursulin wrote:
>
> On 11/02/16 23:09, yu.dai@intel.com wrote:
>> From: Alex Dai <yu.dai@intel.com>
>>
>> GuC client object is always pinned during its life cycle. We cache
>> the kmap of its first page, which includes guc_process_desc and
>> doorbell. By doing so, we can simplify the code where we read from
>> this page to get where GuC is progressing on work queue; and the
>> code where driver program doorbell to send work queue item to GuC.

[snip]

>>
>> -    /* Finally, update the cached copy of the GuC's WQ head */
>> -    gc->wq_head = desc->head;
>
> Did you mean to remove the above?

I wondered that too at first, but the answer is "yes" -- see below.

>>
>> +    client->client_base = kmap(i915_gem_object_get_dirty_page(obj, 0));
>
> Was this another bug, that the page/object wasn't dirtied before?

It wouldn't have made any difference; the object is pinned in the GTT 
forever, so it can't be swapped out or reclaimed.

>> -    uint32_t wq_head;
>
> Hm ok I don't get why kmap caching means removing this as well?

'wq_head' was an optimisation so that we could check whether there was 
known to be space in the workqueue without kmapping and reading the 
process descriptor. Now that the client (which includes the process 
descriptor) is permanently mapped, there's no advantage to caching the 
head; we might just as well read the current value from 'desc->head' 
each time.

> Btw I don't see patch 2/2 ?
>
> Regards,
>
> Tvrtko
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-02-15 14:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-11 23:09 [PATCH 1/2] drm/i915/guc: Simplify code by keeping kmap of guc_client object yu.dai
2016-02-12 13:03 ` Tvrtko Ursulin
2016-02-15 14:39   ` Dave Gordon [this message]
2016-02-16 16:27     ` Yu Dai
2016-02-15 15:23   ` Dave Gordon
2016-02-16 16:47     ` Yu Dai
2016-02-17 16:04       ` Daniel Vetter
2016-02-17 17:48         ` Yu Dai
2016-02-18  9:51           ` Chris Wilson

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=56C1E323.5020804@intel.com \
    --to=david.s.gordon@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=tvrtko.ursulin@linux.intel.com \
    --cc=yu.dai@intel.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.