Announcement

Collapse
No announcement yet.

Mesa Gets Patches For GBM, A Graphics Buffer Manager

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

  • Mesa Gets Patches For GBM, A Graphics Buffer Manager

    Phoronix: Mesa Gets Patches For GBM, A Graphics Buffer Manager

    Benjamin Franzke, a developer who as of the past several months has been hacking on Wayland and working to get it running over OpenWF along with making other improvements, has written a graphics buffer manager (GBM) for Mesa...

    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
    openWFD is a miss type both in the article and on the ml right????

    (considering d and f are close to the keyboard)

    Comment


    • #3
      This library replaces the previous hard-coded EGL calls to create buffers and instead uses Mesa's internal DRI interface and for the Gallium3D drivers it acts as a state tracker.
      Weren't EGL and DRI two different things?

      EGL for resource sharing DRI for drawing?

      Comment


      • #4
        Can someone explain in layman's terms what exactly this adds and how it benefits users? I am not trying to say it is useless, the article is just a bit too technical for me to get a clear picture what is going on.

        Comment


        • #5
          Also could some explain what OpenWF is, in layman terms. Cant find anything that doesn't already assume you know what exactly OpenWF is.

          Comment


          • #6
            Originally posted by 89c51 View Post
            openWFD is a miss type both in the article and on the ml right????

            (considering d and f are close to the keyboard)
            No typo, OpenWFD means OpenWF Display (for modesetting)

            Originally posted by TheBlackCat View Post
            Can someone explain in layman's terms what exactly this adds and how it benefits users? I am not trying to say it is useless, the article is just a bit too technical for me to get a clear picture what is going on.
            No real benifit. More of an internal thing.
            Its really just allocating buffers, pulled out of egl.

            Originally posted by Harsh View Post
            Also could some explain what OpenWF is, in layman terms. Cant find anything that doesn't already assume you know what exactly OpenWF is.
            OpenWF (Display) is a modesetting api standardized by Khronos.
            OpenWF™ is a royalty-free, cross-platform API that provides a low-level hardware abstraction interface for composited windowing systems to make use of composition and display hardware. OpenWF is targeted primarily at handheld devices that require portable acceleration of composition whilst minimizing memory bandwidth usage and power levels.

            Comment


            • #7
              Originally posted by 89c51 View Post
              openWFD is a miss type both in the article and on the ml right????

              (considering d and f are close to the keyboard)
              I am assuming the D is for Display, as opposed to the other option, C for Composition.

              OpenWF™ is a royalty-free, cross-platform API that provides a low-level hardware abstraction interface for composited windowing systems to make use of composition and display hardware. OpenWF is targeted primarily at handheld devices that require portable acceleration of composition whilst minimizing memory bandwidth usage and power levels.

              Comment


              • #8
                Originally posted by sandain View Post
                I am assuming the D is for Display, as opposed to the other option, C for Composition.

                http://www.khronos.org/openwf/
                yes it probably is since i don't think the compositor part of openwf is used

                as for the people that asked about openwf as far as i understand it one part is similar to KMS but cross platform (which is better which has more functionality etc i don't know) and the other part is a compositor

                this is what i get from reading around and it might be seriously wrong (you have been warned)

                Comment


                • #9
                  Originally posted by plonoma View Post
                  Weren't EGL and DRI two different things?

                  EGL for resource sharing DRI for drawing?
                  The sentence seemed to be a bit confusing.

                  EGL is a application API.

                  DRI is 'Direct Rendering Infrastructure'. It's part of Linux's graphic acceleration driver stack.

                  **Hardware** <---> **Linux Kernel DRM driver** <---(DRI Protocol)--> **Usespace Driver** <---(App APIs)-> **Applications.**

                  The usespace graphics driver uses the DRI protocol to communicate with the Linux kernel. That is why it's called a 'DRI Driver'. The old style drivers are typically called 'Mesa DRI Driver'. The new style is based on Gallium3D and are generally called 'Gallium driver'.

                  But they are both 'DRI' drivers. The difference is that the old Mesa DRI driver was geared towards just OpenGL. Gallium3D is suppose to support all sorts of different application APIs (2D, OpenGL, OpenCL, etc) through the use of various 'state trackers' and other things. Gallium is much more modern, flexible, and shares a lot more code between drivers then the old style.


                  I think, but not certain, what they are trying to say is that instead of hard coding the buffer managers directly into the DRI driver, they have developed a version that is based on EGL.. which is a standard API for display management.

                  EGL™ is an interface between Khronos rendering APIs such as OpenGL ES or OpenVG and the underlying native platform window system. It handles graphics context management, surface/buffer binding, and rendering synchronization and enables high-performance, accelerated, mixed-mode 2D and 3D rendering using other Khronos APIs. EGL also provides interop capability between Khronos to enable efficient transfer of data between APIs – for example bet

                  Comment


                  • #10
                    Ah yes, I remember finding out this existed when it went and broke the Gentoo live ebuild for mesa. Apparently it's automatically enabled if EGL is enabled (which it is by default on Gentoo), but requires the decidedly non-default --enable-shared-glapi in order to actually work.

                    Comment

                    Working...
                    X