AMD Radeon R9 290X 4GB Review

[SKYMTL]

After nearly two years, AMD is finally launching a new assault on the ultra high end graphics card market with their R9 290X and R9 290. Both of these cards are based on a revised GCN architecture and incorporate enough performance to go toe to toe against the best NVIDIA has to offer. For the time being, only the R9 290X is being launched with the R9 290 getting its unveiling sometime soon. After the rebranded R9 280X, R9 270X and R7 260X made some waves a few weeks ago, the R9 290X is the one everyone was waiting for.

The R9 290X is the fastest graphics card AMD has ever produced and it should be able to compete against NVIDIA’s TITAN in vast majority of games. It also incorporates a number a feature set enhancements like TrueAudio, Mantle support, DX11.2 compatibility and an updated PowerTune engine. However, what really allows the 290X to stretch its legs is the massive amount of raw rendering capabilities AMD built into its core.

In creating the R9 290X, AMD basically maxed out their capabilities in an effort to wring the most out of their GCN architecture as possible. This wasn’t an easy task since it meant increasing the Stream Processor, ROP and TMU counts while still operating within the thermal and power consumption constraints of a less efficient 28nm manufacturing process.

Even though AMD had to constrain their design to fit within relatively stringent limitations, they’ve still equipped the R9 290X with some impressive specifications. It has 2816 Stream Processors and 176 texture units which represents a nearly 40 percent increase in theoretical throughput over Tahiti. While the HD 7970 and by extension the R9 280X was ROP bottlenecked in some rare scenarios, the R9 290X doubles up on Tahiti XT’s ROP layout with 64 units. With these changes, pixel fillrate has essentially doubled from 32GP/s to 64GP/s. Likewise, the texture fillrate and compute performance have seen a 38 percent boost but, like the GTX 780, the R9 290X runs Double Precision at 1/8th the rate of single precision.

With the games industry moving towards larger texture maps and monitors starting to push up against the 4K barrier, AMD has decided to move towards 4GB, 512-bit GDDR5 interface which provides 320 GB/s of memory bandwidth. That should be more than enough for the foreseeable future.

<iframe width="640" height="360" src="//www.youtube.com/embed/7W8T8t1A6q0" frameborder="0" allowfullscreen></iframe>​

AMD has stated power consumption for the R9 290X is about 250W. That’s unusual to say the least since the HD 7970 GHz Edition uses a substantially smaller die package, is significantly less pwoerful and houses less memory than the 290X…yet also consumes about 250W. As you’ll see in our tests, AMD’s latest flagship gulps down a huge amount of power and, according to several board partners we’ve talked to; their board designs easily hit the 300W mark in lab tests. Hence, we've given some approximate numbers for the 290X above.

Another mysterious omission is actual clock speeds. While NVIDIA’s latest cards and even some of AMD’s R-series products list a Boost and Base clock which gives buyers a relatively accurate depiction of the card’s behavior, the 290X features an oddball “up to” frequency which tells us precisely nothing. This is partially due to AMD’s revised PowerTune routine but as we discuss later in this article, there’s no need to be so nebulous about the R9 290X’s operating speeds. For the record, in our testing, the Base frequency seems to be around 850MHz which is a far cry away from 1GHz.

One thing many gamers will be wondering about is price and that’s one area where the R9 290X truly shines. At just $549, it is $100 less than the GTX 780 and a whopping $450 less than NVIDIA’s comparable TITAN. This will be a truly pleasant surprise for anyone who thought it was going to be more than $700 and it also gives a clear indication that the upcoming R9 290 will be even more competitively priced. Oh, you'll need to add a few bucks more if you want the Battlefield 4 Edition.

In AMD’s own lineup the R9 290X will sit in a preeminent position, well above the R9 280X and the HD 7970 GHz Edition. That gap will be closed at some point by the R9 290 which will likely fall into a performance bracket somewhere between the GTX 780 and GTX 770.

With specifications, price and positioning taken into account, it’s obvious that AMD is going for NVIDIA’s jugular within the enthusiast market. TITAN has been sitting in its previously unassailable position for a long time now and with the R9 290X, AMD is conceivably launching a card that will outperform it while costing hundreds less. That’s quite an achievement which may cause NVIDIA to rethink their current pricing structure even with their Holiday Game Bundle.

Real question in this whole equation is availability. While TSMC’s 28nm manufacturing process is mature, yields of these high end cores have never been up to the levels of other SKUs so don’t expect the R9 290X availability to be as widespread as lower-end cards. For the record, according to our retailer contacts, this will be a hard launch with product on the shelves tomorrow.

 

[SKYMTL]

A Closer Look at the R9 290X 4GB

A Closer Look at the Radeon R9 290X

​

With the R9 290X being the flagship of AMD’s 2014 GPU lineup, it takes the styling changes incorporated into the R9 270X and simply upsizes them. This leads to a great looking graphics card which uses a predominantly black fan shroud with some slight Radeon Red highlights. For those wondering, it is about 11.5” long so there shouldn’t be any problems getting it into a typical ATX-sized case.

