From: Daniel Vetter <daniel@ffwll.ch>
To: Daniel Vetter <daniel@ffwll.ch>,
intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 1/2] drm/i915: Slice/Subslice/EU info via GETPARAM
Date: Wed, 6 Aug 2014 17:02:39 +0200 [thread overview]
Message-ID: <20140806150239.GR8727@phenom.ffwll.local> (raw)
In-Reply-To: <20140806144344.GF4660@jeffdesk>
On Wed, Aug 06, 2014 at 09:43:44AM -0500, Jeff McGee wrote:
> On Tue, Aug 05, 2014 at 04:50:16PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 5, 2014 at 4:03 PM, Jeff McGee <jeff.mcgee@intel.com> wrote:
> > >> Also, usual broken record request: I need open-source userspace using
> > >> this (mesa, ddx, libva).
> > >> -Daniel
> > >>
> > >
> > > This is kind of chicken-and-egg problem that I haven't been through. I
> > > assume that we build new interfaces up the stack (kernel->libdrm->usermode).
> > > Any tips or docs on how to proceed?
> >
> > You need to have the full thing ready with kernel, igt, libdrm, and
> > umd driver patches (and maybe even testcases for the new umd feature,
> > e.g. for some of the arb robustness stuff we've done). Then you post
> > them all to relevant mailing lists and go through the review process
> > for all parts. Once that's done and _all_ parts are reviewed, merging
> > starts with kernel+igt, then libdrm + libdrm release, then umd.
> > -Daniel
>
> Thanks Daniel. Is it acceptable to get the kernel part merged with only
> an igt test (technically an open-source userspace component)? I think
> probably not, but have to ask.
Not really. The entire idea behind this is that only once we have the full
stack picture available we can properly assess whether the interface
fullfills the goal. That requires an actual implementation of the feature
for the entire stack.
And Dave Airlie (as the drm upstream maintainer) requires that that entire
pile is open-source.
So we really don't have wiggle room here. And personally I don't want to
open the opportunity for discussions for each specific feature on whether
a bare-bones demonstration test in igt is good enough or not, it really
should be something shippable to users.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
prev parent reply other threads:[~2014-08-06 15:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-31 1:59 [PATCH 1/2] drm/i915: Slice/Subslice/EU info via GETPARAM jeff.mcgee
2014-07-31 1:59 ` [PATCH 2/2] drm/i915/chv: Implement SSEU info for CHV jeff.mcgee
2014-07-31 11:55 ` Mcaulay, Alistair
2014-07-31 23:18 ` Jeff McGee
2014-08-04 8:18 ` Daniel Vetter
2014-08-04 8:22 ` Daniel Vetter
2014-08-05 13:47 ` Jeff McGee
2014-08-05 13:41 ` Damien Lespiau
2014-08-06 14:40 ` Jeff McGee
2014-07-31 11:53 ` [PATCH 1/2] drm/i915: Slice/Subslice/EU info via GETPARAM Mcaulay, Alistair
2014-07-31 23:16 ` Jeff McGee
2014-08-04 8:20 ` Daniel Vetter
2014-08-05 14:03 ` Jeff McGee
2014-08-05 14:50 ` Daniel Vetter
2014-08-06 14:43 ` Jeff McGee
2014-08-06 15:02 ` Daniel Vetter [this message]
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=20140806150239.GR8727@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=intel-gfx@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox