Announcement

Collapse
No announcement yet.

Atomic Page-Flipping Still Being Worked On

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

  • Atomic Page-Flipping Still Being Worked On

    Phoronix: Atomic Page-Flipping Still Being Worked On

    For those wondering about the state of atomic mode-setting / page-flipping, it's still being tackled by an Intel developer...

    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
    Hey guys, I've read both articles on Atomic and Nuclear page flipping. Can one of the devs (or anyone with experience with it) explain the difference between the two? I know they are two different implementations, but i don't get which has advantages / disadvantages over the other, or which is more future-proof, etc.
    All opinions are my own not those of my employer if you know who they are.

    Comment


    • #3
      "Nuclear" is just Michael's bad word-play on atomic.

      Comment


      • #4
        Originally posted by curaga View Post
        "Nuclear" is just Michael's bad word-play on atomic.
        Huh? I'm not the one that named it... http://lists.freedesktop.org/archive...er/027506.html
        Michael Larabel
        https://www.michaellarabel.com/

        Comment


        • #5

          Comment


          • #6
            Originally posted by Michael View Post
            Huh? I'm not the one that named it... http://lists.freedesktop.org/archive...er/027506.html
            Heheh, I didn't even come up with the name (although I'm not really sure who did).. anyways:

            atomic-modeset: setting (or testing) a mode configuration across one or more displays atomically, which would allow to deal properly w/ scenarios like when the highest resolution is only possible when there is just one display plugged in due to bandwidth restrictions, etc. Currently kms doesn't have a way to express this sort of restriction.

            atomic/nuclear-pageflip: synchronized flipping on crtc plus zero or more plane/overlay layers, possibly while setting various other property values synchronized w/ the vblank. This is needed for weston using kms planes for hw composition, and also for something like surfaceflinger which also can bypass the gpu for some composition needs. (Actually it is a fairly common technique in embedded world... I think webos also did the same.)

            In discussing w/ jbarnes and krh at LPC, we came to the idea that atomic/nuclear-pageflip was more urgently needed, and it would be good to not block it on atomic modetest which is a bigger task. So I volunteered to take a crack at it.

            BR,
            -R

            Comment


            • #7
              Originally posted by robclark View Post
              atomic-modeset: setting (or testing) a mode configuration across one or more displays atomically, which would allow to deal properly w/ scenarios like when the highest resolution is only possible when there is just one display plugged in due to bandwidth restrictions, etc. Currently kms doesn't have a way to express this sort of restriction.

              atomic/nuclear-pageflip: synchronized flipping on crtc plus zero or more plane/overlay layers, possibly while setting various other property values synchronized w/ the vblank. This is needed for weston using kms planes for hw composition, and also for something like surfaceflinger which also can bypass the gpu for some composition needs. (Actually it is a fairly common technique in embedded world... I think webos also did the same.)
              Correct me if im on wrong on this Rob-- so its not 2 different solutions to 1 problem like I thought. Its 2 different solutions to 2 different problems? Both code bases are non-conflicting, solve 2 different issues that both needed to be addressed and just happened to be referenced to eachother in their respective articles?
              All opinions are my own not those of my employer if you know who they are.

              Comment


              • #8
                Originally posted by Ericg View Post
                Correct me if im on wrong on this Rob-- so its not 2 different solutions to 1 problem like I thought. Its 2 different solutions to 2 different problems? Both code bases are non-conflicting, solve 2 different issues that both needed to be addressed and just happened to be referenced to eachother in their respective articles?
                yep, exactly.

                Comment


                • #9
                  Originally posted by Ericg View Post
                  Correct me if im on wrong on this Rob-- so its not 2 different solutions to 1 problem like I thought. Its 2 different solutions to 2 different problems? Both code bases are non-conflicting, solve 2 different issues that both needed to be addressed and just happened to be referenced to eachother in their respective articles?
                  Correct, it is two different problems, although there are some similarities between the two problems. I've looked at Ville's work, and that has influenced what I am proposing because the end goal is that it all fits together. I'm trying to propose some changes in drm core to hopefully make it easier on the individual driver writers. I'm hoping that what I am proposing also makes it easier for the atomic modeset, as that problem also needs to be solved and it has some of the same implementation needs. Of course there is still discussion about the details, but that is all part of the normal collaborative development process. So they aren't really competing solutions.

                  Comment


                  • #10
                    Originally posted by robclark View Post
                    Correct, it is two different problems, although there are some similarities between the two problems. I've looked at Ville's work, and that has influenced what I am proposing because the end goal is that it all fits together. I'm trying to propose some changes in drm core to hopefully make it easier on the individual driver writers. I'm hoping that what I am proposing also makes it easier for the atomic modeset, as that problem also needs to be solved and it has some of the same implementation needs. Of course there is still discussion about the details, but that is all part of the normal collaborative development process. So they aren't really competing solutions.
                    Alright, sounds good When these stories originally hit i was under the impression that it was 2 different implementations to solve the same problem and that therefore we'd be at a discussion of "Whos idea is better?" But I'm glad to see that I was wrong on that account. Keep up the good work guys!
                    All opinions are my own not those of my employer if you know who they are.

                    Comment

                    Working...
                    X