​

Much like the R9 270X, AMD’s reference heatsink incorporates secondary intakes around the heatsink shroud’s rearmost portion. This should help the fan’s airflow potential, particularly when it’s partially blocked by another R9 290X in a close Crossfire configuration.

​

On the R9 290X’s side, there is a noticeable omission: no Crossfire connectors. Instead of the physical interface, AMD will be streaming multi-card signals over their new “XDMA” interface. This means AMD is using a hardware DMA engine to stream dual and triple card interactions over the PCI-E bus rather than an external connector. Not only does the new approach provide a bandwidth uplift over the previous solution but it also has the potential to improve latency. We’ll be looking into XDMA’s performance in depth at a later date.

Next to the Crossfire connector’s usual position is a dual-toggle BIOS switch that enables one of two modes: Silent of Uber. Silent, which is the position closest to the I/O plate is the default setting and features a fan speed of 40%. Uber on the other hand ups the fan speed to 55% without changing any other setting and, as we will see later, provides higher performance through AMD’s new PowerTune algorithms. Supposedly all cards from AMD and their board partners will feature these two presets.

​

While the R9 290X may consume more power than the outgoing HD 7970 GHz Edition, it still retains the 8+6 pin power connector layout.

Moving around to the card’s I/O connectors, there is a pair of DVI outputs (note that neither is compatible with a VGA adaptor) along with a DisplayPort with daisy chaining capabilities and an HDMI output. This meshes perfectly with AMD’s new Eyefinity groupings which allow a single card to natively support up to six displays.

​

While the R9 290X may use 4GB of memory, none of the modules are installed on the PCB’s rear quarters. This means the area is free of anything particularly interesting.

​

Removing the shroud reveals a rudimentary dual slot heatsink design which is designed to funnel the air produced by the intake fan through a chamber housing aluminum fins. This sits atop a copper vapor chamber. In our experience, this layout quickly gets overwhelmed by the core’s heat so hopefully board partners will come up with their own advanced designs before long.

​

Other than the copper vapor chamber which covers the core and GDDR5 memory modules, AMD has also installed a full-length secondary heatsink which covers and distributes heat from the PWM. This is a design which has carried forward from previous AMD cards and tends to be the best layout for dissipation for a blower-style cooler.

 

[SKYMTL]

The R9 290X’s Hawaii Architecture in Detail

The R9 290X’s Hawaii Architecture in Detail

AMD’s R9 290X uses a slightly revised and updated version of the GCN architecture which incorporates many of the changes built into the Bonaire XT core but there have been some additional changes built into this highly expanded version. Code named Hawaii, this core is still built using TSMC’s 28nm manufacturing process but its die is massive at 438mm², encompassing some 6.2 billion transistors or about 24% larger than the Tahiti XT found on the R9 280X / HD 7970. As a comparison, NVIDIA’s GK110 weighs in at an epic 7.1 billion transistors packed into a die that’s about 551mm² so substantially larger than AMD’s solution.

The relatively small increase in die area is quite impressive considering Hawaii offers much better performance (particularly when it comes to geometry processing and pixel fillrates) over the previous generation flagship architecture. How was this possible? Let’s take a deep dive into the core to see where the changes are housed.

From a high-level standpoint there have been some significant changes necessitated by the raw number of Stream Processors, cache and other internal components. There has also been the addition of a TrueAudio module, a dedicated partition for AMD’s new Crossfire XDMA interface and six Eyefinity controllers for native 3x2 Eyefinity support. With that being said, this architecture is a simple evolution of GCN rather than a ground-up new design, so don’t expect a huge number of updates here.

One of the primary space savers implemented in this move from Tahiti to Hawaii is a new type of memory controller design. Even though Hawaii uses eight 64-bit controllers for a 512-bit interface in lieu of the 6x64-bit layout found on Tahiti, it actually uses 20% less space without sacrificing one iota of performance. This allowed AMD to cram more primary processing horsepower onto the die without having to worry about insufficient memory bandwidth.

GCN’s primary building block, the Compute Unit has gone largely unchanged in this iteration. It is still a compact, self contained building block of sorts that was initially designed to increase on-die content flow efficiency by keeping much of the data local rather than handing it off to a global shared stream. As with Tahiti, each Compute Unit is treated independently and allows for the SIMD communications, sequencing and scheduling to be run in a single cohesive structure before handing it off.

From a thread processing perspective a single Compute Unit has 4 sub Vector Units (or SIMDs) made of up 16 Stream Processors each for a total of 64 cores per CU. This layout is backstopped by a quartet of Texture Units and 16KB of dedicated read / write L1 cache.

With the Vector Units producing their own independent streams, AMD included a high bandwidth scheduler. The Scheduler works alongside the unified cache and the 64KB of local data share to facilitate the information flow between data lanes. In the Queen’s English, it acts like a traffic light to direct data towards a set location.

Another important part of the Compute Unit’s hierarchy is the inclusion of a dedicated Scalar Unit with its own registers. This unit acts like a general purpose programmable core that can issue its own instructions and can take part of the workload off of the other areas of the Compute Units or can work independently if need be. Think of it as a central processing unit within each cu.

