52
Yeah, Vista-32 on my laptop with 4GB RAM shows 3.5GB RAM installed. I have an 8600M with a 256 MB framebuffer so all PCIE devices including it fit in that 0.5GB. I use Linux-32 as my primary desktop though, which I think uses HIGHMEM to access memory above 896MB (more knowledgeable kernel hackers correct me if I'm wrong), which isn't too efficient. One of these days I'll install a 64-bit OS, I keep telling myself.
Nope. GPUs stopped mapping the entire video memory into physical memory a long time ago as their video memories increased (except Intel GPUs, maybe, since they still have little). Should be a lot less than 1GB per GPU now IMO. They use hw magic to make the entire memory accessible.
No, Windows can only access 3.5GB of system memory, the remaining 0.5GB will be mapped above 4GB in the physical address space. When you have lots of PCI devices in the system, they take up some space in the physical address space. So if your PCI(E) devices take up 1GB of space, the BIOS will fit less of that 4GB of RAM into the 4GB physcial address space. Your PCI devices would would already be allocating BARs like I said earlier. Like AC said, you can enable PAE to reclaim some of that lost space. I know there is a flag in XP (Run:msconfig, Advanced:) to enable PAE, but I don't know if that has any effect.
No graphics card maps the entire framebuffer into the physical address space, even on 64-bit OSs. I'll just use up a few 10s of MBs for BAR0, a few more for BAR1, and so on. The driver will manage all the framebuffer memory for you, all the client has to do is call the equivalent of malloc().
For those who've no time or inclination to read the article:
1) The attacker should first modify system MTRR
register(s) in order to mark the region of system
memory where the SMRAM is located as
cacheable with type Write-Back (WB).
2) Attacker now generates write accesses to
physical addresses corresponding to locations
where the SMRAM is located.
3) Finally attacker needs to trigger an SMI, which
will transfer execution to the SMM code. The CPU
will start executing the SMM code, but will be
fetching the instructions from the cache first.
I hate to say it because they do good work, but I think nVidia is ultimately doomed as it is today. Everyone rips Intel's integrated 3d graphics but they just keep getting better every year.
And nVidia's graphics aren't getting any better? A GPU and a CPU stuffed together into the same chip will always be a low-cost/low-power/low-end solution, can never come close to the capability of a GPU that has the whole die to itself. If Intel/AMD has ~2B transistors in a chip that are divided between a general-purpose CPU and a GPU, can that ever match a 2B transistor discrete GPU + a discrete CPU? Unlikely. Plus, CUDA has put forth interesting possibilities for putting the GPU to other uses.
Although AMD should have bought nVidia instead of ATI, they do own ATI, and so have a pretty good graphics system on their own.
And they should have taken nVidia down with them, instead of ATI, like their doing now. They did nVidia a favour by going for ATI instead.
Eventually, both AMD and Intel are going to wind up with 3d calculations on the die in some fashion, and that's going to leave nVidia for what?
See above. Keyword: Discrete GPUs.
"It may be that our role on this planet is not to worship God but to create him." -Arthur C. Clarke
