From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Moving intel_decode.c to libdrm Date: Wed, 21 Dec 2011 10:09:30 -0800 Message-ID: <1324490983-6975-1-git-send-email-eric@anholt.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from annarchy.freedesktop.org (annarchy.freedesktop.org [131.252.210.176]) by gabe.freedesktop.org (Postfix) with ESMTP id F2BBFA0AB9 for ; Wed, 21 Dec 2011 10:10:11 -0800 (PST) Received: from pollan.anholt.net (annarchy.freedesktop.org [127.0.0.1]) by annarchy.freedesktop.org (Postfix) with ESMTP id 40E2F130079 for ; Wed, 21 Dec 2011 10:10:06 -0800 (PST) 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: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org 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).