None of this has necessarily changed from Tahiti’s version of GCN but several efficiency optimizations have been built into these units. While Hawaii carries forward MQSAD support and 2816 IEEE 2008-compliant shaders, there has been a precision improvement for native LOG/EXP ops to 1ULP. This won’t necessarily help with game performance but there may be a slight boost in some outlier compute-centric applications.

The vast majority of improvements have been rolled into Hawaii’s geometry processing stages which points towards AMD gearing up for the enhancements being rolled out within DX11.2 and Direct3D 11.2. Gone are the two Geometry Engines and in their place is a quartet of engines which allows this architecture to process four concurrent primitives per clock. These new abilities have been backed up by enhanced caching capabilities, particularly on the L2 read / write side which has been increased to 1MB and provides a staggering 1TB/s of internal bandwidth between the L1 and L2 sidebars.

Additional processing is also being done on-die with an enhanced Load / Store front end which is primarily being used to facilitate internal communications. Finally, AMD has improved off-chip buffering which leads to higher tessellation throughput than the previous generation.

The individual Compute Units, Geometry Processor and Rasterizer alongside four individual Render Back-Ends and other secondary elements are combined into a single high level organizational unit called the Shader Engine. Each Shader Engine houses 704 cores (broken into eleven Compute Units of 64 cores each), 44 Texture Units and 16 ROPs. This Shader Engine concept can be likened to NVIDIA’s Graphics Compute Unit since it groups high level functionality but in this case, AMD has added individual back-ends which can scale separately from the memory hierarchy.

AMD has pooled the primary core resources into this engine to facilitate communications. For example, all of the engine’s four individual cache sets can be shared by up to 4 Compute Engines each while the Render Back-Ends with their ROPs and depth cache are completely scalable based on the needs of a given operation.

Compute throughput has also been addressed with eight individual Asynchronous Compute Engines taking the place of Tahiti’s two engines. Not only do they have direct access to the read / write L2 cache and the global data share pathways but they can work in parallel and each can manage up to eight data queues.

The ACEs workflow goes through the core’s memory controllers before it hits one of two DMA engines. These DMA engines can actually saturate the bi-directional 16GB/s bandwidth of a PCI-E 3.0 slot. However, the compute performance of this particular architecture will never come close to needing that much bandwidth anyways since most of its processing is done on-die.

 

[SKYMTL]

AMD's Clock Gating Goes Dynamic

AMD's Clock Gating Goes Dynamic

As AMD and NVIDIA have begun pushing the limits of the 28nm manufacturing process, both have struggled to optimized performance, power consumption and heat output. PowerTune was launched by AMD in an effort to address these three factors by constraining clocks at predetermined maximum limits which could only be modified via overclocking. This capped both power consumption and performance but unlike NVIDIA’s innovative GeForce Boost, it didn’t take into account the myriad of other factors like temperatures (a major contributing factor to efficiency) and available power overhead.

One good example of this metric is the HD 7970 GHz Edition’s approach to clock speeds in comparison to a GTX 780. The AMD card had a hard cap of 1050MHz regardless of how low the ASIC’s temperatures were. The GTX 780 on the other hand had the capability to take advantage (within reason of course) of cooler conditions by boosting up to higher clock speeds which is something AMD lacked. With the R9 290 cards, AMD is pushing aside their old, relatively archaic approach to on-die performance optimizations and implementing a whole new plan for balancing performance and efficiency.

While the baseline PowerTune equation has remained largely the same (ie: performance being tied closely to power consumption), AMD has added a number of features into their refreshed architecture which allows for closer control over the ASIC’s power management and how it determines optimal frequencies. Many of these have been carried over from lessons learned within the APU segment.

As with PowerTune’s previous iteration, temperature and activity sensors are interspersed throughout the GPU core to determine how much power the GPU should be actively using. Much of this data was estimated rather than calculated at the source. However, AMD has now added a secondary group of sensors which actively monitor the actual amount of current being drawn from the board’s regulators. This data is then combined with the information accrued through the architecture’s power estimation engine to paint a much more accurate picture of the board’s power needs.

With the thermal sensors and power telemetry feeding into a common DPM arbitrator, the new PowerTune hardware control mechanism can begin making choices based real time information rather than assumptions. This should allow AMD to wring the best possible frequencies out of their architecture without worrying about smashing face first into a TDP wall. This means there is no single clock for these new products since the functional relationship between power and clocks has to be maintained (ie: constantly moving power metrics and temperatures determine frequencies).

One of the most important factors of the new PowerTune equation is AMD’s commitment to totally user-customizability. If someone wants a cool running card that operates at higher frequencies by way of an increased thermal overhead, they can achieve just that through the Catalyst Control Center. The same thing goes for slightly lower clock speeds and absolute silence or any point in-between. In short, a gamer can now how the card they want regardless of their needs.

