[PATCH] drm/vgem: create a render node for vgem

Daniel Vetter daniel at ffwll.ch
Mon Oct 29 13:51:53 UTC 2018


On Mon, Oct 29, 2018 at 12:03:46PM +0000, Emil Velikov wrote:
> On Fri, 26 Oct 2018 at 14:40, Daniel Vetter <daniel at ffwll.ch> wrote:
> >
> > On Fri, Oct 26, 2018 at 01:06:47PM +0100, Emil Velikov wrote:
> > > From: Emil Velikov <emil.velikov at collabora.com>
> > >
> > > VGEM doesn't do anything modeset specific, so in a way exposing a
> > > primary node is 'wrong'. At the same time, we extensively use if for
> > > creating dumb buffers, fences, prime fd <> handle imports/exports.
> > >
> > > To the point that we explicitly annotate the vgem fence ioctls as
> > > DRM_RENDER_ALLOW and have an IGT test which opens the render node.
> > >
> > > close(drm_open_driver_render(DRIVER_VGEM))
> >
> > Huh, I guess that test doesn't pass?
> >
> It does since the IGT code seems bonkers... Namely it silently falls
> back to the primary/card node.
> It seems to be for historical reasons... back in the days where render
> nodes were still experimental and had to be explicitly enabled via
> kernel arg.
> 
> I'll try and follow-up to address that.

I guess enforcing this with igt is a bit harder, since not much with
render nodes is generic across drivers. Hence a lot of the tests are very
specific.

But anything we can increase the odds for people using render nodes is
good I guess, and if it's just using vgem as a driver copypaste template.
-Daniel

> 
> > > Better late than never, let's flip the switch.
> > >
> > > Cc: David Airlie <airlied at linux.ie>
> > > Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> > > Signed-off-by: Emil Velikov <emil.velikov at collabora.com>
> >
> > Acked-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> 
> Thanks. I'll give it a few more days for others to review/comment.
> 
> -Emil

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the dri-devel mailing list