3 ms·

Is this a problem on Linux as well? See, those of us developing graphics drivers view vsync as the best thing since sliced bread for its ability to make our com

Is this a problem on Linux as well? See, those of us developing graphics drivers view vsync as the best thing since sliced bread for its ability to make our composited desktops and movie players tear-free. If GLX can't properly do this for people, I'd be interested in hearing what game developers want, since we hear from them so infrequently.

oconnore 15y ago
Graphics drivers on Linux have a long ways to go before they need to worry about things like this. I can't even run a composited desktop on my Radeon HD 6310 without tearing, video corruption, horizontal black and white bars and unrecoverable errors where the entire screen looks like it has been run through a pixelated blur function. This is the same on old and new kernels (anywhere from 2.6.38 to 3.0), and cross distro (Fedora and Ubuntu).
5hoom 15y ago
Forgive me as I'm not a linux or a low-level graphics guy, but I think this is a problem inherit with the technique, not the platform. Vsync is great, it gives excellent image quality (no tearing), but brings an inevitable input lag as there is a delay as the frame syncs up to flip. You're not going to notice this on a gui or video, but it can be felt in twitch-games (1st person shooters especially, you'll find pro-gamer types often turn vsync off for this reason) as your input is essentially always at least a frame behind what is going on on screen. Not sure how it works in opengl, but I recall triple buffering was to be the cure for all issues in d3d land, but as described in the post, it isn't. For the time being it's something which has to be addressed in the game code itself by way of internally timing frames & such, if it's addressed at all :/
blackhole 15y ago
5hoom is correct - the problem is the technique. Simply put, if you don't want any input lag, you have to IMMEDIATELY render to the screen, which by definition will cause tearing. The windows DWM does not have this problem, but judging from a large number of presentation API functions I toyed around with in the DirectX9 Ex, they are probably using a very low level flipping technique available to the operating system to eliminate the input lag. I have not been able to find anything concerning how they manage this and if I could utilize it for a fullscreen game, nor have I investigated whether openGL implements a working triple buffer system (mostly since I can't use it... yet). The real question here isn't whether it affects Linux, its a question of whether Linux provides an alternative technique (presumably via openGL) that can be utilized by a game developer.
- caf 15y ago
  The parent is asking what those alternative techniques would ideally look like, from a game developer's point of view.

oconnore 15y ago

Graphics drivers on Linux have a long ways to go before they need to worry about things like this. I can't even run a composited desktop on my Radeon HD 6310 without tearing, video corruption, horizontal black and white bars and unrecoverable errors where the entire screen looks like it has been run through a pixelated blur function. This is the same on old and new kernels (anywhere from 2.6.38 to 3.0), and cross distro (Fedora and Ubuntu).

5hoom 15y ago

Forgive me as I'm not a linux or a low-level graphics guy, but I think this is a problem inherit with the technique, not the platform. Vsync is great, it gives excellent image quality (no tearing), but brings an inevitable input lag as there is a delay as the frame syncs up to flip. You're not going to notice this on a gui or video, but it can be felt in twitch-games (1st person shooters especially, you'll find pro-gamer types often turn vsync off for this reason) as your input is essentially always at least a frame behind what is going on on screen. Not sure how it works in opengl, but I recall triple buffering was to be the cure for all issues in d3d land, but as described in the post, it isn't. For the time being it's something which has to be addressed in the game code itself by way of internally timing frames & such, if it's addressed at all :/

blackhole 15y ago

5hoom is correct - the problem is the technique. Simply put, if you don't want any input lag, you have to IMMEDIATELY render to the screen, which by definition will cause tearing. The windows DWM does not have this problem, but judging from a large number of presentation API functions I toyed around with in the DirectX9 Ex, they are probably using a very low level flipping technique available to the operating system to eliminate the input lag. I have not been able to find anything concerning how they manage this and if I could utilize it for a fullscreen game, nor have I investigated whether openGL implements a working triple buffer system (mostly since I can't use it... yet). The real question here isn't whether it affects Linux, its a question of whether Linux provides an alternative technique (presumably via openGL) that can be utilized by a game developer.

caf 15y ago
The parent is asking what those alternative techniques would ideally look like, from a game developer's point of view.