2017-08-02 19:22:48 +02:00
|
|
|
/*
|
|
|
|
Simple DirectMedia Layer
|
2020-01-17 05:49:25 +01:00
|
|
|
Copyright (C) 1997-2020 Sam Lantinga <slouken@libsdl.org>
|
2017-08-02 19:22:48 +02:00
|
|
|
|
|
|
|
This software is provided 'as-is', without any express or implied
|
|
|
|
warranty. In no event will the authors be held liable for any damages
|
|
|
|
arising from the use of this software.
|
|
|
|
|
|
|
|
Permission is granted to anyone to use this software for any purpose,
|
|
|
|
including commercial applications, and to alter it and redistribute it
|
|
|
|
freely, subject to the following restrictions:
|
|
|
|
|
|
|
|
1. The origin of this software must not be misrepresented; you must not
|
|
|
|
claim that you wrote the original software. If you use this software
|
|
|
|
in a product, an acknowledgment in the product documentation would be
|
|
|
|
appreciated but is not required.
|
|
|
|
2. Altered source versions must be plainly marked as such, and must not be
|
|
|
|
misrepresented as being the original software.
|
|
|
|
3. This notice may not be removed or altered from any source distribution.
|
|
|
|
*/
|
2017-08-22 02:20:50 +02:00
|
|
|
|
2017-08-02 19:22:48 +02:00
|
|
|
#include "../../SDL_internal.h"
|
|
|
|
|
|
|
|
#if SDL_VIDEO_DRIVER_KMSDRM && SDL_VIDEO_OPENGL_EGL
|
|
|
|
|
|
|
|
#include "SDL_kmsdrmvideo.h"
|
|
|
|
#include "SDL_kmsdrmopengles.h"
|
|
|
|
#include "SDL_kmsdrmdyn.h"
|
|
|
|
|
|
|
|
#ifndef EGL_PLATFORM_GBM_MESA
|
|
|
|
#define EGL_PLATFORM_GBM_MESA 0x31D7
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* EGL implementation of SDL OpenGL support */
|
|
|
|
|
|
|
|
int
|
|
|
|
KMSDRM_GLES_LoadLibrary(_THIS, const char *path) {
|
2020-02-27 17:20:34 +01:00
|
|
|
NativeDisplayType display = (NativeDisplayType)((SDL_VideoData *)_this->driverdata)->gbm;
|
|
|
|
return SDL_EGL_LoadLibrary(_this, path, display, EGL_PLATFORM_GBM_MESA);
|
2017-08-02 19:22:48 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
SDL_EGL_CreateContext_impl(KMSDRM)
|
|
|
|
|
|
|
|
int KMSDRM_GLES_SetSwapInterval(_THIS, int interval) {
|
|
|
|
if (!_this->egl_data) {
|
|
|
|
return SDL_SetError("EGL not initialized");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (interval == 0 || interval == 1) {
|
|
|
|
_this->egl_data->egl_swapinterval = interval;
|
|
|
|
} else {
|
|
|
|
return SDL_SetError("Only swap intervals of 0 or 1 are supported");
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
KMSDRM_GLES_SwapWindow(_THIS, SDL_Window * window) {
|
2020-02-09 20:44:22 +01:00
|
|
|
SDL_WindowData *windata = ((SDL_WindowData *) window->driverdata);
|
|
|
|
SDL_DisplayData *dispdata = (SDL_DisplayData *) SDL_GetDisplayForWindow(window)->driverdata;
|
|
|
|
SDL_VideoData *viddata = ((SDL_VideoData *)_this->driverdata);
|
2017-08-02 19:22:48 +02:00
|
|
|
KMSDRM_FBInfo *fb_info;
|
Fixed bug 5140 - KMSDRM: Dynamic vsync toggle does not work
Manuel Alfayate Corchete
The KMSDRM backend was doing things wrong because of some small (but important) misconceptions on how KMS/DRM works: to implement a largely broken non-vsync refresh mechanism, the SwapWindow() function was issuing new pageflips before previous ones had completed, thus causing EBUSY returns, buffer mismanagement, etc... resulting in general breakage on vsync disabling from apps, that would not allow vsync to work again without KMSDRM video re-initialization.
To further clarify, on most DRM drivers async pageflips are NOT working nowadays, so all issued pageflips will complete on next VBLANK, NOT ASAP (calling drmModePageFlip() with the DRM_MODE_PAGE_FLIP_ASYNC flag will return error).
The old code was assuming that can just issue a synchronous (=on VBLANK) pageflip and then pass a 0 timeout to the pull() function so we do not wait for the pageflip event, thinking that this will lead to correct non-vsynced screen updates from the program: That is plain wrong.
Each pageflip has to be waite before issuing a new one, ALWAYS. And if we do not support ASYNC pageflips on the DRM driver level, then we are forced to wait for the next VBLANK. There is no way around it.
I have also added many comments on the KMSDRM code. This is needed for future reference for me or others who may need to look at this code: KMS/DRM terminology regarding what SYNC and ASYNC mean in pageflip terms, and where to do certain things and why, is not trivial. It is not desirable or possible to invest time on researching the same concepts every time there is need to dive into this code. So please leave all these comments in the patch.
2020-05-27 01:27:00 +02:00
|
|
|
SDL_bool crtc_setup_pending = SDL_FALSE;
|
|
|
|
|
|
|
|
/* ALWAYS wait for each pageflip to complete before issuing another, vsync or not,
|
|
|
|
or drmModePageFlip() will start returning EBUSY if there are pending pageflips.
|
|
|
|
|
|
|
|
To disable vsync in games, it would be needed to issue async pageflips,
|
|
|
|
and then wait for each pageflip to complete. Since async pageflips complete ASAP
|
|
|
|
instead of VBLANK, thats how non-vsync screen updates should wok.
|
|
|
|
|
|
|
|
BUT Async pageflips do not work right now because calling drmModePageFlip() with the
|
|
|
|
DRM_MODE_PAGE_FLIP_ASYNC flag returns error on every driver I have tried.
|
|
|
|
|
|
|
|
So, for now, only do vsynced updates: _this->egl_data->egl_swapinterval is
|
|
|
|
ignored for now, it makes no sense to use it until async pageflips work on drm drivers. */
|
2017-08-02 19:22:48 +02:00
|
|
|
|
2020-02-09 20:44:22 +01:00
|
|
|
/* Recreate the GBM / EGL surfaces if the display mode has changed */
|
|
|
|
if (windata->egl_surface_dirty) {
|
|
|
|
KMSDRM_CreateSurfaces(_this, window);
|
Fixed bug 5140 - KMSDRM: Dynamic vsync toggle does not work
Manuel Alfayate Corchete
The KMSDRM backend was doing things wrong because of some small (but important) misconceptions on how KMS/DRM works: to implement a largely broken non-vsync refresh mechanism, the SwapWindow() function was issuing new pageflips before previous ones had completed, thus causing EBUSY returns, buffer mismanagement, etc... resulting in general breakage on vsync disabling from apps, that would not allow vsync to work again without KMSDRM video re-initialization.
To further clarify, on most DRM drivers async pageflips are NOT working nowadays, so all issued pageflips will complete on next VBLANK, NOT ASAP (calling drmModePageFlip() with the DRM_MODE_PAGE_FLIP_ASYNC flag will return error).
The old code was assuming that can just issue a synchronous (=on VBLANK) pageflip and then pass a 0 timeout to the pull() function so we do not wait for the pageflip event, thinking that this will lead to correct non-vsynced screen updates from the program: That is plain wrong.
Each pageflip has to be waite before issuing a new one, ALWAYS. And if we do not support ASYNC pageflips on the DRM driver level, then we are forced to wait for the next VBLANK. There is no way around it.
I have also added many comments on the KMSDRM code. This is needed for future reference for me or others who may need to look at this code: KMS/DRM terminology regarding what SYNC and ASYNC mean in pageflip terms, and where to do certain things and why, is not trivial. It is not desirable or possible to invest time on researching the same concepts every time there is need to dive into this code. So please leave all these comments in the patch.
2020-05-27 01:27:00 +02:00
|
|
|
/* Do this later, when a fb_id is obtained. */
|
|
|
|
crtc_setup_pending = SDL_TRUE;
|
2020-02-09 20:44:22 +01:00
|
|
|
}
|
|
|
|
|
Fixed bug 5140 - KMSDRM: Dynamic vsync toggle does not work
Manuel Alfayate Corchete
The KMSDRM backend was doing things wrong because of some small (but important) misconceptions on how KMS/DRM works: to implement a largely broken non-vsync refresh mechanism, the SwapWindow() function was issuing new pageflips before previous ones had completed, thus causing EBUSY returns, buffer mismanagement, etc... resulting in general breakage on vsync disabling from apps, that would not allow vsync to work again without KMSDRM video re-initialization.
To further clarify, on most DRM drivers async pageflips are NOT working nowadays, so all issued pageflips will complete on next VBLANK, NOT ASAP (calling drmModePageFlip() with the DRM_MODE_PAGE_FLIP_ASYNC flag will return error).
The old code was assuming that can just issue a synchronous (=on VBLANK) pageflip and then pass a 0 timeout to the pull() function so we do not wait for the pageflip event, thinking that this will lead to correct non-vsynced screen updates from the program: That is plain wrong.
Each pageflip has to be waite before issuing a new one, ALWAYS. And if we do not support ASYNC pageflips on the DRM driver level, then we are forced to wait for the next VBLANK. There is no way around it.
I have also added many comments on the KMSDRM code. This is needed for future reference for me or others who may need to look at this code: KMS/DRM terminology regarding what SYNC and ASYNC mean in pageflip terms, and where to do certain things and why, is not trivial. It is not desirable or possible to invest time on researching the same concepts every time there is need to dive into this code. So please leave all these comments in the patch.
2020-05-27 01:27:00 +02:00
|
|
|
if (windata->double_buffer) {
|
|
|
|
/* Use a double buffering scheme, independently of the number of buffers that the GBM surface has,
|
|
|
|
(number of buffers on the GBM surface depends on the implementation).
|
|
|
|
Double buffering (instead of triple) is achieved by waiting for synchronous pageflip to complete
|
|
|
|
inmediately after the pageflip is issued. That way, in the end of this function only two buffers
|
|
|
|
are needed: a buffer that is available to be picked again by EGL as a backbuffer to draw on it,
|
|
|
|
and the new front buffer that has just been set up.
|
|
|
|
|
|
|
|
Since programmer has no control over the number of buffers of the GBM surface, wait for pageflip
|
|
|
|
is done inmediately after issuing pageflip, and so a double-buffer scheme is achieved. */
|
|
|
|
|
|
|
|
/* Ask EGL to mark the current back buffer to become the next front buffer.
|
|
|
|
That will happen when a pageflip is issued, and the next vsync arrives (sync flip)
|
|
|
|
or ASAP (async flip). */
|
|
|
|
if (!(_this->egl_data->eglSwapBuffers(_this->egl_data->egl_display, windata->egl_surface))) {
|
|
|
|
SDL_LogError(SDL_LOG_CATEGORY_VIDEO, "eglSwapBuffers failed.");
|
|
|
|
return 0;
|
|
|
|
}
|
2017-08-02 19:22:48 +02:00
|
|
|
|
Fixed bug 5140 - KMSDRM: Dynamic vsync toggle does not work
Manuel Alfayate Corchete
The KMSDRM backend was doing things wrong because of some small (but important) misconceptions on how KMS/DRM works: to implement a largely broken non-vsync refresh mechanism, the SwapWindow() function was issuing new pageflips before previous ones had completed, thus causing EBUSY returns, buffer mismanagement, etc... resulting in general breakage on vsync disabling from apps, that would not allow vsync to work again without KMSDRM video re-initialization.
To further clarify, on most DRM drivers async pageflips are NOT working nowadays, so all issued pageflips will complete on next VBLANK, NOT ASAP (calling drmModePageFlip() with the DRM_MODE_PAGE_FLIP_ASYNC flag will return error).
The old code was assuming that can just issue a synchronous (=on VBLANK) pageflip and then pass a 0 timeout to the pull() function so we do not wait for the pageflip event, thinking that this will lead to correct non-vsynced screen updates from the program: That is plain wrong.
Each pageflip has to be waite before issuing a new one, ALWAYS. And if we do not support ASYNC pageflips on the DRM driver level, then we are forced to wait for the next VBLANK. There is no way around it.
I have also added many comments on the KMSDRM code. This is needed for future reference for me or others who may need to look at this code: KMS/DRM terminology regarding what SYNC and ASYNC mean in pageflip terms, and where to do certain things and why, is not trivial. It is not desirable or possible to invest time on researching the same concepts every time there is need to dive into this code. So please leave all these comments in the patch.
2020-05-27 01:27:00 +02:00
|
|
|
/* Get a handler to the buffer that is marked to become the next front buffer, and lock it
|
|
|
|
so it can not be chosen by EGL as a back buffer. */
|
|
|
|
windata->next_bo = KMSDRM_gbm_surface_lock_front_buffer(windata->gs);
|
|
|
|
if (!windata->next_bo) {
|
|
|
|
SDL_LogError(SDL_LOG_CATEGORY_VIDEO, "Could not lock GBM surface front buffer");
|
|
|
|
return 0;
|
|
|
|
/* } else {
|
|
|
|
SDL_LogDebug(SDL_LOG_CATEGORY_VIDEO, "Locked GBM surface %p", (void *)windata->next_bo); */
|
|
|
|
}
|
2017-08-02 19:22:48 +02:00
|
|
|
|
Fixed bug 5140 - KMSDRM: Dynamic vsync toggle does not work
Manuel Alfayate Corchete
The KMSDRM backend was doing things wrong because of some small (but important) misconceptions on how KMS/DRM works: to implement a largely broken non-vsync refresh mechanism, the SwapWindow() function was issuing new pageflips before previous ones had completed, thus causing EBUSY returns, buffer mismanagement, etc... resulting in general breakage on vsync disabling from apps, that would not allow vsync to work again without KMSDRM video re-initialization.
To further clarify, on most DRM drivers async pageflips are NOT working nowadays, so all issued pageflips will complete on next VBLANK, NOT ASAP (calling drmModePageFlip() with the DRM_MODE_PAGE_FLIP_ASYNC flag will return error).
The old code was assuming that can just issue a synchronous (=on VBLANK) pageflip and then pass a 0 timeout to the pull() function so we do not wait for the pageflip event, thinking that this will lead to correct non-vsynced screen updates from the program: That is plain wrong.
Each pageflip has to be waite before issuing a new one, ALWAYS. And if we do not support ASYNC pageflips on the DRM driver level, then we are forced to wait for the next VBLANK. There is no way around it.
I have also added many comments on the KMSDRM code. This is needed for future reference for me or others who may need to look at this code: KMS/DRM terminology regarding what SYNC and ASYNC mean in pageflip terms, and where to do certain things and why, is not trivial. It is not desirable or possible to invest time on researching the same concepts every time there is need to dive into this code. So please leave all these comments in the patch.
2020-05-27 01:27:00 +02:00
|
|
|
/* Issue synchronous pageflip: drmModePageFlip() NEVER blocks, synchronous here means that it
|
|
|
|
will be done on next VBLANK, not ASAP. And return to program loop inmediately. */
|
2020-02-09 20:44:22 +01:00
|
|
|
|
Fixed bug 5140 - KMSDRM: Dynamic vsync toggle does not work
Manuel Alfayate Corchete
The KMSDRM backend was doing things wrong because of some small (but important) misconceptions on how KMS/DRM works: to implement a largely broken non-vsync refresh mechanism, the SwapWindow() function was issuing new pageflips before previous ones had completed, thus causing EBUSY returns, buffer mismanagement, etc... resulting in general breakage on vsync disabling from apps, that would not allow vsync to work again without KMSDRM video re-initialization.
To further clarify, on most DRM drivers async pageflips are NOT working nowadays, so all issued pageflips will complete on next VBLANK, NOT ASAP (calling drmModePageFlip() with the DRM_MODE_PAGE_FLIP_ASYNC flag will return error).
The old code was assuming that can just issue a synchronous (=on VBLANK) pageflip and then pass a 0 timeout to the pull() function so we do not wait for the pageflip event, thinking that this will lead to correct non-vsynced screen updates from the program: That is plain wrong.
Each pageflip has to be waite before issuing a new one, ALWAYS. And if we do not support ASYNC pageflips on the DRM driver level, then we are forced to wait for the next VBLANK. There is no way around it.
I have also added many comments on the KMSDRM code. This is needed for future reference for me or others who may need to look at this code: KMS/DRM terminology regarding what SYNC and ASYNC mean in pageflip terms, and where to do certain things and why, is not trivial. It is not desirable or possible to invest time on researching the same concepts every time there is need to dive into this code. So please leave all these comments in the patch.
2020-05-27 01:27:00 +02:00
|
|
|
fb_info = KMSDRM_FBFromBO(_this, windata->next_bo);
|
|
|
|
if (!fb_info) {
|
|
|
|
return 0;
|
|
|
|
}
|
2017-08-02 19:22:48 +02:00
|
|
|
|
Fixed bug 5140 - KMSDRM: Dynamic vsync toggle does not work
Manuel Alfayate Corchete
The KMSDRM backend was doing things wrong because of some small (but important) misconceptions on how KMS/DRM works: to implement a largely broken non-vsync refresh mechanism, the SwapWindow() function was issuing new pageflips before previous ones had completed, thus causing EBUSY returns, buffer mismanagement, etc... resulting in general breakage on vsync disabling from apps, that would not allow vsync to work again without KMSDRM video re-initialization.
To further clarify, on most DRM drivers async pageflips are NOT working nowadays, so all issued pageflips will complete on next VBLANK, NOT ASAP (calling drmModePageFlip() with the DRM_MODE_PAGE_FLIP_ASYNC flag will return error).
The old code was assuming that can just issue a synchronous (=on VBLANK) pageflip and then pass a 0 timeout to the pull() function so we do not wait for the pageflip event, thinking that this will lead to correct non-vsynced screen updates from the program: That is plain wrong.
Each pageflip has to be waite before issuing a new one, ALWAYS. And if we do not support ASYNC pageflips on the DRM driver level, then we are forced to wait for the next VBLANK. There is no way around it.
I have also added many comments on the KMSDRM code. This is needed for future reference for me or others who may need to look at this code: KMS/DRM terminology regarding what SYNC and ASYNC mean in pageflip terms, and where to do certain things and why, is not trivial. It is not desirable or possible to invest time on researching the same concepts every time there is need to dive into this code. So please leave all these comments in the patch.
2020-05-27 01:27:00 +02:00
|
|
|
/* When needed, this is done once we have the needed fb_id, not before. */
|
|
|
|
if (crtc_setup_pending) {
|
|
|
|
if (KMSDRM_drmModeSetCrtc(viddata->drm_fd, dispdata->crtc_id, fb_info->fb_id, 0,
|
|
|
|
0, &dispdata->conn->connector_id, 1, &dispdata->mode)) {
|
|
|
|
SDL_LogError(SDL_LOG_CATEGORY_VIDEO, "Could not configure CRTC on video mode setting.");
|
|
|
|
}
|
|
|
|
crtc_setup_pending = SDL_FALSE;
|
|
|
|
}
|
2017-08-02 19:22:48 +02:00
|
|
|
|
Fixed bug 5140 - KMSDRM: Dynamic vsync toggle does not work
Manuel Alfayate Corchete
The KMSDRM backend was doing things wrong because of some small (but important) misconceptions on how KMS/DRM works: to implement a largely broken non-vsync refresh mechanism, the SwapWindow() function was issuing new pageflips before previous ones had completed, thus causing EBUSY returns, buffer mismanagement, etc... resulting in general breakage on vsync disabling from apps, that would not allow vsync to work again without KMSDRM video re-initialization.
To further clarify, on most DRM drivers async pageflips are NOT working nowadays, so all issued pageflips will complete on next VBLANK, NOT ASAP (calling drmModePageFlip() with the DRM_MODE_PAGE_FLIP_ASYNC flag will return error).
The old code was assuming that can just issue a synchronous (=on VBLANK) pageflip and then pass a 0 timeout to the pull() function so we do not wait for the pageflip event, thinking that this will lead to correct non-vsynced screen updates from the program: That is plain wrong.
Each pageflip has to be waite before issuing a new one, ALWAYS. And if we do not support ASYNC pageflips on the DRM driver level, then we are forced to wait for the next VBLANK. There is no way around it.
I have also added many comments on the KMSDRM code. This is needed for future reference for me or others who may need to look at this code: KMS/DRM terminology regarding what SYNC and ASYNC mean in pageflip terms, and where to do certain things and why, is not trivial. It is not desirable or possible to invest time on researching the same concepts every time there is need to dive into this code. So please leave all these comments in the patch.
2020-05-27 01:27:00 +02:00
|
|
|
if (!KMSDRM_drmModePageFlip(viddata->drm_fd, dispdata->crtc_id, fb_info->fb_id,
|
|
|
|
DRM_MODE_PAGE_FLIP_EVENT, &windata->waiting_for_flip)) {
|
|
|
|
windata->waiting_for_flip = SDL_TRUE;
|
|
|
|
} else {
|
|
|
|
SDL_LogError(SDL_LOG_CATEGORY_VIDEO, "Could not issue pageflip");
|
|
|
|
}
|
2017-10-21 13:20:57 +02:00
|
|
|
|
Fixed bug 5140 - KMSDRM: Dynamic vsync toggle does not work
Manuel Alfayate Corchete
The KMSDRM backend was doing things wrong because of some small (but important) misconceptions on how KMS/DRM works: to implement a largely broken non-vsync refresh mechanism, the SwapWindow() function was issuing new pageflips before previous ones had completed, thus causing EBUSY returns, buffer mismanagement, etc... resulting in general breakage on vsync disabling from apps, that would not allow vsync to work again without KMSDRM video re-initialization.
To further clarify, on most DRM drivers async pageflips are NOT working nowadays, so all issued pageflips will complete on next VBLANK, NOT ASAP (calling drmModePageFlip() with the DRM_MODE_PAGE_FLIP_ASYNC flag will return error).
The old code was assuming that can just issue a synchronous (=on VBLANK) pageflip and then pass a 0 timeout to the pull() function so we do not wait for the pageflip event, thinking that this will lead to correct non-vsynced screen updates from the program: That is plain wrong.
Each pageflip has to be waite before issuing a new one, ALWAYS. And if we do not support ASYNC pageflips on the DRM driver level, then we are forced to wait for the next VBLANK. There is no way around it.
I have also added many comments on the KMSDRM code. This is needed for future reference for me or others who may need to look at this code: KMS/DRM terminology regarding what SYNC and ASYNC mean in pageflip terms, and where to do certain things and why, is not trivial. It is not desirable or possible to invest time on researching the same concepts every time there is need to dive into this code. So please leave all these comments in the patch.
2020-05-27 01:27:00 +02:00
|
|
|
/* Since issued pageflips are always synchronous (ASYNC dont currently work), these pageflips
|
|
|
|
will happen at next vsync, so in practice waiting for vsync is being done here. */
|
|
|
|
if (!KMSDRM_WaitPageFlip(_this, windata, -1)) {
|
|
|
|
SDL_LogError(SDL_LOG_CATEGORY_VIDEO, "Error waiting for pageflip event");
|
|
|
|
return 0;
|
|
|
|
}
|
2017-10-21 13:20:57 +02:00
|
|
|
|
Fixed bug 5140 - KMSDRM: Dynamic vsync toggle does not work
Manuel Alfayate Corchete
The KMSDRM backend was doing things wrong because of some small (but important) misconceptions on how KMS/DRM works: to implement a largely broken non-vsync refresh mechanism, the SwapWindow() function was issuing new pageflips before previous ones had completed, thus causing EBUSY returns, buffer mismanagement, etc... resulting in general breakage on vsync disabling from apps, that would not allow vsync to work again without KMSDRM video re-initialization.
To further clarify, on most DRM drivers async pageflips are NOT working nowadays, so all issued pageflips will complete on next VBLANK, NOT ASAP (calling drmModePageFlip() with the DRM_MODE_PAGE_FLIP_ASYNC flag will return error).
The old code was assuming that can just issue a synchronous (=on VBLANK) pageflip and then pass a 0 timeout to the pull() function so we do not wait for the pageflip event, thinking that this will lead to correct non-vsynced screen updates from the program: That is plain wrong.
Each pageflip has to be waite before issuing a new one, ALWAYS. And if we do not support ASYNC pageflips on the DRM driver level, then we are forced to wait for the next VBLANK. There is no way around it.
I have also added many comments on the KMSDRM code. This is needed for future reference for me or others who may need to look at this code: KMS/DRM terminology regarding what SYNC and ASYNC mean in pageflip terms, and where to do certain things and why, is not trivial. It is not desirable or possible to invest time on researching the same concepts every time there is need to dive into this code. So please leave all these comments in the patch.
2020-05-27 01:27:00 +02:00
|
|
|
/* Return the previous front buffer to the available buffer pool of the GBM surface,
|
|
|
|
so it can be chosen again by EGL as the back buffer for drawing into it. */
|
|
|
|
if (windata->curr_bo) {
|
|
|
|
KMSDRM_gbm_surface_release_buffer(windata->gs, windata->curr_bo);
|
|
|
|
/* SDL_LogDebug(SDL_LOG_CATEGORY_VIDEO, "Released GBM surface buffer %p", (void *)windata->curr_bo); */
|
|
|
|
windata->curr_bo = NULL;
|
2020-02-09 20:44:22 +01:00
|
|
|
}
|
Fixed bug 5140 - KMSDRM: Dynamic vsync toggle does not work
Manuel Alfayate Corchete
The KMSDRM backend was doing things wrong because of some small (but important) misconceptions on how KMS/DRM works: to implement a largely broken non-vsync refresh mechanism, the SwapWindow() function was issuing new pageflips before previous ones had completed, thus causing EBUSY returns, buffer mismanagement, etc... resulting in general breakage on vsync disabling from apps, that would not allow vsync to work again without KMSDRM video re-initialization.
To further clarify, on most DRM drivers async pageflips are NOT working nowadays, so all issued pageflips will complete on next VBLANK, NOT ASAP (calling drmModePageFlip() with the DRM_MODE_PAGE_FLIP_ASYNC flag will return error).
The old code was assuming that can just issue a synchronous (=on VBLANK) pageflip and then pass a 0 timeout to the pull() function so we do not wait for the pageflip event, thinking that this will lead to correct non-vsynced screen updates from the program: That is plain wrong.
Each pageflip has to be waite before issuing a new one, ALWAYS. And if we do not support ASYNC pageflips on the DRM driver level, then we are forced to wait for the next VBLANK. There is no way around it.
I have also added many comments on the KMSDRM code. This is needed for future reference for me or others who may need to look at this code: KMS/DRM terminology regarding what SYNC and ASYNC mean in pageflip terms, and where to do certain things and why, is not trivial. It is not desirable or possible to invest time on researching the same concepts every time there is need to dive into this code. So please leave all these comments in the patch.
2020-05-27 01:27:00 +02:00
|
|
|
|
|
|
|
/* Take note of the current front buffer, so it can be freed next time this function is called. */
|
|
|
|
windata->curr_bo = windata->next_bo;
|
2020-02-09 20:44:22 +01:00
|
|
|
} else {
|
Fixed bug 5140 - KMSDRM: Dynamic vsync toggle does not work
Manuel Alfayate Corchete
The KMSDRM backend was doing things wrong because of some small (but important) misconceptions on how KMS/DRM works: to implement a largely broken non-vsync refresh mechanism, the SwapWindow() function was issuing new pageflips before previous ones had completed, thus causing EBUSY returns, buffer mismanagement, etc... resulting in general breakage on vsync disabling from apps, that would not allow vsync to work again without KMSDRM video re-initialization.
To further clarify, on most DRM drivers async pageflips are NOT working nowadays, so all issued pageflips will complete on next VBLANK, NOT ASAP (calling drmModePageFlip() with the DRM_MODE_PAGE_FLIP_ASYNC flag will return error).
The old code was assuming that can just issue a synchronous (=on VBLANK) pageflip and then pass a 0 timeout to the pull() function so we do not wait for the pageflip event, thinking that this will lead to correct non-vsynced screen updates from the program: That is plain wrong.
Each pageflip has to be waite before issuing a new one, ALWAYS. And if we do not support ASYNC pageflips on the DRM driver level, then we are forced to wait for the next VBLANK. There is no way around it.
I have also added many comments on the KMSDRM code. This is needed for future reference for me or others who may need to look at this code: KMS/DRM terminology regarding what SYNC and ASYNC mean in pageflip terms, and where to do certain things and why, is not trivial. It is not desirable or possible to invest time on researching the same concepts every time there is need to dive into this code. So please leave all these comments in the patch.
2020-05-27 01:27:00 +02:00
|
|
|
/* Triple buffering requires waiting for last pageflip upon entering instead of waiting at the end,
|
|
|
|
and issuing the next pageflip at the end, thus allowing the program loop to run
|
|
|
|
while the issued pageflip arrives (at next VBLANK, since ONLY synchronous pageflips are possible).
|
|
|
|
In a game context, this means that the player can be doing inputs before seeing the last
|
|
|
|
completed frame, causing "input lag" that is known to plage other APIs and backends.
|
|
|
|
Triple buffering requires the use of three different buffers at the end of this function:
|
|
|
|
1- the front buffer which is on screen,
|
|
|
|
2- the back buffer wich is ready to be flipped (a pageflip has been issued on it, which has yet to complete)
|
|
|
|
3- a third buffer that can be used by EGL to draw while the previously issued pageflip arrives
|
|
|
|
(should not put back the previous front buffer into the free buffers pool of the
|
|
|
|
GBM surface until that happens).
|
|
|
|
If the implementation only has two buffers for the GBM surface, this would behave like a double buffer.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* Wait for previously issued pageflip to complete. */
|
|
|
|
if (!KMSDRM_WaitPageFlip(_this, windata, -1)) {
|
|
|
|
SDL_LogError(SDL_LOG_CATEGORY_VIDEO, "Error waiting for pageflip event");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Free the previous front buffer so EGL can pick it again as back buffer.*/
|
|
|
|
if (windata->curr_bo) {
|
|
|
|
KMSDRM_gbm_surface_release_buffer(windata->gs, windata->curr_bo);
|
|
|
|
/* SDL_LogDebug(SDL_LOG_CATEGORY_VIDEO, "Released GBM surface buffer %p", (void *)windata->curr_bo); */
|
|
|
|
windata->curr_bo = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Ask EGL to mark the current back buffer to become the next front buffer.
|
|
|
|
That will happen when a pageflip is issued, and the next vsync arrives (sync flip)
|
|
|
|
or ASAP (async flip). */
|
|
|
|
if (!(_this->egl_data->eglSwapBuffers(_this->egl_data->egl_display, windata->egl_surface))) {
|
|
|
|
SDL_LogError(SDL_LOG_CATEGORY_VIDEO, "eglSwapBuffers failed.");
|
|
|
|
return 0;
|
2017-08-02 19:22:48 +02:00
|
|
|
}
|
2017-10-27 01:37:20 +02:00
|
|
|
|
Fixed bug 5140 - KMSDRM: Dynamic vsync toggle does not work
Manuel Alfayate Corchete
The KMSDRM backend was doing things wrong because of some small (but important) misconceptions on how KMS/DRM works: to implement a largely broken non-vsync refresh mechanism, the SwapWindow() function was issuing new pageflips before previous ones had completed, thus causing EBUSY returns, buffer mismanagement, etc... resulting in general breakage on vsync disabling from apps, that would not allow vsync to work again without KMSDRM video re-initialization.
To further clarify, on most DRM drivers async pageflips are NOT working nowadays, so all issued pageflips will complete on next VBLANK, NOT ASAP (calling drmModePageFlip() with the DRM_MODE_PAGE_FLIP_ASYNC flag will return error).
The old code was assuming that can just issue a synchronous (=on VBLANK) pageflip and then pass a 0 timeout to the pull() function so we do not wait for the pageflip event, thinking that this will lead to correct non-vsynced screen updates from the program: That is plain wrong.
Each pageflip has to be waite before issuing a new one, ALWAYS. And if we do not support ASYNC pageflips on the DRM driver level, then we are forced to wait for the next VBLANK. There is no way around it.
I have also added many comments on the KMSDRM code. This is needed for future reference for me or others who may need to look at this code: KMS/DRM terminology regarding what SYNC and ASYNC mean in pageflip terms, and where to do certain things and why, is not trivial. It is not desirable or possible to invest time on researching the same concepts every time there is need to dive into this code. So please leave all these comments in the patch.
2020-05-27 01:27:00 +02:00
|
|
|
/* Take note of the current front buffer, so it can be freed next time this function is called. */
|
|
|
|
windata->curr_bo = windata->next_bo;
|
|
|
|
|
|
|
|
/* Get a handler to the buffer that is marked to become the next front buffer, and lock it
|
|
|
|
so it can not be chosen by EGL as a back buffer. */
|
|
|
|
windata->next_bo = KMSDRM_gbm_surface_lock_front_buffer(windata->gs);
|
|
|
|
if (!windata->next_bo) {
|
|
|
|
SDL_LogError(SDL_LOG_CATEGORY_VIDEO, "Could not lock GBM surface front buffer");
|
|
|
|
return 0;
|
|
|
|
/* } else {
|
|
|
|
SDL_LogDebug(SDL_LOG_CATEGORY_VIDEO, "Locked GBM surface %p", (void *)windata->next_bo); */
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Issue synchronous pageflip: drmModePageFlip() NEVER blocks, synchronous here means that it
|
|
|
|
will be done on next VBLANK, not ASAP. And return to program loop inmediately. */
|
|
|
|
fb_info = KMSDRM_FBFromBO(_this, windata->next_bo);
|
|
|
|
if (!fb_info) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* When needed, this is done once we have the needed fb_id, not before. */
|
|
|
|
if (crtc_setup_pending) {
|
|
|
|
if (KMSDRM_drmModeSetCrtc(viddata->drm_fd, dispdata->crtc_id, fb_info->fb_id, 0,
|
|
|
|
0, &dispdata->conn->connector_id, 1, &dispdata->mode)) {
|
|
|
|
SDL_LogError(SDL_LOG_CATEGORY_VIDEO, "Could not configure CRTC on video mode setting.");
|
|
|
|
}
|
|
|
|
crtc_setup_pending = SDL_FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
if (!KMSDRM_drmModePageFlip(viddata->drm_fd, dispdata->crtc_id, fb_info->fb_id,
|
|
|
|
DRM_MODE_PAGE_FLIP_EVENT, &windata->waiting_for_flip)) {
|
|
|
|
windata->waiting_for_flip = SDL_TRUE;
|
|
|
|
} else {
|
|
|
|
SDL_LogError(SDL_LOG_CATEGORY_VIDEO, "Could not issue pageflip");
|
2017-10-27 01:37:20 +02:00
|
|
|
}
|
2017-08-02 19:22:48 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
SDL_EGL_MakeCurrent_impl(KMSDRM)
|
|
|
|
|
|
|
|
#endif /* SDL_VIDEO_DRIVER_KMSDRM && SDL_VIDEO_OPENGL_EGL */
|
|
|
|
|
|
|
|
/* vi: set ts=4 sw=4 expandtab: */
|