Memory Leak?
Débuté par
TheGreatXL
, nov. 04 2009 06:21
#326
Posté 22 mars 2010 - 04:38
well 1.03 patch or not, im playing awakening and progressively the loading times get longer and longer still. so maybe a major fix has been made, but reasons and causes still exist and conitnue to force the need to exit and reload. oh well, at least u only need to go to the main menu and not reload entirely
#327
Posté 22 mars 2010 - 06:37
I have a similar problem, the game tends to get a bit laggier and load times slightly longer, but only after I've played for several hours on end. I don't really mind it, though, since I see it as a good time to alt + f4 and take a break, get some fresh air, etc.
#328
Posté 22 mars 2010 - 07:23
I have noticed the same and it does help with taking a break but it can be a little annoying as well.
#329
Posté 22 mars 2010 - 08:28
For those of you who have a amd processor you can just install amd fusion and run it that will get rid of the stutters and lag during the game this does not change the load times though, at least for me.
#330
Posté 28 mars 2010 - 11:14
The problem of memory leak has been happening since the release or origins, i have yet to see bioware to come up with a fix for it since 2009, and 14 pages of, people posting their computer stats on the Forum Home » Dragon Age: Origins » Dragon Age: Origins PC Technical Support forums with the same problems, if i missed it no real helpfull information on how to fix it unless u exit to the main game screen then to go back into the saved game. The fact that the problem is still recuring, from patches 1.0 to 1.3 shows the problem is still continuing and no real fix for the memory leak has been programmed.
Modifié par Unkown Networker, 28 mars 2010 - 11:15 .
#331
Posté 06 avril 2010 - 10:52
This occurs on both my dual core AMD system, and my new quad core Intel system. After an hour or two, the loading times increase substantially, and become unbearable once you pass the two-hour mark. Sometimes the game even crashes during loading, if I play it for more than that (say four hours or so). Bioware doesn't seem keen on fixing it... so temporary solutions?
Well, you can always restart the game completely, about every hour. Restarting the application cleans out all the memory, so you can start anew.
Another 'solution' that at least worked on Mass Effect 2 (yes, that game also suffers from insane load times, but there it starts happening almost right away), is to change the processor affinity when the game has started up. Simply tell it to run off only one processor, and it's supposed to help. In ME2, you could simply apply the changes, and then turn on the other processors immediately afterwards, and the issue would be solved, but you can still take advantage of the multicore processing power. I'm not sure if the same thing applies to Dragon Age, however.
As far as I know, that's what we have to make due with, until programmers stop shafting the PC version of these games, and actually start making them without memory leaks occurring. Honestly, this is despicable.
EDIT: After some testing, altering the processor affinity (change it to a single processor, then switch back to all immediately afterwards), works the same in Dragon Age as it does in Mass Effect 2, for me. Memory no longer seems to be leaking (loading times do not increase the longer you play), and to top it off, the loading times also become near instant on my system--sometimes the loading screen doesn't even have time to open up completely. It's like the game finally makes use of my computer's full potential. A simple enough solution, until these lazy programmers can mend their game so that it works as it should.
Well, you can always restart the game completely, about every hour. Restarting the application cleans out all the memory, so you can start anew.
Another 'solution' that at least worked on Mass Effect 2 (yes, that game also suffers from insane load times, but there it starts happening almost right away), is to change the processor affinity when the game has started up. Simply tell it to run off only one processor, and it's supposed to help. In ME2, you could simply apply the changes, and then turn on the other processors immediately afterwards, and the issue would be solved, but you can still take advantage of the multicore processing power. I'm not sure if the same thing applies to Dragon Age, however.
As far as I know, that's what we have to make due with, until programmers stop shafting the PC version of these games, and actually start making them without memory leaks occurring. Honestly, this is despicable.
EDIT: After some testing, altering the processor affinity (change it to a single processor, then switch back to all immediately afterwards), works the same in Dragon Age as it does in Mass Effect 2, for me. Memory no longer seems to be leaking (loading times do not increase the longer you play), and to top it off, the loading times also become near instant on my system--sometimes the loading screen doesn't even have time to open up completely. It's like the game finally makes use of my computer's full potential. A simple enough solution, until these lazy programmers can mend their game so that it works as it should.
Modifié par Kindo, 06 avril 2010 - 06:00 .
#332
Posté 28 juin 2010 - 03:36
i have a quad core amd proc. i tried disabling 2 cores, 3 cores, acually seems to make the
game run worse...so for now i just keep reloading every 20-30 mins. shame this game has such major technical flaws because it really is one hall of a good rpg.
game run worse...so for now i just keep reloading every 20-30 mins. shame this game has such major technical flaws because it really is one hall of a good rpg.
#333
Posté 27 juillet 2010 - 05:05
Bump >.<
#334
Posté 27 juillet 2010 - 05:34
I also have a quadcore (Phenom 9500) and experienced the same problem. I tried disabling the cores: no effect. After some reading I found a solution:
it's called phenomfix. Before I play Dragon Age I click on TLB_Disable.exe and the game runs perfect! But be cautious: use it on your own risk. I don't have problems with it, but I read that it could *&#$@ your system because you disable a protection that's in your processor.
For the loading times I bought Advanced System Optimizer for their Memory Optimizer.
These two did the job for me, and now I can finally enjoy Dragon Age's full potential. It's a pitty that BioWare didn't fix this by itself though...
it's called phenomfix. Before I play Dragon Age I click on TLB_Disable.exe and the game runs perfect! But be cautious: use it on your own risk. I don't have problems with it, but I read that it could *&#$@ your system because you disable a protection that's in your processor.
For the loading times I bought Advanced System Optimizer for their Memory Optimizer.
These two did the job for me, and now I can finally enjoy Dragon Age's full potential. It's a pitty that BioWare didn't fix this by itself though...
#335
Posté 27 juillet 2010 - 07:42
what i have noticed is that the farther into the game i was, the sooner there was a performance drop which was only cured by a game restart. Cant say anything about load times, they were pretty short always. AMD quadcore here
#336
Posté 11 août 2010 - 11:12
It is pretty pathetic if you ask me. I for one will not buy the next game when it comes out until i have some confirmation that there is no stupid leak in it. I can maybe play for 20 minutes and then it starts, talking takes longer, inventory takes longer and the loading times take up to 2 minutes.
#337
Posté 14 août 2010 - 04:29
I have i7 920 overclocked to 3.4 Ghz. 6 GB RAM and this happens to me as well, in origins and awakening.
#338
Posté 20 septembre 2010 - 02:40
Still at least one memory leak on the current build, seems to occur for me if new party members join or I swap any out but annoyingly (perhaps just as well) not every time I do so. Performance definitely drops off after hours of play, which is not entirely unexpected but it does seem quite sharp and even if that time is spent in a relatively small number of locations (so minimal resource swapping). Eventually the game will attempt an illegal memory access and be terminated.
One a side note, the notion that "a 32 bit OS cannot use more than 4GiB of RAM" is bull****. Talk about the blind leading the blind. ;¬)
One a side note, the notion that "a 32 bit OS cannot use more than 4GiB of RAM" is bull****. Talk about the blind leading the blind. ;¬)
#339
Posté 20 septembre 2010 - 03:22
You are all wet, of course. It's Microsoft's Windows after all! ("64 K is enough for anyone"!)
http://msdn.microsof...778(VS.85).aspx
Meanwhile, see the only official anything that looked like there might someday be an answer to this, and it never was answered as such.
"Loading time gradually slowing down; information collection attempt"
http://social.biowar...0984/23#2955988
http://msdn.microsof...778(VS.85).aspx
Meanwhile, see the only official anything that looked like there might someday be an answer to this, and it never was answered as such.
"Loading time gradually slowing down; information collection attempt"
http://social.biowar...0984/23#2955988
Modifié par Gorath Alpha, 20 septembre 2010 - 03:29 .
#340
Posté 20 septembre 2010 - 03:38
Gorath - a lot of that looked like combinations of overheating processors and thrashing disks, to be honest. A few people even claimed their issues went away with new video driver builds; I suspect the technically ignorant simply latched onto this impressive sounding term and naively called whatever issues they had 'a memory leak'. I know there at least one memory fault in there myself only because DEP will catch it and that does take as much as four hours of play to finally happen for me, usually almost immediately after a party member is recruited or I swap out party members. Frustratingly (for troubleshooting) it doesn't do it every time I swap party members (but has done so pretty much every time someone new joins, within a minute or two at most), Unfortunately it could be related to my playstyle as much as anything.
The way myths get passed around by gamers claiming "twenty years of programming experience" is quite amusing, I thought, made me smile enough to care a lot less about this issue. I was only annoyed when it caught me unaware at a point where I'd not saved for quite a while (the first time it happened).
The way myths get passed around by gamers claiming "twenty years of programming experience" is quite amusing, I thought, made me smile enough to care a lot less about this issue. I was only annoyed when it caught me unaware at a point where I'd not saved for quite a while (the first time it happened).
#341
Posté 20 septembre 2010 - 03:55
I don't use "popularized" terms for things that are so far off of the mark as the OP's choice in this thread, and it's doubtful that I've previously added a comment in this old thread. But Microsoft Windows simply has no addresses it can use beyond the 4 GB point, unless it is specifically a 64-Bit version. The link at Microsoft is a good one, easy for anyone to understand, I should think.
My own experience was in software from 1972 to 1985, after which I was teaching at the local Community College (IT classes, yes). Hardware only really began to interest me after about 1989, when I began building an occasional PC for friends and family, beyond those I'd been building for myself.
My own experience was in software from 1972 to 1985, after which I was teaching at the local Community College (IT classes, yes). Hardware only really began to interest me after about 1989, when I began building an occasional PC for friends and family, beyond those I'd been building for myself.
#342
Posté 20 septembre 2010 - 06:53
Gaidheal wrote...
One a side note, the notion that "a 32 bit OS cannot use more than 4GiB of RAM" is bull****. Talk about the blind leading the blind. ;¬)
You are quite incorrect in making this statement. There are some OS's that use PAE, but not mainstream. And don't forget, the total amount of memory includes video memory.
#343
Posté 20 septembre 2010 - 09:07
I have played this game (Dragon Age: Origins) on two systems now, and both had problems. For what it's worth, here goes...
1st system was a custom-built AMD Athlon 64X2 (dual core), Nvidia Geforce 7950GT, 2GB of RAM, running WindowsXP Home Edition, and it lagged like mad not even after playing for 5 minutes. Lots of crashes to desktop, lockups, completely unplayable in my book. I finally gave up with only about 5% of the game complete. It just wasn't worth it.
2nd system, also custom-built, has an AMD Phenom II X6 (6 core) 1055T, Nvidia Geforce GTX 470, 4GB ram, running Windows 7 64bit Home Premium. It started off running DAO just fine, smooth as silk, never crashed, played perfectly, no errors, etc. THEN, I updated to the 1.04 patch and it started lagging like crazy, not as bad as on my first system, but it was really getting annoying. Had a handful of random crashes, but nothing too terrible that I couldn't keep playing. But it was really slow in some places, jerky gameplay made it hard to tell what was going on, load times really increased (guessing about a 25% increase in load times), and just trying to open up a menu (hitting esc, or trying to open up the character info screens, or spells and talents lists) took several, several, loooong seconds.
Then I saw someone's post on forcing the game to use DirectX 9 (with the -dx9 switch after the shortcut's command line) and all that went away!! It's playing like it did before, even after hours and hours of gameplay. Whatever "leak" there was, seemed to be fixed by a DX9 switch. Makes me think it's not memory related, but something else.
1st system was a custom-built AMD Athlon 64X2 (dual core), Nvidia Geforce 7950GT, 2GB of RAM, running WindowsXP Home Edition, and it lagged like mad not even after playing for 5 minutes. Lots of crashes to desktop, lockups, completely unplayable in my book. I finally gave up with only about 5% of the game complete. It just wasn't worth it.
2nd system, also custom-built, has an AMD Phenom II X6 (6 core) 1055T, Nvidia Geforce GTX 470, 4GB ram, running Windows 7 64bit Home Premium. It started off running DAO just fine, smooth as silk, never crashed, played perfectly, no errors, etc. THEN, I updated to the 1.04 patch and it started lagging like crazy, not as bad as on my first system, but it was really getting annoying. Had a handful of random crashes, but nothing too terrible that I couldn't keep playing. But it was really slow in some places, jerky gameplay made it hard to tell what was going on, load times really increased (guessing about a 25% increase in load times), and just trying to open up a menu (hitting esc, or trying to open up the character info screens, or spells and talents lists) took several, several, loooong seconds.
Then I saw someone's post on forcing the game to use DirectX 9 (with the -dx9 switch after the shortcut's command line) and all that went away!! It's playing like it did before, even after hours and hours of gameplay. Whatever "leak" there was, seemed to be fixed by a DX9 switch. Makes me think it's not memory related, but something else.
#344
Posté 21 septembre 2010 - 02:02
LOL
Guys, I hope you don't make your living on OS and system programming! If you want to go into it in depth Raymond Chen did several articles tackling the memory system in 32 bit Windows in quite some detail and clearing up the myth and confusions. The short version, which you ought to know if you think about it, is that virtual memory isn't the same as physical memory. Windows does confuse people by the way it reports memory, mind you, even ignoring the error (but industry standard, it's true) with using SI unit prefixes to mean what we now call 'binary prefixes' (x1024 vs x1000) but all it ever gives to a thread are virtual addresses which could map to a page it has swapped out to drive or right into real memory. Windows doesn't handle your hardware, you could have a terabyte there and so long as Windows has the drivers for your CPU & chipset combo (supporting this huge wad) it'd merrily handle that fine (I wouldn't want the job of writing PAE+++, though!).
Gorath - link is very easy to understand... you imply that you didn't quite understand it though; XP's virtual memory system uses a 32 bit address word but that's unrelated to support for more than 4 GiB in the way you seem to think.
PAE, by the way, is used by just about EVERY XP installation, it's routinely turned on at install time and has been for a long time now. People (like myself) running XP32 are using PAE whether they realize this or not, unless they have not updated Windows in years or have very, very old hardware. Any current generation CPU and those going back several generations, uses PAE since they have more address lines than could be handled without it. It is specifically a 32 bit OS extension, too, and as mainstream as it gets; no 64 bit OS has it since they use a full 64 bit address word and thus don't need it.
CrustyCat - Nope, I am completely correct, as I always am when I make such statements since I don't guess at it. ;¬) To quote you: You are quite incorrect in making that statement. In fact, it is worse, video memory isn't at all included in the memory total; what does happen, however, is that there is a window of addresses assigned to the video card (and it's not related directly to the total VRAM either, it's just an address window - address space is not the same as physical {bus} addresses).
Baramon - your issues were certainly not a memory leak, no. As regards the DX9 thing, on XP you only had DX9 so that would seem to undermine the idea that it was directly related to D3D mode, too. It sounds like you were running into some sort of performance bottleneck and that could be down so many things I am not even going to pretend to be able to e-diagnose it. :¬)
Guys, I hope you don't make your living on OS and system programming! If you want to go into it in depth Raymond Chen did several articles tackling the memory system in 32 bit Windows in quite some detail and clearing up the myth and confusions. The short version, which you ought to know if you think about it, is that virtual memory isn't the same as physical memory. Windows does confuse people by the way it reports memory, mind you, even ignoring the error (but industry standard, it's true) with using SI unit prefixes to mean what we now call 'binary prefixes' (x1024 vs x1000) but all it ever gives to a thread are virtual addresses which could map to a page it has swapped out to drive or right into real memory. Windows doesn't handle your hardware, you could have a terabyte there and so long as Windows has the drivers for your CPU & chipset combo (supporting this huge wad) it'd merrily handle that fine (I wouldn't want the job of writing PAE+++, though!).
Gorath - link is very easy to understand... you imply that you didn't quite understand it though; XP's virtual memory system uses a 32 bit address word but that's unrelated to support for more than 4 GiB in the way you seem to think.
PAE, by the way, is used by just about EVERY XP installation, it's routinely turned on at install time and has been for a long time now. People (like myself) running XP32 are using PAE whether they realize this or not, unless they have not updated Windows in years or have very, very old hardware. Any current generation CPU and those going back several generations, uses PAE since they have more address lines than could be handled without it. It is specifically a 32 bit OS extension, too, and as mainstream as it gets; no 64 bit OS has it since they use a full 64 bit address word and thus don't need it.
CrustyCat - Nope, I am completely correct, as I always am when I make such statements since I don't guess at it. ;¬) To quote you: You are quite incorrect in making that statement. In fact, it is worse, video memory isn't at all included in the memory total; what does happen, however, is that there is a window of addresses assigned to the video card (and it's not related directly to the total VRAM either, it's just an address window - address space is not the same as physical {bus} addresses).
Baramon - your issues were certainly not a memory leak, no. As regards the DX9 thing, on XP you only had DX9 so that would seem to undermine the idea that it was directly related to D3D mode, too. It sounds like you were running into some sort of performance bottleneck and that could be down so many things I am not even going to pretend to be able to e-diagnose it. :¬)
#345
Posté 21 septembre 2010 - 02:23
To clarify and aid others, rather than just point out why I'm correct, I offer the following:
In Windows XP (32 bit) when you use the properties tab on 'My Computer' to look at memory, the figure you see, if you have more than 4 GiB of RAM is the total available virtual address range (which is indeed a maximum of 4 GiB - 2^32 addresses) *minus* address windows which have been carved out for bus devices; such devices include your video hardware and sound cards as well as a longish list of 'legacy' ports and devices and system hardware. This is why it is often something like three and a half gigabytes but varies from system to system, according to what exactly is fitted. The confusion arose because for some unknown reason Windows will never report a value larger than the installed RAM even though its address range has been 4 GiB on 32 bit versions for a very long time. This meant that with 2 GiB of RAM installed you would see XP report '2048 MB' (the full total because it can 'carve' a full 2 GiB of addresses out of its 4 GiB range without conflicting with the ports assigned to bus devices) which is, of course, the same as the total physical RAM installed but with 4 GiB installed you would see less than that reported as described above. Various MS engineers have gone on record admitting that this behaviour is silly and misleading and several explanations for why have been advanced but the bottom line is that this figure IS NOT related directly to installed and available RAM and in point of fact 32 bit XP will use at upto at least 16 GiB and significantly more in most cases (it varies by version).
The video port address range, which leads to the notion that "Windows will use even less of your RAM if you have a good video card" idea is as follows:
The address range assigned to modern video cards can be quite large, though it varies by model, and for a time it was often pretty close to the total VRAM on the card. However, it is not directly related and Windows doesn't 'map' your VRAM into its virtual address space in a 1:1 ratio. Your cards drivers will, however, use a 'window' (port actually) to talk to the VRAM on the card and possibly other onboard (the video board) hardware.
In Windows XP (32 bit) when you use the properties tab on 'My Computer' to look at memory, the figure you see, if you have more than 4 GiB of RAM is the total available virtual address range (which is indeed a maximum of 4 GiB - 2^32 addresses) *minus* address windows which have been carved out for bus devices; such devices include your video hardware and sound cards as well as a longish list of 'legacy' ports and devices and system hardware. This is why it is often something like three and a half gigabytes but varies from system to system, according to what exactly is fitted. The confusion arose because for some unknown reason Windows will never report a value larger than the installed RAM even though its address range has been 4 GiB on 32 bit versions for a very long time. This meant that with 2 GiB of RAM installed you would see XP report '2048 MB' (the full total because it can 'carve' a full 2 GiB of addresses out of its 4 GiB range without conflicting with the ports assigned to bus devices) which is, of course, the same as the total physical RAM installed but with 4 GiB installed you would see less than that reported as described above. Various MS engineers have gone on record admitting that this behaviour is silly and misleading and several explanations for why have been advanced but the bottom line is that this figure IS NOT related directly to installed and available RAM and in point of fact 32 bit XP will use at upto at least 16 GiB and significantly more in most cases (it varies by version).
The video port address range, which leads to the notion that "Windows will use even less of your RAM if you have a good video card" idea is as follows:
The address range assigned to modern video cards can be quite large, though it varies by model, and for a time it was often pretty close to the total VRAM on the card. However, it is not directly related and Windows doesn't 'map' your VRAM into its virtual address space in a 1:1 ratio. Your cards drivers will, however, use a 'window' (port actually) to talk to the VRAM on the card and possibly other onboard (the video board) hardware.
#346
Posté 21 septembre 2010 - 03:00
Actually, I'll recant on one point, since the current page detailing physical RAM limits for Windows versions shows that there are limits as low 4 GiB, but note that this is a Microsoft imposed licensing limit not an inability of the XP codebase to handle greater than that, as shown by large variation, up to 128 GiB for example, within the 32 bit NT line.
I was fairly sure that MS had licensed 'vanilla' XP Pro for more than that but ten seconds of Googling didn't turn up the old table I remember, so no matter. ;¬)
I was fairly sure that MS had licensed 'vanilla' XP Pro for more than that but ten seconds of Googling didn't turn up the old table I remember, so no matter. ;¬)
#347
Posté 21 septembre 2010 - 10:07
Would increasing the amount of RAM ( Random access Memory) in our computers fix the problem or will it only make it worse
#348
Posté 21 septembre 2010 - 07:24
Here's an example for vista.
Various devices in a typical computer require memory-mapped access. This
is known as memory-mapped I/O (MMIO). For the MMIO space to be
available to 32-bit operating systems, the MMIO space must reside within
the first 4 GB of address space.
For example, if you have a
video card that has 256 MB of onboard memory, that memory must be mapped
within the first 4 GB of address space. If 4 GB of system memory is
already installed, part of that address space must be reserved by the
graphics memory mapping. Graphics memory mapping overwrites a part of
the system memory. These conditions reduce the total amount of system
memory that is available to the operating system.
The reduction in available system memory depends on the devices
that are installed in the computer. However, to avoid potential driver
compatibility issues, the 32-bit versions of Windows Vista limit the
total available memory to 3.12 GB.
If a computer has many installed devices, the available memory
may be reduced to 3 GB or less. However, the maximum memory available in
32-bit versions of Windows Vista is typically 3.12 GBPAE-mode-induced driver compatibility issues
Driver compatibility issues that are related to Data Execution
Prevention (DEP) are typically physical address extension (PAE)
mode-induced compatibility issues.
Note PAE is required only on computers that have processors that support hardware-enforced DEP.
DEP
may cause compatibility issues with any driver that performs code
generation or that uses other techniques to generate executable code in
real time. Many drivers that experienced these issues have been fixed.
Because DEP is always on for drivers that are on 64-bit versions of
Windows, these drivers typically experienced compatibility issues.
However, there is no guarantee that all drivers have been updated to fix
PAE-mode-induced compatibility issues. However, there are few drivers
that use these techniques. DEP alone does not typically cause driver
compatibility issues.
The primary driver compatibility issues
that you may experience occur when you run PAE mode on 32-bit computers.
PAE mode enables processors to use more than 4 GB of memory. The
primary difference between PAE memory paging schemes and non-PAE memory
paging schemes is the additional level of paging that is required in PAE
mode. PAE mode requires three levels of paging instead of two levels of
paging.
Some drivers might not load if PAE mode is enabled
because the device might be unable to perform 64-bit addressing. Or, the
drivers might be written with the assumption that PAE mode requires
more than 4 GB of memory. Such drivers are written with the expectation
that the drivers will always receive 64-bit addresses in PAE mode and
that the driver or the device cannot interpret the address.
Other
drivers might load in PAE mode but cause system instability by directly
modifying system page table entries (PTE). These drivers expect 32-bit
page table entries but receive 64-bit PTEs in PAE mode instead.
The
most common PAE compatibility issue for drivers involves direct memory
access (DMA) transfers and map register allocation. Many devices that
support DMA, typically 32-bit adapters, cannot perform 64-bit physical
addressing. When these devices run in 32-bit mode, the devices can
address all physical address space. In PAE mode, data can be present at a
physical address that is larger than 4 GB. To enable devices that have
these constraints to function in this scenario, Microsoft Windows 2000
Server and later versions of Windows provide double-buffering for the
DMA transaction. Windows 2000 Server and later versions of Windows do
this by providing a 32-bit address that is indicated by a map register.
The device can perform the DMA transaction to the 32-bit address. The
kernel copies the memory to the 64-bit address that is provided to the
driver. When the computer runs with PAE mode disabled, drivers for
32-bit devices do not require that system memory be allocated to their
map registers. This means that double-buffering is not required because
all devices and all drivers are contained within the 32-bit address
space. Tests of drivers for 32-bit devices on 64-bit processor–based
computers have demonstrated that DMA-capable drivers that are client
tested typically expect unlimited map registers.
So, after all this, it doesn't really matter. Who cares. 32-bit OS - 4GB 64-bit OS - Lot's More.
Crusty
Various devices in a typical computer require memory-mapped access. This
is known as memory-mapped I/O (MMIO). For the MMIO space to be
available to 32-bit operating systems, the MMIO space must reside within
the first 4 GB of address space.
For example, if you have a
video card that has 256 MB of onboard memory, that memory must be mapped
within the first 4 GB of address space. If 4 GB of system memory is
already installed, part of that address space must be reserved by the
graphics memory mapping. Graphics memory mapping overwrites a part of
the system memory. These conditions reduce the total amount of system
memory that is available to the operating system.
The reduction in available system memory depends on the devices
that are installed in the computer. However, to avoid potential driver
compatibility issues, the 32-bit versions of Windows Vista limit the
total available memory to 3.12 GB.
If a computer has many installed devices, the available memory
may be reduced to 3 GB or less. However, the maximum memory available in
32-bit versions of Windows Vista is typically 3.12 GBPAE-mode-induced driver compatibility issues
Driver compatibility issues that are related to Data Execution
Prevention (DEP) are typically physical address extension (PAE)
mode-induced compatibility issues.
Note PAE is required only on computers that have processors that support hardware-enforced DEP.
DEP
may cause compatibility issues with any driver that performs code
generation or that uses other techniques to generate executable code in
real time. Many drivers that experienced these issues have been fixed.
Because DEP is always on for drivers that are on 64-bit versions of
Windows, these drivers typically experienced compatibility issues.
However, there is no guarantee that all drivers have been updated to fix
PAE-mode-induced compatibility issues. However, there are few drivers
that use these techniques. DEP alone does not typically cause driver
compatibility issues.
The primary driver compatibility issues
that you may experience occur when you run PAE mode on 32-bit computers.
PAE mode enables processors to use more than 4 GB of memory. The
primary difference between PAE memory paging schemes and non-PAE memory
paging schemes is the additional level of paging that is required in PAE
mode. PAE mode requires three levels of paging instead of two levels of
paging.
Some drivers might not load if PAE mode is enabled
because the device might be unable to perform 64-bit addressing. Or, the
drivers might be written with the assumption that PAE mode requires
more than 4 GB of memory. Such drivers are written with the expectation
that the drivers will always receive 64-bit addresses in PAE mode and
that the driver or the device cannot interpret the address.
Other
drivers might load in PAE mode but cause system instability by directly
modifying system page table entries (PTE). These drivers expect 32-bit
page table entries but receive 64-bit PTEs in PAE mode instead.
The
most common PAE compatibility issue for drivers involves direct memory
access (DMA) transfers and map register allocation. Many devices that
support DMA, typically 32-bit adapters, cannot perform 64-bit physical
addressing. When these devices run in 32-bit mode, the devices can
address all physical address space. In PAE mode, data can be present at a
physical address that is larger than 4 GB. To enable devices that have
these constraints to function in this scenario, Microsoft Windows 2000
Server and later versions of Windows provide double-buffering for the
DMA transaction. Windows 2000 Server and later versions of Windows do
this by providing a 32-bit address that is indicated by a map register.
The device can perform the DMA transaction to the 32-bit address. The
kernel copies the memory to the 64-bit address that is provided to the
driver. When the computer runs with PAE mode disabled, drivers for
32-bit devices do not require that system memory be allocated to their
map registers. This means that double-buffering is not required because
all devices and all drivers are contained within the 32-bit address
space. Tests of drivers for 32-bit devices on 64-bit processor–based
computers have demonstrated that DMA-capable drivers that are client
tested typically expect unlimited map registers.
So, after all this, it doesn't really matter. Who cares. 32-bit OS - 4GB 64-bit OS - Lot's More.
Crusty
#349
Posté 21 septembre 2010 - 08:45
Crusty - that's almost correct but misleading in a couple of places, probably because whoever wrote it isn't clear on the distinction between Windows' address range (max of 4 GiB, with a 32 bit pointer) and the amount of physical memory that a given version will address (limited by licensing, in Vista these values actually reside in the registry and can be changed if you know what you are doing, since they all use the same kernel build). It also implies that if you have, say, 256 MiB of VRAM on your video card that is all mapped 1:1 into this address range, which is not correct either. I'll accept your post as a grudging "You're right and I will be more careful in future about making definitive statements in areas I lack expertise." *grin*
In practical terms, though, it amounts to a similar thing - Microsoft restrict usable physical memory in their 32 bit OS builds such that it does make sense for people to migrate to a 64 bit version if they have a PC with more than 4 GiB. What isn't true but which Microsoft are recalcitrant about correcting is the perception that this is an inherent architectural limit imposed by using a 32 word. Even with the limit so imposed, Windows will use the full 4 GiB.
To answer the other poster - more memory installed (assuming your OS can address it, as discussed above) will mask the problem more effectively, if it is in fact a leak, as it will allow it to run longer before encountering problems. It won't fix it though - as the name implies, a leak is a constant 'drip' of memory which is not being released back to the OS even as the program keeps claiming memory in other parts of its task.
In practical terms, though, it amounts to a similar thing - Microsoft restrict usable physical memory in their 32 bit OS builds such that it does make sense for people to migrate to a 64 bit version if they have a PC with more than 4 GiB. What isn't true but which Microsoft are recalcitrant about correcting is the perception that this is an inherent architectural limit imposed by using a 32 word. Even with the limit so imposed, Windows will use the full 4 GiB.
To answer the other poster - more memory installed (assuming your OS can address it, as discussed above) will mask the problem more effectively, if it is in fact a leak, as it will allow it to run longer before encountering problems. It won't fix it though - as the name implies, a leak is a constant 'drip' of memory which is not being released back to the OS even as the program keeps claiming memory in other parts of its task.
#350
Posté 21 septembre 2010 - 08:49
P.S. The DEP and PAE stuff is flat out wrong and the driver claims are spurious and theoretical at best, Microsoft caused more driver access problems with their deliberate alteration of the kernel (SP2) than would ever have arisen had they not sought to force migration to 64 bit with the artificially imposed limit on physical memory.





Retour en haut





