Announcement

Collapse
No announcement yet.

GLAMOR 0.5 To Advance 2D Over OpenGL

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

  • #16
    Originally posted by entropy View Post
    What's the plan for 2d on SI+ then?
    I thought it should be just Glamor (apart from ShadowFB).
    The plan is pretty simple -- get the 3D driver working (there's been some good progress in the last week), see how Glamour works on SI, if it's sucky try to make it better, and if making it better doesn't go well (ie if we conclude that Glamour isn't ready for "prime time" yet) then look into alternatives. It just seems that since most of the toolkits are running directly over OpenGL then doing the same with the X driver has to be the right thing at some point, and it seems like that point is probably kinda now-ish.

    Comment


    • #17
      Originally posted by bridgman View Post
      The plan is pretty simple -- get the 3D driver working (there's been some good progress in the last week), see how Glamour works on SI, if it's sucky try to make it better, and if making it better doesn't go well (ie if we conclude that Glamour isn't ready for "prime time" yet) then look into alternatives. It just seems that since most of the toolkits are running directly over OpenGL then doing the same with the X driver has to be the right thing at some point, and it seems like that point is probably kinda now-ish.
      As a small counter to all the silly negative feedback you guys get around here, I think you're doing an awesome job and am very happy you communicate directly with the community.

      People need to stop acting like its the end of the world because bridgeman didn't do 9 years of dev work by himself, using his probably non-existant open source mobile phone, jury rigged to his windows only supported modem.

      /me is happy getting well over 100fps with my 5850 and open drivers. Keep up the good work Radeon dev guys.

      Comment


      • #18
        Originally posted by bridgman View Post
        The plan is pretty simple -- get the 3D driver working (there's been some good progress in the last week), see how Glamour works on SI, if it's sucky try to make it better, and if making it better doesn't go well (ie if we conclude that Glamour isn't ready for "prime time" yet) then look into alternatives. It just seems that since most of the toolkits are running directly over OpenGL then doing the same with the X driver has to be the right thing at some point, and it seems like that point is probably kinda now-ish.
        This sounds promising and a bit different from what I read before.
        Thanks for sharing!

        Since ownagefool has the impression that there's negative feedback all over the place,
        I might add that I do appreciate the work done by the FOSS devs.

        Comment


        • #19
          Hello,

          I would be interested to hear about the reasons why the GLAMOR architecture was chosen for 2D acceleration instead of the xorg or xa state tracker. The last time I was trying out the xorg state tracker the experience wasn't too bad although there were some glitches. Are there any advantages GLAMOR offers over the mentioned state tracker or is it simply that two Intel developers are working on the GLAMOR architecture? It's seems to been a while since there was any work done on the xa state tracker.

          Comment


          • #20
            This has been discussed in more detail in other threads, but agd5f's last comment was basically that the state trackers were based on EXA and so would have all the same limitations EXA does in the native X driver, while Glamor didn't start with the same restrictions.

            My view was a bit less technical -- given that toolkits and apps are increasingly running over OpenGL, it seems like a good time to start doing the same with X

            Comment


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

                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