The second generation serial VID interface boasts an all-new voltage regularity controller which has the capability to balance all aspects of the core’s power spectrum. The controller can ensure the core remains within .5% of a given power target by switching clock and voltage inputs at a rate of up to 500 transitions per second. This allows for additional frequency granularity without the large peaks and valleys sometimes experienced in competing solutions. Best of all, much of this will be transparent to end users but it can still be controlled via different modifiers within AMD’s software stack.

Fan control also plays a large part in the new PowerTune equation. While previous solutions used standard fan speed tables the integrated controllers within the GPU can now target an optimal operating temperature (which is 95°C on the R9 290X) via more precise methods. For example, the fan controller is now completely variable in nature and reacts in real time to changing conditions while also boasting a predictive element so it can determine needs down the road.

This new fan controller and its relationship to the SVID interface means the fan speed fluctuate in a strictly controlled manner rather than drastic, noticeable upwards and downwards changes.

 

[SKYMTL]

Clock Speeds vs. Temperatures; PowerTune Does The Tango

Clock Speeds vs. Temperatures; PowerTune Does The Tango

While benchmarking our R9 290X sample, we came across an interesting occurrence: our second and third in-game runs always came up with demonstrably lower performance than the first run-through. Typically, that kind of instance will happen once in a while but not with such regular consistency. After hours of testing we came to the realization that as the card stabilized at its thermal limit of 94°C, PowerTune began dynamically reducing clock speeds in an effort to balance temperatures and power consumption.

In order to understand what’s happening here, we’ll have to refer back to AMD’s PowerTune equation which governs clock speeds on the R9 290X. It will allow the core temperature to reach a maximum level, after which frequencies tend to fluctuate according to how close PowerTune’s algorithms determine the core is to a give power limit. This happens frequently in Silent Mode which relies on lower fan speeds while Uber Mode’s profile allows for a bit more headroom despite hitting the same 94°C plateau.

Let’s take a look at some temperature results first. In all of these situations, the load upon the GPU was constant with the camera and onscreen character in a constant fixed position.

As you can see, both Silent and Uber Modes head north towards 94°C at roughly the same pace, though the faster fan speed in Uber means that it takes a bit longer to get there. That’s good since it means PowerTune is working its magic, balancing everything out and making sure the core is fully utilized if there’s any thermal or power overhead left. So what effect does this have upon clock seeds? This is where the interesting part starts.

In Silent Mode, clock speeds are obviously sacrificed so the fan doesn’t need to spin above 40%. This also points to why we were seeing lower performance after multiple runs: for two to three minutes, the core remains at 1GHz but thereafter clock speeds begin dropping as PowerTune begins its balancing act. In this situation, since the Power Limit and fan speed are both maxed out at their respective default settings, core clocks are on the chopping block.

In Uber Mode on the other hand, there are a few dips here and there but for the most part the higher fan speeds are able to compensate somewhat for the rising temperatures and their respective impact upon power consumption. This means frequencies remain relatively high with PowerTune avoiding the messy process of throttling through clock gating.

As you might expect, these two different scenarios lead to varying performance metrics with Uber Mode obviously taking a sometimes-sizable lead. This isn’t an outlier instance either since, as our performance tests will show, quite a few applications other than Hitman are power limited and switching to Uber Mode tends to make a significant difference.

These results also highlight a worrying trend for reviewers. Typically we boot up a game, load a save file and begin benchmarking over 1-2 minutes. As evidenced by the results above, that kind of approach won’t return real-world results since the R9 290X’s clock speeds take several minutes to level out, possibly skewing results.

Even though NVIDIA cards equipped with GeForce Boost don’t typically exhibit such behavior, with the numbers above in-hand, we’ve decided to change our benchmarking procedure. Now, before every run, cards are left to “heat up” for 10 minutes under in-game load which will ensure more realistic benchmark numbers.

 

[SKYMTL]

More Display Possibilities for Eyefinity

More Display Possibilities for Eyefinity

While Eyefinity may not be used by the majority of gamers, the few who use three or even six monitors compose a demanding group of enthusiasts. Unfortunately, in the past, using a single card for Eyefinity purposes either limited output options since the mini DisplayPort connector needed to be part of any monitor grouping. This meant either using a DisplayPort-equipped panel, buying a HDMI / DVI to DisplayPort adaptor or waiting for an Eyefinity version of the card to be released.

On all new R7 and R9 series cards, a user will be able to utilize any combination of display connectors when hooking their card up to an Eyefinity grouping. While most cards won’t have the horsepower necessary to power games across three 1080P screens (the beastly R9 290X and R9 290 will likely be the exceptions to this), the feature will surely come in handy for anyone who wants additional desktop real estate.

These possibilities have been applied to lower-end R7 series cards as well. This is particularly important for content creation purposes where 3D gaming may not be required but workspace efficiency can be greatly increased by using multiple monitors.

Most R-series cards will come equipped with two DVI connectors, a single HDMI 1.4 port and a DisplayPort 1.2 output. While there are a number of different display configurations available, most R9 280X cards will come with a slightly different layout: two DVIs, a single HDMI port and two mini DisplayPorts. In those cases, AMD’s newfound display flexibility will certainly come in handy.

