That's one thing but zoomed out, it just seems like much more work to use ue3 then rewrite the renderer than to just use ue4...I'm no software dev but this just seems so that impractical.
That's one thing but zoomed out, it just seems like much more work to use ue3 then rewrite the renderer than to just use ue4...I'm no software dev but this just seems so that impractical.That's what happens when you take your original code using an old version of UE3 and try to staple DX12 on.
Will be real interesting to see if Quantum Break has similar issues. Could be some where along the way the "DX12 on console to PC port be so easy" meme broke.
PC edition's graphical fidelity is improved through the introduction of NVIDIA HBAO+ Ambient Occlusion shadowing.
Is Quantum Break using any GameWorks?
This title has NV HBAO+ tacked onto it and it's either on/off, no other normal AO implementation.
http://www.geforce.com/whats-new/ar...r-ultimate-edition-game-ready-driver-released
You know it's bad when the actual developers are telling radeon users to disable AO to fix issues, so they actually are fully aware, what's gimping AMD GPUs is the NV HBAO+ code.
As for issues with Fiji, it seems to be a repeating theme. Fiji stuttered badly in Rise of Tomb Raider before AMD could optimize their drivers (16.1.1), while other GCN had no issues.
I suspect HBM requires specific memory optimization that differs greatly to GDDR5, timings and allocations, because each stack has it's own MC slice.
"You're not limited in this world to any number of stacks, but from a capacity point of view, this generation-one HBM, each DRAM is a two-gigabit DRAM, so yeah, if you have four stacks you're limited to four gigabytes. You could build things with more stacks, you could build things with less stacks. Capacity of the frame buffer is just one of our concerns. There are many things you can do to utilise that capacity better. So if you have four stacks you're limited to four [gigabytes], but we don't really view that as a performance limitation from an AMD perspective."
"If you actually look at frame buffers and how efficient they are and how efficient the drivers are at managing capacities across the resolutions, you'll find that there's a lot that can be done. We do not see 4GB as a limitation that would cause performance bottlenecks. We just need to do a better job managing the capacities. We were getting free capacity, because with [GDDR5] in order to get more bandwidth we needed to make the memory system wider, so the capacities were increasing. As engineers, we always focus on where the bottleneck is. If you're getting capacity, you don't put as much effort into better utilising that capacity. 4GB is more than sufficient. We've had to go do a little bit of investment in order to better utilise the frame buffer, but we're not really seeing a frame buffer capacity [problem]. You'll be blown away by how much [capacity] is wasted."
- Joe Marci
That's one thing but zoomed out, it just seems like much more work to use ue3 then rewrite the renderer than to just use ue4...I'm no software dev but this just seems so that impractical.
Is Quantum Break using any GameWorks?
This title has NV HBAO+ tacked onto it and it's either on/off, no other normal AO implementation.
http://www.geforce.com/whats-new/ar...r-ultimate-edition-game-ready-driver-released
You know it's bad when the actual developers are telling radeon users to disable AO to fix issues, so they actually are fully aware, what's gimping AMD GPUs is the NV HBAO+ code.
As for issues with Fiji, it seems to be a repeating theme. Fiji stuttered badly in Rise of Tomb Raider before AMD could optimize their drivers (16.1.1), while other GCN had no issues.
I suspect HBM requires specific memory optimization that differs greatly to GDDR5, timings and allocations, because each stack has it's own MC slice.
You do know one set of Radeons isn't experience the severity as another set of Radeons are?
You can blame Gameworks until you turn blue, wouldn't put it past you, but there is more to this otherwise all Radeons would be experiencing the same issues.
This is AMD's inability to handle memory management in directx 12. They need to fix their drivers as usual.
<br />Wrong, AMD has conformant DX12 drivers ... <br />
<br />
It's very rare that non-standard behaviour occurrence is at the fault of the drivers as far as DX12 is concerned ... <br />
<br />
It's Nvidia/developer that's at fault for the visual corruption with HBAO+ on AMD cards since they're the one's responsible for porting it to DX12 ...
<br />
<br />
This is the first major directx 12 release. So I don't know what you are basing your claims on.
<br />
<br />
This is the first major directx 12 release. So I don't know what you are basing your claims on.
What part of the actual developers of Gears of Wars, saying AO (which we now know, is NV HBAO+) is the feature causing issues with Radeons don't you understand?
Where did the devs say that?
http://www.geforce.com/whats-new/ar...r-ultimate-edition-game-ready-driver-released
Nvidia THEMSELVES say their using HBAO+ ...
Where did the devs say that?
There are visual issues with AMD graphics cards and the Ambient Occlusion setting, it is strongly recommended to turn this setting OFF.
On the official forum.
https://gearsofwar.com/en-us/forums...es/9aa87281-98f1-4203-aed5-95ddb54420db/posts
They didn't mention it's NV's HBAO+, but NVIDIA had no problems mentioning it in their press release. heh
I just wanted to clarify what the devs said as one of the big issues with the game on AMD GPUs. There's other problems for sure.
Tacking on DX12 on such an ancient engine like UE3 is questionable to start with. I thought they went for a real remake, but yeah... Microsoft is actually not inspiring any faith at all in DX12 and their App Store so far.
Devs should seriously consider Vulkan if they haven't done so already. True cross-platform, not tied to Win10 and not tied to Microsoft's ecosystem.
Eh?Then they don't get WDDM 2.0 or equivalents ...
If IHVs want to build their implementation around inferior display driver models then they can try so but quite a bit of the CPU reduction overhead comes from that ...
Eh?
Vulkan is on top of WDDM, it is not a replacement for it.
https://twitter.com/repi/status/585573314669711361
Wrong, AMD has conformant DX12 drivers ...
It's very rare that non-standard behaviour occurrence is at the fault of the drivers as far as DX12 is concerned ...
It's Nvidia/developer that's at fault for the visual corruption with HBAO+ on AMD cards since they're the one's responsible for porting it to DX12 ...
On the official forum.
https://gearsofwar.com/en-us/forums...es/9aa87281-98f1-4203-aed5-95ddb54420db/posts
They didn't mention it's NV's HBAO+, but NVIDIA had no problems mentioning it in their press release. heh
Go on, spin it if you wish. But when devs talk like that, it reminds me of CDPR and HairWorks gimping AMD performance. They said if you recall along the lines of "we can't do anything about that cos it's NV code, just turn it off"..
However, a few months later, they actually updated it with an optimized HairWorks in the patch notes. And they added sliders for it to lower tessellation factors for users. Good devs as they put in the effort to optimize NV's sloppy feature.
Like it was AMD's fault for broken shadows in Dragon Age 2 with Nvidia cards?