Jump to content

Why does DirectX use more memory than OpenGL?


Recommended Posts

I'm hoping this is the right area to post this. But I have a question that I have never seen any explanation posted for anywhere on the internet:

Why does (at least in KSP) DirectX use obscenely more memory (usually more than 2x) than OpenGL mode?

When you have the correct hardware, there is no visual differences between the two whatsoever. There should be negligible or NO difference in memory usage whatsoever. (Especially on the texture memory side of things)

The only rational explanation I can think of immediately, is that due to an error by Microsoft, Unity, or Squad, (Or any combination of the 3) DirectX mode is loading the textures into memory twice.

Does anyone have an actual, detailed explanation?

Link to comment
Share on other sites

OpenGL works differently to DirectX. On my hardware, I lose memory using OpenGL.

Rational explanations can't explain computers - it must be quantum ^^.

Expect many 'actual, detailed explanations' - ignore them all, except as it works on your particular machine.

(Obviously, the technologies are doing much the same job and largely in the same ways, but you really can't compare them directly).

Link to comment
Share on other sites

That's in part due to the fact that the OpenGL is an open source library whose code is well known and can be adapted for optimization (mainly because it's free). DirectX being proprietary, holds other restrictions that keep certain optimizations from happening. You can only use the API the way it is and said API is restricted to the Windows OS (Linux and OSX games have to be ported to use OpenGL instead when you have a Linux or OSX version.)

Link to comment
Share on other sites

That doesn't explain why it is using that much RAM... We are talking about 1-2 Gb's.... This kind of amount must be due to textures...... since they both load the same texture files (And the filesize of the textures doesn't even total that much) it sure looks like someone made a boo boo and it's loading them twice.

Link to comment
Share on other sites

That doesn't explain why it is using that much RAM... We are talking about 1-2 Gb's.... This kind of amount must be due to textures...... since they both load the same texture files (And the filesize of the textures doesn't even total that much) it sure looks like someone made a boo boo and it's loading them twice.

Could be, that on your specific video card, DirectX textures are stored as raw, and OpenGL textures are stored as compressed textures in memory.

Or that in your case, the OpenGL implementation does not do bump/specular mapping and thus does not need to load the textures for that, saving a lot of memory.

Or, that the OpenGL implementation uses smaller texture sizes because your video card opengl driver does not support bigger textures. (Some of the textures in KSP are huge)

(I'm a software engineer, and I maintain an application that uses OpenGL, which is fun any annoying sometimes. Windows OpenGL drivers is a minefield)

Link to comment
Share on other sites

That's in part due to the fact that the OpenGL is an open source library whose code is well known and can be adapted for optimization (mainly because it's free). DirectX being proprietary, holds other restrictions that keep certain optimizations from happening. You can only use the API the way it is and said API is restricted to the Windows OS (Linux and OSX games have to be ported to use OpenGL instead when you have a Linux or OSX version.)

This is false, OpenGL is NOT a library but a free (as in free beer) API. Graphics card vendors will make their own implementations in the drivers that go with the card. They can create and release extensions to it but the process is quite restrictive. There is an open source implementation called MESA aimed to linux-like architectures however the latest version (10.4) only supports openGL 3.3 rather than the newest OpenGL 4.5.

Some drivers will keep the buffer memory in application memory (allocated by the dll you have to load when accessing OpenGL) as a cache or move it to a different process like the memory allocated to the driver or on the GPU memory or in swap-space. What will actually happen is entirely up to the implementation and the restrictions the OpenGL spec provides (like that you should always be able to read your own buffers).

Link to comment
Share on other sites

This is false, OpenGL is NOT a library but a free (as in free beer) API. Graphics card vendors will make their own implementations in the drivers that go with the card. They can create and release extensions to it but the process is quite restrictive. There is an open source implementation called MESA aimed to linux-like architectures however the latest version (10.4) only supports openGL 3.3 rather than the newest OpenGL 4.5.

Some drivers will keep the buffer memory in application memory (allocated by the dll you have to load when accessing OpenGL) as a cache or move it to a different process like the memory allocated to the driver or on the GPU memory or in swap-space. What will actually happen is entirely up to the implementation and the restrictions the OpenGL spec provides (like that you should always be able to read your own buffers).

While I do know the difference between Open Source and Free Software, I don't really care which term is used, since the context is more important than the 'correct term'.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...