All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Glisse <j.glisse@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	Ben Skeggs <bskeggs@redhat.com>
Subject: Re: Fence, timeline and android sync points
Date: Thu, 14 Aug 2014 14:26:11 -0400	[thread overview]
Message-ID: <20140814182611.GE2000@gmail.com> (raw)
In-Reply-To: <20140814155848.GZ10500@phenom.ffwll.local>

On Thu, Aug 14, 2014 at 05:58:48PM +0200, Daniel Vetter wrote:
> On Thu, Aug 14, 2014 at 10:12:06AM -0400, Jerome Glisse wrote:
> > On Thu, Aug 14, 2014 at 09:16:02AM -0400, Rob Clark wrote:
> > > On Wed, Aug 13, 2014 at 1:07 PM, Jerome Glisse <j.glisse@gmail.com> wrote:
> > > > So this is fundamentaly different, fence as they are now allow random driver
> > > > callback and this is bound to get ugly this is bound to lead to one driver
> > > > doing something that seems innocuous but turn out to break heavoc when call
> > > > from some other driver function.
> > > 
> > > 
> > > tbh, that seems solvable by some strict rules about what you can do in
> > > the callback.. ie. don't do anything you couldn't do in atomic, and
> > > don't signal another fence.. off the top of my head that seems
> > > sufficient.
> > > 
> > > If the driver getting the callback needs to do more, then it can
> > > always schedule a worker..
> > > 
> > > But I could certainly see the case where the driver waiting on fence
> > > sets everything up before installing the cb and then just needs to
> > > write one or a couple regs from the cb.
> > 
> > Yes sane code will do sane things, sadly i fear we can not enforce sane
> > code everywhere especialy with out of tree driver and i would rather
> > force there hand to only allow sane implementation. Providing call back
> > api obviously allows them to do crazy stuff.
> 
> Well then don't support out of tree drivers. Fairly easy problem really,
> and last time I checked "out of tree drivers suck" isn't a valid
> objections for upstream code ... It's kinda assumed that they all do, it's
> why we have staging after all.

As usual i fail at expressing my point. I am not saying do not merge this
because of out of tree drivers, i am saying while doing an api let make it
sane and try to make it so that it enforce sanity to anything that lives
outside our realm.

And not even thinking outside kernel tree, but someone might come along and
start using fence, see the callback stuff and start doing crazy stuff with
that all this inside a different obscur kernel subsystem. Then someone in
graphic sees that and use that as justification to do crazy thing too,
because hey, if he is doing why can't i ?

> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

  reply	other threads:[~2014-08-14 18:26 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-12 22:13 Fence, timeline and android sync points Jerome Glisse
2014-08-13  1:23 ` Jerome Glisse
2014-08-13  7:59 ` Christian König
2014-08-13 13:41   ` Jerome Glisse
2014-08-13 14:08     ` Christian König
2014-08-13 15:56       ` Jerome Glisse
2014-08-13  8:28 ` Daniel Vetter
2014-08-13 13:36   ` Jerome Glisse
2014-08-13 15:54     ` Daniel Vetter
2014-08-13 17:07       ` Jerome Glisse
2014-08-14  9:08         ` Daniel Vetter
2014-08-14 14:23           ` Jerome Glisse
2014-08-14 15:55             ` Daniel Vetter
2014-08-14 18:18               ` Jerome Glisse
2014-08-14 18:47                 ` Daniel Vetter
2014-08-14 19:15                   ` Jerome Glisse
2014-08-14 19:40                     ` Maarten Lankhorst
2014-08-14 19:56                       ` Jerome Glisse
2014-08-14 21:20                         ` Daniel Vetter
2014-08-14 21:23                     ` Daniel Vetter
2014-08-14 23:03                       ` Jerome Glisse
2014-08-15  8:07                         ` Daniel Vetter
2014-08-15 14:53                           ` Jerome Glisse
2014-08-14 21:30                     ` Daniel Vetter
2014-08-15  6:54                     ` Thomas Hellstrom
2014-08-15 14:52                       ` Jerome Glisse
2014-08-16  7:01                         ` Thomas Hellstrom
2014-08-16 15:30                           ` Jerome Glisse
2014-08-14  9:15         ` Maarten Lankhorst
2014-08-14 11:53           ` Christian König
2014-08-14 12:37             ` Maarten Lankhorst
2014-08-14 14:31               ` Christian König
2014-08-14 14:09           ` Jerome Glisse
2014-08-14 13:16         ` Rob Clark
2014-08-14 14:12           ` Jerome Glisse
2014-08-14 15:58             ` Daniel Vetter
2014-08-14 18:26               ` Jerome Glisse [this message]
2014-08-14 19:16                 ` Maarten Lankhorst
2014-08-14 22:11             ` Rob Clark

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=20140814182611.GE2000@gmail.com \
    --to=j.glisse@gmail.com \
    --cc=bskeggs@redhat.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel@ffwll.ch \
    --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.