Form autofoo perspective things look great.
Thanks, that exactly what I wanted to know.
Although I second Ilia's concern - we need a form of runtime detection
here. Pretty much all distros ship the vdpau(+ other video driver
backend) in a separate library. Thus this will likely get us nowhere
we want - as I'm suspecting this is to assist the unsuspecting user,
which hasn't installed package X or Y in the first place ?
As I said, Mesa should NOT check what vdpau backend libraries are
installed or used before advertising NV_vdpau_interop.
Take a look at how the interop works, NV_vdpau_interop should be
advertised if the OpenGL implementation provides the necessary
functions. What and if a VDPAU backend gets loaded to work with that is
completely independent of this.
We want to switch over to a DMABuf based interop implementation so that
we can get away from using the Mesa internal structures.
This not only has the advantage of fixing this ugly hack, but also would
allow an application to decode on one driver (radeonsi) and display with
another one (r600).
Regards,
Christian.
Am 22.01.2016 um 17:15 schrieb Emil Velikov:
Form autofoo perspective things look great.
Although I second Ilia's concern - we need a form of runtime detection
here. Pretty much all distros ship the vdpau(+ other video driver
backend) in a separate library. Thus this will likely get us nowhere
we want - as I'm suspecting this is to assist the unsuspecting user,
which hasn't installed package X or Y in the first place ?
I won't object against it but please can we get a big fat warning/note
- anything vaguely alike "this is a hack until we get a runtime
detection of the presence/interop of the partner library/module" will
be great.
Thanks
Emil
On 21 January 2016 at 21:02, Christian König <deathsim...@vodafone.de> wrote:
Advertising NV_vdpau_interop while the backend for the driver isn't
installed is fine, cause this only means that the OpenGL side has support
for it.
Mesa doesn't have a runtime dependency on libvdpau and to initialize
NV_vdpau_interop the application must open libvdpau first.
So if libvdpau isn't installed this will fail way even before Mesa into the
picture.
My question is rather if that's the right approach? I'm not really an expert
on autohell.
Regards,
Christian.
Am 21.01.2016 um 17:09 schrieb Ilia Mirkin:
I wonder if something more robust is needed. Let's say a distro builds
with vdpau and everything else enabled, but then ships the libraries
separately...
On Thu, Jan 21, 2016 at 11:05 AM, Christian König
<deathsim...@vodafone.de> wrote:
From: Christian König <christian.koe...@amd.com>
Only enable it when we compile the state tracker as well.
Signed-off-by: Christian König <christian.koe...@amd.com>
---
configure.ac | 1 +
src/mesa/state_tracker/st_extensions.c | 2 ++
src/mesa/state_tracker/st_vdpau.c | 6 ++++++
3 files changed, 9 insertions(+)
diff --git a/configure.ac b/configure.ac
index 8d19dab..a92f707 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1741,6 +1741,7 @@ AM_CONDITIONAL(HAVE_ST_XVMC, test "x$enable_xvmc" =
xyes)
if test "x$enable_vdpau" = xyes; then
PKG_CHECK_MODULES([VDPAU], [vdpau >= $VDPAU_REQUIRED])
gallium_st="$gallium_st vdpau"
+ DEFINES="$DEFINES -DHAVE_ST_VDPAU"
fi
AM_CONDITIONAL(HAVE_ST_VDPAU, test "x$enable_vdpau" = xyes)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 2a3e523..25e88ea 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -959,12 +959,14 @@ void st_init_extensions(struct pipe_screen *screen,
extensions->ARB_ES3_compatibility = GL_TRUE;
}
+#ifdef HAVE_ST_VDPAU
if (screen->get_video_param &&
screen->get_video_param(screen, PIPE_VIDEO_PROFILE_UNKNOWN,
PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
PIPE_VIDEO_CAP_SUPPORTS_INTERLACED)) {
extensions->NV_vdpau_interop = GL_TRUE;
}
+#endif
if (screen->get_shader_param(screen, PIPE_SHADER_VERTEX,
PIPE_SHADER_CAP_DOUBLES) &&
diff --git a/src/mesa/state_tracker/st_vdpau.c
b/src/mesa/state_tracker/st_vdpau.c
index 63af119..71dd15b 100644
--- a/src/mesa/state_tracker/st_vdpau.c
+++ b/src/mesa/state_tracker/st_vdpau.c
@@ -49,6 +49,8 @@
#include "st_format.h"
#include "st_cb_flush.h"
+#ifdef HAVE_ST_VDPAU
+
static void
st_vdpau_map_surface(struct gl_context *ctx, GLenum target, GLenum
access,
GLboolean output, struct gl_texture_object
*texObj,
@@ -180,9 +182,13 @@ st_vdpau_unmap_surface(struct gl_context *ctx,
GLenum target, GLenum access,
st_flush(st, NULL, 0);
}
+#endif
+
void
st_init_vdpau_functions(struct dd_function_table *functions)
{
+#ifdef HAVE_ST_VDPAU
functions->VDPAUMapSurface = st_vdpau_map_surface;
functions->VDPAUUnmapSurface = st_vdpau_unmap_surface;
+#endif
}
--
2.5.0
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
