12-22-2009, 03:41 PM
In .NET world we usually do Thread.Sleep(50); to avoid letting the thread eat up all the CPU.
[blog] Thread Counting...
|
12-22-2009, 03:41 PM
In .NET world we usually do Thread.Sleep(50); to avoid letting the thread eat up all the CPU.
01-13-2010, 09:01 AM
Ok now emu works only with 2 cores, gradually people buying 4 cores cpu and others multicore cpu if it is difficult to make multicore support for emu is it possible to make separate streams for sound or graphics?
Example: main streams eerec, vurec, microvu – to mtgs (2 core usage), graphics, sound, controller, cdvdrom – to others free cores. sorry if I do poorly explained
01-13-2010, 09:44 AM
(12-22-2009, 03:41 PM)Ravenheart Wrote: In .NET world we usually do Thread.Sleep(50); to avoid letting the thread eat up all the CPU. The problem with this is you're going to burn some multiple of 50 units of time (milliseconds I think) and that is probably far too coarse-grained for something like this. To borrow Air's code chunk, Code: volatile bool IsRunning = true; Quote:Example: main streams eerec, vurec, microvu – to mtgs (2 core usage), graphics, sound, controller, cdvdrom – to others free cores. This has been suggested before, but it's incredibly hard to seperate the things in a way that would make a real difference. As it stands all the work is done by two cores, one core for the graphics and the other core for everything else. Trying to seperate pretty much anything else out is a) really difficult to do correctly, and b) not guaranteed to give any boost, and may well end up hindering performance. So far the best use for more cores is to throw it at the graphics plugin in the form of the software rendering threads.
"This thread should be closed immediately, it causes parallel imagination and multiprocess hallucination" --ardhi
01-13-2010, 09:49 AM
is the new threading option it VirtualDub not a sample? or is it completely different
03-05-2010, 07:15 AM
I hate to perform necromancy..but couldn't you use a binary semaphore?
03-27-2010, 12:50 PM
out of morbid curiosity wouldent it be much more effective to off load th GS onto our modern gpu's via cuda or sum such. to me gpu doing emu of a fellow gpu would make more scence exspechely with more and more gpu's becomeing cuda ready ( or whatever ati calls that abelity on there cards ).
03-27-2010, 01:53 PM
The GS is pretty much the opposite of your GPU. It is software based so what you suggest is very hard to impossible.
03-27-2010, 02:32 PM
03-27-2010, 02:38 PM
Google can give you amazing results.
http://en.wikipedia.org/wiki/Graphics_Sy...ifications (03-05-2010, 07:15 AM)NoEffex Wrote: I hate to perform necromancy..but couldn't you use a binary semaphore? I agree. Air, the old setup used would have had horrendous performance if these actions typically took longer than a thread's quantum. Code: volatile bool IsRunning = true; Using a semaphore shared between threads would be: Code: //IsRunning is your semaphore that you've passed as a reference to each thread. (If you want multiple threads to work in unison under the lock, and know it's possible to do safely, go ahead and use a counting semaphore instead) The binary semaphore has the decency to put the other threads to sleep. Putting threads to sleep and waking them again when it's their turn is far more efficient in the overhead department. Note: If I've horribly misunderstood what the problem is, feel free to hit me. It's 3:30am, and I honestly am about to drop. =p |
« Next Oldest | Next Newest »
|