IEGD allocates lot of virtual memory in process memory space

[JPede3]

Hi

I have an old, large application running under WinXP embedded on a embedded system with a Intel 945 or 965 chipset.

The IEGD version 9.02 is presently used (version 10 apparently does not support color calibration that we need so we can not used that)

Now I observe that certain components in the application causes the IEGD to allocate large chunks (256 Mbyte) of memory space in the 2 Gbyte virtual process memory space.

GDI+, the video merging render VMR7 and some parts of DirectX does that.

In the attached image you can see tow large blocks in shareable memory.

However they do allocate space in the limited 2 Gbyte space for the process.

Is there some way I can get rid of these chunks?

Do I do anything wrong?

Can I setup the system in a different way?

Regards

Jens

[Kirk_B_Intel]

IEGD has a very dynamic and fairly robust memory management capability built in, Newer versions improve upon that and should have color correction capability no different from 9.x versions. If you are having issues with color correction on 10.x, we need to know about it so we can correct any issues.

Usually when you see large chunks of virtual memory getting allocated, it means your application is requesting buffers for texture maps, or other features (like video decode blocks). Many times we see poor programming in an application where it will use a texture but not close it when done. If you clean up the application to better dealloacte the buffers, IEGD will return the memeroy to the heap.

We cannot be much help with your application as we do not offer that sort of support.

Hope this helps,

Kirk

[JPede3]

Hi Kirk

Thank you so much for the answer. I really appreciate the attention.

Regarding the problem with memory allocation I see the huge memory blocks allocated by the IEGD i 3 occasions. When I do my own rendering - that is my problem. I will go trough my code and check if I do everything correct. I think I allocate the textures I need and deliver them back when not needed anymore. I think the problem is specifically connected to allocating dynamic textures in the default pool. Is there any special precausions for that?

Then I see the problem when I use the Mircrosoft VMR7 or VMR9 video renderers.

And when I use Microsoft GDI+.

I do not see a similar behaviour when I run the same code on other platforms than the Intel GPU targets with 945/965 chipsets.

The problem with color calibration in IEGD version 10 I address in another post. Please take a look at that too.

Once again thank you. Intel is improving :-)

Regards

[Kirk_B_Intel]

VRM7 should be OK but I believe there may be issues in 9.x with VMR9 although I do not recall the issues being with memory allocations.

Video rendering is a memory intensive process and I am not surprised large chunks of memory are needed.

I need to get my video decode expert involved to see if any of this makes sense, or what you can do to avoid the issues.

[JPede3]

Hi Kirk

I also see the problem with allocation of large chunks of virtual memory space with VMR7 and GDI+.

I have prepared a small example of rendering with dynamic textures from the default pool.

Try if you can compile it. Remove the .txt extension ot the files. Otherwise I can send the exe-file too.

When I run the example I see the same behaviour with the large block of memory allocated.

I can not see why this happen. I do not see this behaviour on other platforms.

The example was with IEGD ver 9.02.

In the example there is no reason to use dynamic textures, but in my real application I have a pretty static grid of vertex points that I color with textures being updated 30 times/second.

I think dynamic textures is just for cases like that, but I do not want to use 256 MByte of my process space.

Regards Jens

[Kirk_B_Intel]

From your sample, I can understand what you are seeing now. That virtual memory allocation is by design. It is part of the built in memory management. The embedded driver does not implement DVMT and therefore needs to allocate the entire graphics memory virtual space when a 3D application begins to run. This is virtual space (does not use real RAM unless needed) and to date has not impacted system operation. Think of it as the "cost of doing buisness" with 3D embedded graphics use.

Hope this helps.

[JPede3]

Well, even embedded applications can be large and require a lot of memory.

And I know that the allocation not necessary means real physical memory.

But the Windows XP virtual process memory space is "only" 2 Gbyte. When IEGD requires 256 MByte virtual meory a number of times it is a problem for me. If the virtual memory space is fracmented, as it easily gets if you have a lot of DLLs and memory allocations, then a contiguous block of 256 MByte not easily fits in.

A number of questions arise.

1) Is there any form of error message or exception if IEGD can not allocate the block?

In my experience it just sillently fail which is extremely dangerous in an embedded system.

2) In my small example it seems like IEGD does not allocate the 256 MByte block if I allocate the dynamic texture in system memory and afterwards copy it to video memory with IDirect3DDevice9::UpdateTexture. Is it correct that only dynamic textures in default memory cause the IEGD to allocate the 256 MByte block?

3) I observe that when my program both starts VMR7, GDI+ and work with dynamic textures, then 3 blocks of 256 MByte must be allocated by IEGD in order to get all features to work. Is there any way I can cut this to 1 or 2 blocks?

Should all these features be started from the same Windows thread?

Finally could you please also take a look at my other problem reported at

http://embedded.communities.intel.com/message/3392 http://embedded.communities.intel.com/message/3392" rel="nofollow">http://embedded.communities.intel.com/message/3392

Regards Jens

[Kirk_B_Intel]

JensMose wrote:

1) Is there any form of error message or exception if IEGD can not allocate the block?

In my experience it just sillently fail which is extremely dangerous in an embedded system.

Windows is masking the failure that we loudly report from the driver stack- they just do not report it to you. http://www.microsoft.com http://www.microsoft.com" rel="nofollow">www.microsoft.com is where you should complain about that... ;-)

2) In my small example it seems like IEGD does not allocate the 256 MByte block if I allocate the dynamic texture in system memory and afterwards copy it to video memory with IDirect3DDevice9::UpdateTexture. Is it correct that only dynamic textures in default memory cause the IEGD to allocate the 256 MByte block?

The most common to trigger the allocation of the virtual space are dynamic textures and (on US15W) hardware video decode (which potentially needs a ton of memory especially for HD at 1080p). I am not able to list the other cases as they just depend on the potential memory need.

3) I observe that when my program both starts VMR7, GDI+ and work with dynamic textures, then 3 blocks of 256 MByte must be allocated by IEGD in order to get all features to work. Is there any way I can cut this to 1 or 2 blocks?

Should all these features be started from the same Windows thread?

Not positive but the multi-threaded aspects of your routine sure seem to be the reason for the multiple virtual allocations. The driver needs to be positive it has the space avaialble for every thread being used.

Finally could you please also take a look at my other problem reported at

http://embedded.communities.intel.com/message/3392 http://embedded.communities.intel.com/message/3392" rel="nofollow">http://embedded.communities.intel.com/message/3392

Yes

[JPede3]

Hi Kirk

1) I will complain to Microsoft. Thanks for the information.

2) I will try to allocate my dynamic textures in system memory and then use IDirect3DDevice9::UpdateTexture to copy the data to video memory.

Then I must see what the performance penality is, if any.

3) Maybe I can change my thread structure so more things are started from the same thread. Maybe this helps but I doubt.

May I sugest that you consider changing the memory allocation scheme in the future.

The present implementation sure gives problems.

Regards Jens

[Kirk_B_Intel]

Such a change would be seriously traumatic to the driver that has been operating this way for about 6-7 years without any other complaints about the memory scheme. We have evaluated the GMA DMVT scheme and neither the ROI, nor the benefits do not outweigh the risks for our market segments. We certainly will keep it in mind.