Thread: Anandtech News

Earlier this evening Google announced the sale of Motorola Mobility to hardware manufacturer Lenovo for a deal valued at just below $3 billion. Given my fondness for the Moto X and Moto G, two of the best ergonomically executed handsets in the Android space from my perspective, I had a bunch of thoughts about this deal that I wanted to get down in writing.
I'll start off with a bit of praise for Motorola. The transformation of the company post-Google-acquisition has been nothing short of awesome. The in-hand feel of the Moto X and Moto G remain unparalleled by any competing Android device in my opinion. I absolutely understand that's personal preference, but the next three points aren't. With the Moto X, Motorola bucked the trend of higher CPU core counts (disregarding their driving-me-to-drink 8-core messaging for a moment) and instead opted for two high frequency CPU cores that ultimately delivered better thermally bound CPU performance than the quad-core alternative. Motorola also was the first Android vendor I came across to think of addressing the issue of random IO performance, in this case by deploying a NAND Flash aware file system (f2fs) on the Moto G and X. Finally, Motorola is one of very few Android OEMs that doesn't blatantly cheat in a whole host of terrible smartphone benchmarks. In short, I like the new Motorola. The good news is that I'm not sad to see the company go to Lenovo.
Lenovo doesn't have a history of ruining brands. Its acquisition of IBM's PC business seems to have done well, and I can only assume that Lenovo has the same intents with Motorola. Acquisitions that strengthen the position of the acquirer are (understandably) sensible ones, and here we're talking about two relatively small players in the overall smartphone industry combining with hopes of increasing market (and revenue) share. With both Motorola and Lenovo controlling single digit percentages of the smartphone market (1.3% and 5.1%, respectively, according to Gartner) it's clear that neither party has a chance independently. Lenovo could leverage its position in China, while Motorola would hopefully be able to do the same in the US (although with a much steeper slope to climb). So far the deal makes sense, although it doesn't guarantee anywhere near instant success.
The basic fact is that it seems like it's difficult to turn a profit, even in the face of substantial revenue, in the smartphone space. LG and HTC have both struggled here, while Apple and Samsung do quite well. Apple aims squarely at the high end, while Samsung arrives at great profits through a combination of factors - not the least of which is its ability to act as both an integrator and supplier of technologies.
While odds against turning a substantial profit would point to this deal being a bad (or neutral) one, if there's a company that knows how to successfully compete in a low margin business it's Lenovo. In a world where being a PC OEM is hardly desirable, Lenovo seems to have done fairly well. Leveraging its presence in China as well as higher margins from its corporate business, Lenovo has been able to support and reinvent its consumer facing PC business. It's entirely possible (likely?) that Lenovo views it can repeat the same success in smartphones.
(Side note: if smartphones end up being low margin businesses for most companies, that potentially increases the reliance of smartphone vendors on reference designs from silicon vendors - drawing an interesting parallel to how things work in the PC space.)

Google's position in all of this is interesting. CEO Larry Page posted his thoughts on the sale to Google's official blog. I'd like to call out a couple of important quotes:
"...the smartphone market is super competitive, and to thrive it helps to be all-in when it comes to making mobile devices."
and
"As a side note, this does not signal a larger shift for our other hardware efforts. The dynamics and maturity of the wearable and home markets, for example, are very different from that of the mobile industry. "
The first point solidifies Google's position with regards to Android. It will be an OS and services provider, relying on its partners to build the hardware. Monetization comes from mobile search advertising, location based advertising and general mobile data mining. At a high level this is the Windows/PC ecosystem strategy, except instead of charging a ton for an OS license Google makes its money in these other ways. 
I have to point out that although Microsoft was once a proponent of this approach, as of late it seems to have lost some faith (for good reason) in the PC OEM ecosystem and chose to throw its hat in the ring with Surface. It took PCs a very long time to get to this point, and I suspect if the same end result happens to the Android ecosystem it will take a while before it gets there either. Following the Microsoft model makes a lot of sense from the perspective of growing marketshare. Given how Google primarily monetizes Android today, being in the software/services business and leaving hardware up to its partners is absolutely the right move for the company. If we've learned anything from watching the PC evolve however, it's that OEMs participating in a low margin business tend to prioritize profits first and user experience second. My hope for a Google-owned Motorola was a device vendor that was independent of that mess, but as I just mentioned I don't see this being a problem for some time to come.
Larry's side note above also makes sense, it tells us a lot about Google's willinginess to play in the hardware space. In a sense, Google won't be a fast follower but it will gladly reap the rewards of a being a first mover in any industry. Focus is extremely important for the success of any company, big or small, and in this case Google is doing right by its shareholders and being focused. Google is absolutely an early mover in the wearables space and with its acquisition of Nest you can say the same thing for its role in the connected home. As I wrote about the Galaxy Gear not too long ago, with those in the smartphone space addicted to exponential growth, a maturing market drives almost everyone to look for the next big thing. There are a handful of these markets that seem feasible in the near term: automotive tech, connected home and wearable computing (+ maybe a category for things like the Oculus Rift).
Android is turning out to be the mid-90s Windows of the mobile space, while Google wants Glass and Nest to be the iPhones of wearables and the connected home. I can definitely see the former, and I think Nest absolutely puts Google on the right right for the latter, I am uncertain about how Glass plays out in the wearables space over time. The wearables market is still very much in its infancy.

