Roadmap for features planed for containers where and Some future features ideas.

[Eric W. Biederman]

"Peter Dolding" <oiaohm at gmail.com> writes:

> The simple problem that is not possible and most likely never will be.
>  How to virtual opengl for VNC is use a program call
> http://virtualgl.org  and that is not state less and gpu dependent.
>
> You are keeping on forgetting high end stuff like glsl need to be
> processed in video cards gpu's to emulate need really large cpu's.  2d
> rendering is simple to do stateless.
>
> Your opinion is simply not workable.  You are not thinking of the
> problem correct.
>
> Lets say you want to migrate between X86 and PPC running applications
> using containers how are you going to do it.   This is really the
> level of complexity you have inside video card gpu's.  They are that
> far different.   Programs have to generate there glsl code to suit the
> video card they are talking to or it will not work correctly.  Reason
> why some games have on box only NVidia or only ATI gpu's.
>
> Now before you say emulate.  Like to point something nasty out.
> State dump of a gpu is basically not documented its a black box so
> emulation is not a option.  Even if you could you are talking about
> emulating something that will need the power of a 16 core 4 ghz intel
> processor if it has only 1 GPU to emulate.  Note some video cards have
> upto 4.   How effective gpu's are at doing there job is highly under
> estimated .
>
> Yes the issue is some opengl programs can be done stateless up until
> they start using shader languages physics and other things in GPU.
> Past that point stateless and gpu independent stuff.  Lots and lots of
> programs need the GPU dependant stuff.
>
> Virtualgl does rendering server side due to the massive amounts of
> data that can be travelling between the cpu and gpu.   It really like
> saying we are not going to have a maths processer in the server and
> every time you want to do some maths you have to go threw network to
> do it.
>
> GPU are not just drawing to screen.   They do all kinds of things
> these days.  They have to be used locally to the program running there
> is not enough network bandwidth and they will not run right.

I need to research this some more, but migration is essentially the
same problem as suspend and hibernation (admittedly different kinds of
video make this trickier).  Migration and hibernation we can handle
today with hardware going away and coming back.  It sounds like to me
the most general approach is a light-weight proxy X server that can
forward things on the slow path and allow the fast path accesses to
go fast.

Eric