gistfile1.txt

memeka> I am having issues with alpha in ppssppsdl (using sdl2) .. but the libretro version is working fine
12:38 PM <memeka> libretro does not use STENCIL, but uses ALPHA instead ... no idea details ... but can STENCIL be disabled in ppssppsdl ?
1:55 PM <memeka> hm
1:55 PM <memeka> can I force the use of FBO565?
2:29 PM  → TheMajinZenki, AreaScout and Bobbo_ joined  ⇐ anarsoul|2, TheMajin|AWAY, chinho_, memeka, xsacha, Achiel and marzipanWhale quit  
5:04 PM  → sergio-br2, Achiel, ent, refs and chinho joined  ⇐ AreaScout quit  ↔ dogen, [SS] and Achielsan popped in  ↔ DocMAX (was DocMAX2), Viper168 (was Viper168_) and elgatov nipped out  

Thursday, February 19th, 2015
12:21 AM  → memeka joined  ⇐ Bobbo_ and Achiel quit  
12:32 AM <memeka> https://github.com/hrydgard/native/blob/master/gfx_es2/fbo.cpp#L157 has transparency issues with FBO_8888 ... using FBO_565 the image looks good with buffered rendering - unbuffered still have the alpha issues ... any idea why?
1:10 AM  → Achiel and dogen joined  ⇐ ent, John_K, refs, Kingcom, elgatov and sergio-br2 quit  ↔ David3k popped in  ↔ chinho, Viper168 and ludkiller nipped out  •  gigaherz → ghz|afk  
6:18 AM <[Unknown]> memeka: well, fbos are not created there when using non-buffered rendering
6:18 AM <[Unknown]> but, I guarantee that some games need alpha to render things correctly
6:18 AM <[Unknown]> so forcing it to 565 for FBOs that need alpha (aka other than 565) will definitely give you graphical glitches
6:19 AM <[Unknown]> an interesting note: on the PSP, stencil and alpha are both stored in the alpha bits of the framebuffer
6:19 AM <memeka> [Unknown]: the gl config that gets selected is: R8 G8 B8 A0 STENCIL8
6:19 AM <[Unknown]> for this? glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL);
6:19 AM <memeka> yes
6:19 AM <[Unknown]> so, then, the driver is smoking which drug?
6:20 AM <memeka> [Unknown]: it's an android driver workig in linux with libhybris :P
6:20 AM <[Unknown]> some exotic drug then
6:20 AM <[Unknown]> so then what, 565 gives alpha?
6:20 AM <memeka> [Unknown]: in retroarch all is good, but there is another GL config that gets selected: R8 G8 B8 A8 STENCIL0
6:20 AM ⇐ dogen quit (~dogen@50-0-50-8.dsl.dynamic.fusionbroadband.com) Quit: Leaving
6:20 AM <[Unknown]> that will cause problems for other games
6:21 AM <[Unknown]> no alpha will cause blending issues and render-to-texture issues
6:21 AM <memeka> so A0 STENCIL8 is the correct config?
6:21 AM <[Unknown]> no stencil will cause things to not render or to render outside of boxes
6:21 AM <[Unknown]> we need 8 bits of each: RGBA and stencil
6:21 AM <[Unknown]> plus at least 16 bits Z
6:22 AM <memeka> i have 32bits Z
6:22 AM <memeka> or 24
6:22 AM <[Unknown]> total of 56 bits (RGBA 32 + 8 alpha + 16 Z)
6:22 AM <memeka> yeah, i don't think my gpu has a config for rgbas 88888
6:22 AM <[Unknown]> if opengl offered some way to alias stencil and alpha, like the psp does, that would be *awesomesauce*, and we'd only need 48 bits
6:22 AM ⇐ chinho quit (~chinhodad@69-196-174-24.dsl.teksavvy.com) Ping timeout: 264 seconds
6:23 AM <[Unknown]> so then, retroarch isn't working, it's just working differently
6:23 AM <memeka> i see
6:24 AM <[Unknown]> what gpu is this again?
6:24 AM <[Unknown]> why would it not be able to do rgba32 + 8 stencil? almost sounds like it's doing what the psp does and storing alpha and stencil in the same bits
6:24 AM <memeka> gpu is PVR544mp2
6:24 AM <[Unknown]> hmm, if it really can't do both alpha and stencil, that would explain a LOT
6:25 AM <[Unknown]> we have a bunch of weird glitches that only happen on PowerVR 54*
6:25 AM <memeka> let me quickly check
6:25 AM <memeka> aaa
6:25 AM <memeka> really? :(
6:25 AM <[Unknown]> well, some of them seem to be other issues
6:25 AM → chinho joined (~chinhodad@69-196-174-24.dsl.teksavvy.com)
6:25 AM <[Unknown]> for example, we tracked one down to mod() not actually doing a modulus
6:25 AM <memeka> lol
6:26 AM <[Unknown]> we replaced it on powervr cards with the mathematical equivalent, and things improved
6:26 AM ⇐ chinho quit (~chinhodad@69-196-174-24.dsl.teksavvy.com) Client Quit
6:26 AM <[Unknown]> another issue is afaik it reduces all shader vars to lowp
6:26 AM <[Unknown]> at least in frag shaders
6:27 AM <memeka> i dunno what that means
6:27 AM <[Unknown]> meaning, it has less bits of precision
6:27 AM <memeka> but i did notice the performance was way lower than what i expected
6:27 AM <[Unknown]> I think lowp is like a 12 or 8 bit floating point
6:27 AM <memeka> it was lower than mali400mp4 and lower than mali450mp2
6:27 AM <[Unknown]> powervr is also way slow at alpha testing, something psp games use like it's on sale
6:27 AM <memeka> yeah i removed alpha test
6:28 AM <memeka> i did all the speed hacks ...
6:28 AM <memeka> with buffered mode .. it's almost playable ... ~50fps
6:28 AM <memeka> and unbuffered actually similar ...
6:29 AM <memeka> [Unknown]: btw, PCMain.cpp needs updating
6:29 AM <memeka> with SDL2, you don't need EGL_Init and EGL_Open EGL_Close
6:29 AM <memeka> also, swapbuffers can be done with the same code thru SDL2
6:30 AM <memeka> as non-EGL
6:30 AM <[Unknown]> hmm, well, I don't know anything about SDL/EGL, but if you send a pull I'm sure ector will look (or maybe xsacha)
6:30 AM <memeka> SDL_SwapWindow
6:30 AM <memeka> let me quickly check egl config
6:32 AM <[Unknown]> I dunno if there are any powervr-specific profiling tools or perf guides, there may be more (aside from not alpha testing) that can be done on it to improve perf
6:33 AM <[Unknown]> I only have an adreno
6:35 AM <memeka> [Unknown]: I am not sure how much libhybris is reducing the performance
6:35 AM <memeka> i think android drivers are softfp, linux is hardfp, and hybris is doing the conversion
6:37 AM <[Unknown]> probably, Android is generally softfp
6:41 AM <memeka> EGL_CONFIG_ID = 14 EGL_BUFFER_SIZE = 32 EGL_ALPHA_SIZE = 8 EGL_DEPTH_SIZE = 24 EGL_STENCIL_SIZE = 8 EGL_TRANSPARENT_TYPE = 12344 EGL_LUMINANCE_SIZE = 0 EGL_GREEN_SIZE = 8 EGL_RED_SIZE = 8
6:42 AM <memeka> hmm, it's there ... i will have to check when i get home if there are still alpha issues...
6:43 AM <memeka> but i remember using config 14 before...
6:49 AM  ↔ ludkiller nipped out  
6:50 AM <memeka> [Unknown]: Some Android devices (especially Mali, it seems) composite badly if there's alpha in the backbuffer.
6:50 AM <memeka> So in non-buffered rendering, we will simply consider the dest alpha to be zero in blending equations.
6:51 AM <memeka> #ifdef ANDROID if (g_Config.iRenderingMode == FB_NON_BUFFERED_MODE) { if (glBlendFuncA == GL_DST_ALPHA) glBlendFuncA = GL_ZERO;
6:51 AM <memeka> [Unknown]: any idea what effect would this have in my case if I remove the ANDROID ifdef ?
6:52 AM <[Unknown]> might help, try it... there are probably a few other things behind incorrect defines
6:53 AM <[Unknown]> but it's an uncommon blend eq anywya
6:53 AM <[Unknown]> *anyway
6:53 AM <memeka> i see
6:53 AM <[Unknown]> that's checking for dst alpha as the multiplier for the src color
6:53 AM <[Unknown]> oh, wait, there's this too: if (glBlendFuncB == GL_DST_ALPHA) glBlendFuncB = GL_ZERO;
6:54 AM <[Unknown]> that's at least less uncommon
6:54 AM <[Unknown]> but generally it's src * src.alpha + dst * (1 - src.alpha)
6:54 AM <[Unknown]> which isn't affected by that if
6:55 AM <memeka> yeah there are a few cases there i havent pasted them all
6:55 AM <memeka> just wanted to ask if any of them would screw alpha, in case i have them activated
6:55 AM <[Unknown]> HdkR: https://github.com/hrydgard/ppsspp/issues/7504
6:56 AM <[Unknown]> we just got a bug report that games with high graphic quality run poorly on weak devices, but games with low graphic quality run fine
6:56 AM <[Unknown]> ...
6:56 AM <[Unknown]> memeka: well, all the cases involve dst.alpha as the blending multiplier, which is not that common... would only affect some games
6:56 AM <[Unknown]> Persona uses it for example
6:57 AM <[Unknown]> and actually, dst.alpha on the psp means stencil, really
6:57 AM <[Unknown]> we have to do all sorts of tricks to try to fill the dst alpha with the value that ought to be in the stencil buffer
6:57 AM <memeka> ok
6:57 AM <memeka> i shall try and see how it looks like
6:58 AM <memeka> thanks for the help
6:58 AM <memeka> hilarious issue
7:43 AM <HdkR> [Unknown]: lol
7:47 AM → John_K joined (~John_K@kelley.ca)
8:12 AM  → Kingcom and •ector (opped) joined  ⇐ AlexAltea quit  ↔ memeka nipped out  
10:10 AM <memeka> [Unknown]: so it's possible the issue is somewhere else ... even with 8 8 8 8 8 still get black textures
10:10 AM <memeka> do you know where it's create_fbo for unbuffered ?
10:10 AM <memeka> the one in native/gfx_es2/fbo.cpp it works for buffered only
10:22 AM <bigpet> memeka: I think the whole point of unbuffered is that there is no fbo
10:23 AM <bigpet> as in, it renders to the default framebuffer
10:24 AM <memeka> bigpet: in gfx_es2/fbo.cpp create_fbo I could set depth to FBO_565 and it would eliminate alpha issues that i was having ... in buffered mode ... can i do something similar in unbuffered mode?
10:24 AM <memeka> can i set depth manually ?
10:37 AM <•ector> https://github.com/hrydgard/ppsspp/issues/7502 hmm, still issues with memcpy/memset replacement functions....
10:38 AM <•ector> memeka, in non-buffered mode you are relying on the backbuffer, so you need to modify the OpenGL init to disable destination alpha if you really want to do it (but I think it will break some things..)
10:40 AM <memeka> ector: there are still some things that i think are hardcoded to 8888 ... i request an opengl config with alpha 0, red 5, green 6, blue 5 => but still have alpha issues, so it's not really what i want ...
10:41 AM <•ector> so, I missed the start of this discussion .. what game is having issues?