No, the plugin framework was developed specifically for a customer. The only documentation for it is in the API headers. I wish I could be of more help. This project interests me, but the only way I make money is by consulting and doing custom development for companies regarding VirtualGL and TurboVNC (and occasionally libjpeg-turbo), so I just can't devote a lot of free time to research projects like this, particularly given that gaming companies historically haven't been money makers for me.
On 6/12/15 4:13 PM, Marco Marino wrote: > Ok, thanks. Is there some technical documentation for virtualgl > developers? I need to understand the code, if i have to write a plugin. > And the code is not trivial. I have no experience, and i never read > virtualgl code before. > However, thanks again for you answers. > MM > > 2015-06-12 22:42 GMT+02:00 DRC <dcomman...@users.sourceforge.net > <mailto:dcomman...@users.sourceforge.net>>: > > OK, then yes, with the qualifications that you mention (a workload that > updates a predictable area of the screen in a predictable way, i.e. > games & video applications; low-bandwidth; reasonable image quality), > then a video codec such as H.264 is definitely going to be the best > solution. > > I am working with some engineers at nVidia to look into how to integrate > H.264 with VirtualGL and TurboVNC, but we are still just bouncing ideas > around at this point. I don't know if we'll come up with anything > concrete in the timeframe you need. And since you're a student, writing > a transport plugin would be a good exercise. > > Study testplugin.cpp. Some things you'll have to consider: > > -- how to handle the delivery of images over the network. The VGL > Transport is really designed for use along with a remote X server, so > it's probably not the right protocol for you to use. What would be > Really Cool(TM) is if you could leverage an existing streaming video > protocol. > > -- how to handle the delivery of keyboard/mouse events from the client > to the server. When you're dealing with an immersive application, such > as a game, for which window and GUI management are irrelevant, you could > do something clever, such as using an Xvfb instance on the server side > to act as a 2D X server. Xvfb would be used solely for event > management. Your plugin would intercept keyboard/mouse events from the > client and inject them into the Xvfb instance so that the 3D application > will receive them via its X event queue. No actual pixels will be drawn > into that X server-- the pixels will be intercepted by the VGL plugin > and sent directly to the client. > > You are not required to open source any of your work (VGL plugins can be > proprietary), but if you choose to do so, I'll be happy to review it for > possible inclusion in VirtualGL. > > Also, you should investigate whether libx264 is a faster solution than > FFmpeg for compressing H.264. > > Please feel free to ask follow-up questions on the virtualgl-devel list. > > > On 6/12/15 12:17 PM, Marco Marino wrote: > > Thanks for your answer. > > As you told "H.264 doesn't benefit all applications-- mainly it will > > only improve the situation for games and other very video-like > > workloads". And this is my purpose! I need a reliable, high latency > > network compatible "transport". I'm interested in gaming, and video > > reproduction but i want (!) to use linux, and i thought that VirtualGL > > could be an option. > > Use a low JPEG quality is not a solution for me, I need good image > quality. > > Write a transport plugin could be a solution? What i have to study > > before I can write a transport plugin? Have you some example (yes, i > > know testplugin.cpp) ? > > Thank you, > > MM > > > > 2015-05-27 9:42 GMT+02:00 DRC <dcomman...@users.sourceforge.net > <mailto:dcomman...@users.sourceforge.net> > > <mailto:dcomman...@users.sourceforge.net > <mailto:dcomman...@users.sourceforge.net>>>: > > > > Depending on what you really need to do, it may not be necessary to > get > > that fancy. Most users of VirtualGL use it with an X11 proxy. > TurboVNC > > is the X proxy that our project provides and which has features and > > performance specifically targeted at 3D applications, but there are > > other X proxies that work with VGL as well (although usually not as > fast > > as TurboVNC.) The X proxy, when combined with VirtualGL, will > cause all > > of the 2D (X11) as well as 3D (OpenGL) rendering commands from the > > application to be rendered on the server and sent to the client as > image > > updates. TurboVNC specifically has a feature called "automatic > lossless > > refresh", which allows you to use a very low JPEG quality for most > > updates, but when the server senses that you have stopped moving > things > > around (such as when you stop rotating a 3D scene, etc.), it will > send a > > lossless update of the screen. X proxies also do a much better job > of > > handling high-latency networks, since they are sending more > > coarse-grained image updates instead of very fine-grained and > chatty X11 > > updates over the network. > > > > VirtualGL can also operate without an X proxy, but this is less > useful > > on high-latency networks, because it requires that the > non-3D-related > > X11 commands be sent over the network to the client machine. Even > > though the 3D-related X11 commands are being redirected by > VirtualGL and > > are being rendered on the server, the 2D-related X11 commands used > to > > draw the application GUI, etc. are still sent over the network, and > that > > can create performance problems on wide-area networks. > > > > Now, to more specifically answer your question-- you can reduce the > JPEG > > quality in VirtualGL, which will significantly reduce the bandwidth. > > Using TurboVNC will likely reduce the bandwidth as well, not only > > because the X11 stuff is being rendered on the server but because > > TurboVNC has a more adaptive compression scheme, whereas VirtualGL > uses > > plain motion-JPEG. I'm currently working with nVidia to research > > possible ways of leveraging their NVENC library to do H.264 > compression > > in VirtualGL, but there are a lot of technical hurdles we haven't > > figured out yet vis-a-vis how that would interact with X proxies > such as > > TurboVNC. Also, H.264 doesn't benefit all applications-- mainly it > will > > only improve the situation for games and other very video-like > > workloads. More tradition 3D applications (CAD, visualization, > etc.) > > are already quite optimal with TurboVNC's existing compression > scheme. > > > > VirtualGL does have a transport plugin API, so you could > conceivably use > > that to write your own transport plugin based on the existing VGL > > Transport code (see server/testplugin.cpp for an example) but which > uses > > ffmpeg instead of libjpeg-turbo to do the 3D image compression. > Whether > > or not that would really improve bandwidth usage would depend a lot > on > > your specific workload. > > > > > > On 5/27/15 1:31 AM, Marco Marino wrote: > > > Hi, > > > i'm a student and i'm trying virtualgl for education purposes. > From my > > > tests with vglrun I saw that huge amount of bandwidth is required > for > > > acceptable image quality (eg: -c jpeg with quality 90 requires > peaks of > > > 50/60 Mbits). Is there a way to compress the video flow? Can i do > > > something like: "VGLSOCKET" -> My compression library (like > ffmpeg or > > > similar) -> TCP/UDP socket ? In practice i want try to compress > with my > > > own code the output of VGL. Is this possible? I'm sorry if this > is a > > > stupid question, but I don't have knowledge about virtualgl. > > > Thanks > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > VirtualGL-Users mailing list > >VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net> > > <mailto:VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net>> > >https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > VirtualGL-Users mailing list > >VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net> > >https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > <mailto:VirtualGL-Users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > ------------------------------------------------------------------------------ _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
