Announcement

Collapse
No announcement yet.

A Software-Based Pixman Renderer For Wayland's Weston

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

  • A Software-Based Pixman Renderer For Wayland's Weston

    Phoronix: A Software-Based Pixman Renderer For Wayland's Weston

    There hasn't been too many new Wayland/Weston developments to report on recently, but being published this weekend for review and comments is a new Pixman renderer for Weston. This Pixman renderer allows for pure software rendering with the Weston reference compositor and adds MIT-SHM support to the X11 back-end...

    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
    One important note: this renderer allows to launch weston on hosts without any gpu acceleration, I'm working now on 16bpp support and fbdev backend now.

    Comment


    • #3
      someone please correct me here. is xwayland already out but not merged, or it is not a stable release yet? if so, wouldn't that mean that the fall release of x.org would have working xwayland to be used with wayland.

      Comment


      • #4
        Originally posted by anarsoul View Post
        One important note: this renderer allows to launch weston on hosts without any gpu acceleration, I'm working now on 16bpp support and fbdev backend now.
        Good news. But I have a question since you posted that piece of info: Isn't llvmpipe already capable of handling Wayland on hosts that do not have GPU acceleration?

        Comment


        • #5
          Originally posted by Rexilion View Post
          Good news. But I have a question since you posted that piece of info: Isn't llvmpipe already capable of handling Wayland on hosts that do not have GPU acceleration?
          It should perform a lot better. Instead of using a pass-through shader program, transforming and interpolating floating point coordinates, and sampling textures, you can just do a blit. GL is a very complex system to program the relatively simple operations a basic compositor mostly uses.

          Comment


          • #6
            Originally posted by pq__ View Post
            It should perform a lot better. Instead of using a pass-through shader program, transforming and interpolating floating point coordinates, and sampling textures, you can just do a blit. GL is a very complex system to program the relatively simple operations a basic compositor mostly uses.
            Thanks for the info. So I guess we all should go Wayland right now. I mean, take X and rip out everything except the RENDER extension. Give it some hard earned code cleanup and you have something comparable to Wayland.

            Especially since the optimizations X uses are also being enabled for Wayland as well...

            Or am I speaking total rubbish?

            Comment


            • #7
              Originally posted by Rexilion View Post
              So I guess we all should go Wayland right now. I mean, take X and rip out everything except the RENDER extension. Give it some hard earned code cleanup and you have something comparable to Wayland.

              Especially since the optimizations X uses are also being enabled for Wayland as well...

              Or am I speaking total rubbish?
              You're wrong about the extension: Wayland is the equivalent of the X's DRI2 extension(sharing video memory between the programs and the display server) NOT to the Render extension..

              Comment


              • #8
                Originally posted by renox View Post
                You're wrong about the extension: Wayland is the equivalent of the X's DRI2 extension(sharing video memory between the programs and the display server) NOT to the Render extension..
                You are right. A simple Wiki lookup would have corrected me. I also stumbled on the below...

                The MIT Shared Memory Extension or MIT-SHM is a X Window System extension for exchange of image data between client and server using shared memory.

                Which looks like your description on DRI2. Confusing...

                I'm just glad that Wayland is being made. Not known with all the technical details (as shown above) I tried to compile the entire X stack once under Fedora. Think I never finished getting that done XD .

                Comment


                • #9
                  Originally posted by Rexilion View Post
                  You are right. A simple Wiki lookup would have corrected me. I also stumbled on the below...

                  The MIT Shared Memory Extension or MIT-SHM is a X Window System extension for exchange of image data between client and server using shared memory.

                  Which looks like your description on DRI2. Confusing...
                  The shared memory extension is for sharing the "normal" (DRAM) main memory between a program and the display server, the DRI2 extension is for sharing "video memory" between a program and the display server, if you have a GPU board, the "video memory" is the memory is in the board..

                  Comment


                  • #10
                    Then under Wayland, Cairo can then use a pixman backend instead of cairo-gl, which, I believe, was not ready and was not performant.

                    Comment

                    Working...
                    X