Onboard vid memory vs. Card vid memory
Author
Has anyone noticed that when creating a DirectDraw surface in video memory, if the graphics adapter is onboard, the framerate is very slow, but if the adapter is a card, the framerate is very fast.
does anybody know any tricks on what to do about this strange phenomenon? I want people with high powered cards to be able to get optimum performance, but I don''t want to screw over people with onboard video.
Youre making some very broad generalizations here... typically onboard graphics aren''t as good as stand alone graphics cards, if you''re comparing a geforce card of any type with an arbitrary low end onboard video then don''t expect the two to compare.
Now there have been improvements to onboard video... so if you''re comparing an nforce mother board (with an onboard geforce2mx) to a stand alone geforce2 mx, then that''s a different story all together.
Are we talking about apples and apples here.. or apples and crab apples?
Now there have been improvements to onboard video... so if you''re comparing an nforce mother board (with an onboard geforce2mx) to a stand alone geforce2 mx, then that''s a different story all together.
Are we talking about apples and apples here.. or apples and crab apples?
Generally speaking, if the onboard graphics adapter uses the system''s RAM, as opposed to having its own memory then, no matter the card, it will be SLOW.
There are many reasons why it''s true:
- First, the lame excuse, that many people tell you so often. They eat memory that could be used for other applications. This is true only for very low memory configurations. It that was true, it''d be just a matter of adding more RAM.
- When you need to have access to the video memory, nothing else can be using it at the same time. So, even if you''re not doing anything(let''s consider a refresh rate of 60 Hz) your video "card" has to take control of your RAM 60 times per second, for what time it takes to read the contents of the framebuffer. Meanwhile, unless all the data fits in the cache, you processor is starving. The inverse is also true. Now imagine a game, with both the graphics subsystem and the processor demanding huge amounts of data, and I hope you understand now.
- The manufacturer is free to create the video card to use any kind of memory he can think of. They''re not restricted to RAMBUS/DDR/SDRAM or whatever. Remember the time when EDO Ram was the king, and the graphics cards had memories with much lower latencies?
- Last, onboard systems are low budget computers. For that reason, you will not generally find a good graphics "card" onboard. Heck, even the chipsets tend to be awful. Not to mention AC''97 modems/sound.
You don''t want to screw people with onboard video? Try to lower your program''s requirements, just as you''d do for people with crappy offboard video cards.
There are many reasons why it''s true:
- First, the lame excuse, that many people tell you so often. They eat memory that could be used for other applications. This is true only for very low memory configurations. It that was true, it''d be just a matter of adding more RAM.
- When you need to have access to the video memory, nothing else can be using it at the same time. So, even if you''re not doing anything(let''s consider a refresh rate of 60 Hz) your video "card" has to take control of your RAM 60 times per second, for what time it takes to read the contents of the framebuffer. Meanwhile, unless all the data fits in the cache, you processor is starving. The inverse is also true. Now imagine a game, with both the graphics subsystem and the processor demanding huge amounts of data, and I hope you understand now.
- The manufacturer is free to create the video card to use any kind of memory he can think of. They''re not restricted to RAMBUS/DDR/SDRAM or whatever. Remember the time when EDO Ram was the king, and the graphics cards had memories with much lower latencies?
- Last, onboard systems are low budget computers. For that reason, you will not generally find a good graphics "card" onboard. Heck, even the chipsets tend to be awful. Not to mention AC''97 modems/sound.
You don''t want to screw people with onboard video? Try to lower your program''s requirements, just as you''d do for people with crappy offboard video cards.
"adapter uses the system''s RAM," that wouldn''t make much sense, it still should have it''s own memory.
-------
"Programming is like sex make one mistake, and you have to support it forever."
Homepage: www.ussshrike.com/pcwebvia/
-------
"Programming is like sex make one mistake, and you have to support it forever."
Homepage: www.ussshrike.com/pcwebvia/
Author
Ok, I don''t think you guys are getting what I''m asking.
Say you are creating a DirectDraw surface. You can set the flag for the DDSCAPS structure to either SYSTEMMEMORY or VIDEOMEMORY.
Usually, you''d want to set the flag to VIDEOMEMORY, because video memory works faster than system memory. And if you run the program on a computer with a regular graphics card (ie, not onboard), it works as expected.
But when you run the program on a computer with an onboard graphics card, it works the OPPOSITE. The fps, rather than being 75 comparatively, now slows to around 10-13. But when you change the flag to SYSTEMMEMORY, it jumps back up to around 60.
That''s what I''m asking about, what tricks can I use so that it can determine which flag it should set (VIDEOMEMORY on default).
thanks.
Say you are creating a DirectDraw surface. You can set the flag for the DDSCAPS structure to either SYSTEMMEMORY or VIDEOMEMORY.
Usually, you''d want to set the flag to VIDEOMEMORY, because video memory works faster than system memory. And if you run the program on a computer with a regular graphics card (ie, not onboard), it works as expected.
But when you run the program on a computer with an onboard graphics card, it works the OPPOSITE. The fps, rather than being 75 comparatively, now slows to around 10-13. But when you change the flag to SYSTEMMEMORY, it jumps back up to around 60.
That''s what I''m asking about, what tricks can I use so that it can determine which flag it should set (VIDEOMEMORY on default).
thanks.
Wreakon, it should, but cheap onboard cards dont. they used shared memory. this is why cheap pcs that tout 128mb of shared ram and 8mb graphics accelerator really mean 8mb system ram for the video card and 120mb for the restof the system. the 8mb is reserved for video card access only, and there is nothing you can do about it. lukeyes, i never expeirenced your phenomon where the SYSTEM_MEMORY flag made things faster for integrated cards. the best way is to let the driver decide where things go. it knows best.
Author
so you''re saying keep the default of SYSTEMMEMORY (that''s the default for DX''s Blt function, not default is in my specified default). That''s what I''m planning on doing. I''m planning to put a variable in my DirectDraw wrapper that holds whether to use Video memory over System, and when I initialize it keep it to system. But if you run a config program that will come bundled with the game, it will write in the config file that you want to use Video, and then subsequently set it in the program.
But I think you got something with why this may be happening. If the shared video RAM is actually system RAM, then if I''m putting the surfaces in system memory, I AM actually putting them in video. Confusing, yet kinda makes sense to me.
just wanna know if anyone has ran into this problem before.
But I think you got something with why this may be happening. If the shared video RAM is actually system RAM, then if I''m putting the surfaces in system memory, I AM actually putting them in video. Confusing, yet kinda makes sense to me.
just wanna know if anyone has ran into this problem before.
Author
so you''re saying keep the default of SYSTEMMEMORY (that''s the default for DX''s Blt function, not default is in my specified default). That''s what I''m planning on doing. I''m planning to put a variable in my DirectDraw wrapper that holds whether to use Video memory over System, and when I initialize it keep it to system. But if you run a config program that will come bundled with the game, it will write in the config file that you want to use Video, and then subsequently set it in the program.
But I think you got something with why this may be happening. If the shared video RAM is actually system RAM, then if I''m putting the surfaces in system memory, I AM actually putting them in video. Confusing, yet kinda makes sense to me.
just wanna know if anyone has ran into this problem before.
But I think you got something with why this may be happening. If the shared video RAM is actually system RAM, then if I''m putting the surfaces in system memory, I AM actually putting them in video. Confusing, yet kinda makes sense to me.
just wanna know if anyone has ran into this problem before.
Author
so you''re saying keep the default of SYSTEMMEMORY (that''s the default for DX''s Blt function, not default is in my specified default). That''s what I''m planning on doing. I''m planning to put a variable in my DirectDraw wrapper that holds whether to use Video memory over System, and when I initialize it keep it to system. But if you run a config program that will come bundled with the game, it will write in the config file that you want to use Video, and then subsequently set it in the program.
But I think you got something with why this may be happening. If the shared video RAM is actually system RAM, then if I''m putting the surfaces in system memory, I AM actually putting them in video. Confusing, yet kinda makes sense to me.
just wanna know if anyone has ran into this problem before.
But I think you got something with why this may be happening. If the shared video RAM is actually system RAM, then if I''m putting the surfaces in system memory, I AM actually putting them in video. Confusing, yet kinda makes sense to me.
just wanna know if anyone has ran into this problem before.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
