First Look: AMD Trinity APU, Linux Already Runs Well
Remember those AMD Bulldozer benchmarks we showed back in March from an early engineering sample that was published to OpenBenchmarking.org by one of AMD's partners months prior to the product launch? Well, since the consumer-grade Bulldozer chips are going to be out soon, AMD's partners are already supplying information on the AMD Trinity APUs that won't be launched until next year. The Linux performance appears quite competitive and there's also some new codenames and details to share.
This weekend while browsing OpenBenchmarking.org when deciding what features to work on next for this collaborative testing platform that's integrated into the Phoronix Test Suite, I stumbled upon more data from some engineering samples that were submitted in recent weeks. It happened to be just like the discovery of the dual-Interlagos results earlier this year -- when an AMD government partner was running the Phoronix Test Suite and knowingly decided to share their Linux benchmark results with the world using OpenBenchmarking.org. With Bulldozer now coming to market, AMD's partners are now already looking towards Trinity. From what I have found so far, the Trinity data at hand comes from two AMD partners this time and also one system that's even traced back to Sunnyvale, California.
Trinity is the Fusion successor to the recently launched Llano APUs. AMD has publicly acknowledged Trinity and said the new hardware will be available in 2012. They've also said that the performance is roughly 50% faster than Llano. The Trinity results I've seen under Linux have been impressive, but tough to compare to my current Llano hardware due to other hardware differences. The Catalyst graphics support seems a bit premature, but we're still months away from the actual Trinity launch. The compute performance is at least in order.
As far as why AMD and their partners are already publicly posting results, I really have no idea. When running the Phoronix Test Suite, sharing results is *always optional* and the user is prompted whether they would like to upload their results or not to OpenBenchmarking or opt-in to submitting system software/hardware details. All of the testing works fine without any Internet connectivity or sharing. Intel and the dozens of other IHVs using the Phoronix Test Suite on pre-production hardware have no problems, but AMD's partners working on engineering samples seem to treat testing in a haphazard manner and have no issues knowingly pushing out information early. (AMD GPG at least does their testing in a better manner, with having used my open-source testing infrastructure for several years.) Thank you though, since AMD rarely sends CPU samples to Phoronix.com [even though they're freely using software I've developed for Linux performance validation and automated testing], in order to supply compatibility information and benchmarks to the Linux community, I'm often waiting until I can buy the hardware or when granted remote SSH access to systems from others with early AMD hardware access. With careless (or perhaps just being very nice) AMD partners, there's already details for Linux users on Trinity.
One of the AMD Linux engineering systems for Trinity is running nicely even on Ubuntu 11.04 with the Linux 2.6.38 kernel. The CPU string is AMD Eng Sample 2M252057C4450_32/25/16_9900_609 and its graphics are the Trinity Devastator Mobile with 512MB of video memory and an AMD Pumori motherboard. The PCI ID on the Trinity Devastator appears to be 0x9900. This Trinity APU is quad-core and running at 2.50GHz. The current quad-core Llano offerings are clocked at 2.6GHz (A6-3650) and 2.9GHz (A8-3850), while this Trinity part is clocked slower, it's numbers are nice compared to my A8-3850 Linux system.
It appears that the graphics acceleration support for the Trinity Devastator is in place as of the fglrx 8.90 release stream. It's nice to see the Trinity APU working with Ubuntu 11.04, albeit on the proprietary driver. By the time Trinity is officially out, Ubuntu 12.04 LTS should be here and hopefully with mature support and perhaps some performance optimizations within the GCC compiler.