Announcement

Collapse
No announcement yet.

Running The Xorg State Tracker On R300 Gallium3D

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

  • Running The Xorg State Tracker On R300 Gallium3D

    Phoronix: Running The Xorg State Tracker On R300 Gallium3D

    Yesterday I mentioned that, thanks to new patches on the Mesa mailing list, it's now possible to use the R600 Gallium3D driver with the Xorg state tracker. This means that for all modern ATI/AMD Radeon GPUs (anything newer than the Radeon HD 2000 series), the Xorg state tracker can be used for EXA and X-Video/XvMC acceleration rather than relying upon any DDX driver. The xf86-video-ati driver can be tossed away, while the R300 Gallium3D driver (supporting up through the Radeon X1000 GPUs) has already supported this state tracker, but how well does it work?..

    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
    Do the drivers need to support specific state trackers?

    I thought the Gallium3D idea was that a single generic driver can automatically accelerate all and any state tracer.

    Comment


    • #3
      Originally posted by zoomblab View Post
      Do the drivers need to support specific state trackers?

      I thought the Gallium3D idea was that a single generic driver can automatically accelerate all and any state tracer.
      In theory, there is no difference between theory and practice. In practice, there is.

      I think that the realistic situation is that any driver can support any and all state trackers with a little bit of work (instead of a complete rewrite).

      Don't forget that few (if any) drivers and state trackers are completely mature.

      Comment


      • #4
        I though, "ah, I think that article should be interesting." *click*

        I read through all the build-up and then it ends abruptly with "it was buggy."

        Comment


        • #5
          Originally posted by mattst88 View Post
          I though, "ah, I think that article should be interesting." *click*

          I read through all the build-up and then it ends abruptly with "it was buggy."
          Welcome to Phoronix

          Comment


          • #6
            Originally posted by pingufunkybeat View Post
            In theory, there is no difference between theory and practice. In practice, there is.

            I think that the realistic situation is that any driver can support any and all state trackers with a little bit of work (instead of a complete rewrite).

            Don't forget that few (if any) drivers and state trackers are completely mature.
            This is precisely why generic architectures and APIs almost never work as advertised in the open source world.

            Step 1: Someone comes up with a great, generic API for wrangling a bunch of drivers / backends / etc.

            Step 2: A bunch of different people implement hardware or use case-specific backends.

            Step 3: A bunch of other people (who may or may not care about certain individual backends) use the frontend of the API or architecture.

            Step 4: Hilarity ensures, with XYZ frontend calling completely untested (or unimplemented) APIs that ABC backend developer never needed for their purposes.

            If the backend isn't 100% complete, mature and stable, then the architecture is almost useless: you end up patching every single backend that you want to work with your new frontend, or else it just doesn't work. The problem has traditionally been that the backends just aren't complete.

            Example applications of this process:

            * When PulseAudio went to time-based scheduling, 90% of ALSA drivers couldn't handle the API calls that PA was making, because nobody else had ever depended upon those APIs before, so those paths in the drivers were untested, resulting in tons of bugs. ALSA developers even realized that the semantics of some APIs are undefined or unclear or should be made more stringent.

            * The Gallium3d OpenVG state tracker uses the hardware-specific backends in ways that are (of course) only supported by the hardware the developer tested on.

            * Ditto for Clover / hardware OpenCL yet-to-come.

            * Ditto for Xorg state tracker.

            The only semi-reliable state tracker that should work on most of the Gallium3d drivers today is the desktop GL 2.1 state tracker. Even the most incomplete g3d drivers support that API as well as could be expected for alpha-quality software. For the remainder of the fantastical state trackers that are in development, all bets are off. And Murphy, that guy who likes to make things go wrong, will ensure that every single state tracker written will require a major refactoring, reimplementation, or extension of every driver backend. They just don't make this stuff easy.

            I'm a fan of clean layering in software architecture, but we're basically trying to build the roof of a house where only two walls have actually been built, and the foundation has random missing bricks here and there. It's just not going to hold up. Tack on the fact that folks who fill in the foundation couldn't care less about what people building the roof are doing (and vice versa; people building the roof couldn't care less about the foundation), and it's a recipe for disaster. The only house that's cohesive to any appreciable degree (and even here, it's very shoddy and incomplete for all drivers except r300g) is the GL 2.x pipeline.

            Comment


            • #7
              If this is the future, it is one more focused break point. Currently if there's a mesa bug, you still have 2d, can surf the web, play movies etc. If the 2d driver depended on mesa, your only backup would be the vesa driver == no movies or other 2d-accel use.

              Comment


              • #8
                Mhm. I thought it depends on how much of the Gallium API is actually implemented in a particular driver (all of which are work in progress..)?!

                Comment


                • #9
                  Originally posted by curaga View Post
                  If this is the future, it is one more focused break point. Currently if there's a mesa bug, you still have 2d, can surf the web, play movies etc. If the 2d driver depended on mesa, your only backup would be the vesa driver == no movies or other 2d-accel use.
                  Fair point, but probably worth mentioning that the mesa stack is somewhere around a million lines of code while the Gallium3D HW layer is much smaller, maybe 20,000 LOC for any one GPU including pipe and winsys (I haven't counted recently, last time I looked it was just over 10,000). AFAIK the Xorg state tracker only uses the Gallium3D HW layer, not the rest of mesa.

                  There is a chicken-and-egg aspect here, in the sense that if the only thing exercising the Gallium3D driver is the GL state tracker in mesa then realistically that is also the only thing that the Gallium3D driver is likely to work with.

                  Adding other "clients" (video decode, xorg state tracker) and keeping them in a working state allows the core HW driver bits to be exercised more ways and over time that should result in a more broadly useful driver (ie if you have one working client then adding a second is almost always likely to fail, but if you have 5 then there's a pretty good chance that the 6th will work with little or no change in the underlying driver).
                  Test signature

                  Comment


                  • #10
                    Originally posted by not.sure View Post
                    Mhm. I thought it depends on how much of the Gallium API is actually implemented in a particular driver (all of which are work in progress..)?!
                    The driver has to be able to handle any commands the state tracker creates, which can sometimes be an issue. Even if the driver should have support, sometimes a new state tracker will use it in different ways that hadn't previously been tested.

                    Also, i think several of the state trackers have hooks - some of these are optional, but others may not be. The point is to allow drivers to be able to do what they need to, while allowing the state tracker to handle all the generic stuff.

                    If you look at the commit that added support for r600g, i think there was only about 100 lines or so of C code. Then another 100 or so of changes in the makefiles to get everything building correctly, since this has to create a new .so library, etc.

                    Comment

                    Working...
                    X