Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: Atomic Page-Flipping Still Being Worked On

  1. #1
    Join Date
    Jan 2007
    Posts
    15,098

    Default 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. #2
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,912

    Default

    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.

  3. #3
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,182

    Default

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

  4. #4

    Default

    Quote 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

  5. #5
    Join Date
    Nov 2007
    Posts
    1,024

    Default


  6. #6
    Join Date
    Sep 2011
    Posts
    276

    Default

    Quote 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

  7. #7
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,912

    Default

    Quote 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?

  8. #8
    Join Date
    Jul 2009
    Posts
    286

    Default

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

  9. #9
    Join Date
    Sep 2011
    Posts
    276

    Default

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

  10. #10
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,912

    Default

    Quote 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!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •