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

[Ben Widawsky]

I should have added... The shader debugger isn't complete. This is a 
prototype/proof of concept. Somehow that got dropped in my earlier mail.

On 01/04/2012 11:34 AM, Ben Widawsky wrote:
> 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
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel