[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I hate Linux -- Apple is leading the standards charge on the



On Sat, 2004-01-31 at 13:17, Sean \The RIMBoy\ wrote:
> Yes, Apple was a little behind on the AGP boat.  I was disappointed on 
> that but it looks like they've learned their lesson there.  

AGP is _not_ a standard.  It is an Intel bastardization of the PCI
standard for its own purpose.  There have been countless issues with the
AGP "non-standard" -- e.g., the first AGP video cards that were off
0.05" in mechanical spacing, Pentium II CPU cache coherency issues,
etc...  AGP has been a nightmare in general, one that is just now well
understood.

Long story short, Intel has _never_ designed I/O interconnects.  Digital
designed PCI, not Intel, Digital released the first PCI bridge chips. 
Before the Intel E7500 chipset, Intel had _never_ designed a chipset
that supported multiple PCI busses (even the i450NX used a Digital PCI
bridge chip).  And even the E7500 was actually designed by ServerWorks,
fka Reliance Computer Corporation (RCC), the major provider of 4+ way
mainboards for major PC OEMs (before they started releasing products to
mainboard OEMs for end-user consumption).

AGP was the "workaround" that Intel introduced to add a "2nd" PCI bus,
one that was dedicated to video.  They also made some additives like
Direct in-Memory Execution (DiME), one that causes all kinds of
coherency issues with memory access and the CPU.  In a nutshell, I/O
should _never_ access memory directly other than to transfer to/from
(not execute code/data), _only_ nodes on the CPU bus should.  So that's
why AGP is so unstable, and a general "no-no" from a system design
standpoint.

Intel is _finally_ doing away with AGP.  PCI-Express, which is a
serialized I/O bus, will address many things with I/O.  The first
PCI-Express slots will be the x16 slot (16 serial channels), which
directly replaces AGP.  It also resolves a lot of issues that AGP had
with its "DiME" approach.

I personally feel AMD's HyperTransport** makes a far better approach. 
You see, unlike Intel interconnect, HyperTransport is a
"platform-independent, node-type-independent" NUMA (Non-Uniform Memory
Architecture) approach.  All memory is _local_ to the "Processor Unit
(PU)," be it a CPU or a GPU (Graphical Processor Unit).  To access any
other memory than its own, one node PU must contact another, so they
maintain coherency.  Furthermore, the other node PU _may_ have the
memory area already cached in its L1/L2, so that further reduces memory
latency.

[ **NOTE:  HyperTransport was actually designed by API Networks.  API
Networks was formerly Alpha Processor, Inc. (API), which is basically
what Digital spun off from its Semiconductor division.  In other words,
Digital semiconductor designed PCI and HyperTransport.  Even Intel's
first AGP logic was designed by Digital, as its aberration of PCI
logic.  The AGP-to-AGP bridge chip on the 4-VSA100 3dfx Voodoo5 6000
(which was virtually 2 AGP cards on 1 card) was also Digital/API's. ]

nVidia is supporting both HyperTransport and PCI-Express, and AMD and
its HyperTransport partners are creating HyperTransport tunnels and
bridges to PCI-Express.  PCI-Express should solve the issues AGP has.

> For the most part I agree.  Firewire IMO is still the better I/O when it 
> comes to drives and video camera's.  I have a hard time grasping the 
> concept of hooking a HD to the same bus as my mouse.

You were _never_ supposed to.  Let's put it in Linux/UNIX terms.

 USB -- designed as a "character device" (PIO) bus
 FW -- designed as a "block device" (DMA) bus

Anyone remember "Device Bay"???  If not, look it up.

In a nutshell, it was an universal expansion bay that took either USB or
FireWire devices.  USB for the slow, Programmed I/O (PIO) character
devices and FireWire for the fast, Direct Memory Access (DMA) block
devices.

USB was _never_ designed for block devices.


-- 
Bryan J. Smith, E.I. -- Engineer, Technologist, School Teacher
b.j.smith@ieee.org



-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.