Re: [Mesa-dev] [PATCH RFC] egl/dri2: Add dri3 support to x11 platform
On Sat, 4 Jul 2015 11:18:18 +0800 Boyan Ding boyan.j.d...@gmail.com wrote: [snip] +/* FIXME: Is this right? Seems problematic for WL_bind_wayland_display */ What seems to be the problem ? Afaik xcb_dri3_open_reply_fds should return an FD which is ok (be that a render_node device, or a master one with explicit auth). The problem is that WL_bind_wayland_display don't work under dri3 on x11. I only found it yesterday that to get it work, we'll need to add a mechanism to pass fd instead of name of dri device in wl_drm protocol. Previously, if a wayland client wants to use hardware accelerated EGL, it (with the help of libEGL in mesa) will bind to wl_drm object, and wl_drm will immediately send the name of dri device to the wayland client (actually also libEGL in mesa). After wayland platform code opens the device, it has to send the fd to the X server or drm to get authentication. Things are different with dri3, where a fd is directly sent to the client without the need to authenticate. I propose the following addition in wl_drm protocol: There are two kinds of wl_drm implementation. One is the current form. The other one, called dri3-capable (or whatever name), include wl_drm object built on dri3 directly or indirectly through wayland platform. If a client binds to a dri3-capable wl_drm object, it will send a device event to the client with NULL or empty string (so a client who knows nothing about it can safely fail). If the client knows about dri3-capable wl_drm object, it will send a request named get_fd and wl_drm will respond it with an fd acquired with dri3. If the wl_drm object is not dri3-capable it will raise an error if it receives a get_fd request, so will a dri3-capable wl_drm object if it receives authenticate request. Remember, that all protocol errors in Wayland are always fatal, and cause the whole client to be disconnected. Also, on Wayland EGL simply cannot have its private connection to the server, it *must* be shared with the whole application because otherwise EGL cannot operate on the app's wl_surfaces. If you really wanted to go this route (it seems you already have a better idea than this), just use the normal mechanism to extend the current wl_drm interface, or invent a whole new interface. Object flavours does not seem like a workable solution the way you describe, if I understood what you had in mind. Note, that the compositor and the app may be using different versions of Mesa, which means they may be using different definitions of wl_drm. Therefore, wl_drm must follow the same stable protocol rules as everything else. Thanks, pq So the following dri3_authenticate function is not needed. Let's not expose WL_bind_wayland_display for now, and its enablement should be separate patches. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH RFC] egl/dri2: Add dri3 support to x11 platform
On 4 July 2015 at 04:18, Boyan Ding boyan.j.d...@gmail.com wrote:
Hi Emil,
On 07/03/2015 10:36 PM, Emil Velikov wrote:
Hi Boyan,
Thank you for doing this ! A few suggestions which you might be interesting:
Considering that the backend has handled more than dri2 perhaps we can
do a s/dri2/dri/ :-) That obviously is independent of your work.
On 01/07/15 16:31, Boyan Ding wrote:
Signed-off-by: Boyan Ding boyan.j.d...@gmail.com
---
configure.ac |3 +
src/egl/drivers/dri2/Makefile.am |5 +
src/egl/drivers/dri2/egl_dri2.c | 65 +-
src/egl/drivers/dri2/egl_dri2.h | 12 +-
src/egl/drivers/dri2/platform_x11.c | 127 ++-
src/egl/drivers/dri2/platform_x11_dri3.c | 1591
++
src/egl/drivers/dri2/platform_x11_dri3.h | 140 +++
7 files changed, 1926 insertions(+), 17 deletions(-)
create mode 100644 src/egl/drivers/dri2/platform_x11_dri3.c
create mode 100644 src/egl/drivers/dri2/platform_x11_dri3.h
diff --git a/configure.ac b/configure.ac
index af61aa2..090e6c9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1545,6 +1545,9 @@ if test x$enable_egl = xyes; then
if test x$enable_shared_glapi = xno; then
AC_MSG_ERROR([egl_dri2 requires --enable-shared-glapi])
fi
+if test x$enable_dri3 = xyes; then
+EGL_LIB_DEPS=$EGL_LIB_DEPS -lxcb-dri3 -lxcb-present
-lXxf86vm -lxshmfence -lxcb-sync
Neither one of these should be a direct -lfoo expression. We should
check/use PKG_CHECK_MODULES and foo_{CFLAGS,LIBS}.
I'll correct that.
+fi
else
# Avoid building an empty libEGL. Drop/update this
# when other backends (haiku?) come along.
diff --git a/src/egl/drivers/dri2/Makefile.am
b/src/egl/drivers/dri2/Makefile.am
index 55be4a7..d5b511c 100644
--- a/src/egl/drivers/dri2/Makefile.am
+++ b/src/egl/drivers/dri2/Makefile.am
@@ -52,6 +52,11 @@ if HAVE_EGL_PLATFORM_X11
libegl_dri2_la_SOURCES += platform_x11.c
AM_CFLAGS += -DHAVE_X11_PLATFORM
AM_CFLAGS += $(XCB_DRI2_CFLAGS)
+if HAVE_DRI3
+libegl_dri2_la_SOURCES += \
+platform_x11_dri3.c \
+platform_x11_dri3.h
+endif
endif
if HAVE_EGL_PLATFORM_WAYLAND
diff --git a/src/egl/drivers/dri2/egl_dri2.c
b/src/egl/drivers/dri2/egl_dri2.c
index b1b65f7..052c579 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -322,6 +322,12 @@ struct dri2_extension_match {
int offset;
};
+static struct dri2_extension_match dri3_driver_extensions[] = {
+ { __DRI_CORE, 1, offsetof(struct dri2_egl_display, core) },
+ { __DRI_IMAGE_DRIVER, 1, offsetof(struct dri2_egl_display,
image_driver) },
+ { NULL, 0, 0 }
+};
+
static struct dri2_extension_match dri2_driver_extensions[] = {
{ __DRI_CORE, 1, offsetof(struct dri2_egl_display, core) },
{ __DRI_DRI2, 2, offsetof(struct dri2_egl_display, dri2) },
@@ -464,6 +470,24 @@ dri2_open_driver(_EGLDisplay *disp)
}
EGLBoolean
+dri2_load_driver_dri3(_EGLDisplay *disp)
dri3_load_driver perhaps ?
I prefixed all my functions in public files with dri2 instead of
dri3 because the EGL driver is currently called DRI2 (although it
seems funny to see dri3 in a driver called dri2).
The current name of the driver is DRI2 because it uses dri2 to talk
with the X server and uses similar technologies with direct rendering
on other platforms. With my patch, the first reason becomes invalid.
But should the name of the driver or namespace of all functions (or
just the functions involved with dri3) change? I'm open to others'
suggestions. The same applies to comments on function names below.
Iirc for swrast based wayland (platform_wayland.c) we already remove
the it uses dri2 assumption. Then again all this is a simple name
change which, as mentioned before, is not strictly related to your
work.
[snip]
diff --git a/src/egl/drivers/dri2/egl_dri2.h
b/src/egl/drivers/dri2/egl_dri2.h
index f0cc6da..d258753 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -153,11 +153,16 @@ struct dri2_egl_display
int dri2_major;
int dri2_minor;
+ int dri3_major;
+ int dri3_minor;
+ int present_major;
+ int present_minor;
Many of these are unused. Same goes for the glx code which was the
inspiration for this work :-)
I think it's safe to remove them then.
__DRIscreen *dri_screen;
int own_dri_screen;
const __DRIconfig **driver_configs;
void *driver;
const __DRIcoreExtension *core;
+ const __DRIimageDriverExtension *image_driver;
const __DRIdri2Extension *dri2;
const __DRIswrastExtension *swrast;
const
Re: [Mesa-dev] [PATCH RFC] egl/dri2: Add dri3 support to x11 platform
On 04/07/2015 05:18, Boyan Ding wrote : Hi Emil, On 07/03/2015 10:36 PM, Emil Velikov wrote: [snip] +/* FIXME: Is this right? Seems problematic for WL_bind_wayland_display */ What seems to be the problem ? Afaik xcb_dri3_open_reply_fds should return an FD which is ok (be that a render_node device, or a master one with explicit auth). The problem is that WL_bind_wayland_display don't work under dri3 on x11. I only found it yesterday that to get it work, we'll need to add a mechanism to pass fd instead of name of dri device in wl_drm protocol. Previously, if a wayland client wants to use hardware accelerated EGL, it (with the help of libEGL in mesa) will bind to wl_drm object, and wl_drm will immediately send the name of dri device to the wayland client (actually also libEGL in mesa). After wayland platform code opens the device, it has to send the fd to the X server or drm to get authentication. Things are different with dri3, where a fd is directly sent to the client without the need to authenticate. I propose the following addition in wl_drm protocol: There are two kinds of wl_drm implementation. One is the current form. The other one, called dri3-capable (or whatever name), include wl_drm object built on dri3 directly or indirectly through wayland platform. If a client binds to a dri3-capable wl_drm object, it will send a device event to the client with NULL or empty string (so a client who knows nothing about it can safely fail). If the client knows about dri3-capable wl_drm object, it will send a request named get_fd and wl_drm will respond it with an fd acquired with dri3. If the wl_drm object is not dri3-capable it will raise an error if it receives a get_fd request, so will a dri3-capable wl_drm object if it receives authenticate request. So the following dri3_authenticate function is not needed. Let's not expose WL_bind_wayland_display for now, and its enablement should be separate patches. Hi, Both XWayland DRI3 and EGL Wayland are able to handle render-nodes, and render-nodes have been available for quite some time now. In fact there has been several times discussions on wayland irc channel to only advertise render-nodes via wl_drm. Instead of adding a function to wl_drm to get an fd directly, I advocate just advertising the render node name (if your device is not a render node, it is possible to get the render node name), and then you don't have to authenticate. In case render-nodes are not available, then it's ok not to advertise the extension. Yours, Axel Davy ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH RFC] egl/dri2: Add dri3 support to x11 platform
On 07/04/2015 04:17 PM, Axel Davy wrote: On 04/07/2015 05:18, Boyan Ding wrote : Hi Emil, On 07/03/2015 10:36 PM, Emil Velikov wrote: [snip] +/* FIXME: Is this right? Seems problematic for WL_bind_wayland_display */ What seems to be the problem ? Afaik xcb_dri3_open_reply_fds should return an FD which is ok (be that a render_node device, or a master one with explicit auth). The problem is that WL_bind_wayland_display don't work under dri3 on x11. I only found it yesterday that to get it work, we'll need to add a mechanism to pass fd instead of name of dri device in wl_drm protocol. Previously, if a wayland client wants to use hardware accelerated EGL, it (with the help of libEGL in mesa) will bind to wl_drm object, and wl_drm will immediately send the name of dri device to the wayland client (actually also libEGL in mesa). After wayland platform code opens the device, it has to send the fd to the X server or drm to get authentication. Things are different with dri3, where a fd is directly sent to the client without the need to authenticate. I propose the following addition in wl_drm protocol: There are two kinds of wl_drm implementation. One is the current form. The other one, called dri3-capable (or whatever name), include wl_drm object built on dri3 directly or indirectly through wayland platform. If a client binds to a dri3-capable wl_drm object, it will send a device event to the client with NULL or empty string (so a client who knows nothing about it can safely fail). If the client knows about dri3-capable wl_drm object, it will send a request named get_fd and wl_drm will respond it with an fd acquired with dri3. If the wl_drm object is not dri3-capable it will raise an error if it receives a get_fd request, so will a dri3-capable wl_drm object if it receives authenticate request. So the following dri3_authenticate function is not needed. Let's not expose WL_bind_wayland_display for now, and its enablement should be separate patches. Hi, Both XWayland DRI3 and EGL Wayland are able to handle render-nodes, and render-nodes have been available for quite some time now. In fact there has been several times discussions on wayland irc channel to only advertise render-nodes via wl_drm. Instead of adding a function to wl_drm to get an fd directly, I advocate just advertising the render node name (if your device is not a render node, it is possible to get the render node name), and then you don't have to authenticate. In case render-nodes are not available, then it's ok not to advertise the extension. Yours, Axel Davy Hi, You are right. Sending name of the render node is much easier and doesn't need to touch the protocol. drmGetRenderDeviceNameFromFd from libdrm can do this. I gave it a try locally and it works. I think advertising render node device when available is reasonable. Thanks, Boyan Ding ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH RFC] egl/dri2: Add dri3 support to x11 platform
Hi Boyan,
Thank you for doing this ! A few suggestions which you might be interesting:
Considering that the backend has handled more than dri2 perhaps we can
do a s/dri2/dri/ :-) That obviously is independent of your work.
On 01/07/15 16:31, Boyan Ding wrote:
Signed-off-by: Boyan Ding boyan.j.d...@gmail.com
---
configure.ac |3 +
src/egl/drivers/dri2/Makefile.am |5 +
src/egl/drivers/dri2/egl_dri2.c | 65 +-
src/egl/drivers/dri2/egl_dri2.h | 12 +-
src/egl/drivers/dri2/platform_x11.c | 127 ++-
src/egl/drivers/dri2/platform_x11_dri3.c | 1591
++
src/egl/drivers/dri2/platform_x11_dri3.h | 140 +++
7 files changed, 1926 insertions(+), 17 deletions(-)
create mode 100644 src/egl/drivers/dri2/platform_x11_dri3.c
create mode 100644 src/egl/drivers/dri2/platform_x11_dri3.h
diff --git a/configure.ac b/configure.ac
index af61aa2..090e6c9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1545,6 +1545,9 @@ if test x$enable_egl = xyes; then
if test x$enable_shared_glapi = xno; then
AC_MSG_ERROR([egl_dri2 requires --enable-shared-glapi])
fi
+if test x$enable_dri3 = xyes; then
+EGL_LIB_DEPS=$EGL_LIB_DEPS -lxcb-dri3 -lxcb-present
-lXxf86vm -lxshmfence -lxcb-sync
Neither one of these should be a direct -lfoo expression. We should
check/use PKG_CHECK_MODULES and foo_{CFLAGS,LIBS}.
+fi
else
# Avoid building an empty libEGL. Drop/update this
# when other backends (haiku?) come along.
diff --git a/src/egl/drivers/dri2/Makefile.am
b/src/egl/drivers/dri2/Makefile.am
index 55be4a7..d5b511c 100644
--- a/src/egl/drivers/dri2/Makefile.am
+++ b/src/egl/drivers/dri2/Makefile.am
@@ -52,6 +52,11 @@ if HAVE_EGL_PLATFORM_X11
libegl_dri2_la_SOURCES += platform_x11.c
AM_CFLAGS += -DHAVE_X11_PLATFORM
AM_CFLAGS += $(XCB_DRI2_CFLAGS)
+if HAVE_DRI3
+libegl_dri2_la_SOURCES += \
+ platform_x11_dri3.c \
+ platform_x11_dri3.h
+endif
endif
if HAVE_EGL_PLATFORM_WAYLAND
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index b1b65f7..052c579 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -322,6 +322,12 @@ struct dri2_extension_match {
int offset;
};
+static struct dri2_extension_match dri3_driver_extensions[] = {
+ { __DRI_CORE, 1, offsetof(struct dri2_egl_display, core) },
+ { __DRI_IMAGE_DRIVER, 1, offsetof(struct dri2_egl_display, image_driver)
},
+ { NULL, 0, 0 }
+};
+
static struct dri2_extension_match dri2_driver_extensions[] = {
{ __DRI_CORE, 1, offsetof(struct dri2_egl_display, core) },
{ __DRI_DRI2, 2, offsetof(struct dri2_egl_display, dri2) },
@@ -464,6 +470,24 @@ dri2_open_driver(_EGLDisplay *disp)
}
EGLBoolean
+dri2_load_driver_dri3(_EGLDisplay *disp)
dri3_load_driver perhaps ?
+{
+ struct dri2_egl_display *dri2_dpy = disp-DriverData;
+ const __DRIextension **extensions;
+
+ extensions = dri2_open_driver(disp);
+ if (!extensions)
+ return EGL_FALSE;
+
+ if (!dri2_bind_extensions(dri2_dpy, dri3_driver_extensions, extensions)) {
+ dlclose(dri2_dpy-driver);
+ }
+ dri2_dpy-driver_extensions = extensions;
+
+ return EGL_TRUE;
+}
+
+EGLBoolean
dri2_load_driver(_EGLDisplay *disp)
{
struct dri2_egl_display *dri2_dpy = disp-DriverData;
@@ -507,7 +531,9 @@ dri2_setup_screen(_EGLDisplay *disp)
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
unsigned int api_mask;
- if (dri2_dpy-dri2) {
+ if (dri2_dpy-image_driver) {
+ api_mask = dri2_dpy-image_driver-getAPIMask(dri2_dpy-dri_screen);
+ } else if (dri2_dpy-dri2) {
api_mask = dri2_dpy-dri2-getAPIMask(dri2_dpy-dri_screen);
} else {
assert(dri2_dpy-swrast);
@@ -527,11 +553,12 @@ dri2_setup_screen(_EGLDisplay *disp)
if (api_mask (1 __DRI_API_GLES3))
disp-ClientAPIs |= EGL_OPENGL_ES3_BIT_KHR;
- assert(dri2_dpy-dri2 || dri2_dpy-swrast);
+ assert(dri2_dpy-image_driver || dri2_dpy-dri2 || dri2_dpy-swrast);
disp-Extensions.KHR_surfaceless_context = EGL_TRUE;
disp-Extensions.MESA_configless_context = EGL_TRUE;
- if ((dri2_dpy-dri2 dri2_dpy-dri2-base.version = 3) ||
+ if (dri2_dpy-image_driver ||
+ (dri2_dpy-dri2 dri2_dpy-dri2-base.version = 3) ||
(dri2_dpy-swrast dri2_dpy-swrast-base.version = 3)) {
disp-Extensions.KHR_create_context = EGL_TRUE;
@@ -591,7 +618,14 @@ dri2_create_screen(_EGLDisplay *disp)
dri2_dpy = disp-DriverData;
- if (dri2_dpy-dri2) {
+ if (dri2_dpy-image_driver) {
+ dri2_dpy-dri_screen =
+ dri2_dpy-image_driver-createNewScreen2(0, dri2_dpy-fd,
+ dri2_dpy-extensions,
+
Re: [Mesa-dev] [PATCH RFC] egl/dri2: Add dri3 support to x11 platform
Hi Emil,
On 07/03/2015 10:36 PM, Emil Velikov wrote:
Hi Boyan,
Thank you for doing this ! A few suggestions which you might be interesting:
Considering that the backend has handled more than dri2 perhaps we can
do a s/dri2/dri/ :-) That obviously is independent of your work.
On 01/07/15 16:31, Boyan Ding wrote:
Signed-off-by: Boyan Ding boyan.j.d...@gmail.com
---
configure.ac |3 +
src/egl/drivers/dri2/Makefile.am |5 +
src/egl/drivers/dri2/egl_dri2.c | 65 +-
src/egl/drivers/dri2/egl_dri2.h | 12 +-
src/egl/drivers/dri2/platform_x11.c | 127 ++-
src/egl/drivers/dri2/platform_x11_dri3.c | 1591
++
src/egl/drivers/dri2/platform_x11_dri3.h | 140 +++
7 files changed, 1926 insertions(+), 17 deletions(-)
create mode 100644 src/egl/drivers/dri2/platform_x11_dri3.c
create mode 100644 src/egl/drivers/dri2/platform_x11_dri3.h
diff --git a/configure.ac b/configure.ac
index af61aa2..090e6c9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1545,6 +1545,9 @@ if test x$enable_egl = xyes; then
if test x$enable_shared_glapi = xno; then
AC_MSG_ERROR([egl_dri2 requires --enable-shared-glapi])
fi
+if test x$enable_dri3 = xyes; then
+EGL_LIB_DEPS=$EGL_LIB_DEPS -lxcb-dri3 -lxcb-present
-lXxf86vm -lxshmfence -lxcb-sync
Neither one of these should be a direct -lfoo expression. We should
check/use PKG_CHECK_MODULES and foo_{CFLAGS,LIBS}.
I'll correct that.
+fi
else
# Avoid building an empty libEGL. Drop/update this
# when other backends (haiku?) come along.
diff --git a/src/egl/drivers/dri2/Makefile.am
b/src/egl/drivers/dri2/Makefile.am
index 55be4a7..d5b511c 100644
--- a/src/egl/drivers/dri2/Makefile.am
+++ b/src/egl/drivers/dri2/Makefile.am
@@ -52,6 +52,11 @@ if HAVE_EGL_PLATFORM_X11
libegl_dri2_la_SOURCES += platform_x11.c
AM_CFLAGS += -DHAVE_X11_PLATFORM
AM_CFLAGS += $(XCB_DRI2_CFLAGS)
+if HAVE_DRI3
+libegl_dri2_la_SOURCES += \
+platform_x11_dri3.c \
+platform_x11_dri3.h
+endif
endif
if HAVE_EGL_PLATFORM_WAYLAND
diff --git a/src/egl/drivers/dri2/egl_dri2.c
b/src/egl/drivers/dri2/egl_dri2.c
index b1b65f7..052c579 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -322,6 +322,12 @@ struct dri2_extension_match {
int offset;
};
+static struct dri2_extension_match dri3_driver_extensions[] = {
+ { __DRI_CORE, 1, offsetof(struct dri2_egl_display, core) },
+ { __DRI_IMAGE_DRIVER, 1, offsetof(struct dri2_egl_display, image_driver)
},
+ { NULL, 0, 0 }
+};
+
static struct dri2_extension_match dri2_driver_extensions[] = {
{ __DRI_CORE, 1, offsetof(struct dri2_egl_display, core) },
{ __DRI_DRI2, 2, offsetof(struct dri2_egl_display, dri2) },
@@ -464,6 +470,24 @@ dri2_open_driver(_EGLDisplay *disp)
}
EGLBoolean
+dri2_load_driver_dri3(_EGLDisplay *disp)
dri3_load_driver perhaps ?
I prefixed all my functions in public files with dri2 instead of
dri3 because the EGL driver is currently called DRI2 (although it
seems funny to see dri3 in a driver called dri2).
The current name of the driver is DRI2 because it uses dri2 to talk
with the X server and uses similar technologies with direct rendering
on other platforms. With my patch, the first reason becomes invalid.
But should the name of the driver or namespace of all functions (or
just the functions involved with dri3) change? I'm open to others'
suggestions. The same applies to comments on function names below.
[snip]
diff --git a/src/egl/drivers/dri2/egl_dri2.h
b/src/egl/drivers/dri2/egl_dri2.h
index f0cc6da..d258753 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -153,11 +153,16 @@ struct dri2_egl_display
int dri2_major;
int dri2_minor;
+ int dri3_major;
+ int dri3_minor;
+ int present_major;
+ int present_minor;
Many of these are unused. Same goes for the glx code which was the
inspiration for this work :-)
I think it's safe to remove them then.
__DRIscreen *dri_screen;
int own_dri_screen;
const __DRIconfig **driver_configs;
void *driver;
const __DRIcoreExtension *core;
+ const __DRIimageDriverExtension *image_driver;
const __DRIdri2Extension *dri2;
const __DRIswrastExtension *swrast;
const __DRI2flushExtension *flush;
@@ -189,6 +194,7 @@ struct dri2_egl_display
#ifdef HAVE_X11_PLATFORM
xcb_connection_t *conn;
int screen;
+ Display *dpy;
If we only loved XF86VIDMODE and/or xcb a bit more we wouldn't need this
:'-(
[Mesa-dev] [PATCH RFC] egl/dri2: Add dri3 support to x11 platform
Signed-off-by: Boyan Ding boyan.j.d...@gmail.com
---
configure.ac |3 +
src/egl/drivers/dri2/Makefile.am |5 +
src/egl/drivers/dri2/egl_dri2.c | 65 +-
src/egl/drivers/dri2/egl_dri2.h | 12 +-
src/egl/drivers/dri2/platform_x11.c | 127 ++-
src/egl/drivers/dri2/platform_x11_dri3.c | 1591 ++
src/egl/drivers/dri2/platform_x11_dri3.h | 140 +++
7 files changed, 1926 insertions(+), 17 deletions(-)
create mode 100644 src/egl/drivers/dri2/platform_x11_dri3.c
create mode 100644 src/egl/drivers/dri2/platform_x11_dri3.h
diff --git a/configure.ac b/configure.ac
index af61aa2..090e6c9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1545,6 +1545,9 @@ if test x$enable_egl = xyes; then
if test x$enable_shared_glapi = xno; then
AC_MSG_ERROR([egl_dri2 requires --enable-shared-glapi])
fi
+if test x$enable_dri3 = xyes; then
+EGL_LIB_DEPS=$EGL_LIB_DEPS -lxcb-dri3 -lxcb-present -lXxf86vm
-lxshmfence -lxcb-sync
+fi
else
# Avoid building an empty libEGL. Drop/update this
# when other backends (haiku?) come along.
diff --git a/src/egl/drivers/dri2/Makefile.am b/src/egl/drivers/dri2/Makefile.am
index 55be4a7..d5b511c 100644
--- a/src/egl/drivers/dri2/Makefile.am
+++ b/src/egl/drivers/dri2/Makefile.am
@@ -52,6 +52,11 @@ if HAVE_EGL_PLATFORM_X11
libegl_dri2_la_SOURCES += platform_x11.c
AM_CFLAGS += -DHAVE_X11_PLATFORM
AM_CFLAGS += $(XCB_DRI2_CFLAGS)
+if HAVE_DRI3
+libegl_dri2_la_SOURCES += \
+ platform_x11_dri3.c \
+ platform_x11_dri3.h
+endif
endif
if HAVE_EGL_PLATFORM_WAYLAND
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index b1b65f7..052c579 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -322,6 +322,12 @@ struct dri2_extension_match {
int offset;
};
+static struct dri2_extension_match dri3_driver_extensions[] = {
+ { __DRI_CORE, 1, offsetof(struct dri2_egl_display, core) },
+ { __DRI_IMAGE_DRIVER, 1, offsetof(struct dri2_egl_display, image_driver) },
+ { NULL, 0, 0 }
+};
+
static struct dri2_extension_match dri2_driver_extensions[] = {
{ __DRI_CORE, 1, offsetof(struct dri2_egl_display, core) },
{ __DRI_DRI2, 2, offsetof(struct dri2_egl_display, dri2) },
@@ -464,6 +470,24 @@ dri2_open_driver(_EGLDisplay *disp)
}
EGLBoolean
+dri2_load_driver_dri3(_EGLDisplay *disp)
+{
+ struct dri2_egl_display *dri2_dpy = disp-DriverData;
+ const __DRIextension **extensions;
+
+ extensions = dri2_open_driver(disp);
+ if (!extensions)
+ return EGL_FALSE;
+
+ if (!dri2_bind_extensions(dri2_dpy, dri3_driver_extensions, extensions)) {
+ dlclose(dri2_dpy-driver);
+ }
+ dri2_dpy-driver_extensions = extensions;
+
+ return EGL_TRUE;
+}
+
+EGLBoolean
dri2_load_driver(_EGLDisplay *disp)
{
struct dri2_egl_display *dri2_dpy = disp-DriverData;
@@ -507,7 +531,9 @@ dri2_setup_screen(_EGLDisplay *disp)
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
unsigned int api_mask;
- if (dri2_dpy-dri2) {
+ if (dri2_dpy-image_driver) {
+ api_mask = dri2_dpy-image_driver-getAPIMask(dri2_dpy-dri_screen);
+ } else if (dri2_dpy-dri2) {
api_mask = dri2_dpy-dri2-getAPIMask(dri2_dpy-dri_screen);
} else {
assert(dri2_dpy-swrast);
@@ -527,11 +553,12 @@ dri2_setup_screen(_EGLDisplay *disp)
if (api_mask (1 __DRI_API_GLES3))
disp-ClientAPIs |= EGL_OPENGL_ES3_BIT_KHR;
- assert(dri2_dpy-dri2 || dri2_dpy-swrast);
+ assert(dri2_dpy-image_driver || dri2_dpy-dri2 || dri2_dpy-swrast);
disp-Extensions.KHR_surfaceless_context = EGL_TRUE;
disp-Extensions.MESA_configless_context = EGL_TRUE;
- if ((dri2_dpy-dri2 dri2_dpy-dri2-base.version = 3) ||
+ if (dri2_dpy-image_driver ||
+ (dri2_dpy-dri2 dri2_dpy-dri2-base.version = 3) ||
(dri2_dpy-swrast dri2_dpy-swrast-base.version = 3)) {
disp-Extensions.KHR_create_context = EGL_TRUE;
@@ -591,7 +618,14 @@ dri2_create_screen(_EGLDisplay *disp)
dri2_dpy = disp-DriverData;
- if (dri2_dpy-dri2) {
+ if (dri2_dpy-image_driver) {
+ dri2_dpy-dri_screen =
+ dri2_dpy-image_driver-createNewScreen2(0, dri2_dpy-fd,
+ dri2_dpy-extensions,
+ dri2_dpy-driver_extensions,
+ dri2_dpy-driver_configs,
+ disp);
+ } else if (dri2_dpy-dri2) {
if (dri2_dpy-dri2-base.version = 4) {
dri2_dpy-dri_screen =
dri2_dpy-dri2-createNewScreen2(0, dri2_dpy-fd,
@@ -627,7 +661,7 @@ dri2_create_screen(_EGLDisplay *disp)
extensions = dri2_dpy-core-getExtensions(dri2_dpy-dri_screen);
- if (dri2_dpy-dri2) {
+ if (dri2_dpy-image_driver || dri2_dpy-dri2) {
