zIndex - Can't get it to work

FlyingTomahawk

what video player are you using?

I haven't touched my Pi for a while and I updated today all the core packages and I was updating my theme when I realized that if I set ES (v2.3.1RP) to use the OMX player (HW accelerated) it covers the marquee and anything else like it has the highest zIndex number.
Even setting my marquee zIndex value to 1000000 didn't fix it.

I don't want to go too off-topic here but to me the new ES update feels buggy and heavy on the resources of the Pi. I mean I really appreciate the work that the guys put into ES to improve it and all but I kinda have the feeling that it has become too much maybe?

Like I said I haven't touched my Pi stuff for a while and this are just a couple bugs that I had today while updating my theme.

loosing connection to controller (Buffalo SNES) only a restart through ssh can fix it
if OMX is activated Pi temps spike really high up. I had the temp icon and power icon showing a couple of times before I decided to install my fan into the case.
switching between themes can cause a freeze and nothing works anymore.
Got the blocky text and white images with 256 GPU memory. Raised it to 320 and it somewhat works now but still getting the bugs mentioned above.
when shutting down or restarting my Pi I could sometimes see glGetError 0x505 errors listed

These are just a few bugs that I could see today which were not there with the previous ES versions. I thought maybe my theme is heavy so I switch to carbon but the same happens there.

Anyways, I guess @jdrassa will sooner or later chime in I hope and explain to us what exactly happens with the video zIndex property.

asmithau

@FlyingTomahawk

Thanks for the info. I turned off the OMX videoplayer and this did resolve it, with the side effect of the video playing poorly of course.

In answer to your other listed issues, I do agree in seeing the power icon more often (I have the official power supply and a heatsink in place), but I haven't seen issues switching between themes, the text / white images or the error with shutting down.

Appreciate your quick response and at this stage I'll wait to hear from @jdrassa

Thanks again :)

asmithau

Scratch that - just saw the other issues you mentioned too....

jdrassa

@asmithau When using OMX player z-index values are ignored. This is why it was implemented as an option. OMX player works by essentially playing the video in a separate process that is rendered on top of ES.

jdrassa

@FlyingTomahawk said in zIndex - Can't get it to work:

@asmithau

what video player are you using?

I haven't touched my Pi for a while and I updated today all the core packages and I was updating my theme when I realized that if I set ES (v2.3.1RP) to use the OMX player (HW accelerated) it covers the marquee and anything else like it has the highest zIndex number.
Even setting my marquee zIndex value to 1000000 didn't fix it.

I don't want to go too off-topic here but to me the new ES update feels buggy and heavy on the resources of the Pi. I mean I really appreciate the work that the guys put into ES to improve it and all but I kinda have the feeling that it has become too much maybe?

Like I said I haven't touched my Pi stuff for a while and this are just a couple bugs that I had today while updating my theme.

loosing connection to controller (Buffalo SNES) only a restart through ssh can fix it

if OMX is activated Pi temps spike really high up. I had the temp icon and power icon showing a couple of times before I decided to install my fan into the case.

switching between themes can cause a freeze and nothing works anymore.

Got the blocky text and white images with 256 GPU memory. Raised it to 320 and it somewhat works now but still getting the bugs mentioned above.

when shutting down or restarting my Pi I could sometimes see glGetError 0x505 errors listed

Tagging @pjft in case he hasn't seen this. It is odd that you are seeing temps spike high when using OMX player since it is supposed to be more efficient then VLC.

FlyingTomahawk

@jdrassa

Everything seems to be less stable at the moment at least when i try to work on my theme. I guess once settled for one theme things run smoother?

asmithau

@jdrassa - Ah, no worries. That's make sense.

Thanks for coming back and letting me know, and keep up the great work!

pjft

Thanks for tagging me @jdrassa ! I hadn't seen this, no.

I am intrigued by OMX making temps spike really high up, and would like to dig into that. And yes, z-index does not work with OMX player.

@FlyingTomahawk , some guidance:

losing connection to controllers, unsure what to do about that. Seems to be an unfortunately common updated driver problem, judging by similar reports in the forums?
OMX, would like to debug. Could you tell me a bit more about this, namely: do those videos work well with VLC without spiking up temperature and such? What resolution are they and codec? If you can share one of them via Dropbox/Google Drive/Mega, send it my way. Also, could you log in via SSH when that's happening and run topand see what processes are effectively running and taking up most of the CPU? How many emulationstation processes do you see?
Blocky text/switching between themes/memory, glGetError 0x505 and such. You got it right by increasing GPU memory, I suppose, though it shouldn't be needed. What you really need to do is reduce VRAM. Set it to 100 or even 80 if your theme works. (I should really try to get a fix for VRAM in ES).

I'll try to explain it here how it currently works, as I've done it a few times in different places.

