[PATCH intel-gpu-tools 00/10] Upgrade module configuration - Part 2

[Ben Widawsky]

On Wed, Jan 04, 2012 at 03:31:48PM +0100, Daniel Vetter wrote:
> On Wed, Jan 4, 2012 at 15:17, Gaetan Nadon <memsize at videotron.ca> wrote:
> > On 12-01-03 09:42 PM, Eric Anholt wrote:
> >> On Mon, 02 Jan 2012 18:23:15 -0500, Gaetan Nadon <memsize at videotron.ca> wrote:
> >>> This series applies some xorg project policies and code reuse from util-macros.
> >>> In some cases it reverts "upgrades" that were "too new" for the overall xorg.
> >>> There were no bug fixes, things went smoothly.
> >> Both series for updates to automake infrastructure for this project are
> >>
> >> Acked-by: Eric Anholt <eric at anholt.net>
> >>
> >> I think I cribbed from xf86-video-intel when I originally did this
> >> stuff, and I didn't mean for it to be gratuitously different from our
> >> other projects, as I recall.
> > Things evolved gradually over the last 3 years to arrive at the
> > configuration we have today. I provided explanations so the changes do
> > not appear to be gratuitous.
> >
> > I noticed the system_routine configuration is rather convoluted. I
> > prototyped a formal automake Makefile.am and it simplifies things quite
> > a bit, all the way up to configure.ac. As it is now, the system_routine
> > does not build from a tarball due to a missing Makefile.
> >
> > I'd need a little help to do  a better job. I suppose "sr" is the system
> > routine, how would this gets used by someone who installed the package
> > from a distro? I am wondering which files to install from this subdir.
> 
> The system_routine/debugger stuff is from Ben Widawsky. Adding him to
> cc so he can join the fun.
> -Daniel
> -- 
> Daniel Vetter
> daniel.vetter at ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch


Wow, you're my hero. I spent at least a full day trying to get it
working with autotools, and just gave up.

The first question which must be answered is, does anyone still want
this. Maybe I didn't advertise the feature well enough, but nobody
seemed intersted. To remind everyone, this is a HW supported feature to
do shader debugging on the GEN EUs.

As of now, the debugger directory has nothing which should be installed
since my mesa patches never made it upstream (ie. the debugger is
prototype/instructional only). Carl Worth volunteered to work on it a
bit, but since there were more promosing tools to be developed, I think
it got dropped on the floor. Honestly, even a successful build really
shouldn't be a requirement for the i-g-t package as of this instant. I
just wanted to have something in place so next time someone wants to try
doing shader debugging on intel platforms, my hard work can be reused.

Now assuming you do want to get it working properly after reading
that...

The package relies on python3, and intel-gen4asm to assemble the
system_routine.  (http://cgit.freedesktop.org/xorg/app/intel-gen4asm/).
This was supposed to go away as the "compilation" was going to move to
mesa (though I personally preferred a discrete SR, others were opposed).
In any case, the dependency is there now. 

debugger/debug_rdata.c - help debug the debugger, shouldn't be installed

debugger/system_routine/pre_cpp.py - roll my own preprocessor which
evelautates defines. Shouldn't be installed. Would prefer a better
solution here, but couldn't find one.

debugger/system_routine/eviction_macro.c - generate a lot of repetivive
code for the sr. Shouldn't be installed. Not even relevant on Gen7+.

debugger/eudb - the client side debugger (equivalent of gdb). Must be
run as root. Probably would be an install target.

debugger/system_routine/sr.* - There are a few options here and it
depends on how mesa wanted to use it. One option is a binary blob to be
read in at runtime. Another is to take the bytes as an array and build
it in to mesa (this was what the final mesa patches had). The most
reusable from mesa side would probably be to install the binary
somewhere, and mesa could just suck it in at runtime.

As a side note, I'm willing to improve on this stuff if I found some
users of the feature. It sort of died a lonely death unfortunately.

Ben