Atomic Page-Flipping Still Being Worked On

[phoronix]

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

[Ericg]

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.

[curaga]

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

[Michael]

"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

[elanthis]

[robclark]

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

[Ericg]

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?

[daniels]

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.

[robclark]

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.

[Ericg]

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!