From: Daniel Vetter <daniel@ffwll.ch>
To: Derek <derek0883@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: Ilija Hadzic's Virtual CRTCs feature discuss
Date: Tue, 26 Aug 2014 10:18:49 +0200 [thread overview]
Message-ID: <20140826081849.GH15520@phenom.ffwll.local> (raw)
In-Reply-To: <CAOMUgmj0gJs+aNp6zYraTh2HLprcLbkQgNB_X+mf4WKBQZDq2A@mail.gmail.com>
On Mon, Aug 25, 2014 at 12:02:09PM -0700, Derek wrote:
> Hi, Daniel
> Thanks for your response!
> Talking about v4l's virtual gpu driver? Could you please tell some more
> informations. is this driver in
> git.linuxtv.org/cgit.cgi/media_tree.git
> I want to take a look this driver. but I can't find it in their git
> repository. Or is there any introduction post related this driver? Thanks.
It isn't merged yet afaik, but Hans Verkuil has made a nice presentation
about it at LinuxCon. Unfortunately the linuxcon page doesn't even have
the slides afaics.
http://lccona14.sched.org/event/2e156d3ce84309b2932f2e7a512904e0#.U_xCcjSmXmE
The driver was called vidid (there's an older one called vidi apparently).
But I don't think it's a good model for a virtual drm driver, if that's
why you want to look at it. Just mentioned it to show that there's lots of
uses for virtual drivers.
-Daniel
>
> Best wishes
> Derek
>
>
> On Mon, Aug 25, 2014 at 6:12 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>
> > On Mon, Aug 18, 2014 at 03:35:16PM -0700, Derek wrote:
> > > Hi every one
> > > I'm currently working on VirtualMonitor in my leisure time. It allows you
> > > to use compute/tablet/smartphone as a second monitor for your primary
> > > computer. please refer to http://virtualmonitor.github.io for more
> > > information. Currently I have released very basic version for
> > > windows2000-windows7 to demonstrate the project is feasible. When I was
> > > trying to make a further step on windows, I realized it is difficult for
> > an
> > > individual, as it is not open source and also without technical support
> > > from Microsoft.
> > >
> > > Then I want to move to linux, and I found Ilija Hadzic's post about
> > Virtual
> > > CRTCs. his post is here:
> > >
> > http://lists.freedesktop.org/archives/dri-devel/2011-November/015975.html
> > > In his implementation, GPU driver can create arbitrary number of CRTCs
> > > (configurable by user) instead of only those CRTCs that represent real
> > > hardware.
> > > It is very useful not only for VirtualMonitor, but also
> > > VNC/Virtualization/USB display etc. based on this implementation those
> > > application will be able to take full advantage of the physical graphic
> > > card(3D acceleration).
> > >
> > > I want raise Ilijia's original question agian, if anybody in this
> > community
> > > think Virtual CRTCs is useful, and willing to work together to make a
> > > further progress.
> > > My thought is if can implement a driver independent layer between dri and
> > > vendor specific GPU driver, with some general API. maybe implement this
> > > based one vendor related GPU first? e.g. based on Ilijia's implementation
> > > for Radeon as a daemon?
> > >
> > > GPU driver is not my expertise, If some expert from this community think
> > > this feature is interesting, and willing to initiate a project for this
> > > feature, that will be great. Then people can work and discuss together.
> > >
> > > Any comments regarding to Virtual CRTC or VirtualMonitor are very
> > welcome.
> > > Thanks.
> >
> > I think the concept is overall sound (haven't looked at the old patches in
> > detail).For the actual implementation I think a separate virtual drm
> > driver is now
> > the better approach, since with dma-buf and soon native fence support we
> > can do this now properly.
> >
> > And especially now that we have multi-gpu support in X it should integrate
> > almost seamlessly into X (and other display managers with multi-gpu
> > support). Instead of requering special support in all drivers.
> >
> > Another thing for which iirc no one ever proposed a decent solution is
> > synchronization to consumers of the frontbuffers for virtual gpus. So I
> > guess the driver-private ioctl interface to make that magic work will be
> > key.
> >
> > A (configurable) virtual gpu should also be really useful for automated
> > testing, e.g. of hot-plug and unplug (both drm core and userspace). The
> > v4l folks have such a driver (recently massively revamped for 3.18) and it
> > looks extremely useful.
> >
> > For the configuration interface I guess a few simple module options to get
> > started should be enough, eventually we can switch to configfs (or
> > similar) to be able to configure and create/destroy virtual gpus at
> > runtime.
> >
> > Just my random thoughts, probably good to kickstart the discussion with
> > some quick patches and chat with people on #dri-devel on freenode irc.
> >
> > Cheers, Daniel
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2014-08-26 8:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-18 22:35 Ilija Hadzic's Virtual CRTCs feature discuss Derek
2014-08-25 13:12 ` Daniel Vetter
2014-08-25 19:02 ` Derek
2014-08-26 8:18 ` Daniel Vetter [this message]
[not found] ` <CAOMUgmhOGBE8_LDFa9pMcyyhott4SaA5jm0wQgxJXZ2+-9u=HA@mail.gmail.com>
2014-08-27 17:54 ` Daniel Vetter
2014-08-27 18:05 ` Derek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140826081849.GH15520@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=derek0883@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox