I understand your point of view, but without any documentation (and a bit of help) is impossible for me develop such transport plugin. Actually i'm also working (part-time) for an ISP as openstack administrator, so i do not have much time. VirtualGL is an interesting software for the cloud, because my (personal) idea is that in the future also GPU will be an integrated part of vms. So i need a way to stream 3d applications and VirtualGL is fantastic (except for the bandwidth). Another (personal) idea is that in the near (i hope) future, OpenGL will be re-evaluated for what it is: the best API for 3d in the world. So, if you find a little time, please reconsider the idea of expand the documentation of virtualgl for developers and make more easy the transport plugin development. Thanks, MM
2015-06-13 0:23 GMT+02:00 DRC <[email protected]>: > 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 <[email protected] > > <mailto:[email protected]>>: > > > > 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 <[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>>>: > > > > > > 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 > > >[email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> > > >https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > _______________________________________________ > > > VirtualGL-Users mailing list > > >[email protected] > > <mailto:[email protected]> > > >https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > VirtualGL-Users mailing list > > [email protected] > > <mailto:[email protected]> > > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > VirtualGL-Users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > VirtualGL-Users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/virtualgl-users >
------------------------------------------------------------------------------
_______________________________________________ VirtualGL-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/virtualgl-users
