Solution for " White Screen of Death "
-
@fieldofcows said in Solution for " White Screen of Death ":
This cache is configurable in es_settings.cfg and via the UI in "Other Settings" -> "VRAM LIMIT". The default is 100Mb and I can push my RPi3 to about 120Mb before it starts dropping textures. Note that this limit does not include fonts which load on top of this limit.
i don't know if it's useful, but
sudo vcdbg relocgives you the free vram (in a bit of an unwieldy format)
sudo vcdbg reloc |grep "\[" | awk '{split($0,a," "); print a[12]}' | awk '{split($0,a,","); print a[1]}' | awk '{sum+=$1}END{print sum}'this gives it in bytes (stole this from somewhere.. not sure if it's properly working)
vcgencmd get_mem arm vcgencmd get_mem gpugets the memory split for system and gpu respectively.
obviously you need some sort of fallback for none-pi systems, but maybe this could be used to pick the cache? not sure.
-
@fieldofcows I looked through your last commit, and I've got an idea for prioritizing textures based on proximity to the current system, but it would involve a data structure change. I can't think of a way to do it with the current implementation (sorry!), but I also only looked through your changes, and have not dug through the rest of the code. That being said, feel free to ignore the rest of this post if it's completely stupid :). You know the system far better than I do.
If you've got an array (or ArrayList or equivalent), and each index represents a system (or a particular filter or view, from the metadata improvements I described), you can just start putting textures into your cache starting from the first index and moving outward in both directions one index at a time. When the cache is full, stop. Every time the user moves from one system to another, just unload the most distant system from the opposite direction and load the next closest (not yet loaded) system in the current direction. Edit: you'd only need to keep track of the current index (which I think you already have), and the left and right extents. The array could just be an array of bits, as well (loaded vs not loaded), to save on memory.
For example, if there are 20 systems and the user is at index 10 and the VRAM can hold 10 textures, the cache will hold items 5 through 14 (or 6 through 15, depending which direction you start with). Moving to the right would unload 5 and load 15, whereas moving to the left would unload 14 and load 4. Wraparound can be handled with modulus. With the metadata improvements and custom views/filters, that would just involve updating the array and the loaded textures each time a view is created or deleted. I also thought about using a modified red/black tree or something similar, but figured that the array would be the simplest to write and probably the fastest to execute.
I also tried to look through the code to see if I could spot where the "onKeyRelease" event is getting lost, but couldn't spot it from my relatively short read-through.
-
Guys if you need some "big" theme to test I can upload the uncompressed and unoptimized 1080p version of oldroom, it has very heavy images... XD
But it "only" has 21 systems right now.
Edit: Even with that amount of systems, and that heavy theme, I don't have white screen under windows OS, so maybe it's a Rpi only problem... btw I have 8gb ram.
-
@Nismo Sure, if you want to upload it, I will test it on my Pi. If you also have a compressed/optimized version, I can test that one too and compare the results.
-
@MWGemini ok, i'll upload in a minute.
-
@MWGemini Here you have all new oldroom 1.8 themes in one single zip file: http://www.mediafire.com/file/ph8g8jh7s2vfayi/oldroom_themes.zip
- Crude original not optimized version (22.8mb)
- 1080p version (13.9mb)
- 720p version (recommended) (9.31mb)
Enjoy.
-
@Nismo I tested all three variants. The first two could not fit in my 100mb cache, so there was the normal hiccup as systems loaded and unloaded. The third fits entirely in cache (58.45mb with my systems), so transitions are very smooth.
I probably don't have the images scraped in the way that your theme is expecting them, because all I see on the detailed view is an empty desk (no TV or anything), but in terms of the white screen, @fieldofcows appears to have it fixed.
One thing I did notice is that while switching from one theme to another, all systems were loaded with white backgrounds, and I had to drill in to the system and drill back out to start displaying the images and ribbon. In fact, it did appear to be a full WSOD- no ribbon or anything else displayed, only the debug data. Minor annoyance, but figured it was worth mentioning. When switching themes, the cache appears to be loaded (based on the RAM debug numbers), but the images don't appear at first. I also tried just switching themes and letting the Pi sit for several minutes to see if it was a latency or timing issue, but that did not appear to have any effect.
-
@MWGemini You don't see tv's because the video view is not loaded. That's because you doesn't have video tags in your gamelist.xml, you need almost one game with video tag in gamelist.xml and then the video view will be loaded for that system.
About the systems with white background it doesn't happen to anybody with the current version of ES, you are the first one that have that problem, maybe it's the new WSOD fix that have some strange behaviour.
Make sure the system exist inside the oldroom theme folder, only 21 systems supported right now.
-
@Nismo I would be fairly certain that it's just a bug in the WSOD fix and has nothing to do with your theme. I've tested a bunch of different themes now (both with and without video) and they all exhibit the same behavior.
-
-
@fieldofcows Working well, as far as I can tell. There is definitely a noticeable hiccup when scrolling through the system carousel, but considering that the alternative is a completely unusable system, I think it's a great improvement.
I also noticed that while installing new themes via the Retropie->Retropie Setup script that the setup program was slow to respond to inputs. I've never seen that before, but it might be completely unrelated.
-
I've been working hard on this over the last couple of days. I wasn't happy with the jerkiness that is introduced when the memory limit is reached, especially as we have some CPU cores sitting there idle.
After some experimentation, I determined it would be too hard to make the current TextureResource load in a background thread so I've done some fairly extensive surgery on this area to tidy the code up, provide a maximum VRAM limit as before but reload images from disk when needed in a separate worker thread, instead displaying a placeholder image whilst it's loading.
I've just got it to the stage where I can try it out on a RPi3 and I'm pleased to say it runs as smoothly as anything. I've still got some work to do (SVGs often render upside down, add some more thread safety and I would like to blend from the transition image to the loaded image rather than just 'jumping') but it's looking good.
-
@fieldofcows sounds great :)
-
@fieldofcows I second what @BuZz said- sounds great! Let me know when you have another version that you'd like me to test, or if you'd like some help on the dev side.
-
Thanks guys - I was very wary of submitting the previous fix. I can just imagine new users that have never seen a WSOD saying "I've added 20 systems and ES has gone slow and jerky". Hopefully the new fix will solve all that.
-
@fieldofcows impressive work!
-
@fieldofcows said in Solution for " White Screen of Death ":
I can just imagine new users that have never seen a WSOD saying "I've added 20 systems and ES has gone slow and jerky".
That level of consideration is much appreciated. Thanks for all your hard work!
-
The threading is working really well. Everything runs really smoothly with late-loading images fading into view when ready without too much distraction for the user. I'm not quite ready to say it's finished yet but if anyone wants to try it they can get it here:
https://github.com/fieldofcows/EmulationStation/releases/tag/v0.3-RPi-2
Same instructions as I provided in a previous post.
This release is for testing only and has some known issues:
- Textures are not always rendered after changing themes
- Sometimes carousel images are rendered the wrong size (observed only once)
- Opacity of loading image is sometimes incorrect
In addition, more testing needs to be applied to the following areas:
- Launching and resuming from a game
- Video preview - as yet completely untested but has been reworked
- General stability
Adding threading to something that was not designed for it is always a daunting task so the more testers the better :)
-
Just in case anyone else is following the same steps as in the earlier post, don't forget to delete the old emulationstation file you downloaded previously (if you tested the previous version using the same steps). I forgot to do that the first time and then wondered why it looked the same...
@fieldofcows this version is much smoother. The loading hiccup is basically gone now. Thank you! I also really like the new fade-in effect for background images (I tested with both a slide and fade transition as well). I was able to get it to where some background images didn't load, however (just the white screen as the background). I was trying to scroll through the carousel as rapidly as possible, and eventually some just decided never to load again. I noticed when this happened that the VRAM was well above my 100mb cutoff (at about 150-160 of the 167.26 theoretical max displayed). If I drilled into a system, it did seem to flush the excess down, and then scrolling through the carousel until another image had to be unloaded seemed to get it working as it should again.
Interestingly, sometimes the backgrounds would be already loaded, but the system name in the center of the gray carousel bar had to be loaded, which is an interesting visual effect with the fade in when it loads. Personally, I think I like having that center name portion not fade in, so I'd prefer to have them all loaded before the background images, but I'm sure others will feel differently. I have not been able to replicate the "image being rendered the wrong size" issue you mentioned. Images to the left and right of the center are drawn slightly smaller than the center system name, and at a different opacity, but once in the center, they always looked normal to me.
When switching themes, I did see that background textures often didn't load at first. Drilling into a system and back out helped fix this (drilling in appears to cause the VRAM to be purged back below the threshold I set, default of 100mb). I did also notice some corrupted text graphics in the menu after switching themes as well. All first-level menu text was fine, but drilling into any menu item showed odd symbols in place of some text controls (but not all).
The video preview stuff appears to be having problems. Although I haven't scraped my videos the way the OldRoom theme expects it, videos played there, but were interlaced with black frames. After switching back to my modified tronkyfran theme (without specific video support, but where videos still used to display just fine), looking at a game with a video actually froze the Pi and required a reboot. While shutting down (I use an ATXRasPi for power control), I noticed an error message (I think three of them) about a buffer underrun, but wasn't able to see enough of it to provide more details. If you can point me to the relevant log files, I can paste them, upload them, or email them to you, whichever you prefer.
After a clean reboot, I did some "normal" testing instead of trying to break things. Video previews played just fine, at least for a little while. After scrolling through several games with video previews, the videos stopped loading, and I got a white texture instead, although I was hearing the audio of the video play. If I started a game and then exited, videos showed with a black screen, but audio for them played normally.
As far as launching games goes, I have not noticed any problems with launching games or playing games. I tested about a dozen games on several different systems, all seemed normal to me.
All in all, an improvement over the previous patch, but definitely a few kinks to iron out. If You've got ideas for other tests you'd like me to me run, let me know.
-
@MWGemini Thanks a lot for this testing. That really saves me a load of time.
I'm not surprised at the video playback issues as I basically haven't even tried that yet and it takes a different code path to the other images. I'd guess it's not freeing the previous texture on every frame so it (silently) consumes the video RAM. Shouldn't be hard to fix.
Using the 'slide' transition is really pushing the Pi when it is swapping textures. I'm surprised it works as well as it does but yes, there is an issue there where some textures either get stuck in the queue or lost. I think it's related to the theme change issue and just needs hunting down. There are a couple of queues and a number of states each texture can be in now so the logic is fairly tricky to get right without killing performance.
With regards to the carousel, I agree these should be prioritised and loaded up front. It did make a change to make that happen but it doesn't seem to be working 100%. It's only a suggestion to the loader to prioritise those textures so they can be (and it seems they are being) swapped out.
As I said though, this is an early build with known issues. Once these are ironed out I don't see why this can't fix the WSOD problem once and for all.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.