More...

If you had asked me a few years ago, I would've said that hybrid drives will be the next big thing in the storage industry. A hybrid drive made so much sense -- it combined the performance of an SSD with the capacity of a hard drive in an affordable and easy to use package. WD's Black² takes a different approach and instead of being a hybrid drive, it's a dual-drive with full user control of the SSD. Is it a better concept than the hybrid drives we've seen so far? Read on to find out.

More...

In the motherboard section of AnandTech, we rarely touched the audio section of the motherboard until fairly recently.  Audio is a delicate issue, and knowledge on the subject falls into a wide range from the tone deaf all the way to the hyper enthusiast.  Professional and prosumer audio equipment can be honed to perfection and cost an appropriate amount, where discussion on quality over $10k per meter cables can happen.  It is very hard to quantify an audio experience into a single set of rules, but as the motherboard arena can feature rather elaborate audio setups designed to enhance the quality or provide sufficient electrical filtering, and that these can be some of the major selling points, several of our readers asked us to start testing the audio.

To put this into perspective, a motherboard manufacturer can create an audio portion of the motherboard that costs $2 to buy and implement.  Another manufacturer will spend $20 to get a better audio codec and DAC, better audio filters, headphone amplifiers, and specifically separate the digital and audio traces on the motherboard as to reduce potential sources of interference, as well as focusing on a single output to achieve all this.  Part of testing these scenarios is producing such a test that a reader can relate to, as well as a series of numbers for comparison to put in the review – both manufacturers and readers want to see that their hard earned engineering money and effort went into something that can be compared.

In light of this request to test audio, looking into the best way to test it is a minefield.  The correct equipment in order to get an accurate test of dynamic range, noise and distortion costs over $10k – for example, the audio equipment used in Chris Heinonen’s recent foray into smartphone audio testing was an Audio Precision APx582, which starts at eleven thousand.  Audio Precision is often cited as the company that all audio manufacturers go to in order to test their hardware.  Unfortunately unlike Chris I am not able to source Audio Precision testing equipment due to my location and contacts, but having the hardware on hand takes everything out of the equation except the audio generator and filtering pathway that a manufacturer decides to use.

One ‘quick and easy’ test that has been in the mix and in several press pack guides is Rightmark: Audio Analyzer (RM:AA).  This is a software solution to what is ultimately a hardware problem, and relies on the same hardware doing both the signal production and the signal receiving.  This causes a number of issues, such as channel leakage, harmonic resonance in adjacent signals and that the limiting factor of the hardware being testing might affect other parts of the test.  More often than not it is also difficult to compare results between products, due to input levels and driver settings.  In order to provide accurate and comparable results, the software has to be explicitly set up for consistency and comparison, something a lot of reviewers that use RM:AA do not do.

I must confess that for a while I was in this crowd.  My RM:AA test was ultimately out of the box and produced wildly conflicting results.  When audio solutions were quoted as 108 dB for signal-to-noise ratio were getting 92 dB, the conclusions were along the lines of differences in signaling and manufacture of the motherboard. In reality, the test was very wrong – the OS by default limits input/output to 16-bit + 44.1 kHz, producing an artificial ceiling, and the volume ratio of output/input in the testing loop was not standardized.  While I kept the input/output the same, in fact each output of the audio jacks can have different responses to the audio in question.  

After delving further into the topic, we standardized the RM:AA test at AnandTech.  The OS is now set to 24-bit, 192 kHz input and output (or the highest possible based on the audio codec options), the output volume was set to 100% and the input volume adjusted to provide accurate results without over-distorting the input.  Ultimately our testing is still limited to the level of the input on the codec, often cited around 104 dB SNR compared to a 108 dB or 112 dB peak output, depending on what audio codec + DAC are used.  Even when the same 3.5mm shielded cable is used or different tests, cable losses in a uncontrolled environment can be excessive (1-2 dB SNR), and my location next to a busy main road might also introduce error.
This test is in no way perfect – we typically quote the SNR and THD+N (Total Harmonic Distortion + Noise) results as these were ultimately relevant to those who wanted cleaner and louder output, rather than a quality control test.
Recently we tested the ASUS Rampage IV Black Edition.  In this review, we noted that for ASUS’ audio solution, they used their SupremeFX technology – a shielded audio codec with separated tracing, audio filters, headphone amplifiers and gold plated connectors.  In this, ASUS use a Realtek audio codec to power a Cirrus Logic DAC, rated at 120 dB SNR and -107 dB THD+N.  Our results were well below this in terms of SNR, ~95 dB, which is substantially lower.  At the time I was unsure of the reason, and needless to say ASUS got back to me to confirm my testing methodology.
After retests on my end, and a more professional test from ASUS, we exchanged new numbers for comparison.  My initial numbers were indeed erroneous. After retesting, the ASUS Rampage IV Black Edition falls in the middle of the pack:

ASUS and I compared our SNR graphs to see the differences:

