F**K MY LIFE

[Squall Leonhart]

starscream isn't a dev

[tysonrss]

But delroth is.

[Squall Leonhart]

delroth didn't back the claim that idle processes running in the background will make the emulator any more unstable.

processes that are chewing an inconsistent amount of cpu and io, triggering DPC and ISR issues maybe, but none of the applications in the ops tray are of this sort and won't affect dolphin stability.

[tysonrss]

(07-07-2012, 01:00 PM)neobrain Wrote: More stuttering => more irregular timing => more instability. You see, Dolphin's synchronization code is highly sensitive for these kind of issues.

My apologies. I meant Neobrain.

[Squall Leonhart]

neobrain isn't infallible :p

[delroth]

(07-08-2012, 01:25 PM)tysonrss Wrote:

(07-07-2012, 01:00 PM)neobrain Wrote: More stuttering => more irregular timing => more instability. You see, Dolphin's synchronization code is highly sensitive for these kind of issues.

My apologies. I meant Neobrain.

But so much things can actually cause irregular timing, I don't even think 5-10 background programs would actually be relevant. We're doing disc IO synchronously in the CPU thread FFS, which means blocking system calls in the CPU thread, which means context switching + wait for an interrupt if the data isn't in cache. Same with GL/DX calls done in the GPU thread synchronously: this inserts random latency due to several factors (driver implem, data transfer, shaders execution, ...).

Obviously there are probably still some race conditions in Dolphin's code (we know that for sure -- EFB CPU access is prone to crashes because of this for example), but compared to all the blocking stuff that always for sure interrupts CPU/GPU threads it's completely negligible. Maybe one day Dolphin will manage to extract all blocking system calls from the timing-critical paths (trying to do that with async-dvd...) but until it's done background programs are the least likely cause of bugs. And even then, if you've got more than 4 cores you could get away with increasing the Dolphin process priority and (almost) not be preempted anymore.

[tysonrss]

What about if you have dual cores? Would setting the priorty to high do anything?

[neobrain]

(07-08-2012, 02:53 PM)delroth Wrote: Obviously there are probably still some race conditions in Dolphin's code (we know that for sure -- EFB CPU access is prone to crashes because of this for example)

Uhm, afaict EFB access code doesn't suffer from any race conditions, does it? oO

[delroth]

(07-08-2012, 06:55 PM)neobrain Wrote:

(07-08-2012, 02:53 PM)delroth Wrote: Obviously there are probably still some race conditions in Dolphin's code (we know that for sure -- EFB CPU access is prone to crashes because of this for example)

Uhm, afaict EFB access code doesn't suffer from any race conditions, does it? oO

Depends on how much your graphics drivers are reentrant. I've managed to get Dolphin to crash in glReadPixels because it's executed in the CPU thread when accessing EFB from CPU. Only on windows, not on Linux though.

EDIT: Disregard that, I can't read code.

[neobrain]