On 2 December 2015 at 19:35, Eric Anholt <eric at anholt.net> wrote: > Emil Velikov <emil.l.velikov at gmail.com> writes: > >> On 1 December 2015 at 20:35, Eric Anholt <eric at anholt.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
