[PATCH 1/3] drm/etnaviv: submit support for in-fences

Lucas Stach l.stach at pengutronix.de
Fri Mar 17 14:26:49 UTC 2017


Am Freitag, den 17.03.2017, 15:09 +0100 schrieb Philipp Zabel:
> On Fri, 2017-03-17 at 10:55 -0300, Gustavo Padovan wrote:
> > 2017-03-16 Rob Clark <robdclark at gmail.com>:
> > 
> > > On Wed, Mar 8, 2017 at 9:37 AM, Gustavo Padovan <gustavo at padovan.org> wrote:
> > > >> diff --git a/include/uapi/drm/etnaviv_drm.h b/include/uapi/drm/etnaviv_drm.h
> > > >> index 2584c1cca42f6..e9c388a1d8ebe 100644
> > > >> --- a/include/uapi/drm/etnaviv_drm.h
> > > >> +++ b/include/uapi/drm/etnaviv_drm.h
> > > >> @@ -154,6 +154,10 @@ struct drm_etnaviv_gem_submit_bo {
> > > >>   * one or more cmdstream buffers.  This allows for conditional execution
> > > >>   * (context-restore), and IB buffers needed for per tile/bin draw cmds.
> > > >>   */
> > > >> +#define ETNA_SUBMIT_NO_IMPLICIT         0x0001
> > > >> +#define ETNA_SUBMIT_FENCE_FD_IN         0x0002
> > > >
> > > > ETNA_SUBMIT_NO_IMPLICIT and ETNA_SUBMIT_FENCE_FD_IN are the same, when
> > > > you send and fence_fd to the kernel you are requesting on explicit sync
> > > > thus I think the ETNA_SUBMIT_NO_IMPLICIT can be dropped and
> > > > ETNA_SUBMIT_FENCE_FD_IN would be the one to look at.
> > > 
> > > jfwiw, I kept separate no-implicit and fence-fd-in flags in msm mostly
> > > because I couldn't think of a good backwards-compatible way to add it
> > > later if needed.  Currently userspace sets both flags together, and
> > > possibly always will.  But keeping separate flags seemed like a good
> > > idea for future-proofing..
> > 
> > Fair enough. Let's do the same for etnaviv then.
> 
> Alright. Unless Lucas disagrees, I'll keep it as is for consistency.

This flag might make things a bit more "fun" later, as we might need to
merge fences (or even fence arrays of different types) if we are going
to use both implicit and explicit fences to infer scheduling decisions
from.

But to avoid introducing any unnecessary differences between freedreno
and etnaviv, I would suggest to keep the flag around.

Regards,
Lucas



More information about the dri-devel mailing list