Triangles are usually not enough, you want textures too. If you're playing video you are faced with some though choices:
- stream the compressed video (the display has to be able to decode the format).
- transcode the video to a format supported by the display (expensive without dedicated hardware).
- stream uncompressed video (back to 60 frames of HD).
Clearly, the best option is hardware assisted transcoding. But then, why not use that hardware to compress on the fly the HD video, and keep the whole architecture a lot more simple in the first place? Food for thought.
Posted Oct 10, 2012 1:43 UTC (Wed) by mjg59 (subscriber, #23239)
[Link]
Right, once you're dealing with a significant number of textures then the texture load alone is probably more expensive than just pushing the pixels over the wire. Acceleration primitives make sense when you're doing nothing but drawing rectangles, but once you're beyond that point the reason you're using a GPU is because it's faster at turning your scene into a 2D image than the CPU is, not because you're using less memory bandwidth that way.
XDC2012: OpenGL futures
Posted Oct 11, 2012 10:15 UTC (Thu) by nix (subscriber, #2304)
[Link]
Still, doing the rendering at the client side when the client side is networkologically remote means that your X server (which is very likely to have a fast 3D-capable GPU) will see its GPU going unused, while the server (rather less likely to have a GPU) suddenly has to do GPU tasks... probably using llvmpipe. Ah well.
XDC2012: OpenGL futures
Posted Oct 11, 2012 15:17 UTC (Thu) by raven667 (subscriber, #5198)
[Link]
If this is a significant concern, for a large multi-user desktop server, then you can stuff GPUs into it to offload rendering, this is what other VDI solutions support such as VMware.