Re: [PATCH intel-gpu-tools v2 0/6] Convert debugger to Automake

2012-01-09 Thread Ben Widawsky 
On Fri, Jan 06, 2012 at 06:25:04PM -0500, Gaetan Nadon wrote:
 Version 2 improves commit messages and custom build commands
 
 Also fixed some nits in other makefiles.
 
 I checked that the binaries produced have the same size, but I'd like
 someone to run a sanity check on the module. I ran distcheck,
 out-of-source build and build from tarball. 
 A Tested-by tag would be appreciated.
 
 I'll be away for the next few days. I'll collect review tags and I'll
 push the patches next week if all goes well.
 
 Gaetan Nadon (6):
   Debugger: convert existing makefiles to Automake.
   Benchmark: use correct src and build location
   lib: fix include directives, alphabetize sources
   scripts: use PYTHON primary directive for python scripts
   tools: use correct src and build location
   config: remove unused AC_DEFINE for CAIRO, LIBUDEV and GLIB
 
  Makefile.am|8 ++--
  benchmarks/Makefile.am |   29 +++
  configure.ac   |   60 +++
  debugger/Makefile.am   |   27 +--
  debugger/system_routine/.gitignore |   12 -
  debugger/system_routine/GNUmakefile.in |3 -
  debugger/system_routine/Makefile   |   84 
 
  debugger/system_routine/Makefile.am|   42 
  lib/Makefile.am|   45 -
  scripts/Makefile.am|7 +--
  tools/Makefile.am  |   78 ++
  11 files changed, 174 insertions(+), 221 deletions(-)
  delete mode 100644 debugger/system_routine/GNUmakefile.in
  delete mode 100644 debugger/system_routine/Makefile
  create mode 100644 debugger/system_routine/Makefile.am

Acked-by: Ben Widawsky b...@bwidawsk.net
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

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

2012-01-04 Thread 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 mems...@videotron.ca wrote:
  On 12-01-03 09:42 PM, Eric Anholt wrote:
  On Mon, 02 Jan 2012 18:23:15 -0500, Gaetan Nadon mems...@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 e...@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.vet...@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@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

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

2012-01-04 Thread Ben Widawsky 

On 01/04/2012 02:14 PM, Gaetan Nadon wrote:

On 12-01-04 02:38 PM, Ben Widawsky wrote:

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 Nadonmems...@videotron.ca
wrote:

On 12-01-03 09:42 PM, Eric Anholt wrote:

On Mon, 02 Jan 2012 18:23:15 -0500, Gaetan
Nadonmems...@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 Anholte...@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.vet...@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 that the module is posted on x.org web and picked-up by a distro,
I'd like to avoid bug reports.


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.

I noticed. That can be handled in configure. I can 'dist' the generated
.c files so one can build from a tarball without having python3/gen4asm.
We do this for lex  yacc for example.


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.

How about test and helper. The helper seems unfinished. Worth
keeping? I assume they wouldn't be installed either. The test data
object has the same name as /usr/bin/test command.


The only purpose of helper was to get output not in a tempfile. This was 
useful for catching bugs in intel-gen4asm, but probably shouldn't be 
distributed. It's fine with me if you remove this target completely.


Test.g4a is the simplest possible system routine we can run on the GPU 
without actually hanging the system. Rename as you like. It's really 
useful to have around, but also should be fine to just remove this 
target. Anyone doing

Re: [PATCH intel-gpu-tools 0/4] Upgrade module configuration and packaging

