[PATCH v2 xserver 00/11] modesetting: MS_ALL_IN_ONE

[Alex Deucher]

On Mon, Jan 9, 2017 at 3:27 AM, Hans de Goede <hdegoede at redhat.com> wrote:
> Hi,
>
> On 09-01-17 02:52, Yu, Qiang wrote:
>>
>>
>> Hi Hans,
>>
>> I forgot there is another difference, PRIME solution has to copy screen
>> once before display
>> to iGPU while MS_ALL_IN_ONE don't have to and can display what full screen
>> app draws
>> directly by page flip (for DRI2) which may be important for embedded
>> platforms with week
>> GPU and limited memory bandwidths.
>
>
> Hmm, I guess you're talking imx6 + etnaviv now right, because with a
> discrete GPU
> + iGPU displaying the rendered frame, we are always going to need one copy
> from
> discrete-GPU RAM to system RAM. But I agree that getting rid of the extra
> copy for
> imx6 would be really good, I even dare to call it a must-have feature.

Qiang can correct me if I'm wrong, but I think there are some cases
where it makes more sense for the dGPU to directly access system
memory rather than use vram and copy.

Alex

>
>> Benefit from common interface of drm/gbm/egl, may be modesetting can play
>> a bigger role
>> of span multi drm devices to give more optimization like this and:
>> 1. multi render node, a single protocol screen to accept request and
>> dispatch to each render
>> node for render
>> 2. multi display node associate with the render node (some display node
>> has the same drm
>> device with render node), so no need to handle bo tile-linear copy and
>> each render node can
>> handle request of its related display node.
>
>
> Ack I agree that we would need to do better here, but I don't believe this
> should be some
> special mode activated by some special means, e.g. in the imx6 + etnaviv
> case the modesetting
> driver should simply recognize that they are sharing RAM and use
> page-flipping (passing buffer
> ownership between the 2) rather then copying, without the user needing to do
> anything
> special.
>
> Regards,
>
> Hans
>
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel