Concept: Dynamic Viewport Context Window Manager (DVCWM)

Abstract: A paradigm shift in window manager design, DVCWM combines a simple, but effective tab-based approach with dynamic creation/destruction of virtual desktops (viewports) of four different contexts: Single, Multi, Toggle and Session.

Originally posted on old SmithDot.NET blog 2004 Apr 25 (an update/article from on-going discussions since 2001 onward)

• Tab-Based Window Management
• The Redundancy of It All
• The 4 Viewport Contexts: SingleVC, MultiVC, ToggleVC, SessionVC
• The 4 Window-Buttons: Single, Multi, Toggle and Close
• Example DVCWM Wireframes
• MultiVC: "Active" w/1 ToggleVC "On"
• SingleVC: "Active" w/1 ToggleVC "On"
• SessionVC: "Active" w/1 ToggleVC "On"
• Common Tasks and Accommodation
• Child Windows
• VC and Window History
• Other Considerations
• Initial Implementation
  

Tab-Based Window Management

A good majority of users do not like the concept of overlapped windows. They prefer tiled windows or, from a more X-Windows (largely UNIX) centric perspective (hereafter referred to as simply X), virtual desktops or viewports. Seeing the full picture, or being able to easily switch between full or non-overlapped partial views is ideal. Just like a daytimer or tabbed notebook, people want to be able to flip through things quickly, but not clutter what they are focused on at the time. Unfortunately, as today's most popular graphical user interfaces (GUI) are designed, this is still not a reality, and overlapped windows dominate the landscape.

Not surprisingly the original creator of the GUI, Xerox's PARC, came up with an better GUI for the '90s. Although far from perfect, Xerox's TabWorks was sold to various OEMs as a replacement GUI shell for MS Windows (i.e. a replacement for explorer.exe). Despite various advantages, TabWorks suffered the fate of many other 3rd party GUI shells, incompatibilities as Microsoft felt any non-standard shell affected the brandname and look of their product. So even the most interested of OEMs, like Compaq, had to drop TabWorks for sheer reasons of incompatibilities.

Many punduits have stated that real-world replicas are not the ideal approach to GUIs. As such, they have dismissed the concept of tab-based window managers. Although a few tab-based managers exist for X, they more or less just group instances of the same (or similar) program(s) together. This in itself is also difficult to accomplish, as programs themselves are supposed to maintain their own child windows, not the window manager itself.

The Redundancy of It All

In the X world, many users are enamored with the virtual desktop or viewport, multiple desktops where they can run windows uncluttered from other windows on other desktops. Some X window managers even treat the two distinctly different, offering a dimension of virtual desktops, each with their own dimension of viewports. Either the window manger or desktop framework offers, or users can even specify, a fixed number of viewports/desktops, and use them to their hearts delight. Maximizing, minimizing and doing other things to the windows under each desktop/viewport. And there is even the concept of a "sticky window," or one that traverses across virtual desktops/viewports.

Sounds both redudant and confusing if you ask me. Much of it seems to be a case of taking X and adopting MS Windows concepts.

To start:

1. Maximized Windows: What good does a virtual desktop/viewport (hereafter referred to as simply viewport) do if you simply maximize one program on it? That maximized window might as well be its own viewport! Is there any reason to have other programs on that viewport? Probably not.
   
2. Sticky Windows: I love these and hate these. I like to have things like my calculator, dictionary checker, music player, volume mixer, etc... follow me around, but I want to turn them off on a dime too. I wish there was an easier way to not only toggle them on and off quickly, but to group them together so I could "toggle" a select set (e.g., calc/dict, player/mixer, etc...) viewable and not viewable easily.
   
3. Minimized Windows: Why do I need to minimize windows if I have multiple viewports anyway? Sometimes I "get lost" or "forget about something minimized" and don't see it until I either launch it again, or I just hit "Alt-Tab," which kinda defeats the purpose of using a GUI if I have to go back to the keyboard. A minimized window seems to be the most MS Windows concept of them all, totally foreign to a desktop with multiple viewports! In a daytimer or notebook, I simply flip between pages, just like I do viewports. At most I'd just like a toggle for the sticky windows.
4. The "Real" Desktop: And at what point do I have my "real" desktop? Yeah, that one with the icons for the GUI session? Is it fixed to one viewport? Or all? Now what if I want to run multiple GUI sessions -- like GNOME and KDE, and have their respectively session managers running? How about I add ROX Filer to the mix, let alone XFCE and others? Who "owns" that "real" desktop?

