Announcement

Collapse
No announcement yet.

Intel's UXA Will Not Be Merged Back Into EXA

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

  • Intel's UXA Will Not Be Merged Back Into EXA

    Phoronix: Intel's UXA Will Not Be Merged Back Into EXA

    Back in August we talked about the UXA acceleration architecture, which was developed by Intel and based upon EXA but pixmaps were dealt with as GEM objects. A month later at the X Developers' Summit, Keith Packard had clarified his UXA work. At that time he said the information learned from UXA would work its way back into EXA by separating the pixmap management and acceleration components of EXA...

    http://www.phoronix.com/vr.php?view=NzA0NQ

  • #2
    I don't think this is soo bad. It's a bit like the thing with radeon/radeonhd: The advantage of radeonhd is that it supports less hardware and so it is smaller, smarter and more compact. And if it's a new accel technology, why not. Even if it's in fact only an extended EXA. And even (or just because) if it's only useful for IGPs.

    Comment


    • #3
      I'd be curious as to the architectural reasons why, but I suppose we have to wait for the videos/minutes.

      Comment


      • #4
        I'd be curious as to the architectural reasons why, but I suppose we have to wait for the videos/minutes.
        Probably because there isn't any point in merging it back into the EXA drivers.

        Just like it was pointless to try to take the existing legacy EXA DDX stuff and extend it to create a functional equivalent to UXA, it's pointless to try to backport UXA into EXA legacy DDX.

        If UXA works, then why should you give a darn about sucking it into EXA? Just use UXA. Done. Get rid of EXA completely, throw it down the bit-bin of history... The EXA API was sort of designed, on purpose, to be driven by 3D graphics hardware and have a relatively short life as a 2D driven API. I think most X.org people understood that 2D hardware in Video cards is a dying thing... even modern cards with 2D hardware the 2D cores are essentially unchanged from when they were originally designed back in the Gefore 256 days (circa 1999).

        As far as programs go it shouldn't matter. Both implement the EXA API, so programs and end users shouldn't give a darn one way or the other. The only way it would matter to end users is if they experience a difference in performance and/or reliability.

        Comment


        • #5
          They never intended to help out other drivers by improving EXA incrementally. I could have told you this the moment Intel started putting
          Code:
          #if I830_USE_UXA
          into their driver. This showed they considered EXA and UXA distinct frameworks.

          Comment


          • #6
            Originally posted by drag View Post
            ...If UXA works, then why should you give a darn about sucking it into EXA? Just use UXA. Done...
            In it of itself, I don't. I don't advocate endless support of hardware (especially since the power/performance/energy cost ratios might suggest some is cheaper to replace), but there is plenty of capable hardware out there for general applications, and as I see plenty of these interesting new features being implemented I wonder how that older hardware could benefit. IE - would improved 2D performance on an older system mean my computer is relevant just a little longer, or that CPU performance can be put to more useful purpose. So when new APIs are implemented it tends to leave older drivers behind...

            I don't want to hinder progress, new features, and all of Intel's great work. I'm not even pretending to have a full understanding of the implications. I just was posing the question because I was curious, and trying to see the bigger picture.

            Comment


            • #7
              Originally posted by drag View Post
              If UXA works, then why should you give a darn about sucking it into EXA? Just use UXA. Done. Get rid of EXA completely, throw it down the bit-bin of history...
              I think the point is that UXA only works for integrated graphics processors where video memory = system memory. You would still need EXA for GPUs with dedicated video memory.

              Comment


              • #8
                Originally posted by bugmenot View Post
                Even if it's in fact only an extended EXA.
                Actually, it's a stripped down EXA. The sad thing is that the main benefit of UXA (storing pixmaps in buffer objects) could already be done with EXA before UXA existed, and the parts they stripped from EXA would be inactive anyway in that case. There are academic problems with the EXA driver interfaces for this, but I think it would have been better to fix those than to create yet another acceleration architecture. Why they chose differently is anyone's guess.

                Comment


                • #9
                  So that Intel has a lead since their drivers now use UXA.

                  Comment


                  • #10
                    As far as I understand, the only advantage of UXA is that IGPs don't have to make an extra copy. For discrete cards, it offers no real advantages that can't be done with EXA.

                    Also, saying that 2d acceleration is on the way out is kind of silly. It may be true in the future that 2d will be treated simply as a subset of 3d, but that doesn't mean it will go away. There are still servers and other applications that don't need 3d, but do need fast 2d (for UI.)

                    Comment


                    • #11
                      Yep; 2D engines may be on their way out but most of our interaction with PCs is still via 2D metaphors (screen representations of paper documents etc..) and those will continue to rely heavily on 2D acceleration APIs.

                      Comment


                      • #12
                        Originally posted by TechMage89 View Post
                        As far as I understand, the only advantage of UXA is that IGPs don't have to make an extra copy.
                        Again, the exact same thing can be done with EXA, since before UXA even existed.

                        (How many times will I have to repeat this? I must be starting to sound like a broken record. )

                        Comment


                        • #13
                          EXA is a programming API designed for 2D acceleration for applications on your desktop.

                          UXA is a GEM-based implementation of the EXA API. So the fact that UXA can't do anything more then the old EXA drivers is because that is by design. The EXA API dictates what you can do and both do it.


                          However with UXA being based on GEM this will lead to much simplier and more effective ways to make your 2D application world work with video acceleration and 3D acceleration methods.

                          For example:

                          A composited desktop, like what Compiz uses has your 2D applications render to a off-screen buffer and then textures from that offscreen buffer are mapped to the 3D objects that make up the image you see on your display.

                          For the old EXA scheme this means that:
                          1. The application is rendered to the offscreen buffer by your video card.
                          2. The CPU reads the texture data out of the video card memory and into main memory.
                          3. The CPU performs the necessary functions to transform the 2-D image format to a 3-D compatible texture format.
                          4. The system reads the image out of main memory and back into video card memory.
                          5. the image is then mapped to the 3D object.
                          6. The display is rendered.


                          So you have at least 3 different copies of the image in memory. The 2-D object, the 3-D texture object, and then the in memory format for the CPU to process.

                          With UXA scheme you have:
                          1. The application is rendered to the offscreen buffer by your video card.
                          2. The 2D image format is mapped to 3-D object as a texture.
                          3. the display is rendered.


                          So you have 1 copy of the image in video ram and you knock out the cpu-based translation function as well as 2 trips from video to main memory..

                          Each trip takes thousands of cpu cycles. Then you have cache issues with the CPU since each time the cpu has to dump cache your loosing massive amounts of performance.

                          The Intel UXA driver only applies to Intel devices, obviously.
                          However this GEM-backed 2D API scheme will apply to ALL hardware. Nvidia, AMD, Via, etc.


                          They all have the same problems with the current way of doing things... the objects used in the 2D X.org drivers are not compatible with the objects used in any other APIs and each Driver, each API has it's own memory management scheme which is hard and complicated to deal with and coordinate. By moving to a completely GEM-backed way of doing things then it eliminates a lot of complexity and will improve performance.


                          -----------------------


                          The sucky part about is is that this sort of thing will not show up on micro benchmarks. When you do 2D rendering performance testing the UXA stuff shouldn't be that much different then EXA stuff... it'll be slower if anything. And it'll be the same thing for 3D performance benchmarks.. it'll be slower if anything.

                          But if your doing macro benchmarks were you have 3D and 2D and video acceleration being used together on a busy system then the GEM-backed system should not only be very much faster, but it also should be much more stable as it's a much less complex way of doing already very complex things.

                          Comment


                          • #14
                            Originally posted by drag View Post
                            UXA is a GEM-based implementation of the EXA API. So the fact that UXA can't do anything more then the old EXA drivers is because that is by design. The EXA API dictates what you can do and both do it.
                            The main reason people complain here is that UXA and EXA consits mostly of the same code - UXA has a few changes and everything else is mostly thrown-out-code.
                            The problem is basically that with a little work EXA could do exactly the same stuff as UXA, having one code-base with all the accaleration logic instead of two, and if Intel would e.g. fix a bug, everybody could benefit.

                            It looks almost like Intel tries to get some lead ahead others, by taking open-source stuff, forking it, modifying it so that nobody else can't benefit of enhancements they make and maintain it themself.
                            Its the same as with TTM (which had already some drivers implemented) - they just did their own thing.
                            I agree, this is all conspiracy speculation

                            - Clemens

                            Comment


                            • #15
                              Lets see what happens with AMD and Nvidia and the whole Xorg community. I think in the future someone will eventually merge all those things together.

                              Comment

                              Working...
                              X