From: Eric Anholt <eric@anholt.net>
To: dri-devel@lists.freedesktop.org
Cc: "Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>
Subject: drm/scheduler for vc5
Date: Fri, 30 Mar 2018 13:05:22 -0700 [thread overview]
Message-ID: <87o9j572il.fsf@anholt.net> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 1444 bytes --]
I've been keeping my eye on what's going on with drm/scheduler, and I'm
definitely interested in using it. I've got some questions about how to
fit it to this HW, though.
For this HW, most rendering jobs have two phases: binning and rendering,
and the HW has two small FIFOs for descriptions of each type of job to
be submitted. The bin portion must be completed before emitting the
render. Some jobs may be render only, skipping the bin phase.
The render side is what takes most of the time. However, you can
usually bin the next frame while rendering the current one, helping keep
your shared shader cores busy when you're parsing command lists. The
exception is if the next bin depends on your last render (think
render-to-texture with texturing in a vertex shader).
This makes me think that I should expose two entities for the HW's
binner and the renderer. Each VC6 job would have two drm_sched_job: The
render job would depend on the fence from the bin job, and bin may or
may not depend on the previous render.
However, as an extra complication, the MMU is shared between binner and
renderer, so I can't schedule a new job with a page table change until
the other side finishes up. Is there a good way to express this with
drm/scheduler, or should I work around this by internally stalling my
job submissions to the HW when a page table change is needed, and then
trigger that page table swap and submit once a job completes?
[-- 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
next reply other threads:[~2018-03-30 20:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-30 20:05 Eric Anholt [this message]
2018-03-31 17:46 ` drm/scheduler for vc5 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
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=87o9j572il.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.