Måns went and got one of those Sheeva Plugs— the wall-wart form factor computer that is a self-contained ARM-based computer. Of course it’s already in service doing FATE duty. This is an ARMv5TE CPU which is in contrast the the ARMv7 series on the Beagle Board. This is why there are 2 blocks of ARM results on the FATE page.
In other FATE news, I activated 10 new tests tonight: v210, for the V210 10-bit YUV format; and 9 more fidelity range extension H.264 conformance vectors.
Could you maybe place the two ARM entries on the FATE homepage next to each other? That makes more sense IMO.
@Diego:
Mike can’t (yet) place the FATE entries in specific order at all. Since he’s working on a more elaborate front page I guess it would be a bit pointless to spend much time on this one…
And I just realized: what happened to our Windows builds?
I mean the front page is crowded enough, I don’t mind them missing there just like PPC64, but PPC64 at least still submits results so when something breaks you can still find out when it happened (if you know the configuration ID).
And hey, it’s running Gentoo, right on. :)
I don’t know why you keep complaining about the website, Mike, I think it’s perfectly readable right now. I kinda like it the way it is.
Also, I was just thinking — it shouldn’t make any difference, I imagine, but what about running another x86_64 on an AMD machine as well? Do you have all the hardware yourself physically at your location, or is some of it remote?
@Diego, Reimar has it right. Any change to the web presentation at this stage requires horrendous effort on my part (I’m really bad at this stuff). A redesign will occur after I upgrade the current FATE backend to support more kinds of tests. The current order of the blocks is merely a function of the order in which records were added to the ‘machine’ SQL table (PPC was the first; ARMv5TE is the most recent).
@Reimar: Ramiro’s Windows machine had some hardware failures so I deactivated the Windows builds on the front page since they would just get stale. About PPC64: At one point, I noticed that PPC64 builds hadn’t moved forward in several weeks so I figured those results weren’t coming in anymore. Was that a temporary problem? If so, I can reinstate them to the front page.
@Steve Dibb: I handle all the hardware for the top 5 groups (just because I was first): Linux on PPC, x86_32, and x86_64, as well as Mac OS X on x86_32 and x86_64. All the remainder of the configurations are contributed by other generous developers (with MÃ¥ns contributing a remarkable diversity). It would be possible to run AMD64, sure. But is it really that valuable? gcc would generate the same code as for EM64T. Are there common problems with generated code not running on one platform or the other?
Doesn’t this cpu support IWMMXT ?
Which CPU? There are a lot of CPUs being discussed in this thread.
@Mike:
sometimes the FATE program stops running on the PPC64 (e.g. due to a maintenance reboot) and I just don’t notice it.
I don’t think there is much point for it on the main page, the gcc 4.3.1 only has internal compiler errors and the 4.1.2 behaves basically identical to the 32 bit PPC.
I’ll see if I manage to set up a FATE config on some Windows system. It would only run when I start it manually maybe once a day but if nobody else is ready to do Windows that seems better than nothing…
About AMD64: in theory some 3DNOW code might be run on those, but unless SSE/SSE2 is disable there is almost no 3DNOW code.
@mat: The Marvell Feroceon 88FR131 used in the SheevaPlug implements the ARMv5TE architecture which does not include iwmmxt. That was supported only on Intel Xscale CPUs.