Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

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

  1. #11
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,543

    Default

    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.

  2. #12
    Join Date
    Aug 2008
    Location
    Tokyo, Japan
    Posts
    38

    Default

    Quote 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. )

  3. #13
    Join Date
    Sep 2006
    Posts
    714

    Default

    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.

  4. #14
    Join Date
    Jan 2008
    Posts
    206

    Default

    Quote 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

  5. #15
    Join Date
    Aug 2008
    Posts
    233

    Default

    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.

  6. #16
    Join Date
    Jan 2008
    Posts
    206

    Default

    Ohm, sorry, what are you talking about?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •