Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[blog] Benchmarking Multithreaded PCSX2
#21
Happy New Year Rama and the rest of the dev crew Smile

This is a very interesting yet promising discussion. It appears you guys are indeed close to making some significant progress with quad core or more support. Please continue to keep us posted Smile

I look forward to the day I'll be able to play Ridge Racer V with no slowdowns Smile
Reply

Sponsored links

#22
Thumbs Up 
[b][b]Please Add the English Language (USA / UK) in PCSX2 Beta Software....[/b][/b]
Closedeyes


Attached Files Thumbnail(s)
   
Reply
#23
That was an extremely over the top post.. however youll probably find "Anglicky" is czech for english.

If you aren't Czechoslovakian, then shame on you for downloading a package someone else but us put on the web Wink
[Image: ref_sig_anim.gif]
Like our Facebook Page and visit our Facebook Group!
Reply
#24
This might seem like a dumb question since I haven't look at the code (I wouldn't know where to begin), so please bare with me

Isn't it really inefficient to have that interdependency between the EE/Core thread and the GS thread? Almost completely defeats the purpose of multi-threading

Why does the EE thread need to wait for the GS thread? Couldn't the EE thread continue to just stream data without needing a response from the GS? If the GS thread is out of sync with the EE, the worst that could happen is that you lose a few frames right? Seems like a small price for a potentially huge performance improvement
Reply
#25
You wouldnt just lose frames, youd get black frames. Also the ee core writes and reads gs registers, if the information is wrong you could get bad graphics or games freezing completely depending on direction.
[Image: ref_sig_anim.gif]
Like our Facebook Page and visit our Facebook Group!
Reply
#26
Why write directly to/from the registers though? In what situation would the "information" be wrong? I figured you could have something like this:

Have 3 blocks of shared memory
EE thread:
1. Do its stuff
2. Write data to block 1 (with timestamp at end of block)
3. Do its stuff
4. Write new data to block 2 (with timestamp at end of block)
5. Do its stuff
6. Write new data to block 3 (with timestamp at end of block)
7. Return to step 1

GS thread:
1. Load data from block 1 into registers
2. Render all the data/ all the other functionality
3. Check timestamp on each block/verify contents of block
4. Begin from step 1 with the block that has the soonest timestamp after the last one rendered (or re-render the same block if there is no new block)

This would mean that EE thread can continue to work without being interrupted by the GS thread, and the GS thread will always have something to render (sometimes will be the same data) so instead of getting black screens, you just get the same frame again. Even if this whole process is significantly less streamlined, I still feel that it would offer better performance than having thread interdependency
Reply
#27
These are details you can probably find in the sources. Look at MTGS.cpp or GS.cpp.
I'm no expert on this but I know there's a good reason for all the choices made about threading.
I'm guessing now but I think having the GS process the same information twice would lead to
graphic garbage and crashes. Running the GS far out of sync with the rest of the emu would either cause
input lag or be inefficient.
Again, this is just what I remember about it. Check the sources and you'll find a lot of comments put in by Jake
that explain everything Smile
If it turns out your idea is still possible, we can take it further.
Reply
#28
If anyone is a wizard enough to rewrite the GSDX plugin to fix long-standing bugs/glitches/issues with it, we would all love you forever <3
That would do way more than rewriting the multithreading for the main PCSX2 program.
Reply
#29
That was completely off topic darkwraith Tongue
[Image: ref_sig_anim.gif]
Like our Facebook Page and visit our Facebook Group!
Reply
#30
actually that's something I wanted to look into as well >_>

specifically, the extreme slow down that occurs when rendering 2d stuff in hardware mode - what exactly causes those issues?
happens a lot in game menus as well as in games like DMC and Shadow Hearts where there's 2d backgrounds and stuff
Reply




Users browsing this thread: 1 Guest(s)