linux-kernel - Re: [PATCH 9/9] drm/vc4: Add an interface for capturing the GPU state after a hang.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACvgo53NZ+uOo83pDOr7Yw321MmeKbbgAQRKPasv6kOhKsPrNA@mail.gmail.com>
Date:	Thu, 3 Dec 2015 11:46:47 +0000
From:	Emil Velikov <emil.l.velikov@...il.com>
To:	Eric Anholt <eric@...olt.net>
Cc:	ML dri-devel <dri-devel@...ts.freedesktop.org>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 9/9] drm/vc4: Add an interface for capturing the GPU state
 after a hang.

On 2 December 2015 at 19:35, Eric Anholt <eric@...olt.net> wrote:
> Emil Velikov <emil.l.velikov@...il.com> writes:
>
>> On 1 December 2015 at 20:35, Eric Anholt <eric@...olt.net> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/