[Mesa-dev] [PATCH 7/7] st/va: add headless support, i.e. VA_DISPLAY_DRM
Julien Isorce
julien.isorce at gmail.com
Tue Oct 20 09:06:42 PDT 2015
On 19 October 2015 at 17:16, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 17 October 2015 at 00:14, Julien Isorce <julien.isorce at gmail.com>
> wrote:
> > This patch allows to use gallium vaapi without requiring
> > a X server running for your second graphic card.
> >
> I've sent a lengthy series which should mitigate the need of some hunks.
>
Ok I'll wait for your patches to land before going further on this patch.
Should I expect vl_winsy_drm.c in your patches ? Not sure do understood
that part. Actually I though about having "vl_screen_create_drm" and
renames vl_screen_create to vl_screen_create_x11 (because it takes XDisplay
in params) but then I got confused because vl_winsys.h includes Xlib.h.
Should future vl_screen_create_drm be in another header, vl_drm.h ?
Thx
Julien
> > Signed-off-by: Julien Isorce <j.isorce at samsung.com>
> > ---
> > src/gallium/state_trackers/va/Makefile.am | 9 ++++++
> > src/gallium/state_trackers/va/context.c | 49
> +++++++++++++++++++++++++++----
> > 2 files changed, 53 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/gallium/state_trackers/va/Makefile.am
> b/src/gallium/state_trackers/va/Makefile.am
> > index 2a93a90..348cfe1 100644
> > --- a/src/gallium/state_trackers/va/Makefile.am
> > +++ b/src/gallium/state_trackers/va/Makefile.am
> > @@ -30,6 +30,15 @@ AM_CFLAGS = \
> > $(VA_CFLAGS) \
> > -DVA_DRIVER_INIT_FUNC="__vaDriverInit_$(VA_MAJOR)_$(VA_MINOR)"
> >
> > +AM_CFLAGS += \
> > + $(GALLIUM_PIPE_LOADER_DEFINES) \
> > + -DPIPE_SEARCH_DIR=\"$(libdir)/gallium-pipe\"
> > +
> > +if HAVE_GALLIUM_STATIC_TARGETS
> > +AM_CFLAGS += \
> > + -DGALLIUM_STATIC_TARGETS=1
> > +endif
> > +
> Like this one.
>
> > AM_CPPFLAGS = \
> > -I$(top_srcdir)/include
> >
> > diff --git a/src/gallium/state_trackers/va/context.c
> b/src/gallium/state_trackers/va/context.c
> > index ddc863b..9ab2710 100644
> > --- a/src/gallium/state_trackers/va/context.c
> > +++ b/src/gallium/state_trackers/va/context.c
> > @@ -28,7 +28,8 @@
> >
> > #include "pipe/p_screen.h"
> > #include "pipe/p_video_codec.h"
> > -
> > +#include "pipe-loader/pipe_loader.h"
> > +#include "state_tracker/drm_driver.h"
> > #include "util/u_memory.h"
> > #include "util/u_handle_table.h"
> > #include "util/u_video.h"
> > @@ -98,7 +99,7 @@ static struct VADriverVTableVPP vtable_vpp =
> > PUBLIC VAStatus
> > VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
> > {
> > - vlVaDriver *drv;
> > + vlVaDriver *drv = NULL;
> Unnecessary change.
>
> >
> > if (!ctx)
> > return VA_STATUS_ERROR_INVALID_CONTEXT;
> > @@ -107,8 +108,40 @@ VA_DRIVER_INIT_FUNC(VADriverContextP ctx)
> > if (!drv)
> > return VA_STATUS_ERROR_ALLOCATION_FAILED;
> >
> > - drv->vscreen = vl_screen_create(ctx->native_dpy, ctx->x11_screen);
> > - if (!drv->vscreen)
> > + drv->vscreen = NULL;
> DItto.
>
> > +
> > + switch (ctx->display_type) {
> > + case VA_DISPLAY_X11:
> > + drv->vscreen = vl_screen_create(ctx->native_dpy, ctx->x11_screen);
> > + if (!drv->vscreen)
> > + goto error_screen;
> > + break;
> > +
> > + case VA_DISPLAY_DRM:
> > + case VA_DISPLAY_DRM_RENDERNODES: {
> > + struct drm_state *drm_info = (struct drm_state *) ctx->drm_state;
> > + if (!drm_info)
> > + goto error_screen;
> > +
> > + drv->vscreen = CALLOC_STRUCT(vl_screen);
> > +
> > +#if GALLIUM_STATIC_TARGETS
> > + drv->vscreen->pscreen = dd_create_screen(drm_info->fd);
> > +#else
> > + int loader_fd = dup(drm_info->fd);
> > + if (loader_fd == -1)
> > + goto error_screen;
> > +
> > + if (pipe_loader_drm_probe_fd(&drv->dev, loader_fd))
> > + drv->vscreen->pscreen = pipe_loader_create_screen(drv->dev,
> PIPE_SEARCH_DIR);
> > +#endif
> And much of this.
>
> Having this around feels rather abusive. I'm leaning that ideally we
> need vl_winsy_drm.c, but I'll let others decide. At the very least the
> error paths looks quite funky. Please use the same approach as in
> vlVaTerminate()
>
> -Emil
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20151020/613657b4/attachment.html>
More information about the mesa-dev
mailing list