Alpha blending issues on some platforms

[memeka]

I am trying to get ppssppsdl to run on several ARM linux platforms.

1) using Mali fbdev drivers and my own SDL2 video context driver (and slightly modified init code in PCMain.cpp), I can get it to run on Odroid C1 (Mali450) and Odroid U3 (Mali 400). On Odroid-C1 however there are issues with alpha blending, the transparent textures including the moving bits in the PPSSPPSDL menu have a black background. The same build works well on U3. Apparently the amlogic in C1 does alpha blending internally - and this might be the issue. Reducing the depth from 32bpp to 16bpp (which cannot be done on the fly, it's a boot parameter of the board) solves the issue for C1 as well - but can I somehow make this work with 32bpp as well?

2) same issue on a PowerVR422MP2 (Odroid XU), using libhybris to have GLES2 from its android driver. I did a similar procedure there, my own SDL2 video context driver and slightly modified init code in PCMain.cpp. There is an issue with libhybris (does not allow ppsspp to create an egl_surface after sdl2 took over, so I am getting the egl_surface created by SDL2 using something like (wiki.libsdl.org/SDL_SysWMinfo) for SDL_SYSWM_ANDROID - I am getting both the native window and the egl_surface from SDL2). Again, things work except for the alpha blending

All of them (including C1 in 32bpp, PowerVR) do not have this issue when using the libretro core... so i'm guessing it must be something which is set up from SDL init... I've tried setting up SDL2 with PIXEL_FORMAT RGB888 instead of RGBA8888, I tried setting in PCMain.cpp (github.com/hrydgard/native/blob/master/base/PCMain.cpp#L442) ALPHA 8 (it's currently setting only RGB) and several other combinations or similar things ... nothing worked

Any ideas?

PS - also, the PVR422MP2 performance was similar (or worse) than Mali400, which makes no sense to me, as performance should be x2 for PVR... any ideas why?

[[Unknown]]

Well, a few things:

1. Just a note about Mali-400. With most drivers, I'm pretty sure many of the shaders we generate (depends on game) are too complex, causing it to use the CPU for lighting and transforms rather than the GPU (it turns off the hardware transform setting.) This only occurs in some areas of some games, but if/when it does it will get poor performance. So Mali vs PowerVR depends on where you're testing.

2. As long as you use buffered rendering (which should be, "allow games to use buffers during rendering"), games at least shouldn't be using the backbuffer's depth/stencil/alpha. So if games don't look fine, there's something else going on. If games do look fine, then yeah, probably there is some issue with alpha indeed.

3. PowerVR is not very fast when you discard pixels, which has to be done when using the outdated technique of alpha testing. Unfortunately, pretty much every PSP game ever made uses alpha testing, and many use it very heavily. We aggressively try to optimize it out, which helps a lot afaik, but it still gives a big penalty to PowerVR. There's a speedhack in settings to disable alphatesting entirely, it will definitely cause glitches in most games though.

Is Qt able to build on any of these platforms? Might be interesting if that works. Does libretro use something other than SDL? What does it use?

-[Unknown]

[memeka]

Hi,

Thanks for the reply. I have tried the alpha testing setting, I know that PVR is slow in that.
The alpha blending issue appears not just in the games, but also in the PPSSPPSDL menu (the background of the +, X, O floating around)...
I did not try Qt, but I think that under X11 things also look fine.
So it must be a difference in framebuffer drivers - e.g. Mali400 and Mali450 use v similar drivers, but there is a difference between the samsung fb driver in Odroid-U3 (where there is no alpha issue) and the amlogic driver for the C1.

Libretro has a graphic context driver for framebuffer - which is the one I basically ported to SDL2. So SDL2 initialises EGL the same way as retroarch does. Hence my suspicion that there must be some settings from when the screen is set up, and not the emulation code itself.

I am not sure if this matters, but the retroarch context driver does not support shared context, so the libretro version only works with buffered rendering. in PPSSPPSDL non-buffered also works - well, with black instead of alpha, of course.

I hope what I am writing here makes sense, it's pretty late in the night

[Henrik]

That blending wouldn't work at all, not even in the menus, sounds really weird - we use standard OpenGL alpha blending and it works fine on my new Mali phone..

[memeka]

(02-09-2015 07:23 AM)Henrik Wrote:  That blending wouldn't work at all, not even in the menus, sounds really weird - we use standard OpenGL alpha blending and it works fine on my new Mali phone..

I doubt it's running linux in framebuffer
In Android, even in Linux X11, things look good. These issues are only with Linux fbdev and SDL2.

I tried mupen64plus standalone and I am getting similar issues, although like I said before, with retroarch and libretro cores (ppsspp-libretro, mupen64plus-libretro) I don't get black instead of alpha.

Since mupen64plus is also using SDL2, it must be a SDL2 init thing. And since I am using the same context driver code as retroarch, it must be in some other part from SDL2 ...

It's strange that this issue does not happen when framebuffer is set on 16bpp, or with Odroid-U3. I will try getting an egl config that has 16bpp, maybe that will change something...

UPDATE: checking the egl_config that retroarch and sdl2 gets - it's the same! So what can SDL2 do extra after context initialisation that screws up alpha... ?

[Henrik]

Sounds like a GPU driver issue, really, then.