[PATCH v2 1/6] drm/vblank: Add intro to documentation
Thomas Zimmermann
tzimmermann at suse.de
Tue Mar 31 06:14:14 UTC 2020
Hi,
just a few more nits below.
Am 30.03.20 um 23:51 schrieb Lyude Paul:
> I am glad that my explanation of vblanks made sense! Some comments below on
> things I think we could improve here
>
> On Mon, 2020-03-30 at 20:57 +0200, Sam Ravnborg wrote:
>> Lyude Paul wrote a very good intro to vblank here:
>>
> https://lore.kernel.org/dri-devel/faf63d8a9ed23c16af69762f59d0dca6b2bf085f.camel@redhat.com/T/#mce6480be738160e9d07c5d023e88fd78d7a06d27
>>
>> Add this to the intro chapter in drm_vblank.c so others
>> can benefit from it too.
>>
>> v2:
>> - Reworded to improve readability (Thomas)
>>
>> Signed-off-by: Sam Ravnborg <sam at ravnborg.org>
>> Co-developed-by: Lyude Paul <lyude at redhat.com>
>> Cc: Lyude Paul <lyude at redhat.com>
>> Acked-by: Thomas Zimmermann <tzimmermann at suse.de>
>> Cc: Thomas Zimmermann <tzimmermann at suse.de>
>> Cc: Daniel Vetter <daniel at ffwll.ch>
>> Cc: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
>> Cc: Maxime Ripard <mripard at kernel.org>
>> Cc: Thomas Zimmermann <tzimmermann at suse.de>
>> Cc: David Airlie <airlied at linux.ie>
>> ---
>> drivers/gpu/drm/drm_vblank.c | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
>> index bcf346b3e486..ec2c2083b186 100644
>> --- a/drivers/gpu/drm/drm_vblank.c
>> +++ b/drivers/gpu/drm/drm_vblank.c
>> @@ -41,6 +41,23 @@
>> /**
>> * DOC: vblank handling
>> *
>> + * From the computer's perspective, every time the monitor displays
>> + * a new frame the scanout engine have "scanned out" the display image
>> + * from top to bottom, one row of pixels at a time.
>> + * The current row of pixels is referred to as the current scanline.
>> + *
>> + * In addition to the display's visible area, there's usually a couple of
>> + * extra scanlines which aren't actually displayed on the screen
>> + * (the extra scanlines are sometimes used by HDMI audio and friends).
>> + * The period where the extra scanlines are "scanned out" is referred
>> + * to as the vertical blanking period (vblank for short).
>
> I'd reword this, starting from "(the extra scanlines…" (I'd also remove the
> paranthesis):
>
> These extra scanlines don't contain image data, and are occasionally used
> for features like audio and infoframes. The region made up of these
> scanlines is referred to as the vertical blanking region, or vblank for
> short.
>
> I'd also add a simple ascii-art diagram here, since this might make a lot more
> sense to some people if there's a visual reference. Probably something like
> this (feel free to get a little creative)
>
> ⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽
> | |
> | |
> | New frame |
> | |
> |↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓|
> |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| ← Scanline, updates the
> |↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓| frame as it travels
> | | down (AKA "scans out")
> | |
> | |
> | Old frame |
> | |
> | |
> | |
> | |
> | | physical bottom of
> |⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽| ← display
> ┆xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx┆
> ┆xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx┆ ← vertical blanking
> ┆xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx┆ region
> ------------------------------------------------
>> + *
>> + * On a lot of display hardware, programming needs to take effect during
>> the
>> + * vertical blanking period so that settings like gamma, what frame being
>
> s/what frame being/which frame is being/
I still had read it twice in either variant. Maybe:
s/what frame being scanned out/the displayed image buffer
>
>> + * scanned out, etc. can be safely changed without showing visual tearing
I think tearing refers specifically to mid-frame buffer flips. Maybe
s/tearing/artifacts
or
s/tearing/distortion
Best regards
Thomas
>> + * on the screen. In some unforgiving hardware, some of this programming
>> has
>> + * to both start and end in the same vblank - vertical blanking period.
>
> You can just say vblank here, since we already explained what the vertical
> blanking period is up above.
>
> Alex Deucher pointed out to me that it's probably also worth mentioning that not
> all hardware actually fires off the vblank interrupt at the start of the
> vertical blank, depending on the hardware the interrupt could also happen a few
> scanlines after the start of vblank, a few scanlines before the start, somewhere
> in the middle, at the end of the vblank, etc.
>
> Other then that, this looks great so far! Feel free to cc me in the respin for
> this patch and I'll be happy to give my r-b.
>
>> + *
>> * Vertical blanking plays a major role in graphics rendering. To achieve
>> * tear-free display, users must synchronize page flips and/or rendering to
>> * vertical blanking. The DRM API offers ioctls to perform page flips
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20200331/f717da67/attachment-0001.sig>
More information about the dri-devel
mailing list