Many may disagree with me, but I find the overlap of approaches to window and viewport management are not well defined and out-of-control. Fortunately, I think there is a way to address all of it, and in a very legacy-compatible way. In fact, I believe it would work without issue on even MS Windows! The key is to merge the concepts of viewports and windows altogether.

The 4 Viewport Contexts: SingleVC, MultiVC, ToggleVC, SessionVC

I have played back and forth with this since first considering the DVCWM approach. I finally standardized on the following nomenclature for what I call Viewport Context (VC), which are "tabs" on the sides of the screen. I avoid the term "tabs" because they are now commonly used in the standard 3-pane application window today:

1. SingleVC: This is a viewport with a single, maximized window. Unlike a traditional window manager, the viewport and window are one in DVCWM. This is done via dynamic viewport creation and destruction, as we'll see. When the SingleVC is activated, it covers all the real estate.
   
2. MultiVC: This is a viewport capable of holding multiple windows, including a background that covers all real estate in case not all the windows do. This is very much like the traditional viewport in a traditional window manager. When a MultiVC is activated, it covers all the real estate.
   
3. ToggleVC: This is a viewport capable of holding multiple windows, but unlike the MultiVC, it does not have a background. In other words, when you select a ToggleVC, only the space actually being used by the windows in the ToggleVC covers the most previous VC activated.
4. SessionVC: This is probably the most difficult to understand (and possibly code to accomodate all session/window managers out there), unless you see it in action. In a nutshell, the SessionVC is the "real" desktop -- aka the "root desktop." That means it shows the GNOME/Nautilus (or gmc) desktop and its icons, the KDE/Konqueror (or kfm) desktop and its icons, or maybe you run something like ROX and its session manager.
   

Okay, what's the big deal here? I've added context to viewports. It seems simple, but it is very powerful overall. Most importantly, I am not doing anything unexpected with the windows themselves, so compatibility is maintained. All I'm doing is assigning them to viewports, which any and all X applications take no issue with. The fact that the viewports have a context, which is at the heart of DVCWM, introduces no compatibility issues.

The 4 Window-Buttons: Single, Multi, Toggle and Close

Again, this seems to be a traditional approach, but it is not quite. Context is everything, and the merger of window and viewport changes evertyhing.

1. Single: [Greyed out if program is already in a SingleVC] If the application is either "Multied" or "Toggled," make it a "Singled" in its own SingleVC. There is no right-click option at all.
   
2. Multi: [Greyed out if program is already in a MultiVC] If the application is either "Singled" or "Toggled," make it "Multied" as part of the last activated MultiVC. Right clicking lets you select a specific MultiVC (even if greyed out).
   
3. Toggle: [Greyed out if a program is already in a ToggleVC] If the application is either "Singled" or "Multied," make it "Toggled" as part of the last activated ToggleVC. Right clicking lets you select a specific MultiVC (even if greyed out).
4. Close: [Never greyed out] Closes the window. If it is the last window on the activated VC, then that VC is destroyed, unless it is the "default" MultiVC (which is always available).

Example DVCWM Wireframes

I have always envisioned DVCWM's default layout to be a bunch of "tabs" for each VC, with the 4 VCs oriented to the four corners of the screen. The tabs may be "hidden," to give maximum viewport space (minus a few pixels on the sides), or always shown (taking a few hundred pixels on the sides). Eventually there will be options for placement, but I feel the "location" of the VCs are important to their "context," and really prefer the "4 corners" concept.

Three example wireframes highlighting the differences between the viewport contexts in DVCWM are below. In each example, there are 3 of each VC type launched. This will, of course, vary in reality, as VCs are dynamically created and destroyed as needed.

NOTE: For a high resolution, vector graphic of each wireframe, please click on the graphic for each to open an Adobe Acrobat PDF file. They are partially scaled for a 1600x1200 screen, using 50 pixel high, 150 pixel wide tabs, with the VC/program title bars also 50 pixels high. If the tabs are not configured for autohiding, and take up fixed real estate, they would result in an approximate 1250x1150 "usable" area (around 175 pixels from each of the sides for the tabs, and 50 for the VC title bar on the top or bottom, depending on the VC selected). If autohiding, then an approximately 1550x1150 is "usable" (about 25 pixels from each side, and 50 pixels from the top or bottom). Title bars with smaller fonts and/or autohiding would be recommended for resolutions 1024x768 and lower.

