KWIN GLES: (blue) lines

[star-buck]

• small (blue) lines, mostly when entering text fields

[davidedmundson]

My somewhat technical notes from last week on "The blue lines"

• I wrote some mods for kwin that dumped the images it was rendering in it's final eglSwapBuffers.
  The blue lines appear in our buffer we have, not just on screen. So their damaged before that point.

• I also wondered if it was a bug in EGL_IMAGE_PRESERVED_KHR so blitted the backbuffer just after a swap, but no lines were introduced there.

Therefore I think the kwin code for rendering output is actually fine, but we have a bug "receiving" the images where the textures we have are slightly out of sync.

For that reason the whole section with EGL_KHR_PARTIAL_UPDATE/SwapBuffersWithDamage that I spent some time implementing isn't in the right area at all (but an area potentially worth revisiting if we want to tweak performance)

---

• I have added code to KWin::EglTexture::onDamage and then working backwards from there.
  That's still a WIP.

One area that's potentially very relevant is kwin has a whole section for making sure GL events are synced with updates from X; (see SyncObjects in scene_opengl.cpp) this relies on an extension that doesn't exist in Mali.

If I run on my desktop:
KWIN_COMPOSE=O2ES (to use GLES)
KWIN_EXPLICIT_SYNC=0 (to mimic not having GL_EXT_x11_sync_object extension like the pinebook scene_opengl.cpp:354 )
kwin_x11

I see some corruption, albeit not identical.

[davidedmundson]

On the glitches:

I'm 90% sure I now know where the bug is.
It's not really kwin, it's that bloody X driver.

X clients render into an area of memory.
Kwin uses GL to create a texture from that same piece of memory without copying it.
There is no working locking in place. Two people read and write the same thing at once.

There's code trying to do this: ARMSOCPrepareAccess/ARMSOCFinishAccess have UMPlock code which in theory would match the relevant lock code in the mali binary blob which kwin is using to read the texture.

We didn't have a working umplock driver, so I built that, but it still doesn't work as our mali kernel module isn't using UMP anymore but DMA-BUF.

Having one side lock something doesn't help. we need our X locking to match whatever locks our Mali driver does. That's incredibly difficult as half of it is a binary blob which documentation says can be compiled in different variants, and I have no idea what Allwinner has given us.

---

After reaching this conclusion I did some googling and someone else reports the same symptoms we have:
https://community.arm.com/graphics/f/discussions/4259/umplock-equivalent-for-mali-400-dmabuf-version

It has an incredibly unhelpful reply from an ARM person.

---

Plan of attack moving foward:

• built the mali kernel device driver with ump support, in the hope that the binary blob will use that, and then umplock will work and everything is synced.

and/or

• implement whatever the equivalent dmabuf locking is in armsoc_exa.c and hope the mali binary blobs support that.

[shadeslayer]

I vaguely recall that the libMali.so blob also needs to implement the umplock bits, but I'm not 100% sure.

[davidedmundson]

Previously on the image we didn't even have the umplock kernel modules (/dev/umplock)

I've added that, and debug shows X now using it.

But strace'ing kwin, I can't see any calls to it, nor can I find any reference when extracting strings from the blob.

[shadeslayer]

@davidedmundson make sure /dev/ump is in the video group?

[shadeslayer]

@davidedmundson from running strings on the libMali.so blob I see VARIANT=mali400-gles-linux-x11-dma_buf-no_Werror

Which is the dma_buf variant, so UMP won't actually work here.

[davidedmundson]

This sucks.

There's code to make ump-based locking work in our X driver, but not our GL blob is trying to use newer dmabuf stuff

There's a nice API to do dmabuf-based locking which I think is what I need to add to our X driver .... but API is not in our kernel because that's too old...

I'm gonna try adding some kernel API to expose dma_buf_begin_cpu_access and then add that to the X driver, but I'm not entirely optimistic.

[star-buck]

The reason we have an old kernel is what?

[star-buck]

And on netrunner pinebook debian we have what kernel?

[llelectronics]

The typical ARM problem. Proprietary drivers only being compatible with one old kernel version.
No real upstream vanilla kernel support as chip creators don't contribute to the upstream kernel.
Shadeslayer tried already running the vanilla kernel ( a newer one) but that did not work so well and opens the box of pandora ones more.

[llelectronics]

So we use the one that works best out of the box with the hardware. And this is the one with the binary blobs cusomized for the pinebook itself instead of the vanilla kernel.

[star-buck]

Can we start putting real kernel version numbers in here, as it makes the discussion so much more useful...

