Announcement

Collapse
No announcement yet.

OpenCL, OpenGL 3.1 State Trackers "Hopefully Soon"

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

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


            • #21
              Originally posted by deanjo View Post
              From the few time's I've chatted with vmware dev's they seem to be more concerned about Xen then any other solution.
              I can understand that. Both Citrix and Novell have quite some cash

              Red Hat supports Xen until 2015 (I think it was), and based on the number of important customers they have there still uses Xen, they will either stop or continue to support Xen.

              But KVM is very cool from a developers stand point. All feaures that are in the kernel, are also in the guest. For free

              Xen is not like that. You have to modify the feature that you want in the guest.

              But Solid ICE, is really something nobody besides Red Hat can offer. So mayby VMware is not afraid of KVM compared to Xen, but they might be about Solid ICE.
              Last edited by Louise; 05-17-2009, 03:10 PM.

              Comment


              • #22
                Ok, so for the "why Tugsten" question, I find the possiblity to virtualize whatever compute resource might be available more convincing that the need to run Aero. At least as a money making plan.

                (of course, Vmware has a lot of cash, and Tugsten has a business of its own, so it could be mostly defensive, maybe to keep it out of RH)

                Comment


                • #23
                  Originally posted by remm View Post
                  Ok, so for the "why Tugsten" question, I find the possiblity to virtualize whatever compute resource might be available more convincing that the need to run Aero. At least as a money making plan.

                  (of course, Vmware has a lot of cash, and Tugsten has a business of its own, so it could be mostly defensive, maybe to keep it out of RH)
                  yes. vmware just wants opencl support to guest so they can sell virtualization solutions for scientists

                  opencl would be nice also for ssl and some other computational expensive server side technologies.

                  Comment

                  Working...
                  X