Announcement

Collapse
No announcement yet.

Gallium3D Drivers Might Lose The EGL State Tracker, OpenVG

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

  • Gallium3D Drivers Might Lose The EGL State Tracker, OpenVG

    Phoronix: Gallium3D Drivers Might Lose The EGL State Tracker, OpenVG

    Marek Ol??k this week volleyed a controversial proposal to effectively knock off the EGL state tracker for Gallium3D drivers...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I forgot openVG exists.

    Does anyone use it?

    Comment


    • #3
      Originally posted by peppercats View Post
      I forgot openVG exists.

      Does anyone use it?
      No, which is why they're getting rid of this.

      There are OpenVG on top of OpenGL implementations out there for the people who really want to play around with it.

      Comment


      • #4
        Cairo can use OpenVG. Not sure that anyone uses that feature though.

        Comment


        • #5
          My feeling is the Cairo OpenVG backend never really became popular because it is only usable with the egl_gallium EGL driver which means even for Gallium based systems it wouldn't be available with the egl_dri2 EGL driver being preferred by distributions/users. I think that extends over to OpenVG on Linux as a whole. Who doesn't want accelerated vector graphics? But if no end-user is ever likely to have it available, what's the point? May as wel shoe-horn OpenGL for the purpose or use Cairo with a less capable backend, at least it works.

          Still, it doesn't have to be that way. If somebody would step up to maintain the Linux OpenVG stack, port Vega to egl_dri2, it's possible that would make it more popular, and certainly would make the Cairo backend more practical. Any takers? I'm always taking on too many things and never getting enough done or I would take up the challenge myself... ...if only days were longer...

          Comment


          • #6
            OpenVG could be used to improve rendering performance of image viewers rendering svg and other vector graphics, right?

            Because that's an area where improvements are sorely needed. Just open any big/complex vector graphic in eog/gwenview/whatever and zoom in and pan around. It's really slow right now.

            Comment


            • #7
              Originally posted by haagch View Post
              OpenVG could be used to improve rendering performance of image viewers rendering svg and other vector graphics, right?

              Because that's an area where improvements are sorely needed. Just open any big/complex vector graphic in eog/gwenview/whatever and zoom in and pan around. It's really slow right now.
              Yes, but unfortunately there doesn't really seem to be any interest...
              Last edited by s_j_newbury; 08 November 2014, 10:23 AM.

              Comment


              • #8
                Originally posted by s_j_newbury View Post
                Who doesn't want accelerated vector graphics? But if no end-user is ever likely to have it available, what's the point? May as wel shoe-horn OpenGL for the purpose or use Cairo with a less capable backend, at least it works.
                The thing is Linux graphic stack has already been accelerated through XRender, GLAMOR or cairo-gl (Wayland).
                There is no need switching to OpenVG unless you really like OpenVG's API.

                Comment


                • #9
                  Originally posted by zxy_thf View Post
                  The thing is Linux graphic stack has already been accelerated through XRender, GLAMOR or cairo-gl (Wayland).
                  There is no need switching to OpenVG unless you really like OpenVG's API.
                  XRender, which EXA, UXA, SNA, and GLAMOR -among others- implement, is a dead end, because -as its name suggests- it's tied to X, and [because] it's the server who, in behalf of the client, draws. Aside from other reasons (maybe synchronisation?), such design is bad because it ties together things that aren't necessary bound - what does the compositor have to do with the rendering method, as long as it understands its output? XRender has been a "poison" because of the effort duplication that it has caused: graphics code not only had to be developed and maintained in Mesa, but also in each XRender implementation - think of a possible specialized OpenVG implementation ? la SNA and SNA itself. Now, if XRender wasn't X-specific -it would be something like "OpenRender"-, which would mean that its implementations were in Mesa (just as OpenGL implementations), it would be OK - and it would have surely been dropped, because its interface doesn't match today's needs, as was pointed out in the past (I believe there were some explanations, but don't remember where...). So XRender is not a good 2D acceleration and should already be abandoned - both Cairo and OpenVG work in X, without being tied to it.

                  Cairo is a wrapper that still needs backends. The OpenGL one works fine, but... ??

                  Now, about OpenVG itself, it hasn't been adopted -at least in the desktop-. I don't know why; I have just glanced over it, but I'm not a developer. Perhaps most are just using Cairo and other wrappers, and, because Cairo works fine with its OpenGL backend, there was no interest. Maybe it's a bad API. I wonder, however, if 2D things could be made faster by switching to it.
                  Last edited by kalrish; 10 November 2014, 05:23 PM.

                  Comment

                  Working...
                  X