MultiVC: "Active" w/1 ToggleVC "On"

The first example DVCWM wireframe highlights the more traditional virtual desktop/viewport X users are accustomed to in a MultiVC.

In this example, the 2nd MultiVC is "activated."

• MultiVC "Tab" and "Title Bar"
  
• MultiVCs (by default) will be located in the bottom-left corner
• "VC Ttitle Bar" will extend on the bottom (taking 50 pixels away from the bottom)
  
• "Bar-link" from the "Tab" to the "Title Bar" for the VC shows which one is active
• VC "Tabs" have a button for quick properties access (including a list of all programs running in the VC)
  
• The "Active" VC has that button at the "end" (right-most for MultiVC) of its "VC Title Bar"
  
• MultiVC Background
• Just like any traditional viewport, the background can be set on a MultiVC basis
• In this example, the background is the same as the tab color, a Bluish-Green color
  
• MultiVC Programs (2)
  
• In this eample, there are two (2) programs that are located or "Multied" to this MultiVC
• Whatever they do not cover, the background of the MultiVC shows through
• In this example, they are the green-reddot windows
• The windows then each have their own, 4 window-buttons
• They cannot be "maximized" or they would become their own SingleVC (aka "Singled")
  

Of note is that there are multiple "Title Bars" in a MultiVC. One at the bottom for the MultiVC itself, and then one title bar at the top of each program.

In addition, the 2nd ToggleVC is "on" (and will be left on for all other examples as well)

• ToggleVC "Tab" and "On" Indicator
  
• ToggleVCs (by default) will be located in the bottom-right corner
• NOTE: this is open to debate, and it might be better in the upper-right (let alone user customizable)
  
• There is no such thing as a "Title Bar" for ToggleVCs, only an "On" Indicator next to the "Tab"
  
• Like other VCs, there is a button for quick property access
• ToggleVCs are never active themselves, they are just either "on" or "off"
• ToggleVC "Overlap"
• There is no "background" for the ToggleVCs.
• In traditional WM speak, think of ToggleVCs as groupings of "sticky" windows
• Any ToggleVCs that are "on" will then overlapp the entire, active MultiVC
• If multiple ToggleVCs are "on," the last ToggleVC turned on overlapps the others
• ToggleVC Programs (2)
  
• In this example, one ToggleVC is "on," the other 2 are "off"
• The ToggleVC "on" has 2 programs in it
  
• In this example, they are the yellow-brown windows
• And like any other window, the windows in the ToggleVC each have their own, 4 window-buttons
• They cannot be "maximized" or they would become their own SingleVC (aka "Singled")
  

SingleVC: "Active" w/1 ToggleVC "On"

The second example DVCWM wireframe highlights the "merger" of viewport and maximized window into the SingleVC. This is a key point in DVCWM's approach, the removal of redundancy and confusion between a viewport and a maximized window. SingleVCs are viewports dynamically created to hold a single program that has been singled, or maximized in the traditional window manager sense (and, correspondingly, dynamically destroyed when it is Mulited, or normalized in traditional WM speak).

In this example, the 2nd SingleVC is "activated."

• SingleVC "Tab" and combined "Title Bar"
  
• SingleVCs (by default) will be located in the top-left corner
• The combined "VC/Program Ttitle Bar" will extend on the bottom (taking 50 pixels away from the top)
  
• "Bar-link" from the "Tab" to the "Title Bar" for the VC shows which one is active, just like for MultiVCs
  
• Unlike MultiVC, the 4 window buttons are "merged" into the "combined" VC/Program Title Bar
  
• SingleVC Background = None
  
• There is none because the program is taking up the whole VC
• In this example, the purple color is the program's full window, same as its tab
  
• SingleVC Programs (1)
  
• Again, in any SingleVC, there is but one program
  
• It covers everything, nothing shows through
• Again, in the SingleVC, the window-buttons are merged with the VC Title Bar
• A SingleVC that is either "Multied" (normalized) or "Toggled" (stickied) is no longer a SingleVC (and joins an existing MultiVC or ToggleVC, respectively)
  

Of final note is the single "Title Bar" in the SingleVC, at the top. It is the name of the program itself, as it is the only thing running in the VC.

