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

    http://www.phoronix.com/vr.php?view=MTE4Mjc

  • #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.

    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
        http://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?

              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!

                    Comment


                    • #11
                      OK, I'll bite and ramble on phoronix too...

                      From my POV the two problems are very much related. In fact so much that I would handle it all through one ioctl.

                      In both cases you need:
                      - pass an arbitrary number of properties to the driver to modify the state
                      - the full device state must available to the driver before you can check whether a certain configuration is possible
                      - the API must support a mode where you just check the state, but don't apply it to the hardware

                      Where things start to differ is when you want to modify the actual hardware state.

                      In the pagelip case you absolutely want two features in the apply path:
                      - asynchronouse operation to avoid blocking the compositor
                      - atomically apply the state within a single hardware pipe/crtc

                      Ideally you would also want asynchronous execution for the modeset path, but people are lazy and don't want to write the necessary state machine (or whatever logic) to handle it. So that's why mode setting is generally is handled through a synchronous (ie. blocking) code path.

                      Now, since you anyway need the same state checking and virtually identical API in both cases, I see no reason to impose a split on that level. It can all be left as an internal implementation detail. Doing it that way would also allow some enterprising developer to actually implement asynchronous mode setting if they so wish.

                      So as I see it, you just need a few extra flags in the API so that user space can demand asynchronous operation from the driver. If the driver can't satisfy the request asynchronously the user gets an error, and can do whatever fallback is appropriate.

                      Comment


                      • #12
                        Originally posted by Michael View Post
                        Huh? I'm not the one that named it... http://lists.freedesktop.org/archive...er/027506.html
                        Ah, sorry for the misunderstanding.

                        Comment

                        Working...
                        X