Monday, March 6th 2017

AMD Project ReSX is an eSports Gamer Outreach by Making Radeon More Responsive

AMD's late-Monday release of the Radeon Software Adrenalin 18.3.1 has a big change not chronicled in its change-log, the first implementation of ReSX. Short for "Radeon eSports Experience," ReSX is the code-name of a major effort within the Radeon Software team to address some of the fundamental complaints competitive eSports gamers had been having with Radeon GPUs - click-to-response and frame-time. As an eSports gamer chasing a million-dollar price-pool, you'd want your graphics hardware to have the least frame-time (the most fluid output), the highest frame-rates, and of course the least click-to-response time (the infinitesimal amount it times for a click of your mouse to register as action, be sent to the game-server, and render on-screen, simultaneously.

AMD stated that has approached these problems from two fronts - by working with developers of the biggest eSports titles to optimize their game-engines for Radeon; as well as making under-the-hood changes to Radeon Software. The company is announcing not just marginally higher frame-rates in certain eSports titles, but also significant improvements to frame-time (99th percentile of), and lower click-to-response times. According to the performance numbers put out by AMD, while these improvements may not be double-digit percentage points difference, could still translate into a vastly improved gaming experience, according to AMD.
Add your own comment

30 Comments on AMD Project ReSX is an eSports Gamer Outreach by Making Radeon More Responsive

#26
bug
kruk said:
My point is that some devs obviously can make games run faster on DX11 that others (just look at the benchmarks here on TPU from like 2016). If you can't optimize like they do in DX11, why not go Vulkan/DX12? Several engines already support it. Why should AMD resort to driver hacks, if there is a much better native alternative for both, red and green team?
So your argument against AMD doing something about their higher driver overhead is that devs should use a different API. Neat.
Posted on Reply
#27
renz496
theoneandonlymrk said:
You getting on topic at some point??

You brought up compute not I, i just corrected some of your miss direction.

I find it really funny when trolls work tangential arguments.
And i initially did not talk to you either. I was replying to HD64G about what he says about GCN compute over nvidia. Now you complain me talking about compute and not you who brought the topic? Before you call me a troll maybe you should look yourself at the mirror first.
Posted on Reply
#28
BiggieShady
renz496 said:
I was replying to HD64G about what he says about GCN compute over nvidia.
... and it was a good point you made. However I would add that mining algorithms are not written for GCN, rather suitable for GCN - the whole class of algorithms favors GCN as it lets it operate closer to architecture's peak efficiency (perf/watt). All kinds of cuda mining software have great gcn counterparts, can't say the same for vice versa. As for pointing out Fermi as a milestone, I agree - all that nvidia has been doing last 7 years was refining fermi and look where it got them perf/watt wise.
Posted on Reply
#29
kruk
bug said:
So your argument against AMD doing something about their higher driver overhead is that devs should use a different API. Neat.
Great selective reading skills and nice bait, but I'll pass ...
Posted on Reply
#30
bug
kruk said:
Great selective reading skills and nice bait, but I'll pass ...
Thanks. It means a lot coming from you.
Posted on Reply
Add your own comment