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

Discussion in 'Abit' started by pigdos, Feb 15, 2006.

  1. pigdos

    pigdos Guest

    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
    pigdos, Feb 15, 2006
    #1
    1. Advertising

  2. pigdos

    - HAL9000 Guest

    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?)?
    - HAL9000, Feb 15, 2006
    #2
    1. Advertising

  3. pigdos

    pigdos Guest

    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, Feb 15, 2006
    #3
  4. pigdos

    Rennie Guest

    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
    Rennie, Feb 16, 2006
    #4
  5. pigdos

    Paul Guest

    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?)?
    Paul, Feb 16, 2006
    #5
  6. pigdos

    - HAL9000 Guest

    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?
    - HAL9000, Feb 16, 2006
    #6
  7. pigdos

    pigdos Guest

    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?

    >
    >
    pigdos, Feb 17, 2006
    #7
  8. pigdos

    - HAL9000 Guest

    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...
    - HAL9000, Feb 17, 2006
    #8
  9. pigdos

    pigdos Guest

    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...

    >
    >
    pigdos, Feb 18, 2006
    #9
  10. pigdos

    - HAL9000 Guest

    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.
    - HAL9000, Feb 18, 2006
    #10
  11. pigdos

    pigdos Guest

    The 8237 could handle 8-bit DMA, what I meant by this is that the 8237a
    could only read/write 8-bits at a time. The DMA controller takes over the
    memory bus when used. The one other use I remember for DMA was for ISA sound
    cards.

    Unless the athlon64's have memory controllers with built-in support for AGP
    or DMA(which I doubt) I don't think they would be as efficient as a north
    bridge memory controller for handling DMA or AGP read/write requests. If the
    north bridge isn't connected to system memory (which must be highly
    unlikely) then we introduce more propagation delays for the flow of data.
    Why? Because we have more devices through which data must flow. The AGP
    video card's request for AGP memory data starts off w/a address operation on
    the AGP bus. If the north bridge is the memory controller then that's where
    it ends. But in an Athlon 64 the north bridge must generate ANOTHER address
    request to the memory controller on the A64. What could be make this
    scenario worse is if the video card AGP address request results in a TLB
    miss for the north bridge then we have to generate two address requests to
    the A64 memory controller. Furthermore, if the north bridge is not attached
    to system memory (which I doubt) every byte read in an AGP memory access or
    in a DMA access must first be read by the on-board memory controller of the
    A64 and then forwarded to the north bridge. I guess you're right though the
    CPU still doesn't have to get directly involved.

    >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 isIf this
    > is true then the CPU is basically bottlenecked for the duration of this
    > event. Super scalar or not, the CPU can't be reading and forwarding mass
    > quantities of AGP data and still be
    > dma'ing to memory.
    >
    > The miracle of dma is that the cpu doesn't get involved.


    --
    Doug
    pigdos, Feb 18, 2006
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Doug
    Replies:
    11
    Views:
    468
  2. Simon
    Replies:
    0
    Views:
    670
    Simon
    Jun 15, 2004
  3. Jason Stacy
    Replies:
    0
    Views:
    516
    Jason Stacy
    Jan 6, 2007
  4. Jeff Sumner

    Faster Ram=Faster Powerbook?

    Jeff Sumner, Dec 22, 2004, in forum: Apple
    Replies:
    1
    Views:
    303
    Don Bruder
    Dec 22, 2004
  5. Replies:
    19
    Views:
    571
    Mark Borgerson
    Nov 28, 2011
Loading...

Share This Page