Difference between revisions of "User:Bluddy"

From ScummVM :: Wiki
Jump to navigation Jump to search
 
(9 intermediate revisions by the same user not shown)
Line 17: Line 17:
== Working On ==
== Working On ==
* PSP Optimization
* PSP Optimization
** Rendering speedup - done
** Rendering speedup: done and makes vsync super accurate (better than PC)
*** Made the wait for vsync not slow down the main thread, by using callbacks. Turns out the callback mechanism that's tied to the GU is unable to call waitForVblank, but the regular callback mechanism can. This reduced the wait from 15ms on average to 3ms, part of which is due to the fact that by notifying the callback I think we switch context to another thread. Not a huge deal.
** MP3 using Media Engine: done
*** Also, because the callback is in highest priority, it's super accurate. We get pefect vsync now, which we didn't before (see white fadeout in FOTAQ intro)
*** Turn into thread for better efficiency (allowing music more processing time without slowdown)
** Timidity
*** But will threading really help? It's pretty complicated. What about syncing?
*** A lot of work. May improve speed over midi, but it'll be the last optimization.
*** Correct small bug with seeking (already corrected in mainstream mp3 decoder). Clean up messy code.
** MP3 using Media Engine
*** I made a hack that'll do it, but unfortunately nobody knows how to use it for 22kHz mp3s, which is all of our MP3s. This means I need to reverse engineer the PSP FW in order to figure out how to do this properly (the PSP FW knows how to use the ME for 22 kHz files). So this is going to be hard too.
*** Check if cooleyes' sirens2 program can play 22kHz files properly. If it can, we're doing something wrong.
**** Can't compile the darn thing!
*** Another program is supposed to be able to handle it. Check it out. (ps2forum post)
** Video Speedup
** Video Speedup
*** Smush can be sped up for aligned platforms, and VFPU cache can be used in PSP
*** Actually harder than expected: it's hard to find codecs that do the kind of work that the VFPU will improve
*** Check other codecs for possible speedups using VFPU/alignment
*** Check other codecs for possible speedups using VFPU/alignment
** Tests
** Tests: done
*** cached vs uncached access in memory
*** how long does changing thread priority take?
*** how long does retrieving thread priority take?
*** how long do different length MS reads take? done. 1B = 1KB = 2.5ms. 2KB = 3.5ms. 10Kb = 10ms. The more, the more efficient.
*** how much reading is done by MP3 rendering/movie playback? How much will we need to cache? done. Reads chunks of 15-25KB preceded by small 4KB reads. Whole MP3 loads are a problem (200KB+).
*** how much reading is done by MP3 rendering/movie playback? How much will we need to cache? done. Reads chunks of 15-25KB preceded by small 4KB reads. Whole MP3 loads are a problem (200KB+).
*** Check fseek's time.
*** How often do we read from the memory stick when we're going fast (movies)? Can we use a thread to do async reading? Is there enough time between reads?
*** how many ticks per second? Can we do it more efficiently than SDL? done. 1,000,000. Yes and we did. Getting time struct is wasteful. Went down from 9-14us to 1-2us.
** Improve memcpy: alignment, rotation
** Improve memcpy: alignment, rotation
*** Possibly use VFPU's cache for even better performance.
*** Memcpy is done. Not sure how to improve it with VFPU.
** Caching of stream
*** Memmove can also be improved -- needs reverse memcpy.
*** Implement cache that reads while other threads don't (mutex) and fills up memory with file data. First stage will be like PS2: just read ahead. Done.
** No More SDL: done.
*** Play with cache sizes to find the best default one.
** Threads for audio: consumer and producer
*** Double the cache size for heavy streaming, see if it helps. It might cause
*** Again, is this really helpful? It may allow lowering of priority, but only temporarily? What about syncing?
***
* Aspect Ratio: done
** No More SDL!
* Replace stdio with PSP functions: done.  
*** Improve SDL audio output. done.
** Turns out it's a huge speed boost!
**** SDL blocks when outputting audio. This is the thread we do most work in, so don't block.
* Timidity
***** Unfortunately, it wasn't the kind of blocking that the name of the function would imply. It just means that it blocks if we try to play and the audio's already playing. This is still the only way to render sound properly, possibly due to tiny delays when context switching.
** A lot of work. May improve speed over midi and sound better.
***** Our thread is still more efficient than SDL. Also, we can control the priority. We can also make the thread consume and another low priority thread the PCM producer for possibly higher efficiency.
***** Check if the timer (which is under heavy use in CoMI) also causes the clicking issue in that game because of long sound rendering. Maybe we can play with priorities, or maybe we need to put context switches in the timer/music/main code.
**** Also, SDL creates threads that ALL have VFPU bit set. That's not efficient when switching contexts.
**** Additionally, change priority so that MP3/MIDI rendering is in same priority and is fairer while getting called back is higher priority.
**** Maybe add a task switch in the Mixer to allow main thread to do stuff if there's a lot of mixing (and it's all from memory).
*** Replace SDL Timer. Done
**** All we need is a simple sleeping thread
*** Remove SDL condition for PowerManager
**** If getting threadId is fast, we can just get it on every criticalSection entry, and register with our threadId. Every thread will say it's in critical section after checking powermanager hasn't notified of suspend. Powermanager will notify of suspend, then loop once over the threadIds, then delay 100ms, then loop again over threadIds. No mutex needed.
*** Replace SDL mutex. Easy.


