Sign in to follow this  
devronious

Made final performance fixes, please check out...

Recommended Posts

devronious    108
I just got done with the DirectForms final performance improvements and wish that a couple of users can download and test. Perhaps a few from the low end and a few from the high end and inbetween please ? Anyways, I incorperated a speed load and fast size algorithm on top of operating the main vertex buffers as dynamic and giving some size surplus. Sped things up my my system here quite a but. The low end FX5200 didn't see much improvement but the other 7900gt and 6800gtx systems did. This will be great too for people building free projects as the cost to them will be nothing. Next I will have it generate c++ code as well as the current c# code. Should only take a week or two for that. Please download here and test out. Devin

Share this post


Link to post
Share on other sites
Lifepower    136
Still crashes without any error message or warning. [sad]

I'd suggest adding some additional checks so the application at least closes nicely with an error message.

Share this post


Link to post
Share on other sites
devronious    108
Yes. This is because of:

this.presentParams.PresentationInterval = PresentInterval.Immediate;

Just for show so that you can see how little time DirectForms actually takes to scan input and render/process. About 1 ms on my system or 1,000fps.

It's not DirectForms but rather the TechDemo app. The same is true for the CPU Usage. If I use a timer instead of full render loop then I get idle-like load operation. It's just how the app that uses DirectForms is set up.

If I change it to normal op it exits fine. The point I'm hoping to make is that the Entire 5,200 poly DirectForms system that the Tech Demo uses only requires about (on my machine) 1 ms out of the game's frame time.

How did it perform on your system? Can you also give specs please.

Thanks Much,

Devin

[edit] Just so you know how the system works. It uses only 1 VertexBuffer and 1 Texture to operate. The Texture is more like a collage of all the required images and the VertexBuffer is a shared buffer that joins all of the Vertex data into a single buffer. All this equates to fast operation. The shader has been optimized to do as little as possible.

Also it may load slow for now. The error we were having is in the new fastload operation I set up. I disabled it for now. I will figure out the glitch and re-enable it later. Anyways it loads bam fast with the fast load. The error should be a simple thing to fix.

Share this post


Link to post
Share on other sites
Lifepower    136
Quote:
Original post by devronious
OK, this should fix that problem, Font might be large and load slower but for now, please try this...

Unfortunally, I'm still having application crash right after selecting resolution and clicking "Start". It changes video mode and I see hard disk activity, then Windows says that app has a problem and will be closed.

You should definitely check whether all resources are loaded properly and everything you use is created properly. Seems to me like a non-handled Direct3D error.

Again, my machine is Intel Core 2 Duo 1.86 Ghz, 2.5 Gb RAM, Nvidia GeForce 7600 GS. I'm running Win XP Pro SP2, .NET Framework 1.1 and 2.0, using debug DirectX runtimes (I also have DX SDK October 2006 installed, if that matters), latest Nvidia video drivers. I have another machine, which seems to have the same problem (maybe because it has similar system setup?).

Let me know if there is more info I can give you to help fixing the problem.

P.S. I have checked the tech demo several times already but have not yet seen it working. If you want me to continue checking the demo to see if the problem has been fixed, please provide a ZIP package instead of installer; having to install/uninstall it each time starts to be a little tedious. [embarrass]

Share this post


Link to post
Share on other sites
devronious    108
Quote:
having to install/uninstall it each time starts to be a little tedious.


No prob and thanks for helping. Your system is very similar to the one I have here.

Please download the following Tech Demo executable file and put into the Tech Demo directory. This should report at least the general area where the problem resides.

EXE File

Thanks,

Devin

Share this post


Link to post
Share on other sites
Imgelling    222
~300 fps
50% cpu load, doesnt matter if I have the max fps checked or not, cpu load stays the same.

It didn't seem to properly exit. Window closes but it is still running in my task manager.

I used fullscreen 1680x1050 60hz.


Ok, I used the same resolution but windowed, got 17fps and when I clicked the X to close the window, it shutdown properly. Pressing esc in windowed mode shut the program down correctly. Wonder why it doesn't in fullscreen.

Oh yeah, in windowed mode, I opened up the task manager. Memory usage was at 38megs, then started to creep up, 2k at a time..then a huge jump to 40.5Megs then kept increasing by 2k for a while before I shut it down.

