The video is decoded with these options.
It is, but the frames are just discarded. Whenever I've used mplayer as a benchmark previously, it was always inclusive of rendering them to the display, which is far more important if you are trying to judge whether a system is capable of playing back the video or not (which is what I was doing, rather than basic benchmarking).
Early indications from the RageMem benchmarks suggested that there are problems with VRAM write speeds. At a guess, I'd assume these were driver related at this stage given the hardware is PCIe based. However, if anybody wanted to give the system a real drubbing, which I'm sure plenty of people do, there's your ideal opportunity. Quick, before anybody notices that and fixes it :lol:
Seriously though, right now, the PA6T is uncharted territory for existing software. It's a 64-bit processor running in 32-bit mode. To me, that raises a lot of questions. Are those old optimisations we're used to for the 32-bit machines still valid? Or are they a hindrance? In my personal experience, the PPC can be a huge pain in the arse when it comes to micro optimizing. For anybody unsure about this, Apple's PPC optimized memcpy() implementation is fascinating reading.
We're basing all out our conclusions so far on applications compiled for earlier PPC processors. I'd be interested to see what software actually optimized for PA6T (even in 32-bit mode) is capable of.
