Am Donnerstag, den 05.04.2018, 11:32 +0200 schrieb Daniel Vetter: > On Thu, Apr 5, 2018 at 9:16 AM, Alexey Brodkin > <Alexey.Brodkin at synopsys.com> wrote: > > Hi Daniel, > > > > On Thu, 2018-04-05 at 08:18 +0200, Daniel Vetter wrote: > > > On Wed, Apr 4, 2018 at 10:06 PM, Alexey Brodkin > > > <Alexey.Brodkin at synopsys.com> wrote: > > > > Hello, > > > > > > > > We're trying to use DisplayLink USB2-to-HDMI adapter to render > > > > GPU-accelerated graphics. > > > > Hardware setup is as simple as a devboard + DisplayLink > > > > adapter. > > > > Devboards we use for this experiment are: > > > > ?* Wandboard Quad (based on IMX6 SoC with Vivante GPU) or > > > > ?* HSDK (based on Synopsys ARC HS38 SoC with Vivante GPU as > > > > well) > > > > > > > > I'm sure any other board with DRM supported GPU will work, > > > > those we just used > > > > as the very recent Linux kernels could be easily run on them > > > > both. > > > > > > > > Basically the problem is UDL needs to be explicitly notified > > > > about new data > > > > to be rendered on the screen compared to typical bit-streamers > > > > that infinitely > > > > scan a dedicated buffer in memory. > > > > > > > > In case of UDL there're just 2 ways for this notification: > > > > ?1) DRM_IOCTL_MODE_PAGE_FLIP that calls drm_crtc_funcs- > > > > >page_flip() > > > > ?2) DRM_IOCTL_MODE_DIRTYFB that calls drm_framebuffer_funcs- > > > > >dirty() > > > > > > > > But neither of IOCTLs happen when we run Xserver with xf86- > > > > video-armada driver > > > > (see https://urldefense.proofpoint.com/v2/url?u=http-3A__git.ar > > > > m.linux.org.uk_cgit_xf86-2Dvideo-2Darmada.git_log_-3Fh- > > > > 3Dunstable-2Ddevel&d=DwIBaQ&; > > > > c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkh > > > > pk5R81I&m=oEAlP64L9vkuUs_k3kGwwwlN1WJbDMJbCo0uDhwKwwk&s=3ZHj- > > > > 6JXZBLSTWg_4KMnL0VNi7z8c0RxHzj2U5ywVIw&e=). > > > > > > > > Is it something missing in Xserver or in UDL driver? > > > > > > Use the -modesetting driverr for UDL, that one works correctly. > > > > If you're talking about "modesetting" driver of Xserver [1] then > > indeed > > picture is displayed on the screen. But there I guess won't be any > > 3D acceleration. > > > > At least that's what was suggested to me earlier here [2] by Lucas: > > ---------------------------->8--------------------------- > > For 3D acceleration to work under X you need the etnaviv specific > > DDX > > driver, which can be found here: > > > > http://git.arm.linux.org.uk/cgit/xf86-video-armada.git/log/?h=unsta > > ble-devel > > You definitely want to use -modesetting for UDL. And I thought with > glamour and the corresponding mesa work you should also get > accelaration. Insisting that you must use a driver-specific ddx is > broken, the world doesn't work like that anymore. On etnaviv the world definitely still works like this. The etnaviv DDX uses the dedicated 2D hardware of the Vivante GPUs, which is much faster and efficient than going through Glamor. Especially since almost all X accel operations are done on linear buffers, while the 3D GPU can only ever do tiled on both sampler and render, where some multi-pipe 3D cores can't even read the tiling they write out. So Glamor is an endless copy fest using the resolve engine on those. If using etnaviv with UDL is a use-case that need to be supported, one would need to port the UDL specifics from -modesetting to the -armada DDX. > Lucas, can you pls clarify? Also, why does -armada bind against all > kms drivers, that's probaly too much. I think that's a local modification done by Alexey. The armada driver only binds to armada and imx-drm by default. Regards, Lucas
