Moving intel_decode.c to libdrm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <daniel.vetter at ffwll.ch>
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux