George, I don't think this guy actually understands the K8 system
architecture
DK

Mon, 20 Feb 2006 05:43:14 GMT, "pigdos" <NA@nowhere.comwrote:

>Are you sure about that? That would seem to me really inefficient and
>contribute to propagation delays. The north bridge (which still exists)
>would have to receive all the data and forward it to/from the A64 memory
>controller, PCI/PCIe/AGP buses rather than handling all this itself? For
>example, if we have an AGP access, say from the video card to system memory,
>the AGP bus would xfer it's address request to the North Bridge, the North
>Bridge would then have to forward this request to the A64 memory controller,
>which would then fetch the AGP memory data, send it back to the North Bridge
>and then the North Bridge sends it back to the video card. It would even be
>worse if we experience a TLB miss in the North Bridge because then we have
>to request the GART from the A64 memory controller. DMA access would
>similarly be degraded. No matter how fast the bus between the A64 memory
>controller and the North Bridge there would still be more latency than if
>the North Bridge could handle it itself.

There will be a (very) small latency hit on DMA and AGP memory data
accesses when compared to using an external memory controller.
However that is *WAY* more than offset by the (comparatively large)
decrease in latency on CPU memory requests.

The high-bandwidth/low-latency design of hypertransport, used to link
the I/ chips (call them a "north bridge" if you like, it's not
particularly accurate though) means that you're adding only a few
nanoseconds of latency to forward the request on, usually on the order
of 20-40ns (maybe even less). Remember that this link was designed
with this sort of forwarding of memory requests in mind since that's
exactly what it does in a multiprocessor setup when accessing remote
memory. If we compare this to some common sources of DMA access the
latency becomes pretty negligible. For example, hard drives have a
latency up in the millisecond range, so an extra 30 nanoseconds or so
is totally invisible. Same goes for network cards.

The only place where this really comes into affect is video cards, and
in particular, shared memory video cards. AGP/PCI-Express cards with
built-in memory don't really need to worry much about transferring
data to main memory on the fly since *MST* of the important data is
kept in local memory on the card itself. The difference in latency
and bandwidth between local memory and remote memory is HUGE, so an
extra 30ns of latency and virtually no hit to bandwidth doesn't end up
changing things much. When you're looking at "really slow" vs. "the
tiniest bit slower", usually you don't worry too much.

However with shared memory video, things get a bit trickier. Here
you're ALWAYS dealing with remote memory and you're always limited by
bandwidth and latency. However again this is a bit of a comparison
between "bad" and "just slightly worse", and the goal in designing
integrated video is ALWAYS to reduce the bandwidth needs and hide
latency, regardless of what platform you're using.

Tony Hill
hilla <underscore20 <atyahoo <dotca

pigdos wrote:

>Duh, I never said I did That's why I was asking a QUESTIN. Dumb****
*plonk*

In article <qHsKf.59293$PL5.35144@newssvr11.news.prodigy.com>,
pigdos <NA@nowhere.comtop-posted (grr):
>Duh, I never said I did That's why I was asking a QUESTIN. Dumb****

Yet another rude top-poster plonked into the killfile

_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( http://alfter.us/ Top-posting!
\_^_/ rm -rf /bin/laden >What's the most annoying thing on Usenet?

George Macdonald wrote:
[] I wish you'd learn to post properly to Usenet.
In other words, please don't top post, pigdos.
http://www.xs4all.nl/~

pigdos wrote:
"Properly," according to whom? I was using usenet before there were any such
standards. Show me convincing evidence as to WHY top-posting is so evil. Net
nazi. Where anywhere in the AGP 2.0 spec does it mention DMA mode? No where.
Neither do any chipset datasheets I have. Cite your source please.

Look. In c.s.i.p.h.c top posting is considered both rude/uncultured
and it's a very ineffective way to communicate (generally). If you can
see what people are responding to, it helps to understand. Newsgroups
generally have a high ratio of reads/writes, so try and respect the
reader.

Then I'll be more specific, whatever chip that has taken over the functions
of the north bridge w.r.t. AGP/PCI xfers.

I was never arguing that CPU<>memory xfers were any worse, I was arguing
that AGP memory xfers (DIME?) could be slower. I'd like to see some proof
that A64's have dedicated hardware for the AGP GART TLB as well, because I
doubt it and I couldn't find any mention of such hardware in the datasheets
I've read for the A64.

Ultimately, who cares? Nothing latency sensitive goes in or out the
AGP/PCIe graphics. For RT graphics, you want 60Hz, possibly upto 80Hz.
That's a cycle time of around 0.125s or 125ms if you want 80hz. Worst
case round trip for a word read from memory islet's say 150ns for a
single processor system. Even if it went to disk, it would only take
around 30-70ms.

So the ultimate question is: "Who gives a damn?" You're quibbling
about ns of latency for operations where it doesn't matter. AGP memory
transfers are bandwidth oriented, not latency oriented.

Now perhaps you're worried that if the memory controller gets saturated
that graphics performance would degrade. That's a pretty fair concern.
However, that should be properly handled by having different channels
of requests/sends from the memory controller. Moreover, there's no
difference between the northbridge approach and on-die controller.

DK

Mon, 27 Feb 2006 03:17:17 GMT, "pigdos" <NA@nowhere.comwrote:

>The memory controller has to read every byte (which takes time) then setup
>and execute a write of every byte.

Err, not really but for the sake of argument we'll assume that
there's some accuracy to that statement. So, umm what's your point
here? There's nothing too different about how the Athlon64's memory
controller reads/writes to memory as compared to that of a P4 system,
it's just that the controller has been moved from the Memory
Controller Hub (MCH) onto the CPU die itself.

If this doesn't involve two separate buses
then we still have to turn-around the bus before we can even write
>this data or read more. How wide is the data path between the A64 and the
>BIU (it might not be a north bridge, but it sure as hell is a BIU of some
>type)? For AGP writes this might not be an issue, but for AGP reads it
>might.

Hypertransport IS two separate buses. Hypertransport is a
unidirectional point-to-point I/ connection. In the case of the
Athlon64/ the two directions are both 16-bits wide and run at
either 1600MT/s or 2000MT/s (800 or 1000MHz DDR, depending on the
stepping of the processor and chipset).

It's neither an issue for AGP reads or writes.

Tony Hill
hilla <underscore20 <atyahoo <dotca