Announcement

Collapse
No announcement yet.

Progress On The Gallium3D State Tracker For Cairo

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

  • Progress On The Gallium3D State Tracker For Cairo

    Phoronix: Progress On The Gallium3D State Tracker For Cairo

    Last month we reported on the initial work being done to the Gallium3D state tracker to accelerate Cairo as part of this year's X.Org Google Summer of Code project. Since then there's been more progress by Igor Trindade Oliveira, the GSoC student developer working on this state tracker...

    http://www.phoronix.com/vr.php?view=ODQwNg

  • #2
    Doesn't the current Nouveau stack accelerate Cairo at all?

    Comment


    • #3
      Originally posted by cl333r View Post
      Doesn't the current Nouveau stack accelerate Cairo at all?
      yes and no. Cairo can use several backends, for example X11 or OpenGL. If nouveau accelerates those APIs, cairo is accelerated.

      The G3D state tracker is a means to bypass the intermediate API, because neither X11 noch OpenGL were made for drawing vector graphics. Going directly to the G3D driver could yield better performance.

      Comment


      • #4
        Gallium for gecko and webkit

        mmmh... would it be better to have a gallium state tracker for the 3D/video layer of the web rendering engines (gecko and webkit)? Since at the end, their entire graphic stack will be built on 3D?

        Comment


        • #5
          Originally posted by sylware View Post
          mmmh... would it be better to have a gallium state tracker for the 3D/video layer of the web rendering engines (gecko and webkit)? Since at the end, their entire graphic stack will be built on 3D?
          No I don't think that's a good idea. If you want to use a 3D API which is cross-platform, has many implementations and widespread usage, OpenGL is really the only choice. Leave Gallium as a back-end for certain graphics libraries, and not use it by apps directly.

          As for the html 5 video element, Clutter really looks like the perfect fit for this. As it allows for overlaying graphics over video textures, as required for usage in html. And with the work of gbeauchesne on clutter-gst, there's also hardware accelerated video decoding available.

          Comment


          • #6
            backends of web renderer 3D engines

            Originally posted by monraaf View Post
            No I don't think that's a good idea. If you want to use a 3D API which is cross-platform, has many implementations and widespread usage, OpenGL is really the only choice. Leave Gallium as a back-end for certain graphics libraries, and not use it by apps directly.
            well, I don't really agree. I can see that opengl backend for the "futur to be" web renderer 3D engine is mandatory. I can also see that avoiding opengl kludge by directly going through Gallium3D (or other similar yet te be APIs) can become a significant advantage.

            The "only" requirement, is a clean backend interface for the futur web renderer 3D engines. I bet those 3D engines will be different from one web renderer to another:webkit/chromium webkit/gecko.

            Comment


            • #7
              Originally posted by rohcQaH View Post
              yes and no. Cairo can use several backends, for example X11 or OpenGL. If nouveau accelerates those APIs, cairo is accelerated.

              The G3D state tracker is a means to bypass the intermediate API, because neither X11 noch OpenGL were made for drawing vector graphics. Going directly to the G3D driver could yield better performance.
              I see, thanks, btw, German weder noch == English neither nor.

              Comment


              • #8
                Originally posted by sylware View Post
                well, I don't really agree. I can see that opengl backend for the "futur to be" web renderer 3D engine is mandatory. I can also see that avoiding opengl kludge by directly going through Gallium3D (or other similar yet te be APIs) can become a significant advantage.
                I don't see that as a kludge. Just different layers of code, that have different purposes. I'm not sure what the advantages of using Gallium3D directly over using the OpenGL state tracker would be. I can only see the disadvantage of targeting an API that will most likely only be supported by a small subset of hardware drivers compared to OpenGL.

                If the advantage would be performance, then there's definitely something wrong with the Gallium3D design.

                Comment


                • #9
                  Originally posted by monraaf View Post
                  I don't see that as a kludge.
                  Then our choices are very different. It will be near impossible to agree.

                  Originally posted by monraaf View Post
                  I'm not sure what the advantages of using Gallium3D directly over using the OpenGL state tracker would be.
                  Since mesa opengl will be built an Gallium3D, that means opengl is klugde or should be seen as a *compatibility layer*. It means less code then it means better.

                  Originally posted by monraaf View Post
                  I can only see the disadvantage of targeting an API that will most likely only be supported by a small subset of hardware drivers compared to opengl.
                  ? Gallium3D will be the hardware driver for mesa/opengl.

                  Originally posted by monraaf View Post
                  If the advantage would be performance, then there's definitely something wrong with the Gallium3D design.
                  "mesa opengl on top of Gallium3D is in development and still slow", this is more accurate. Would be nice to have a 3D engine directly coded on Gallium3D and with manually coded shaders (for recent hardware).

                  Comment

                  Working...
                  X