While we’re on the subject of connectors, it should also be mentioned that the R9 290X and R9 290 lack the necessary pin-outs for VGA adaptors. It looks like the graphics market will finally see this legacy support slowly dwindle down with only lower-end cards featuring the necessary connections.

For six monitor Eyefinity, the newer cards’ DisplayPort 1.2 connector supports multi-stream transport which allows for multiple display streams to be carried across a single connector. This will allow daisy-chaining up to three monitors together with another three being supported by the card’s other connectors.

The DP 1.2 connector’s multi streaming ability also allows MST hubs to be used. These hubs essentially take the three streams and then break them up into individual outputs, facilitating connections on monitors that don’t support daisy-chaining. After years of talk, there’s finally one available from Club3D but its rollout in North America isn’t guaranteed.

 

[SKYMTL]

TrueAudio; A Revolution in Audio Technology?

TrueAudio; A Revolution in Audio Technology?

When we think of gaming in relation to graphics cards, the first thing that likely comes to mind will be in-game image fidelity and how quickly a given solution can process high graphical detail levels. Realism and player immersion is only partially determined by how “good” a game looks and there are many other factors that contribute to how engaged a player will be in a game. Unfortunately, in the grand scheme of game design and a push towards higher end graphics, the soundstage is often overlooked despite its ability to define an environment and truly draw a gamer in.

Multi channel positional audio goes a long way towards player immersion but the actual quality produced by current solutions isn’t usually up to the standards most expect. We’ve all heard it time and again: a multitude of sounds which get jumbled together or a simple lack of ambient sound with the sole focus being put on the player’s gunshots or footsteps. Basically, it’s almost impossible to find a game with the high definition, visceral audio tracks found in today’s Hollywood blockbusters despite the fact that developers sink hundreds of millions into their titles.

The lack of developer generated, high quality audio tracks isn’t absent for lack of trying. Indeed, the middleware software and facilitators are already present in the marketplace but developers have a finite amount of CPU resources to work with. Typically those CPU cycles have to be shared with primary tasks such as game world building, compute, A.I., physics and simply running the game’s main programming. As you might expect, audio processing is relatively low in the pecking order and rarely gets the reserved CPU bandwidth many think it deserves. This is where AMD’s TrueAudio gets factored into the equation.

While sound cards and other forms of external audio renderers can take some load off the processor’s shoulders, they don’t actually handle the lion’s share of actual processing and sound production. TrueAudio on the other hand remains in the background, acting as a facilitator for audio processing and sound creation and allows for ease-of-use from a development perspective, thus freeing up CPU resources for other tasks.

TrueAudio’s stack provides a highly programmable audio pipeline and allows for decoding, mixing and other features to be done within a versatile environment. This frees programmers from the constraints typically placed upon audio processing during the game creation process.

In order to give TrueAudio some context, let’s compare it to graphics engine development. Audio engineers and programmers usually record real-world sounds and then mix them down or modify layers to create a given effect. Does the player need to hear a gunshot at some point? Record a gunshot and mix accordingly. There is very little ground-up environmental modeling like game designers do with triangles and other graphics tools.

TrueAudio on the other hand allows audio teams to get a head start on the sound development process by creating custom algorithms without having to worry about CPU overhead. As a result, it could allow for more audio detailing without running headfirst into a limited allocation of processor cycles.

According to AMD, one of the best features of TrueAudio is its transparency to developers since it can be accessed through the exact same means as the current audio stack. There aren’t any new languages to learn since it can be utilized through current third party middleware programs, making life for audio programmers easier and allowing for enhanced artistic freedom.

TrueAudio’s position within the audio stack enhances its perception as a facilitator since it runs behind the scenes, rather than attempting to run the show. Supporting game audio tracks are passed to TrueAudio, processed and then sent back to the main Windows Audio stack so it can be output as normal towards the sound card, USB audio driver or via the graphics processor’s HDMI / DisplayPort. It doesn’t take the place of a sound card but rather expands the possibilities for developers and works alongside the standard pipeline to ensure audio fidelity remains high.

TrueAudio is implemented directly within supporting Radeon graphics cards (the R7 260X, R9 290 and R9 290X) via a set of dedicated Tensilica HiFi EP audio DSP cores housed within GPU die. These cores will be dedicated to in-game audio processing and feature floating point as well as fixed point sound processing which gives game studios significantly more freedom than they currently have. It also allows for offloading the processing part of audio rather than remaining tied at the hip to CPU cycles.

In order to ensure quick, seamless access to routing and bridging is possible, the DSPs have rapid access to local-level memory via onboard cache and RAM. There’s also shared instruction data for the streaming DMA engine and other secondary audio processing stages. More importantly, the main bus interface plugs directly into the high speed display pipeline with its frame buffer memory for guaranteed memory access. At all times

While TrueAudio ensures that processing can be done on dedicated DSP cores rather than on the main graphics cores, there can still be a CPU component here as well since TrueAudio is simply supplementing what the main processor is already tasked with doing. In some cases, these CPU algorithms can build upon TrueAudio platform, enhancing audio immersion even more.

