Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


mind in a box

Member Since 20 Apr 2010
Offline Last Active Mar 26 2015 06:26 AM

Posts I've Made

In Topic: ConstantBuffer is leaking memory after release

12 March 2015 - 08:24 PM

I know about that. The strange thing is, that this allocated memory persists, even after a call to Present, which flushes the pipeline as far as I know.

One user made me aware of this because he ran out of memory after loading a save-file 20 times.

 

I guess I'll have to do more tests with this tomorrow or something. Maybe something else is badly screwing up there.


In Topic: ConstantBuffer is leaking memory after release

12 March 2015 - 12:51 PM

Well, I boiled it down to repeatedly adding and removing an object many times first. I then have two different kinds of objects I have to deal with. One with has this constantbuffer and one which has none at all, just POD, and with that one everything is fine.

 

But when running the test with adding and removing an object of said object-type (at load time, in the actual app-code), the memory consumption started to grow.

I then went and narrowed it down to a constant buffer, and then further down to this code, because I was thinking about my wrapper doing something wrong.

 

Now, the test-code I posted is ran right before the actual object would be loaded.

 

Every of such objects have that constantbuffer, and it fills the memory quite well if you have about ~10000 objects going through there on every load of a savegame.


In Topic: Rendering a lot of different geometry

26 January 2015 - 06:12 PM

It actually became a problem when the game ran slower on my weaker laptop then it did with the original render.

 

But actually I just got a decent performance boost by just using straight forward instancing! I'm happy with the performance how it is now. Thanks for your time :)


In Topic: Rendering a lot of different geometry

26 January 2015 - 05:01 PM

Thanks for the replies. I am currently doing frustum and distance culling, which works quite fast. I'm also not trying to eliminate draw-calls, because I get poor performance without them as well, so the cause must be something else.

 

 

Also I've seen lists get generated per-frame of higher than 4kb and be fine, so that probably won't kill you, so long as you're not copying that list too much.

 

8KB per frame is only 480 KB/s and modern cpu can handle about 25GB/s bandwith.

 

I'm just asking, because that looked like a bit much for something which should run as fast as possible and I'm almost out of ideas.

 

Another thing is, that the game I am hooking uses the SmartHeap-Library, which happily hooks into my injected DLL as well, taking care of the memory allocations. Now I don't know how fast that 15 year old library is, I just caught it taking a lot of time when deleting what I thought was my lists.

 

I'm going to try to batch what I can using instancing now, which hopefully doesn't suffer from these problems.


In Topic: Shouldn't the depth-test stop occluded pixels from being shaded?

11 December 2013 - 01:19 PM

We created some meshes which roughly cover the area of our HUD-Elements (Because they have a small fade at the sides) which we are rendering instead of the actual HUD-Elements.

These are the first Objects to render in the whole frame, so what could disable my early-z in such a case?


PARTNERS