facebook rss twitter

ROTR and ZBrush performance updates cheer AMD Ryzen users

by Mark Tyson on 26 June 2017, 12:31

Tags: AMD (NYSE:AMD)

Quick Link: HEXUS.net/qadizj

Add to My Vault: x

AMD's Technical Marketing guy Robert Hallock again took to the firm's blogs ahead of the weekend. As usual it's good news for AMD hardware users. The latest post by Hallock details performance updates for AMD Ryzen users that will significantly speed up game Rise of the Tomb Raider, and 3D art app ZBrush by Pixologic.

Rise of the Tomb Raider

Players of Rise of the Tomb Raider on AMD Ryzen processors can enjoy a huge performance uplift delivered in version 770.1 of the game. Check out the graphs derived from AMD's own testing of the game in Full HD and medium and high quality presets, below. On average this performance uplift is a meaty 28 per cent.

Developer Crystal Dynamics explained the optimisation success was down to tuning the size of split rendering tasks. "By tuning the size of those tasks – breaking some up, allowing multicore CPUs to contribute in more cases, and combining some others, to reduce overheads in the scheduler – the game can more efficiently exploit extra threads on the host CPU," said the developer.

The latest update to ROTR is available via Steam right now. You can update, and roll back and forth, to do your own comparative testing.

Pixologic ZBrush

AMD is delighted with the new ZBrush (4R8) update. Describing the performance update as a "doozy," Robert Hallock published test results showing that in some operations ZBrush now performed a stunning 204,772 per cent faster than it did previously on AMD Ryzen processors.

As I am not a ZBrush user, though I have seen its impressive artwork, and so I am not sure how this 'Light Placement Time' improvement impacts upon ZBrush artists. In an example given, placing lights in the real-time viewport of the program previously took 22.5 seconds but now "this routine operation" takes just 11ms.

The update isn't entirely one dimensional as the headlining improvement might suggest. UI operations involving the Draw and Light menus are said to be "altogether snappier" too. It would be interesting to know what impact the ZBrush software optimisations have had on users of (many-core) Intel processors.



HEXUS Forums :: 7 Comments

Login with Forum Account

Don't have an account? Register today!
22.5 seconds to 11 milliseconds. That is not just a performance leap, that's just crazy to near unbelievablity (not even sure that's a word it's so crazy).

Basically they had a performance increase for that “routine job”, that's over a 2000% increase.

It is interesting that because the Zen Architecture is so different that intelligent design of the code and processes for the new system increases performance.
Optimization!!! We need more optimization! We have powerful hardware but the hurry to put a product on the “shelf” often developers “forget” to do any optimization…
Tabbykatze
22.5 seconds to 11 milliseconds. That is not just a performance leap, that's just crazy to near unbelievablity (not even sure that's a word it's so crazy).

Basically they had a performance increase for that “routine job”, that's over a 2000% increase.

It is interesting that because the Zen Architecture is so different that intelligent design of the code and processes for the new system increases performance.
That's likely some improvements to the underlying code too. While I can't see zen as the sole reason for the boost, going back to look at ‘optimisations’ for it could have resulted in using ‘better code’ and as such I fully expect intel cpu's seeing a boost too but then that wouldn't help AMD's marketing team lol

I kind of expect to see other applications see similar ‘improvements’ in some areas because a lot of professional programs use a lot of legacy code that is completely unoptimised and causes slow performance. I know 3DS max still has plenty of bits that aren't even multithreaded for example….
Going from 22.5 seconds to 11 milliseconds seems more like they fixed a bug than optimizing something, it's difficult to know if I'm just arguing semantics though as we don't know how long it took on an Intel based system. :)
Corky34
Going from 22.5 seconds to 11 milliseconds seems more like they fixed a bug than optimizing something, it's difficult to know if I'm just arguing semantics though as we don't know how long it took on an Intel based system. :)

I think performance loss to bug or bad code can be an interchangeable term xD