Announcement

Collapse
No announcement yet.

Mesa / Gallium3D Branch Happenings

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

  • #16
    Originally posted by bridgman View Post
    For a Linux distro to use Gallium3D by default, I don't think anything else is required other than some proven history of it actually working.
    Are you implying that everything is already implemented what is needed to have a running OS atop Gallium3D? Obviously, with only the r300g driver and with keeping in mind that these things are experimental(=buggy).

    Comment


    • #17
      Originally posted by HokTar View Post
      Are you implying that everything is already implemented what is needed to have a running OS atop Gallium3D? Obviously, with only the r300g driver and with keeping in mind that these things are experimental(=buggy).
      I think that's what he just implied...

      I'm about to sacrifice a machine to verify that premise. While I wouldn't expect it to work robustly at this time, a non-production machine test to feed them info on bugs, etc. would be useful for everyone in the community if it's at that stage now.

      Comment


      • #18
        Well, it's a good idea. Basically, this is why I asked.
        Since as far as I know, there are no Ubuntu test packages to try, nor for any other distro, I assumed that it is in "an absolutely-not-working, only-developers-can-play-with" state. But bridgman's reply suggests otherwise, which would be awesome!

        OK, one can get the bits from various git sources, but I'm too lazy at the moment...

        Comment


        • #19
          Thank for the answer Bridgman

          Comment


          • #20
            Just to be clear, I wasn't implying anything about the stack "just working"-- the r300g driver is progressing nicely but AFAIK all of the testing so far has been with the 3D state tracker. A "finished" Gallium3D driver should work equally well with all of the state trackers but an "under development" driver has every chance of working with one state tracker and blowing up with a different state tracker, since the state trackers are likely to use the interface in ways which have not yet been tested and beaten into a working state.

            Originally posted by HokTar View Post
            I assumed that it is in "an absolutely-not-working, only-developers-can-play-with" state. .
            That is my assumption as well. All the pieces exist and are under development, but I would be surprised if they "just worked" together without some developer attention. Then again we weren't expecting that people would play games on Richard's "still working on getting the basic tests to pass" GLSL code either

            Originally posted by HokTar View Post
            But bridgman's reply suggests otherwise, which would be awesome!.
            That was not my intention, and after re-reading a few times I still don't see where that suggestion was hiding in my post
            Last edited by bridgman; 12-10-2009, 11:50 AM.

            Comment


            • #21
              Originally posted by bridgman View Post
              ...I still don't see where that suggestion was hiding in my post
              Well, the part:
              "proven history of it actually working"
              was something that gave me the impression. It sounds as if developers would think it's OK, but distro-makers don't believe so. :P

              Thanks for the clarification, now I think I have a better understanding of the current state. Please keep us posted!

              In the meantime I can't wait the power-management to arrive into the next kernel!

              Comment


              • #22
                Originally posted by bridgman View Post
                I think the main use of the softpipe driver is as a "reference" platform so that (a) upper level functionality can be built and tested without having to wait for hardware drivers, and (b) if there is a question about the behaviour of a specific hw driver it can be compared to the softpipe reference rather than having to find different hardware for A/B testing.

                From a user point of view, however, unless there is a good hw driver for your card then you shouldn't be planning to use Gallium3D, although the llvmpipe driver might be turn out to be interesting if you have a big honkin' CPU and weak graphics.
                Softpipe is the safety net. Not every GPU is going to come in at once. As long as theres a soft pipe they can finish without waiting for a billion ducks to get in a row. Some of those cards are probably being 4 and 5 times more work than the "average" gpu.

                Comment

                Working...
                X