Carsten Neumann <[email protected]> schrieb am 26.05.2009 18:34:00:
Hello Carsten,
sorry for the late response.
> One thing I've been wondering about is if the fact that syncNeeded is
> written by one thread and read by another may cause problems. If you
> replace it with an unsigned int and use something like
> _InterlockedExchangeAdd(syncNeeded, 1) to signal the need for a sync,
> _InterlockedExchangeAdd(syncNeeded, 0) to test the value, and
> _InterlockedExchangeAdd(syncNeeded, -1) to set it back you could avoid
that.
I thought reading and writing of primitive types like bool is thread-safe
in the way I use it. I switched to _InterlockedExchangeAdd(), it seems to
be a better solution, thanks for the hint.
> In your initial mail you were also saying that your models have large
> textures, so uploading those may also cause drops in the framerate when
> adding geometry to a scene. Your code unfortunately did not contain the
> timing parts, is it possible that you were timing more than just the
> sync, e.g. did you include the time spend in barriers, or the texture
> upload time?
For measuring the time I use QueryPerformanceCounter():
class Measure
{
public:
Measure()
{
QueryPerformanceFrequency((LARGE_INTEGER*)&frequency);
QueryPerformanceCounter((LARGE_INTEGER*)&time1);
}
~Measure()
{
QueryPerformanceCounter((LARGE_INTEGER*)&time2);
double dTimeDiff =
(((double)(time2-time1))/((double)frequency));
std::cout << "Time: " << dTimeDiff << std::endl;
}
private:
LONGLONG time1, time2, frequency;
};
void display(void)
{
// check creation threads for available changes
if(syncNeeded == true)
{
std::string changes;
changes += "Changed: " +
DL::toString(creationThread->getChangeList()->sizeChanged()) + " / ";
changes += "AddRefd: " +
DL::toString(creationThread->getChangeList()->sizeAddRefd()) + " / ";
changes += "SubRefd: " +
DL::toString(creationThread->getChangeList()->sizeSubRefd()) + " / ";
changes += "Created: " +
DL::toString(creationThread->getChangeList()->sizeCreated()) + " / ";
changes += "Destroyed: " +
DL::toString(creationThread->getChangeList()->sizeDestroyed());
std::cout << changes << std::endl;
Measure m;
syncBarrier->enter(2);
creationThread->getChangeList()->applyAndClear();
syncBarrier->enter(2);
}
mgr->redraw();
renderThread->getChangeList()->clearAll();
}
> Could you run the attached program with your models please and post the
> output? I'd like to be able to compare data points from a single program
> to avoid doubt what exactly is included in my and your timings.
Here are my results from your attached program:
Create thread sync complete
Loading [Pg.obj] - (0 / 417)
renderThread sync: sizeChanged: 122 / sizeAddRefd: 52 / sizeSubRefd: 7 /
sizeCreated: 31 / sizeDestroyed: 0
tSyncStart [381086] tSyncEnd [381086] -- 0.013
tStart [760274448930846] tEnd [760274473936884] -- 25006038 == 12.5344 ms
Time: 1.011 Frames: 56 Fps: 55.3907 Sync: 1
Loading [Ebene01.obj] - (1 / 417)
renderThread sync: sizeChanged: 60 / sizeAddRefd: 24 / sizeSubRefd: 3 /
sizeCreated: 16 / sizeDestroyed: 0
tSyncStart [381087] tSyncEnd [381087] -- 0.003
tStart [760276708610004] tEnd [760276715074536] -- 6464532 == 3.24037 ms
Time: 1.015 Frames: 61 Fps: 60.0985 Sync: 1
Loading [WS_2.obj] - (2 / 417)
Time: 1.017 Frames: 61 Fps: 59.9803 Sync: 0
Time: 1.016 Frames: 59 Fps: 58.0709 Sync: 0
Time: 1.011 Frames: 24 Fps: 23.7389 Sync: 0
Time: 1.064 Frames: 20 Fps: 18.797 Sync: 0
Time: 1.08 Frames: 14 Fps: 12.963 Sync: 0
Time: 1.062 Frames: 29 Fps: 27.307 Sync: 0
Time: 1.58 Frames: 1 Fps: 0.632911 Sync: 0
Time: 1.326 Frames: 1 Fps: 0.754148 Sync: 0
Time: 1.008 Frames: 61 Fps: 60.5159 Sync: 0
renderThread sync: sizeChanged: 93 / sizeAddRefd: 45 / sizeSubRefd: 6 /
sizeCreated: 29 / sizeDestroyed: 0
tSyncStart [381098] tSyncEnd [381098] -- 0.005
tStart [760299344588790] tEnd [760299353130078] -- 8541288 == 4.28135 ms
Time: 1.017 Frames: 59 Fps: 58.0138 Sync: 1
Loading [Am_Markt_10.obj] - (3 / 417)
renderThread sync: sizeChanged: 161 / sizeAddRefd: 76 / sizeSubRefd: 10 /
sizeCreated: 44 / sizeDestroyed: 0
tSyncStart [381218] tSyncEnd [381218] -- 0.153
tStart [760538103277554] tEnd [760538405402064] -- 302124510 == 151.441 ms
Time: 1.077 Frames: 56 Fps: 51.9963 Sync: 1
Loading [Am_Markt_11.obj] - (4 / 417)
renderThread sync: sizeChanged: 217 / sizeAddRefd: 98 / sizeSubRefd: 12 /
sizeCreated: 57 / sizeDestroyed: 0
tSyncStart [381101] tSyncEnd [381101] -- 0.002
tStart [760303499787840] tEnd [760303504259058] -- 4471218 == 2.24121 ms
Time: 1.016 Frames: 60 Fps: 59.0551 Sync: 1
Loading [Am_Markt_12.obj] - (5 / 417)
renderThread sync: sizeChanged: 289 / sizeAddRefd: 122 / sizeSubRefd: 15 /
sizeCreated: 70 / sizeDestroyed: 0
tSyncStart [381102] tSyncEnd [381102] -- 0.003
tStart [760305594148776] tEnd [760305600574980] -- 6426204 == 3.22115 ms
Time: 1.017 Frames: 61 Fps: 59.9803 Sync: 1
Characteristics of some models:
Am_Markt_10.obj: Filesize 5kb, 16 Triangles, 3 Geometries, 3 Textures
(256*512, 2 * 256*256)
Am_Markt_11.obj: Filesize 15kb, 72 Triangles, 4 Geometries, 4 Textures (3
* 256*256, 512*512)
WS_2.obj: Filesize 7.2mb, 59918 Triangles, 2 Geometries, 1 Texture
(256*256)
In that test run the sync of Am_Markt_10.obj took much more time. When I
run the program again, the problem happens on a different object. For me
it seems that the changelist are too big to guarantee short sync times. So
I wrote my own OBJ loader and add only a small piece of the model before
synchronization. What I basically do:
- Read the complete file into an internal data structure
- Create vertex list, sync, create normal list, sync, create material
node, sync, read image, sync, calc mipmaps for image, sync, create
geometry node, sync, and so on?
The changelist are now very small (around 10 changed/created FC?s) and the
problem seems to be gone.
I'll try this week to use an external thread to avoid the drop down of the
framerate when loading large objects (see results above, WS_2.obj). At the
moment I sleep the thread in my OBJ loader after reading 500 lines to
minimize this problem, but I don't think that is a good solution. I'll
post here my results.
Thanks for your help.
Marc
------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
