BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  RAM shared by graphics chip - something to worry about? Goto page 1, 2  Next          BorlandTalk.com Forum Index -> Delphi Non-Technical View previous topic :: View next topic   Author Message David Clegg Guest Posted: Fri May 07, 2004 12:08 am    Post subject: RAM shared by graphics chip - something to worry about? I've finally roped my employer into replacing my current laptop, due to (among other factors) some gnarly problems with the TFT screen. The one they're looking to buy me has an integrated Intel graphics chip which can share up to 64 MB of RAM. They intend to get me one with 1Gb total RAM. As this machine will be primarily used for development (Delphi Win32, C++ Win32, and C#), is this shared memory going to be a performance problem? I've never had experience with a system using shared memory like this, but my initial reaction would be to get one with a video chipset which uses dedicated memory. Before suggesting one which doesn't share memory in this fashion, I want to make sure it isn't incurring an unnecessary expense. -- Cheers, David Clegg dclegg_at_ebetonline_dot_com Vote 1 http://cc.borland.com/codecentral/ccweb.exe/listing?id=21489 Coming Soon! Google Groups searching with Dyna-extend(tm) technology! Quality Central. The best way to bug Borland about bugs. http://qc.borland.com "You couldn't fool me on the foolingest day of the year with an electrified fooling machine." - Homer Simpson Back to top OBones Guest Posted: Fri May 07, 2004 1:28 am    Post subject: Re: RAM shared by graphics chip - something to worry about? David Clegg wrote: Quote: I've finally roped my employer into replacing my current laptop, due to (among other factors) some gnarly problems with the TFT screen. The one they're looking to buy me has an integrated Intel graphics chip which can share up to 64 MB of RAM. They intend to get me one with 1Gb total RAM. As this machine will be primarily used for development (Delphi Win32, C++ Win32, and C#), is this shared memory going to be a performance problem? I've never had experience with a system using shared memory like this, but my initial reaction would be to get one with a video chipset which uses dedicated memory. Before suggesting one which doesn't share memory in this fashion, I want to make sure it isn't incurring an unnecessary expense. Well, shared memory has an impact on all the system, because it requires the CPU to handle the sharing of the memory. Further, if your programs are making use of graphics, then this will slow you down and this is really noticeable. So you'll say that you're not doing graphics, just development. But considering that you will be doing C#, then you will be using the .Net IDE which does a lot of use of the graphics to create that "not so" neat and clean view. Basically, if the price difference is not that crucial, go for the dedicated memory, you won't regret it. After all, there is only a 5% difference at most in the two... Back to top David Clegg Guest Posted: Fri May 07, 2004 1:34 am    Post subject: Re: RAM shared by graphics chip - something to worry about? OBones wrote: Quote: Basically, if the price difference is not that crucial, go for the dedicated memory, you won't regret it. Thanks, thats good enough for me. :-) I just spoke to the purchasing guy, and he's happy to up the ante for me. He's also checking out upping the RAM to 2Gb. Mmmm...... -- Cheers, David Clegg dclegg_at_ebetonline_dot_com Vote 1 http://cc.borland.com/codecentral/ccweb.exe/listing?id=21489 Coming Soon! Google Groups searching with Dyna-extend(tm) technology! Quality Central. The best way to bug Borland about bugs. http://qc.borland.com "Just because I don't care doesn't mean I don't understand." - Homer Simpson Back to top OBones Guest Posted: Fri May 07, 2004 2:13 am    Post subject: Re: RAM shared by graphics chip - something to worry about? David Clegg wrote: Quote: OBones wrote: Basically, if the price difference is not that crucial, go for the dedicated memory, you won't regret it. Thanks, thats good enough for me. :-) I just spoke to the purchasing guy, and he's happy to up the ante for me. He's also checking out upping the RAM to 2Gb. Mmmm...... You lucky b... Back to top Rene Tschaggelar Guest Posted: Fri May 07, 2004 8:11 am    Post subject: Re: RAM shared by graphics chip - something to worry about? OBones wrote: Quote: David Clegg wrote: I've finally roped my employer into replacing my current laptop, due to (among other factors) some gnarly problems with the TFT screen. The one they're looking to buy me has an integrated Intel graphics chip which can share up to 64 MB of RAM. They intend to get me one with 1Gb total RAM. As this machine will be primarily used for development (Delphi Win32, C++ Win32, and C#), is this shared memory going to be a performance problem? I've never had experience with a system using shared memory like this, but my initial reaction would be to get one with a video chipset which uses dedicated memory. Before suggesting one which doesn't share memory in this fashion, I want to make sure it isn't incurring an unnecessary expense. Well, shared memory has an impact on all the system, because it requires the CPU to handle the sharing of the memory. Further, if your programs are making use of graphics, then this will slow you down and this is really noticeable. So you'll say that you're not doing graphics, just development. But considering that you will be doing C#, then you will be using the .Net IDE which does a lot of use of the graphics to create that "not so" neat and clean view. Basically, if the price difference is not that crucial, go for the dedicated memory, you won't regret it. After all, there is only a 5% difference at most in the two... Not necessarily. It is not the CPU doing the sharing, but usually a modified bus controller. There may or may not be a negative impact. That depends on what the graphic controller does. With a unified architecture, there is no slowdown through the AGP bus. And flipping a page is just a change of a pointer. I once had a machine that was based on a shared architecture. It delivered a peak performace undreamed of for a split achitecture at that time. Now at great increased clockrates, I'd expect a performance boost from a unified memory architecture against a split memory. Simply as the graphic controller and the CPU mostly operate on their own cache. Memory is not faster than 300MHz, while the CPU is 10 times faster. Also consider, that at a refreshrate of 60Hz for a TFT, that is also the limit of the framrate for the graphics part. At a resolution of 1kx1k, a fill then takes 1Meg write accesses, or roughly 20% of the memory bus bandwidth. That is the worst case when watching a movie for example, the graphics controller has almost nothing to do. That'd be this way also for a split architecture as the CPU reads the movie and has to transfer it through the AGP to the graphics section. The difference now comes for the read accesses, when the movie images are being read out to the DACs. A split architecture has the read on the seperate image memory and therefore no load on the main memory. A blunt approach of a unified architecture takes another 20% of the memory bus bandwidth. And a sophisticated unified approach would have multiported memory access through the bus controller. My old machine had it this way, I have no idea whether this approach is now standard or not. Rene -- Ing.Buro R.Tschaggelar http://www.ibrtses.com Your newsgroups @ http://www.talkto.net Back to top Richard Foersom Guest Posted: Fri May 07, 2004 8:23 am    Post subject: Re: RAM shared by graphics chip - something to worry about? This thread is a bit far from Delphi, but here goes... Quote: Well, shared memory has an impact on all the system, because it requires the CPU to handle the sharing of the memory. It is not the CPU that handle the sharing of memory, it is done by the chipset, the chip often called the north bridge (*1). The shared memory is a draw back because CPU memory access must wait whenever the video chip makes a memory access. Longer tech explanation further down at (*2). Quote: Further, if your programs are making use of graphics, then this will slow you down and this is really noticeable. Ever since the days of Windows 3.1 PCs has been using graphics all the time . Rather shared meory will be a problem for programs making lots of CPU memory access and at the same time video uses high pixel resolution and refresh rate. Typically a limitation for games or video processing. Nowadays with a low resolution of just 1024*768 pixels, typical business applications e.g. word processing, using the Delphi IDE etc. would not suffer from shared memory, because most memory access happens within the CPU cache. A different problem for shared memory systems are, that the integrated video chip usually is a run-of-the-mill product, so no special 3D graphics accelleration or so. If you can claim you need 1600*1200 or higher screen resolution or need video processing, then definately go for separate video graphics. For standard business notebook shared memory would not matter, other issues like harddisk speed would be more important. A company like Dull computer will tell you what specific CPU is in the system but the harddisk is just specified by size. Dull wants you to believe all harddisks are the same, which is ofcourse not true, just take a look in the DE C't magazine (2004/9) or at <http://www.storagereview.com/>. Doei RIF -------- (*1) Only for the AMD Optoron (64 bit CPU) the north bridge memory controller is build into the CPU. (*2) Tech explanation about video chip shared memory: Because the screen pixels contiously need to be refreshed, the video chip continously needs to access the memory to get the pixel data. The higher the screen resolutions the more memory is need to be read for each frame. Also with true color rather then 16 bit color again more data needs to be read per frame. Also higher screen refresh rate (75Hz etc.) multiplies the memory needed to be read per second. With normal RAM e.g. DDR, SDRAM, only one memory action can happen at a time, so the CPU must wait whenever video chip makes a memory access. The video chip needs the priority because the screen update can not wait, both for CRT and LCD. If the video chip would not be able to read the data on time, "snow" would appear on the screen. Oldtimers might recall the "snow" effect on the original IBM PC CGA video cards (mid 1980'ies), which did not handle memory arbitration proper in hardware. Turbo Pascal had a software work around, which would only update the video memory at safe times (when the CRT beam was off screen). Back to top Barry Kelly Guest Posted: Fri May 07, 2004 11:50 am    Post subject: Re: RAM shared by graphics chip - something to worry about? "David Clegg" <dclegg (AT) nospam (DOT) ebetonline.com> wrote: Quote: I've finally roped my employer into replacing my current laptop, due to (among other factors) some gnarly problems with the TFT screen. The one they're looking to buy me has an integrated Intel graphics chip which can share up to 64 MB of RAM. They intend to get me one with 1Gb total RAM. As this machine will be primarily used for development (Delphi Win32, C++ Win32, and C#), is this shared memory going to be a performance problem? I've never had experience with a system using shared memory like this, but my initial reaction would be to get one with a video chipset which uses dedicated memory. Before suggesting one which doesn't share memory in this fashion, I want to make sure it isn't incurring an unnecessary expense. It wouldn't be RAM I'd be worried about - from my experience with the "Intel Extreme-2" on-board graphics chipset, it *eats* CPU power to provide cheap graphics power. It can't even keep up with quickly dragging a fullish (1024x768) window around a 1280x1024 screen - the window lags the mouse by about 1/10th of a second, visible and weird, with approx 85% CPU utilization for the simple blitting that requires - on a 2.5 GHz processor! I have 4+ year old graphics cards with better performance, especially with respect to CPU utilization. Working on a simple GDI+ C# application, I needed to use P/Invoke to get semi-decent performance; .NET has no access to ScrollWindowEx without it. Redraw slowness and scrolling slowness in other applications, especially smooth-scrolling in Internet Explorer: 100% CPU utilization. Intel's graphics suck. -- Barry Kelly People often find it easier to be a result of the past than a cause of the future. Back to top Barry Kelly Guest Posted: Fri May 07, 2004 11:54 am    Post subject: Re: RAM shared by graphics chip - something to worry about? Barry Kelly <barry_j_kelly (AT) hotmail (DOT) com> wrote: Quote: Redraw slowness and scrolling slowness in other applications, especially smooth-scrolling in Internet Explorer: 100% CPU utilization. I neglected to mention that the scrolling isn't actually smooth; it jerks, due to the chip not being able to keep up. -- Barry Kelly People often find it easier to be a result of the past than a cause of the future. Back to top Thomas J. Theobald Guest Posted: Fri May 07, 2004 1:32 pm    Post subject: Re: RAM shared by graphics chip - something to worry about? Unless you decide to be playing some late-model version of Unreal or Doom, this will have no effect on you at all. 64MB is a drop in the bucket of your total RAM, and your CPU won't be touched without running some enormous level of multitasking. The graphics controller onboard and its memory manager will operate independently. Overall, I wouldn't worry about it. T Back to top Richard Foersom Guest Posted: Fri May 07, 2004 1:53 pm    Post subject: Re: RAM shared by graphics chip - something to worry about? Hoi Barry Quote: It wouldn't be RAM I'd be worried about - from my experience with the "Intel Extreme-2" on-board graphics chipset, it *eats* CPU power to provide cheap graphics power. It can't even keep up with quickly dragging a fullish (1024x768) window around a 1280x1024 screen - the window lags the mouse by about 1/10th of a second, visible and weird, with approx 85% CPU utilization for the simple blitting that requires - on a 2.5 GHz processor! It is great to hear your examples of the limitations of integrated graphics and shared memory architecture. It does not really utilize 85% of your CPU power, but it stalls the CPU access to the memory because as I explained in an earlier posting the graphics need to have first priority to memory. You could have a 17GHz processor and it would make no difference, because the limit is the memory access speed. The memory access is something in the order of 300MHz as Rene Tschaggelar explained. Quote: It can't even keep up with quickly dragging a fullish (1024x768) window around a 1280x1024 screen - the window lags the mouse by about 1/10th of a second, visible and weird, with approx 85% CPU utilization for the simple blitting that requires - on a 2.5 GHz processor! How many colors do you use? 16 bit? true color? True color is 24 bit, but most likely stored as 32 bit, so true color requires 100% more memory bandwidth than 16 bit colors. What monitor screen refresh rate do you use? 75Hz, 85Hz, 100Hz? Memory bandwidth requirement goes up as refresh rrate goes up. I do understand why you want to use a resonable high resolution like 1280*1024, rather than the more common 1024*768. 1280*1024 is 66% more pixels than 1024*768, so that is 66% more memory bandwidth eaten. What is the maximum pixel resolution, colors, refresh rate the Intel graphics allow you to do? If you are close to that limit, it probably means the graphics eat a big part of the memory bandwidth. Please Barry, could you temporary try to reduce the colors and screen refresh rate, and tell us if that make the redraw, scrolling and window movement faster. I could like to know if that makes a visible difference. Quote: Intel's graphics suck. <sarcasm> No, how could that be? Intel is the biggest company so it must be the best! </sarcasm>. Doei RIF Back to top JED Guest Posted: Mon May 10, 2004 1:20 am    Post subject: Re: RAM shared by graphics chip - something to worry about? David Clegg wrote: Quote: I've finally roped my employer into replacing my current laptop, due to (among other factors) some gnarly problems with the TFT screen. What machine are you looking at? Back to top David Clegg Guest Posted: Mon May 10, 2004 1:29 am    Post subject: Re: RAM shared by graphics chip - something to worry about? JED wrote: Quote: What machine are you looking at? My choice is limited by the fact that our workplace has an arrangement with Dell. We use them for all our hardware requirements both internally and deployed to clients. It is a toss up between the Latitude D500 and Latitude D600. I'm erring on the side of the latter. It's got a slightly smaller screen, but looks like a gruntier machine overall. I'm quite harsh on notebooks, so durability is important. I use it on the train frequently, and this can really cause problems if the laptop isn't sturdy enough. My prior laptop (before we started purchasing Dells) had to have its screen replaced twice due to serious cracks developing in the housing. -- Cheers, David Clegg dclegg_at_ebetonline_dot_com Vote 1 http://cc.borland.com/codecentral/ccweb.exe/listing?id=21489 Coming Soon! Google Groups searching with Dyna-extend(tm) technology! Quality Central. The best way to bug Borland about bugs. http://qc.borland.com "Hello? Operator! Give me the number for 911!" - Homer Simpson Back to top JED Guest Posted: Mon May 10, 2004 1:45 am    Post subject: Re: RAM shared by graphics chip - something to worry about? David Clegg wrote: Quote: My choice is limited by the fact that our workplace has an arrangement with Dell. We use them for all our hardware requirements both internally and deployed to clients. It is a toss up between the Latitude D500 and Latitude D600. I use and recommend DELL. So you wont get any arguments here. Guess the d800 is out of the question :-( Just make sure you get the HDD size that is 7200rpm. I'd go for a 1.6 D505 personally. Guess it depends what you have at the moment. If you currently have 14 then stick with it, otherwise I couldn't imagine going smaller... Guess because it's a business deal you can't go with an inspiron? Back to top David Clegg Guest Posted: Mon May 10, 2004 1:55 am    Post subject: Re: RAM shared by graphics chip - something to worry about? JED wrote: Quote: Guess the d800 is out of the question I'd imagine so :-) Quote: Just make sure you get the HDD size that is 7200rpm. Alas their web-site doesn't specify the speeds (only capacity). I'll go and talk to the purchasing guy to see if he's got more details. If the 7200 only comes in a max of 20Gb (doubtful), I'd go for a larger capacity one, even though it would be slower. Quote: I'd go for a 1.6 D505 personally. So you don't think having shared video memory would be to detrimental to performance? That was my main reason for upping to the D600. However it came at a cost of downgrading to a 14.1 inch screen. Quote: Guess it depends what you have at the moment. If you currently have 14 then stick with it, otherwise I couldn't imagine going smaller... I have a Latitude C810 with 15 inch screen, so was a little concerned by downsizing to 14.1. It seemed an acceptable trade-off to get dedicated video, but I wonder if I'm worrying overly about the video performance. I can't see it being used for playing high end 3D games (although I like to tell myself it's quite capable of doing so ), Quote: Guess because it's a business deal you can't go with an inspiron? The Inspiron's I've seen appear to be quite flimsy compared to the Latitude. I'd destroy one of those in no time :-) -- Cheers, David Clegg dclegg_at_ebetonline_dot_com Vote 1 http://cc.borland.com/codecentral/ccweb.exe/listing?id=21489 Coming Soon! Google Groups searching with Dyna-extend(tm) technology! Quality Central. The best way to bug Borland about bugs. http://qc.borland.com "This donut has purple in the middle. Purple is a fruit!" - Homer Simpson Back to top JED Guest Posted: Mon May 10, 2004 2:04 am    Post subject: Re: RAM shared by graphics chip - something to worry about? David Clegg wrote: Quote: Alas their web-site doesn't specify the speeds (only capacity). I'll go and talk to the purchasing guy to see if he's got more details. If the 7200 only comes in a max of 20Gb (doubtful), I'd go for a larger capacity one, even though it would be slower. I think 40gig are 7200. 60 are not (speaking from experience). You'll notice it a lot especially running the compiler. Very IO intensive. Quote: I'd go for a 1.6 D505 personally. So you don't think having shared video memory would be to detrimental to performance? That was my main reason for upping to the D600. However it came at a cost of downgrading to a 14.1 inch screen. Well if you aren't going to play games I wouldn't bother with it. The ATI 9000 is an OK card for games but nothing very special at all. It's old as well. Most have 9600 mobilities Quote: I have a Latitude C810 with 15 inch screen, so was a little concerned by downsizing to 14.1. It seemed an acceptable trade-off to get dedicated video, but I wonder if I'm worrying overly about the video performance. I can't see it being used for playing high end 3D games (although I like to tell myself it's quite capable of doing so ), Guess because it's a business deal you can't go with an inspiron? The Inspiron's I've seen appear to be quite flimsy compared to the Latitude. I'd destroy one of those in no time Well I have an 8500 and if you are careful they are fine. No problems here. I'd check out the 600m (separate graphics - small screen) or 8600 - dream screen (1920 x 1200 - yum!). Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> Delphi Non-Technical All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C++ Builder Newsgroups----------------C++ BuilderC++ Builder (ActiveX)C++ Builder (Announcements)C++ Builder (Command Line Tools)C++ Builder DatabasesC++ Builder Databases (ADO)C++ Builder Databases (Desktop)C++ Builder Databases (InterBase Express)C++ Builder Databases (Multi-Tier)C++ Builder Databases (SQL Servers)C++ Builder (Graphics)C++ Builder (IDE)C++ Builder (Internet)C++ Builder (Internet Socket)C++ Builder (Internet Web)C++ Builder (Jobs)C++ Builder (Language)C++ Builder (Language C++)C++ Builder (Compatibility with MFC)C++ Builder (Native API)C++ Builder (Non-Technical)C++ Builder (Students)C++ Builder (Third Party Tools)C++ Builder (Upgrade)C++ Builder (VCL)C++ Builder (VCL Components Usage)C++ Builder (VCL Components Development)C++ Builder (VCL Usage)C++ Builder (WinAPI)C++ Builder Installation Delphi Newsgroups----------------Delphi (General)Delphi ActiveX Controls UsageDelphi ActiveX Controls DevelopmentDelphi As400Delphi DatabasesDelphi Databases (ADO)Delphi Databases (dbExpress)Delphi Databases (Desktop)Delphi Databases (InterBase Express)Delphi Databases (Multi-Tier)Delphi Databases (SQL Servers)Delphi DeploymentDelphi GraphicsDelphi IDEDelphi InternationalizationDelphi InternetDelphi Internet Isapi-WebBrokerDelphi Internet WebSnapDelphi Internet WinsockDelphi JobsDelphi Language BASMDelphi Language ObjectPascalDelphi Model Driven Architecture (General)Delphi Model Driven Architecture (Third Party)Delphi MultimediaDelphi Native APIDelphi Non-TechnicalDelphi ObjectPascalDelphi OLE AutomationDelphi OO designDelphi OpenToolsAPIDelphi Reporting-ChartingDelphi RTLDelphi StudentsDelphi TeamSourceDelphi Thirdparty ToolsDelphi Thirdparty Tools (General)Delphi Thirdparty Tools (IntraWeb)Delphi Thirdparty Tools (RaveReports)Delphi UpgradeDelphi VCLDelphi VCL ComponentsDelphi VCL Components UsingDelphi VCL Components WritingDelphi WebServices SOAPDelphi WinAPIDelphi XMLDelphi Installationcomp.lang.pascal.delphi.components.misccomp.lang.pascal.delphi.components.usagecomp.lang.pascal.delphi.components.writingcomp.lang.pascal.delphi.databasescomp.lang.pascal.delphi.misccomp.sources.delphi JBuilder Newsgroups----------------JBuilderJBuilder AnnouncementsJBuilder Applet IssuesJBuilder As400JBuilder CompilerJBuilder CORBA/RMIJBuilder DatabasesJBuilder DB SwingJBuilder DebuggerJBuilder DeploymentJBuilder DocumentationJBuilder EnterpriseJBuilder HandheldJBuilder IDEJBuilder JavaJBuilder JavaAPIJBuilder Java LanguageJBuilder Java SwingJBuilder Java BeansJBuilder Java Beans UsageJBuilder Java Beans DevelopmentJBuilder JBCLJBuilder JDataStoreJBuilder JobsJBuilder LinuxJBuilder MacintoshJBuilder & MobileSetJBuilder MultiLingual AppsJBuilder Non-TechnicalJBuilder OpenToolsJBuilder Servlets (JSP)JBuilder StudentsJBuilder Team DevelopmentJBuilder Thirdparty ToolsJBuilder UpgradeJBuilder Installation InterBase Newsgroups----------------InterBaseInterBase Bug DiscussionInterBase GeneralInterBase IBConsoleInterBase OpenSourceInterBase ReplicationInterBase SQLInterBase ThirdpartyInterBase Installation Miscellaneous Borland Newsgroups----------------AppCenterAppServerEnteraVisiBroker  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.