A window quession?

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

A window quession?

Postby Julio Jerez » Tue Jan 06, 2009 1:22 pm

I am running the engine under vtune and I find something very bad
Here is the main thread timing

"ntkrnlpa.exe","NewtonDemos.exe","8,660"
"ntdll.dll","NewtonDemos.exe","4,536"
"nvoglnt.dll","NewtonDemos.exe","2,536"
"hal.dll","NewtonDemos.exe","2,276"
"kernel32.dll","NewtonDemos.exe"
"newton.dll","NewtonDemos.exe","315"
"NewtonDemos.exe","NewtonDemos.exe","285"
"Ntfs.sys","NewtonDemos.exe","70","46"

There is a fix cost impuse by application ntkrnlpa.exe,
This cost is added to all child threads, a s you can see the Newton DLL overhead of eth main thread is negrgible only 215 sample as compel to 8660 from that app

Now he is the timing in one of the children thread that I s doing the heavy lifting on collision and solver

"newton.dll","NewtonDemos.exe","5,874"
"hal.dll","NewtonDemos.exe","103"
"ntkrnlpa.exe","NewtonDemos.exe","40"
"kernel32.dll","NewtonDemos.exe","8"
"ntdll.dll","NewtonDemos.exe","2"

Which I found normal sine newton dll is doing lot of work, but the time, does any body know what
ntkrnlpa.exe is. That function is making everything to waist lots of time on the main thread
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: A window quession?

Postby JernejL » Tue Jan 06, 2009 3:06 pm

nvoglnt is gpu driver,

I asked reactos developers that i know and they tell me that ntkrnlpa.exe does this: http://en.wikipedia.org/wiki/Physical_Address_Extension
in essense it supports different memory paging layout to use more ram than normally 32 bits could address.

if it uses so much cpu i think it means it has a lot of memory paging operations..
Help improving the Newton Game Dynamics WIKI
User avatar
JernejL
 
Posts: 1578
Joined: Mon Dec 06, 2004 2:00 pm
Location: Slovenia

Re: A window quession?

Postby martinsm » Tue Jan 06, 2009 3:19 pm

I think that is because Newton SDK demo's uses immediate mode or vertex arrays for rendering. So for each frame gpu driver must send a lot of data (vertex positions, normals, colors, other attributes) from CPU to GPU. You should consider using VBO's (Vertex Buffer Objects), they should boost performance significantly. VBO will allow to store static data (vertex positions, normals, colors, texcoords) directly in GPU memory so no large memory transfer will be required each frame. For dynamic data like debug view from Newton it will still be needed to display dynamic data, but VBO should be able to do it more efficiently than vertex arrays or immediate mode calls (glBegin, glVertex, ..., glEnd).
martinsm
 
Posts: 86
Joined: Mon Dec 19, 2005 3:15 pm
Location: Latvia

Re: A window quession?

Postby Julio Jerez » Tue Jan 06, 2009 4:03 pm

Ha that makes sence, I have 900 geometries each its one buffer.
after I changed the format I wave the caching to make simpler butthat made the SDK very jumpy and erratic.
I can either use BVO, or add the Instance, Or both.
The reason I did not want to use BVO, is because some mesa driver do not soppurt them and I did not want to deal with that too much.
But then I get reports of hipcops.
This is way more severa in Linux systems, but I could figure out what was coussing the slow down.
Anyway that's good to know.

Thank you.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 18 guests

cron