[FoRK] The Future of Desktops
Gregory Alan Bolcer
greg at bolcer.org
Sun Mar 2 08:39:18 PST 2014
Agreed though.... Nividia has two break through technologies that
reduced that difference. That technique is fast-eliminating the types
of apps that don't work well for client render.
The first is the grid, the second is g-sync. The first is a
coordinative system with two GPUs at each end that speak a special
condensed protocol that can sync between a remote server and some
bandwidth varied internet connected client PC. The second is the GPU in
your PC talking across an HDMI cable or wifi to a GPU in either a gaming
client or the monitor using the same trick.
On a completely different subject, I was the founder of a company that
made a remote application streaming service. You could run a 400 Meg
Microsoft Office, or 1.2Gig Adobe Creative Suite and start using it in
under 60 seconds on a client as we tricked it into thinking it was
completely installed on a lan or wifi connection. The bits would also
get cached (and remote provisioned if you wanted). The biggest sales
issue we had was educating people that the apps were actually running
native on the system and were identical to having them locally installed
at a time when everyone else was educating the market about remote
On 3/1/2014 9:04 PM, J. Andrew Rogers wrote:
> On Mar 1, 2014, at 6:39 PM, Gregory Alan Bolcer <greg at bolcer.org> wrote:
>> Or it's Nividia GRID (and GaaS supported by PC-to-shield).
> More or less. You can’t push the render to the client for every application; sometimes the bandwidth of the frame is orders of magnitude smaller than any client-side render scheme.
> I’ve seen a growing number of cases where the frame generation requires 100+ Gbps of bandwidth due to the (necessary) complexity of the data model being rendered. That isn’t a lot of bandwidth for a system or even a cluster of servers but it is a hell of a lot for a LAN connection never mind a WAN connection. For cases like this, “steering” a constraint in a virtual server space that can construct frames in parallel is pretty efficient.
> It is the main reason visualization software can’t render non-trivial real-time data sources — they are designed to do a client-side render but the required bandwidth is implausibly high.
> FoRK mailing list
greg at bolcer.org, http://bolcer.org, c: +1.714.928.5476
More information about the FoRK