search

blue-systems / neon-pinebook-remix

Todos for Neon Pinebook Remix
3 stars 0 forks source link

GFX Video: "hardware decoding + GPU rendering" (FOSDEM) #62

Open star-buck opened 6 years ago

star-buck commented 6 years ago

info: Plasma: GL ES Kwin Compositing: Xrender, as Kwin GL ES is faulty redrawing stuff (bad lines, etc.) Compositor: drawing stuff on top/transparency,blur Xrender: simulated method of drawing stuff on top using X

issues:

plus side:

davidedmundson commented 6 years ago

smplayer wasnt working, only mpv

That's fixable, it was simply a matter of me having upgraded mpv with patches, and smplayer was then out of date; and I had to update that...and everything got out of sync.

window mode did stutter

I don't how to fix this. It's why I went back to my overlays to get the framerate up.

You saying netrunner worked better at least gives me something to try, I'll get some stats to prove whether it is or not, and if so look at copying the relevant parts of the X stack into the Ubuntu base.

davidedmundson commented 6 years ago

I don't how to fix this. It's why I went back to my overlays to get the framerate up.

Every flip to the next frame, the code path through X instead of just updating the window, goes through this code path where it copies the entire buffer into another buffer from kwin which is ~4px wider containing the window borders. Pretty wasteful.

Turn off both borders and shadows and you can make it fly as it doesn't need to copy anything, but that doesn't work when windowed and embbed in smplayer.

Apparently other X drivers just have ways of doing faster copies using lowlevel hardware image-copying functions. Ours has one, but it throws an error if the two buffers are not the same size, making it useless for this case.

star-buck commented 6 years ago

What Xdriver is it used here? Any way to not make it throw an error?

davidedmundson commented 6 years ago

xf86-video-armsoc (the DRM one)

I had tried the removing the check, but then it gets into kernel code which will return an error or just crash the system.

star-buck commented 6 years ago

For this gpu approach, do we use the exact same stuff + method as in netrunner?

davidedmundson commented 6 years ago

As it's not on the same base it will be different stuff everywhere; different X, different mpv, different libs. Same X driver, same mali blobs.

Method is subtly different:

Netrunner is doing gpu decoding and gpu rendering.

Neon (this fosdem version) does hw decoding and gpu rendering, which from my results always gave /considerably/ lower mpv CPU, just not where the bottleneck is.

With the same file with a large window on Netrunner I'm still seeing similar sized stutters and framedrops, so I'm not particularly convinced there's anything magic there.

star-buck commented 6 years ago

Netrunner 20171221: There are occasional black blibs on Netrunner while playing back video, but the window can be at least 2/3 screen in window mode, so it is visibly better than FOSDEM windowed mode?

davidedmundson commented 6 years ago

Personally I didn't think there was a big issue watching the FOSDEM image at 2/3 screen. I guess it depends on the video.

Measuring it, there is a subtle performance difference:

For the same 720p video in a window filling the screen height (but not full screen) Neon GPU rendering: 2180 framedrops Netrunner GPU rendering: 1700 framedrops

So something about the stack made a difference. I got the neon one down to 1950, just by turning off some X debug.

There may be a solution, turning on kwin's GL mode saves X doing one of the copying. We turned it off because of "glitches", but if fixing that is faster than speeding this up, it could work.

davidedmundson commented 6 years ago

From last image:

As for speed:

There may be a solution, turning on kwin's GL mode saves X doing one of the copies.

As found out on #netrunnerlinux you and I were running different netrunners, so actually it seems we were talking about the same thing here.