[Soc-coordination] Possible GSoC idea: MIPS N32 ABI Port

[Matt Turner]

On Fri, Mar 1, 2013 at 4:46 PM, Aaro Koskinen <aaro.koskinen at 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.koskinen at 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.