ducalex wrote: ↑
Thu Dec 12, 2019 1:21 pm
You are absolutely correct, I tried several things for a few weeks before giving up, but nothing ended up being worth committing unfortunately.
The multitude of config errors suggest to me that you might be using the newer esp-idf 4 or master when this project was made with 3.3.
If you are doing only GO stuff with esp-idf then I suggest sticking with 3.2/3.3 as most projects are still using 3.x.
But if you need or want 4.x for any reason then I have some free time this weekend, I can try to get it to compile to give you a start.
Yes I just took the latest IDF, as I have never developed for this platform before. Following their latest version we can at least in theory gain performance:
- The libc that is used could get optimizations.
- We get a newer gcc which could be better at optimizing.
- We get support for newer ESP32s which could be faster (e.g. https://www.cnx-software.com/2019/05/21 ... ensa-lx7/ this is a single core, but with updated isa. Which leads me to think that at least single core performance could be higher. Hopefully there will be a dual-core version as well. This also support 128MB of spi RAM, way more than we need but it's nice not to be constrained by memory. Hopefully there will be other version with more SRAM. I guess you want to stick as much as possible of your application into that.)
I personally really like the ordoid-go platform, you get so much for so little! If we can get snes to run enjoyably on ESP32s, maybe there could be a snes-button-compatible version of the go with a newer esp32 that also brings other improvements (Isn't the lcd bandwidth limited? I think I read it was only possible to run it at 45Hz?). Anyway, I would be totally interested in a 'new' go platform like that if there is enjoyable snes support.
I will take a look at the errors and try to port it to latest idf on Monday, are you sure the code builds? If you could make sure that it builds with your idf in beforehand, that would be super nice
porting it to newer idf would be a nice task for myself. Ideally multiple idf versions would be supported, to simplify distribution. Maybe we can just have multiple sdkconfig files?
Of course there is value in committing, just keep the master branch clean and buildable and do development/tuning/tests in separate branches. Once you are happy with something, merge to master and if not you can let it live in its own branch for historical purposes. The list of things that you tried (viewtopic.php?f=159&t=35143#p259471
) seems like a good place to start, you seem to have done valuable work which would be nice to have if someone were to continue.
I have a few questions/comments, I hope it's ok
1. "Moving PPU-rendering to second core"/multi-threading - So you moved the PPU-redering to a separate thread? If the hardware can be modeled with threads and emulate correct, this seems like a great idea. This would have been nice to have in a separate branch. This would give me (as a programmer with no former experience from emulation) an idea of how I can contribute.
2. "Reassess the types used everywhere." - This seems like a valid approach as long as it doesn't compromises the correctness. One could do this opportunistically when developing feature X. (You can have two instances of the git repo checked out, one working on feature-x branch and one working on a branch which does this kind of aggressive optimizations. This branch will rebase on master and can be called 'testing' and include experimental optimizations, once you collect statistics if the changes were in fact valid it can be merged to master. In fact I would opt for this workflow for all features. First merge to testing, and then when we have runtime statistics that it is ok we merge it to master)
3. Dynamic recompilation - I am not sure if I know exactly how this works, but maybe you can verify if my theory is correct: since we have two cores this would mean a lot of performance gain as the dynamic recompiler can run in a separate thread on one core while the other core can run native optimized code rather than interpreting foreign machine code. I just read this: https://en.wikipedia.org/wiki/Dynamic_recompilation
. In section Gaming it mentions emulators which uses it, unfortunately it doesn't mention any snes emulator. This should probably be the main focus if we want to get significant improvements in playability, or what do you think?
It would also be nice to have in mind, if doing this, to maintain the same machine state and keep the original interpreter and make them changeable.
I did look to see if there were any snes emulator with dynamic recompilation, but couldn't find any. Admittedly I didn't look that hard, so it may still exist.
4. Internal-RAM/SRAM - I don't know the architecture well enough, but yes I would assume that we want as much as possible in the SRAM. When prioritizing things with lowest latency requirements goes there first. Things that can be allowed to be accessed with long latency should not be there. This seems like something that could be easier than the dynamic recompilation, but on the other hand if dynamic recompilation is the only way forward that should be main priority.
What is your opinion? Do you still think its possible to get this running enjoyably on the esp32?
I have some spare time at the moment, and I am interested in helping out