It's certainly possible to do this but not recommended. You have to bear in mind that this scheme will send all of the OpenGL commands and data over the network without compression and that, unless the app is smart enough to use display lists, all of the commands/data will be sent every time a frame is rendered. Additionally, all of the rendered 3D images will be sent back over the network uncompressed (because the glReadPixels() call that VGL is making to read back the framebuffer contents is also being executed indirectly.) Even gigabit is probably insufficient for this in most real-world cases. What you'd be doing is basically circumventing VirtualGL's entire reason for existence.
If the display is ultimately going to end up on P1, then why not just run the application on P2 with VirtualGL and use P1 as the client? You may think that you want the compute to occur on P1, but all you're doing there is trading off one performance problem for a much much worse one. On Feb 17, 2012, at 9:26 AM, Nathan Kidd <nathan...@spicycrypto.ca> wrote: > On 12-02-17 07:13 AM, VITIELLO Fabien wrote: >> Do you know if it's possible to realize the following scheme in the >> attached file with VirtualGL ? >> >> The scheme describes the following use case : >> >> An application located on a platform P1 (which has no 3D hardware >> acceleration support but communicates with other applications through >> inter-process communications (IPC)) calls OpenGL commands redirected to >> a remote X server on a P2 platform which has a good 3D hardware >> acceleration. The 3D rendering is displayed in this P2 platform. >> >> This use case could take advantages of the communication inter-processus >> with a remote 3D acceleration on another platform. The display could be >> done on the platform P2 or P1 via the VirtualGL client/server feature. > > Certainly possible, run the app with VGL on P1, but set VGL_DISPLAY to > P2 (e.g. VGL_DISPLAY=P2:0). (This is interpreting your "IPC" as simply > meaning remote X11 rendering.) > > However, whether this will give you acceptable performance is highly > dependent on > a) is the application written to handle indirect rendering well (i.e. > if it does 500 glGet()s per rendered frame you're out of luck), and > b) how fast is your network between P1 and P2. > > -Nathan > OpenText > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