One of the primary challenges for audio engineers has always be the creation of a three dimensional audio space through stereo headphones. In typical setup, the in-game engine does the preliminary processing and then mixes down the tracks to simple stereo sound. Additional secondary DSPs (typically located on a USB headphone amp) then render the track into virtual surround signal across a pair of channels, adding in the necessary reverberations, separation and other features to effectively “trick” a user into hearing a directionally-enhanced soundstage. The end result is typically less than stellar since the sounds tend to get jumbled up due to a lack definition.

TrueAudio helps virtual surround sound along by offering a quick pathway for its processing. It uses a high quality DSP which insures individual channels can be separated and addressed with their own dedicated, primary pipeline. AMD has teamed up with GenAudio to get this figured out and from presentations we’ve seen, it seems like they’ve made some incredible headway thus far.

While nothing has to be changed from a developer standpoint since all third party applications and runtimes can work with TrueAudio, this new addition can leveraged for more than just optimizing CPU utilization. Advanced effects, a richer soundstage, clearer voice tracks and more can all be enabled due to its lower overhead and broad-ranging application support. In addition, mastering limiters can allow for individual sounds to come through without distortion.

Unlike some applications, TrueAudio isn’t an end-all-be-all solution since it can be used to target select, high bandwidth streams so not all sounds have to be processed through it. AMD isn’t cutting the CPU out of this equation and that’s important as they move towards a heterogeneous computing environment.

As with all new initiatives, the failure or success of TrueAudio will largely depend on the willingness of developers to support it. While it feels like we've been down this road before with HD3D, Bullet Physics and other AMD marketing points from years past that never really got off the ground, we fell like TrueAudio can shine. Developers are already onboard and AMD has gone through great pains to make its development process easy.

Audio is one of the last frontiers that hasn’t been already addressed. Anything that improves the PC audio experience is welcome but don’t expect TrueAudio to work miracles. It will still only be as good as the end point hardware (in this case your headphones and associated sound card) but it should allow better speaker setups to shine, taking immersion to the next level. Will it fundamentally redefine what the PC graphics card can provide? We certainly hope so.

 

[SKYMTL]

AMD's Mantle; A Possible Game Changer

AMD's Mantle; A Possible Game Changer

In order to understand where Mantle is coming from, we need to go back in time and take the Playstation 3 as an example of how AMD wants to change the way games interact with a PC’s graphics subsystem. While the PS3’s Cell processor and its associated graphics core are extremely hard to program for, games like Uncharted 3 and The Last of Us boast visuals that are equal to if not better than some of today’s newest PC games which run on hardware that was unimaginable when Sony launched their console.

So how was this seemingly impossible feat accomplished? Consoles give developers easier access to the graphics subsystem without messy driver stacks, loads of API overhead, a cluttered OS and other unnecessary eccentricities eating up valuable resources. As a result, console games are able to fully utilize a given resource pool and allow programmers to do more with less. In some cases (the PS3 is another excellent example of this) the flow towards true utilization takes a bit longer as programmers have to literally relearn how to approach their trade but AMD's focus here is to streamline the whole process.

Mantle has been created to reduce the number of obstacles placed before developers when they’re trying to create new PC titles or port games over from consoles. In the past, things like CPU optimizations and efficient inter-component communication have largely been pushed aside as developers struggled to come to grips with the wide range of PC hardware configurations being used. This leads to multi core CPUs remaining idle, the GPU’s on-die resources being wasted and a real lack of optimal performance conditions on the PC, regardless of its advanced hardware.

There’s also a very heavy software component when programming for the PC environment since developers routinely have to contend with a predominantly heavy driver stack and slowly evolving primary level software. That’s a problem since it leads to the software / memory interaction becoming a rather stringent traffic light, bottlenecking the flow of information between the CPU and GPU, limiting throughput.

DirectX 10 and DX11 have gone a long way towards addressing some of these roadblocks but their overall performance is still hindered by their high-level nature. They keep communication between the API, GPU, game and CPU under strict control, something developers don’t want to wade through. When using them, transmitting a large number of draw calls leads to a CPU bottleneck, meaning today’s graphics architectures can never realize their full potential.

This is where Mantle gets factored into the equation; not as a direct replacement for DirectX or OpenGL but rather as a complementary force. It’s an API that focuses on “bare metal”, low level programming with a thin, lightweight driver that effectively manages resource distribution, grants additional control over the graphics memory interface and optimizes those aforementioned draw-calls. Think of Mantle like a low level strafing run that targets key components rather than high level carpet bombing that may or may not achieve a given objective.

With a more direct line of access to the GPU, AMD is hoping that GCN’s performance could drastically increase through rendering efficiencies rather than having to throw raw horsepower at problems. Opening up new rendering techniques which aren’t tied at the hip to today’s primary APIs is also a possibility. Theoretically, this could allow Mantle to process a ninefold increase in draw-calls and more importantly, it will ensure optimizations can be carried over from the console version of a game to the PC and vice versa.