The VRAM setting probably should be called "Max Texture Memory" instead. What it does is it allows the user to load textures (from themes, or even the videos playing) until that max is hit. From then on, it will explicitly unload older textures in order to make room for newer ones. This was part of the fix for the white screen of death.
What happens, though, is that it is completely disconnected from the actual available GPU memory. So, if you set VRAM too high (in particular, higher than the amount of available GPU memory), it will try to load textures at will and eventually run out of memory, resulting in similar behavior as the WSOD, only more limited these days. That's the glGetError 0x505 for you, as well as white images and blocky text. It's the GL pipeline saying that it doesn't have memory to render whatever it's trying to render.
As such, increasing texture memory might/will help, but if VRAM is left unchecked, you're just delaying the problem. So, before increasing the GPU split, I'd rather start with reducing VRAM and seeing if it helps. I personally run a 256 split with 80VRAM, using the Comic Book theme which is reasonably heavy image wise. I also ran TrokyFran for a while with the same settings and it works. The only case where it conceptually wouldn't work would be if loading a single system view and gamelist elements would take up more than 80MB of GPU memory, and that would need to be quite a heavy theme. Unfortunately videos aren't taken into account here (they're loaded separately).

From experience, booting up a clean Pi and loading ES will still leave something around 100MB-150MB of GPU memory to use, so I would usually err on the side of caution and stick to the lower bounds, as textures are loaded in full chunks - meaning that if the used GPU memory is still lower than the max VRAM setting, it will load the texture regardless of its size (as we don't quite know how much it will take prior to loading it). So, conceptually, let's say you have:

MAX VRAM: 100MB
Used VRAM: 99MB

And try to load a new texture, it will load it without unloading anything. Meaning that, if the new texture takes up 20MB (which isn't that rare, for a 1080p screen) in GPU memory, you'll be using 119MB of GPU memory. Only at the next texture load will it unload older textures until it's using up less than the set VRAM.

An example of available GPU memory for me (just run sudo vcdbg reloc to get the same for you):
On the command line, ES not loaded, 256MB split:
192M free memory in 17 free block(s)
largest free block is 164M bytes

With ES loaded, and 80 VRAM setting:
130M free memory in 36 free block(s)
largest free block is 130M bytes

I believe that the firmware will always allocate 16MB of the GPU memory to video hardware devices, which means out of that we only have access to 240MB, and I take it that the 48MB in use are either leftover textures that weren't unloaded, or maybe actual framebuffer cache for the terminal sessions I'm running and whatever. Still, it should give you a perspective on GPU memory as a whole.

Hope the explanation helps, and try that out and let me know how it goes.

FlyingTomahawk

@pjft

Thank you for the very well written explanation. Now things make more sense.
I had my VRAM set at 500 and GPU 256 after getting those bugs I changed to VRAM 800 and GPU 320. So first thing I did today is reduce those numbers to VRAM 80 and GPU 256. So far everything runs smooth without hick ups or lags.

Then I tested the players.
First without fan, I get around 78.2C with the VLC player and around 69.1C with the OMX player. With fan installed I get around 54.2C with the VLC and 47.8 with the OMX player.
I guess this is to be expected?
I must mention that the room temperature is lot cooler today. So I can very well imagine that the Pi temps would go somewhere into the 80+ area without fan and on a hot summer day.

I cannot play videos with the VLC player. Too choppy and too many lags.
I got the videos from the UXML Scraper, default resolution 640x480 mp4 format.
Here links to two SNES videos that run terribly on VLC but very smooth with OMX.

Video 1

Video 2

Is there any way to add zIndex to OMX? Or is it technically not possible?
@asmithau sorry for hijacking your thread here. I will try to keep it short from now on.

pjft

@FlyingTomahawk Thanks for testing out and for further explanations.

I do hate it that VRAM allows users to shoot themselves in the foot so easily - I should probably at least add a warning popup when someone sets it too high.

As for players, correct, this is expected: VLC is a lot more resource intensive than OMX Player. It's also not hardware accelerated, so I'd expect temperatures to be a lot higher on VLC than OMXPlayer, as well as some videos not working on VLC. In my experience, VLC can handle at most 480x360@30fps without struggling, and it will still likely overheat after a while of ongoing use - 10-20 mins, in my experience, though YMMV.

I believe you had mentioned, though, that OMX Player was spiking in temperature - which led me to believe that it was performing worse than VLC. Is that not the case?

I'd certainly expect temperature to rise when playing videos (and rising more depending on the resolution and such) but I wouldn't expect it to be worse than VLC.

As for z-index on OMXPlayer, that is indeed a technical limitation/challenge. I won't go into much detail, but it's a separate rendering pipeline. You can think of it at the moment as separate rendering canvases, and that you cannot get OMXPlayer to be rendered within the ES canvas - it's either behind or in front of it, but it cannot be in between different elements.

Quite a few people have looked into it but arrived to no satisfactory conclusion for now.

Not saying it can't be done, but it's not something that's being explored at the moment given the amount of time and dead-ends people ran into so far.

I suppose there's some hope in getting a proper hardware accelerated VLC bundled with Raspbian, which could perhaps address some of these challenges, though it's unclear from some of the tests whether it doesn't suffer from the exact same problem as OMX Player.

So that's the status.

FlyingTomahawk

@pjft said in zIndex - Can't get it to work:

I believe you had mentioned, though, that OMX Player was spiking in temperature - which led me to believe that it was performing worse than VLC. Is that not the case?

It was the case on that particular day. It could have been a combination of high room temps, large video size since I was testing some new layout for my theme and my Pi settings.
Today all seems to be running as expected which is a relieve so I know now that my hardware is correctly configured. And yes, a warning message if VRAM is set too high would be a good idea.

I changed my theme layout to accommodate the OMX player by moving the marquee out of the way so that it won't overlap. But I can very well imagine that it will not look good on theme layouts like the NeoGeo/Capcom theme by ruckage.

alt text

Thanks again for taking the time to help out and for improving ES in anyway possible.

pjft

Not at all, thanks for the interest and for raising these things.

Indeed, OMXPlayer was launched to accommodate users who don't need overlays on top of videos and want to have an overall better performing experience on the Pi.

Alas, it does have those known limitations, which is unfortunate and will definitely not be especially compatible with some themes.

It's not ideal, but... baby steps. We'll get there!

Thanks for the note, and keep up the good work.