Latency and stuttering with 3D acceleration

The other day, I read this interesting article on Anandtech about the GPU stuttering issues that were recently discovered with AMD cards. I wanted to do a quick write-up about that, since it relates to what I am doing.

As I’ve written a while ago, I develop software with 3D acceleration for multiple screens at a time, with multiple GPUs. This poses very similar problems to the ones explained here with FRAPS: I can only synchronize the screens up to the Present()-call, and I am dependent on the underlying driver queues from there.

For me it is very good news that this has now become an important issue in driver development, because it will mean that different vendors will probably diverge less in latency in the future. So synchronization will be easier and more reliable for me in the future.

Note also that I wrote at the time that nVidia had some issues in OpenGL when rendering multiple windows, which AMD did not. This could actually have been a result of nVidia’s latency handling scheme. It appeared like there was some kind of scheduling going on, but it only worked on a process-wide basis, rather than scheduling per-thread, and balancing out the performance equally between all windows. And if that theory is correct, then it would also explain why AMD did not suffer from it: they simply did not try to be clever at all, so they could not get it wrong either.

And well, it has to be said: it can’t really be coincidence that once again it happens to be AMD where these issues were detected. nVidia said that they’d been working on latency issues since Fermi, and Intel probably has been working on them as well, since their drivers did not seem to show big issues either. But for some reason it never even occured to the AMD driver team that this kind of latency issue exists, which is a bit sad.

This entry was posted in Direct3D, Hardware news, OpenGL, Software development and tagged , , , , , , , , , , , . Bookmark the permalink.

2 Responses to Latency and stuttering with 3D acceleration

  1. helloworld says:

    All I can say is I was absolutely spot-on in one of the posts I made in your thread several years ago on the asm board, don’t know if you remember this.
    Some months ago I wanted to share with you some thoughts that occured to me on this matter and what I concluded, but got lazy. Maybe later.
    I’ll just try a little prediction, a maybe novel thing that I envisioned:
    Part of the solution will include something in the like of giving a timestamp to the Present() call in the future.
    There are several scenarios starting from this idea, but either way this solution is superior to the current state of things. Time will tell if I was right. Thing is the frame througput and jitter is important, but what’s displayed is, too.
    I have also written some prototype that is already providing far better information and analysis that an fps counter, and have other ideas for detailed info on the frame-by-frame behavior including artifacts of multitasking oses, all realtime. I could witness monitor behaviour, vsync, etc.
    With a 120Hz screen this only gets more critical.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s