36
edits
Difference between revisions of "User:Bluddy"
Jump to navigation
Jump to search
m
→Working On
m (→Working On) |
m (→Working On) |
||
| Line 19: | Line 19: | ||
** Rendering speedup - done | ** Rendering speedup - done | ||
*** 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. | *** 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. | ||
*** 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) | |||
** Timidity | ** Timidity | ||
*** A lot of work. May improve speed over midi, but it'll be the last optimization. | *** A lot of work. May improve speed over midi, but it'll be the last optimization. | ||
** MP3 using Media Engine | ** 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. | *** 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 | *** Smush can be sped up for aligned platforms, and VFPU cache can be used in PSP | ||
*** Check other codecs for possible speedups using VFPU | *** Check other codecs for possible speedups using VFPU/alignment | ||
** Tests | |||
*** 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? | *** 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 many ticks per second? Can we do it more efficiently than SDL? | *** Check fseek's time. | ||
*** 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 | |||
*** Possibly use VFPU's cache for even better performance. | |||
** Caching of stream | |||
*** 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. | |||
*** Play with cache sizes to find the best default one. | |||
*** Double the cache size for heavy streaming, see if it helps. It might cause | |||
*** | |||
** No More SDL! | ** No More SDL! | ||
*** Improve SDL audio output | *** Improve SDL audio output. done. | ||
**** SDL blocks when outputting audio. This is the thread we do most work in, so don't block. | **** SDL blocks when outputting audio. This is the thread we do most work in, so don't block. | ||
***** 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. | ***** 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. | ||
| Line 47: | Line 54: | ||
**** Additionally, change priority so that MP3/MIDI rendering is in same priority and is fairer while getting called back is higher priority. | **** 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). | **** 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 | *** Replace SDL Timer. Done | ||
**** All we need is a simple sleeping thread | **** 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 == | ||