On 2021-08-27 9:53 a.m., Simon Ser wrote: > On Tuesday, August 24th, 2021 at 18:48, Harry Wentland <harry.wentland@xxxxxxx> wrote: > >> To elaborate on this a bit more, each HW plane's scanout engine >> has the ability to scan out a cursor, in addition to the plane's >> framebuffer. This cursor is drawn onto the plane at the scanout >> phase. Any further scaling, color processing, or other operation >> on the pipe will equally apply to the cursor as to the framebuffer >> itself. >> >> Our driver will look at the cursor position and place the cursor >> with the topmost HW plane at that position. > > Ah. I may have missed something in my previous email then. With the > scenario I've described: > > ┌────────────────────────────┐ > │Primary │ > │ │ > │ │ > │ ┌───────┐ │ > │ │Cursor │ │ > │ │ │ │ > │ │ ┌───┼────────┐ │ > │ └───┼───┘ │ │ > │ │ │ │ > │ │ │ │ > │ │ Overlay│ │ > │ └────────────┘ │ > │ │ > └────────────────────────────┘ > Nice diagram. > Is it possible to draw the cursor only on the overlay pipe (not on the primary > pipe), even though the overlay pipe doesn't cover the whole CRTC? > > Or will the overlay pipe crop the cursor image? > It will be cropped to the overlay rectangle. If you can allocate your overlay such that its destination rectangle always spans the entire CRTC you'd have no cursor issues. Unfortunately that means that you would use more memory bandwidth since you're scanning out an overlay that's larger than you really need. Harry >> If I understood Simon right the primary plane (bottom-most, >> game plane) might not cover the entire screen, which is fine. > > Yes. > >> Is the Steam overlay always the size of the crtc, or does it >> match the size of the game plane, or is it unrelated to either? > > The overlay may not cover the whole CRTC. The usual case is some kind of > notification bubble showing in a corner. See the drawing above. > >>>>>>> Basically, we cannot draw the cursor at the same size and position on >>>>>>> two separated pipes since it uses extra bandwidth and DML only run >>>>>>> with one cursor. >>>>>> >>>>>> I don't understand this limitation. Why would it be necessary to draw the >>>>>> cursor on two separate pipes? Isn't it only necessary to draw it once on >>>>>> the overlay pipe, and not draw it on the primary pipe? >>>>> >>>>> I will try to provide some background. Harry and Nick, feel free to >>>>> correct me or add extra information. >>>>> >>>>> In the amdgpu driver and from the DRM perspective, we expose cursors as >>>>> a plane, but we don't have a real plane dedicated to cursors from the >>>>> hardware perspective. We have part of our HUPB handling cursors (see >>>>> commit "drm/amd/display: Add DCN3.1 DCHHUB" for a hardware block >>>>> overview), which requires a different way to deal with the cursor plane >>>>> since they are not planes in the hardware. >>>> >>>> What are DCHUBBUB and MMHUBBUB responsible for? Is one handling the primary >>>> plane and the other handling the overlay plane? Or something else entirely? >> >> MMHUBBUB > DCHUBBUB > HUBP (for each pipe) >> >> MMHUBBUB is irrelevant if DWB (display writeback) is not used. DWB is not >> enabled in the driver. >> >> DCHUBBUB is the overall scanout engine for all DC pipes and includes a >> HUBP per pipe. >> >> HUBP will have requestors for the primary framebuffer, DCC meta, dynamic >> metadata (for things like Dolby HDR, though it's not fully implemented), >> and cursor data. > > I see. Thanks! >
