search

blue-systems / neon-pinebook-remix

Todos for Neon Pinebook Remix
3 stars 0 forks source link

KWIN GLES: (blue) lines #68

Open star-buck opened 6 years ago

star-buck commented 6 years ago
davidedmundson commented 6 years ago

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

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)

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 commented 6 years ago

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:

and/or

shadeslayer commented 6 years ago

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

davidedmundson commented 6 years ago

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 commented 6 years ago

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

shadeslayer commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

The reason we have an old kernel is what?

star-buck commented 6 years ago

And on netrunner pinebook debian we have what kernel?

llelectronics commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

llelectronics commented 6 years ago

The binary blob kernel we use currently is 3.10.105.

shadeslayer commented 6 years ago

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 commented 6 years ago

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

davidedmundson commented 6 years ago

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

shadeslayer commented 6 years ago

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

@davidedmundson I was using the mali binary blobs

davidedmundson commented 6 years ago

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 commented 6 years ago

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

davidedmundson commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@subdiff that will not work for X11

subdiff commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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.