Announcement

Collapse
No announcement yet.

Intel's UXA Will Not Be Merged Back Into EXA

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

  • #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.
    Test signature

    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


            • #16
              Ohm, sorry, what are you talking about?

              Comment

              Working...
              X