DRM_UDL and GPU under Xserver

[Daniel Vetter]

On Thu, Apr 5, 2018 at 12:29 PM, Lucas Stach <l.stach at pengutronix.de> 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 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.

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