Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 23

Thread: OpenCL, OpenGL 3.1 State Trackers "Hopefully Soon"

  1. #11
    Join Date
    Aug 2007
    Posts
    6,646

    Default

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

  2. #12
    Join Date
    Mar 2009
    Posts
    20

    Default

    Quote Originally Posted by remm View Post
    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.

  3. #13
    Join Date
    Sep 2008
    Posts
    270

    Default

    Quote Originally Posted by remm View Post
    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.

  4. #14
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,543

    Default

    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.

  5. #15
    Join Date
    May 2008
    Posts
    598

    Default

    Quote Originally Posted by bridgman View Post
    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
    Last edited by Louise; 05-17-2009 at 02:12 PM. Reason: Wrote "host" ment "client".

  6. #16
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,543

    Default

    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.

  7. #17
    Join Date
    May 2008
    Posts
    598

    Default

    Quote Originally Posted by bridgman View Post
    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

    Quote Originally Posted by bridgman View Post
    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

  8. #18
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,543

    Default

    Quote Originally Posted by Louise View Post
    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
    Last edited by bridgman; 05-17-2009 at 03:32 PM.

  9. #19
    Join Date
    May 2008
    Posts
    598

    Default

    Quote Originally Posted by bridgman View Post
    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?

    Quote Originally Posted by bridgman View Post
    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???

  10. #20
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,587

    Default

    Quote Originally Posted by Louise View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •