Re: [Intel-gfx] [PATCH 00/10] [RFC v2] quick dump
On Sun, Feb 03, 2013 at 10:13:10AM -0800, Ben Widawsky wrote: - The build kind of sucks on Arch because of Arch's choices regarding python libraries. To build this on Arch, you must run something like: ./autogen.sh PYTHON_LDFLAGS=-L/usr/lib/python3.3 -lpython3.3m Don't you have a python3.pc that would allow you to pull the right flags? An other detail it that we can't add those hard dependencies to i-g-t, distributions will hate us (even more). So you'd need to make its compilation optional. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/10] [RFC v2] quick dump
On Sun, Feb 03, 2013 at 10:13:10AM -0800, Ben Widawsky wrote: On Sun, Feb 03, 2013 at 12:22:25PM +, Chris Wilson wrote: On Sun, Feb 03, 2013 at 10:29:15AM +0100, Jesse Barnes wrote: On Sat, 2 Feb 2013 16:07:52 -0800 Ben Widawsky b...@bwidawsk.net wrote: This is my second attempt at winning approval for the series. First one was: https://patchwork.kernel.org/patch/1493131/ In spending the time to rework this tool, I've begun to lose my belief in some of the original motivations I had. Even if you don't want to review, but just like (or dislike) what you see, I'd appreciate such comments. I'd like to see it land in i-g-t. Having the regs defined in a text or xml file is an improvement over what we have today, and is easier to extend. At first the advantage of reg_dumper was that it parsed out the bitfields of the various regs. But we didn't keep up with that, and also haven't kept up with the regs on new platforms as well as we could. Text files would make that easier, and xml files might bring back the bit field parsing, which would be extra nice. Completely agree. For me the big improvement would be being able to use the bspec register names or our internal approximation thereof rather than having to loop up the actual addresses every time. Having the name database available in python should make building integrated little snippets to parse traces which are also python accessible. -Chris It's really nice to get support from you. A mix of fever and staring at the same code too long can really make someone go crazy. Still, a few concerns left from me, one of which I accidentally left out of the description. - Someone needs to give me a yes or no on the m4 extension macros. This will block any pushing. - The build kind of sucks on Arch because of Arch's choices regarding python libraries. To build this on Arch, you must run something like: ./autogen.sh PYTHON_LDFLAGS=-L/usr/lib/python3.3 -lpython3.3m I really don't like autogen not working out of the box. Perhaps I need to add an AC_ flag to default this tool to off? What do others think? Does it work properly on other distros? How to handle this? - Ideally, I'd like someone to send me some fixes for valleyview definitions if they're needed. I am not sure. Jesse, if you can send me a list of DPIO offsets to read, I'll add the appropriate patch. (It can wait until you get back). Yeah, I like. Can't help you with the autfoo though :( And no opinion on the m4 macro stuff, I guess you need to poke our legal guys quickly for this. The only thing to ponder imo is whether we should add intel_ prefixes to the tools and add all the new files to the install target (probably need tos shove the data files somewhere in var then). Without that we need to ask bug reporters to install latest git and run the dumper tools from there. Otoh we do ask them to grab latest i-g-t git almost every time, anyway ... -Daniel -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/10] [RFC v2] quick dump
On Mon, Feb 04, 2013 at 04:10:55PM +0100, Daniel Vetter wrote: On Sun, Feb 03, 2013 at 10:13:10AM -0800, Ben Widawsky wrote: On Sun, Feb 03, 2013 at 12:22:25PM +, Chris Wilson wrote: On Sun, Feb 03, 2013 at 10:29:15AM +0100, Jesse Barnes wrote: On Sat, 2 Feb 2013 16:07:52 -0800 Ben Widawsky b...@bwidawsk.net wrote: This is my second attempt at winning approval for the series. First one was: https://patchwork.kernel.org/patch/1493131/ In spending the time to rework this tool, I've begun to lose my belief in some of the original motivations I had. Even if you don't want to review, but just like (or dislike) what you see, I'd appreciate such comments. I'd like to see it land in i-g-t. Having the regs defined in a text or xml file is an improvement over what we have today, and is easier to extend. At first the advantage of reg_dumper was that it parsed out the bitfields of the various regs. But we didn't keep up with that, and also haven't kept up with the regs on new platforms as well as we could. Text files would make that easier, and xml files might bring back the bit field parsing, which would be extra nice. Completely agree. For me the big improvement would be being able to use the bspec register names or our internal approximation thereof rather than having to loop up the actual addresses every time. Having the name database available in python should make building integrated little snippets to parse traces which are also python accessible. -Chris It's really nice to get support from you. A mix of fever and staring at the same code too long can really make someone go crazy. Still, a few concerns left from me, one of which I accidentally left out of the description. - Someone needs to give me a yes or no on the m4 extension macros. This will block any pushing. - The build kind of sucks on Arch because of Arch's choices regarding python libraries. To build this on Arch, you must run something like: ./autogen.sh PYTHON_LDFLAGS=-L/usr/lib/python3.3 -lpython3.3m I really don't like autogen not working out of the box. Perhaps I need to add an AC_ flag to default this tool to off? What do others think? Does it work properly on other distros? How to handle this? - Ideally, I'd like someone to send me some fixes for valleyview definitions if they're needed. I am not sure. Jesse, if you can send me a list of DPIO offsets to read, I'll add the appropriate patch. (It can wait until you get back). Yeah, I like. Can't help you with the autfoo though :( And no opinion on the m4 macro stuff, I guess you need to poke our legal guys quickly for this. Okay, I think I've satisfied myself, from the project page: http://savannah.gnu.org/projects/autoconf-archive/ Every single one of those macros can be re-used without imposing any restrictions whatsoever on the licensing of the generated configure script. In particular, it is possible to use all those macros in configure scripts that are meant for non-free software The only thing to ponder imo is whether we should add intel_ prefixes to the tools and add all the new files to the install target (probably need tos shove the data files somewhere in var then). Without that we need to ask bug reporters to install latest git and run the dumper tools from there. Otoh we do ask them to grab latest i-g-t git almost every time, anyway ... -Daniel I've gone back and forth as to whether or not I want to robustly support this from make install. I'm not really too certain of the correct way to install python scripts, so I've mostly punted on this. My feeling for now is, let's make it work in tree, and when it becomes more useful, make sure it works with make install. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/10] [RFC v2] quick dump
On Sat, 2 Feb 2013 16:07:52 -0800 Ben Widawsky b...@bwidawsk.net wrote: This is my second attempt at winning approval for the series. First one was: https://patchwork.kernel.org/patch/1493131/ In spending the time to rework this tool, I've begun to lose my belief in some of the original motivations I had. Even if you don't want to review, but just like (or dislike) what you see, I'd appreciate such comments. I'd like to see it land in i-g-t. Having the regs defined in a text or xml file is an improvement over what we have today, and is easier to extend. At first the advantage of reg_dumper was that it parsed out the bitfields of the various regs. But we didn't keep up with that, and also haven't kept up with the regs on new platforms as well as we could. Text files would make that easier, and xml files might bring back the bit field parsing, which would be extra nice. Acked-by: Jesse Barnes jbar...@virtuousgeek.org Jesse ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/10] [RFC v2] quick dump
On Sun, Feb 03, 2013 at 10:29:15AM +0100, Jesse Barnes wrote: On Sat, 2 Feb 2013 16:07:52 -0800 Ben Widawsky b...@bwidawsk.net wrote: This is my second attempt at winning approval for the series. First one was: https://patchwork.kernel.org/patch/1493131/ In spending the time to rework this tool, I've begun to lose my belief in some of the original motivations I had. Even if you don't want to review, but just like (or dislike) what you see, I'd appreciate such comments. I'd like to see it land in i-g-t. Having the regs defined in a text or xml file is an improvement over what we have today, and is easier to extend. At first the advantage of reg_dumper was that it parsed out the bitfields of the various regs. But we didn't keep up with that, and also haven't kept up with the regs on new platforms as well as we could. Text files would make that easier, and xml files might bring back the bit field parsing, which would be extra nice. Completely agree. For me the big improvement would be being able to use the bspec register names or our internal approximation thereof rather than having to loop up the actual addresses every time. Having the name database available in python should make building integrated little snippets to parse traces which are also python accessible. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/10] [RFC v2] quick dump
On Sun, Feb 03, 2013 at 12:22:25PM +, Chris Wilson wrote: On Sun, Feb 03, 2013 at 10:29:15AM +0100, Jesse Barnes wrote: On Sat, 2 Feb 2013 16:07:52 -0800 Ben Widawsky b...@bwidawsk.net wrote: This is my second attempt at winning approval for the series. First one was: https://patchwork.kernel.org/patch/1493131/ In spending the time to rework this tool, I've begun to lose my belief in some of the original motivations I had. Even if you don't want to review, but just like (or dislike) what you see, I'd appreciate such comments. I'd like to see it land in i-g-t. Having the regs defined in a text or xml file is an improvement over what we have today, and is easier to extend. At first the advantage of reg_dumper was that it parsed out the bitfields of the various regs. But we didn't keep up with that, and also haven't kept up with the regs on new platforms as well as we could. Text files would make that easier, and xml files might bring back the bit field parsing, which would be extra nice. Completely agree. For me the big improvement would be being able to use the bspec register names or our internal approximation thereof rather than having to loop up the actual addresses every time. Having the name database available in python should make building integrated little snippets to parse traces which are also python accessible. -Chris It's really nice to get support from you. A mix of fever and staring at the same code too long can really make someone go crazy. Still, a few concerns left from me, one of which I accidentally left out of the description. - Someone needs to give me a yes or no on the m4 extension macros. This will block any pushing. - The build kind of sucks on Arch because of Arch's choices regarding python libraries. To build this on Arch, you must run something like: ./autogen.sh PYTHON_LDFLAGS=-L/usr/lib/python3.3 -lpython3.3m I really don't like autogen not working out of the box. Perhaps I need to add an AC_ flag to default this tool to off? What do others think? Does it work properly on other distros? How to handle this? - Ideally, I'd like someone to send me some fixes for valleyview definitions if they're needed. I am not sure. Jesse, if you can send me a list of DPIO offsets to read, I'll add the appropriate patch. (It can wait until you get back). -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
