OpenCL, OpenGL 3.1 State Trackers "Hopefully Soon"

[Kano]

But you want Aero too in VMs, don't you

[krogy]

Beyond that, I don't know either the reason for the acquisition.
[cut]
Well, the money is mostly in the server virtualization space.

i smell GPU accelerated OpenCL computation.
that should be pretty usefull for some kind of server.

[MaestroMaus]

Beyond that, I don't know either the reason for the acquisition. Maybe it is for 3D virtualization but that seems odd to me (besides running Windows games, I don't see the benefit, so making real money from that seems difficult).

They might have a customer like Onlive who needs that.

[bridgman]

If you wanted a single, standard API to run across a client/host boundary Gallium3D seems like a pretty good choice.

Also if you want to pick up a team familiar with 3D on Linux there's probably nobody better in the world.

Just a thought.

[Louise]

If you wanted a single, standard API to run across a client/host boundary Gallium3D seems like a pretty good choice.

Also if you want to pick up a team familiar with 3D on Linux there's probably nobody better in the world.

Just a thought.

Do you mean that the client should talk directly to the GPU, and not having to go though the hyper visor?

That sounds very dangerous from a security point of view. Wouldn't it be possible to have the GPU write to memory outside of the client address space?

But very interesting, if that is indeed what they are doing

[bridgman]

Definitely would have to go through the hypervisor and have contents checked; the question is just *what* goes through the hypervisor.

This is all just idle speculation, I'm not in on the secret plan or anything.

[Louise]

Definitely would have to go through the hypervisor and have contents checked; the question is just *what* goes through the hypervisor.

This is pretty complicated stuff

Should there then be a Gallium3D driver on the host, that then would act like a hypervisor for 2D/3D calls?

There exist network cards that are aware that there is running virtual guests on the host, so the network card can't be used to do code injection by DMA.

If they exposed the GPU, I would think that it would be possible to have shaders to write anywhere in memory.

...Unless they encrypted and hashed the memory and page tables

This is all just idle speculation, I'm not in on the secret plan or anything.

But a very cool guess.

Let's just hope, that they don't finish the new Gallium3D API, before we have stable 3D drivers

[bridgman]

This is pretty complicated stuff

Should there then be a Gallium3D driver on the host, that then would act like a hypervisor for 2D/3D calls?

There exist network cards that are aware that there is running virtual guests on the host, so the network card can't be used to do code injection by DMA.

If they exposed the GPU, I would think that it would be possible to have shaders to write anywhere in memory.

The problem with 3D is that (a) client programs use it a lot, and (b) it's one of the places where letting the client program get to the hardware is almost totally impractical from a performance POV. That kind of implies drivers which are aware that they are running on a virtualized system.

The current DRM already checks register accesses and buffer locations before allowing a command packet to get through to the hardware. As the stack transitions to using a common memory manager and passing handles rather than pointers the checking should get easier.

The buffer checking code is mostly here (for 6xx/7xx anyways) : http://cgit.freedesktop.org/~agd5f/d...h=r6xx-r7xx-3d

[Louise]

The problem with 3D is that (a) client programs use it a lot, and (b) it's one of the places where letting the client program get to the hardware is almost totally impractical from a performance POV. That kind of implies drivers which are aware that they are running on a virtualized system.

Oh yeah, the GPU resources would need to managed...

Maybe they have found away to talk to each core, so e.g. one guest gets 50 of the GPU cores?

The current DRM already checks register accesses and buffer locations before allowing a command packet to get through to the hardware. As the stack transitions to using a common memory manager and passing handles rather than pointers the checking should get easier.

Now VMware is getting ideas

I wonder how Red Hat feels about all this. They bought Qumranet last year, which are best known for KVM.

But Red hat also got Solid ICE, which virtualizes Linux and Windows desktops.

http://www.qumranet.com/products-and-solutions

Maybe VMware are afraid of what Red Hat will be able to deliver???

[deanjo]

Maybe VMware are afraid of what Red Hat will be able to deliver???

From the few time's I've chatted with vmware dev's they seem to be more concerned about Xen then any other solution.