ASUS achieve a -108 dB SNR compared to my -101 dB SNR result due to ASUS using Audio Precision testing tools and my test using the Line In + RMAA methodology.  The RMAA test also relies on a 1 kHz pulse at -60 dB for its test rather than a range of frequencies, which as a result causes the peak seen at 1 kHz.
In light of the discrepancy, we are coming to a fork in the road for audio testing.  I fall wholeheartedly into the ‘tone deaf’ part of the crowd when it comes to analyzing audio and prefer an easy-to-read number as a comparison, although I understand this is not the be-all and end-all when it comes to audio.  Ideally I would like to use Chris’ setup for future motherboard tests.  I have asked Chris to perform testing on a few select models if he has time in the future, which might be in the works.  But I do not have access to an AP testing setup, and my current solution sits with RM:AA.  ASUS has offered to provide their results in future press packs, although independent verification is what we want to report.  In light of motherboard development we may see other manufacturers doing it also.  In order to improve our reporting in this area, I will in future publish the SNR graphs we receive from RM:AA for comparison.

More...

There's been some level of uncertainty regarding OCZ and especially the outstanding product warranties. I covered OCZ's situation and its position at Toshiba in our Vertex 460 review but now we've finally got the official word about warranties as well.
In short, all OCZ's latest SSDs will be covered by warranty normally, but the unfortunate news is that all non-SSD products (such as PSUs, DRAM, USB drives etc.) will not be supported at all. Outstanding product warranties were excluded from the acquisition terms, so it appears that Toshiba is only willing to cover the most necessary products, those being OCZ's most popular SSDs. Bear in mind that the acquisition only included OCZ's consumer and enterprise storage divisions -- last time I heard OCZ was looking for a buyer for its other units but it seems that they've not been able to find one.

Normal Support	Support Until Jan 22, 2015	Not Supported
Vector 150 Vector Vertex 460 Vertex 450 Vertex 4 Vertex 3 Vertex 2 Vertex RevoDrive RevoDrive 3 RevoDrive 3X2	Agility 4 Agility 3 Agility 2 Agility	ALL Non-SSD Products Core Series Apex Petrol Octane Series Solid Series Colossus Series IBIS Enyo Nocti RevoDrive Hybrid Summit Synapse Onyx Series Solid Series OCZ SATA I SSD (1st gen) OCZ SATA II SSD (1st gen)

The good news is that the most popular SSDs are covered, including the older members of the Vertex family. The Agility series will be supported for another year, meaning that some warranties of Agility 3 and 4 will be shortened. Unsupported products include the rest of OCZ's SSDs and most of these are models that were never even sampled to media. Ultimately I believe these products were also OCZ's stumbling blocks because although they were cheap, the performance was horrible and failure rates were ridiculously high. 
If you have an unsupported product, you may not be out of luck if you happen to live in EU or other region with strict consumer protection laws. Here in Finland the seller is responsible for the warranty by law and OCZ's decision to discontinue support for some products does not change that. Obviously I can't speak for other countries but this is something worth finding out in case your product fails during the original, now discontinued, warranty period. 
The full details can be found on OCZ's warranty page.

More...

After a false start or two, AMD is finally getting the first beta of Mantle out the door. With EA DICE having shipped their Mantle patch for Battlefield 4 and developer Oxide having released their Star Swarm technical demo, the first Mantle-enabled applications have landed. Meanwhile AMD for their part is still hammering out an installation issue on their new Mantle-enabled Catalyst drivers, which has led to them missing their previously scheduled January release date.
In the interim, AMD has released a slightly finickier set of drivers to the press for us to play around with ahead of the public Mantle driver release. These drivers should be functionally and performance identical to the public drivers, they just have an outstanding installation bug that requires a workaround, something that AMD doesn’t want in the shipping version. AMD hasn’t provided a public release date for these drivers – at this point it’s in their best interest to avoid providing release dates they don’t know if they can keep – but given the fact that this is the sole showstopper issue in our press drivers, we certainly don’t expect they’ll take much longer.
In any case, we’re hard at work at the moment putting together our full evaluation of this first version of Mantle. That article won’t be ready until next week, but in the meantime given the immense interest in Mantle, we wanted to quickly publish our first batch of numbers for Battlefield 4. We will have a much wider selection of benchmarks for our full article, including many more video cards and results for Star Swarm, but we wanted to quickly bring you what’s almost certainly going to be the most interesting set of data: Mantle performance with a high-end video card.

For that we’re turning to AMD’s Radeon R9 290X, testing the performance of that card under both Direct3D and Mantle in EA’s Battlefield 4. Battlefield 4 is Mantle’s showcase title and accordingly the first real world use case for AMD’s new API, making it the best place to start. As an application retrofitted with Mantle support we don’t expect Battlefield 4 to tap the complete potential of Mantle right out of the door – certainly not when the Mantle SDK and driver stack itself is still in development – but it can give us an idea of what kind of performance gains we can expect if developers chase the low-hanging fruit offered by Mantle.
What is that low-hanging fruit? For the most part that is going to be CPU bottlenecks, specifically bottlenecking in issuing draw calls. Of all of the bottlenecks that can impact a high performance GPU, keeping it fed can be the biggest bottleneck, and in turn bottlenecking in the draw call submission phase can be the biggest culprit. In the long term Mantle will also benefit GPU performance more directly by optimizing workflows within a GPU, and we already see a small bit of that today in Battlefield 4, but the bulk of the optimizations for these earliest titles have been made around the draw call bottleneck.