Just tried it again, I did not get the huge jump up to 40Megs, but it still grew in memory consumption.

System Specs:
P4-3.0 Ghz
2 gigs ram
Geforce 7600 512MB ram pci-express

Share this post


Link to post
Share on other sites
devronious    108
Cool thanks. I beleive the reason the demo sticks in memory is because of the way I setup the device. If you try unchecking the MaxFPS checkbox a little while before exiting it shouldn't hang around in the process list. Has to do with the Present Interval too high.

Weird that your windowed mode is so slow. Must be driver? I'll check the mem issue.

Share this post


Link to post
Share on other sites
Imgelling    222
Ok, tried unchecking the MAXFPS box before closing. Closes correctly.

In the settings, it is using a 16bit (r5b6g5) format, my desktop is 32bit. That may be causing the slow down.


..running program again...
Oops, just saw the 32bit format option. Ok, it runs at ~300fps. Sorry, didn't see that.

Now about that Present Interval, being set to Immediate shouldn't be causing a problem. All my games, demos, and what not use that interval (as it turns off vsync). No problems with those. But, I guess I shouldn't assume how your doing things.

But, forgot to mention, your GUI looks great! Good work! I am currently looking into creating my own for XNA as I haven't found any available that I like. Besides, learning from doing is usually the best way for me.

[Edited by - Imgelling on May 8, 2007 9:45:49 PM]

Share this post


Link to post
Share on other sites
devronious    108
Quote:
But, forgot to mention, your GUI looks great! Good work!


Thanks, Cool thing is that it's just a skin. You can have many different skins for the same GUI and it totally changes the appearance of it, but workings are the same. I think this would be cool in a game. Choose your GUI skin.

The immediate interval prob, might have something to do with event hooks at the device object. And that at that speed it can't unhook them fast enough. I'll look into that too. I noticed that if I only run it that way for a second or two it does exit the process list but takes a second or two.

BTW, did you overwrite the executable with the one I posted 4 posts ago?

Share this post


Link to post
Share on other sites
Imgelling    222
No, I haven't. Will do now..

I have now. Not seeing any difference in anything. Is there something I should be looking for? I know it doesn't report any errors or anything.

Same fps and cpu load. And still the immediate interval closing problem.


Just curious, I see your using C#. So are you using MDX1.1, MDX2.0, or XNA?

Share this post


Link to post
Share on other sites
devronious    108
Quote:
Just curious, I see your using C#. So are you using MDX1.1, MDX2.0, or XNA?


MDX 1.1.

The new executable just gives the proper format and better error reporting.

...

The mem issue and process list problem are one in the same. I have an object that renders to the RenderTarget which is the texture I use for the whole system.

1. I store the old rendertarget and depthbuffers into variables.
2. Set my custom rendertarget and depthbuffers.
3. Render
4. Restore the original rendertarget and depth buffers.
5. Dispose of variable stored rendertarget and depthbuffers.

This seems to eat away at memory even though I'm disposing of the stored data. Also causes the hang on shut down. What to do???

Any ideas why?

Share this post


Link to post
Share on other sites
Headkaze    607
System: P4 3Ghz, 1Gig RAM, GeForce 6600 GT

1280x1024 75hz Windowed Mode (Maximized)
30 FPS, 60% CPU Load

1280x1024 75hz Fullscreen Mode
342 FPS, 50% CPU Load (I get 589 FPS when I close the window with the listview)

Share this post


Link to post
Share on other sites
Headkaze    607
Quote:
Original post by devronious
Quote:
Just curious, I see your using C#. So are you using MDX1.1, MDX2.0, or XNA?


MDX 1.1.

The new executable just gives the proper format and better error reporting.

...

The mem issue and process list problem are one in the same. I have an object that renders to the RenderTarget which is the texture I use for the whole system.

1. I store the old rendertarget and depthbuffers into variables.
2. Set my custom rendertarget and depthbuffers.
3. Render
4. Restore the original rendertarget and depth buffers.
5. Dispose of variable stored rendertarget and depthbuffers.

This seems to eat away at memory even though I'm disposing of the stored data. Also causes the hang on shut down. What to do???

Any ideas why?


