09:01 <asdf28> https://github.com/kszaq/linux-amlogic-le/tree/3.14_vsync_mali_r6p1/drivers/amlogic/drm

09:01 <asdf28> has someone got this to work with the legacy kernel?

09:02 <asdf28> i got it as far as creating a /dev/dri/card0 device, but applications fail with "drmModeGetResources failed"

09:03 <asdf28> is this a so-called legacy DRM driver that does not set the mode through the kernel?

09:04 <asdf28> and requires a window server to be running?

09:06 <asdf28> it would be interesting to try this because DRM drivers with the mainline kernel have poor 3D performance

09:22 <asdf28> okay, i just saw that the modesetting stuff has been commented out with an "ifdef #MUSE"

09:22 <asdf28> what is MUSE?

09:25 <asdf28> and some of the required DRM features only exist in later kernel versions

09:40 <chewitt> asdf28 which mali device are you trying to work with?

09:41 <chewitt> see https://github.com/LibreELEC/mali-utgard/tree/DX910-SW-99002-r9p0-01rel0-multiplatform

09:41 <chewitt> there are also midgard/bifrost drivers in the LE github

09:42 <chewitt> but might not build against 5.9+ kernels as we switched to lima/panfrost

09:42 <chewitt> prob. not much difference tho

09:45 <asdf28> chewitt: yes, it's mali utgard, thanks for the link. i have already tried this driver

09:45 <asdf28> but something is wrong when it comes to 3D performance using the newer drivers

09:46 <chewitt> new ARM drivers, or lima?

09:46 <asdf28> whereas the legacy kernel runs it silky smooth

09:46 <asdf28> both

09:47 <asdf28> i have tried the ARM wayland opennGL drivers and mesa openGL

09:47 <chewitt> sounds like a rock > you < hard-place situation

09:47 <asdf28> and both kernel drivers, mali and lima

09:47 <asdf28> they all work, but slow

09:48 <asdf28> i just wanted to test if it's the kernel maybe

09:48 <asdf28> so it would be interesting to use the newer drivers with the old kernel

09:50 <asdf28> and i saw that in the github repository linked above, someone backported the DRM driver to it, that would be all that's needed i think

10:02 <asdf28> it's not relevant for LibreELEC though, because there are no 3D games in there

10:06 <asdf28> but with a fast enough 3D driver, lakka could be ported to use a mainline kernel as well

10:16 <chewitt> the trick is to find a repeatable test with lima, and provide feedback to the devs on what fails

10:16 <chewitt> then they can target something specific to fix

10:20 <asdf28> it's weird because it does not seem to be related to raw CPU or GPU performance. i remember that i fiddled with CPU and GPU clock speeds and it had no noticeable effect

10:21 <asdf28> there's also nothing that "fails", so to speak

10:21 <asdf28> it's just slow

10:21 <chewitt> ahh, I guess the current focus is conformance not performance

10:21 <chewitt> performance usually comes later once you've implemented a complete(r) system

10:22 <asdf28> i wouldn't expect it to be as fast as the proprietar driver though

10:22 <asdf28> yes

10:22 <asdf28> the openGL DRM driver from ARM is the one that i'm wondering about

10:22 <asdf28> the one that's called "libmali" in the libreelec packages

10:23 <chewitt> long-term I'd expect lima to be faster; less weird outdated stuff to be done in code

10:23 <asdf28> because it's also very slow compared to the legacy drivers that the board comes with

10:24 <chewitt> lima is still more of a community effort, panfrost has commercial interest behind it that drive focus

10:25 <chewitt> i'm sure it will get there, but, things take time

10:42 <asdf28> one thing that i noticed is that the 3D performance takes a big hit once the driver is using DRM

10:42 <asdf28> the older drivers all use the framebuffer device

10:44 <asdf28> but i can't directly compare them because i can't get the FB drivers to work on newer kernels

10:45 <asdf28> so i can't compare the drivers using the same kernel

