Just to give an idea of the scale of the problem, even a "mid-range" nVidia card-- something like I'm running, the Quadro 600, which is one of the lower-end "professional" cards but still better than a consumer-grade GeForce card-- is capable of 400 million polygons per second. Now, the Intel GPUs that ship in a lot of machines these days are capable of only about 1/10 of that (30-40 million), since they are using hybrid software/hardware OpenGL rendering. If you're talking about pure software rendering solely using the CPU, then it's another factor of 10 (3-4 million polys/second) on a reasonably modern CPU. Thus, the difference between a decent GPU and a decent CPU is easily two orders of magnitude (more if you're using a more high-end Quadro than what I have.) GPUs are designed precisely for doing 3D computations, and they've had 20 years to get really really good at them. When I first started in the 3D business in 1996, the 3DLabs chips we were working with back then (this was pre-nVidia, and before the term "GPU" was even invented) were less than an order of magnitude faster than software rendering, and even with acceleration, you were looking at something like 300k-500k polys/second. Flash forward 17 years, and CPUs can now render OpenGL something like 50 or 100 times faster than they could in 1996, but GPUs have improved by more like a factor of 1000 to 2000 during the same time period. And that's just considering raw geometry performance. When you start considering texture mapping, the GPU has an even larger advantage.
Arthur is right. The purpose of VirtualGL is ultimately to virtualize GPU resources (hence the name.) We do that by redirecting rendering into an off-screen buffer on the X display that is connected to the GPU. If you're using purely software rendering, then there is no purpose to doing redirection at all. You can simply run Mesa in-process, but per above, it's going to be slow. The other thing to bear in mind is that, when you start talking about redirecting OpenGL to another machine, then you're talking about "indirect OpenGL." With indirect OpenGL, all of the OpenGL commands are sent over the wire, and if your app is using immediate mode (the "traditional" way OpenGL is rendered, in which all geometry commands are repeated with every frame, as opposed to using display lists or VBO's), or if the app is using a lot of textures, then the performance will still be very bad even if there's a GPU on the other end. On 9/19/13 10:56 AM, Amanda Tumminello wrote: > I have been looking at and playing with this software for some time. It > works wonderfully when using 3D enabled graphics cards! > > Is it possible to offload to a CPU instead of a GPU. If so is there any > special steps that I need to take? We have some servers with adequate > processing that i have been told should be able to handle the graphics > load. ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