The hanging on shutdown does not occur for me in Windowed mode, only fullscreen mode. Perhaps that might help you identify the problem.

- Have you tried running the DirectX runtimes in debug mode?
- Have you tried wrapping the whole thing in a try/catch and also do a global error hook by adding an event handler to the Application.ThreadException event. Perhaps output any errors when this occurs to a log file?
- It's hard to help beyond that without seeing code, but to exit you should call Application.Exit() which will then trigger the Form_Close() event. Have a cleanup routine in Form_Close(). Do not try to manually close the form using Form.Close(), just use Application.Exit().
- Also post your render loop, I'm getting an icon from the taskbar icon tray drawing through the window.

Share this post


Link to post
Share on other sites
devronious    108
Headkaze,

Thanks for checking it out. If you want to run the Demo without full cpu load then uncheck MaxFPS during the resolution selection dialog at startup. [edit] you must have the latest "DirectForms Tech Demo.exe" file downloaded from the above link or fresh installation of the Tech Demo for 0% CPU Load to work.

Here's the problem render loop area...

[source lang = "c#"]
Surface db = this.Device.DepthStencilSurface;
Surface rt = this.Device.GetRenderTarget(0);
this.Device.DepthStencilSurface = this.depthBuffer;
this.Device.SetRenderTarget(0, this.DirectForms.MasterImage.MasterTexture.GetSurfaceLevel(0));

base.Device.Clear(ClearFlags.Target | ClearFlags.ZBuffer, base.BackgroundColor, 1, 0);
this.SceneObjects.Draw();

this.Device.DepthStencilSurface = db;
this.Device.SetRenderTarget(0, rt);
db.Dispose();
rt.Dispose();




As you can see I'm fetching the rendertarget and depth buffer, replacing them and then restoring them later. At the end I dispose them. But this code still eats away at memory.

Share this post


Link to post
Share on other sites
sirob    1181
The surface returned from :
this.DirectForms.MasterImage.MasterTexture.GetSurfaceLevel(0)
is never disposed. That will cause a leak.

Also, this portion of code isn't exception safe, and will leak in the case of any exception. You should be using the using () { } syntax to assure the objects are disposed of even in the case of an exception.

Share this post


Link to post
Share on other sites
sirob    1181
Quote:
Original post by devronious
So I should add using statements for both the rendertarget and depthbuffer?

And the surface you set as a temporary rendertarget.

You should be using the using () {}; syntax for any temporary disposable you hold. If you're not saving a reference to the object as a member, any exception would cause you to lose the reference to the object. The using syntax assures the object will be disposed of no matter what.

Also, any object holding references to IDisposables (any D3D interface) needs to be disposable too, and it's Dispose method needs to call Dispose on all it's disposable members.

Failing to do any of these things would result in the device failing to reset if it is ever lost, and is also just sloppy.

Hope this helps.

Share this post


Link to post
Share on other sites
devronious    108
Thanks Sirob,

Quote:
Also, any object holding references to IDisposables (any D3D interface) needs to be disposable too, and it's Dispose method needs to call Dispose on all it's disposable members.


Yes I have everything setup this way. Although not everything is wrapped in a using statement though. Only temporary uses of DirectX resources would I wrap in such a statement. Correct?

Share this post


Link to post
Share on other sites
Lifepower    136
Quote:
Original post by devronious
Please download the following Tech Demo executable file and put into the Tech Demo directory. This should report at least the general area where the problem resides.

I did and it crashed again, without saying anything. Maybe you can create a log file (some text file on disk) and write calls there so we can know where the problem occurs?

Share this post


Link to post
Share on other sites
devronious    108
Lifepower,

strange you are having such trouble.

OK, this file should report on every possible error. Please download and overwrite your existing exe file with it. Also, please run the demo in windowed mode.

EXE File

I'll work on a log file if this doesn't report. This should as every call possible is in a try-catch statement, from the Program.cs file to the Form.cs file.

Thanks,

Devin

Share this post


Link to post
Share on other sites
devronious    108
Cool. That really helps me know where to look. This is strange. I will investigate possible areas. I am running the April SDK. I wonder if that matters. Anyways, I will generate an exe that focuses on that area for debug data.

Thanks,

-Devin

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this