Announcement

Collapse
No announcement yet.

OpenCL, OpenGL 3.1 State Trackers "Hopefully Soon"

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    But you want Aero too in VMs, don't you

    Comment


    • #12
      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.

      Comment


      • #13
        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.

        Comment


        • #14
          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.

          Comment


          • #15
            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, 01:12 PM. Reason: Wrote "host" ment "client".

            Comment


            • #16
              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.

              Comment


              • #17
                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

                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

                Comment


                • #18
                  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, 02:32 PM.

                  Comment


                  • #19
                    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?

                    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???

                    Comment


                    • #20
                      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.

                      Comment

                      Working...
                      X