Athlon 64's: a shared memory bus?

  • Thread starter Thread starter pigdos
  • Start date Start date
pigdos said:
"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 is...let'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
 
"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.

Though I expect you'll not even bother, you could try starting here:
http://www.cs.tut.fi/~jkorpela/usenet/ or you could try figuring out
yourself what is wrong with your top-posting, non-trimming, bandwidth
wasting habit - funny how you deduced that was my quibble all by yourself.
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.

I have a PDF doc, filename AGP20.PDF, which appears to have been written by
Intel, May 4 1998 and is the full AGP 2.0 spec - on page 3 in the Table of
Contents appears what I have already quoted: "Two Usage Models: Execute and
DMA". Umm, how many times do you need to be told?
Then I'll be more specific, whatever chip that has taken over the functions
of the north bridge w.r.t. AGP/PCI xfers.

Difficult to respond to a non-sentence which does not parse but I believe
I've already answered whatever your question is here. In all current
systems, however, the AGP/PCI functions of your beloved north bridge have
been distributed differently.
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.

Hmm, you don't seem to be very good at finding any documentation at all but
if you look in the BIOS & Kernel Developer's Guide, you'll find the docs on
AGP aperture and the corresponding registers.

As for AGP/PCI-e memory transactions being slower, I promise you won't
notice the difference.
 
"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.

Sorry, who are you calling a Net Nazi? Who are you asking to mention
the AGP spec? Who are you asking to cite source?
Then I'll be more specific, whatever chip that has taken over the functions
of the north bridge w.r.t. AGP/PCI xfers.

Hmm, how about AGP & the NB/SB paradigm is history? :P
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.

Does it matter whether they did it with some dedicated GART hardware
or via magical potato chips. when benchmarks across the board on
graphics performance puts A64 squarely ahead of Intel solutions?

Plus, if you're concerned about video performance, then you should
just get one of them card with 512MB of local memory and stop worrying
about having to transfer large amount of data across the external bus
with an onboard video chip.

If you were a Phd in EE I'd take your word as fact, since you're not, I
don't...

I'll quite happily take the word of most of the veterans here who have
in all likelihoods done more years of actual work on said systems
design (maybe even help invent them) than some guy with who just got
his PhD in EE. Sure the EEPhD might explain the EE concepts/tech
involved better but may not necessarily know actual in use specifics
of a particular system esp if he majored and did his thesis in say
semi-con design rather than comp architecture.

Pigdos, is this Doug the fellow you were calling a net nazi and
demanding credentials from? :P

Though seriously, I don't know about western culture but we've been
taught to be nice and respectful when asking questions about things we
don't know.
 
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/O connection. In the case of the
Athlon64/Opteron 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.
 
Um, that's AGP 2.0, not AGP 3.0. I guess you don't know the difference? The
document I'm looking at is for the AGP 3.0 spec. and yes, there ARE
differences.

You never bother proving your assertions do you? Your opinion is nothing but
fact? Prove to me that there are, in fact, dedicated registers in the A64
memory controller to handle AGP transactions.

Your mention of top-posting is nothing but a red herring to divert attention
from the issues.
 
30+ years of doing what?

An AGP 2.0 spec. document doesn't prove anything, why don't we look at the
AGP 3.0 spec?
 
Obviously you have a LOT to learn. You don't think "DMA and burst xfers"
have to go over a bus of some type? You don't think bus turnaround is an
issue? I think you need to take a refresher course in basic digital logic
and design.
 
This is all I wanted to hear. Why George felt the need to denigrate me at
every turn I'll never know. I didn't know this, that's why I asked.

Does PCIe feature any functionality equivalent to AGP w.r.t. storing texture
data in system memory?
 
Obviously you have a LOT to learn. You don't think "DMA and burst xfers"
have to go over a bus of some type? You don't think bus turnaround is an
issue? I think you need to take a refresher course in basic digital logic
and design.
I might answer you silly posts once you;

1) stop top-posting like a spoiled brat

2) include some context so I know what the hell you're going on
about.
 
This is all I wanted to hear. Why George felt the need to denigrate me at
every turn I'll never know. I didn't know this, that's why I asked.

George had answered your questions more than once, I'm just wording
things differently for ya here..
Does PCIe feature any functionality equivalent to AGP w.r.t. storing texture
data in system memory?

To the best of my knowledge, no. DIME was a really dumb idea and
other than a few odd-ball video cards it was NEVER used in AGP.

Obviously though PCI-Express CAN do DMA just like AGP does.
Essentially all video cards for the past 5+ years or so, regardless of
whether they are AGP or PCI-e have used AGP to transfer the raw data
from system memory/hard drives into the video cards local texture
memory for use. Usually this is done all at once (eg in games it
happens when you load up a new level).
 
Um, that's AGP 2.0, not AGP 3.0. I guess you don't know the difference? The
document I'm looking at is for the AGP 3.0 spec. and yes, there ARE
differences.

Why would anyone not know who cared? There are numerous articles on the
subject and the AGP docs were publicly available to all... as opposed to
the PCI Expess docs.
You never bother proving your assertions do you? Your opinion is nothing but
fact?

You got it right - just the facts. said:
Prove to me that there are, in fact, dedicated registers in the A64
memory controller to handle AGP transactions.

I took you to the water but you won't drink. Think about it.
 
This is all I wanted to hear. Why George felt the need to denigrate me at
every turn I'll never know. I didn't know this, that's why I asked.

What do you expect? You asked. You got correct answers. You argued...
from a position of complete ignorance. You refused to look at docs which
were referenced. Umm, you denigrated yourself.Ô_ô
Does PCIe feature any functionality equivalent to AGP w.r.t. storing texture
data in system memory?

If you would read your beloved AGP 3.0 specs you'd know that it no longer
refers to DiME (or "execute mode") for texture data. This is at least in
part because AGP 3.0 added support for isochronous transfers, a more
generic form of high speed guaranteed "packet" response for data transfers;
this was essentially to cope with the demands of new devices which do
streaming and video capture. PCI-e docs are not publicly available but I
believe it also supports isochronous transfers. Perhaps someone who has
access to the docs can comment... but there are certainly several PCI-e
video cards which use UMA and partial UMA for *any* video data. As for
DiME I don't believe it was used by any major game software for texturing.
 
In case the point escaped you, I was merely pointing out that the AGP 3.0
specs no where mention DMA, but I guess that doesn't matter to your most
royal majesty.

You never posted any proof that any of the A64's or opterons feature
dedicated GART hardware or TLB's. I can only guess your assertion that they
do is bullshit...
 
Neither does it refer to DMA, so I guess you were wrong as well, your Royal
Highness.

Are there any AGP video cards that use isochronous xfers?

On another note, do any of the modern Pentium-4 chipsets feature DDR or
DDR-II memory architectures with xfer speeds on-par w/A64's? I had thought
Pentium-4's could perform dual-channel so wouldn't it be the equivalent of a
128-bit wide memory bus?

I'm still waiting for proof that A64's have dedicated hardware (LOL) to
handle GART and TLB's for AGP memory xfers, your majesty.

--
Doug
George Macdonald said:
This is all I wanted to hear. Why George felt the need to denigrate me at
every turn I'll never know. I didn't know this, that's why I asked.

What do you expect? You asked. You got correct answers. You argued...
from a position of complete ignorance. You refused to look at docs which
were referenced. Umm, you denigrated yourself.Ô_ô
Does PCIe feature any functionality equivalent to AGP w.r.t. storing
texture
data in system memory?

If you would read your beloved AGP 3.0 specs you'd know that it no longer
refers to DiME (or "execute mode") for texture data. This is at least in
part because AGP 3.0 added support for isochronous transfers, a more
generic form of high speed guaranteed "packet" response for data
transfers;
this was essentially to cope with the demands of new devices which do
streaming and video capture. PCI-e docs are not publicly available but I
believe it also supports isochronous transfers. Perhaps someone who has
access to the docs can comment... but there are certainly several PCI-e
video cards which use UMA and partial UMA for *any* video data. As for
DiME I don't believe it was used by any major game software for texturing.
 