For our Mantle preview we’re taking a look at two sections of the Battlefield 4 single player game, the first being from the Tashgar mission and the second being from the South China Sea mission. As was the case with Battlefield 3 the use of single player is less than ideal, but as Battlefield 4 lacks a formal benchmark or for that matter the ability to record multiplayer matches, we’re left with single player if we want to have reasonably repeatable benchmarks. And we’ll definitely want a high degree of repeatability if we’re to be able to distinguish Mantle gains from variability in GPU bound scenarios.
Meanwhile to cover a wider spectrum of possibilities, we’re running our 290X against 3 CPU configurations on our GPU testbed. The first of which is our standard configuration, which is our i7-4960X with all cores and HypterThreading enabled (6C/12T), running at 4.2GHz. Our second configuration drops that down to 4C/4T at 2GHz, to test for the benefits of Mantle on a still relatively large core count at lower clockspeeds. Our final configuration takes the core count down further, to 2C/4T at 3GHz, so that we can see what performance is like for processors with fewer cores but higher clockspeeds.
Finally, on a quick note, for measuring Battlefield 4's performance we're using the game's newly built in PerfOverlay.FrameFileLogEnable feature, which replaces FRAPS in this game due to the fact that FRAPS only works with Direct3D and OpenGL. FrameFileLogEnable logs frame times for later analysis, and from this we can reconstruct the minimum and average framerates, and even the full frame pacing performance of the game (but only from the perspective of the game, not the video card). Today we'll be looking at just the average framerates, but be sure to come back next week for our full evaluation, where we'll have frame pacing data and minimum framerates ready to go.

CPU:	Intel Core i7-4960X @ 4.2GHz
Motherboard:	ASRock Fatal1ty X79 Professional
Power Supply:	Corsair AX1200i
Hard Disk:	Samsung SSD 840 EVO (750GB)
Memory:	G.Skill RipjawZ DDR3-1866 4 x 8GB (9-10-9-26)
Case:	NZXT Phantom 630 Windowed Edition
Monitor:	Sharp PN-K321
Video Cards:	AMD Radeon R9 290X (Uber)
Video Drivers:	AMD Catalyst 14.1 Beta
OS:	Windows 8.1 Pro

SP-Tashgar

Our first test comes from the Tashgar mission, and is the benchmark we will be using for day-to-day GPU benchmarking. This benchmark takes place immediately at the start of the mission, with our character driving out of the mountains and into the city of Tashgar. This benchmark has a limited CPU load and is GPU-bound in most situations, which potentially limits the benefits of Mantle in alleviating CPU bottlenecks, but gives us an idea of what kind of performance benefits we can expect in GPU-bound scenarios.

Battlefield 4 Tashgar: Mantle Performance Gains
 	Ultra	High	Low
i7-4960X 6C/12T @ 4.2GHz	8%	10%	-14%
i7-4960X 4C/4T @ 2GHz	8%	13%	26%
i7-4960X 2C/4T @ 3GHz	8%	13%	28%

Even at 1080p Ultra, where the Radeon R9 290X is clearly GPU-bound, we can see that switching to Mantle offers some performance improvements. With our i7-4960X fully powered up, this leads to an 8% performance increase, and we see similar performance increases even with other CPU configurations. Since we don’t appear to be CPU-bound in any appreciable way, this gives us a decent idea of what kind of GPU performance benefits Mantle can offer.
Meanwhile if we switch to High and Low settings, the higher framerates are able to tease out the CPU benefits of Mantle. With BF4’s High settings this is 10-13% depending on the CPU configuration, which indicates we’re still significantly GPU bound here.
Using Low quality settings on the other hand significantly widens the gap in both directions, with the minimum gain being -14%, and the maximum gain being 28%. In the case of our 6C/12T CPU configuration, Mantle actually has a detrimental impact on performance, bringing down our framerate from a positively absurd 216fps to a slightly less absurd 181fps. This was unexpected to say the least, and while we’re not particularly concerned about it given the fact that we have little reason to use this setting in day-to-day gaming, but it does point to a weakness in the current builds of BF4 and the Mantle drivers.
Otherwise if we move to our slower CPU configurations, the benefits are 26% and 28% for 4C/4T and 2C/4T respectively. Despite the fact that the 4C/4T setup has more real cores to work with, which under normal circumstances would be the stronger setup for a highly threaded application, it’s the 2C/4T setup that technically benefits the most. The difference is quite small, but it’s an interesting outcome none the less.
SP-South China Sea

Our second test comes from the South China Sea mission of Battlefield 4, where our character and his squad are on the quickly disintegrating USS Titan. Whereas our first test is rather uniformly GPU-bound, the breakup of the USS Titan offers us the chance to look at a more CPU-bound scenario. Even this scene isn’t exclusively CPU-bound, but with ship parts and other debris flying around everywhere, it’s going to be one of the more strenuous CPU workloads in the single player game.

Battlefield 4 South China Sea: Mantle Performance Gains
 	Ultra	High	Low
i7-4960X 6C/12T @ 4.2GHz	7%	8%	7%
i7-4960X 4C/4T @ 2GHz	10%	26%	17%
i7-4960X 2C/4T @ 3GHz	10%	30%	28%

