Page 3 of 3 FirstFirst 123
Results 21 to 24 of 24

Thread: GLAMOR 0.5 To Advance 2D Over OpenGL

  1. #21
    Join Date
    Dec 2009
    Posts
    14

    Default

    Thanks for answering my question! I thought that the state trackers were also using the 3D engine of the graphics card. But I have to admit that I don't have any technical understanding . It's nice to see though that there seems to be at least a common denominator in that respect (assuming that Intel will use GLAMOR some time in the future). Too bad though that Intel isn't interested in Gallium. The lack of ressources is just to obvious and it's sad to see when the spare resources are split into different projects (although at least some parts seem to shareable between classic mesa and Gallium).

  2. #22
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,379

    Default

    The state trackers also use the 3D engine (as does EXA), but apparently make more use of the standard EXA framework. I haven't looked at the Glamor internals but I guess Glamor executes Render operations directly rather than mapping Render operations to EXA functions first.

    Something like that anyways... hopefully one of the devs closer to the ddx code will jump in

  3. #23
    Join Date
    Dec 2007
    Posts
    2,313

    Default

    Quote Originally Posted by MartinS View Post
    Thanks for answering my question! I thought that the state trackers were also using the 3D engine of the graphics card. But I have to admit that I don't have any technical understanding . It's nice to see though that there seems to be at least a common denominator in that respect (assuming that Intel will use GLAMOR some time in the future). Too bad though that Intel isn't interested in Gallium. The lack of ressources is just to obvious and it's sad to see when the spare resources are split into different projects (although at least some parts seem to shareable between classic mesa and Gallium).
    There is no 2D hardware on GPUs anymore. There hasn't been for years (r5xx was the last series with a dedicated 2D engine). Everything uses the 3D engine, the only difference is the intermediate APIs. EXA accelerates 3 operations:
    Solid() - draws solid rectangles (this translates to drawing a solid colored quad using the 3D engine)
    Copy() - copies a rectangle from one surface to another surface (this translates to drawing a textures quad using the 3D engine)
    Composite() - combines a src image with an optional mask image and blends the result with the destination (translates to drawing a multi-textured quad with the 3D engine)
    That's it. Everything else uses software. EXA was designed for early 3D engines (think rage128 and r1xx radeons). RENDER was designed before that and didn't really take into account 3D APIs so it's hard to make the implementation semantically compliant since the hw doesn't work the way RENDER wants it to since 3D APIs have different semantics. If RENDER had better semantics it would be easier to implement on hw. Drivers implement callbacks for those 3 functions sets. Within the callback, they implement what is necessary to translate the EXA API into machine instructions. In the ddx, we translate the EXA state directly into hw instructions. In the gallium state tracker we translate the EXA API into TGSI state and then use the gallium pipe drivers to translate it to hw instructions. The state tracker has the advantage over a native EXA implemention in that it can take advantage of the existing pipe driver to handle hw state and shader compilation. In a native EXA implemenation all of that has to be re-implemented in the ddx which effectively means maintaining two drivers. To support more advanced RENDER features like gradients and trapezoids, EXA needs to be reworked as it currently does not support them (falls back to software rendering).

    Glamor implements RENDER by translating RENDER API into OpenGL API which in turn get translated into hw instructions by the OpenGL driver. Glamor has the following advantages over EXA:
    1. Is implemented in terms of GL which is a more familiar API to most people than TGSI or native hw instructions. This makes it much easier to support new RENDER features and allows you to take advantage of all the work on the 3D driver.
    2. Glamor supports everything EXA does, plus has experimental support for gradients and trapezoids. Going forward it is a better framework for accelerating RENDER.

  4. #24
    Join Date
    Nov 2008
    Location
    Old Europe
    Posts
    904

    Default

    Quote Originally Posted by agd5f View Post
    There is no 2D hardware on GPUs anymore. There hasn't been for years (r5xx was the last series with a dedicated 2D engine). Everything uses the 3D engine, the only difference is the intermediate APIs. EXA accelerates 3 operations:
    Solid() - draws solid rectangles (this translates to drawing a solid colored quad using the 3D engine)
    Copy() - copies a rectangle from one surface to another surface (this translates to drawing a textures quad using the 3D engine)
    Composite() - combines a src image with an optional mask image and blends the result with the destination (translates to drawing a multi-textured quad with the 3D engine)
    That's it. Everything else uses software. EXA was designed for early 3D engines (think rage128 and r1xx radeons). RENDER was designed before that and didn't really take into account 3D APIs so it's hard to make the implementation semantically compliant since the hw doesn't work the way RENDER wants it to since 3D APIs have different semantics. If RENDER had better semantics it would be easier to implement on hw. Drivers implement callbacks for those 3 functions sets. Within the callback, they implement what is necessary to translate the EXA API into machine instructions. In the ddx, we translate the EXA state directly into hw instructions. In the gallium state tracker we translate the EXA API into TGSI state and then use the gallium pipe drivers to translate it to hw instructions. The state tracker has the advantage over a native EXA implemention in that it can take advantage of the existing pipe driver to handle hw state and shader compilation. In a native EXA implemenation all of that has to be re-implemented in the ddx which effectively means maintaining two drivers. To support more advanced RENDER features like gradients and trapezoids, EXA needs to be reworked as it currently does not support them (falls back to software rendering).

    Glamor implements RENDER by translating RENDER API into OpenGL API which in turn get translated into hw instructions by the OpenGL driver. Glamor has the following advantages over EXA:
    1. Is implemented in terms of GL which is a more familiar API to most people than TGSI or native hw instructions. This makes it much easier to support new RENDER features and allows you to take advantage of all the work on the 3D driver.
    2. Glamor supports everything EXA does, plus has experimental support for gradients and trapezoids. Going forward it is a better framework for accelerating RENDER.
    Thanks for the detailed explanation.
    This makes perfectly sense to me - now.

Posting Permissions

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