Solution for " White Screen of Death "

mattrixk

@fieldofcows said in Solution for " White Screen of Death ":

Now, where can I find more hours in the day...

~~Insomnia?~~

(please don't)

MWGemini

@mattrixk I've also written up a design doc that I shared with @fieldofcows regarding the metadata and database redesign. Still a work in progress, but I'm hoping it's heading in the right direction.

fieldofcows

@MWGemini Hi, yes I've read it and it looks good and aligned to what I'm currently working on. I've just been too consumed with this WSOD fix to work on the metadata. If this fix works OK then I'll be back to it shortly.

MWGemini

@fieldofcows Sounds good! I've made some further edits, but I know you've got plenty on your plate. Keep up the good work! I'll install your patch and do some testing.

fieldofcows

@MWGemini said in Solution for " White Screen of Death ":

Do you happen to have installation steps for your latest patch handy?

Borrowed from my previous instructions on the Video Preview thread:

Installation instructions:

Download a fresh copy of retropie from https://github.com/RetroPie/RetroPie-Setup/releases/download/4.1/retropie-4.1-rpi2_rpi3.img.gz and install it on an SD card (or install it on an existing card at your own risk)
Connect the raspberry pi to the network
Boot the raspberry pi and exit ES back to the terminal
Download or copy the new ES with WSOD fix from https://github.com/fieldofcows/EmulationStation/releases/download/v0.3-RPi-1/emulationstationinto the home directory, e.g.

wget https://github.com/fieldofcows/EmulationStation/releases/download/v0.3-RPi-1/emulationstation

Make executable and replace the original ES (maybe backing up the original first)

chmod +x emulationstation
sudo cp emulationstation /opt/retropie/supplementary/emulationstation/

Add the biggest theme you can think of and as many systems as you can :)
Restart

MWGemini

@fieldofcows I was just about to post that link. You beat me to it!

fieldofcows

I believe the build should work on the RPi2 as well if anyone wants to try it but doesn't have a RPi3 - although I cannot confirm this as I don't have a RPi2 myself.

MWGemini

@fieldofcows Initial reports: huge success! It fixed the dropped textures I was seeing, although there is that slight but noticeable hitch as I cycle through the carousel and force new textures to be loaded. The only bug I have found so far is that if you are pressing right or left while the load is happening, it reacts as though the input key is being held down. This only happened once, and I have not been able to replicate it yet. Edit: It looks like if you move in one direction (either left or right) until textures start to load, then start moving in the opposite direction, as soon as you hit the end of the cache, where new textures have to be loaded, the "onKeyRelease" event (or whatever it is in ES) doesn't register, causing the input to loop. This is easily fixed by the user by simply pressing and releasing that key.

I can also confirm that 120mb is the upper limit before textures start getting dropped (at least on my system).

Will investigate further and try various ROMs as well.

MWGemini

@fieldofcows I've tried a variety of ROMs, on a variety of systems (including PSX, N64, and Dreamcast), and have not noticed any performance change from the prior official RP build of ES. The closest I came to seeing any gameplay change was graphical glitches in one of the N64 ROMs I tried, but that emulator has always been glitchy for me, so it's very possible that nothing has changed in that regard.

Overall, I'm extremely happy with the change. The only thing I might suggest is that instead of a least-recently-used cache, to keep textures in the cache based on proximity to the currently selected system. In my case, I have 18 or so systems loaded, and the cache can only contain about 10 of the images (modified tronkyfran theme with 100mb VRAM limit). To go right one index is more likely than going left 11, so it might reduce the loading hiccup if the farthest systems are unloaded and the closest systems are kept in memory. Edit: even better would be to do this on a background thread if possible, which could prevent any noticeable hiccups as textures load and unload.

At this point, that's really a nitpicky request, though. You've just fixed one of the biggest (and longest-lasting?) bugs in ES, and I'm sure the community will be very happy about that!

fieldofcows

@MWGemini Brilliant. Thanks for that. Yes, I'm already looking at prioritising the systems around the currently selected system - great minds think alike.

I have considered a background thread because this would completely cure the jerkiness at the expense of seeing images appear over time. I'll take a look but I'm not sure how easy it will be to make the texture code thread safe.

dankcushions

@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 reloc

gives 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 gpu

gets 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.

MWGemini

@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.

Nismo

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.

MWGemini

@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.

Nismo

@MWGemini ok, i'll upload in a minute.

Nismo

@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.

MWGemini

@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.

Nismo

@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.

MWGemini

@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

@MWGemini @Nismo Yes I think there is an issue when switching themes. I have noticed this myself too. I think that when a theme is switched it purges the texture objects but maybe leaves them in VRAM. Needs a bit of investigation.

Apart from that it's working ok though?