Gene said:
For you and Paul: I should add that the CPU is an Intel Core i5 2500 on
an ASUS P8H67-M EVO motherboard (a home-built computer).
The i5 series has built-in graphics, called Intel HD Graphics 1000
(GT1), and the MB chipset supports it.
The Intel Graphics control, the Resource Monitor, and CPU-Z aren't
helping me much, when it comes to seeing specifically what my graphics
system is using. My lack of knowledge comes into play as well
IIRC, Intel offers information on line, so maybe later I'll see what
they say (and what I forgot!). Or Google or Wikipedia...
But I just thought of System Information.
It says
Installed Physical Memory (RAM) 4.00 GB
Total Physical Memory 3.91 GB
Available Physical Memory 1.96 GB
That doesn't help me a lot.
On the memory panel it shows these addresses related to graphics:
0xFE000000-0xFE3FFFFF Intel(R) HD Graphics Family OK
0xC0000000-0xCFFFFFFF Intel(R) HD Graphics Family OK
0xA0000-0xBFFFF Intel(R) HD Graphics Family OK
as well as 28 other blocks of memory, mostly above 0xFE000000, but I'm
too lazy to calculate all of the allocations to see how much it is.
The second video allocation seems to be about 268MB, if I didn't
miscount the F's. The other two are small(ish); to me the last one looks
like the old VGA allocation.
Under Display, I see this:
Adapter RAM 1.77 GB (1,897,897,984 bytes)
I hope this is more meaningful to you two than it seems to be to me
Using the P8H67-M EVO manual:
http://dlcdnet.asus.com/pub/ASUS/mb/LGA1155/P8H67-M_EVO/e5955_P8H67_M_EVO.zip
I can see (PDF page 78 or so)
iGPU Memory [32M, 64M, 96M, 128M]
"... allocate a fixed amount of system memory"
So that is UMA type, as far as I know. You might be able to
display that in GPUZ. Maybe it can list the static allocation
of your HD 2000 graphics ?
http://www.techpowerup.com/downloads/SysInfo/GPU-Z/
TechPowerUp GPU-Z v0.5.4 Jun 29, 2011
Now your
"Total Physical Memory 3.91 GB"
could mean you're using the default of [64M], and if the 64M
wasn't in usage, your physical memory would be listed as 3.97GB or so.
*******
Intel offers this.
http://www.intel.com/support/graphics/sb/CS-029090.htm
It has some ways of displaying graphics memory usage.
Their screenshot example here shows three parameters.
http://www.intel.com/support/graphics/sb/img/graphicsdriversizeat75pct1.jpg
Minimum Graphics memory 32M
Maximum Graphics memory 729M
Graphics Memory in Use 103M
So if you use one of their tools, you may get a better
idea of the static BIOS allocation and the range of
dynamic allocations allowed.
*******
On my laptop, the sideport (local) memory seems to be 256MB.
Hardware reserved is about 262MB, which I can't make sense out of.
(Since there shouldn't be any other losses on this laptop. The
sideport should be doing the job. I don't see a good reason
for the sideport to be "backed" by UMA or anything.)
System Info reports
Installed 3.00GB
Total Physical 2.74GB (more or less consistent with the Hardware Reserved loss)
Available Physical 1.66GB (kinda useless info, how much is currently left)
Task Manager shows a graph indicating 1.02GB of memory is "in use",
which accounts roughly for the difference between 2.74 and 1.66GB
Resmon's colored blocks show
Hardware Reserved 262MB
In Use 1001MB
Modified 63MB
Standby 1257MB
Free 489MB
(Total 3072MB)
Available in the Resmon window is listed as 1746MB.
(The numbers will be changing, as I'm taking screen
snapshots and the like.)
For whatever reasons, my graphics have a 256MB sideport,
and *something* is stealing 262MB total, which is pretty
suspicious. You would think my laptop would have a
"static + dynamic" capability, and Wikipedia lists that
for HD 4250 as
http://en.wikipedia.org/wiki/Comparison_of_AMD_graphics_processing_units
Up to 512 system + optional 128 sideport
It could be that 128MB was the largest chip available when
the article was written.
The 262MB hardware reserved shouldn't really be there.
It can't be an address space penalty, because the laptop
runs the 64 bit version of Windows 7.
*******
Anyway, perhaps the Intel methods will shine a bit more
light on your static + dynamic graphics allocations.
Paul