Re: [PATCH intel-gpu-tools 00/10] Upgrade module configuration - Part 2
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. Thanks for the review. ___ 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
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 ___ 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
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
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. 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. I'll submit a patch which reflects your sepc above. This will preserve existing work. Additional work can be done afterwards. I'll test it all builds such that we don't get bug reports. One question on the sr.*. I suppose it is only for Linux, but would it not be the same code being generated
Re: [PATCH intel-gpu-tools 00/10] Upgrade module configuration - Part 2
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 00/10] Upgrade module configuration - Part 2
On 12-01-04 06:33 PM, Ben Widawsky wrote: 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. In my prototype I did not use temp files (was filling my /tmp) but used several rules, each step being saved in
Re: [PATCH intel-gpu-tools 00/10] Upgrade module configuration - Part 2
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. pgp15r1mBdcSV.pgp Description: PGP signature ___ 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
[PATCH intel-gpu-tools 00/10] Upgrade module configuration - Part 2
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. Should there be any reasons to deviate, I'd be happy to make appropriate adjustements and comments. Gaetan Nadon (6): config: remove unrequired AM_PROG_CC_C_O config: remove duplicate AC_PROG_CC and AC_PROG__CC_99 config: use project wide xorg warnings variable config: set-up xorg automatic rebuilding rules config: the minimum version for autoconf is 2.60 config: restore the libtool minimum version to 1.5 autogen.sh | 14 ++ benchmarks/Makefile.am |2 +- configure.ac | 44 +++- debugger/Makefile.am |2 +- lib/Makefile.am|2 +- tests/Makefile.am |2 +- tools/Makefile.am |2 +- 7 files changed, 26 insertions(+), 42 deletions(-) -- 1.7.5.4 ___ 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
