Kingdoms of Amalur Re-reckoning

The thing is neither of those had such performance issues from the start. So there was nothing to fix in that regard. Also Darksiders Warmastered and Darksiders 2 both ran worse than their original counterpart and didn’t look much or any better than before.

Also stuff like this shouldn’t be a thing Day 1. Its stupid how bad ports and or performance have become the expectation these days. You’re spending money on it not getting it for free. Expecting a shit port is the worst thing ever.

I upgraded from a 1600X to a 3600X and the FPS is exactly the same. So its not even a CPU limitation. GPU wise a 1080 should nowhere needed to play this either. So it comes down to the game itself.

1 Like

Agreed on this especially, big well funded project having to get support over months to iron out launch issues should have never become a thing in the first place.

Big publishers not being able to take the time and budget needed for a port of a existing game and the assets and code too instead managing a inferior version which hopefully can be patched up but just as often is just dropped also.

Thats the thing… they claim it to be running at 4k 60 on Xbox One X. So either it’s super checkerboarded or all optimization went there. Otherwise i can’t explain how this game started to perform this bad from a DX9 to DX 11 jump compared to the original.

Console port might be more robust, only thing I can find is 2560x1440 on PS4 Pro and upscaling to 4k and then it claims 4k native for the XBox One X which would mean it doesn’t use checkerboard or other upscaling methods.

Well it would if the listing was consistent at least, often it’s just vague “4k” and the method to reach this can vary.

Wonder what’s bottlenecking the PC version though, draw calls and culling should be hitting consoles too if there’s a miss here but there’s differences in PC D3D and what the XBox use just for one thing including D3D12 but that was probably not used here.
(Kaldaien mentioned that as a underlying hindrance for the two recent Assassin’s Creed games though.)

Hmm a 3000 series Ryzen has improvements to single core performance too and newer Windows10 and chipset drivers aid the way the scheduler and scaling works for Zen2 CPU’s and while faster at this there’s something a bit wrong with the code if a Intel i9 9000 or 10000 series CPU is needed to remove that bottleneck.

EDIT: Considering how important and aggressive LOD and geometry culling is on consoles it’s strange that it would break because if there’s something wrong with it the performance hit should be pretty noticeable.

Modern games get really clever trying to push detail while having a incredibly aggressive draw distance limit and removing non-visible geometry plus more sophisticated middleware for this sort of purpose too Umbra for example I believe for one of them.

Curious, wonder if they really messed something up somewhere and this just broke entirely.
Could be a invalid D3D usage or just a typo so they might have to do some digging and checking in the code to figure it out.

Meaning it could take a while to find what’s wrong.

EDIT: Plus documentation and Microsoft and a lot of DXGI, D3D and DWM behaviors.
Gotten better but that shows up constantly for DXVK’s issue tracker.

Exactly if it would have been SIngle Core bound i should have seen an improvement from 1600X to 3600X.
My GPU is a 1080 and runs the original better since the upgrade. So there is something wrong there. And its neither CPU or GPU :confused:

1 Like

DXVK does wonders for the game.

Specs:
GTX 1080 Ti on a 8700K, Win10


–720p with everything at lowest–

D3D11 - ~70 FPS

DXVK - ~170 FPS


–4K with everything set to highest (except for supersampling and without AA enabled)–

DXVK - ~45 FPS

https://images.aemony.se/sharex/koa_2020-09-21_21-32-30.png

DXVK - ~60 FPS

https://images.aemony.se/sharex/koa_2020-09-21_21-35-39.png


Anyone interested in throwing DXVK at the game can do so by following these short few instructions:

  1. Download the latest tar.gz archive from Releases · doitsujin/dxvk · GitHub

  2. Open the archive in an archive manager and extract dxgi.dll and d3d11.dll from the x32 folder of the archive to the game folder.

  3. Run the game.

1 Like

Or the builds of it from here.
https://git.froggi.es/doitsujin/dxvk/-/jobs

Of the latest commits there’s nothing particularly important though.

The latest submitted build project failed though so this ends at the first commit from September 4th.

Missing some neat stuff from September 11th, September 14th and September 17th but once DXVK 1.7.2 is out or what the next version will be that’s a non issue. :slight_smile:

As to what’s to gain over 1.7.1 the memory heap improvements seem like a good enhancement.
(But not a must have addition or anything.)

EDIT: X32 ?

Hmm would have assumed 64-bit as the go-to default nowadays interesting.

EDIT: Driver wise AMD 20.8.3 or the current latest 20.9.1 for the Vulkan extensions it contains.
NVIDIA I’m not sure what the 356.38 (Was it?) drivers go up to and then there’s the VLK beta drivers which has the newest extensions but it’s on a 350.xx branch missing the newer core driver merges since which 350 - 352 driver it’s based on.

Vulkan also has a runtime.
https://vulkan.lunarg.com/sdk/home

Drivers often include this anyway but it’s backwards compatible so I prefer just having the latest overall.

1.2.148.1 resolves a crash issue and that’s kinda why I keep the runtime up to date whereas generally it just matches up with the latest SDK release version and changes and support for that.
(AMD’s bundled runtime is version 1.2.135.0 I believe, unsure about NVIDIA’s bundled files and their version of this think it’s 1.2.130 to 1.2.133 somewhere.)

EDIT: As for the extensions well it’s the ones from DXVK 1.7.0 and 1.7.1

