On Mon, Jan 9, 2017 at 3:27 AM, Hans de Goede <hdego...@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@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
