Re: Dual core and the Sample Framework
- From: "Peter C." <PeterC@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 1 Mar 2006 13:30:43 -0800
1) Threading in my app: Yes, I create one Thread object to do background
loading/unloading of textures. I'm making a screensaver and I wanted to keep
the framerate as solid as possible, so I took texture streaming out of the
render path. The problem happens whether I set the DisableMultithreadedFlag
to 'true' or 'false' in the ModifyDeviceSettings callback.
2) Running DXSDK samples: They exhibit the same problems. I tested with the
HDRCubeMap sample as it has animation based on timing. Both managed versions
(.NET2.0 and .NET1.something) showed problems and both the 32-bit and 64-bit
versions of the C++ code were screwed up. I went into the Task Manager and
manually set the affinity to either core for the samples and that fixed the
problem.
This makes me think there's something screwy with my setup. Surely someone
else has found this big a problem if it's truly a inherent in the code.
On a slight aside, after finding this problem with my app, I realized that
this was behind why Knights of the Old Republic 2 never worked on this
machine.
"ZMan" wrote:
From Microsoft.....
"with the exception of the garbage collector, no platform we will run on
will switch threads out from underneath you... Can managed hosts do it?
Sure.. But the desktop CLR doesn't"
Which matches the information I found below and gives us an interesting
problem.
Unless you are creating any threads yourself your entire dxut based
application should run on a single thread on a single processor and yet the
behavior you see is indicative of the multi core problem described in the
article and your fix also matches that article.
So can you clarify a couple of things.
1. Do you have any threading of your own in the application? I had assumed
you were just running one of the SDK sample so there wouldn't be.
2. If you were not just running an SDK sample can you try a few of them and
see if they exhibit the same behavior. If so let us know which ones.
--
Zman
http://www.thezbuffer.com - News and information for Managed DirectX
"ZMan" <zman@xxxxxxxxxxxxxx> wrote in message
news:eM4L6HQPGHA.3556@xxxxxxxxxxxxxxxxxxxxxxx
Thanks for that information on .Net thread - I had no clue about that.
So I figured I needed to do more reading and now I'm even more confused.
http://msdn2.microsoft.com/en-us/library/system.threading.thread.beginthreadaffinity.aspx
....Some hosts of the Common Language Runtime, such as Microsoft® SQL
Server "Yukon", provide their own thread management. A host that provides
its own thread management can move an executing task from one physical
operating system thread to another at any time. Most tasks are not
affected by this switching. However, some tasks have thread affinity -
that is, they depend on the identity of a physical operating system
thread. These tasks must inform the host when they execute code that
should not be switched.......
So this implies that only 'some' hosts of the CLR are affected by this. No
comments on if this also applies to the default host of the CLR (though
this blog implies that it only applies to SQL server
http://mtaulty.com/blog/(1rarpnzt1xi0va454dvvas3k)/archive/2004/05/24/430.aspx).
Though given that you are seeing the problem this would imply that yes the
CLR is switching the .Net thread to another process thread on another
machine. The problem I see with this is that DirectX is not by default
thread safe so hopping the rendering thread around multiple threads feels
a little dangerous. I guess as long as its always just on one thread at a
time this won't matter as there won't be any critical sections needed to
provide thread safety. Maybe I'm just too paranoid.
Its an interesting issue though and one that might need some updates to
that article for managed code. I'll see if anyone at Microsoft is
interested.
--
Zman
http://www.thezbuffer.com - News and information for Managed DirectX
"Peter C." <PeterC@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:8014284F-28B2-4ABB-A46F-FF746A9A2F60@xxxxxxxxxxxxxxxx
Thanks for the link. I had missed that article.
From my limited understanding, a Thread in .NET is a conceptual thread,
not
an OS thread. ProcessThreads are OS threads. A Thread can run in multiple
ProcessThreads (unless I've called Thread.BeginThreadAffinity( ) ). A
ProcessThread can run on multiple CPUs (unless I've set its
ProcessorAffinity
property). If I could limit the rendering to one ProcessThread, identify
it
and set its affinity, that might solve the issue. But I don't see a way
for
that to happen.
I mainly posted this because I thought Microsoft would want to know there
might be an issue with this.
"ZMan" wrote:
This may help
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/Game_Timing_and_Multicore_Processors.asp?frame=true
However it sounds like you are talking more about issues with the sample
framework - as far as I know (and I just searched the sample framework
for
'thread') the sample code is not actually multithreaded - it certainly
doesn't turn on the multithreaded flag for D3D. So what you are seeing
is (I
assume) your application being switched across the processors by windows
as
part of its context switching (I had no clue that it could do that).
From
the above article though setting processor affinity is the correct way
to
fix this.
--
Zman
http://www.thezbuffer.com - News and information for Managed DirectX
"Peter C." <PeterC@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:D07E909C-556F-4C65-8478-B4632400D675@xxxxxxxxxxxxxxxx
If this is an old topic or if it's already solved, I'm quite sorry.
I'm using the February 2006 SDK to make an MDX2.0 app. On my dual core
machine, the timing from the Sample Framework (totalTime, elapsedTime)
gets
screwed up. I found the cause, which is that the render code is run in
threads which run on both cores. Since the cores have slightly
different
clock counters and the time is based on them, the current time jumps
backward
and forward small amounts and makes the animation terribly jumpy.
Setting
the
current Process's affinity to either core solves the problem.
Is there a way around this issue without limiting the entire app to
one
core? I've thought about workarounds but I haven't come up with
anything
very
bright yet.
- References:
- Re: Dual core and the Sample Framework
- From: ZMan
- Re: Dual core and the Sample Framework
- From: ZMan
- Re: Dual core and the Sample Framework
- Prev by Date: Re: Create transparent surface on top of windows
- Next by Date: Re: Dual core and the Sample Framework
- Previous by thread: Re: Dual core and the Sample Framework
- Next by thread: Re: Dual core and the Sample Framework
- Index(es):
Relevant Pages
|