WTF does that mean? You gotta degree of some sort? Ever do any hardware
engineering? Are you an MCSE who deludes himself into thinking he's ready
for the EIT?
 
WTF does that mean?

It means; You're a top-posting twit who doesn't know how to use the
Usenet! Hint: everything you "quote" is after your signature, which any
decent newsreader trims as a matter of course.
You gotta degree of some sort?

Yep, of some sort. You hiring? You better have *loads* of money!
Ever do any hardware engineering?

Only for 32 years (sorry French Franc)... Yep, even high-end processor
development.

You?
Are you an MCSE who deludes himself into thinking he's ready for the EIT?

MSCE, nope. BSEE. EIT? Why on Earth would I even consider NSPE? They
have nothing I've ever wanted.

You?
 
Um, the AMD A64 documentation also refers to a North Bridge, but I suppose
your majesty is the final authority on the architecture of the A64, not AMD:
AMD Functional Data Sheet,
939-Pin Package

2.5 Northbridge
The Northbridge logic in the processor refers to the HyperTransportT
technology interface, the
memory controller, and their respective interfaces to the CPU core. These
interfaces are described in
more detail in the following sections.
2.5.1 HyperTransportT Technology Overview
The processor includes a 16-bit HyperTransportT technology interface
designed to be capable of
operating up to 2000 mega-transfers per second (MT/s), resulting in a
bandwidth of up to 8 Gbytes/s
(4 Gbytes/s in each direction). The processor supports HyperTransportT
synchronous clocking
mode. Refer to the HyperTransportT I/O Link Specification
(www.hypertransport.org) for details of
link operation.
2.5.1.1 Link Initialization
The HyperTransportT technology interface of the processor can be operated as
a single 16-bit link.
The HyperTransportT I/O Link Specification details the negotiation that
occurs at power-on to
determine the widths and rates that will be used with the link. Refer also
to the BIOS and Kernel
Developer's Guide for the AMD AthlonT 64 and AMD OpteronT Processors, order#
26094, for
information about link initialization and setup of routing tables.
The unused L0_CTLIN_H/L[1] pins must be terminated as follows:
.. L0_CTLIN_H[1] must be pulled High.
.. L0_CTLIN_L[1] must be pulled Low.

No mention of GART or TLB's for AGP read accesses either...

--
Doug
George Macdonald said:
This is all I wanted to hear. Why George felt the need to denigrate me at
every turn I'll never know. I didn't know this, that's why I asked.

What do you expect? You asked. You got correct answers. You argued...
from a position of complete ignorance. You refused to look at docs which
were referenced. Umm, you denigrated yourself.Ô_ô
Does PCIe feature any functionality equivalent to AGP w.r.t. storing
texture
data in system memory?

If you would read your beloved AGP 3.0 specs you'd know that it no longer
refers to DiME (or "execute mode") for texture data. This is at least in
part because AGP 3.0 added support for isochronous transfers, a more
generic form of high speed guaranteed "packet" response for data
transfers;
this was essentially to cope with the demands of new devices which do
streaming and video capture. PCI-e docs are not publicly available but I
believe it also supports isochronous transfers. Perhaps someone who has
access to the docs can comment... but there are certainly several PCI-e
video cards which use UMA and partial UMA for *any* video data. As for
DiME I don't believe it was used by any major game software for texturing.
 
In case the point escaped you, I was merely pointing out that the AGP 3.0
specs no where mention DMA, but I guess that doesn't matter to your most
royal majesty.

Since DiME is no longer a classified method, it doesn't have to - anyone
who knows about data transfer methods can recognize the DMA method... which
*was* documented in previous versions of the spec... or are you still going
to insist that as well as dropping DiME, Intel also dropped DMA and made a
whole new specification which is backwards compatible but totally
different?
You never posted any proof that any of the A64's or opterons feature
dedicated GART hardware or TLB's. I can only guess your assertion that they
do is bullshit...

I cannot be held responsible for your incompetence at finding information
which is freely available at www.amd.com ... in the tech docs section....
would ya believe?... and I *have* provided the name of the document. What
more do you want?
 
Back
Top