[Mesa-dev] [PATCH v7 5/5] radeonsi: Enable adaptive_sync by default for radeon
It's better to let most applications make use of adaptive sync
by default. Problematic applications can be placed on the blacklist
or the user can manually disable the feature.
Signed-off-by: Nicholas Kazlauskas
---
src/gallium/drivers/radeonsi/driinfo_radeonsi.h | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
index 8c5078c13f..cbf3bb01fb 100644
--- a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
+++ b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
@@ -1,4 +1,8 @@
// DriConf options specific to radeonsi
+DRI_CONF_SECTION_QUALITY
+DRI_CONF_ADAPTIVE_SYNC("true")
+DRI_CONF_SECTION_END
+
DRI_CONF_SECTION_PERFORMANCE
DRI_CONF_RADEONSI_ENABLE_SISCHED("false")
DRI_CONF_RADEONSI_ASSUME_NO_Z_FIGHTS("false")
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v7 4/5] loader/dri3: Enable adaptive_sync via _VARIABLE_REFRESH property
The DDX driver can be notified of adaptive sync suitability by
flagging the application's window with the _VARIABLE_REFRESH property.
This property is set on the first swap the application performs
when adaptive_sync is set to true in the drirc.
It's performed here instead of when the loader is initialized for
two reasons:
(1) The window's drawable can be missing during loader init.
This can be observed during the Unigine Superposition benchmark.
(2) Adaptive sync will only be enabled closer to when the application
actually begins rendering.
If adaptive_sync is false then the _VARIABLE_REFRESH property
is deleted on loader init.
The property is only managed on the glx DRI3 backend for now. This
should cover most common applications and games on modern hardware.
Vulkan support can be implemented in a similar manner but would likely
require splitting the function out into a common helper function.
Signed-off-by: Nicholas Kazlauskas
---
src/loader/loader_dri3_helper.c | 48 -
src/loader/loader_dri3_helper.h | 2 ++
2 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index 1981b5f051..e5a6e2a9a1 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -101,6 +101,32 @@ get_xcb_visualtype_for_depth(struct loader_dri3_drawable
*draw, int depth)
return NULL;
}
+/* Sets the adaptive sync window property state. */
+static void
+set_adaptive_sync_property(xcb_connection_t *conn, xcb_drawable_t drawable,
+ uint32_t state)
+{
+ static char const name[] = "_VARIABLE_REFRESH";
+ xcb_intern_atom_cookie_t cookie;
+ xcb_intern_atom_reply_t* reply;
+ xcb_void_cookie_t check;
+
+ cookie = xcb_intern_atom(conn, 0, sizeof(name), name);
+ reply = xcb_intern_atom_reply(conn, cookie, NULL);
+ if (reply == NULL)
+ return;
+
+ if (state)
+ check = xcb_change_property_checked(conn, XCB_PROP_MODE_REPLACE,
+ drawable, reply->atom,
+ XCB_ATOM_CARDINAL, 32, 1, );
+ else
+ check = xcb_delete_property_checked(conn, drawable, reply->atom);
+
+ xcb_discard_reply(conn, check.sequence);
+ free(reply);
+}
+
/* Get red channel mask for given drawable at given depth. */
static unsigned int
dri3_get_red_mask_for_depth(struct loader_dri3_drawable *draw, int depth)
@@ -331,16 +357,30 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
draw->have_back = 0;
draw->have_fake_front = 0;
draw->first_init = true;
+ draw->adaptive_sync = false;
+ draw->adaptive_sync_active = false;
draw->cur_blit_source = -1;
draw->back_format = __DRI_IMAGE_FORMAT_NONE;
mtx_init(>mtx, mtx_plain);
cnd_init(>event_cnd);
- if (draw->ext->config)
+ if (draw->ext->config) {
+ unsigned char adaptive_sync;
+
draw->ext->config->configQueryi(draw->dri_screen,
"vblank_mode", _mode);
+ draw->ext->config->configQueryb(draw->dri_screen,
+ "adaptive_sync",
+ _sync);
+
+ draw->adaptive_sync = adaptive_sync;
+ }
+
+ if (!draw->adaptive_sync)
+ set_adaptive_sync_property(conn, draw->drawable, false);
+
switch (vblank_mode) {
case DRI_CONF_VBLANK_NEVER:
case DRI_CONF_VBLANK_DEF_INTERVAL_0:
@@ -879,6 +919,12 @@ loader_dri3_swap_buffers_msc(struct loader_dri3_drawable
*draw,
back = dri3_find_back_alloc(draw);
mtx_lock(>mtx);
+
+ if (draw->adaptive_sync && !draw->adaptive_sync_active) {
+ set_adaptive_sync_property(draw->conn, draw->drawable, true);
+ draw->adaptive_sync_active = true;
+ }
+
if (draw->is_different_gpu && back) {
/* Update the linear buffer before presenting the pixmap */
(void) loader_dri3_blit_image(draw,
diff --git a/src/loader/loader_dri3_helper.h b/src/loader/loader_dri3_helper.h
index 0d18181312..663ce3c0e2 100644
--- a/src/loader/loader_dri3_helper.h
+++ b/src/loader/loader_dri3_helper.h
@@ -156,6 +156,8 @@ struct loader_dri3_drawable {
xcb_special_event_t *special_event;
bool first_init;
+ bool adaptive_sync;
+ bool adaptive_sync_active;
int swap_interval;
struct loader_dri3_extensions *ext;
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v7 2/5] util: Add adaptive_sync driconf option
This option lets the user decide whether mesa should notify the
window manager / DDX driver that the current application is adaptive
sync capable.
It's off by default.
Signed-off-by: Nicholas Kazlauskas
---
src/util/xmlpool/t_options.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/util/xmlpool/t_options.h b/src/util/xmlpool/t_options.h
index e0a30f5fd1..80ddf0e203 100644
--- a/src/util/xmlpool/t_options.h
+++ b/src/util/xmlpool/t_options.h
@@ -210,6 +210,11 @@ DRI_CONF_OPT_BEGIN_V(vblank_mode,enum,def,"0:3") \
DRI_CONF_DESC_END \
DRI_CONF_OPT_END
+#define DRI_CONF_ADAPTIVE_SYNC(def) \
+DRI_CONF_OPT_BEGIN_B(adaptive_sync,def) \
+DRI_CONF_DESC(en,gettext("Adapt the monitor sync to the application
performance (when possible)")) \
+DRI_CONF_OPT_END
+
#define DRI_CONF_MESA_GLTHREAD(def) \
DRI_CONF_OPT_BEGIN_B(mesa_glthread, def) \
DRI_CONF_DESC(en,gettext("Enable offloading GL driver work to a
separate thread")) \
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v7 3/5] drirc: Initial blacklist for adaptive sync
Applications that don't present at a predictable rate (ie. not games) shouldn't have adapative sync enabled. This list covers some of the common desktop compositors, web browsers and video players. Signed-off-by: Nicholas Kazlauskas --- src/util/00-mesa-defaults.conf | 82 ++ 1 file changed, 82 insertions(+) diff --git a/src/util/00-mesa-defaults.conf b/src/util/00-mesa-defaults.conf index a937c46d05..8e9a87d603 100644 --- a/src/util/00-mesa-defaults.conf +++ b/src/util/00-mesa-defaults.conf @@ -21,6 +21,8 @@ Application bugs worked around in this file: built-ins (specifically gl_VertexID), which causes the vertex shaders to fail to compile. +* Applications that are not suitable for adapative sync are blacklisted here. + TODO: document the other workarounds. --> @@ -314,6 +316,86 @@ TODO: document the other workarounds. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v7 1/5] util: Get program name based on path when possible
Some programs start with the path and command line arguments in
argv[0] (program_invocation_name). Chromium is an example of
an application using mesa that does this.
This tries to query the real path for the symbolic link /proc/self/exe
to find the program name instead. It only uses the realpath if it
was a prefix of the invocation to avoid breaking wine programs.
Cc: Timothy Arceri
Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Eric Engestrom
---
src/util/u_process.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/src/util/u_process.c b/src/util/u_process.c
index 5e5927678d..a1667e7807 100644
--- a/src/util/u_process.c
+++ b/src/util/u_process.c
@@ -41,8 +41,29 @@ static const char *
__getProgramName()
{
char * arg = strrchr(program_invocation_name, '/');
- if (arg)
+ if (arg) {
+ /* If the / character was found this is likely a linux path or
+ * an invocation path for a 64-bit wine program.
+ *
+ * However, some programs pass command line arguments into argv[0].
+ * Strip these arguments out by using the realpath only if it was
+ * a prefix of the invocation name.
+ */
+ static char *path;
+
+ if (!path)
+ path = realpath("/proc/self/exe", NULL);
+
+ if (path && strncmp(path, program_invocation_name, strlen(path)) == 0) {
+ /* This shouldn't be null because path is a a prefix,
+ * but check it anyway since path is static. */
+ char * name = strrchr(path, '/');
+ if (name)
+return name + 1;
+ }
+
return arg+1;
+ }
/* If there was no '/' at all we likely have a windows like path from
* a wine application.
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v7 0/5] Mesa integration for DRM variable refresh rate API
op.org/archives/amd-gfx/2018-April/021047.html https://lists.freedesktop.org/archives/dri-devel/2017-October/155207.html https://lists.freedesktop.org/archives/dri-devel/2018-September/189404.html https://lists.freedesktop.org/archives/dri-devel/2018-September/190910.html https://lists.freedesktop.org/archives/mesa-dev/2018-September/205001.html https://lists.freedesktop.org/archives/mesa-dev/2018-September/205883.html https://lists.freedesktop.org/archives/mesa-dev/2018-October/206486.html https://lists.freedesktop.org/archives/mesa-dev/2018-October/206802.html https://lists.freedesktop.org/archives/mesa-dev/2018-October/206854.html Nicholas Kazlauskas (5): util: Get program name based on path when possible util: Add adaptive_sync driconf option drirc: Initial blacklist for adaptive sync loader/dri3: Enable adaptive_sync via _VARIABLE_REFRESH property radeonsi: Enable adaptive_sync by default for radeon .../drivers/radeonsi/driinfo_radeonsi.h | 4 + src/loader/loader_dri3_helper.c | 48 ++- src/loader/loader_dri3_helper.h | 2 + src/util/00-mesa-defaults.conf| 82 +++ src/util/u_process.c | 23 +- src/util/xmlpool/t_options.h | 5 ++ 6 files changed, 162 insertions(+), 2 deletions(-) -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v6 5/5] radeonsi: Enable adaptive_sync by default for radeon
It's better to let most applications make use of adaptive sync
by default. Problematic applications can be placed on the blacklist
or the user can manually disable the feature.
Signed-off-by: Nicholas Kazlauskas
---
src/gallium/drivers/radeonsi/driinfo_radeonsi.h | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
index 8c5078c13f..cbf3bb01fb 100644
--- a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
+++ b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
@@ -1,4 +1,8 @@
// DriConf options specific to radeonsi
+DRI_CONF_SECTION_QUALITY
+DRI_CONF_ADAPTIVE_SYNC("true")
+DRI_CONF_SECTION_END
+
DRI_CONF_SECTION_PERFORMANCE
DRI_CONF_RADEONSI_ENABLE_SISCHED("false")
DRI_CONF_RADEONSI_ASSUME_NO_Z_FIGHTS("false")
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v6 4/5] loader/dri3: Enable adaptive_sync via _VARIABLE_REFRESH property
The DDX driver can be notified of adaptive sync suitability by
flagging the application's window with the _VARIABLE_REFRESH property.
This property is set on the first swap the application performs
when adaptive_sync is set to true in the drirc.
It's performed here instead of when the loader is initialized for
two reasons:
(1) The window's drawable can be missing during loader init.
This can be observed during the Unigine Superposition benchmark.
(2) Adaptive sync will only be enabled closer to when the application
actually begins rendering.
If adaptive_sync is false then the _VARIABLE_REFRESH property
is deleted on loader init.
The property is only managed on the glx DRI3 backend for now. This
should cover most common applications and games on modern hardware.
Vulkan support can be implemented in a similar manner but would likely
require splitting the function out into a common helper function.
Signed-off-by: Nicholas Kazlauskas
---
src/loader/loader_dri3_helper.c | 47 -
src/loader/loader_dri3_helper.h | 2 ++
2 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index 1981b5f051..7d225e1a9d 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -101,6 +101,32 @@ get_xcb_visualtype_for_depth(struct loader_dri3_drawable
*draw, int depth)
return NULL;
}
+/* Sets the adaptive sync window property state. */
+static void
+set_adaptive_sync_property(xcb_connection_t *conn, xcb_drawable_t drawable,
+ uint32_t state)
+{
+ static char const name[] = "_VARIABLE_REFRESH";
+ xcb_intern_atom_cookie_t cookie;
+ xcb_intern_atom_reply_t* reply;
+ xcb_void_cookie_t check;
+
+ cookie = xcb_intern_atom(conn, 0, sizeof(name), name);
+ reply = xcb_intern_atom_reply(conn, cookie, NULL);
+ if (reply == NULL)
+ return;
+
+ if (state)
+ check = xcb_change_property_checked(conn, XCB_PROP_MODE_REPLACE,
+ drawable, reply->atom,
+ XCB_ATOM_CARDINAL, 32, 1, );
+ else
+ check = xcb_delete_property_checked(conn, drawable, reply->atom);
+
+ xcb_discard_reply(conn, check.sequence);
+ free(reply);
+}
+
/* Get red channel mask for given drawable at given depth. */
static unsigned int
dri3_get_red_mask_for_depth(struct loader_dri3_drawable *draw, int depth)
@@ -318,6 +344,7 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
xcb_get_geometry_reply_t *reply;
xcb_generic_error_t *error;
GLint vblank_mode = DRI_CONF_VBLANK_DEF_INTERVAL_1;
+ unsigned char adaptive_sync;
int swap_interval;
draw->conn = conn;
@@ -331,16 +358,28 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
draw->have_back = 0;
draw->have_fake_front = 0;
draw->first_init = true;
+ draw->adaptive_sync = false;
+ draw->adaptive_sync_active = false;
draw->cur_blit_source = -1;
draw->back_format = __DRI_IMAGE_FORMAT_NONE;
mtx_init(>mtx, mtx_plain);
cnd_init(>event_cnd);
- if (draw->ext->config)
+ if (draw->ext->config) {
draw->ext->config->configQueryi(draw->dri_screen,
"vblank_mode", _mode);
+ draw->ext->config->configQueryb(draw->dri_screen,
+ "adaptive_sync",
+ _sync);
+
+ draw->adaptive_sync = adaptive_sync;
+ }
+
+ if (!adaptive_sync)
+ set_adaptive_sync_property(conn, draw->drawable, false);
+
switch (vblank_mode) {
case DRI_CONF_VBLANK_NEVER:
case DRI_CONF_VBLANK_DEF_INTERVAL_0:
@@ -879,6 +918,12 @@ loader_dri3_swap_buffers_msc(struct loader_dri3_drawable
*draw,
back = dri3_find_back_alloc(draw);
mtx_lock(>mtx);
+
+ if (draw->adaptive_sync && !draw->adaptive_sync_active) {
+ set_adaptive_sync_property(draw->conn, draw->drawable, true);
+ draw->adaptive_sync_active = true;
+ }
+
if (draw->is_different_gpu && back) {
/* Update the linear buffer before presenting the pixmap */
(void) loader_dri3_blit_image(draw,
diff --git a/src/loader/loader_dri3_helper.h b/src/loader/loader_dri3_helper.h
index 0d18181312..663ce3c0e2 100644
--- a/src/loader/loader_dri3_helper.h
+++ b/src/loader/loader_dri3_helper.h
@@ -156,6 +156,8 @@ struct loader_dri3_drawable {
xcb_special_event_t *special_event;
bool first_init;
+ bool adaptive_sync;
+ bool adaptive_sync_active;
int swap_interval;
struct loader_dri3_extensions *ext;
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v6 3/5] drirc: Initial blacklist for adaptive sync
Applications that don't present at a predictable rate (ie. not games) shouldn't have adapative sync enabled. This list covers some of the common desktop compositors, web browsers and video players. Signed-off-by: Nicholas Kazlauskas --- src/util/00-mesa-defaults.conf | 82 ++ 1 file changed, 82 insertions(+) diff --git a/src/util/00-mesa-defaults.conf b/src/util/00-mesa-defaults.conf index a937c46d05..8e9a87d603 100644 --- a/src/util/00-mesa-defaults.conf +++ b/src/util/00-mesa-defaults.conf @@ -21,6 +21,8 @@ Application bugs worked around in this file: built-ins (specifically gl_VertexID), which causes the vertex shaders to fail to compile. +* Applications that are not suitable for adapative sync are blacklisted here. + TODO: document the other workarounds. --> @@ -314,6 +316,86 @@ TODO: document the other workarounds. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v6 1/5] util: Get program name based on path when possible
Some programs start with the path and command line arguments in
argv[0] (program_invocation_name). Chromium is an example of
an application using mesa that does this.
This tries to query the real path for the symbolic link /proc/self/exe
to find the program name instead. It only uses the realpath if it
was a prefix of the invocation to avoid breaking wine programs.
Signed-off-by: Nicholas Kazlauskas
---
src/util/u_process.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/src/util/u_process.c b/src/util/u_process.c
index 5e5927678d..a1667e7807 100644
--- a/src/util/u_process.c
+++ b/src/util/u_process.c
@@ -41,8 +41,29 @@ static const char *
__getProgramName()
{
char * arg = strrchr(program_invocation_name, '/');
- if (arg)
+ if (arg) {
+ /* If the / character was found this is likely a linux path or
+ * an invocation path for a 64-bit wine program.
+ *
+ * However, some programs pass command line arguments into argv[0].
+ * Strip these arguments out by using the realpath only if it was
+ * a prefix of the invocation name.
+ */
+ static char *path;
+
+ if (!path)
+ path = realpath("/proc/self/exe", NULL);
+
+ if (path && strncmp(path, program_invocation_name, strlen(path)) == 0) {
+ /* This shouldn't be null because path is a a prefix,
+ * but check it anyway since path is static. */
+ char * name = strrchr(path, '/');
+ if (name)
+return name + 1;
+ }
+
return arg+1;
+ }
/* If there was no '/' at all we likely have a windows like path from
* a wine application.
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v6 2/5] util: Add adaptive_sync driconf option
This option lets the user decide whether mesa should notify the
window manager / DDX driver that the current application is adaptive
sync capable.
It's off by default.
Signed-off-by: Nicholas Kazlauskas
---
src/util/xmlpool/t_options.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/util/xmlpool/t_options.h b/src/util/xmlpool/t_options.h
index e0a30f5fd1..80ddf0e203 100644
--- a/src/util/xmlpool/t_options.h
+++ b/src/util/xmlpool/t_options.h
@@ -210,6 +210,11 @@ DRI_CONF_OPT_BEGIN_V(vblank_mode,enum,def,"0:3") \
DRI_CONF_DESC_END \
DRI_CONF_OPT_END
+#define DRI_CONF_ADAPTIVE_SYNC(def) \
+DRI_CONF_OPT_BEGIN_B(adaptive_sync,def) \
+DRI_CONF_DESC(en,gettext("Adapt the monitor sync to the application
performance (when possible)")) \
+DRI_CONF_OPT_END
+
#define DRI_CONF_MESA_GLTHREAD(def) \
DRI_CONF_OPT_BEGIN_B(mesa_glthread, def) \
DRI_CONF_DESC(en,gettext("Enable offloading GL driver work to a
separate thread")) \
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v6 0/5] Mesa integration for DRM variable refresh rate API
rg/archives/dri-devel/2017-October/155207.html https://lists.freedesktop.org/archives/dri-devel/2018-September/189404.html https://lists.freedesktop.org/archives/dri-devel/2018-September/190910.html https://lists.freedesktop.org/archives/mesa-dev/2018-September/205001.html https://lists.freedesktop.org/archives/mesa-dev/2018-September/205883.html https://lists.freedesktop.org/archives/mesa-dev/2018-October/206486.html https://lists.freedesktop.org/archives/mesa-dev/2018-October/206802.html https://lists.freedesktop.org/archives/mesa-dev/2018-October/206854.html Nicholas Kazlauskas (5): util: Get program name based on path when possible util: Add adaptive_sync driconf option drirc: Initial blacklist for adaptive sync loader/dri3: Enable adaptive_sync via _VARIABLE_REFRESH property radeonsi: Enable adaptive_sync by default for radeon .../drivers/radeonsi/driinfo_radeonsi.h | 4 + src/loader/loader_dri3_helper.c | 47 ++- src/loader/loader_dri3_helper.h | 2 + src/util/00-mesa-defaults.conf| 82 +++ src/util/u_process.c | 23 +- src/util/xmlpool/t_options.h | 5 ++ 6 files changed, 161 insertions(+), 2 deletions(-) -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 5/5] radeonsi: Enable adaptive_sync by default for radeon
It's better to let most applications make use of adaptive sync
by default. Problematic applications can be placed on the blacklist
or the user can manually disable the feature.
Signed-off-by: Nicholas Kazlauskas
---
src/gallium/drivers/radeonsi/driinfo_radeonsi.h | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
index 8c5078c13f..cbf3bb01fb 100644
--- a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
+++ b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
@@ -1,4 +1,8 @@
// DriConf options specific to radeonsi
+DRI_CONF_SECTION_QUALITY
+DRI_CONF_ADAPTIVE_SYNC("true")
+DRI_CONF_SECTION_END
+
DRI_CONF_SECTION_PERFORMANCE
DRI_CONF_RADEONSI_ENABLE_SISCHED("false")
DRI_CONF_RADEONSI_ASSUME_NO_Z_FIGHTS("false")
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 4/5] loader/dri3: Enable adaptive_sync via _VARIABLE_REFRESH property
The DDX driver can be notified of adaptive sync suitability by
flagging the application's window with the _VARIABLE_REFRESH property.
This property is set on the first swap the application performs
when adaptive_sync is set to true in the drirc.
It's performed here instead of when the loader is initialized for
two reasons:
(1) The window's drawable can be missing during loader init.
This can be observed during the Unigine Superposition benchmark.
(2) Adaptive sync will only be enabled closer to when the application
actually begins rendering.
If adaptive_sync is false then the _VARIABLE_REFRESH property
is deleted on loader init.
The property is only managed on the glx DRI3 backend for now. This
should cover most common applications and games on modern hardware.
Vulkan support can be implemented in a similar manner but would likely
require splitting the function out into a common helper function.
Signed-off-by: Nicholas Kazlauskas
---
src/loader/loader_dri3_helper.c | 47 -
src/loader/loader_dri3_helper.h | 2 ++
2 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index f641a34e6d..dad0ede624 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -101,6 +101,32 @@ get_xcb_visualtype_for_depth(struct loader_dri3_drawable
*draw, int depth)
return NULL;
}
+/* Sets the adaptive sync window property state. */
+static void
+set_adaptive_sync_property(xcb_connection_t *conn, xcb_drawable_t drawable,
+ uint32_t state)
+{
+ static char const name[] = "_VARIABLE_REFRESH";
+ xcb_intern_atom_cookie_t cookie;
+ xcb_intern_atom_reply_t* reply;
+ xcb_void_cookie_t check;
+
+ cookie = xcb_intern_atom(conn, 0, sizeof(name), name);
+ reply = xcb_intern_atom_reply(conn, cookie, NULL);
+ if (reply == NULL)
+ return;
+
+ if (state)
+ check = xcb_change_property_checked(conn, XCB_PROP_MODE_REPLACE,
+ drawable, reply->atom,
+ XCB_ATOM_CARDINAL, 32, 1, );
+ else
+ check = xcb_delete_property_checked(conn, drawable, reply->atom);
+
+ xcb_discard_reply(conn, check.sequence);
+ free(reply);
+}
+
/* Get red channel mask for given drawable at given depth. */
static unsigned int
dri3_get_red_mask_for_depth(struct loader_dri3_drawable *draw, int depth)
@@ -318,6 +344,7 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
xcb_get_geometry_reply_t *reply;
xcb_generic_error_t *error;
GLint vblank_mode = DRI_CONF_VBLANK_DEF_INTERVAL_1;
+ unsigned char adaptive_sync;
int swap_interval;
draw->conn = conn;
@@ -331,16 +358,28 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
draw->have_back = 0;
draw->have_fake_front = 0;
draw->first_init = true;
+ draw->adaptive_sync = false;
+ draw->adaptive_sync_active = false;
draw->cur_blit_source = -1;
draw->back_format = __DRI_IMAGE_FORMAT_NONE;
mtx_init(>mtx, mtx_plain);
cnd_init(>event_cnd);
- if (draw->ext->config)
+ if (draw->ext->config) {
draw->ext->config->configQueryi(draw->dri_screen,
"vblank_mode", _mode);
+ draw->ext->config->configQueryb(draw->dri_screen,
+ "adaptive_sync",
+ _sync);
+
+ draw->adaptive_sync = adaptive_sync;
+
+ if (!adaptive_sync)
+ set_adaptive_sync_property(conn, draw->drawable, false);
+ }
+
switch (vblank_mode) {
case DRI_CONF_VBLANK_NEVER:
case DRI_CONF_VBLANK_DEF_INTERVAL_0:
@@ -879,6 +918,12 @@ loader_dri3_swap_buffers_msc(struct loader_dri3_drawable
*draw,
back = dri3_find_back_alloc(draw);
mtx_lock(>mtx);
+
+ if (draw->adaptive_sync && !draw->adaptive_sync_active) {
+ set_adaptive_sync_property(draw->conn, draw->drawable, true);
+ draw->adaptive_sync_active = true;
+ }
+
if (draw->is_different_gpu && back) {
/* Update the linear buffer before presenting the pixmap */
(void) loader_dri3_blit_image(draw,
diff --git a/src/loader/loader_dri3_helper.h b/src/loader/loader_dri3_helper.h
index 0d18181312..663ce3c0e2 100644
--- a/src/loader/loader_dri3_helper.h
+++ b/src/loader/loader_dri3_helper.h
@@ -156,6 +156,8 @@ struct loader_dri3_drawable {
xcb_special_event_t *special_event;
bool first_init;
+ bool adaptive_sync;
+ bool adaptive_sync_active;
int swap_interval;
struct loader_dri3_extensions *ext;
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 3/5] drirc: Initial blacklist for adaptive sync
Applications that don't present at a predictable rate (ie. not games) shouldn't have adapative sync enabled. This list covers some of the common desktop compositors, web browsers and video players. Signed-off-by: Nicholas Kazlauskas --- src/util/00-mesa-defaults.conf | 82 ++ 1 file changed, 82 insertions(+) diff --git a/src/util/00-mesa-defaults.conf b/src/util/00-mesa-defaults.conf index a937c46d05..8e9a87d603 100644 --- a/src/util/00-mesa-defaults.conf +++ b/src/util/00-mesa-defaults.conf @@ -21,6 +21,8 @@ Application bugs worked around in this file: built-ins (specifically gl_VertexID), which causes the vertex shaders to fail to compile. +* Applications that are not suitable for adapative sync are blacklisted here. + TODO: document the other workarounds. --> @@ -314,6 +316,86 @@ TODO: document the other workarounds. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 0/5] Mesa integration for DRM variable refresh rate API
ts.freedesktop.org/archives/dri-devel/2018-September/189404.html https://lists.freedesktop.org/archives/dri-devel/2018-September/190910.html https://lists.freedesktop.org/archives/mesa-dev/2018-September/205001.html https://lists.freedesktop.org/archives/mesa-dev/2018-September/205883.html https://lists.freedesktop.org/archives/mesa-dev/2018-October/206486.html https://lists.freedesktop.org/archives/mesa-dev/2018-October/206802.html Nicholas Kazlauskas (5): util: Get program name based on path when possible util: Add adaptive_sync driconf option drirc: Initial blacklist for adaptive sync loader/dri3: Enable adaptive_sync via _VARIABLE_REFRESH property radeonsi: Enable adaptive_sync by default for radeon .../drivers/radeonsi/driinfo_radeonsi.h | 4 + src/loader/loader_dri3_helper.c | 47 ++- src/loader/loader_dri3_helper.h | 2 + src/util/00-mesa-defaults.conf| 82 +++ src/util/u_process.c | 23 +- src/util/xmlpool/t_options.h | 5 ++ 6 files changed, 161 insertions(+), 2 deletions(-) -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 1/5] util: Get program name based on path when possible
Some programs start with the path and command line arguments in
argv[0] (program_invocation_name). Chromium is an example of
an application using mesa that does this.
This tries to query the real path for the symbolic link /proc/self/exe
to find the program name instead. It only uses the realpath if it
was a prefix of the invocation to avoid breaking wine programs.
Signed-off-by: Nicholas Kazlauskas
---
src/util/u_process.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/src/util/u_process.c b/src/util/u_process.c
index 5e5927678d..a1667e7807 100644
--- a/src/util/u_process.c
+++ b/src/util/u_process.c
@@ -41,8 +41,29 @@ static const char *
__getProgramName()
{
char * arg = strrchr(program_invocation_name, '/');
- if (arg)
+ if (arg) {
+ /* If the / character was found this is likely a linux path or
+ * an invocation path for a 64-bit wine program.
+ *
+ * However, some programs pass command line arguments into argv[0].
+ * Strip these arguments out by using the realpath only if it was
+ * a prefix of the invocation name.
+ */
+ static char *path;
+
+ if (!path)
+ path = realpath("/proc/self/exe", NULL);
+
+ if (path && strncmp(path, program_invocation_name, strlen(path)) == 0) {
+ /* This shouldn't be null because path is a a prefix,
+ * but check it anyway since path is static. */
+ char * name = strrchr(path, '/');
+ if (name)
+return name + 1;
+ }
+
return arg+1;
+ }
/* If there was no '/' at all we likely have a windows like path from
* a wine application.
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v5 2/5] util: Add adaptive_sync driconf option
This option lets the user decide whether mesa should notify the
window manager / DDX driver that the current application is adaptive
sync capable.
It's off by default.
Signed-off-by: Nicholas Kazlauskas
---
src/util/xmlpool/t_options.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/util/xmlpool/t_options.h b/src/util/xmlpool/t_options.h
index e0a30f5fd1..80ddf0e203 100644
--- a/src/util/xmlpool/t_options.h
+++ b/src/util/xmlpool/t_options.h
@@ -210,6 +210,11 @@ DRI_CONF_OPT_BEGIN_V(vblank_mode,enum,def,"0:3") \
DRI_CONF_DESC_END \
DRI_CONF_OPT_END
+#define DRI_CONF_ADAPTIVE_SYNC(def) \
+DRI_CONF_OPT_BEGIN_B(adaptive_sync,def) \
+DRI_CONF_DESC(en,gettext("Adapt the monitor sync to the application
performance (when possible)")) \
+DRI_CONF_OPT_END
+
#define DRI_CONF_MESA_GLTHREAD(def) \
DRI_CONF_OPT_BEGIN_B(mesa_glthread, def) \
DRI_CONF_DESC(en,gettext("Enable offloading GL driver work to a
separate thread")) \
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v4 5/5] loader/dri3: Enable adaptive sync via _VARIABLE_REFRESH property
The DDX driver can be notified of adaptive sync suitability by
flagging the application's window with the _VARIABLE_REFRESH property.
This property is set on the first swap the application performs
when adaptive_sync_enable is set to true in the drirc.
It's performed here instead of when the loader is initialized for
two reasons:
(1) The window's drawable can be missing during loader init.
This can be observed during the Unigine Superposition benchmark.
(2) Adaptive sync will only be enabled closer to when the application
actually begins rendering.
If adaptive_sync_enable is false then the _VARIABLE_REFRESH property
is deleted on loader init.
The property is only managed on the glx DRI3 backend for now. This
should cover most common applications and games on modern hardware.
Vulkan support can be implemented in a similar manner but would likely
require splitting the function out into a common helper function.
Signed-off-by: Nicholas Kazlauskas
---
src/loader/loader_dri3_helper.c | 58 -
src/loader/loader_dri3_helper.h | 2 ++
2 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index f641a34e6d..d4ff5abe41 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -101,6 +101,39 @@ get_xcb_visualtype_for_depth(struct loader_dri3_drawable
*draw, int depth)
return NULL;
}
+/* Sets the adaptive sync window property state. */
+static void
+set_adaptive_sync_property(xcb_connection_t *conn,
+ xcb_window_t window,
+ uint32_t state)
+{
+ static char const name[] = "_VARIABLE_REFRESH";
+ xcb_intern_atom_cookie_t cookie;
+ xcb_intern_atom_reply_t* reply;
+
+ cookie = xcb_intern_atom(conn, 0, sizeof(name), name);
+ reply = xcb_intern_atom_reply(conn, cookie, NULL);
+ if (reply == NULL)
+ return;
+
+ if (state)
+ xcb_change_property(conn,
+XCB_PROP_MODE_REPLACE,
+window,
+reply->atom,
+XCB_ATOM_CARDINAL,
+32,
+1,
+);
+ else
+ xcb_delete_property(conn,
+ window,
+ reply->atom);
+
+ xcb_flush(conn);
+ free(reply);
+}
+
/* Get red channel mask for given drawable at given depth. */
static unsigned int
dri3_get_red_mask_for_depth(struct loader_dri3_drawable *draw, int depth)
@@ -318,6 +351,7 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
xcb_get_geometry_reply_t *reply;
xcb_generic_error_t *error;
GLint vblank_mode = DRI_CONF_VBLANK_DEF_INTERVAL_1;
+ unsigned char adaptive_sync_enable;
int swap_interval;
draw->conn = conn;
@@ -331,16 +365,30 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
draw->have_back = 0;
draw->have_fake_front = 0;
draw->first_init = true;
+ draw->adaptive_sync_enable = false;
+ draw->adaptive_sync_active = false;
draw->cur_blit_source = -1;
draw->back_format = __DRI_IMAGE_FORMAT_NONE;
mtx_init(>mtx, mtx_plain);
cnd_init(>event_cnd);
- if (draw->ext->config)
+ if (draw->ext->config) {
draw->ext->config->configQueryi(draw->dri_screen,
"vblank_mode", _mode);
+ draw->ext->config->configQueryb(draw->dri_screen,
+ "adaptive_sync_enable",
+ _sync_enable);
+
+ draw->adaptive_sync_enable = adaptive_sync_enable;
+
+ if (!adaptive_sync_enable)
+ set_adaptive_sync_property(conn,
+(xcb_window_t)draw->drawable,
+false);
+ }
+
switch (vblank_mode) {
case DRI_CONF_VBLANK_NEVER:
case DRI_CONF_VBLANK_DEF_INTERVAL_0:
@@ -879,6 +927,14 @@ loader_dri3_swap_buffers_msc(struct loader_dri3_drawable
*draw,
back = dri3_find_back_alloc(draw);
mtx_lock(>mtx);
+
+ if (draw->adaptive_sync_enable && !draw->adaptive_sync_active) {
+ set_adaptive_sync_property(draw->conn,
+ (xcb_window_t)draw->drawable,
+ true);
+ draw->adaptive_sync_active = true;
+ }
+
if (draw->is_different_gpu && back) {
/* Update the linear buffer before presenting the pixmap */
(void) loader_dri3_blit_image(draw,
diff --git a/src/loader/loader_dri3_helper.h b/src/loader/loader_dri3_helper.h
index 0d18181312..86f994cb2a 100644
--- a/src/loader/loader_dri3_helper.h
+++ b/src/loader/loader_dri3_helper.h
@@ -156,6 +156,8 @@ struct loader_dri3_drawable {
xcb_special_event_t *special_event;
bool firs
[Mesa-dev] [PATCH v4 3/5] drirc: Initial blacklist for adaptive sync
Applications that don't present at a predictable rate (ie. not games) shouldn't have adapative sync enabled. This list covers some of the common desktop compositors, web browsers and video players. Signed-off-by: Nicholas Kazlauskas --- src/util/00-mesa-defaults.conf | 82 ++ 1 file changed, 82 insertions(+) diff --git a/src/util/00-mesa-defaults.conf b/src/util/00-mesa-defaults.conf index a937c46d05..104f763247 100644 --- a/src/util/00-mesa-defaults.conf +++ b/src/util/00-mesa-defaults.conf @@ -21,6 +21,8 @@ Application bugs worked around in this file: built-ins (specifically gl_VertexID), which causes the vertex shaders to fail to compile. +* Applications that are not suitable for adapative sync are blacklisted here. + TODO: document the other workarounds. --> @@ -314,6 +316,86 @@ TODO: document the other workarounds. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v4 4/5] radeonsi: Enable adapative sync by default for radeon
It's better to let most applications make use of adaptive sync
by default. Problematic applications can be placed on the blacklist
or the user can manually disable the feature.
Signed-off-by: Nicholas Kazlauskas
---
src/gallium/drivers/radeonsi/driinfo_radeonsi.h | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
index 8c5078c13f..edf5eea874 100644
--- a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
+++ b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
@@ -1,4 +1,8 @@
// DriConf options specific to radeonsi
+DRI_CONF_SECTION_QUALITY
+DRI_CONF_ADAPTIVE_SYNC_ENABLE("true")
+DRI_CONF_SECTION_END
+
DRI_CONF_SECTION_PERFORMANCE
DRI_CONF_RADEONSI_ENABLE_SISCHED("false")
DRI_CONF_RADEONSI_ASSUME_NO_Z_FIGHTS("false")
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v4 1/5] util: Add adaptive_sync_enable driconf option
This option lets the user decide whether mesa should notify the
window manager / DDX driver that the current application is adaptive
sync capable.
It's off by default.
Signed-off-by: Nicholas Kazlauskas
---
src/util/xmlpool/t_options.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/util/xmlpool/t_options.h b/src/util/xmlpool/t_options.h
index e0a30f5fd1..789f6cc56d 100644
--- a/src/util/xmlpool/t_options.h
+++ b/src/util/xmlpool/t_options.h
@@ -210,6 +210,11 @@ DRI_CONF_OPT_BEGIN_V(vblank_mode,enum,def,"0:3") \
DRI_CONF_DESC_END \
DRI_CONF_OPT_END
+#define DRI_CONF_ADAPTIVE_SYNC_ENABLE(def) \
+DRI_CONF_OPT_BEGIN_B(adaptive_sync_enable,def) \
+DRI_CONF_DESC(en,gettext("Adapt the monitor sync to the application
performance (when possible)")) \
+DRI_CONF_OPT_END
+
#define DRI_CONF_MESA_GLTHREAD(def) \
DRI_CONF_OPT_BEGIN_B(mesa_glthread, def) \
DRI_CONF_DESC(en,gettext("Enable offloading GL driver work to a
separate thread")) \
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v4 2/5] util: Get program name based on path when possible
Some programs start with the path and command line arguments in
argv[0] (program_invocation_name). Chromium is an example of
an application using mesa that does this.
This tries to query the real path for the symbolic link /proc/self/exe
to find the program name instead. It only uses the realpath if it
was a prefix of the invocation to avoid breaking wine programs.
Signed-off-by: Nicholas Kazlauskas
---
src/util/u_process.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/src/util/u_process.c b/src/util/u_process.c
index 5e5927678d..cd16521ab3 100644
--- a/src/util/u_process.c
+++ b/src/util/u_process.c
@@ -41,8 +41,24 @@ static const char *
__getProgramName()
{
char * arg = strrchr(program_invocation_name, '/');
- if (arg)
+ if (arg) {
+ /* If the / character was found this is likely a linux path or
+ * an invocation path for a 64-bit wine program.
+ *
+ * However, some programs pass command line arguments into argv[0].
+ * Strip these arguments out by using the realpath only if it was
+ * a prefix of the invocation name.
+ */
+ static char *path;
+
+ if (!path)
+ path = realpath("/proc/self/exe", NULL);
+
+ if (path && strncmp(path, program_invocation_name, strlen(path)) == 0)
+ return path + (arg - program_invocation_name + 1);
+
return arg+1;
+ }
/* If there was no '/' at all we likely have a windows like path from
* a wine application.
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v4 0/5] Mesa integration for DRM variable refresh rate API
These patches are part of a proposed new interface for supporting variable refresh rate via DRM properties. It adds a new option for supporting adaptive sync to drirc along with the implementation of notifying the window manager/DDX of the support via a window property. The option is enabled by default for radeonsi so included is an initial blacklist of applications that shouldn't have this option enabled. In order to catch some of these applications a patch to the program name detection was needed to ignore arguments for some Linux applications. === Changes from v3 === * Blacklist updated to include more desktop environments * Variable refresh property is now deleted when adaptive_sync_enable is false during loader init - this should resolve a potential issue with reusing windows with blacklisted applications. === Changes from v2 === * A patch to add the option to the drirc was missing from the v2 patchset. That patch is now included in v3. * The method to fix program name detection for Chromium based applications for the drirc was modified to not break detection for 32-bit/64-bit WINE applications. === Adaptive sync and variable refresh rate === Adaptive sync is part of the DisplayPort specification and allows for graphics adapters to drive displays with varying frame timings. Variable refresh rate (VRR) is essentially the same, but defined for HDMI. === Use cases for variable refresh rate === Variable frame (flip) timings don't align well with fixed refresh rate displays. This results in stuttering, tearing and/or input lag. By adjusting the display refresh rate dynamically these issues can be reduced or eliminated. However, not all content is suitable for dynamic refresh adaptation. The user may experience "flickering" from differences in panel luminance at different refresh rates. Content that flips at an infrequent rate or demand is more likely to cause large changes in refresh rate that result in flickering. Userland needs a way to let the driver know when the screen content is suitable for variable refresh rates. === DRM API to support variable refresh rates === This patch introduces a new API via atomic properties on the DRM connector and CRTC. The drm_connector has one new optional boolean property: * bool vrr_capable - set by the driver if the hardware is capable of supporting variable refresh rates The drm_crtc has one new default boolean property: * bool vrr_enabled - set by userspace indicating that variable refresh rate should be enabled == Overview for DRM driver developers === Driver developers can attach the "vrr_capable" property by calling drm_connector_attach_vrr_capable_property(). This should be done on connectors that could be capable of supporting variable refresh rates (such as DP or HDMI). The "vrr_capable" can then be updated accordingly by calling drm_connector_set_vrr_capable_property(). The "vrr_enabled" property can be checked from the drm_crtc_state object. === Overview for Userland developers == The "vrr_enabled" property on the CRTC should be set to true when the CRTC is suitable for variable refresh rates. To demonstrate the suitability of the API for variable refresh and dynamic adaptation there are additional patches using this API that implement adaptive variable refresh across kernel and userland projects: * DRM (dri-devel) * amdgpu DRM kernel driver (amd-gfx) * xf86-video-amdgpu (https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu) * mesa (mesa-dev) These patches enable adaptive variable refresh on X for AMD hardware. Support for variable refresh is disabled by default in xf86-video-amdgpu and will require additional user configuration. The patches have been tested as working on upstream userland with the GNOME desktop environment under a single monitor setup. They also work on KDE in a single monitor setup with the compositor disabled. The patches require that suitable applications flip via the Present extension to xf86-video-amdgpu for the entire Screen. Some compositors may interfere with this if they are unable to unredirect the window. Full implementation details for these changes can be reviewed in their respective mailing lists and the xf86-video-amdgpu GitLab. === Previous discussions === These patches are based upon feedback from previous threads on the subject. These are linked below for reference: https://lists.freedesktop.org/archives/amd-gfx/2018-April/021047.html https://lists.freedesktop.org/archives/dri-devel/2017-October/155207.html https://lists.freedesktop.org/archives/dri-devel/2018-September/189404.html https://lists.freedesktop.org/archives/dri-devel/2018-September/190910.html https://lists.freedesktop.org/archives/mesa-dev/2018-September/205001.html https://lists.freedesktop.org/archives/mesa-dev/2018-September/205883.html https://lists.freedesktop.org/archives/mesa-dev/2018-October/206486.html Nicholas Kazlau
[Mesa-dev] [PATCH v3 4/5] radeonsi: Enable adapative sync by default for radeon
It's better to let most applications make use of adaptive sync
by default. Problematic applications can be placed on the blacklist
or the user can manually disable the feature.
Signed-off-by: Nicholas Kazlauskas
---
src/gallium/drivers/radeonsi/driinfo_radeonsi.h | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
index 8c5078c13f..edf5eea874 100644
--- a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
+++ b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
@@ -1,4 +1,8 @@
// DriConf options specific to radeonsi
+DRI_CONF_SECTION_QUALITY
+DRI_CONF_ADAPTIVE_SYNC_ENABLE("true")
+DRI_CONF_SECTION_END
+
DRI_CONF_SECTION_PERFORMANCE
DRI_CONF_RADEONSI_ENABLE_SISCHED("false")
DRI_CONF_RADEONSI_ASSUME_NO_Z_FIGHTS("false")
--
2.19.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 5/5] loader/dri3: Enable adaptive sync via _VARIABLE_REFRESH property
The DDX driver can be notified of adaptive sync suitability by
flagging the application's window with the _VARIABLE_REFRESH property.
This property is set on the first swap the application performs
when adaptive_sync_enable is set to true in the drirc.
It's performed here instead of when the loader is initialized for
two reasons:
(1) The window's drawable can be missing during loader init.
This can be observed during the Unigine Superposition benchmark.
(2) Adaptive sync will only be enabled closer to when the application
actually begins rendering. For some displays this means there is
less time spent watching flickering occur during application load.
For now this property is only set on the glx DRI3 backend. This should
cover most common applications and games on modern hardware.
Vulkan support can be implemented in a similar manner but would likely
require splitting the function out into a common helper function.
Signed-off-by: Nicholas Kazlauskas
---
src/loader/loader_dri3_helper.c | 46 -
src/loader/loader_dri3_helper.h | 2 ++
2 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index f641a34e6d..a485e241ae 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -101,6 +101,34 @@ get_xcb_visualtype_for_depth(struct loader_dri3_drawable
*draw, int depth)
return NULL;
}
+/* Sets the adaptive sync window property state. */
+static void
+set_adaptive_sync_property(xcb_connection_t *conn,
+ xcb_window_t window,
+ uint32_t state)
+{
+ static char const name[] = "_VARIABLE_REFRESH";
+ xcb_intern_atom_cookie_t cookie;
+ xcb_intern_atom_reply_t* reply;
+
+ cookie = xcb_intern_atom(conn, 0, sizeof(name), name);
+ reply = xcb_intern_atom_reply(conn, cookie, NULL);
+ if (reply == NULL)
+ return;
+
+ xcb_change_property(conn,
+ XCB_PROP_MODE_REPLACE,
+ window,
+ reply->atom,
+ XCB_ATOM_CARDINAL,
+ 32,
+ 1,
+ );
+
+ xcb_flush(conn);
+ free(reply);
+}
+
/* Get red channel mask for given drawable at given depth. */
static unsigned int
dri3_get_red_mask_for_depth(struct loader_dri3_drawable *draw, int depth)
@@ -318,6 +346,7 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
xcb_get_geometry_reply_t *reply;
xcb_generic_error_t *error;
GLint vblank_mode = DRI_CONF_VBLANK_DEF_INTERVAL_1;
+ unsigned char adaptive_sync_enable;
int swap_interval;
draw->conn = conn;
@@ -331,16 +360,25 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
draw->have_back = 0;
draw->have_fake_front = 0;
draw->first_init = true;
+ draw->adaptive_sync_enable = false;
+ draw->adaptive_sync_active = false;
draw->cur_blit_source = -1;
draw->back_format = __DRI_IMAGE_FORMAT_NONE;
mtx_init(>mtx, mtx_plain);
cnd_init(>event_cnd);
- if (draw->ext->config)
+ if (draw->ext->config) {
draw->ext->config->configQueryi(draw->dri_screen,
"vblank_mode", _mode);
+ draw->ext->config->configQueryb(draw->dri_screen,
+ "adaptive_sync_enable",
+ _sync_enable);
+
+ draw->adaptive_sync_enable = adaptive_sync_enable;
+ }
+
switch (vblank_mode) {
case DRI_CONF_VBLANK_NEVER:
case DRI_CONF_VBLANK_DEF_INTERVAL_0:
@@ -879,6 +917,12 @@ loader_dri3_swap_buffers_msc(struct loader_dri3_drawable
*draw,
back = dri3_find_back_alloc(draw);
mtx_lock(>mtx);
+
+ if (draw->adaptive_sync_enable && !draw->adaptive_sync_active) {
+ set_adaptive_sync_property(draw->conn, (xcb_window_t)draw->drawable,
true);
+ draw->adaptive_sync_active = true;
+ }
+
if (draw->is_different_gpu && back) {
/* Update the linear buffer before presenting the pixmap */
(void) loader_dri3_blit_image(draw,
diff --git a/src/loader/loader_dri3_helper.h b/src/loader/loader_dri3_helper.h
index 0d18181312..86f994cb2a 100644
--- a/src/loader/loader_dri3_helper.h
+++ b/src/loader/loader_dri3_helper.h
@@ -156,6 +156,8 @@ struct loader_dri3_drawable {
xcb_special_event_t *special_event;
bool first_init;
+ bool adaptive_sync_enable;
+ bool adaptive_sync_active;
int swap_interval;
struct loader_dri3_extensions *ext;
--
2.19.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 2/5] util: Get program name based on path when possible
Some programs start with the path and command line arguments in
argv[0] (program_invocation_name). Chromium is an example of
an application using mesa that does this.
This tries to query the real path for the symbolic link /proc/self/exe
to find the program name instead. It only uses the realpath if it
was a prefix of the invocation to avoid breaking wine programs.
Signed-off-by: Nicholas Kazlauskas
---
src/util/u_process.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/src/util/u_process.c b/src/util/u_process.c
index 5e5927678d..cd16521ab3 100644
--- a/src/util/u_process.c
+++ b/src/util/u_process.c
@@ -41,8 +41,24 @@ static const char *
__getProgramName()
{
char * arg = strrchr(program_invocation_name, '/');
- if (arg)
+ if (arg) {
+ /* If the / character was found this is likely a linux path or
+ * an invocation path for a 64-bit wine program.
+ *
+ * However, some programs pass command line arguments into argv[0].
+ * Strip these arguments out by using the realpath only if it was
+ * a prefix of the invocation name.
+ */
+ static char *path;
+
+ if (!path)
+ path = realpath("/proc/self/exe", NULL);
+
+ if (path && strncmp(path, program_invocation_name, strlen(path)) == 0)
+ return path + (arg - program_invocation_name + 1);
+
return arg+1;
+ }
/* If there was no '/' at all we likely have a windows like path from
* a wine application.
--
2.19.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 3/5] drirc: Initial blacklist for adaptive sync
Applications that don't present at a predictable rate (ie. not games) shouldn't have adapative sync enabled. This list covers some of the common desktop compositors, web browsers and video players. Signed-off-by: Nicholas Kazlauskas --- src/util/00-mesa-defaults.conf | 79 ++ 1 file changed, 79 insertions(+) diff --git a/src/util/00-mesa-defaults.conf b/src/util/00-mesa-defaults.conf index a937c46d05..b5e07d70c8 100644 --- a/src/util/00-mesa-defaults.conf +++ b/src/util/00-mesa-defaults.conf @@ -21,6 +21,8 @@ Application bugs worked around in this file: built-ins (specifically gl_VertexID), which causes the vertex shaders to fail to compile. +* Applications that are not suitable for adapative sync are blacklisted here. + TODO: document the other workarounds. --> @@ -314,6 +316,83 @@ TODO: document the other workarounds. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -- 2.19.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 0/5] Mesa integration for DRM variable refresh rate API
These patches are part of a proposed new interface for supporting variable refresh rate via DRM properties. It adds a new option for supporting adaptive sync to drirc along with the implementation of notifying the window manager/DDX of the support via a window property. The option is enabled by default for radeonsi so included is an initial blacklist of applications that shouldn't have this option enabled. In order to catch some of these applications a patch to the program name detection was needed to ignore arguments for some Linux applications. === Changes from v2 === * A patch to add the option to the drirc was missing from the v2 patchset. That patch is now included in v3. * The method to fix program name detection for Chromium based applications for the drirc was modified to not break detection for 32-bit/64-bit WINE applications. === Adaptive sync and variable refresh rate === Adaptive sync is part of the DisplayPort specification and allows for graphics adapters to drive displays with varying frame timings. Variable refresh rate (VRR) is essentially the same, but defined for HDMI. === Use cases for variable refresh rate === Variable frame (flip) timings don't align well with fixed refresh rate displays. This results in stuttering, tearing and/or input lag. By adjusting the display refresh rate dynamically these issues can be reduced or eliminated. However, not all content is suitable for dynamic refresh adaptation. The user may experience "flickering" from differences in panel luminance at different refresh rates. Content that flips at an infrequent rate or demand is more likely to cause large changes in refresh rate that result in flickering. Userland needs a way to let the driver know when the screen content is suitable for variable refresh rates. === DRM API to support variable refresh rates === This patch introduces a new API via atomic properties on the DRM connector and CRTC. The drm_connector has one new optional boolean property: * bool vrr_capable - set by the driver if the hardware is capable of supporting variable refresh rates The drm_crtc has one new default boolean property: * bool vrr_enabled - set by userspace indicating that variable refresh rate should be enabled == Overview for DRM driver developers === Driver developers can attach the "vrr_capable" property by calling drm_connector_attach_vrr_capable_property(). This should be done on connectors that could be capable of supporting variable refresh rates (such as DP or HDMI). The "vrr_capable" can then be updated accordingly by calling drm_connector_set_vrr_capable_property(). The "vrr_enabled" property can be checked from the drm_crtc_state object. === Overview for Userland developers == The "vrr_enabled" property on the CRTC should be set to true when the CRTC is suitable for variable refresh rates. To demonstrate the suitability of the API for variable refresh and dynamic adaptation there are additional patches using this API that implement adaptive variable refresh across kernel and userland projects: * DRM (dri-devel) * amdgpu DRM kernel driver (amd-gfx) * xf86-video-amdgpu (https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu) * mesa (mesa-dev) These patches enable adaptive variable refresh on X for AMD hardware. Support for variable refresh is disabled by default in xf86-video-amdgpu and will require additional user configuration. The patches have been tested as working on upstream userland with the GNOME desktop environment under a single monitor setup. They also work on KDE in a single monitor setup with the compositor disabled. The patches require that suitable applications flip via the Present extension to xf86-video-amdgpu for the entire Screen. Some compositors may interfere with this if they are unable to unredirect the window. Full implementation details for these changes can be reviewed in their respective mailing lists and the xf86-video-amdgpu GitLab. === Previous discussions === These patches are based upon feedback from previous threads on the subject. These are linked below for reference: https://lists.freedesktop.org/archives/amd-gfx/2018-April/021047.html https://lists.freedesktop.org/archives/dri-devel/2017-October/155207.html https://lists.freedesktop.org/archives/dri-devel/2018-September/189404.html https://lists.freedesktop.org/archives/dri-devel/2018-September/190910.html https://lists.freedesktop.org/archives/mesa-dev/2018-September/205001.html https://lists.freedesktop.org/archives/mesa-dev/2018-September/205883.html Nicholas Kazlauskas (5): util: Add adaptive_sync_enable driconf option util: Get program name based on path when possible drirc: Initial blacklist for adaptive sync radeonsi: Enable adapative sync by default for radeon loader/dri3: Enable adaptive sync via _VARIABLE_REFRESH property .../drivers/radeonsi/driinfo_radeonsi.h | 4 + src/loader/loader
[Mesa-dev] [PATCH v3 1/5] util: Add adaptive_sync_enable driconf option
This option lets the user decide whether mesa should notify the
window manager / DDX driver that the current application is adaptive
sync capable.
It's off by default.
Signed-off-by: Nicholas Kazlauskas
---
src/util/xmlpool/t_options.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/util/xmlpool/t_options.h b/src/util/xmlpool/t_options.h
index e0a30f5fd1..789f6cc56d 100644
--- a/src/util/xmlpool/t_options.h
+++ b/src/util/xmlpool/t_options.h
@@ -210,6 +210,11 @@ DRI_CONF_OPT_BEGIN_V(vblank_mode,enum,def,"0:3") \
DRI_CONF_DESC_END \
DRI_CONF_OPT_END
+#define DRI_CONF_ADAPTIVE_SYNC_ENABLE(def) \
+DRI_CONF_OPT_BEGIN_B(adaptive_sync_enable,def) \
+DRI_CONF_DESC(en,gettext("Adapt the monitor sync to the application
performance (when possible)")) \
+DRI_CONF_OPT_END
+
#define DRI_CONF_MESA_GLTHREAD(def) \
DRI_CONF_OPT_BEGIN_B(mesa_glthread, def) \
DRI_CONF_DESC(en,gettext("Enable offloading GL driver work to a
separate thread")) \
--
2.19.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 4/4] loader/dri3: Enable adaptive sync via _VARIABLE_REFRESH property
The DDX driver can be notified of adaptive sync suitability by
flagging the application's window with the _VARIABLE_REFRESH property.
This property is set on the first swap the application performs
when adaptive_sync_enable is set to true in the drirc.
It's performed here instead of when the loader is initialized for
two reasons:
(1) The window's drawable can be missing during loader init.
This can be observed during the Unigine Superposition benchmark.
(2) Adaptive sync will only be enabled closer to when the application
actually begins rendering. For some displays this means there is
less time spent watching flickering occur during application load.
For now this property is only set on the glx DRI3 backend. This should
cover most common applications and games on modern hardware.
Vulkan support can be implemented in a similar manner but would likely
require splitting the function out into a common helper function.
Signed-off-by: Nicholas Kazlauskas
---
src/loader/loader_dri3_helper.c | 46 -
src/loader/loader_dri3_helper.h | 2 ++
2 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index f641a34e6d..a485e241ae 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -101,6 +101,34 @@ get_xcb_visualtype_for_depth(struct loader_dri3_drawable
*draw, int depth)
return NULL;
}
+/* Sets the adaptive sync window property state. */
+static void
+set_adaptive_sync_property(xcb_connection_t *conn,
+ xcb_window_t window,
+ uint32_t state)
+{
+ static char const name[] = "_VARIABLE_REFRESH";
+ xcb_intern_atom_cookie_t cookie;
+ xcb_intern_atom_reply_t* reply;
+
+ cookie = xcb_intern_atom(conn, 0, sizeof(name), name);
+ reply = xcb_intern_atom_reply(conn, cookie, NULL);
+ if (reply == NULL)
+ return;
+
+ xcb_change_property(conn,
+ XCB_PROP_MODE_REPLACE,
+ window,
+ reply->atom,
+ XCB_ATOM_CARDINAL,
+ 32,
+ 1,
+ );
+
+ xcb_flush(conn);
+ free(reply);
+}
+
/* Get red channel mask for given drawable at given depth. */
static unsigned int
dri3_get_red_mask_for_depth(struct loader_dri3_drawable *draw, int depth)
@@ -318,6 +346,7 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
xcb_get_geometry_reply_t *reply;
xcb_generic_error_t *error;
GLint vblank_mode = DRI_CONF_VBLANK_DEF_INTERVAL_1;
+ unsigned char adaptive_sync_enable;
int swap_interval;
draw->conn = conn;
@@ -331,16 +360,25 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
draw->have_back = 0;
draw->have_fake_front = 0;
draw->first_init = true;
+ draw->adaptive_sync_enable = false;
+ draw->adaptive_sync_active = false;
draw->cur_blit_source = -1;
draw->back_format = __DRI_IMAGE_FORMAT_NONE;
mtx_init(>mtx, mtx_plain);
cnd_init(>event_cnd);
- if (draw->ext->config)
+ if (draw->ext->config) {
draw->ext->config->configQueryi(draw->dri_screen,
"vblank_mode", _mode);
+ draw->ext->config->configQueryb(draw->dri_screen,
+ "adaptive_sync_enable",
+ _sync_enable);
+
+ draw->adaptive_sync_enable = adaptive_sync_enable;
+ }
+
switch (vblank_mode) {
case DRI_CONF_VBLANK_NEVER:
case DRI_CONF_VBLANK_DEF_INTERVAL_0:
@@ -879,6 +917,12 @@ loader_dri3_swap_buffers_msc(struct loader_dri3_drawable
*draw,
back = dri3_find_back_alloc(draw);
mtx_lock(>mtx);
+
+ if (draw->adaptive_sync_enable && !draw->adaptive_sync_active) {
+ set_adaptive_sync_property(draw->conn, (xcb_window_t)draw->drawable,
true);
+ draw->adaptive_sync_active = true;
+ }
+
if (draw->is_different_gpu && back) {
/* Update the linear buffer before presenting the pixmap */
(void) loader_dri3_blit_image(draw,
diff --git a/src/loader/loader_dri3_helper.h b/src/loader/loader_dri3_helper.h
index 0d18181312..86f994cb2a 100644
--- a/src/loader/loader_dri3_helper.h
+++ b/src/loader/loader_dri3_helper.h
@@ -156,6 +156,8 @@ struct loader_dri3_drawable {
xcb_special_event_t *special_event;
bool first_init;
+ bool adaptive_sync_enable;
+ bool adaptive_sync_active;
int swap_interval;
struct loader_dri3_extensions *ext;
--
2.19.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 3/4] radeonsi: Enable adapative sync by default for radeon
It's better to let most applications make use of adaptive sync
by default. Problematic applications can be placed on the blacklist
or the user can manually disable the feature.
Signed-off-by: Nicholas Kazlauskas
---
src/gallium/drivers/radeonsi/driinfo_radeonsi.h | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
index 8c5078c13f..edf5eea874 100644
--- a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
+++ b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
@@ -1,4 +1,8 @@
// DriConf options specific to radeonsi
+DRI_CONF_SECTION_QUALITY
+DRI_CONF_ADAPTIVE_SYNC_ENABLE("true")
+DRI_CONF_SECTION_END
+
DRI_CONF_SECTION_PERFORMANCE
DRI_CONF_RADEONSI_ENABLE_SISCHED("false")
DRI_CONF_RADEONSI_ASSUME_NO_Z_FIGHTS("false")
--
2.19.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 2/4] drirc: Initial blacklist for adaptive sync
Applications that don't present at a predictable rate (ie. not games) shouldn't have adaptive sync enabled. This list covers some of the common desktop compositors, web browsers and video players. Signed-off-by: Nicholas Kazlauskas --- src/util/00-mesa-defaults.conf | 79 ++ 1 file changed, 79 insertions(+) diff --git a/src/util/00-mesa-defaults.conf b/src/util/00-mesa-defaults.conf index ca69dd164f..14dd3077f8 100644 --- a/src/util/00-mesa-defaults.conf +++ b/src/util/00-mesa-defaults.conf @@ -21,6 +21,8 @@ Application bugs worked around in this file: built-ins (specifically gl_VertexID), which causes the vertex shaders to fail to compile. +* Applications that are not suitable for adapative sync are blacklisted here. + TODO: document the other workarounds. --> @@ -310,6 +312,83 @@ TODO: document the other workarounds. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -- 2.19.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 1/4] util: Get program name based on path when possible
Some programs start with the path and command line arguments in
argv[0] (program_invocation_name). Chromium is an example of
an application using mesa that does this.
This tries to query the real path for the symbolic link /proc/self/exe
to find the program name instead.
Signed-off-by: Nicholas Kazlauskas
---
src/util/u_process.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/src/util/u_process.c b/src/util/u_process.c
index 5e5927678d..4cae6f6dee 100644
--- a/src/util/u_process.c
+++ b/src/util/u_process.c
@@ -41,8 +41,22 @@ static const char *
__getProgramName()
{
char * arg = strrchr(program_invocation_name, '/');
- if (arg)
+ if (arg) {
+ /* This is likely part of a Linux file path.
+ * Try to get the program name without any command line arguments. */
+ static char * full_path;
+
+ if (!full_path)
+ full_path = realpath("/proc/self/exe", NULL);
+
+ if (full_path) {
+ char * res = strrchr(full_path, '/');
+ if (res)
+return res+1;
+ }
+
return arg+1;
+ }
/* If there was no '/' at all we likely have a windows like path from
* a wine application.
--
2.19.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 0/4] Mesa integration for DRM variable refresh rate API
These patches are part of a proposed new interface for supporting variable refresh rate via DRM properties. It adds a new option for supporting adaptive sync to drirc along with the implementation of notifying the window manager/DDX of the support via a window property. The option is enabled by default for radeonsi so included is an initial blacklist of applications that shouldn't have this option enabled. In order to catch some of these applications a patch to the program name detection was needed to ignore arguments for some Linux applications. === Changes from v1 === * Method of notifying DDX changed to use window property instead of AMDGPU extension * Program name detection patch fixed for WINE applications * More applications added to the blacklist * Patches reordered to allow for more stable bisection === Adaptive sync and variable refresh rate === Adaptive sync is part of the DisplayPort spec and allows for graphics adapters to drive displays with varying frame timings. Variable refresh rate (VRR) is essentially the same, but defined for HDMI. === Use cases for variable refresh rate === Variable frame (flip) timings don't align well with fixed refresh rate displays. This results in stuttering, tearing and/or input lag. By adjusting the display refresh rate dynamically these issues can be reduced or eliminated. However, not all content is suitable for dynamic refresh adaptation. Content that is flipped infrequently or at random intervals tends to fair poorly. Multiple clients trying to flip under the same screen can similarly interfere with prediction. Userland needs a way to let the driver know when the content on the screen is suitable for variable refresh rate and if the user wishes to have the feature enabled. === DRM API to support variable refresh rates === This patch introduces a new API via atomic properties on the DRM connector and CRTC. The connector has two new optional properties: * bool variable_refresh_capable - set by the driver if the hardware is capable of supporting variable refresh tech * bool variable_refresh_enabled - set by the user to enable variable refresh adjustment over the connector The CRTC has one additional default property: * bool variable_refresh - a content hint to the driver specifying that the CRTC contents are suitable for variable refresh adjustment == Overview for DRM driver developers === Driver developers can attach the optional connector properties via drm_connector_attach_variable_refresh_properties on connectors that support variable refresh (typically DP or HDMI). The variable_refresh_capable property should be managed as the output on the connector changes. The property is read only from userspace. The variable_refresh_enabled property is intended to be a property controlled by userland as a global on/off switch for variable refresh technology. It should be checked before enabling variable refresh rate. === Overview for Userland developers == The variable_refresh property on the CRTC should be set to true when the CRTCs are suitable for variable refresh rate. In practice this is probably an application like a game - a single window that covers the whole CRTC surface and is the only client issuing flips. To demonstrate the suitability of the API for variable refresh and dynamic adaptation there are additional patches using this API that implement adaptive variable refresh across kernel and userland projects: * DRM (dri-devel) * amdgpu DRM kernel driver (amd-gfx) * xf86-video-amdgpu (amd-gfx) * mesa (mesa-dev) These patches enable adaptive variable refresh on X for AMD hardware provided that the user sets the variable_refresh_enabled property to true on supported connectors (ie. using xrandr --set-prop). The patches have been tested as working on upstream userland with the GNOME desktop environment under a single-monitor setup. They also work on KDE in single monitor setup if the compositor is disabled. The patches require that the application window can issue screen flips via the Present extension to xf86-video-amdgpu. Due to Present extension limitations some desktop environments and multi-monitor setups are currently not compatible. Full implementation details for these changes can be reviewed in their respective mailing lists. === Previous discussions === These patches are based upon feedback from patches and feedback from two previous threads on the subject which are linked below for reference: https://lists.freedesktop.org/archives/amd-gfx/2018-April/021047.html https://lists.freedesktop.org/archives/dri-devel/2017-October/155207.html https://lists.freedesktop.org/archives/mesa-dev/2018-September/205001.html Nicholas Kazlauskas Nicholas Kazlauskas (4): util: Get program name based on path when possible drirc: Initial blacklist for adaptive sync radeonsi: Enable adapative sync by default for radeon loader/dri3: Enable adaptive sync via _VARIABLE_REFRESH property .../drivers
[Mesa-dev] [PATCH 4/4] util: Get program name based on path when possible
Some programs start with the path and command line arguments in
argv[0] (program_invocation_name). Chromium is an example of
an application using mesa that does this.
This tries to query the real path for the symbolic link /proc/self/exe
to find the program name instead.
Signed-off-by: Nicholas Kazlauskas
---
src/util/u_process.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/src/util/u_process.c b/src/util/u_process.c
index 5e5927678d..ca4d0770cb 100644
--- a/src/util/u_process.c
+++ b/src/util/u_process.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#undef GET_PROGRAM_NAME
@@ -36,22 +37,32 @@
#if !defined(__GLIBC__) || (__GLIBC__ < 2)
/* These aren't declared in any libc5 header */
extern char *program_invocation_name, *program_invocation_short_name;
+extern char *__progname;
#endif
static const char *
__getProgramName()
{
- char * arg = strrchr(program_invocation_name, '/');
+ static char * actual_path;
+ char * path = NULL;
+ char * arg = NULL;
+
+ if (!actual_path)
+ actual_path = realpath("/proc/self/exe", NULL);
+
+ path = actual_path ? actual_path : program_invocation_name;
+
+ arg = strrchr(path, '/');
if (arg)
return arg+1;
/* If there was no '/' at all we likely have a windows like path from
* a wine application.
*/
- arg = strrchr(program_invocation_name, '\\');
+ arg = strrchr(path, '\\');
if (arg)
return arg+1;
- return program_invocation_name;
+ return path;
}
#define GET_PROGRAM_NAME() __getProgramName()
#elif defined(__CYGWIN__)
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] drirc: Initial blacklist for adaptive sync
Applications that don't present at a predictable rate (ie. not games) shouldn't have adapative sync enabled. This list covers some of the common desktop compositors and some web browsers. Signed-off-by: Nicholas Kazlauskas --- src/util/00-mesa-defaults.conf | 37 ++ 1 file changed, 37 insertions(+) diff --git a/src/util/00-mesa-defaults.conf b/src/util/00-mesa-defaults.conf index a68bc03027..a5fbead7b9 100644 --- a/src/util/00-mesa-defaults.conf +++ b/src/util/00-mesa-defaults.conf @@ -21,6 +21,8 @@ Application bugs worked around in this file: built-ins (specifically gl_VertexID), which causes the vertex shaders to fail to compile. +* Applications that are not suitable for adapative sync are blacklisted here. + TODO: document the other workarounds. --> @@ -306,6 +308,41 @@ TODO: document the other workarounds. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -- 2.18.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] Enable adapative sync by default for radeon
It's better to let most applications make use of adaptive sync
by default. Problematic applications can be placed on the blacklist
or the user can manually disable the feature.
Signed-off-by: Nicholas Kazlauskas
---
src/gallium/drivers/radeonsi/driinfo_radeonsi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
index dbaa7c8f17..868736522e 100644
--- a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
+++ b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
@@ -1,6 +1,6 @@
// DriConf options specific to radeonsi
DRI_CONF_SECTION_QUALITY
- DRI_CONF_ADAPTIVE_SYNC_ENABLE("false")
+ DRI_CONF_ADAPTIVE_SYNC_ENABLE("true")
DRI_CONF_SECTION_END
DRI_CONF_SECTION_PERFORMANCE
--
2.18.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] dri3: Add adaptive_sync_enable driconf option
From: Nicolai Hähnle
When enabled, this will request FreeSync via the hybrid amdgpu DDX's
AMDGPU X11 protocol extension.
Due to limitations in the DDX this will only work for applications
that cover the entire X screen (which is important to keep in mind when
you have a multi-monitor setup).
v2: set adaptive_sync_enable = 0 by default
Reviewed-By: Nicholas Kazlauskas
---
.../drivers/radeonsi/driinfo_radeonsi.h | 4 ++
src/loader/loader_dri3_helper.c | 61 ++-
src/loader/loader_dri3_helper.h | 1 +
src/util/xmlpool/t_options.h | 5 ++
4 files changed, 70 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
index 8c5078c13f..dbaa7c8f17 100644
--- a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
+++ b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
@@ -1,4 +1,8 @@
// DriConf options specific to radeonsi
+DRI_CONF_SECTION_QUALITY
+ DRI_CONF_ADAPTIVE_SYNC_ENABLE("false")
+DRI_CONF_SECTION_END
+
DRI_CONF_SECTION_PERFORMANCE
DRI_CONF_RADEONSI_ENABLE_SISCHED("false")
DRI_CONF_RADEONSI_ASSUME_NO_Z_FIGHTS("false")
diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index b625214858..dd70a73f3d 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -22,12 +22,14 @@
*/
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
@@ -303,6 +305,50 @@ loader_dri3_drawable_fini(struct loader_dri3_drawable
*draw)
mtx_destroy(>mtx);
}
+#define X_AMDGPUFreesyncCapability 0
+
+/* Requests must be mulitple of 4 bytes */
+typedef struct _AMDGPUFreesyncCapabilityReq {
+ uint8_t reqType;
+ uint8_t amdgpuReqType;
+ uint16_t length;
+ uint32_t screen;
+ uint32_t drawable;
+} xAMDGPUFreesyncCapabilityReq;
+
+static xcb_extension_t amdgpu_ext_id = { "AMDGPU", 0 };
+
+static bool
+loader_dri3_amdgpu_freesync_enable(xcb_connection_t *conn,
+ xcb_drawable_t drawable)
+{
+ const xcb_query_extension_reply_t *extension;
+
+ extension = xcb_get_extension_data(conn, _ext_id);
+ if (!(extension && extension->present)) {
+ fprintf(stderr, "AMDGPU extension not present -- cannot enable
FreeSync\n");
+ return false;
+ }
+
+ const xcb_protocol_request_t xcb_req = {
+ .count = 1,
+ .ext = _ext_id,
+ .opcode = X_AMDGPUFreesyncCapability,
+ .isvoid = 1,
+ };
+ xAMDGPUFreesyncCapabilityReq req;
+ struct iovec xcb_parts[3];
+
+ req.screen = 0; /* TODO: do we need to support multiple screens? */
+ req.drawable = drawable;
+
+ xcb_parts[2].iov_base = (char *)
+ xcb_parts[2].iov_len = sizeof(req);
+
+ xcb_send_request(conn, 0, xcb_parts + 2, _req);
+ return true;
+}
+
int
loader_dri3_drawable_init(xcb_connection_t *conn,
xcb_drawable_t drawable,
@@ -334,13 +380,20 @@ loader_dri3_drawable_init(xcb_connection_t *conn,
draw->cur_blit_source = -1;
draw->back_format = __DRI_IMAGE_FORMAT_NONE;
+ draw->adaptive_sync = false;
mtx_init(>mtx, mtx_plain);
cnd_init(>event_cnd);
- if (draw->ext->config)
+ if (draw->ext->config) {
draw->ext->config->configQueryi(draw->dri_screen,
"vblank_mode", _mode);
+ unsigned char adaptive_sync_enable = 0;
+ draw->ext->config->configQueryb(draw->dri_screen,
+ "adaptive_sync_enable",
_sync_enable);
+ draw->adaptive_sync = adaptive_sync_enable;
+ }
+
switch (vblank_mode) {
case DRI_CONF_VBLANK_NEVER:
case DRI_CONF_VBLANK_DEF_INTERVAL_0:
@@ -879,6 +932,12 @@ loader_dri3_swap_buffers_msc(struct loader_dri3_drawable
*draw,
back = dri3_find_back_alloc(draw);
mtx_lock(>mtx);
+
+ if (draw->adaptive_sync) {
+ if (!loader_dri3_amdgpu_freesync_enable(draw->conn, draw->drawable))
+ draw->adaptive_sync = false;
+ }
+
if (draw->is_different_gpu && back) {
/* Update the linear buffer before presenting the pixmap */
(void) loader_dri3_blit_image(draw,
diff --git a/src/loader/loader_dri3_helper.h b/src/loader/loader_dri3_helper.h
index 0d18181312..3309df31cf 100644
--- a/src/loader/loader_dri3_helper.h
+++ b/src/loader/loader_dri3_helper.h
@@ -156,6 +156,7 @@ struct loader_dri3_drawable {
xcb_special_event_t *special_event;
bool first_init;
+ bool adaptive_sync;
int swap_interval;
struct loader_dri3_extensions *ext;
diff --git a/src/util/xmlpool/t_options.h b/src/util/xmlpool/t_options.h
index b6f7eed80b..7da731f601 100644
--- a/src/util/xmlpool/t_options.h
+++ b/src/util/xmlpool/t_options.h
@@ -292,6 +292,11 @@ DRI_CONF_OPT_BEGIN_V(vblank_
[Mesa-dev] [PATCH 0/4] Mesa integration for DRM variable refresh rate API
These patches are part of a proposed new interface for supporting variable refresh rate via DRM properties. https://patchwork.freedesktop.org/series/49486/ This is based on existing work by Nicolai Hähnle to help notify xf86-video-amdgpu of applications that use GL to render. It sends these FreeSync notifications by default for any GL application with a blacklist approach to blocking problematic applications. === Adaptive sync and variable refresh rate === Adaptive sync is part of the DisplayPort spec and allows for graphics adapters to drive displays with varying frame timings. Variable refresh rate (VRR) is essentially the same, but defined for HDMI. === Use cases for variable refresh rate === Variable frame (flip) timings don't align well with fixed refresh rate displays. This results in stuttering, tearing and/or input lag. By adjusting the display refresh rate dynamically these issues can be reduced or eliminated. However, not all content is suitable for dynamic refresh adaptation. Content that is flipped infrequently or at random intervals tends to fair poorly. Multiple clients trying to flip under the same screen can similarly interfere with prediction. Userland needs a way to let the driver know when the content on the screen is suitable for variable refresh rate and if the user wishes to have the feature enabled. === DRM API to support variable refresh rates === This patch introduces a new API via atomic properties on the DRM connector and CRTC. The connector has two new optional properties: * bool variable_refresh_capable - set by the driver if the hardware is capable of supporting variable refresh tech * bool variable_refresh_enabled - set by the user to enable variable refresh adjustment over the connector The CRTC has one additional default property: * bool variable_refresh - a content hint to the driver specifying that the CRTC contents are suitable for variable refresh adjustment == Overview for DRM driver developers === Driver developers can attach the optional connector properties via drm_connector_attach_variable_refresh_properties on connectors that support variable refresh (typically DP or HDMI). The variable_refresh_capable property should be managed as the output on the connector changes. The property is read only from userspace. The variable_refresh_enabled property is intended to be a property controlled by userland as a global on/off switch for variable refresh technology. It should be checked before enabling variable refresh rate. === Overview for Userland developers == The variable_refresh property on the CRTC should be set to true when the CRTCs are suitable for variable refresh rate. In practice this is probably an application like a game - a single window that covers the whole CRTC surface and is the only client issuing flips. To demonstrate the suitability of the API for variable refresh and dynamic adaptation there are additional patches using this API that implement adaptive variable refresh across kernel and userland projects: - DRM (dri-devel) - amdgpu DRM kernel driver (amd-gfx) - xf86-video-amdgpu (amd-gfx) - mesa (mesa-dev) These patches enable adaptive variable refresh on X for AMD hardware provided that the user sets the variable_refresh_enabled property to true on supported connectors (ie. using xrandr --set-prop). They have been tested on upstream userland under GNOME/KDE desktop environments under single and multi-monitor setups for a number of GL applications. Most games and benchmarks should work as expected provided that the compositor correctly unredirects the application's surface. KDE seems to have the best support for this with an explicit option to disable tearing support. Full implementation details for these changes can be reviewed in their respective mailing lists. === Previous discussions === These patches are based upon feedback from patches and feedback from two previous threads on the subject which are linked below for reference: https://lists.freedesktop.org/archives/amd-gfx/2018-April/021047.html https://lists.freedesktop.org/archives/dri-devel/2017-October/155207.html Nicholas Kazlauskas Nicholas Kazlauskas (3): Enable adapative sync by default for radeon drirc: Initial blacklist for adaptive sync util: Get program name based on path when possible Nicolai Hähnle (1): dri3: Add adaptive_sync_enable driconf option .../drivers/radeonsi/driinfo_radeonsi.h | 4 ++ src/loader/loader_dri3_helper.c | 61 ++- src/loader/loader_dri3_helper.h | 1 + src/util/00-mesa-defaults.conf| 37 +++ src/util/u_process.c | 17 +- src/util/xmlpool/t_options.h | 5 ++ 6 files changed, 121 insertions(+), 4 deletions(-) -- 2.18.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman
