AGP memory: faster/better on Athlon 64 based systems?

Since some Athlon 64 systems have 128-bit memory interfaces wouldn't AGP
memory be much more viable on these platforms? I'm assuming that AGP video
cards can make use of this wider memory interface.

One more question. On my Nf7s v2.0, Sisoft reports a memory bandwidth of
roughly 3048 MB/sec (average of the two figures), while
memtest reports something like 1384 MB/sec. Why is there such a huge
discrepancy in figures?

Last question: does PCIe feature some equivalent for AGP memory (DIME?)?
--
Doug

If you look at a 64 bit Athlon mother board you'll notice that there
are many traces running directly between the cpu and the memory
sockets. LOL, going through a north-bridge was a silly waste of time
(old designs) and now the cpu designers are doing it the best
(fastest) way possible - a direct connection. So ... going through
"AGP", like going through a north-bridge chip, is slower. The memory
controller is integrated with the cpu.

On your second question, it's much easier to make a test that is good
for making a "relative" bandwidth comparison test than an "absolute"
bandwidth determining test. Perhaps memtest is a relative test?

Forrest

Motherboard Help By HAL web site:
http://home.comcast.net/~mobo.help/


On Wed, 15 Feb 2006 00:02:32 GMT, "pigdos" <> wrote:

>Since some Athlon 64 systems have 128-bit memory interfaces wouldn't AGP
>memory be much more viable on these platforms? I'm assuming that AGP video
>cards can make use of this wider memory interface.
>
>One more question. On my Nf7s v2.0, Sisoft reports a memory bandwidth of
>roughly 3048 MB/sec (average of the two figures), while
>memtest reports something like 1384 MB/sec. Why is there such a huge
>discrepancy in figures?
>
>Last question: does PCIe feature some equivalent for AGP memory (DIME?)?

So AGP video cards on A64-based systems can make use of the 128-bit wide
memory interface?

--
Doug
"- HAL9000" <> wrote in message
news:...
> If you look at a 64 bit Athlon mother board you'll notice that there
> are many traces running directly between the cpu and the memory
> sockets. LOL, going through a north-bridge was a silly waste of time
> (old designs) and now the cpu designers are doing it the best
> (fastest) way possible - a direct connection. So ... going through
> "AGP", like going through a north-bridge chip, is slower. The memory
> controller is integrated with the cpu.
>
> On your second question, it's much easier to make a test that is good
> for making a "relative" bandwidth comparison test than an "absolute"
> bandwidth determining test. Perhaps memtest is a relative test?
>
> Forrest
>
> Motherboard Help By HAL web site:
> http://home.comcast.net/~mobo.help/
>
>
> On Wed, 15 Feb 2006 00:02:32 GMT, "pigdos" <> wrote:
>
>>Since some Athlon 64 systems have 128-bit memory interfaces wouldn't AGP
>>memory be much more viable on these platforms? I'm assuming that AGP video
>>cards can make use of this wider memory interface.
>>
>>One more question. On my Nf7s v2.0, Sisoft reports a memory bandwidth of
>>roughly 3048 MB/sec (average of the two figures), while
>>memtest reports something like 1384 MB/sec. Why is there such a huge
>>discrepancy in figures?
>>
>>Last question: does PCIe feature some equivalent for AGP memory (DIME?)?
>
>

pigdos schrieb:
> So AGP video cards on A64-based systems can make use of the 128-bit wide
> memory interface?
>
They probably can, but there is no need to do so, if you use an AGP card
with large ram onboard ( >128 MB for gaming). In such a case the memory
sharing feature of AGP is never used. For office and internet use only,
it would not make any sense to have a look at speed and bandwidth.
Rennie

In article <>, - HAL9000
<> wrote:

> If you look at a 64 bit Athlon mother board you'll notice that there
> are many traces running directly between the cpu and the memory
> sockets. LOL, going through a north-bridge was a silly waste of time
> (old designs) and now the cpu designers are doing it the best
> (fastest) way possible - a direct connection. So ... going through
> "AGP", like going through a north-bridge chip, is slower. The memory
> controller is integrated with the cpu.
>
> On your second question, it's much easier to make a test that is good
> for making a "relative" bandwidth comparison test than an "absolute"
> bandwidth determining test. Perhaps memtest is a relative test?
>
> Forrest
>
> Motherboard Help By HAL web site:
> http://home.comcast.net/~mobo.help/

Source is available for memtest86, if you want to see how they
do the bandwidth calculation. This code is from init.c .

