Announcement

Collapse
No announcement yet.

Gallium3D Picks Up Networking Support

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

  • Gallium3D Picks Up Networking Support

    Phoronix: Gallium3D Picks Up Networking Support

    The folks at Tungsten Graphics, which are owned by VMware, have been busy with new software releases so far this summer. Mesa 7.5 is coming along well and the Gallium3D driver architecture is now merged into the Mesa mainline code-base for release with Mesa 7.6...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Heh, I have to admit, the first thing that leapt to my mind was a quote from jwz "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can".

    Still, this seems to be very useful. The easiest way to hang a Linux system and needing to force a reboot today is to simply start up a random 3D application or game. Anything which helps developers track down these bugs is a good thing.

    Comment


    • #3
      i understand that this is only for debugging now

      but... (it's going to be a silly question)




      is it possible to give remote desktop capabilities to any system using gallium by expanding this??

      Comment


      • #4
        Originally posted by 89c51 View Post
        i understand that this is only for debugging now

        but... (it's going to be a silly question)

        is it possible to give remote desktop capabilities to any system using gallium by expanding this??
        I'm not quite sure this would give you the ability to do that, and I don't think you'd necessarily want to do it through gallium (the X11 protocol already allows forwarding X11 applications, and VNC or similar can do desktop forwarding).

        That being said, I guess it would be possible to run the shaders on one machine, and then dump the results over the network to be processed/absorbed by another machine... but I have a feeling it would suck up network bandwidth to the point of being unusable. You'd probably be better off running an OpenCL-based application on each remote machine, and then dumping the final (not intermediate) results to a file for either transfer to a local machine, or saved to an exported share.

        Comment


        • #5
          These network functions are not being deployed so that you can create a Multi-GPU configuration over a high-bandwidth LAN or anything exotic like that, but actually to provide a remote debugging utility.
          Now, someone please say this is possible in the future

          Comment


          • #6
            Originally posted by curaga View Post
            Now, someone please say this is possible in the future
            Not in the foreseeable future. Network connections just don't have enough bandwidth to do that with nowadays video cards (even 10Gb/s is nothing compared to the bandwidth of a PCIe 16x link).
            Unless there's an amazing growth in network bandwidth, together with an implausible stall in video card computational power, I don't see this happening ever.

            Comment


            • #7
              Could this help to be able to use more than one GPU at a time? There are many multi-GPU enviroments out there, two chips on a card, or an intel + amd GPU in a laptop. Could gallium3d help out there?

              Comment


              • #8
                Originally posted by bugmenot View Post
                Could this help to be able to use more than one GPU at a time? There are many multi-GPU enviroments out there, two chips on a card, or an intel + amd GPU in a laptop. Could gallium3d help out there?
                That's nothing Gallium3D is responsible for... Gallium3D just provides drivers with implementations for any API (like OpenGL, OpenCL, DirectX, video decoders, etc) it supports and nothing more. This stuff is just a change in architecture which allows for easier debugging, anything which has to do with multi-GPU setups is left to the drivers.
                That said, I don't think we're anywhere near the point, where two GPUs of different vendor can work together. We first would need some common interface to make that work (uhm, wait, I think I even heard of something like that before) and then make the drivers compatible with it. That would probably yield the same amount of work and invasive changes like the currently ongoing work on KMS/DRI2/Gallium3D and.. honestly said, not really /that/ useful. Anyone who really needs two GPUs will buy GPUs of the same vendor and use the corresponding binary blob which is tuned for such applications.

                Comment


                • #9
                  my first guess was GPU network acceleration. this kind of thing http://en.wikipedia.org/wiki/TCP_Offload_Engine

                  remote debugging is cool. one of the xorg devs handheld me through running X in gdb via an ssh session, because the lockup was hard enough that log files did not get written to disk.

                  Comment


                  • #10
                    the car is not able to move yet, but, let us give it 5 wheels!

                    Comment

                    Working...
                    X