2012-01-03 Thread Ben Widawsky 
On 01/02/2012 08:17 AM, Gaetan Nadon wrote:
 This module is hosted as an X.Org app and is published as such.
 This patch adds some missing packaging files and sets some basic 
 infrastructure
 common to all xorg modules which saves maintenance in the long run.
 
 http://www.x.org/wiki/NewModuleGuidelines
 
 
 Gaetan Nadon (4):
   Add mandatory COPYING file.
   Use standard .gitignore file and layout
   Man pages still showing version 1.0 in the 1.1 release
   Add mandatory ChangeLog and INSTALL files
 
  .gitignore |  154 
 +---
  COPYING|  108 ++
  Makefile.am|   14 ++-
  benchmarks/.gitignore  |5 +
  configure.ac   |6 +-
  debugger/.gitignore|2 +
  debugger/system_routine/.gitignore |2 +
  m4/.gitignore  |5 -
  man/Makefile.am|   44 --
  man/{intel_audio_dump.1 = intel_audio_dump.man}   |2 +-
  man/{intel_bios_dumper.1 = intel_bios_dumper.man} |2 +-
  man/{intel_bios_reader.1 = intel_bios_reader.man} |2 +-
  ...intel_error_decode.1 = intel_error_decode.man} |2 +-
  man/{intel_gpu_top.1 = intel_gpu_top.man} |2 +-
  man/{intel_gtt.1 = intel_gtt.man} |2 +-
  man/{intel_lid.1 = intel_lid.man} |2 +-
  man/{intel_reg_dumper.1 = intel_reg_dumper.man}   |2 +-
  man/{intel_reg_read.1 = intel_reg_read.man}   |2 +-
  ...intel_reg_snapshot.1 = intel_reg_snapshot.man} |2 +-
  man/{intel_reg_write.1 = intel_reg_write.man} |2 +-
  man/{intel_stepping.1 = intel_stepping.man}   |2 +-
  ...ad_blit_large.1 = intel_upload_blit_large.man} |2 +-
  ...large_gtt.1 = intel_upload_blit_large_gtt.man} |2 +-
  ...large_map.1 = intel_upload_blit_large_map.man} |2 +-
  ...ad_blit_small.1 = intel_upload_blit_small.man} |2 +-
  tests/.gitignore   |   51 +++
  tools/.gitignore   |   20 +++
  27 files changed, 314 insertions(+), 129 deletions(-)
  create mode 100644 COPYING
  create mode 100644 benchmarks/.gitignore
  create mode 100644 debugger/.gitignore
  create mode 100644 debugger/system_routine/.gitignore
  delete mode 100644 m4/.gitignore
  rename man/{intel_audio_dump.1 = intel_audio_dump.man} (85%)
  rename man/{intel_bios_dumper.1 = intel_bios_dumper.man} (88%)
  rename man/{intel_bios_reader.1 = intel_bios_reader.man} (90%)
  rename man/{intel_error_decode.1 = intel_error_decode.man} (91%)
  rename man/{intel_gpu_top.1 = intel_gpu_top.man} (96%)
  rename man/{intel_gtt.1 = intel_gtt.man} (90%)
  rename man/{intel_lid.1 = intel_lid.man} (89%)
  rename man/{intel_reg_dumper.1 = intel_reg_dumper.man} (93%)
  rename man/{intel_reg_read.1 = intel_reg_read.man} (89%)
  rename man/{intel_reg_snapshot.1 = intel_reg_snapshot.man} (87%)
  rename man/{intel_reg_write.1 = intel_reg_write.man} (89%)
  rename man/{intel_stepping.1 = intel_stepping.man} (90%)
  rename man/{intel_upload_blit_large.1 = intel_upload_blit_large.man} (90%)
  rename man/{intel_upload_blit_large_gtt.1 = 
 intel_upload_blit_large_gtt.man} (89%)
  rename man/{intel_upload_blit_large_map.1 = 
 intel_upload_blit_large_map.man} (89%)
  rename man/{intel_upload_blit_small.1 = intel_upload_blit_small.man} (90%)
  create mode 100644 tests/.gitignore
  create mode 100644 tools/.gitignore
 

I think Daniel Vetter is maintaining this now. He has told me he isn't
subscribed to the list. I would recommend resending with him in CC.

(Same for the other series)

By the way, r-b from me on this series.

~Ben
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel