A Civ for a New Generation
Turn-based strategy games have long been defined by the Civilization series. Civ 5 took up hours and hours of the PC Perspective team's non-working hours (and likely the working ones too) and it looks like the new Civilization: Beyond Earth has the chance to do the same. Early reviews of the game from Gamespot, IGN, and Polygon are quite positive, and that's great news for a PC-only release; they can sometimes get overlooked in the games' media.
For us, the game offers an interesting opportunity to discuss performance. Beyond Earth is definitely going to be more CPU-bound than the other games that we tend to use in our benchmark suite, but the fact that this game is new, shiny, and even has a Mantle implementation (AMD's custom API) makes interesting for at least a look at the current state of performance. Both NVIDIA and AMD sent have released drivers with specific optimization for Beyond Earth as well. This game is likely to be popular and it deserves the attention it gets.
Civilization: Beyond Earth, a turn-based strategy game that can take a very long time to complete, ships with an integrated benchmark mode to help users and the industry test performance under different settings and hardware configurations. To enable it, you simple add "-benchmark results.csv" to the Steam game launch options and then start up the game normally. Rather than taking you to the main menu, you'll be transported into a view of a map that represents a somewhat typical gaming state for a long term session. The game will use the last settings you ran the game at to measure your system's performance, without the modified launch options, so be sure to configure that before you prepare to benchmark.
The output of this is the "result.csv" file, saved to your Steam game install root folder. In there, you'll find a list of numbers, separated by commas, representing the frame times for each frame rendering during the run. You don't get averages, a minimum, or a maximum without doing a little work. Fire up Excel or Google Docs and remember the formula:
1000 / Average (All Frame Times) = Avg FPS
It's a crude measurement that doesn't take into account any errors, spikes, or other interesting statistical data, but at least you'll have something to compare with your friends.
Our testing settings
Just as I have done in recent weeks with Shadow of Mordor and Sniper Elite 3, I ran some graphics cards through the testing process with Civilization: Beyond Earth. These include the GeForce GTX 980 and Radeon R9 290X only, along with SLI and CrossFire configurations. The R9 290X was run in both DX11 and Mantle.
- Core i7-3960X
- ASUS Rampage IV Extreme X79
- 16GB DDR3-1600
- GeForce GTX 980 Reference (344.48)
- ASUS R9 290X DirectCU II (14.9.2 Beta)
Mantle Additions and Improvements
AMD is proud of this release as it introduces a few interesting things alongside the inclusion of the Mantle API.
- Enhanced-quality Anti-Aliasing (EQAA): Improves anti-aliasing quality by doubling the coverage samples (vs. MSAA) at each AA level. This is automatically enabled for AMD users when AA is enabled in the game.
- Multi-threaded command buffering: Utilizing Mantle allows a game developer to queue a much wider flow of information between the graphics card and the CPU. This communication channel is especially good for multi-core CPUs, which have historically gone underutilized in higher-level APIs. You’ll see in your testing that Mantle makes a notable difference in smoothness and performance high-draw-call late game testing.
- Split-frame rendering: Mantle empowers a game developer with total control of multi-GPU systems. That “total control” allows them to design an mGPU renderer that best matches the design of their game. In the case of Civilization: Beyond Earth, Firaxis has selected a split-frame rendering (SFR) subsystem. SFR eliminates the latency penalties typically encountered by AFR configurations.
EQAA is an interesting feature as it improves on the quality of MSAA (somewhat) by doubling the coverage sample count while maintaining the same color sample count as MSAA. So 4xEQAA will have 4 color samples and 8 coverage samples while 4xMSAA would have 4 of each. Interestingly, Firaxis has decided the EQAA will be enabled on Beyond Earth anytime a Radeon card is detected (running in Mantle or DX11) and AA is enabled at all. So even though in the menus you might see 4xMSAA enabled, you are actually running at 4xEQAA. For NVIDIA users, 4xMSAA means 4xMSAA. Performance differences should be negligible though, according to AMD (who would actually be "hurt" by this decision if it brought down FPS).
Quick Performance Comparison
Earlier this week, we posted a brief story that looked at the performance of Middle-earth: Shadow of Mordor on the latest GPUs from both NVIDIA and AMD. Last week also marked the release of the v1.11 patch for Sniper Elite 3 that introduced an integrated benchmark mode as well as support for AMD Mantle.
I decided that this was worth a quick look with the same line up of graphics cards that we used to test Shadow of Mordor. Let's see how the NVIDIA and AMD battle stacks up here.
For those unfamiliar with the Sniper Elite series, the focuses on the impact of an individual sniper on a particular conflict and Sniper Elite 3 doesn't change up that formula much. If you have ever seen video of a bullet slowly going through a body, allowing you to see the bones/muscle of the particular enemy being killed...you've probably been watching the Sniper Elite games.
Gore and such aside, the game is fun and combines sniper action with stealth and puzzles. It's worth a shot if you are the kind of gamer that likes to use the sniper rifles in other FPS titles.
But let's jump straight to performance. You'll notice that in this story we are not using our Frame Rating capture performance metrics. That is a direct result of wanting to compare Mantle to DX11 rendering paths - since we have no way to create an overlay for Mantle, we have resorted to using FRAPs and the integrated benchmark mode in Sniper Elite 3.
Our standard GPU test bed was used with a Core i7-3960X processor, an X79 motherboard, 16GB of DDR3 memory, and the latest drivers for both parties involved. That means we installed Catalyst 14.9 for AMD and 344.16 for NVIDIA. We'll be comparing the GeForce GTX 980 to the Radeon R9 290X, and the GTX 970 to the R9 290. We will also look at SLI/CrossFire scaling at the high end.
Subject: General Tech, Graphics Cards, Shows and Expos | August 15, 2014 - 08:33 PM | Scott Michaud
Tagged: siggraph 2014, Siggraph, OpenGL Next, opengl 4.5, opengl, nvidia, Mantle, Khronos, Intel, DirectX 12, amd
Let's be clear: there are two stories here. The first is the release of OpenGL 4.5 and the second is the announcement of the "Next Generation OpenGL Initiative". They both occur on the same press release, but they are two, different statements.
OpenGL 4.5 Released
OpenGL 4.5 expands the core specification with a few extensions. Compatible hardware, with OpenGL 4.5 drivers, will be guaranteed to support these. This includes features like direct_state_access, which allows accessing objects in a context without binding to it, and support of OpenGL ES3.1 features that are traditionally missing from OpenGL 4, which allows easier porting of OpenGL ES3.1 applications to OpenGL.
It also adds a few new extensions as an option:
ARB_pipeline_statistics_query lets a developer ask the GPU what it has been doing. This could be useful for "profiling" an application (list completed work to identify optimization points).
ARB_sparse_buffer allows developers to perform calculations on pieces of generic buffers, without loading it all into memory. This is similar to ARB_sparse_textures... except that those are for textures. Buffers are useful for things like vertex data (and so forth).
ARB_transform_feedback_overflow_query is apparently designed to let developers choose whether or not to draw objects based on whether the buffer is overflowed. I might be wrong, but it seems like this would be useful for deciding whether or not to draw objects generated by geometry shaders.
KHR_blend_equation_advanced allows new blending equations between objects. If you use Photoshop, this would be "multiply", "screen", "darken", "lighten", "difference", and so forth. On NVIDIA's side, this will be directly supported on Maxwell and Tegra K1 (and later). Fermi and Kepler will support the functionality, but the driver will perform the calculations with shaders. AMD has yet to comment, as far as I can tell.
Image from NVIDIA GTC Presentation
If you are a developer, NVIDIA has launched 340.65 (340.23.01 for Linux) beta drivers for developers. If you are not looking to create OpenGL 4.5 applications, do not get this driver. You really should not have any use for it, at all.
Next Generation OpenGL Initiative Announced
The Khronos Group has also announced "a call for participation" to outline a new specification for graphics and compute. They want it to allow developers explicit control over CPU and GPU tasks, be multithreaded, have minimal overhead, have a common shader language, and "rigorous conformance testing". This sounds a lot like the design goals of Mantle (and what we know of DirectX 12).
And really, from what I hear and understand, that is what OpenGL needs at this point. Graphics cards look nothing like they did a decade ago (or over two decades ago). They each have very similar interfaces and data structures, even if their fundamental architectures vary greatly. If we can draw a line in the sand, legacy APIs can be supported but not optimized heavily by the drivers. After a short time, available performance for legacy applications would be so high that it wouldn't matter, as long as they continue to run.
Add to it, next-generation drivers should be significantly easier to develop, considering the reduced error checking (and other responsibilities). As I said on Intel's DirectX 12 story, it is still unclear whether it will lead to enough performance increase to make most optimizations, such as those which increase workload or developer effort in exchange for queuing fewer GPU commands, unnecessary. We will need to wait for game developers to use it for a bit before we know.
Subject: General Tech | August 15, 2014 - 01:09 PM | Jeremy Hellstrom
Tagged: amd, Mantle, opengl, OpenGL Next
Along with his announcements about FreeSync, Richard Huddy also discussed OpenGL Next and its relationship with Mantle and the role it played in DirectX 12's development. AMD has given Chronos Group, the developers of OpenGL, complete access to Mantle to help them integrate it into future versions of the API starting with OpenGL Next. He also discussed the advantages of Mantle over DirectX, citing AMD's ability to update it much more frequently than Intel has done with DX. With over 75 developers working on titles that take advantage of Mantle the interest is definitely there but it is uncertain if devs will actually benefit from an API which updates at a pace faster than a game can be developed. Read on at The Tech Report.
"At Siggraph yesterday, AMD's Richard Huddy gave us an update on Mantle, and he also revealed some interesting details about AMD's role in the development of the next-gen OpenGL API."
Here is some more Tech News from around the web:
- The Man Responsible For Pop-Up Ads On Building a Better Web @ Slashdot
- Skype stops working on older Android phones leaving Linux users in the dark @ The Inquirer
- ntel teams with 50 Cent's audio firm to launch heart-rate monitoring headphones @ The Inquirer
- TSMC 4Q14 production capacity almost fully booked @ DigiTimes
- Lenovo posts an INCREASE in desktop PC and notebook sales @ The Register
- Boffins brew TCP tuned to perform on lossy links like Wi-Fi networks @ The Register
Subject: General Tech | July 16, 2014 - 04:16 PM | Jeremy Hellstrom
Tagged: gaming, Mantle, battlefield 4, BF4
Mantle is currently supported by the Nitrous, Frostbite 3 and CRYENGINE engines, and the current official list of released or soon to be released games that support the new API has reached eight AAA titles. eTeknix lined up three of these games to test, Battlefield 4, Thief and PvZ Garden Warfare to test on an R9 290X paired with both a AMD FX-8350 and an FX-4100. For BF4 with the Ultra preset, no V-Sync @ 1920 x 1080 both systems saw a noticeable jump in performance and Thief even more so for the FX8350 system. Check out the full results in their review.
"The biggest claim to fame of this new low-overhead API is its use in EA’s Battlefield 4 blockbuster and the support it has from EA’s famous FrostBite 3 Engine. However, what is all the fuss about? How does Mantle actually perform in practice? Why should you even care about it? These are questions we are hoping to address today."
Here is some more Tech News from around the web:
- What's the scariest thing in the world? Ask your teenage daughter @ Polygon
- Yes, Of Course: Grim Fandango Remaster Confirmed For PC @ Rock, Paper, SHOTGUN
- Baldur’s Dash: Pillars Of Eternity Beta Begins Next Month @ Rock, Paper, SHOTGUN
- Developer: "consoles couldn't possibly handle" Star Citizen @ HEXUS
- AMD Mantle support coming to GTA V and CoD: AW says report @ HEXUS
- Braben On Elite, Oc Rift, Dodgy Gravity & Doing Space Right @ Rock, Paper, SHOTGUN
- Aperture Tag Is A Whole New Portal Game… Without Portals @ Rock, Paper, SHOTGUN
Subject: General Tech | July 10, 2014 - 01:17 PM | Ken Addison
Tagged: podcast, video, Intel, Mantle, amd, nvidia, XSPC, quantum dots, western digital, My Cloud Mirror, A10-7850K, Kaveri, arm, quakecon
PC Perspective Podcast #308 - 07/10/2014
Join us this week as we discuss Intel using Mantle, XSPC Watercooling Kits, Quantum Dots, and more!
The URL for the podcast is: http://pcper.com/podcast - Share with your friends!
- iTunes - Subscribe to the podcast directly through the Store
- RSS - Subscribe through your regular RSS reader
- MP3 - Direct download link to the MP3 file
Hosts: Ryan Shrout, Josh Walrath, Jeremy Hellstrom, Allyn Malventano, and Morry Tietelman
When Magma Freezes Over...
Intel confirms that they have approached AMD about access to their Mantle API. The discussion, despite being clearly labeled as "an experiment" by an Intel spokesperson, was initiated by them -- not AMD. According to AMD's Gaming Scientist, Richard Huddy, via PCWorld, AMD's response was, "Give us a month or two" and "we'll go into the 1.0 phase sometime this year" which only has about five months left in it. When the API reaches 1.0, anyone who wants to participate (including hardware vendors) will be granted access.
AMD inside Intel Inside???
I do wonder why Intel would care, though. Intel has the fastest per-thread processors, and their GPUs are not known to be workhorses that are held back by API call bottlenecks, either. Of course, that is not to say that I cannot see any reason, however...
Subject: Graphics Cards | June 19, 2014 - 10:35 AM | Ryan Shrout
Tagged: video, richard huddy, radeon, openworks, Mantle, freesync, amd
On Tuesday, AMD's newly minted Gaming Scientist, Richard Huddy, stopped by the PC Perspective office to talk about the current state of the company's graphics division. The entire video of the interview is embedded below but several of the points that are made are quite interesting and newsworthy. During the discussion we hear about Mantle on Linux, a timeline for Mantle being opened publicly as well as a surprising new idea for a competitor to NVIDIA's GameWorks program.
Richard is new to the company but not new to the industry, starting with 3DLabs many years ago and taking jobs at NVIDIA, ATI, Intel and now returning to AMD. The role of Gaming Scientist is to directly interface with the software developers for gaming and make sure that the GPU hardware designers are working hand in hand with future, high end graphics technology. In essence, Huddy's job is to make sure AMD continues to innovate on the hardware side to facilitate innovation on the software side.
AMD Planning an "OpenWorks" Program
(33:00) After the volume of discussion surrounding the NVIDIA GameWorks program and its potential to harm the gaming ecosystem by not providing source code in an open manner, Huddy believes that the answer to problem is to simply have NVIDIA release the SDK with source code publicly. Whether or not NVIDIA takes that advice has yet to be seen, but if they don't, it appears that AMD is going down the road of creating its own competing solution that is open and flexible.
The idea of OpenFX or OpenWorks as Huddy refers to it is to create an open source repository for gaming code and effects examples that can be updated, modified and improved upon by anyone in the industry. AMD would be willing to start the initiative by donating its entire SDK to the platform and then invite other software developers, as well as other hardware developers, to add or change to the collection. The idea is to create a competitor to what GameWorks accomplishes but in a license free and open way.
NVIDIA GameWorks has been successful; can AMD OpenWorks derail it?
Essentially the "OpenWorks" repository would work in a similar way to a Linux group where the public has access to the code to submit changes that can be implemented by anyone else. Someone would be able to improve the performance for specific hardware easily but if performance was degraded on any other hardware then it could be easily changed and updated. Huddy believes this is how you move the industry forward and how you ensure that the gamer is getting the best overall experience regardless of the specific platform they are using.
"OpenWorks" is still in the planning stages and AMD is only officially "talking about it" internally. However, bringing Huddy back to AMD wasn't done without some direction already in mind and it would not surprise me at all if this was essentially a done deal. Huddy believes that other hardware companies like Qualcomm and Intel would participate in such an open system but the real question is whether or not NVIDIA, as the discrete GPU market share leader, would be in any way willing to do as well.
Still, this initiative continues to show the differences between the NVIDIA and AMD style of doing things. NVIDIA prefers a more closed system that it has full control over to perfect the experience, to hit aggressive timelines and to improve the ecosystem as they see it. AMD wants to provide an open system that everyone can participate in and benefit from but often is held back by the inconsistent speed of the community and partners.
Mantle to be Opened by end of 2014, Potentially Coming to Linux
(7:40) The AMD Mantle API has been an industry changing product, I don't think anyone can deny that. Even if you don't own AMD hardware or don't play any of the games currently shipping with Mantle support, the re-focusing on a higher efficiency API has impacted NVIDIA's direction with DX11, Microsoft's plans for DX12 and perhaps even Apple's direction with Metal. But for a company that pushes the idea of open standards so heavily, AMD has yet to offer up Mantle source code in a similar fashion to its standard SDK. As it stands right now, Mantle is only given to a group of software developers in the beta program and is specifically tuned for AMD's GCN graphics hardware.
Huddy reiterated that AMD has made a commitment to release a public SDK for Mantle by the end of 2014 which would allow any other hardware vendor to create a driver that could run Mantle game titles. If AMD lives up to its word and releases the full source code for it, then in theory, NVIDIA could offer support for Mantle games on GeForce hardware, Intel could offer support those same games on Intel HD graphics. There will be no license fees, no restrictions at all.
The obvious question is whether or not any other IHV would choose to do so. Both because of competitive reasons and with the proximity of DX12's release in late 2015. Huddy agrees with me that the pride of these other hardware vendors may prevent them from considering Mantle adoption though the argument can be made that the work required to implement it properly might not be worth the effort with DX12 (and its very similar feature set) around the corner.
(51:45) When asked about AMD input on SteamOS and its commitment to the gamers that see that as the future, Huddy mentioned that AMD was considering, but not promising, bringing the Mantle API to Linux. If the opportunity exists, says Huddy, to give the gamer a better experience on that platform with the help of Mantle, and developers ask for the support for AMD, then AMD will at the very least "listen to that." It would incredibly interesting to see a competitor API in the landscape of Linux where OpenGL is essentially the only game in town.
AMD FreeSync / Adaptive Sync Benefits
(59:15) Huddy discussed the differences, as he sees it, between NVIDIA's G-Sync technology and the AMD option called FreeSync but now officially called Adaptive Sync as part of the DisplayPort 1.2a standard. Beside the obvious difference of added hardware and licensing costs, Adaptive Sync is apparently going to be easier to implement as the maximum and minimum frequencies are actually negotiated by the display and the graphics card when the monitor is plugged in. G-Sync requires a white list in the NVIDIA driver to work today and as long as NVIDIA keeps that list updated, the impact on gamers buying panels should be minimal. But with DP 1.2a and properly implemented Adaptive Sync monitors, once a driver supports the negotiation it doesn't require knowledge about the specific model beforehand.
AMD demos FreeSync at Computex 2014
According to Huddy, the new Adaptive Sync specification will go up to as high as 240 Hz and as low as 9 Hz; these are specifics that before today weren't known. Of course, not every panel (and maybe no panel) will support that extreme of a range for variable frame rate technology, but this leaves a lot of potential for improved panel development in the years to come. More likely you'll see Adaptive Sync ready display listing a range closer to 30-60 Hz or 30-80 Hz initially.
Prototypes of FreeSync monitors will be going out to some media in the September or October time frame, while public availability will likely occur in the January or February window.
How does AMD pick game titles for the Never Settle program?
(1:14:00) Huddy describes the fashion in which games are vetted for inclusion in the AMD Never Settle program. The company looks for games that have a good history of course, but also ones that exemplify the use of AMD hardware. Games that benchmark well and have reproducible results that can be reported by AMD and the media are also preferred. Inclusion of an integrated benchmark mode in the game is also a plus as it more likely gets review media interested in including that game in their test suite and also allows the public to run their own tests to compare results.
Another interesting note was the games that are included in bundles often are picked based on restrictions in certain countries. Germany, for example, has very strict guidelines for violence in games and thus add-in card partners would much prefer a well known racing game than an ultra-bloody first person shooter.
First and foremost, a huge thanks to Richard Huddy for making time to stop by the offices and talk with us. And especially for allowing us to live stream it to our fans and readers. I have had the privilege to have access to some of the most interesting minds in the industry, but they are very rarely open to having our talks broadcast to the world without editing and without a precompiled list of questions. For allowing it, both AMD and Mr. Huddy have gained some respect!
There is plenty more discussed in the interview including AMD's push to a non-PC based revenue split, whether DX12 will undermine the use of the Mantle API, and how code like TressFX compares to NVIDIA GameWorks. If you haven't watched it yet I think you'll find the full 90 minutes to be quite informative and worth your time.
UPDATE: I know that some of our readers, and some contacts and NVIDIA, took note of Huddy's comments about TressFX from our interview. Essentially, NVIDIA denied that TressFX was actually made available before the release of Tomb Raider. When I asked AMD for clarification, Richard Huddy provided me with the following statement.
I would like to take the opportunity to correct a false impression that I inadvertently created during the interview.
Contrary to what I said, it turns out that TressFX was first published in AMD's SDK _after_ the release of Tomb Raider.
Nonetheless the full source code to TressFX was available to the developer throughout, and we also know that the game was available to NVIDIA several weeks ahead of the actual release for NVIDIA to address the bugs in their driver and to optimize for TressFX.
Again, I apologize for the mistake.
That definitely paints a little bit of a different picture on around the release of TressFX with the rebooted Tomb Raider title. NVIDIA's complaint that "AMD was doing the same thing" holds a bit more weight. Since Richard Huddy was not with AMD at the time of this arrangement I can see how he would mix up the specifics, even after getting briefed by other staff members.
If you want to be sure you don't miss any more of our live streaming events, be sure to keep an eye on the schedule on the right hand side of our page or sign up for our PC Perspective Live mailing list right here.
Subject: General Tech, Graphics Cards | May 1, 2014 - 08:00 AM | Scott Michaud
Tagged: Mantle, amd
As our readers are well aware, Mantle is available for use with a few games. Its compatibility begun with the beta Catalyst 14.1 driver and an update for Battlefield 4. AMD was quite upfront about the technology, even granting a brief interview with Guennadi Riguer, Chief Architect of the API to fill in a few of the gaps left from their various keynote speeches.
What is under lock and key, however, is the actual software development kit (SDK). AMD claimed that it was too immature for the public. It was developed in partnership with DICE, Oxide Games, and other, established developers to fine-tune its shape, all the while making it more robust. That's fine. They have a development plan. There is nothing wrong with that. Today, while the SDK is still not public and sealed by non-disclosure agreement, AMD is accepting applications from developers who are requesting to enter the program.
If you want to develop a Mantle application or game, follow the instructions at their website for AMD to consider you. They consider it stable, performant, and functional enough for "a broader audience in the developer community".
AMD cites 40 developers already registered, up from seven (DICE, Crytek, Oxide, etc.).
If you are not a developer, then this news really did not mean too much to you -- except that progress is being made.
Competition is a Great Thing
While doing some testing with the AMD Athlon 5350 Kabini APU to determine it's flexibility as a low cost gaming platform, we decided to run a handful of tests to measure something else that is getting a lot of attention right now: AMD Mantle and NVIDIA's 337.50 driver.
Earlier this week I posted a story that looked at performance scaling of NVIDIA's new 337.50 beta driver compared to the previous 335.23 WHQL. The goal was to assess the DX11 efficiency improvements that the company stated it had been working on and implemented into this latest beta driver offering. In the end, we found some instances where games scaled by as much as 35% and 26% but other cases where there was little to no gain with the new driver. We looked at both single GPU and multi-GPU scenarios on mostly high end CPU hardware though.
Earlier in April I posted an article looking at Mantle, AMD's answer to a lower level API that is unique to its ecosystem, and how it scaled on various pieces of hardware on Battlefield 4. This was the first major game to implement Mantle and it remains the biggest name in the field. While we definitely saw some improvements in gaming experiences with Mantle there was work to be done when it comes to multi-GPU scaling and frame pacing.
Both parties in this debate were showing promise but obviously both were far from perfect.
While we were benchmarking the new AMD Athlon 5350 Kabini based APU, an incredibly low cost processor that Josh reviewed in April, it made sense to test out both Mantle and NVIDIA's 337.50 driver in an interesting side by side.