There are also some notable speedbumps to this approach as well. While the high-level API (in this case DirectX / Direct3D) will remain the same across multiple hardware and product classes, Mantle is only compatible with GCN. This is great news for anyone using a compatible graphics card or one of the new consoles but GeForce and Intel HD 4000 users may be left out in the cold since, for the time being at least, neither NVIDIA not Intel have a comparable or compatible solution. Pre-GCN cards have also been cast aside in favor of forward progress. With all of this in mind, developers may be forced to bypass legacy support, add in Mantle as a selectable option, or simply ignore Mantle until incompatible products are discontinued.

It goes without saying that AMD has won the next generation console race with the Jaguar APU on both Xbox One and PS4 so leveraging those design wins is an integral part of their future strategy. But very little has been said about the high-level and lower-level APIs being used within those products, primarily the Xbox One. Direct3D 11.2 is a given but no one could point a finger at the low-level API. Microsoft has been forthcoming by saying that it isn't Mantle but the inclusion of native DirectX HLSL compatibility could go a long way towards making AMD’s cross-platform dreams come true.

In many ways, this approach reminds us of 3dfx’s Glide, another low-level application programming interface developed years ago but doomed to failure due to a lack of developer support and its parent company’s eventual demise.

One of main challenges with trying to do anything outside of the typical DirectX / OpenGL environments is selling the idea to developers. Mantle may have show limitless promise but we’ve seen plenty of other budding technologies pushed aside due to a lack industry support. This time around, AMD has some major backers from day one.

Had AMD trotted out a small development studio to pimp their new wares, very few industry pundits would have taken it seriously. Instead, they achieved immediate street cred by gaining the support of Electronic Arts and by extension Dice; a combination responsible for the Battlefied series and a multi-billion dollar juggernaut of the gaming industry.

According to Johan Andersson, lead designer at Dice and a well respected evangelist of higher level PC technology, Mantle is a collaborative effort between AMD, EA, Dice and other studios. As a result, Dice’s Frostbite 3 engine will natively support the new low-level API. That’s a huge deal when you consider the number of triple-A titles that will be using it. Games like Need for Speed: Rivals, Dragon Age Inquisition, Star Wars Battlefront and Battlefield 4 will all utilize the Frostbite 3 engine and could potentially include a Mantle option. Other developers will quickly come onboard too since Mantle was created to fulfill many of their wishes and address their concerns when creating a PC title or port.

The first title to include Mantle support will be the eagerly anticipated Battlefield 4. However, Mantle will only be rolled out in a December patch, about two months after the initial release. This bodes well for the future since it proves Mantle can be patched into a game without affecting the underlying code structure and we’d still like to see it as an onscreen option much like the Source Engine allows for switching between DirectX / OpenGL rendering modes. We will also be interested to see what kind of performance boost (if any) it will achieve over its competitors.

So with all of this taken into account, where does Mantle stand within the current API landscape? We’re not all that sure yet since the technology is very much in its infancy. Judging from the blogosphere’s reaction to its announcement, developers are already clamoring to get early access to the PC-centric version. That’s an encouraging sign. However, how Mantle evolves beyond its current iteration largely depends on AMD’s willingness to support it in the coming years and this is where the question mark lies. Due to its close association with consoles and an ability to facilitate console to PC porting, supporting it from the developer and hardware engineer standpoint will be a no-brainer so the hope for continued engagement is certainly there.

Mantle and its rollout tells us a number of things: AMD’s developer relation program is starting to pay some serious dividends, the inclusion of Graphics Core Next architecture into next generation consoles is a much bigger deal than NVIDIA initially made it out to be and AMD is dead serious about gaming as part of their core focus. Mantle is a common thread which binds so many initiatives together and it has the potential to be a watershed moment for everything in AMD’s portfolio, from the upcoming Kaveri APU to discrete graphics cards to consoles.

The move to Mantle won’t be something completed overnight. Last week’s unveiling is only the first step on what will be a long and hopefully rewarding journey. Stay tuned for more information and a complete in-depth look at Mantle during AMD’s Developer Summit in November.

 

[SKYMTL]

Test System & Setup

Main Test System

Processor: Intel i7 3930K @ 4.5GHz
Memory: Corsair Vengeance 32GB @ 1866MHz
Motherboard: ASUS P9X79 WS
Cooling: Corsair H80
SSD: 2x Corsair Performance Pro 256GB
Power Supply: Corsair AX1200
Monitor: Samsung 305T / 3x Acer 235Hz
OS: Windows 7 Ultimate N x64 SP1


Acoustical Test System

Processor: Intel 2600K @ stock
Memory: G.Skill Ripjaws 8GB 1600MHz
Motherboard: Gigabyte Z68X-UD3H-B3
Cooling: Thermalright TRUE Passive
SSD: Corsair Performance Pro 256GB
Power Supply: Seasonic X-Series Gold 800W


Drivers:
NVIDIA 331.58 Beta
AMD 13.11 v5 Beta



*Notes:

- All games tested have been patched to their latest version

- The OS has had all the latest hotfixes and updates installed