*******
/* Measure cache/memory speed by copying a block of memory. */
/* Returned value is kbytes/second */
static ulong memspeed(ulong src, ulong len, int iter)
{
ulong dst;
ulong wlen;
int i;

dst = src + len;
wlen = len / 4; /* Length is bytes */

/* Calibrate the overhead with a zero word copy */
asm __volatile__ ("rdtsc":"=a" (st_low),"=d" (st_high));
for (i=0; i<iter; i++) {
asm __volatile__ (
"movl %0,%%esi\n\t" \
"movl %1,%%edi\n\t" \
"movl %2,%%ecx\n\t" \
"cld\n\t" \
"rep\n\t" \
"movsl\n\t" \
:: "g" (src), "g" (dst), "g" (0)
: "esi", "edi", "ecx"
);
}
asm __volatile__ ("rdtsc":"=a" (cal_low),"=d" (cal_high));

/* Compute the overhead time */
asm __volatile__ (
"subl %2,%0\n\t"
"sbbl %3,%1"
:"=a" (cal_low), "=d" (cal_high)
:"g" (st_low), "g" (st_high),
"0" (cal_low), "1" (cal_high)
);

/* Do the first copy to prime the cache */
asm __volatile__ (
"movl %0,%%esi\n\t" \
"movl %1,%%edi\n\t" \
"movl %2,%%ecx\n\t" \
"cld\n\t" \
"rep\n\t" \
"movsl\n\t" \
:: "g" (src), "g" (dst), "g" (wlen)
: "esi", "edi", "ecx"
);

/* Now measure the speed */
asm __volatile__ ("rdtsc":"=a" (st_low),"=d" (st_high));
for (i=0; i<iter; i++) {
asm __volatile__ (
"movl %0,%%esi\n\t" \
"movl %1,%%edi\n\t" \
"movl %2,%%ecx\n\t" \
"cld\n\t" \
"rep\n\t" \
"movsl\n\t" \
:: "g" (src), "g" (dst), "g" (wlen)
: "esi", "edi", "ecx"
);
}
asm __volatile__ ("rdtsc":"=a" (end_low),"=d" (end_high));

/* Compute the elapsed time */
asm __volatile__ (
"subl %2,%0\n\t"
"sbbl %3,%1"
:"=a" (end_low), "=d" (end_high)
:"g" (st_low), "g" (st_high),
"0" (end_low), "1" (end_high)
);
/* Subtract the overhead time */
asm __volatile__ (
"subl %2,%0\n\t"
"sbbl %3,%1"
:"=a" (end_low), "=d" (end_high)
:"g" (cal_low), "g" (cal_high),
"0" (end_low), "1" (end_high)
);

/* Make sure that the result fits in 32 bits */
if (end_high) {
return(0);
}

/* Since a copy does both a read & write we need to adjuect the time */
end_low /= 2;

/* Convert to clocks/KB */
end_low /= len;
end_low *= 1024;
end_low /= iter;
if (end_low == 0) {
return(0);
}

/* Convert to kbytes/sec */
return((v->clks_msec)/end_low);
}
*******

HTH,
Paul

>
>
> On Wed, 15 Feb 2006 00:02:32 GMT, "pigdos" <> wrote:
>
> >Since some Athlon 64 systems have 128-bit memory interfaces wouldn't AGP
> >memory be much more viable on these platforms? I'm assuming that AGP video
> >cards can make use of this wider memory interface.
> >
> >One more question. On my Nf7s v2.0, Sisoft reports a memory bandwidth of
> >roughly 3048 MB/sec (average of the two figures), while
> >memtest reports something like 1384 MB/sec. Why is there such a huge
> >discrepancy in figures?
> >
> >Last question: does PCIe feature some equivalent for AGP memory (DIME?)?

I think what we have here is ... failure to communicate. Sorry, just
had to say that.

The (system) memory only interfaces with the cpu on a64 systems as I
explained. As to the data paths for the AGP bus - I really don't know
how they've changed as I haven't kept up with it. A quick search
shows this for a64 topology.

http://www.tomshardware.com/2004/05/05/via/page2.html

Looks like the north bridge has a special buffer (small devoted memory
segment) in it for agp data buffering / transfers between the video
card and the cpu. As far as "make use", one would need to know the
data transfer rates on the various buses - pertinent to the question.

For performance issues, one would normally talk about data "rates" as
opposed to bus widths, memory widths, or data widths. Since "wider"
doesn't necessarily mean higher performance, comparisons in terms of
data rates is more relevant.

Forrest

Motherboard Help By HAL web site:
http://home.comcast.net/~mobo.help/


On Wed, 15 Feb 2006 23:08:40 GMT, "pigdos" <> wrote:

>So AGP video cards on A64-based systems can make use of the 128-bit wide
>memory interface?

So, all AGP memory access has to go through the CPU? It sure looks that way
from your datapath diagram from tomshardware. That can't be a good thing...

