Re: Possible GSoC idea: MIPS N32 ABI Port
Hi, On Fri, Mar 01, 2013 at 06:21:38PM -0800, Matt Turner wrote: - Making the X server work on 2F. Lemote (or someone?) wrote patches, but they're awful hacks not suitable for upstream. Real work needs to happen here. - There are patches for the siliconmotion DDX that use MMI to speed up YUV colorspace conversion. This code should really be in pixman, with the X server using that. I've used X (from Debian) on 2F, so it must work. :-) So I guess you are talking about optimizations here? No, not optimizations, and an unpatched X server does not work with the siliconmotion driver on Yeeloong. Are you using the siliconmotion driver or fbdev? I have Fuloong mini-PC, which doesn't have siliconmotion HW. I didn't realize Lemotes laptops are different in this regard... A. -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130302111004.gf22...@blackmetal.musicnaut.iki.fi
Re: Possible GSoC idea: MIPS N32 ABI Port
Hi, On Sat, Mar 2, 2013 at 3:01 AM, Matt Turner matts...@gmail.com wrote: On Fri, Mar 1, 2013 at 10:35 AM, Aron Xu happyaron...@gmail.com wrote: This was a project in GSoC 2009, however the project wasn't completed due to various reasons. I'm raising it here again because there are interests of doing it around us again. Original description from the GSoC2009 project: This project first focuses on creating a new MIPS N32 ABI port for Debian. Different from O32 and N64, N32 is an address model which has most 64-bit capabilities but using 32-bit data structures to save space and process time. A second focus will be given on making such a “mipsn32el” arch fully optimized for the Loongson 2F CPU which gains more and more popularity in subnotebooks/netbooks in many countries. Multiarch support is almost landed in Debian, and Multiarch cross build is on its way, so we are in a position to make use of such technology during bootstrap (still not working that well, though) and daily use. A user can run an n64 kernel + mixed n32/n64 userland, so that he/she can take advantage of the performance and large memory as needed (like i386/amd64 in some degree). -- Regards, Aron Xu Disclaimer: I'm not a Debian developer or even a user. I am, however, a Gentoo/MIPS developer who completed our n32 port. There were some annoying bits, like packages that hardcode 'lib', but overall it's not a difficult task. Other distributions are already n32, so there's not much if any package porting to do. The scope of this project would be entirely within Debian, getting Debian's infrastructure going for n32. I don't personally think that's a SoC project, but I don't know. Maybe a Debian/n32 port involves lots of work I don't know about, but for Gentoo it was mostly recompile a bunch of stuff and fix things that break. IIRC, I was *terribly* unimpressed with the 2009 Port Debian to N32 project. It was just a recompile everything and see what breaks endeavor, which is what other people have done with much more success (see: Gentoo, Parabola). I think the scope of this project is bootstrapping the port for Debian, which is mostly to properly bootstrap a sbuild and get the base chroot (build-essential) running. If the project can go further, then pushing the port to debian-ports.org will be good. Rebuilding packages cost mostly just some time, while I think bootstrapping a Debian port is a candidate for SoC, so it's not for porting applications, but bring n32/n64 to Debian users. As far as an 'mipsn32el' port for Loongson 2F hardware goes: what does this entail? Recompiling everything with -march=loongson2f? Gentoo (and I think Parabola?) already do this. Besides questionable usefulness, since the hardware is sort of obsoleted by new Loongson 3A hardware, the actual work to do involves getting code upstream that Lemote was too lazy to upstream. This is a whole other project by itself, again, of questionable usefulness and too nebulous to be a SoC project. If you do this project, a suggestion: Ship gcc as an n64 binary. n32 has a virtual memory limit of 2G, so a n32 gcc binary would be unable to build large projects like webkit. As mentioned about the availability of Multiarch support in my initial email, the project itself should not be limited to N32. It's worthy to discuss further on details of this idea. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w6QRKbTkUxhxtiËkFB0XX+EWt7iZuhQw=r2-oypp...@mail.gmail.com
Re: Possible GSoC idea: MIPS N32 ABI Port
On 03/01/2013 11:24 AM, Aron Xu wrote: Hi, On Sat, Mar 2, 2013 at 3:01 AM, Matt Turner matts...@gmail.com wrote: On Fri, Mar 1, 2013 at 10:35 AM, Aron Xu happyaron...@gmail.com wrote: This was a project in GSoC 2009, however the project wasn't completed due to various reasons. I'm raising it here again because there are interests of doing it around us again. Original description from the GSoC2009 project: This project first focuses on creating a new MIPS N32 ABI port for Debian. Different from O32 and N64, N32 is an address model which has most 64-bit capabilities but using 32-bit data structures to save space and process time. A second focus will be given on making such a “mipsn32el” arch fully optimized for the Loongson 2F CPU which gains more and more popularity in subnotebooks/netbooks in many countries. Multiarch support is almost landed in Debian, and Multiarch cross build is on its way, so we are in a position to make use of such technology during bootstrap (still not working that well, though) and daily use. A user can run an n64 kernel + mixed n32/n64 userland, so that he/she can take advantage of the performance and large memory as needed (like i386/amd64 in some degree). I am not a Debian developer either, however I am a user. If the project is accepted, and if it would help, We (Cavium, Inc.) can supply a machine for you to use for development. This would be a Cavium OCTEON based system (MIPS64r2 x 12 CPU SMP w/ 4GB RAM and 1TB SATA disk). I am also quite familiar with n32 and can answer most questions about this ABI. David Daney -- Regards, Aron Xu Disclaimer: I'm not a Debian developer or even a user. I am, however, a Gentoo/MIPS developer who completed our n32 port. There were some annoying bits, like packages that hardcode 'lib', but overall it's not a difficult task. Other distributions are already n32, so there's not much if any package porting to do. The scope of this project would be entirely within Debian, getting Debian's infrastructure going for n32. I don't personally think that's a SoC project, but I don't know. Maybe a Debian/n32 port involves lots of work I don't know about, but for Gentoo it was mostly recompile a bunch of stuff and fix things that break. IIRC, I was *terribly* unimpressed with the 2009 Port Debian to N32 project. It was just a recompile everything and see what breaks endeavor, which is what other people have done with much more success (see: Gentoo, Parabola). I think the scope of this project is bootstrapping the port for Debian, which is mostly to properly bootstrap a sbuild and get the base chroot (build-essential) running. If the project can go further, then pushing the port to debian-ports.org will be good. Rebuilding packages cost mostly just some time, while I think bootstrapping a Debian port is a candidate for SoC, so it's not for porting applications, but bring n32/n64 to Debian users. As far as an 'mipsn32el' port for Loongson 2F hardware goes: what does this entail? Recompiling everything with -march=loongson2f? Gentoo (and I think Parabola?) already do this. Besides questionable usefulness, since the hardware is sort of obsoleted by new Loongson 3A hardware, the actual work to do involves getting code upstream that Lemote was too lazy to upstream. This is a whole other project by itself, again, of questionable usefulness and too nebulous to be a SoC project. If you do this project, a suggestion: Ship gcc as an n64 binary. n32 has a virtual memory limit of 2G, so a n32 gcc binary would be unable to build large projects like webkit. As mentioned about the availability of Multiarch support in my initial email, the project itself should not be limited to N32. It's worthy to discuss further on details of this idea. -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/513134bd.8090...@gmail.com
Re: Possible GSoC idea: MIPS N32 ABI Port
Hi, On Fri, Mar 01, 2013 at 11:01:20AM -0800, Matt Turner wrote: Besides questionable usefulness, since the hardware is sort of obsoleted by new Loongson 3A hardware, the actual work to do involves getting code upstream that Lemote was too lazy to upstream. What code are you referring to? BTW, what are the practical benefits of this effort, especially on Loongson 2F HW? (Any performance figures?) A. -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130301231016.gb22...@blackmetal.musicnaut.iki.fi
Re: Possible GSoC idea: MIPS N32 ABI Port
On Fri, Mar 1, 2013 at 3:10 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, On Fri, Mar 01, 2013 at 11:01:20AM -0800, Matt Turner wrote: Besides questionable usefulness, since the hardware is sort of obsoleted by new Loongson 3A hardware, the actual work to do involves getting code upstream that Lemote was too lazy to upstream. What code are you referring to? The things I know about are: - handling NaN cases for Loongson-specific floating-point instructions in the kernel FPU emulator. There are some patches, but they need to go through review and a bit of clean up. - Making the X server work on 2F. Lemote (or someone?) wrote patches, but they're awful hacks not suitable for upstream. Real work needs to happen here. - There are patches for the siliconmotion DDX that use MMI to speed up YUV colorspace conversion. This code should really be in pixman, with the X server using that. I've spent /some/ time on each of these. BTW, what are the practical benefits of this effort, especially on Loongson 2F HW? (Any performance figures?) Not having to apply hacky patches the kernel and X server to have a usable system seems like an intrinsic benefit to me. As far as performance goes, maybe you could find something to optimize with the MMI instructions like I did for pixman [1]. I'm not sure what though. I think MIPS (the company) contributed a MIPS-backend to Firefox's JavaScript JIT compiler but only for o32. Updating it, or perhaps contributing a new one, for N32/N64 might make a nice project. It would certainly improve the Firefox user experience on Loongson. That would be useful for Loongson 2F, 3A, and any other hardware that's n32-capable. [1] http://mattst88.com/blog/2012/05/17/Optimizing_pixman_for_Loongson:_Process_and_Results/ -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAEdQ38Eh=jdwjjuk-nzmczqdnt+xtgj-34q9a83z383ezht...@mail.gmail.com
Re: Possible GSoC idea: MIPS N32 ABI Port
On Fri, Mar 01, 2013 at 04:14:56PM -0800, Matt Turner wrote: On Fri, Mar 1, 2013 at 3:10 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, On Fri, Mar 01, 2013 at 11:01:20AM -0800, Matt Turner wrote: Besides questionable usefulness, since the hardware is sort of obsoleted by new Loongson 3A hardware, the actual work to do involves getting code upstream that Lemote was too lazy to upstream. What code are you referring to? The things I know about are: - handling NaN cases for Loongson-specific floating-point instructions in the kernel FPU emulator. There are some patches, but they need to go through review and a bit of clean up. Does (mainline) toolchains generate these instructions? But this sounds like a real issue. - Making the X server work on 2F. Lemote (or someone?) wrote patches, but they're awful hacks not suitable for upstream. Real work needs to happen here. - There are patches for the siliconmotion DDX that use MMI to speed up YUV colorspace conversion. This code should really be in pixman, with the X server using that. I've used X (from Debian) on 2F, so it must work. :-) So I guess you are talking about optimizations here? BTW, what are the practical benefits of this effort, especially on Loongson 2F HW? (Any performance figures?) Not having to apply hacky patches the kernel and X server to have a usable system seems like an intrinsic benefit to me. (Actually, I meant the actual measured benefit of n32 vs. current ABI. I of course agree all critical patches should be upstreamed.) As far as performance goes, maybe you could find something to optimize with the MMI instructions like I did for pixman [1]. I'm not sure what though. I think MIPS (the company) contributed a MIPS-backend to Firefox's JavaScript JIT compiler but only for o32. Updating it, or perhaps contributing a new one, for N32/N64 might make a nice project. It would certainly improve the Firefox user experience on Loongson. That would be useful for Loongson 2F, 3A, and any other hardware that's n32-capable. Last time I tried to use latest iceweasel/firefox, it failed due to assumption of 4 KB page size. So the first thing to improve user experience would be to fix all userspace not to assume any specific page size... Or maybe fix kernel so that 4 KB page can be used again on Loongson. Until that n32 won't help nothing. A. -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130302004634.ge22...@blackmetal.musicnaut.iki.fi
Re: Possible GSoC idea: MIPS N32 ABI Port
On Fri, Mar 1, 2013 at 4:46 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: On Fri, Mar 01, 2013 at 04:14:56PM -0800, Matt Turner wrote: On Fri, Mar 1, 2013 at 3:10 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, On Fri, Mar 01, 2013 at 11:01:20AM -0800, Matt Turner wrote: Besides questionable usefulness, since the hardware is sort of obsoleted by new Loongson 3A hardware, the actual work to do involves getting code upstream that Lemote was too lazy to upstream. What code are you referring to? The things I know about are: - handling NaN cases for Loongson-specific floating-point instructions in the kernel FPU emulator. There are some patches, but they need to go through review and a bit of clean up. Does (mainline) toolchains generate these instructions? But this sounds like a real issue. Yes, these instructions are generated. Problems are rare since it involves (IIRC) the instruction being given NaN or QNaN as input, though they have been seen: https://groups.google.com/forum/?fromgroups=#!topic/loongson-dev/vdtRTO-c5Bg - Making the X server work on 2F. Lemote (or someone?) wrote patches, but they're awful hacks not suitable for upstream. Real work needs to happen here. - There are patches for the siliconmotion DDX that use MMI to speed up YUV colorspace conversion. This code should really be in pixman, with the X server using that. I've used X (from Debian) on 2F, so it must work. :-) So I guess you are talking about optimizations here? No, not optimizations, and an unpatched X server does not work with the siliconmotion driver on Yeeloong. Are you using the siliconmotion driver or fbdev? BTW, what are the practical benefits of this effort, especially on Loongson 2F HW? (Any performance figures?) Not having to apply hacky patches the kernel and X server to have a usable system seems like an intrinsic benefit to me. (Actually, I meant the actual measured benefit of n32 vs. current ABI. I of course agree all critical patches should be upstreamed.) Ah, I see. In general N32 provides performance improvements over O32, yes. It allows - native 64-bit integer operations; - passing more than four (?) function arguments by register; - double the number of floating-point registers. Double the number of floating-point registers is hugely important for pixman's Loongson MMI code, and thus graphics in general since basically all rendering is done in software (via pixman) on the 2F+siliconmotion. I'm sure I've done some general benchmarks, but I don't have numbers easily available. As far as performance goes, maybe you could find something to optimize with the MMI instructions like I did for pixman [1]. I'm not sure what though. I think MIPS (the company) contributed a MIPS-backend to Firefox's JavaScript JIT compiler but only for o32. Updating it, or perhaps contributing a new one, for N32/N64 might make a nice project. It would certainly improve the Firefox user experience on Loongson. That would be useful for Loongson 2F, 3A, and any other hardware that's n32-capable. Last time I tried to use latest iceweasel/firefox, it failed due to assumption of 4 KB page size. So the first thing to improve user experience would be to fix all userspace not to assume any specific page size... Indeed. Or maybe fix kernel so that 4 KB page can be used again on Loongson. Until that n32 won't help nothing. It does (just not on Loongson 2). Avoiding the Firefox problem with page sizes and making the kernel use 4K pages is, I imagine at least, the thinking that has led to lots of hacky patches not being upstream. :) For reference, 315fe625 is the relevant kernel commit that disabled 4K pages on Loongson. Since 4K pages would require extra cache flushing to avoid aliasing problems, it's definitely not what you want to do if you care about performance. -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAEdQ38GgSrO5xrsdiZBOCfrsjqsa0M0F-LE=x8R1DjFYAq=3...@mail.gmail.com
Re: [Soc-coordination] Possible GSoC idea: MIPS N32 ABI Port
On Sat, Mar 02, 2013 at 02:35:34AM +0800, Aron Xu wrote: This was a project in GSoC 2009, however the project wasn't completed due to various reasons. I'm raising it here again because there are interests of doing it around us again. Original description from the GSoC2009 project: This project first focuses on creating a new MIPS N32 ABI port for Debian. Different from O32 and N64, N32 is an address model which has most 64-bit capabilities but using 32-bit data structures to save space and process time. A second focus will be given on making such a “mipsn32el” arch fully optimized for the Loongson 2F CPU which gains more and more popularity in subnotebooks/netbooks in many countries. Multiarch support is almost landed in Debian, and Multiarch cross build is on its way, so we are in a position to make use of such technology during bootstrap (still not working that well, though) and daily use. A user can run an n64 kernel + mixed n32/n64 userland, so that he/she can take advantage of the performance and large memory as needed (like i386/amd64 in some degree). Aye! After the brand new arm64 porting effort, I'm keen to see this duplicated with another arch like that. There's a lot of work in setting up a port, and I think the crossbuild / porting effort is worthwhile as a GSoC project. Very cool. Any mentors lined up? -- Regards, Aron Xu ___ Soc-coordination mailing list soc-coordinat...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/soc-coordination Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