Starting once again at 1080p Ultra, even with the greater CPU workload presented by this test, we are unsurprisingly still GPU-bound on Ultra settings. The benefits aren’t as uniform as last time – they now range from 7% to 10% – but it’s safe to say that we’re once again seeing what are mostly the GPU performance benefits of Mantle.
However shifting to High quality shows much greater performance gains, indicating that we’re at least partially (if not fully) CPU-bound here. Once we reduce our CPU performance from 6C/12T to 4C/4T, the performance gains from using Mantle jump from 8% to 26%, and then to 30% when using our 2C/4T configuration. For a game that’s not immensely CPU bound in the first place and has been retrofitted for Mantle, this is towards the upper bound of what we would expect.
Finally switching over to our Low quality settings causes our performance gains to actually taper off some. We’re still CPU-bound on our 4C/4T setup leading to a 17% performance gain, but we’re not as CPU-bound as we were at High quality settings, apparently. Meanwhile the performance gains for 2C/4T remain similar to last time, at 28%. Battlefield 4 has multiple CPU tasks going on here, not the least of which is the simulation itself, so in the case of our 4C/4T setups it’s likely we’ve stumbled onto a situation where the game is more strongly CPU-bound by the simulation and other aspects of the game than it is the submission of draw calls.
First Thoughts

As this is only a brief preview of our results we don’t intend to read too much into this limited data set, but even just looking at the 290X does provide us with some interesting data. For the pure high-end scenario – a 290X or similar GPU with a high-end CPU – Mantle can still offer performance benefits from the GPU workflow optimizations it provides. A 7-10% performance increase is not a dramatic difference, but it is 7-10% better performance than AMD had yesterday.
Meanwhile it comes as little surprise that the greatest performance benefits in our limited BF4 testing come in the mixed performance scenarios, pairing up a high-end GPU with slower CPUs. Since the lowest hanging fruit for Mantle optimizations is going to be CPU draw call bottlenecks, it’s going to be the weaker CPUs that have the most to gain here. In this case we still need to go out of our way to create CPU-bound scenarios – the 290X is rarely held back by the CPU on Ultra quality settings – but when we do create them we can see some of potential that Mantle can offer. At High and Low quality settings, and excluding our one Mantle performance regression, we see performance gains anywhere between 7% and 30%. This shows (if nothing else) that even a retrofit game with a highly optimized Direct3D rendering path, like Battlefield, can still be bottlenecked by draw call performance. And that consequently some of Mantle’s CPU overhead reduction capabilities do in fact pan out.
As for whether all of this is worth the costs and tradeoffs of Mantle from both a consumer perspective and a developer perspective is a longer discussion that we’ll be having next week, alongside our expanded benchmark results. But at first glance it looks like AMD has cleared the first hurdle, which is showcasing that there are tangible benefits to having a low-level graphics API. Now AMD just needs to further hammer out their Mantle drivers and get them into a public-consumable state, so that the wider community of end-users can test and evaluate AMD’s Mantle offering. Outside of the known installation issue we have not encountered any issues with Mantle thus far – this being despite the fact that AMD is being very explicit about the beta nature of the Mantle stack – so hopefully this is a good omen for the company after the delays leading up to this point.

AMD's Official Performance Data

Finally, we’ll quickly close with some of AMD’s performance numbers, which they’ve published in their reviewer’s guide. We feel that vendor-provided should always be taken with a grain of salt, but they do serve their purpose, especially for getting an idea of what performance is like under a best case scenario. To that end we can quickly see that AMD was able to top out at a 41% performance improvement on a 290X paired with an A10-7700K. This is a greater performance gain than the peak gain of 30% we’ve seen in our own results, but not immensely so. More importantly it can give us a good idea of what to reasonably expect for performance under Battlefield 4. If AMD’s results are accurate, then a 40% performance improvement is the most we should be expecting out of Battlefield 4’s Mantle renderer.

More...

Picking up from where we left off yesterday afternoon, word comes from AMD that they have finally squashed the installation bug on their Catalyst 14.1 beta drivers, resolving the last show stopper bug preventing the release of these drivers. As such, albeit a day behind schedule, AMD has finally publically posted the 14.1 beta drivers on their website for public use.
Under most circumstances we don’t place a great deal of importance on any given driver release. Both AMD and NVIDIA have 3-4 “major” driver releases each year, with a major driver release typically being a driver from a new branch that incorporates a mix of new features and low-level performance optimizations.  Consequently it’s the major driver releases that are the most notable releases for each GPU vendor, and even then those are generally regular releases. But even by those standards Catalyst 14.1 is going to me a more significant driver than virtually any other, due to the unprecedented number of features being rolled out all at once.
Altogether AMD is rolling out 3 major new features and a heap-ton of bug fixes with Catalyst 14.1, the first release of the 13.35 driver branch. The marquee feature is of course Mantle, with 14.1 being the first public release with Mantle API support. But 14.1 also includes HSA support for AMD’s recently launched Kaveri (A-7000 series) APUs, and at long last AMD’s suite of “phase 2” frame pacing fixes for all pre-GCN 1.1 (pre-XDMA) hardware. So this is a release that should have something for everyone, and further cuts down on AMD’s feature debt by implementing some long-awaited improvements.
Mantle