--
Doug
"- HAL9000" <> wrote in message
news:...
>I think what we have here is ... failure to communicate. Sorry, just
> had to say that.
>
> The (system) memory only interfaces with the cpu on a64 systems as I
> explained. As to the data paths for the AGP bus - I really don't know
> how they've changed as I haven't kept up with it. A quick search
> shows this for a64 topology.
>
> http://www.tomshardware.com/2004/05/05/via/page2.html
>
> Looks like the north bridge has a special buffer (small devoted memory
> segment) in it for agp data buffering / transfers between the video
> card and the cpu. As far as "make use", one would need to know the
> data transfer rates on the various buses - pertinent to the question.
>
> For performance issues, one would normally talk about data "rates" as
> opposed to bus widths, memory widths, or data widths. Since "wider"
> doesn't necessarily mean higher performance, comparisons in terms of
> data rates is more relevant.
>
> Forrest
>
> Motherboard Help By HAL web site:
> http://home.comcast.net/~mobo.help/
>
>
> On Wed, 15 Feb 2006 23:08:40 GMT, "pigdos" <> wrote:
>
>>So AGP video cards on A64-based systems can make use of the 128-bit wide
>>memory interface?
>
>

Ahh, the miracle of DMA (direct memory access). Doesn't necessarily
have to be a bad thing. But, it is definitely a good thing for the
memory to be tied directly to the cpu - no doubt.

I try to think of the graphics card as more of an autonomous device.
That is, all the (video) resources needed for a game - reside on the
card. Testimony to this would be the general shift to graphics cards
with more and more memory onboard.

Forrest

Trivia: My recollection is that the 80386 was the first (desktop) cpu
with DMA integral to it. Anyone?

Motherboard Help By HAL web site:
http://home.comcast.net/~mobo.help/


On Fri, 17 Feb 2006 00:42:47 GMT, "pigdos" <> wrote:

>So, all AGP memory access has to go through the CPU? It sure looks that way
>from your datapath diagram from tomshardware. That can't be a good thing...

The original IBM XT had 8-bit DMA channels, but they weren't used for hard
drive access back then. The original IBM PC had 8-bit DMA channels as well.

It would be a bad thing if the CPU has to arbitrate memory requests for DMA
memory. In systems where the north bridge handles memory access the CPU
doesn't have to get directly involved w/AGP memory access. If the CPU does
have to get involved w/AGP memory access (DIME?) on A64 based systems that
would be a bad thing. Why? The CPU would have to stop whatever it's doing,
lookup the GART table to find the actual address of the data the video card
wants, generate that memory request and pass all that data to the video
card. While this is going on the CPU can do nothing else.

--
Doug
"- HAL9000" <> wrote in message
news:...
> Ahh, the miracle of DMA (direct memory access). Doesn't necessarily
> have to be a bad thing. But, it is definitely a good thing for the
> memory to be tied directly to the cpu - no doubt.
>
> I try to think of the graphics card as more of an autonomous device.
> That is, all the (video) resources needed for a game - reside on the
> card. Testimony to this would be the general shift to graphics cards
> with more and more memory onboard.
>
> Forrest
>
> Trivia: My recollection is that the 80386 was the first (desktop) cpu
> with DMA integral to it. Anyone?
>
> Motherboard Help By HAL web site:
> http://home.comcast.net/~mobo.help/
>
>
> On Fri, 17 Feb 2006 00:42:47 GMT, "pigdos" <> wrote:
>
>>So, all AGP memory access has to go through the CPU? It sure looks that
>>way
>>from your datapath diagram from tomshardware. That can't be a good
>>thing...
>
>

As I recall the 8086 memory management was on a separate chip. A
quick search shows that it's number was 8237 and was four channels.
You may be thinking of "8" interrupts. Also trying to recall again, I
think only one dma channel was used and it was for D ram refresh.

Later, the memory management function got moved to the "north-bridge".
I think for logic similar to what you describe, and, off load the
silicon on the cpu.

But like the entire north-bridge chip, the memory management function
is hardware based. Therefore the cpu doesn't (or shouldn't) get
involved. Being super scaler and such, the cpu should be happy doing
it's cached operations, if any, while the hard disk or whatever is
dma'ing to memory.

The miracle of dma is that the cpu doesn't get involved.

Forrest

Motherboard Help By HAL web site:
http://home.comcast.net/~mobo.help/


On Sat, 18 Feb 2006 05:32:15 GMT, "pigdos" <> wrote:

>The original IBM XT had 8-bit DMA channels, but they weren't used for hard
>drive access back then. The original IBM PC had 8-bit DMA channels as well.
>
>It would be a bad thing if the CPU has to arbitrate memory requests for DMA
>memory. In systems where the north bridge handles memory access the CPU
>doesn't have to get directly involved w/AGP memory access. If the CPU does
>have to get involved w/AGP memory access (DIME?) on A64 based systems that
>would be a bad thing. Why? The CPU would have to stop whatever it's doing,
>lookup the GART table to find the actual address of the data the video card
>wants, generate that memory request and pass all that data to the video
>card. While this is going on the CPU can do nothing else.