- All scores you see are the averages after 3 benchmark runs

All IQ settings were adjusted in-game and all GPU control panels were set to use application settings

The Methodology of Frame Testing, Distilled

How do you benchmark an onscreen experience? That question has plagued graphics card evaluations for years. While framerates give an accurate measurement of raw performance , there’s a lot more going on behind the scenes which a basic frames per second measurement by FRAPS or a similar application just can’t show. A good example of this is how “stuttering” can occur but may not be picked up by typical min/max/average benchmarking.

Before we go on, a basic explanation of FRAPS’ frames per second benchmarking method is important. FRAPS determines FPS rates by simply logging and averaging out how many frames are rendered within a single second. The average framerate measurement is taken by dividing the total number of rendered frames by the length of the benchmark being run. For example, if a 60 second sequence is used and the GPU renders 4,000 frames over the course of that time, the average result will be 66.67FPS. The minimum and maximum values meanwhile are simply two data points representing single second intervals which took the longest and shortest amount of time to render. Combining these values together gives an accurate, albeit very narrow snapshot of graphics subsystem performance and it isn’t quite representative of what you’ll actually see on the screen.

FCAT on the other hand has the capability to log onscreen average framerates for each second of a benchmark sequence, resulting in the “FPS over time” graphs. It does this by simply logging the reported framerate result once per second. However, in real world applications, a single second is actually a long period of time, meaning the human eye can pick up on onscreen deviations much quicker than this method can actually report them. So what can actually happens within each second of time? A whole lot since each second of gameplay time can consist of dozens or even hundreds (if your graphics card is fast enough) of frames. This brings us to frame time testing and where the Frame Time Analysis Tool gets factored into this equation.

Frame times simply represent the length of time (in milliseconds) it takes the graphics card to render and display each individual frame. Measuring the interval between frames allows for a detailed millisecond by millisecond evaluation of frame times rather than averaging things out over a full second. The larger the amount of time, the longer each frame takes to render. This detailed reporting just isn’t possible with standard benchmark methods.

We are now using FCAT for ALL benchmark results.


Frame Time Testing & FCAT

To put a meaningful spin on frame times, we can equate them directly to framerates. A constant 60 frames across a single second would lead to an individual frame time of 1/60th of a second or about 17 milliseconds, 33ms equals 30 FPS, 50ms is about 20FPS and so on. Contrary to framerate evaluation results, in this case higher frame times are actually worse since they would represent a longer interim “waiting” period between each frame.

With the milliseconds to frames per second conversion in mind, the “magical” maximum number we’re looking for is 28ms or about 35FPS. If too much time spent above that point, performance suffers and the in game experience will begin to degrade.

Consistency is a major factor here as well. Too much variation in adjacent frames could induce stutter or slowdowns. For example, spiking up and down from 13ms (75 FPS) to 28ms (35 FPS) several times over the course of a second would lead to an experience which is anything but fluid. However, even though deviations between slightly lower frame times (say 10ms and 25ms) wouldn’t be as noticeable, some sensitive individuals may still pick up a slight amount of stuttering. As such, the less variation the better the experience.

In order to determine accurate onscreen frame times, a decision has been made to move away from FRAPS and instead implement real-time frame capture into our testing. This involves the use of a secondary system with a capture card and an ultra-fast storage subsystem (in our case five SanDisk Extreme 240GB drives hooked up to an internal PCI-E RAID card) hooked up to our primary test rig via a DVI splitter. Essentially, the capture card records a high bitrate video of whatever is displayed from the primary system’s graphics card, allowing us to get a real-time snapshot of what would normally be sent directly to the monitor. By using NVIDIA’s Frame Capture Analysis Tool (FCAT), each and every frame is dissected and then processed in an effort to accurately determine latencies, frame rates and other aspects.

We've also now transitioned all testing to FCAT which means standard frame rates are also being logged and charted through the tool. This means all of our frame rate (FPS) charts use onscreen data rather than the software-centric data from FRAPS, ensuring dropped frames are taken into account in our global equation.

 

[SKYMTL]

Assassin’s Creed III / Crysis 3

Assassin’s Creed III (DX11)

<iframe width="560" height="315" src="http://www.youtube.com/embed/RvFXKwDCpBI?rel=0" frameborder="0" allowfullscreen></iframe>​

The third iteration of the Assassin’s Creed franchise is the first to make extensive use of DX11 graphics technology. In this benchmark sequence, we proceed through a run-through of the Boston area which features plenty of NPCs, distant views and high levels of detail.


2560 x1440

Crysis 3 (DX11)

<iframe width="560" height="315" src="http://www.youtube.com/embed/zENXVbmroNo?rel=0" frameborder="0" allowfullscreen></iframe>​

Simply put, Crysis 3 is one of the best looking PC games of all time and it demands a heavy system investment before even trying to enable higher detail settings. Our benchmark sequence for this one replicates a typical gameplay condition within the New York dome and consists of a run-through interspersed with a few explosions for good measure Due to the hefty system resource needs of this game, post-process FXAA was used in the place of MSAA.


2560 x1440