<div class="gmail_quote">On Wed, Dec 21, 2011 at 16:46, Daniel Vetter <<a href="mailto:daniel@ffwll.ch">daniel@ffwll.ch</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">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. 狢've tested it with Mesa on gen7 (I have further > code to land to make gen7 decode more reasonable). </div>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 <<a href="mailto:daniel.vetter@ffwll.ch">daniel.vetter@ffwll.ch</a>> </blockquote><div> Yeah, I agree with Daniel - I'll be very happy to have this in libdrm. Thanks a lot! </div></div> -- Eugeni Dodonov<a href="http://eugeni.dodonov.net/" target="_blank"> </a>