== To Do ==
== To Do ==
* PSP
* PSP
** MP3 playback with Media Engine
** Groovie video is slow
** Optimize speed in general
*** Seems like problem is in Groovie engine. Sounds start out fine and then get crackly.
** Optimize video playback speed
** Use libTimidity for music
** Use libTimidity for music
* Generic virtual keyboard: take my keyboard and make it available to all. Involves switching from bitmaps to vectors.
* Generic virtual keyboard: take my keyboard and make it available to all. Involves switching from bitmaps to vectors.
* Generic ELF loader
* Generic ELF loader
** Already done in GSOC. Solve issue with loading one plugin at a time.
* MP3 header processing for faster seeking and getting the file length.
* Image Viewer
== Ideas ==
* PSP may some day be unable to load ScummVM plugins as they are, because it's shifting towards accepting only PRX files (ie. PIC code). Some solution will be needed to adapt the current plugin code for PIC in the main executable.
** Idea: dump the symbol table of the main executable into another file. When loading plugins, load this into memory. Create a symbol in memory using ld script that will indicate where in memory the main executable was loaded. Finally, relocating the plugins will obviously be more work since we don't have ld to do some of the job for us. We might need 2 MipsPlugins: MipsComplete and MipsIncomplete.
** Alternatively instead of dumping the table, just copy the executable into the plugin directory and rename it base.plg.

Latest revision as of 20:01, 11 October 2010

Bluddy
Name Yotam Barnoy
Team Member since 2009-09-22
Working on PSP platform
PSP Optimization
Personal webpage/BLOG -
Email -

Worked On

  • PSP
    • Suspend/resume support
    • Plugin support (ELF loader)
    • Console-oriented virtual keyboard
    • D-pad directional support
    • Eliminating the evil undead flickering bug (it was a tough one)
    • Refactoring, redesign and cleanup

Working On

  • PSP Optimization
    • Rendering speedup: done and makes vsync super accurate (better than PC)
    • MP3 using Media Engine: done
      • Turn into thread for better efficiency (allowing music more processing time without slowdown)
      • But will threading really help? It's pretty complicated. What about syncing?
      • Correct small bug with seeking (already corrected in mainstream mp3 decoder). Clean up messy code.
    • Video Speedup
      • Actually harder than expected: it's hard to find codecs that do the kind of work that the VFPU will improve
      • Check other codecs for possible speedups using VFPU/alignment
    • Tests: done
      • how much reading is done by MP3 rendering/movie playback? How much will we need to cache? done. Reads chunks of 15-25KB preceded by small 4KB reads. Whole MP3 loads are a problem (200KB+).
      • How often do we read from the memory stick when we're going fast (movies)? Can we use a thread to do async reading? Is there enough time between reads?
    • Improve memcpy: alignment, rotation
      • Memcpy is done. Not sure how to improve it with VFPU.
      • Memmove can also be improved -- needs reverse memcpy.
    • No More SDL: done.
    • Threads for audio: consumer and producer
      • Again, is this really helpful? It may allow lowering of priority, but only temporarily? What about syncing?
  • Aspect Ratio: done
  • Replace stdio with PSP functions: done.
    • Turns out it's a huge speed boost!
  • Timidity
    • A lot of work. May improve speed over midi and sound better.

To Do

  • PSP
    • Groovie video is slow
      • Seems like problem is in Groovie engine. Sounds start out fine and then get crackly.
    • Use libTimidity for music
  • Generic virtual keyboard: take my keyboard and make it available to all. Involves switching from bitmaps to vectors.
  • Generic ELF loader
    • Already done in GSOC. Solve issue with loading one plugin at a time.
  • MP3 header processing for faster seeking and getting the file length.
  • Image Viewer

Ideas

  • PSP may some day be unable to load ScummVM plugins as they are, because it's shifting towards accepting only PRX files (ie. PIC code). Some solution will be needed to adapt the current plugin code for PIC in the main executable.
    • Idea: dump the symbol table of the main executable into another file. When loading plugins, load this into memory. Create a symbol in memory using ld script that will indicate where in memory the main executable was loaded. Finally, relocating the plugins will obviously be more work since we don't have ld to do some of the job for us. We might need 2 MipsPlugins: MipsComplete and MipsIncomplete.
    • Alternatively instead of dumping the table, just copy the executable into the plugin directory and rename it base.plg.
Retrieved from "https://wiki.scummvm.org/index.php?title=User:Bluddy&oldid=14877"