From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eugeni Dodonov Subject: Re: Moving intel_decode.c to libdrm Date: Wed, 21 Dec 2011 18:00:15 -0200 Message-ID: References: <1324490983-6975-1-git-send-email-eric@anholt.net> <20111221184624.GD3827@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0654722065==" Return-path: Received: from mail-pz0-f49.google.com (mail-pz0-f49.google.com [209.85.210.49]) by gabe.freedesktop.org (Postfix) with ESMTP id 7CF2DA0A74 for ; Wed, 21 Dec 2011 12:00:56 -0800 (PST) Received: by dajx4 with SMTP id x4so7025882daj.36 for ; Wed, 21 Dec 2011 12:00:56 -0800 (PST) In-Reply-To: <20111221184624.GD3827@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============0654722065== Content-Type: multipart/alternative; boundary=f46d04138eb94d8a5504b49fa44e --f46d04138eb94d8a5504b49fa44e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 21, 2011 at 16:46, Daniel Vetter wrote: > On Wed, Dec 21, 2011 at 10:09:30AM -0800, Eric Anholt wrote: > > I was once again embarassed while explaining to either Ken or Paul > > about how we handle reusing the intel_decode.c file in two trees. > > Here's my attempt at a solution to the problem: Move the code into > > libdrm, and try to give it an API that we won't have to continually > > rev as we throw the kitchen sink into the intel_decode() function > > arguments. > > > > One of the things I'm interested in is doing a version that directly > > pokes at BOs instead of just a pointer, which would let us decode > > associated blocks as we see the various state pointers to them. > > There's also room for some interesting validation in that case. > > > > Further patches (mostly fixing up style) are in my libdrm tree on the > > intel-decode branch. I've tested it with Mesa on gen7 (I have further > > code to land to make gen7 decode more reasonable). > > I've only done a high-level cruise review of this series, but this is > awesome (and has been sitting on my todo list for way to long). > > Very-Much-Acked-by: Daniel Vetter > Yeah, I agree with Daniel - I'll be very happy to have this in libdrm. Thanks a lot! -- Eugeni Dodonov --f46d04138eb94d8a5504b49fa44e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 21, 2011 at 16:46, Daniel Vetter <daniel@ffwll.ch&g= t; wrote:
On Wed, Dec 21, 2011 at 10:09:30AM -0800, Eric Anholt wro= te:
> I was once again embarassed while explaining to either Ken or Paul
> about how we handle reusing the intel_decode.c file in two trees.
> Here's my attempt at a solution to the problem: Move the code into=
> libdrm, and try to give it an API that we won't have to continuall= y
> rev as we throw the kitchen sink into the intel_decode() function
> arguments.
>
> One of the things I'm interested in is doing a version that direct= ly
> pokes at BOs instead of just a pointer, which would let us decode
> associated blocks as we see the various state pointers to them.
> There's also room for some interesting validation in that case. >
> Further patches (mostly fixing up style) are in my libdrm tree on the<= br> > intel-decode branch. =A0I've tested it with Mesa on gen7 (I have f= urther
> code to land to make gen7 decode more reasonable).

I've only done a high-level cruise review of this series, but thi= s is
awesome (and has been sitting on my todo list for way to long).

Very-Much-Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Yeah, I agree = with Daniel - I'll be very happy to have this in libdrm. Thanks a lot! =

--
Eugeni Dodonov

--f46d04138eb94d8a5504b49fa44e-- --===============0654722065== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============0654722065==--