What does Chief think about NVIDIA's Do's and Don'ts DirectX guide?

Talk to software developers and aspiring geeks. Programming tips. Improve motion fluidity. Reduce input lag. Come Present() yourself!
Post Reply
diakou
Posts: 83
Joined: 09 Aug 2020, 11:28

What does Chief think about NVIDIA's Do's and Don'ts DirectX guide?

Post by diakou » 09 Oct 2020, 23:03

So recently, Kaldaien made me aware of a post called https://developer.nvidia.com/dx12-dos-and-donts
It's essentially a short checklist of what game developers should and shouldn't be doing with the API, however it's not strictly only dx12, but also some earlier versions and the rules also pertain to similar looking API's (like Vulkan)

Update 1: Apparently there is a Vulkan specific version as well https://developer.nvidia.com/blog/vulkan-dos-donts/

I was mostly curious on if there's anything that sticks out as odd to you regarding Do's or Don'ts in games in regards to areas you have expertise in (such as things that would affect g-sync, framepacing etc)

So far to me some of the info looks very solid for how short and simple they made it, Kaldaien had this to say about the Swap Chain portions (and at this point, from my extreme amounts of internet scouring, I'm fairly confident Kaldaien and Special K is the Chief and Blurbusters/Testufo version for understanding on swap chain related work in too many games to count)
"It’s chock full of information that I had to figure out the hard way. That section on Swap Chains is spot on, and the only game I have seen that demonstrates a working knowledge of those bullet-points is DOOM Eternal.

On the opposite extreme, Horizon: Zero Dawn doesn’t seem to understand any of the information presented there. It’s very bad to work in a low-level API and do the exact opposite of what the driver developers tell you is best practice.
Figuring out your takes on it as well would be very appreciated whenever you find the time as I think this is another strong way of helping games act and behave smoothly so they can bring true joy and immersion by linking it to game devs.

and lastly an image used jokingly at the end of the post because I found it funny when someone just raw wrote "Happiness vs Lag" from: The Effects of Network Latency on Player Gaming Experience by By Meixintong Zha & Ying Zhang

Image

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: What does Chief think about NVIDIA's Do's and Don'ts DirectX guide?

Post by Chief Blur Buster » 10 Oct 2020, 01:04

diakou wrote:
09 Oct 2020, 23:03
I was mostly curious on if there's anything that sticks out as odd to you regarding Do's or Don'ts in games in regards to areas you have expertise in (such as things that would affect g-sync, framepacing etc)
They are excellent general DO / DON'T's for most use cases.

There are some additional base-cases not listed -- that are applicable for special cases like emulators, which can benefit instead from internal inputdelay logic + waitable swapchains so that you have no frame queue buildups while having minimum lag. With such specialized algorithms built into certain emulators, they have no need for external utils such as RTSS or Kaleidan (in most cases) because of their highly lag-optimized nature of several brands of emulators;
diakou wrote:
09 Oct 2020, 23:03
So far to me some of the info looks very solid for how short and simple they made it, Kaldaien had this to say about the Swap Chain portions (and at this point, from my extreme amounts of internet scouring, I'm fairly confident Kaldaien and Special K is the Chief and Blurbusters/Testufo version for understanding on swap chain related work in too many games to count)
There's so many swapchain workflows in games that they are really essentially black boxes -- some optimized for 60Hz consoles, some optimized for varying framerate / VRR / VSYNC OFF operation -- etc.

But generally, VSYNC ON workflows are often surprisingly lag-inefficient, they just try to render as fast as possible and then cram the frame queue full. And let the drivers throttle the framerate by blocking when the frame queue is full (Max prerendered frames). A queue can make things smooth (absorb render/CPU variances better = less stutter) but adds lag. This is unwanted in high performance gaming for the largest part.

With VRR, an in-game queue really is not necessary, since the display can float its refresh rate with framerate modulating with system performance -- and still look smooth. Sometimes a game switches algorithms when enabling VSYNC ON (fixed timer) versus VSYNC OFF (non-fixed timer), though not all of them. That's why sometimes I have to do the opposing-settings manoever (GSYNC+VSYNC in in NVCP, but VSYNC OFF in the in-game menus) to get the best G-SYNC performance. It's kinda user unfriendly sometimes.

Alas, external framerate cappers has a role to play (whether RTSS or Kaleidan), but it is indeed theoretically possible to optimize a game to the point where it derives no further improvement from framerate-cappers, but it can be very "touchy" (stutter sensitive increase, etc), since framerate capping finetuning is often a system-dependant manoever, whle a VSYNC ON 3-frame-queue is very forgiving of slow-to-fast computers (console-easy zero-configuration smooth gameplay, at the cost of latency).

Pick-poison decisions are common -- sticking to an algorithm optimized for a fast system can create some degraded experiences when running the same algorithm on a really slow low-end computer (e.g. increased stuttering), like an Intel GPU on an older laptop. In some cases, shallow-depth low-lag VSYNC ON can be extremely stuttery on underperformant systems, even if they're delightfully low-lag on fast systems. Then the game has to have all the configurable options of an advanced framerate capper, to try to give low-lag choices for all possible system configurations, complicating user configurability...

One often ends up having to design for the lowest common denominator...
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

diakou
Posts: 83
Joined: 09 Aug 2020, 11:28

Re: What does Chief think about NVIDIA's Do's and Don'ts DirectX guide?

Post by diakou » 13 Oct 2020, 18:46

Thank you, I forgot to respond. Internet culture has made me struggle with knowing what to do when someone posts something and attempting to confirm that I have read it without being able to simply "like" it or give a "reaction" to the post without having to actually give an entire reply/post if there is no new info from my side. Makes me feel like there has to be endless communication to verify to the other part that it was seen/read by replying.

With that being said, this was very useful information, I am constantly improving my knowledge on anything (possibly) latency related even if the end usage is for a different case. It is good to know as much as possible to my understanding limits...or so I think. One day I need to actually sit down and bother to learn a programming language for real instead of meticulously attempt understanding through small-sections of code or API calls or what a written code is capable to do. Knowing how to tie them in/manipulate them more freely would probably benefit me a lot more for the future.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: What does Chief think about NVIDIA's Do's and Don'ts DirectX guide?

Post by Chief Blur Buster » 15 Oct 2020, 15:20

diakou wrote:
13 Oct 2020, 18:46
Thank you, I forgot to respond. Internet culture has made me struggle with knowing what to do when someone posts something and attempting to confirm that I have read it without being able to simply "like" it or give a "reaction" to the post without having to actually give an entire reply/post if there is no new info from my side. Makes me feel like there has to be endless communication to verify to the other part that it was seen/read by replying.
Some helpful tips to readers:

Being an intentionally old-fashioned bulletin board style forum of the pre-social-media era -- the easiest way to monitor your posts is a Search Your Posts feature (See recent diakou of yours in reverse orthographical order -- you can do it for yourself or any user by clicking on the username and then finding the "Search All Posts by").

You can also use the "Subscribe Topic" feature (one of the buttons at the bottom will pop up a menu that shows a Subscribe link).

Alternatively, there's an email-notify feature that can be enabled in your control panel, if you want universal email notifications for all threads you're the creator of.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

Post Reply