In addition, the 2nd ToggleVC is "on" (and will be left on for all other examples as well). The attributes are the same as for the previous MultiVC example. Any ToggleVC that is "on" merely overlays any "active" SingleVC.

SessionVC: "Active" w/1 ToggleVC "On"

The final example DVCWM wireframe highlights the "separation" of DVCWM from the "session manager." I am not sure of the feasibility of this, and if it is even required now that FreeDesktop is trying to address simultaneous GNOME-KDE environments. But I believe it's the best approach for a window manager that is not tied to any "session manager" such as GNOME, KDE, ROX, etc... If anything, the SessionVC "tab" basically becomes the "show desktop" button -- with one for each session manager currently running.

Each "session manager" that launches has its own SessionVC. Typically this will be only one (1) initial session manager (whatever you launch DVCWM with), and other SessionVCs will appear as other session managers launch. My sincerest hope is this will finally address the issue with "multiple session icons" and other conflicting resources when more than session is run -- especially GNOME and KDE, but others as well (like ROX).

In this example, the 3rd SessionVC, GNOME, is "activated,"

• SessionVC "Tab" and combined "Title Bar"
  
• SingleVCs (by default) will be located in the top-left corner
• NOTE: this is open to debate, and it might be better in the lower-right (let alone user customizable)
• The "VC Ttitle Bar" will extend on the bottom (taking 50 pixels away from the top)
  
• "Bar-link" from the "Tab" to the "Title Bar" for the VC shows which one is active, just like for MultiVCs
  
• Since there are no "Windows" in the SessionVC, there is only the single "properties" button
  
• SessionVC Background = "Real" Desktop for the Session
  
• This is the "real" desktop or "root" desktop for the "activated" session (GNOME, KDE, ROX, etc...)
  
• In this example, the background is the same as the tab color, a brown color
  
• Various icons/folders are shown in orange
  
• SessionVC Programs = None
  
• Again, there are no other programs running in a SessionVC
  
• Just the "real" desktop for the "activated" session is shown
  
• A SessionVC cannot be changed at all, it just exists if a "supported" session is running (GNOME, KDE, ROX, etc...)
  

Of note, the "SessionVC Title Bar" could be a menu bar of the session. This is one of the areas where DVCWM will have to be coded to accomodate a few of the differences and/or quirks of different session managers. But the use of SessionVCs will still make DVCWM much, much easier and more compatible "out-of-the-box" with any session manager, as long as it merely knows of it (knows how to detect if GNOME, KDE, ROX, etc... is running).

As the other examples, the 2nd ToggleVC is "on." The attributes are the same as for the previous MultiVC example. Any ToggleVC that is "on" merely overlays any "active" SessionVC.

Common Tasks and Accommodation

Okay, now I'm sure you're starting to build a plethora of questions regarding "how will DVCWM handle X?" Here's a rundown of some of the tasks.

Child Windows

Which VC child windows will be autoassigned to depend on what VC type the parent window is running in. In fact, this actually solves a number of issues with today's WMs, which seem to not only vary, but launch popups across viewports as you switch through them.

• SingleVC Parent -> ToggleVC Child (Created)
  
• If the parent window is in a SingleVC parent, then any child windows (one or more) will be launched into a dynamically created ToggleVC
• Does the child get focus? Depends ...
  
• On: If the parent window SingleVC is active, the child ToggleVC will be "on"
• Off: If the parent window SingleVC is not active, the child ToggleVC will be "off"
• Common applications:
• Floating toolbars. Turn them on/off on a whim c/o DVCWM. Move them to other ToggleVCs so you can turn "banks" of floating toolbars on and off.

This is where I believe DVCWM will really shine -- dealing with the various "focus" issues as well as the floating toolbar "nightmare." Furthermore, the "child" window could be put into a SingleVC, such as in the case of TheGIMP, and the TheGIMP's main window and toolbards in one or more ToggleVCs.

• MultiVC Parent -> MultiVC Child (Existing/Same)
  
• If the parent window is in a MultiVC parent, then the child windows (one or more) will be launched in the same MultiVC.

Seems simple, and works like most traditional window managers. Unfortunately, some window managers launch a child window in the current viewport, which may not be the same as the parent window. I find this rather annoying, not to mention the focus issues. I believe forcing it to always load in the same MultiVC as the parent addresses this nicely. I mean, I hate it when some child window that takes 30+ seconds to spawn because of computational requirements ends up spawning in another viewport that I've switched to because I've switched to working on something else during the delay. I'd rather have it stay with the original viewport and have a "feedback flash" of that other viewport when it finally launches.

• ToggleVC Parent -> ToggleVC Child (Existing/Same)
  
• If the parent window is in a ToggleVC, then the child windows (one or more) will be launched in the same ToggleVC.

Again, straight-forward, like the MultiVC.

• SessionVC Parent -> ToggleVC Child (Created)
  
• If a program is launched from a SessionVC, then the program comes up in a dynamically created ToggleVC
  
• Common applications:
• File managers/browsers.
  

This one is a tad different. First off, there is no such thing as a "SessionVC Window" to begin with. But we do have icons, files and, possibly, menus in the SessionVC. So we need a default VC to launch them to. A common application that would be launched from a SessionVC is a file manager/browser, possibly because a folder icon was opened. These should create a new, dynamically created ToggleVC. Subsequent folders would be be launched in the same ToggleVC, per the defaults of parent windows in a ToggleVC previously discussed.

I yet again feel this is where DVCWM really continues to shine. Viewports with context makes all the difference.

VC and Window History

Now you're probably wondering what happens when you logoff. The fact that people don't want to re-create new VCs everytime they login is understandable. At the same time, most users don't want all of their programs launching when they login, but they do want a way to launch common apps in tandem when they do need them.

Again, DVCWM addresses this too with simple, but effective logic.

To start, when a new VC is created, DVCWM will not remember the settings by default. That way users can create and destroy VCs all the want without any additional overhead or impact, or otherwise undesired effects by default to the user.

• SingleVC: Remember if programs are "Singled" (maximized)
  

The only exception to this rule is if a window is "Singled" (maximized), then DVCWM will remember that for the next time the program is run (assuming it is not "Multied" or "normalized" afterwards). In other words, if a SingleVC is created by "maximizing" a program, the DVCWM will remember for that program.

• MultiVC, ToggleVC: Remember programs, geometry if "named"
• Do not automatically launch at startup, but offer "right-click" seletion under VC corner
  

Now that leaves the MultiVCs and ToggleVCs. Again, the settings for a VC are not remember by default. But if a user assigns a "name" to a Multi or ToggleVC, then DVCWM will remember the name, and what programs (and their geometry) are in that VC. That way the user can create regular Multi and ToggleVCs they use.

Now the next time the user logs in, it will not automatically re-create any of those Multi or ToggleVCs immediately. But it will add a right-click entry to recreate the VC and launch those programs in it. The user merely goes to the proper "corner" for the VC type, right-clicks and then selects the name that they previously assigned that VC.

For example, say I'm a user and I create a ToggleVC which has my calculator and dictionary program. I have named the ToggleVC "Utility" which automatically saves the programs in that VC, their geometry and other window meta-data, etc... The next time I login, I can go to the lower-right of my screen (or whereever the ToggleVC tabs normally appear), right-click and select "Utility." This will create the ToggleVC "Utility" and all the programs in it before, with the last geometry recorded.

• SessionVC: None
  

For SessionVCs, only the session manager at the start of X is launched. I.e., if I run GNOME, then only a SessionVC for GNOME/Nautilus appears. Other SessionVCs will be created if and when programs are launched that launch other session managers (like KDE, ROX, etc...). This creation is dynamic for each time DVCWM is running, and nothing is saved.

Other Considerations

I'm drawning a blank. I know there are several other details of interest that I am forgetting, but have previously recognized how DVCWM would handle and improve upon over traditional window managers.

Initial Implementation

As many others will verify, I am far more of a dreamer than a doer. But I really desire a window manager like DVCWM. It's more than just a philosophical change in window manager design, it's about simplifying window managers period. Today's mesh of separate viewport and window management is seemingly adhoc and is need of update. At the same time, by just redefining how viewports work, putting them under several types of "content" and creating/destroying them dynamically, we can change how window managers work evolutionarily, with minimal impact and maximum compatibility.

For my initial implementation, my desire is to build DVCWM as a window manager for the ROX Desktop. GTK+-based ROX already contains an excellent session manager and file manager, and a native window manager would be the perfect complement. Right now ROX works well with XFWM4 (from XFCE4) and somewhat well with IceWM, but could really use a native window manager other than its bare Effiel-based window manager offering (that very few people use). Ultimately, ROX is fairly nice in general, so I would not mind one bit of DVCWM came with ROX by default (and vice-versa).

In that regard, DVCWM would always launch ROX as its default SessionVC. At the same time, it would help "tame" both GNOME and KDE by putting them in their own SessionVCs as they respectively load. I don't think hiding these details or making a window manager "native" to a particular session manager is the key. I think a window manager that addresses it, as part of adding "context" to viewports, would do it most effectively and with the most compatibility.

As such, I am beginning to code some really basic stuff using GTK+. I have gone through the code of various window managers out there and I'm basically lost. Metacity, while GTK+-based, is built for GNOME 2, and overkill (little more than lots and lots of code for interfacing to GNOME). GTK+-based Sawfish is a little better, being built for GNOME 1, but almost as complicated. GTK+-based XFWM4 is built for the every complexing XFCE while IceWM is Xt-widget based. I'm looking for really good, basic GTK+ window manager example to start from. Maybe I should relook at Enlightenment then?

Eventually I'll get around to GNOME and KDE integration, but by its very nature, DVCWM is designed to be very session-agnostic in general. I want to keep session managers in their own SessionVCs, and the window manager "in control." In my view, that would make DVCWM one of the more universally compatible window managers out there, even if it lacked a lot of advanced session manager functionality outside of each, designated SessionVC. I'm still wondering how feasible the concept of a SessionVC is, but I don't see how it can't work.

After all, we're just talking viewports -- albeit with a bunch of caveats like added "context."

PCI-Express: Throttling I/O and Reducing Contention ...

Originally posted 2004 Apr 19 to PC_Support

I've talked at great length about AMD HyperTransport and boosting the throughput of and reducing contention for I/O at the CPU-Memory-I/O interconnect level. Unfortunately, people want cheap hardware, and the only way to take advantage of AMD HyperTransport is to buy a mainboard with PCI-X, which only boosts the number of traces, increasing overall mainboard cost past $300-400.

Otherwise, despite the massive 6.4GBps per HyperTransport channel of the Opteron (100 = 1 channel, 200 = 2 channel, 800 = 3 channel), there is only a single, measly, 0.125GBps (133Mbps) bus for PCI I/O.

THE PROBLEM:
NO COMMODITY, HIGH-SPEED PCI, THE AGP "BASTARD"

For the life of Intel, it has _never_ designed a good chipset. Intel's current E7500 series is a gift from a cross-patent license with ServerWorks (formerly known as Reliance Computer Corporation, RCC), who designed most server and workstation chipsets for x86 and non-x86 for the longest time. In fact, the PCI Special Interest Group (PCI-SIG) really worked independently of a lot of Intel chipset designers, and expanded PCI to include 64-bit, 66-133MHz PCI-X which is just as bandwidth capable as AGP3.0 (aka AGPx8).

All Intel really designed was a "dedicated 32-bit PCI bus" with a few CPU-like tricks in AGP. Unfortunately, AGP is _not_ a standard, it's an Intel trade secret. And it's CPU-like tricks, such as "Direct, in-Memory Execution" (DiME) and Side Band Addressing (SBA) are hell on CPU cache-memory coherency, especially for multiprocessor. As AGP attempts to make the video I/O act like a CPU, the CPU and AGP do all sorts of inefficient coherency checks, often at the CPU or software-level.

So what the world got was a commodity mainboard solution with a measly, shared 133MBps (32-bit x 33MHz) PCI bus with an unstable and unreliable, dedicated 32-bit AGP bus for graphics. Far too many system integrators build servers with this configuration, assuming there was nothing else out there (like ServerWorks). After all, they just sold a dual-processor server, who cares if it didn't have the I/O to handle the load, the customer often didn't understand why until well after the sale.

THE SOLUTION:
SERIAL I/O

Intel's switched serial, instead of parallel bus (like PCI), Next Generation I/O (NGIO) has been on the developer block for almost a decade. Unfortunately, Intel is still using the same, shared bus for its Pentium series that is now almost 12 years old, while assuming Itanium and its newer, NUMA design would be far more adopted by now. The result was that NGIO was held up for awhile, as an x86 platform was
lacking that could take advantage of it.