The marquee feature for Catalyst 14.1 is of course Mantle, AMD’s new low-level graphics API. Designed specifically around the shared GCN architecture in all of AMD’s current-generation graphics products, Mantle is intended to improve GPU efficiency and overall graphics performance by offering a lower level of hardware access than APIs like Direct3D offer, and in the process bypassing the overhead Direct3D can impose.
Since we have already written a small tome on Mantle from shortly after its announcement back in September, we won’t go into too much depth on Mantle for today’s driver release, but please see our first Mantle article for further details on how Mantle works and what AMD’s goals for the API are. Meanwhile we’re hard at work on a full write-up on Mantle’s performance with the new Catalyst 14.1 drivers, but in the meantime you can also see our Mantle performance preview for a quick glimpse of Mantle’s performance under Battlefield 4 on a Radeon R9 290X.

For this driver release Mantle is supported for all GCN discrete video cards and high performance APUs – Radeon 7000, 8000, and 200 series, and A-7000 series APUs (Kaveri). However at the moment the largest gains are to be found on AMD’s GCN 1.1 parts, the Radeon 290 series, Radeon 260 series (and 7790), and the A-7000 series APUs. For older GCN 1.0 hardware Mantle does work fine, as evidenced by the Star Swarm technical demo in particular, but Battlefield 4 performance isn’t showing the same gains on those parts as it is GCN 1.1 parts. Which indicates that AMD’s Mantle drivers and/or Battlefield 4 are in need of further optimizations, which is something AMD is already committing to follow through on.
On the software side of matters, Battlefield 4 and Star Swarm will be the launch titles for Mantle. AMD is ultimately shooting for much broader support – Thief is due with Mantle support this month, for example – but they will be starting small with just these two titles. Star Swarm itself is a technical demo of an engine that will be used in future games, rather than being a game or game demo itself, so of those two titles Battlefield 4 will carry the banner as the launch title for Mantle.
Finally, it’s important to note that AMD is being especially emphatic in pointing out that the Mantle component of the Catalyst 14.1 driver set is in a beta state. The SDK and the drivers are still a work in progress, hence the lack of GCN 1.0 optimizations in Battlefield 4 for example, so while AMD’s beta drivers are typically of reasonable quality, AMD is making sure everyone is aware that the Mantle component has further limitations and known issues than is in a typical beta release. AMD’s list of Mantle known issues is posted as below, with the most notable being that the state of Crossfire support is especially raw. The low level nature of Mantle means that driver-enforced AFR for multi-GPU setups is absent under Mantle, so proper multi-GPU scaling is largely in the hands of game developers, a significant change from how things work under Direct3D.

• Intermittent stuttering or stability issues may occur when utilizing Mantle with AMD CrossFire™ technology in BattleField 4™
• Mantle performance for the AMD Radeon™ HD 7000/HD 8000 Series GPUs and AMD Radeon™ R9 280X and R9 270X GPUs will be optimized for BattleField 4™ in future AMD Catalyst™ releases. These products will see limited gains in BattleField 4™ and AMD is currently investigating optimizations for them.
• Multi-GPU support under DirectX® and Mantle will be added to StarSwarm in a future application patch
• Notebooks based on AMD Enduro or PowerXpress™ technologies are currently not supported by the Mantle codepath in Battlefield 4™
• AMD Eyefinity configurations utilizing portrait display orientations are currently not supported by the Mantle codepath in Battlefield 4™
• Graphics hardware in the AMD A10-7850K and A10-7700K may override the presence of a discrete GPU under the Mantle codepath in Battlefield 4™

While we have yet to test Crossfire performance, for all other testing we’ve done we have not run into any issues with Mantle. Battlefield 4 for its part has a reputation for bugs – one that’s not unearned – and we’ve still run into the occasional Battlefield 4 bug. But Mantle itself has proven stable in our testing thus far.
Phase 2 Frame Pacing & Dual Graphics

AMD’s second major feature release with Catalyst 14.1 is the long-awaited set of “phase 2” frame pacing improvements for pre-GCN 1.1 hardware. Since March of 2013 AMD has been working on resolving some systematic issues in their multi-GPU frame pacing mechanisms, which under closer scrutiny had proven to be inferior to NVIDIA’s frame pacing mechanisms. In the interim period AMD has released their GCN 1.1 hardware, whose XDMA engine has essentially solved the problem going forward for new hardware, but there is still the matter of existing pre-GCN 1.1 hardware that AMD has been contending with.
For these pre-GCN 1.1 cards, AMD’s frame pacing fixes have been released in multiple phases. Phase 1 was released back in August of 2013 with Catalyst 13.8, and implemented AMD’s vastly improved frame pacing algorithms for D3D10+ on single display configurations. Phase 2 was to follow, and after having been delayed multiple times has finally been released as part of Catalyst 14.1.
Whereas phase 1 focused on single-display issues, phase 2 contains AMD’s multi-display frame pacing fixes. This includes both pure Eyefinity multi-monitor setups, and also fixes for tiled 4K displays, which behave as multiple monitors from the point of view of the video card. With their phase 2 fixes now in place, AMD has an improved frame pacing mechanism for these very high resolution configurations, which is especially important for cards such as the Radeon 7990, which was advertised in part on its suitability for these configurations.

Catalyst 14.1 Frame Pacing
 	Single Display	Eyefinity
D3D11	Y	Y
D3D10	Y	Y
D3D9	N	N
OpenGL	N	N
Mantle	Dev Implemented	Dev Implemented

One thing to note with phase 2 is that like phase 1, these frame pacing improvements are solely for Direct3D 10+. Direct3D 9 and OpenGL are not covered by phase 2 under single-monitor or multi-monitor configurations, and as such still use AMD’s old frame pacing algorithms. AMD will ultimately be releasing a phase 3 driver to handle these APIs, though AMD isn’t providing a schedule for phase 3 at this time.

