All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Anholt <eric@anholt.net>
To: "Christian König" <christian.koenig@amd.com>,
	dri-devel@lists.freedesktop.org
Cc: Alex Deucher <alexander.deucher@amd.com>
Subject: Re: drm/scheduler for vc5
Date: Tue, 03 Apr 2018 16:08:41 -0700	[thread overview]
Message-ID: <87zi2jhoqu.fsf@anholt.net> (raw)
In-Reply-To: <75063f31-e26d-54a8-ebc7-409b3978560d@amd.com>


[-- Attachment #1.1: Type: text/plain, Size: 1453 bytes --]

Christian König <christian.koenig@amd.com> writes:

> Hi Eric,
>
> nice to see that the scheduler gets used more and more.
>
> The feature your need to solve both your binning/rendering as well as 
> your MMU problem is dependency handling. See the "dependency" callback 
> of the backend operations.
>
> With this callback the driver can return dma_fences which need to signal 
> (or at least be scheduled if it targets the same ring buffer/fifo).
>
> Now you need dma_fences as result of your run_job callback for the 
> binning step anyway. So when you return this fence from the binning step 
> as dependency for your rendering step the scheduler does exactly what 
> you want, e.g. not start the rendering before the binning is finished.

It looks like in order to use the bin's fence returned from run_job,
render first needs to depend on exec->bin.base.s_fence->scheduled so
that run_job has been called.  Is there any reason not to just depend on
exec->bin.base.s_fence->finished, instead?  Finished will be signaled
basically immediately after the run_job fence completes, right?

Also, I hadn't quite followed your suggestion about MMU switching
before.  Your trick was that you return a newly-generated dependency on
MMU switching as the final dependency, so that you only decide on
serializing the MMU switch once you're ready to run and the scheduler
was about to pick your job anyway.  This seems good to me.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2018-04-03 23:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-30 20:05 drm/scheduler for vc5 Eric Anholt
2018-03-31 17:46 ` Christian König
2018-04-02 18:49   ` Eric Anholt
2018-04-03  9:18     ` Christian König
2018-04-03 23:08   ` Eric Anholt [this message]
2018-04-04  7:13     ` Christian König

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=87zi2jhoqu.fsf@anholt.net \
    --to=eric@anholt.net \
    --cc=alexander.deucher@amd.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@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.