That all changed with AMD's HyperTransport, and the revolution it started in chipset design -- not only for AMD processors, not only for Intel processors, but for the _entire_ engineering world of system interconnects and mainboard design. From the PCI-SIG to nVidia, it was quickly apparent that NGIO could become a reality, thanx to a commodity bus like HyperTransport. And even outside of 6.4GBps HyperTransport, most north-to-southbridge interconnects were already offering 0.5GBps, a good 4x of what 0.125GBps (133MBps) shared PCI could do anyway.

Thus, PCI-Express was born.

PCI-Express is a multi-channel, serial I/O, based on Intel's NGIO. A single PCI-Express channel is a 1-bit, full-duplex pair running at 2.5Gbps aggregate (1.25GBps per direction) -- 250MBps (125MBps per direction) per 10-bit byte differential, 8-bit byte usable. This 10-bit/byte encoding is now commonplace in new serial data transfer protocols such as SerialATA.

PCI-EXPRESS x16:
THE GRAPHICS INTERCONNECT

The very first purpose of PCI-Express is to replace the non-standard, AGP "bastard" of PCI. Everyone wants to see this happen, even Intel. The common implementation is to bundle 16 PCI-Express channels, or what is known as PCI-Express x16, into a true AGP replacement.

At 16 x 250MBps (125MBps/direction), that's 4GBps (2GBps/direction), and more than enough I/O throughput to replace 2.1GBps AGPx8 (32-bit x DDR266, 533MHz effective). It also makes the graphics bus a _true_, _standard_ I/O bus again -- without all the tricks and issues that AGP was.

But PCI-Express won't stop as just graphics. PCI-Express is also designed to offer other options.

PCI-EXPRESS x1:
DEDICATED I/O ON THE CHEAP

One of the more commodity options will be PCI-Express x1 -- a single channel. PCI-Express x1 is 250MBps (125MBps/direction), which is the most ideal for typical desktop and workstation peripherials. Being that each PCI-Express x1 "port" is "dedicated" to the add-in card, _unlike_ a "shared" 133MBps (32-bit x 33MHz) PCI bus, it is now very easy to keep disk and network I/O from contending with each other.

2.5Gbps (1.25Gbps/direction) = 250MBps (125MBps/direction), is _perfect_ for full-duplex 1Gbps Ethernet (GbE). It is also ideal for 150MBps SerialATA. Just adding two PCI-Express x1 channels would now address the I/O contention of most high-end workstations or entry-level servers!

COMMODITY IMPLEMENTATIONS:

Initially, PCI-Express will see one or both of the following changes in chipsets:

1. A PCI-Express x16 "port" will _replace_ AGP3.0 in the "northbridge"
2. (2) PCI-Express x1 "ports" will be _added_ to the "southbridge"

#1 is of little difference, except for increased stability and a little more bandwidth. The CPU now has a 4GBps (2GBps/direction) connection to video, instead of only 2.1GBps. On a HyperTransport CPU, like the AMD Athlon64/Opteron or IBMPowerPC970/AppleG5, the PCI-Express x16 "port" will probably be on its own HyperTransport "tunnel" -- or maybe a single HyperTransport "peripherial" with the rest of the "southbridge."

#2 is of far more significance. Most southbridge chip designs (Intel, nVidia, SiS and ViA), already have a 0.5GBps** or greater (0.8-1.0GBps in some**) to their northbridge. A 0.125GBps (133MBps) "shared" PCI with Legacy PC (LPC) is underutilizing that connection. Adding in (2) PCI-Express x1 "ports" will add 0.5GBps to throughput, which is easily handled by the connection.

**Common north-south interconnect designs:

• AMD8111: 0.8GBps HT (8+8-bit @ 400MHz)
• Intel "ICH": 0.5GBps PCI (64-bit x 66MHz) + 1.0GBps PCI-X (64-bit x 133MHz)
• nVidia "MCP": 0.8GBps HT (8+8-bit x 400MHz)
• SiS "MuLTIOL": 0.5GBps PCI (64-bit x 66MHz) + 1.0GBps HT (8+8-bit x 500MHz)
• ViA "V-Link": 0.5GBps PCI (64-bit x 66MHz)

Some systems (typically Intel / non-HyperTransport CPU) _may_ implement AGP3.0 with (2) PCI-Express x1 "ports" added to the legacy PCI slots. This will be done by just adding a "southbridge" chip with PCI-Express x1, while leaving the AGP-memory "northbridge."