Besides the immediate frame pacing benefits from the phase 2 fixes, phase 2 is also extremely interesting from a technical perspective, as the high resolutions this covers are so high that they overwhelm the limited bandwidth available via AMD’s Crossfire Bridge Interconnect. As a result AMD is having to ship a significant amount of frame traffic over the PCIe bus, which is notable since AMD doesn’t have the XDMA engine to lean on in these older parts. We’ll be digging into these frame pacing improvements a bit later this month once we’re done with Mantle.
Finally, alongside the phase 2 dGPU fixes, AMD is also including their frame pacing fixes for their Dual Graphics technology, which leverages their multi-GPU capabilities to pair up an iGPU with a dGPU for similar performance improvements. Similar to AMD’s Crossfire technology, Dual Graphics has suffered from frame pacing issues for many of the same reasons, and with this release AMD is finally applying their new frame pacing algorithms to Dual Graphics. Though we haven’t had a chance to test this yet, AMD tells us that Catalyst 14.1 should significantly improve frame pacing for a subset of existing Dual Graphics setups, and meanwhile is also the first driver to properly support Dual Graphics with the recently released Kaveri APUs. Dual Graphics has been nearly an afterthought for most buyers due to outstanding issues such as frame pacing, so hopefully AMD is better able to deliver on its potential with these fixes.
HSA

Last but not least, Catalyst 14.1 also includes the first runtime drivers for AMD’s Heterogeneous System Architecture (HAS). In the works for years and finally delivered with AMD’s recently launched Kaveri APU, HSA is AMD’s end game for integrating their CPUs and GPUs into a single product, coupling the two tightly enough to allow for the GPU component to be an efficient processor for various compute tasks. HSA requires a runtime to compile the pseudo-ISA to the architecture’s native ISA, hence the need for a driver component, which is finally being delivered via Catalyst 14.1.

More so than even Mantle, HSA is a work in progress. It'll still be a matter of years before we see widespread adoption of heterogeneous programming and software, but the release of HSA capable hardware and its associated runtime lays the groundwork for the development of the first HSA applications.
Closing Thoughts

As always, you can grab the driver from AMD’s driver download page. The Windows desktop driver weighs in at 286MB, while the mobility driver weighs in at 270MB.
AMD’s driver download page has extensive release notes on this driver release, including specific supported (and unsupported) products, and lists of known issues and notable bug fixes. Meanwhile AMD’s gaming sub-site has a blog post up on these drivers, reiterating the expected benefits and offering AMD’s own performance numbers.
Finally, as these are beta drivers AMD has been asking for bug reports for any and all issues encountered with 14.1. Bug reports may be submitted via AMD’s issue reporting form.
Gallery: AMD Catalyst 14.1 Beta Drivers Now Available: Mantle, Frame Pacing, & More

More...

The TUF range from ASUS is a different sort of blip on the motherboard radar – they come with a five year warranty.  ASUS will mention that the hardware is built around the idea of stability, using upgraded components in order to do so.  I have rarely had the chance to look at the TUF range, but today we look at ASUS’ first micro-ATX TUF motherboard, the Z87 Gryphon.

More...

With hopes of chipping away at the low end Windows PC market, Google enlisted ASUS' help in putting together a small form factor desktop machine running Chrome OS. The result is the ASUS Chromebox, a NUC-like machine running Google's browser based OS. The specs of the ASUS Chromebox are respectable compared to Intel's line of Haswell NUCs.
You get your choice of one of three CPUs, all based on Intel's Haswell architecture. There's the Celeron 2955U, Core i3-4010U or the Core i7-4600U. All three options carry the same 15W TDP rating, and the system is apparently fanless (at least the Celeron and Core i3 versions are, waiting for confirmation on the i7). ASUS only plans to offer the Celeron and Core i3 versions in North America. 4K video out is supported on the Core models. Given how well Chrome OS can run on a pair of ARM Cortex A15 cores, I fully expect a 15W Haswell based system to be a great performer.

ASUS Chromebox
 	ASUS Chromebox	Intel Haswell NUC
OS Preloaded	Google Chrome OS	None
CPU	Intel Celeron 2955U (2C/2T 1.4GHz 2MB L3) Intel Core i3-4010U (2C/4T 1.7GHz 3MB L3) Intel Core i7-4600U (2C/4T 2.1/3.3GHz 4MB L3)	Intel Core i3-4010U (2C/4T 1.7GHz 3MB L3) Intel Core i5-4250U (2C/4T 1.3/2.6GHz 3MB L3)
GPU	Celeron: Intel HD (200/1000MHz) Core i3: Intel HD 4400 (200/1000MHz) Core i7: Intel HD 4400 (200/1100MHz)	Core i3: Intel HD 4400 (200/1000MHz) Core i5: Intel HD 5000 (200/1000MHz)
Memory	2GB/4GB configs, 2 x DDR3 SO-DIMM Slots	2 x DDR3 SO-DIMM Slots
Storage	16GB M.2 SSD + 100GB Google Drive for 2 years	1 x mini PCIe (full length)
LAN	10/100/1000 Ethernet	10/100/1000 Ethernet
Wireless	dual-band 802.11 a/b/g/n, BT 4.0	1 x mini PCIe (half length)
External I/O	SD card reader 4 x USB 3.0 1 x HDMI 1 x DisplayPort 1 x Audio Jack (mic-in/speaker out)	4 x USB 3.0 1 x mini HDMI 1 x mini DisplayPort 1 x Audio Jack (mic-in/speaker out)
Power Supply	65W	65W
Dimensions	4.88" x 4.88" x 1.65"	4.59" x 4.41" x 1.36"
Starting Price	$179	$285