VK_EXT_extended_dynamic_state
VK_EXT_robustness2
VK_EXT_custom_border_color

Various fixes, optimizations and general improvements, nothing mandatory though but various edge cases and overall tweaks and bug fixing or smaller performance gains if supported.

EDIT: (Yeah a few of these.)
Github page has some good examples for what these are then used for with DXVK. :slight_smile:
(Support what DXGI and D3D9 and D3D11 does or kinda does or mostly support how these do things greatly simplified.)

It’s funny how DXVK increases CPU and VRAM usage, and decreases GPU usage, while still improving overall framerate across the board, by up to ~140% at 720p.

We should throw DXVK at more games that struggles with performance.

Yup, a 32-bit remaster in 2020… :expressionless:

2 Likes

Sadly been more or a “worsemaster” so far :>
Thanks yet again @Aemony i don’t know why i didn’t throw DXVK at it earlier. First time i had such issues and never had used it before.

Yes, I am absolutely certain the performance bottleneck comes from drawing geometry that is not visible. I used SK’s D3D11 graphics debugger to determine this, killing the draw calls causes framerate to shoot through the roof. Those draw calls would not be happening if the engine were better at culling.

The thing here, though, is there is not much of anything a port developer can do about this. You should not be asking them to fix an issue like this, it is just something I can observe and point out is unfortunate, not something that is fixable by anyone but the original engine developer.

What’s with RTSS? Special K is compatible with DXVK :slight_smile:

Lol, only reason I used RTSS for these screenshots was because it lists the API it hooked in its OSD :smiley:

1 Like

Oh, that makes sense :slight_smile:

I hate RTSS’s graphs :disappointed:, they do not smoothly interpolate and very often frametime jitter looks like long vertical lines. It’s impossible to get an accurate picture of any data when the graphs behave that way.

Also, what the hell…? The GPU load% is < 1/2 in the Vulkan screenshot.

The differences between Vk and D3D11 should be API overhead related (and thus CPU) only, I think DXVK is not correctly implementing something and that is indirectly the cause of performance gains. It would be awesome to know which part of D3D11 you can basically ignore and still get an accurate image, that is a feature I would add to Special K :slight_smile:

There’s still a fair bit of stuff I believe that DXVK and D3D11 aren’t quite on par with and might never be, extension support manages for a good bit of it and some of these even became mandatory in newer DXVK builds but it works pretty well with the extension system and having support if it’s available due to differences here for AMD Windows, AMD Linux (Two driver cores?) and NVIDIA Windows and Linux (Plus Intel) supports these by default.

Going through the DXVK issue tracker there’s a lot of weird implementations in some games and others do things that aren’t documented or documented incorrectly, managing all that must be a pretty big effort plus support across D3D9 to D3D11 with all this entails and possibly D3D12 later on.

AMD Navi user here though so I use it by default because the driver code for VK and D3D12 just works a lot better, D3D11 has improved but D3D9/D3D10 is not that great yet (Fixed on a per game basis too from AMD.) plus outside of straight up big performance boosts it also operates more stable and smoother.
(GPU-Z and just logging how it scales or the fan profile logic - there is one now. - but AMD finally fixed that issue - mostly. - in the 20.9.1 drivers. :smiley: )

Great hardware but the code base for D3D11 and earlier is kinda problematic though it’s gotten quite a bit better.

Still interesting that it just works so much better even with DXVK and on NVIDIA too for several games now and both D3D9 and D3D11 also.

Hmm…

GOL : What gave you the idea for DXVK? Why did you decide to make it?

DXVK : “It’s a combination of being dissatisfied with the performance of wine’s own D3D11 implementation, not wanting to dual-boot to Windows anymore, and being inspired by the VK9 project which I had been keeping an eye on for some time. And I really wanted to get one specific game to work.

GOL : Since you’re now contracted by Valve, how did that happen? Must have been quite a shock initially to have Valve approach you?

DXVK : “It wasn’t all that spectacular - they contacted me when News made the round that DXVK could run Nier [NieR:Automata] back in late January, and when offered to work full-time on the project after a friendly chat, I couldn’t really refuse.


So, NieR: Automata is partially responsible for DXVK’s popularity and Valve contacted the developer in response to that game. How come they never contacted me when I “weaponized SteamAPI” in my NieR: Automata mod? :stuck_out_tongue: I feel bamboozled.

1 Like

Speaking of NieR: Automata, it’s funny how after only 3 years the performance optimization FAR has largely become irrelevant.

It all meant the difference between 60 FPS at 4K and 30 FPS when the game shipped and I was running a GTX 1080, now we have GPUs that lock at 4K/60 in that game for 1/2 the price of my 1080. The performance equation has shifted so far in 3 years, that I can even run the game in scRGB HDR without the lighting mod.

At this point, all of NieR: Automata’s problems are image quality. When performance no longer matters you start to realize how broken the game is visually, lol.

You can play nier with unlocked fps though =)
Yes it bugs in some things but for the majority it feels great at 120 or 144

Because your friends list was maxed out at the time… :grin:

lol.

Definitely wasn’t looking for a job offer as in the case of DXVK, but just some kind of statement on whether using SteamAPI at all as a non-partner was acceptable would have been nice. That whole “weaponizing SteamAPI” catch phrase could have gone away more smoothly. I am all but certain if NieR: Automata was the reason for Valve getting involved with DXVK that someone in a developer capacity also knew Special K existed and said nothing.