10:45 <asdf28> this is why i wanted to try the DRM drivers using the legacy kernel

10:46 <asdf28> if it's slow there as well, this would rule out everything else

14:13 <narmstrong> comparing Lima and the ARM Mali acceleration on fbdev is not fair

14:14 <narmstrong> xdarklight: I'm back from vacation, we can discuss to solve your issues !

14:15 <narmstrong> xdarklight: hmm, *our* issues :-)

14:25 <asdf28> no, i was comparing the ARM fbdev driver with the ARM DRM driver

14:26 <asdf28> the DRM OpenGL driver is a lot slower

14:28 <asdf28> and i was wondering if the fbdev driver is faster by itself or because of something else, such as the legacy kernel

14:39 <narmstrong> "fast" how ?

14:39 <narmstrong> DRM will respect the display vsync, fbdev won't necessarely

14:39 <narmstrong> the fbdec "stack" is allmost inexistant, thus you have maximum performance

14:58 <asdf28> it's 20% faster in some 3D games, i'd say

14:59 <narmstrong> in fbdev ? what kind of games did you manage to run on fbdev ? emulators ?

14:59 <narmstrong> against what ? wayland ? or gbm ?

14:59 <asdf28> yes only emulators

15:00 <asdf28> i have also tried glmark, but the fbdev driver does not support some tests of it it seems

15:01 <asdf28> i compared it to the ARM wayland driver running in KMS mode (wayland is not involved in that mode)

15:01 <asdf28> i think that would be gbm then?

15:02 <narmstrong> yes, wayland libmali can work in gbm mode without the wayland compositor

15:04 <asdf28> if one would backport the meson DRM driver to the legacy kernel, you think it wouldn't outperform the old fbdev driver?

15:04 <narmstrong> no, it would not be faster

15:05 <asdf28> oh, that's interesting. i wasn't sure about that, but i wanted to try it

16:13 <xdarklight> hi narmstrong - welcome back!

16:17 <xdarklight> narmstrong: so I basically have multiple topics: 1) my understanding is that some of the meson-dw-hdmi code should be organized differently. this would help me as the code to integrate with the VPU registers is almost identical on the 32-bit SoCs, which don't use the DW HDMI controller though

16:18 <xdarklight> narmstrong: 2) common clock framework support for the video clocks and 3) any topic that comes up along the way ;)

16:20 <xdarklight> narmstrong: for 1) and 2) I have patches to "make it work", but it's not in a state where I can upstream it. so now that I've proven that I can make it work I'm curious to find the next steps with you. I believe that some of these steps will also make the drm maintainers happy/happier, because AFAIU some decoupling - related to 1) for example - is also what they want

17:52 <narmstrong> xdarklight: indeed, 1) would be useful for you hdmi controller and a base for the rework of the dsi integration

17:53 <narmstrong> for 2) we would still need to control a lot of the clock muxes to avoid CCF to use a random clock path

17:55 <xdarklight> narmstrong: for 2) Jerome's exclusive clock control is actually very handy. this is the magic I have to do for the 32-bit SoCs: https://github.com/xdarklight/linux/commit/c46eb61f699b467cff436467d601ae29a58b2eca#diff-25ccc410f0ec07addba8ed18615ae3c9434a6faf1fa4a0dbd1a4598e5e125a42

18:22 <xdarklight> narmstrong: when do you have time to work on a plan for all of this? also how do you like to discuss this (like: here on IRC, some kind of phone call, web meeting, ...)?

18:29 <narmstrong> xdarklight: I have currently a lot of work on non amlogic stuff so it’s hard to answer

18:30 <narmstrong> And usually I’m not very available in the evening, so maybe we could start sketching stuff by email then discuss via irc or slack ?

18:33 <xdarklight> narmstrong: sure. I think it makes sense to start by discussing the reorganization part first (I think it's mostly independent of the CCF stuff)