ARM Mali 450 and the Amlogic S905

[physkets]

According to tom81 on the Odroid forum (scroll towards the end), this also works on the Odroid-C2 running the Amlogic S905 SoC with the ARM Mali 450.

Do you think you could add it formally into your list of supported devices? Or will you have to test it yourself first?

[ssvb]

I don't have an ODROID-C2 board myself. The xf86-video-fbturbo ddx can't run OpenGL ES at full speed on this board because zero-copy buffer swaps support needs a better integration with the display driver, but it should somehow work nevertheless (if your mali drivers are using UMP and not DMA-BUF). I have also seen some person in the #odroid irc channel claiming that there are some problems:

<ParkerR> How in the heck do I get xf86-video-odroid-c1 to work? I see people keep suggesting to use fbturbo but fbturbo has some funky blacks. The odroid-c1 driver just bails out with no screens found. (Arch Linux ARM)
<ssvb> ParkerR: has it? was this fbturbo problem reported anywhere?

I did not get any response though. Basically we need more information.

[physkets]

I don't really understand what you said:

zero-copy buffer swaps support needs a better integration with the display driver

But yes, it does look like it works sometimes. Even in the forum post that I shared above, there are different reactions to it. In one case it seems to load the Mali450 drivers, while in one, it doesn't.

Have you seen the Amlogic S905 data-sheet ?

EDIT: I just looked. There isn't anything much on the GPU in the data-sheet.

[ssvb]

Zero-copy means that we are not moving memory buffers around unnecessarily, so that the Mali hardware outputs its data directly to the place where the display controller picks it up for showing on the screen. That's how you can get hundreds of FPS (without vsync) or perfect tear-free 60Hz (with vsync) and low CPU usage. This currently only works on Allwinner hardware.

But if high performance is not required, then Mali can output data into a generic offscreen buffer. Then this offscreen buffer gets copied to the framebuffer using the CPU. The fbturbo ddx driver works in this way on unsupported hardware and this is not particularly fast. But the other ddx driver implementations may be even slower if they do more redundant things.

But yes, it does look like it works sometimes. Even in the forum post that I shared above, there are different reactions to it. In one case it seems to load the Mali450 drivers, while in one, it doesn't.

Then let's wait until the people from the odroid forum figure it out.

Have you seen the Amlogic S905 data-sheet ?

No.

[physkets]

Thanks for the explanation!

[VittGam]

By the way, the "funky black" issue can be solved workarounded by writing to a register to disable 32-bit alpha transparency:

echo d01068b4 0x7fc0 > /sys/kernel/debug/aml_reg/paddr

It's the same problem that is present in the Raspberry Pi when using a 32-bit framebuffer, and on the Pi it can be solved with framebuffer_ignore_alpha=1 in /boot/config.ini.

[ssvb]

@VittGam It would be great if you could explain how to reproduce this "funky black" problem and how it manifests itself. I think that we need a separate bugreport for it in the github tracker. I don't have any Amlogic S905 hardware, but still can try to check it on my Raspberry Pi 2. Thanks!

[VittGam]

When the register is left at its default value (0x3fc0), this is how the screen is rendered.

[ssvb]

Thanks. Yes, it looks like the normally unused alpha channel (the 8 padding bits in the XRGB32 format) might be interpreted by the display hardware in some cases. Could you please also provide the output of running the "fbset" tool?

If the kernel driver reports that the alpha channel is used, then the X server might need to explicitly set it to 0xFF. Which would be probably the right thing to do, but also introduce some performance loss.

And I suspect that the xf86-video-fbdev ddx probably has exactly the same problem.

[VittGam]

Yes, that bit disables alpha channel parsing, so probably setting it to 0xff instead of leaving it undefined (and so random) should fix the issue. In fact there's the same problem with the fbdev driver.

Here is the output of fbset:

mode "1280x1024"
    geometry 1280 1024 1280 1024 32
    timings 0 0 0 0 0 0 0
    rgba 8/16,8/8,8/0,8/24
endmode

[ssvb]

Yes, since the kernel reports that there are 8 alpha bits in use, the X server can use this information to do something reasonable. Normally the fbset tool reports something like this:

mode "1920x1080"
    geometry 1920 1080 2560 1440 32
    timings 0 0 0 0 0 0 0
    accel true
    rgba 8/16,8/8,8/0,0/0
endmode

Maybe just refusing to work at all would be the most reasonable thing to do? Because setting these alpha bits to 0xFF is not free in terms of CPU cycles and we should not encourage using suboptimal framebuffer configuration resulting in bad performance.

[VittGam]

But the alpha layer is there for a reason... I've read somewhere (I think the Odroid forum but I'm not 100% sure) that the video layers are below the framebuffer layer, so the rendered video won't be visible in the spots where the framebuffer is opaque... And I think that this actually makes sense, since the S905 is a set-top-box chip, so the player/STB GUI can be rendered over the video with alpha transparency where needed.

That said, I don't know how to actually render video to the video layers with Linux and X11; but I can try to switch the color bits to 24 and see what happens.

[VittGam]

It seems to be working with m_bpp set to 24.