Results 1 to 9 of 9

Thread: Progress On The Gallium3D State Tracker For Cairo

  1. #1
    Join Date
    Jan 2007
    Posts
    13,429

    Default 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. #2
    Join Date
    Oct 2009
    Posts
    353

    Default

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

  3. #3
    Join Date
    Nov 2008
    Posts
    755

    Default

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

  4. #4
    Join Date
    Dec 2008
    Posts
    166

    Default 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?

  5. #5
    Join Date
    Dec 2008
    Posts
    980

    Default

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

  6. #6
    Join Date
    Dec 2008
    Posts
    166

    Default backends of web renderer 3D engines

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

  7. #7
    Join Date
    Oct 2009
    Posts
    353

    Default

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

  8. #8
    Join Date
    Dec 2008
    Posts
    980

    Default

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

  9. #9
    Join Date
    Dec 2008
    Posts
    166

    Default

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

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

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

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

Posting Permissions

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