Re: [GD-General] responsive threading

[Alen L. <ale...@cr...>]

If the higher priority thread never ever waits, windows go out of their way 
and give some time to the lower priority thread in that case. Search 
"priority inversion" in MSDN. Perhaps sleeping a bit once in a while in the 
rendering thread to give a slice to the processing thread, might help you 
keep the situation under control.

HTH,
Alen

----- Original Message ----- 
From: "Andras Balogh" <and...@gm...>
To: <gam...@li...>
Sent: Friday, July 29, 2005 21:22
Subject: Re: [GD-General] responsive threading


> I've tried setting the primary thread to time critical and the other 
> thread to idle (and I also disabled it's priority boost), and it does help 
> quite a bit, but I'm still seeing some small glitches. I'm not saying it's 
> bad, it's pretty good actually, and people are so used to bad framerates 
> nowadays that I'm sure they wouldn't complain a tiny bit. I do admit that 
> I'm a bit on the perfectionist side on this one :)
>
> I have tried setting the process priority class to real-time too, but in 
> that case my "idle" priority thread won't be really idle anymore, 
> actually, the hiccups get much worse. I guess I could run in a separate 
> process even, but that's really overkill.
>
>
> Andras
>
> Brian Hook wrote:
>> At the risk of asking the obvious, have you also set your primary thread 
>> to run at the highest priority (REAL_TIME or whatever it's called on 
>> Windows)?
>>
>> I run audio mixing in a separate thread and by setting things 
>> appropriately (and sleeping when necessary) I never get hiccups.
>>
>> Brian
>>
>> On Fri, 29 Jul 2005 14:35:21 -0600, Andras Balogh wrote:
>>
>>>I'm loading lots of "small" (avg. 1k x 1k) regions from lots of
>>>huge (5GB+) wavelet compressed images. I'm using a 3rd party
>>>library to do this (ECW), so I don't know the implementation
>>>details, but I could look at the code, if I knew what to look for..
>>>
>>>
>>>Andras
>>>
>>>
>>>Mat Noguchi (BUNGIE) wrote:
>>>
>>>>What else are you doing on the IO thread to make it eat up so
>>>>much CPU time?
>>>>
>>>>MSN
>>>>-----Original Message-----
>>>>From: gam...@li...
>>>>[mailto:gam...@li...] On
>>>>Behalf Of Andras Balogh Sent: Friday, July 29, 2005 10:44 AM To:
>>>>gam...@li... Subject: [GD-General]
>>>>responsive threading
>>>>
>>>>I'm developing a graphics application, that I want to be very
>>>>responsive, very smooth, all the time! The rendering is pretty
>>>>simple, the framerate is high and stable, so I just lock to
>>>>vsync, and everything moves beautifully smooth! The CPU usage for
>>>>this thread is always below 10%.
>>>>
>>>>However, I also have another thread, that has to do some heavy
>>>>work. This thread does tons of IO operations, and also makes the
>>>>CPU sweat!
>>>>
>>>>There is no synchronization between the two threads, so they
>>>>should be able to run independently. Still, I'm experienceing
>>>>sudden spikes in the
>>>>
>>>>framerate, when the second thread is really hammering. What could
>>>>be the
>>>>
>>>>reason for this? Is it possible to do something about it, to
>>>>regain the continuous framerate? I'm really not interested in the
>>>>performance of the second thread, I just want my first thread to
>>>>run as smooth as possible! I've tried lowering the priority for
>>>>the second thread, and it
>>>>
>>>>does help, but there are still some spikes. Is it possible that
>>>>it's Windows itself doing some operations at higher priority,
>>>>like memory management, IO stuff, and the likes?
>>>>
>>>>Thanks,
>>>>
>>>>
>>>>Andras
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>