News: 0001547748

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

DRM IN_FORMATS_ASYNC Coming For The Intel Driver With Linux 6.16

([Intel] 29 Minutes Ago IN_FORMATS_ASYNC)


Sent out last week was one final batch of drm-misc-next updates ahead of the upcoming Linux 6.16 kernel cycle. Besides a couple fixes, most notable was new async flipping code for the Intel DRM driver with the IN_FORMATS_ASYNC DRM property.

Landing for Linux 6.16 is the "IN_FORMATS_ASYNC" DRM plane property. IN_FORMATS_ASYNC is to be used initially by just the Intel driver for buffer format and modifier pairs supported by a given plan for asynchronous flips. The patch series for exposing the modifiers/formats supported by async flips further notes:

"All of the formats/modifiers supported by the plane during synchronous flips are nor supported by asynchronous flips. The formats/modifiers exposed to user by IN_FORMATS exposes all formats/modifiers supported by plane and this list varies for async flips. If the async flip supported formats/modifiers are exposed to the user, user based on this list can take decision to proceed or not and avoid flip failures during async flips."

Waiting in user-space is already [1]this open GNOME Mutter merge request from seven months ago for supporting the tearing modifiers DRM property. In turn that should help address [2]this merge request for supporting async page flipping or tearing under GNOME.

The IN_FORMATS_ASYNC addition is the main focal point of last week's [3]drm-misc-next pull request ahead of the Linux 6.16 cycle.



[1] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4063

[2] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3797

[3] https://lore.kernel.org/dri-devel/23ded62c-6a62-4195-9c08-4dfb81eafd72@linux.intel.com/



phoronix

It is a very humbling experience to make a multimillion-dollar mistake, but it
is also very memorable. I vividly recall the night we decided how to organize
the actual writing of external specifications for OS/360. The manager of
architecture, the manager of control program implementation, and I were
threshing out the plan, schedule, and division of responsibilities.

The architecture manager had 10 good men. He asserted that they could write
the specifications and do it right. It would take ten months, three more
than the schedule allowed.

The control program manager had 150 men. He asserted that they could prepare
the specifications, with the architecture team coordinating; it would be
well-done and practical, and he could do it on schedule. Furthermore, if
the architecture team did it, his 150 men would sit twiddling their thumbs
for ten months.

To this the architecture manager responded that if I gave the control program
team the responsibility, the result would not in fact be on time, but would
also be three months late, and of much lower quality. I did, and it was. He
was right on both counts. Moreover, the lack of conceptual integrity made
the system far more costly to build and change, and I would estimate that it
added a year to debugging time.
-- Frederick Brooks Jr., "The Mythical Man Month"