In fact, there may _not_ actually be any PCI-Express "slots" on the board, and the (2) PCI-Express x1 "ports" will be used for the on-board GbE and SerialATA connections. That way, there is little design impact and additional cost over existing designs, while offering increased I/O throughput and reduced contention for network and storage.

HIGHER-END AND FUTURE:
PCI-EXPRESS x4 + (x) PCI-EXPRESS x1

PCI-Express itself is _very_ flexible. Vendors are free to bundle and unbundle additional PCI-Express "channels" as necessary. Although a PCI-Express x16 "port" in the "northbridge" (or HyperTransport "tunnel") and (2) PCI-Express x2 "ports" in the "southbridge" will be the most commodity, several vendors are already designing 20 "channels" in the northbridge already.

This opens up a couple of options.

High-end Workstation:

• (1) Graphics: 4.0GBps (2.0GB/dir) PCI-Express x16 "port" (north)
• (1) High-I/O: 1.0GBps (0.5GB/dir) PCI-Express x4 "port" (north)
• (2) Low-I/O: 250MBps (125MB/dir) PCI-Express x1 "ports" (south)
• (1) Legacy: 133MBps PCI bus and Legacy PC (LPC) (south)

The first two, 20 channels total, are located in a high-speed, 5GBps+ "northbridge" (or one 6.4GBps HyperTransport "tunnel"). The latter two are located in a slower-speed, ~0.5GBps "southbridge" (or one 0.8-1.0GBps HyperTransport "bridge").

The PCI-Express x4 "port" now becomes a PCI-X slot "replacement," removing additional costs to add the extra bandwidth for a 1GBps capable I/O card -- like a 2nd video interface, a high-speed storage device, etc...

This is in addition to the PCI-Express x16 for graphics, (2) PCI-Express x1 for other I/O (again, probably one for network, another for disk). Early systems will still have a good number of PCI slots (4-5) though, in addition to the other on-board PCI and legacy PC (LPC components).

Future Commodity Workstation:

• (1) Graphics: 4.0GBps (2.0GB/dir) PCI-Express x16 "port" (north)
• (4) Low-I/O: 250MBps (125MB/dir) PCI-Express x1 "ports" (north)
• (2) Low-I/O: 250MBps (125MB/dir) PCI-Express x1 "ports" (south)
• (1) Legacy: 133MBps PCI bus and Legacy PC (LPC) (south)

Now we're looking towards "replacing" PCI with PCI-Express. Instead of just a PCI-Express "port" or two, or used for on-board network and/or disk, we're starting to put lots of PCI-Express x1 "slots" on the mainboard. So we have maybe only a few (1-3) PCI slots next to (4) PCI-Express x1 "slots" that are available.

High-end Server:

• (5) High-I/O: 1.0GBps (0.5GB/dir) PCI-Express x4 "ports"
• (2) Low-I/O: 250MBps (125MB/dir) PCI-Express x1 "ports"
• (1) Legacy: 133MBps PCI bus and legacy PC (LPC)

In this configuration, we now have (7) PCI Express "ports" so the legacy PCI is probably just there for a few more components, or maybe a slot or two (if one or more of the PCI-Express x1 "ports" is hardwired to a network and/or disk). *OR* we could have:

• (4) High-I/O: 1.0GBps (0.5GB/dir) PCI-Express x4 "ports" (north)
• (4) Low-I/O: 250MBps (125MB/dir) PCI-Express x1 "ports" (north)
• (2) Low-I/O: 250MBps (125MB/dir) PCI-Express x1 "ports" (south)
• (1) Legacy: 133MBps PCI bus and legacy PC (LPC) (south)

Where we break one of the x4s on the northbridge down into (4) x1s, for a total of (6) x1s with the south. Now we have even more peripherial options, and can mix'n match what is connected to actual components on-mainboard, and how many PCI/PCI-Express "slots" we actually have.

And when it come to Opterons 4-way and higher systems, we start connecting two (2) 20 channel HyperTransport "tunnels." Now we've got at least 8 "High-I/O" PCI-Express x4 "ports" on two different CPUs (of the four)! This would be a common design for 12-slot, oversized mainboards in ultra-high-end servers.

PCI-Express is the ultimate flexibility to I/O. Combined with AMD's Scalable HyperTransport and Opteron 200/800 series, PCI-Express will only make I/O scale even more.