Announcement

Collapse
No announcement yet.

GLAMOR 0.5 To Advance 2D Over OpenGL

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

  • #21
    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).

    Comment


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

      Comment


      • #23
        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.

        Comment


        • #24
          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.

          Comment

          Working...
          X