PCSX2
Air
PCSX2 coder
[ 03 11 2009 @ 15:30 ]
Global Visitor Stats
Wondering about who's watching as we make and break bleeding edge alpha/beta versions of PCSX2? I do! Here's a map representing the visits to our SVN repository at Googlecode, for the past 2 weeks.
![[Image: attachment.php?aid=21820]](http://forums.pcsx2.net/attachment.php?aid=21820)
On average, our SVN totals per day:
Top visitors by city:
1. Sapporo 171
2. London 165
3. Tokyo 151
4. Shanghai 147
5. Moscow 142
On average, our SVN totals per day:
- 900 unique viewers
- 3,200 visits (3.5 visits per viewer)
- 9,500 page views in total.
Top visitors by city:
1. Sapporo 171
2. London 165
3. Tokyo 151
4. Shanghai 147
5. Moscow 142
Air
PCSX2 coder
[ 13 10 2009 @ 01:00 ]
omg it's r2000
... and omg! It's the r2000! Bring on the celebration! Everybody to the limit! and err.. well... it'd prolly be more impressive if the emulator was working better. 
![[Image: sbemail39.PNG]](http://www.hrwiki.org/w/images/0/00/sbemail39.PNG)
Air
PCSX2 coder
[ 13 10 2009 @ 00:46 ]
Thread Counting...
One thing is for sure: The new 0.9.7 betas will use a lot more threads than the current 0.9.6 releases. Now this doesn't necessarily mean the emulator will take advantage of quad core CPUs better than 0.9.6, least not in a gameplay sense. As I explained in my previous blog, threading is as much a function of improving responsiveness and recoverability as it is about sharing a workload across multi-core cpus, and so far most of the threading implemented into 0.9.7 is the scalable/responsive sort.
One of the major changes in 0.9.7 will be the removal of what I call an "aggressive spinwait" in the EmotionEngine (EEcore) emulation unit. A spinwait is a simple loop that waits on a variable to change, like so:
This is a very simple threading design, but it's mostly drawbacks and not many advantages. We've continued to use it up to now in PCSX2's EEcore because there wasn't much reason to do away with it; and with the EEcore being the main orchestrator of everything in PCSX2 (gui included!), having the high-resolution responsiveness of a spinwait made some sense.
On the current design in 0.9.6, the EEcore and the GUI share time on the same thread, and when the GS thread is busy, the EEcore will split time between waiting on the GS (via the spinwait) and processing GUI messages. This transition from EEcore emulation to GUI message processing was typically costly, but was necessary to handle input from the user. In the new 0.9.7 design, the EEcore has its own thread separate from the GUI. This allows us to remove the overhead of having to switch to/from GUI processing code, but it came with a somewhat unexpected drawback: the EEcore's aggressive spinwait is now suddenly very aggressive when a game becomes GS-limited. In 0.9.6 the spinwait breaks from time to time to splice in some gui messages and make time for the GS to do its thing too. This kept everything pretty happy. But with the splicing gone, the EEcore is allowed to run free, soaking up tons of resources simply re-testing the same variable over and over.
The full impact became obvious when we realized that setting 2 software threads in GSdx caused PCSX2 to slow to a crawl (sub 1fps!) on dual core systems. That's what happens when you have three threads using spinwaits on a dual core system -- they completely starved out everything else, and to some extent each other as well. (yes, GSdx software uses spinwaits also!)
The primary solution is to get rid of the spinwait in the EEcore. In its wake we'll put the EEcore to sleep and have it wake up only once the MTGS ringbuffer has emptied to a satisfactory percentage. With the EEcore asleep, the GSdx thread(s) will have full reign over all the resources of the cpu; which will allow it to play "catch up" more efficiently than it can even in 0.9.6. This model will be an obvious win for both software rendering, and possibly DX11's multithreaded pipeline in the future.
One of the major changes in 0.9.7 will be the removal of what I call an "aggressive spinwait" in the EmotionEngine (EEcore) emulation unit. A spinwait is a simple loop that waits on a variable to change, like so:
Code:
volatile bool IsRunning = true;
StartThreadedAction();
while( IsRunning );
// When the above while() exits, the ThreadedAction is done.This is a very simple threading design, but it's mostly drawbacks and not many advantages. We've continued to use it up to now in PCSX2's EEcore because there wasn't much reason to do away with it; and with the EEcore being the main orchestrator of everything in PCSX2 (gui included!), having the high-resolution responsiveness of a spinwait made some sense.
On the current design in 0.9.6, the EEcore and the GUI share time on the same thread, and when the GS thread is busy, the EEcore will split time between waiting on the GS (via the spinwait) and processing GUI messages. This transition from EEcore emulation to GUI message processing was typically costly, but was necessary to handle input from the user. In the new 0.9.7 design, the EEcore has its own thread separate from the GUI. This allows us to remove the overhead of having to switch to/from GUI processing code, but it came with a somewhat unexpected drawback: the EEcore's aggressive spinwait is now suddenly very aggressive when a game becomes GS-limited. In 0.9.6 the spinwait breaks from time to time to splice in some gui messages and make time for the GS to do its thing too. This kept everything pretty happy. But with the splicing gone, the EEcore is allowed to run free, soaking up tons of resources simply re-testing the same variable over and over.
The full impact became obvious when we realized that setting 2 software threads in GSdx caused PCSX2 to slow to a crawl (sub 1fps!) on dual core systems. That's what happens when you have three threads using spinwaits on a dual core system -- they completely starved out everything else, and to some extent each other as well. (yes, GSdx software uses spinwaits also!)
The primary solution is to get rid of the spinwait in the EEcore. In its wake we'll put the EEcore to sleep and have it wake up only once the MTGS ringbuffer has emptied to a satisfactory percentage. With the EEcore asleep, the GSdx thread(s) will have full reign over all the resources of the cpu; which will allow it to play "catch up" more efficiently than it can even in 0.9.6. This model will be an obvious win for both software rendering, and possibly DX11's multithreaded pipeline in the future.
Air
PCSX2 coder
[ 07 10 2009 @ 13:39 ]
Thread syncronization
It's the year 2009, and it's almost over at that; and as anyone reading this blog well knows, multithreaded applications are the here-and-now and future of desktop computing. It's the only way we can take advantage of multicore CPUs. But multithreaded programming offers more than just improved multicore performance. Using threaded programming is actually very important to developing software that behaves nicely. By that I mean software that refreshes its window contents quickly, responds to your mouse clicks, and lets you cancel stuff.
For that the best approach is usually threading, with the alternative being something called "Cooperative multitasking" where by a program is written such that it splits all tasks into neat little chunks. For example, the two possible ways to implement loading an image (let's say a png image):
* Load the image one scanline at a time, and then after each scanline manually check for keyboard, mouse, or other input, and refresh the screen.
* Load the image using a thread, and let the usual "global" windows message handler dispatch keyboard, mouse, and refresh messages as usual.
The second approach has several advantages. For one, it needs fewer temporary heap allocations (which are typically slow and fragment memory). It is more responsive: windows messages will be handled in parallel to the image loading, so you don't even need to "wait" until the end of a scanline for user input to have its effect. It's also more scalable: while the first system is able to load one image at a time only in co-operative fashion (extending it to support multiple is possible, but very difficult), the threaded approach can be scaled to load dozens of images at once with no additional complications.
The drawback is that thread synchronization and especially structured error handling across threads tends to be much more complicated than that of the linear cooperative model. If you don't have errors to handle, or don't really care about handling errors, then threaded tasking isn't so bad.
Enter PCSX2, where everything ends up being damn complicated. Being a perfectionist, I figured I'd design the new GUI completely on the threaded model, doing away with cooperative design almost completely. Such a design should help avoid any deadlocking scenarios and allow the emu to recover from almost any error gracefully. Problem: The emulator has a lot of inter-dependent parts and pieces that need to be interlocked and synchronized, and all of them can throw out a variety of errors -- which too I'd like to handle smartly; requesting extra user input when appropriate (and not just throwing out annoying or vague message boxes).
Interlocking dependencies can be a nightmare. For example, if you start a thread that loads an image, and then block on that thread until it completes, you're worse off than if you wrote yourself a cooperative image loader because now the whole program stalls waiting for the thread to complete anyway. And like everything else, there are two ways to handle this:
(1) Use a "friendly" blocking mechanism that periodically polls the user input and updates display. This is no better than cooperative single-thread designs though, as it has slow response times and doesn't scale well to multiple threads.
(2) Build your entire GUI around "messages" and "callbacks" (sometimes also called "signals"). This is the most flexible and user-friendly option but can add a lot of "framework" to any codebase.
I tried to use the first approach initially, because I was in a hurry to get things working. But it's been problematic since day 1, so now I'm redoing most things to use the second method instead.
The second one is in fact the recommended design by Microsoft, and one they've been using for almost everything in Windows ever since Win95. It's one of the reasons the Win32 API feels "heavy" to a lot of programmers, but as it turns out, it's not without good reason.
For that the best approach is usually threading, with the alternative being something called "Cooperative multitasking" where by a program is written such that it splits all tasks into neat little chunks. For example, the two possible ways to implement loading an image (let's say a png image):
* Load the image one scanline at a time, and then after each scanline manually check for keyboard, mouse, or other input, and refresh the screen.
* Load the image using a thread, and let the usual "global" windows message handler dispatch keyboard, mouse, and refresh messages as usual.
The second approach has several advantages. For one, it needs fewer temporary heap allocations (which are typically slow and fragment memory). It is more responsive: windows messages will be handled in parallel to the image loading, so you don't even need to "wait" until the end of a scanline for user input to have its effect. It's also more scalable: while the first system is able to load one image at a time only in co-operative fashion (extending it to support multiple is possible, but very difficult), the threaded approach can be scaled to load dozens of images at once with no additional complications.
The drawback is that thread synchronization and especially structured error handling across threads tends to be much more complicated than that of the linear cooperative model. If you don't have errors to handle, or don't really care about handling errors, then threaded tasking isn't so bad.
Enter PCSX2, where everything ends up being damn complicated. Being a perfectionist, I figured I'd design the new GUI completely on the threaded model, doing away with cooperative design almost completely. Such a design should help avoid any deadlocking scenarios and allow the emu to recover from almost any error gracefully. Problem: The emulator has a lot of inter-dependent parts and pieces that need to be interlocked and synchronized, and all of them can throw out a variety of errors -- which too I'd like to handle smartly; requesting extra user input when appropriate (and not just throwing out annoying or vague message boxes).
Interlocking dependencies can be a nightmare. For example, if you start a thread that loads an image, and then block on that thread until it completes, you're worse off than if you wrote yourself a cooperative image loader because now the whole program stalls waiting for the thread to complete anyway. And like everything else, there are two ways to handle this:
(1) Use a "friendly" blocking mechanism that periodically polls the user input and updates display. This is no better than cooperative single-thread designs though, as it has slow response times and doesn't scale well to multiple threads.
(2) Build your entire GUI around "messages" and "callbacks" (sometimes also called "signals"). This is the most flexible and user-friendly option but can add a lot of "framework" to any codebase.
I tried to use the first approach initially, because I was in a hurry to get things working. But it's been problematic since day 1, so now I'm redoing most things to use the second method instead.
The second one is in fact the recommended design by Microsoft, and one they've been using for almost everything in Windows ever since Win95. It's one of the reasons the Win32 API feels "heavy" to a lot of programmers, but as it turns out, it's not without good reason.
Air
PCSX2 coder
[ 03 10 2009 @ 15:30 ]
Svn Comments are re-enabled!
As of Sept 30th, we've re-enabled user comments at our SVN repository (PCSX2 @ Googlecode).
Comments have been re-enabled primarily so that we can get user feedback again on plugins and the current legacy gui updates. The trunk of svn (the new wx gui) is still too volatile for user comments to be of much use, so don't be surprised if we pretty well blow off "bug reports" relating to it.
(and yes, top priorities for implementation in the new gui are framelimiter, savestates, and the advanced cpu options -- along with bug fixes and memory leak fixes. No timeframe estimates: They'll all get done when they get done!)
Comments have been re-enabled primarily so that we can get user feedback again on plugins and the current legacy gui updates. The trunk of svn (the new wx gui) is still too volatile for user comments to be of much use, so don't be surprised if we pretty well blow off "bug reports" relating to it.
(and yes, top priorities for implementation in the new gui are framelimiter, savestates, and the advanced cpu options -- along with bug fixes and memory leak fixes. No timeframe estimates: They'll all get done when they get done!)
Air
PCSX2 coder
[ 11 09 2009 @ 23:11 ]
New versioning/release pattern
From 0.9.5 onward PCSX2 has been a mostly open SVN revisioning process, where beta builds are SVN-marked and are widely built and distributed to users. 0.9.5 itself was never released as an official 'stable' build, and after the release of 0.9.6 we just called all subsequent SVN builds of PCSX2 "betas." (mostly because we were too lazy and/or busy to bother worrying of version numbers). This lackadaisical version pattern was a source of confusion for users and developers alike.
So starting with our next release of PCSX2 we'll be using an established versioning pattern (which likely won't be for some time -- implementing a new GUI is a complicated ordeal). The new patter will be based on some standard Open Source convention, where odd-numbered versions denote SVN/devel builds (and will have SVN numbers affixed to the version) and even numbered versions denote stable releases. By chance this is already how things have been playing out since 0.9.5, so mostly it just means we're making a conscious effort to continue to apply the pattern in the future. Thus, the past-present-future will look something like this:
Past:
0.9.4 - Official stable release
0.9.5 - Development build (SVN)
Present:
0.9.6 - Official stable release
0.9.7 - Development build (SVN) [wx-enhanced!]
Future:
0.9.8 - Official stable release
0.9.9 - Development build (SVN)
1.0.0 - Official stable release
1.1.0 - Development build (SVN)
This way when people file bug reports we can know from the main version number alone if the report is regarding a stable release or an SVN build, and furthermore users can have a clearer guide to the status of versions being released and such. Furthermore, odd versions will have the SVN revision appended to them by default, like 0.9.7.r1880.
... and yes the hope is that we're going to go to 1.0.0 after 0.9.9, and use a 1.0, 1.1, 1.2, 1.3, etc version pattern, shortening the primary version numbers from three digits to two. But that's a long way down the road yet, and anything could happen between now and then.
So starting with our next release of PCSX2 we'll be using an established versioning pattern (which likely won't be for some time -- implementing a new GUI is a complicated ordeal). The new patter will be based on some standard Open Source convention, where odd-numbered versions denote SVN/devel builds (and will have SVN numbers affixed to the version) and even numbered versions denote stable releases. By chance this is already how things have been playing out since 0.9.5, so mostly it just means we're making a conscious effort to continue to apply the pattern in the future. Thus, the past-present-future will look something like this:
Past:
0.9.4 - Official stable release
0.9.5 - Development build (SVN)
Present:
0.9.6 - Official stable release
0.9.7 - Development build (SVN) [wx-enhanced!]
Future:
0.9.8 - Official stable release
0.9.9 - Development build (SVN)
1.0.0 - Official stable release
1.1.0 - Development build (SVN)
This way when people file bug reports we can know from the main version number alone if the report is regarding a stable release or an SVN build, and furthermore users can have a clearer guide to the status of versions being released and such. Furthermore, odd versions will have the SVN revision appended to them by default, like 0.9.7.r1880.
... and yes the hope is that we're going to go to 1.0.0 after 0.9.9, and use a 1.0, 1.1, 1.2, 1.3, etc version pattern, shortening the primary version numbers from three digits to two. But that's a long way down the road yet, and anything could happen between now and then.
