On Thu, Apr 5, 2018 at 12:29 PM, Lucas Stach <l.stach@xxxxxxxxxxxxxx> wrote: > 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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. Ah right, I've forgotten about the vivante 2d cores again. > 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. I don't think this makes sense. >> 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. Yeah, that sounds a lot more reasonable than trying to teach -armada about all the things -modesetting already knows to be able to be a generic kms driver. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
