From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933028AbbLCLqt (ORCPT ); Thu, 3 Dec 2015 06:46:49 -0500 Received: from mail-ig0-f174.google.com ([209.85.213.174]:36676 "EHLO mail-ig0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752085AbbLCLqs (ORCPT ); Thu, 3 Dec 2015 06:46:48 -0500 MIME-Version: 1.0 In-Reply-To: <87r3j48wzv.fsf@eliezer.anholt.net> References: <1449002158-19156-1-git-send-email-eric@anholt.net> <1449002158-19156-9-git-send-email-eric@anholt.net> <87r3j48wzv.fsf@eliezer.anholt.net> Date: Thu, 3 Dec 2015 11:46:47 +0000 Message-ID: Subject: Re: [PATCH 9/9] drm/vc4: Add an interface for capturing the GPU state after a hang. From: Emil Velikov To: Eric Anholt Cc: ML dri-devel , "Linux-Kernel@Vger. Kernel. Org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2 December 2015 at 19:35, Eric Anholt wrote: > Emil Velikov writes: > >> On 1 December 2015 at 20:35, Eric Anholt wrote: >>> This can be parsed with vc4-gpu-tools tools for trying to figure out >>> what was going on. >>> >> I might be pushing my luck here ... have you thought about basing >> (forking) vc4-gpu-tools of intel-gpu-tools ? I'd imagine that the >> macros and helpers will come in handy, despite that some are quite >> intel specific. >> >> On a related note - with the above project in place I'd imagine you >> have (re)considered about having libdrm-vc4 ? Copying hunks around >> might lead to interesting moments (as you have already noticed :-P) >> >> On that note I'll stop now with beating the libdrm drum :-) > > The headers and code that I copy between the two userspace locations > will go in libdrm when I have a kernel ABI, but vc4_drm.h can't go in > until merging to the kernel, and there's not a whole lot of point > without that. > Definately - I wasn't suggesting about getting things in libdrm before the kernel. On the ABI front you might want to follow nouveau/freedreno/omap approach by using a (disabled by default) experimental-vc4 switch and keeping both vc4_drm.h, vc4_qpu_defines.h (and other?) in the separate libdrm-vc4 package. As things stabilise vc4_drm.h can be moved to the core libdrm package. > Yes, I have thought about basing vc4-gpu-tools off of intel-gpu-tools. > I've actually tried to build and use the kms testing stuff on vc4, and > it was a total bust. Someone needs to do a lot of work to make igt > useful for non-intel. If you'd like me to build my vc4 testing inside > of igt, I'd someone to demo one of my tests building inside of igt, with > the test runner working and none of the intel-specific tests reporting > failure, and get me permission to just push code to that repository > (It's hard enough getting piglit tests reviewed, vc4-specific tests and > tools would never get review). As Dan and Dan covered most of the concerns, can you elaborate which of the following (and others?) are show stoppers: - libpciaccess requirement - libdrm-intel requirement - other misc requirements (xv x11 xext dri2proto cairo-xlib) - no clean "pass" when executed on non intel hardware Thanks Emil