ASUS' Chromebox comes with a 16GB M.2 SSD, and dual-band 802.11n wireless all for a price starting at $179. Google will throw in 100GB of space on Google Drive for 2 years to make up for the limited internal storage.
The box itself is a little bigger than Intel's Haswell NUC, but we're still talking about an extremely small form factor computer. ASUS will ship all units with a VESA mount as well. You can expect availability sometime in March.
Gallery: ASUS Chromebox: Fanless Haswell in a NUC-like Form Factor, Starting at $179

More...

News on the grapevine is filtering down for Bay Trail-D.  We have had the 20W Avoton server equivalent processor in our offices for a little while now, but alongside this Intel have 10W consumer based Celerons to market.  With the chips being a ball-grid-array arrangement it is up to the motherboard manufacturers to provide the base on which these processors sit.  Alongside some display from MSI at CES, GIGABYTE and Biostar are coming to market with their versions.
From GIGABYTE, this is the J1800N-D2H, using the 10W Intel Celeron J1800 Bay Trail-D SoC, a dual core Silvermont CPU starting at 2.41 GHz with turbo up to 2.58 GHz.  N in the name indicates mini-ITX, and D2H positions the motherboard at the lower end in terms of specifications.  The board itself uses a passive heatsink to cool the CPU (more than understandable for 10W), two DDR3L SO-DIMM 1333 MHz slots (1.35V memory only), a D-sub and HDMI audio output, two PS/2 ports, USB 3.0, a USB 2.0 hub, two SATA 3 Gbps ports, a PCIe 2.0 x1 slot, a mini-PCIe slot, Realtek ALC887 audio and Realtek NIC, all in a 17cm square form factor.

The Biostar J1800NH is a similar product with the Celeron J1800 SoC, using instead a single DDR3L SO-DIMM slot, fewer USB 2.0 ports and a Realtek ALC662 audio codec instead.

What is perhaps more surprising is the pricing.  The Biostar motherboard is currently available for $56 with a $60 MSRP – the GIGABYTE motherboard, and the MSI one at CES, should be around $60 as well.  However this SoC, sold by Intel, is listed as $72 tray price (i.e. in batches of 1000).  This means either that these manufacturers are getting them at a discount, or selling them at a loss.

The purpose for Bay Trail-D is tablet like performance in a desktop form factor, with perhaps the added advantage of expandability and connectors.  Users wanting quad core solutions will have to keep eyes peeled for J1850/J1900 versions, or jump to Pentium J2850/J2900.  We saw that ECS was going to release a line of these motherboards last year.  As mentioned, we have Avoton in to test, specifically Intel’s 8-core Silvermont solution for IPC/servers.  Keep your eyes peeled for that review.
Sources: Fanless Tech via Liliputing via Tech Report.
Gallery: 10W Bay Trail-D Coming To Market from GIGABYTE and Biostar

More...

The last few years have seen a rapid rise in popularity of network attached storage (NAS) systems. Coupled with the increased interest in IP cameras for surveillance, this has led to video management / surveillance solutions becoming an important product line for NAS as well as networking equipment vendors. Companies such as QNAP have dedicated surveillance NAS units (VioStor lineup). Other companies provide surveillance solutions as apps for their NAS platform (Synology's Surveillance Station, for example). At CES, we saw Buffalo working together with AXIS to create a networked video recorder (NVR) using a standard 2-bay Marvell-based NAS.
Linksys is no stranger to the NAS market, though they might not be as popular as more established vendors in the space such as Netgear, Synology and QNAP. They are making a concerted effort to re-enter the small and medium business (SMB) market with recent product introductions in the networking space. Towards this, they recently announced some SMB solutions in the surveillance market. A number of 1080p-capable IP cameras were introduced, but our focus here is on the NVR model, the LNR0208C.
The LNR0208C is a standalone NVR system running an embedded Linux OS. Based on a Marvell 2.0 GHz SoC (likely to be one of the higher clocked Kirkwood variants), it supports up to eight simultaneous video feeds in eight separate channels. There is support for all Linksys IP cameras out of the box, but other vendors' cameras which are ONVIF profile S compliant can also be used with the NVR. There is no license requirement to add cameras, unlike the surveillance offerings from other vendors. With two bays, the end user can have up to 8 TB of hot-swappable storage. The NVR-specific features include remote live view and playback and support for linking with other NVRs on the network (multiple NVR monitoring). The hardware itself is a standard 2-bay NAS with a GbE port, two eSATA ports and three USB 2.0 ports. The differentiating aspect is the presence of four digital in / two digital out (DI/DO) ports for sensors and alarms (This application note [PDF] provides an overview of how DI/DO ports can be used in conjunction with an IP camera / NVR system).
The Linksys LNR0208C diskless version has a MSRP of $799.99 MSRP and will become available for purchase later this month.

More...