[llelectronics]

The binary blob kernel we use currently is 3.10.105.

[shadeslayer]

Shadeslayer tried already running the vanilla kernel ( a newer one) but that did not work so well and opens the box of pandora ones more.

Huh? The mainline kernel actually works pretty well, and I'd actually recommend it over the BSP kernel. We ought to try and get the modesetting eglamor X11 driver working on there instead of fiddling with armsoc since that has now been deprecated.

[llelectronics]

Oh so old news. Sorry. Had in mind that X was not running

[davidedmundson]

But you weren't using the mali binary blobs on mainline right?

[shadeslayer]

@llelectronics Oh it definitely does work. I also got weston working

@davidedmundson I was using the mali binary blobs

[davidedmundson]

My last week:

Plan 1: Add umplock support to our kernel and X driver, hope GL driver uses it despite not using UMP.
Didn't work, clearly our blob doesn't use those locks.

Plan 2: Add kernel API to call the dmabuf_start_cpu_access (like new kernels have)
Didn't work, it just calls the relevant lock code in the DRM driver..and that code doesn't exist

Plan 3: If the GL driver doesn't lock, maybe we could lock from userspace in kwin
Didn't work we don't have the DMABuf handle.

Plan 4: Use modesetting driver (which uses eglglamor) that /should/ fix it,as it double buffers the clients, and kwin will see them as regular GL windows.

Didn't work, kernel crashes

Plan 5: Use modesetting driver as above but with mainline kernel.

Didn't work, now X crashes!

Plan 6: Using mainline with our old Xdriver and then add the relevant DMA buf locks into the X driver which are now in the newer kernel.

Before I changed anything, it rendered everything black.
(Shadeslayer said he had that part working though...)

---

Will continue working on Plan 5 or 6 till I get something amazing.

[bhush9]

Issue of libreoffice should be fixed in the new image http://weegie.edinburghlinux.co.uk/~neon/images/pinebook-remix/20180314-1525/

[davidedmundson]

Plan 6: Using mainline with our old Xdriver and then add the relevant DMA buf locks into the X driver

I got this setup running by turning off pageflips, but even before I edited any code it was suuuuper slow. Surprisingly it doesn't glitch even though I haven't made my driver fix yet, but that might just be because it's being slow. :/

[davidedmundson]

Plan 5: Use modesetting driver as above but with mainline kernel.

First crash was ocurring because I wasn't loading glamor properly (despite the debug output)
Got past that, and into another crash.

That crash is ultimately this line.

glamor_egl->display = glamor_egl_get_display(EGL_PLATFORM_GBM_MESA,
glamor_egl->gbm);

that obviously doesn't work, we're not using mesa and we don't have a GBM plugin. Doing that with the proprietory blob is simply not possible.

Interestingly most sections of code are in an #ifdef with a no GBM version, but doing the obvious fixes there results in having to patch a tonne of X, and it's a bit of a never ending rabbit hole. Current WIP.

[shadeslayer]

@davidedmundson JFYI Rockchip made this change to their xserver fork for eglamor support https://github.com/rockchip-linux/xserver/commit/ca089f8ca785d285000cc23c8ff989dfc765c106

Though grepping through their libmali blobs indicates they have GBM support in their libmali. Perhaps we can poke the pinebook people to get us a X11 libmali build with GBM support?

[subdiff]

FYI the Wayland mali blob Pine released some time ago announced GBM support by its file names:
http://wiki.pine64.org/index.php/Mali_Driver#Wayland_MALI_Driver

[shadeslayer]

@subdiff that will not work for X11

[subdiff]

Yes, just pointing out that they already provided us with GBM supporting drivers for a different windowing system. So there is a high likelihood that they can give us the same for X as well.

Best would be such a driver, that supports X and Wayland (because the current Wayland only blob is problematic in regards to SDDM and Xwayland).

As a note a discussion from mailing list about Mali with Glamor: https://lists.x.org/archives/xorg-devel/2016-January/048417.html

[shadeslayer]

@subdiff Right, I already asked tllim if he could get us a X11 + GBM blob. Waiting on his reply. Till then I guess we should work with armsoc.

[subdiff]

if he could get us a X11 + GBM blob

Did you ask for X11 + GBM or X11 + Wayland + GBM? Just to make sure we get a blob in the end that works for X and Wayland as well (the current Wayland blobs misses X support for a full system with SDDM and probably also Xwayland).

[shadeslayer]

The former, I'm not entirely sure the latter is even possible since no one else seems to be releasing that, but I'll ask anyway.