499 files changed, 12868 insertions, 17505 deletions
diff --git a/3D_with_free_drivers_and_low_power_consumption.mdwn b/3D_with_free_drivers_and_low_power_consumption.mdwn
new file mode 100644
index 0000000..3ab7479
--- /dev/null
+++ b/3D_with_free_drivers_and_low_power_consumption.mdwn
@@ -0,0 +1,19 @@
+
+
+# 3D with free drivers and low power consumption
+
+Chipsets and [[GraphicsCards|GraphicsCards]] supported by free drivers can be used without problems or restrictions if your system is updated. Free drivers normally improve from version to the next version; proprietary drivers could be instable if you update to a more recent version. Low power consumption helps to reduce costs, allows to build silent systems and helps to reduce CO2-emission. 
+
+
+## AGP Cards
+[[!table header="no" class="mointable" data="""
+ Card  |  Chipset  |  Max.Power  |  Idle Power  |  cooling  |  3D supported from ... 
+ HIS Radeon 9000  |  RV250  |  28 Watt  |   |  passive  |   radeon driver with x.org >=7.2 
+ HIS Radeon 9600  |  RV350  |  15 Watt  |   |  passive  |  ?? radeon driver with x.org >=?? 
+"""]]
+
+
+## PCI-E Cards
+
+
+## Notebook Chipsets
diff --git a/3D_with_free_drivers_and_low_power_consumption.moin b/3D_with_free_drivers_and_low_power_consumption.moin
deleted file mode 100644
index 36d1f41..0000000
--- a/3D_with_free_drivers_and_low_power_consumption.moin
+++ /dev/null
@@ -1,15 +0,0 @@
-= 3D with free drivers and low power consumption =
-
-Chipsets and GraphicsCards supported by free drivers can be used without problems or restrictions if your system is updated.
-Free drivers normally improve from version to the next version; proprietary drivers could be instable if you update to a more recent version.
-Low power consumption helps to reduce costs, allows to build silent systems and helps to reduce CO2-emission.
-
-== AGP Cards ==
-
-|| Card || Chipset || Max.Power || Idle Power || cooling || 3D supported from ... ||
-|| HIS Radeon 9000 || RV250 || 28 Watt || || passive ||  radeon driver with x.org >=7.2 ||
-|| HIS Radeon 9600 || RV350 || 15 Watt || || passive || ?? radeon driver with x.org >=?? ||
-
-== PCI-E Cards ==
-
-== Notebook Chipsets ==
diff --git a/3Dlabs.mdwn b/3Dlabs.mdwn
new file mode 100644
index 0000000..91fc383
--- /dev/null
+++ b/3Dlabs.mdwn
@@ -0,0 +1,32 @@
+
+
+# 3Dlabs
+
+**Chipsets** [[!map pages="^3Dlabs.+"]] 
+
+
+## Status
+
+Supported chipsets 
+
+   * MX/Gamma Chipset 
+Example graphics cards 
+
+   * Oxygen GMX 2000 
+Important notes: 
+
+   * [[IanRomanick|IanRomanick]] is planning to clean up the current driver and add support for the 500tx: [[announcement|http://dri.sourceforge.net/IRC-logs/20030908.txt]] from DRI IRC meeting.   
+   * Sven Luther also did some preliminary work for permedia chips.  That code is available on the tdlabs-0-0-1 branch in DRI CVS. 
+
+## Specifications
+
+
+## Resources
+
+   * [[3Dlabs homepage|http://www.3dlabs.com/]] 
+   * [[3Dlabs proprietary Linux drivers|http://www.3dlabs.com/support/drivers/index.htm#linux]] 
+
+
+---
+
+ [[CategoryHardwareVendor|CategoryHardwareVendor]] 
diff --git a/3Dlabs.moin b/3Dlabs.moin
deleted file mode 100644
index 3547a5b..0000000
--- a/3Dlabs.moin
+++ /dev/null
@@ -1,26 +0,0 @@
-= 3Dlabs =
-
-'''Chipsets'''
-<<PageList(^3Dlabs.+)>>
-
-== Status ==
-
-Supported chipsets
-  * MX/Gamma Chipset
-
-Example graphics cards
-  * Oxygen GMX 2000
-
-Important notes:
-  * IanRomanick is planning to clean up the current driver and add support for the 500tx: [[http://dri.sourceforge.net/IRC-logs/20030908.txt|announcement]] from DRI IRC meeting.  
-  * Sven Luther also did some preliminary work for permedia chips.  That code is available on the tdlabs-0-0-1 branch in DRI CVS.
-
-== Specifications ==
-
-== Resources ==
-
-  * [[http://www.3dlabs.com/|3Dlabs homepage]]
-  * [[http://www.3dlabs.com/support/drivers/index.htm#linux|3Dlabs proprietary Linux drivers]]
-
-----
-CategoryHardwareVendor
diff --git a/3dfx.mdwn b/3dfx.mdwn
new file mode 100644
index 0000000..3390d55
--- /dev/null
+++ b/3dfx.mdwn
@@ -0,0 +1,70 @@
+
+
+# 3dfx
+
+3dfx is the company that produced the Voodoo chipset, the first successful consumer 3D chipset for the PC. 
+
+
+## Status
+
+Supported cards 
+
+   * 3dfx Voodoo5 
+   * 3dfx Voodoo4 
+   * 3dfx Voodoo3 
+   * 3dfx Voodoo Banshee 
+   * Velocity 100/200 
+Unsupported Cards (2D only): 
+
+   * 3dfx Voodoo2 
+   * 3dfx Voodoo1 
+Voodoo1/Voodoo2 use Glide2 and very different interfaces to later cards.  While it is not impossible to write DRI modules for Voodoo1/2 the hardware is not designed for windowed 3D 
+
+Alan Cox has a glide-free XFree86 driver for Voodoo1/2 [[here|ftp://people.redhat.com/alan/XFree86/Voodoo]].  This driver has been integrated into Xorg. 
+
+Important notes: 
+
+   * 3dfx is now defunct. 
+   * Hardware acceleration is only supported at 16bpp on the Voodoo 3 and the Banshee. 
+   * 16bpp and 24bpp are supported on the Voodoo 5. 
+   * The driver lacks a current maintainer. 
+   * The driver needs significant work. 
+   * SLI is currently not supported. We are looking for volunteers to complete the SLI work. Note that this is quite difficult to complete. 
+   * AGP support in your kernel does not matter to the 3dfx driver, as it doesn't use AGP on Linux/BSD. 
+The tdfx driver uses the Glide library as a HAL, so that needs to be installed before building.  This should be supplied by your distribution, but if not the build process goes like this: 
+
+
+[[!format txt """
+cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/glide co -r glide-devel-branch Glide3
+cd Glide3
+./chores.3dfx --clean --generate
+./configure --help
+./configure # options here
+./build.3dfx
+su
+(enter root password)
+./build.3dfx install
+"""]]
+The Glide build is known to be touchy.  Gentoo users will want to say `export WANT_AUTOMAKE=1.7` before running `chores.3dfx`.  If this branch doesn't build for you, you may have better luck by checking out the Glide trunk by omitting `-r glide-devel-branch` from the `cvs` command.  You'll need `nasm` installed in order to get the optimized assembly code. 
+
+Good luck. 
+
+
+## Future work
+
+Glide is very fragile, and using it as a wrapper layer means that the tdfx driver doesn't look much like the other drivers at the source code level.  This makes the tdfx driver rather hard to maintain.  We should rewrite it to talk to the hardware directly. 
+
+Currently no one is working on this. 
+
+
+## Specifications
+
+You can get them at [[http://www.medex.hu/~danthe/tdfx/|http://www.medex.hu/~danthe/tdfx/]]. 
+
+**Note**: this link is now dead. It's mirrored on web.archive.org at: [[http://web.archive.org/web/20050311015540/http://www.medex.hu/~danthe/tdfx/|http://web.archive.org/web/20050311015540/http://www.medex.hu/~danthe/tdfx/]]. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]], [[CategoryHardwareVendor|CategoryHardwareVendor]] 
diff --git a/3dfx.moin b/3dfx.moin
deleted file mode 100644
index 4632549..0000000
--- a/3dfx.moin
+++ /dev/null
@@ -1,63 +0,0 @@
-= 3dfx =
-
-3dfx is the company that produced the Voodoo chipset, the first successful
-consumer 3D chipset for the PC.
-
-== Status ==
-
-Supported cards
-  * 3dfx Voodoo5
-  * 3dfx Voodoo4
-  * 3dfx Voodoo3
-  * 3dfx Voodoo Banshee
-  * Velocity 100/200
-
-Unsupported Cards (2D only):
-  * 3dfx Voodoo2
-  * 3dfx Voodoo1
-
-Voodoo1/Voodoo2 use Glide2 and very different interfaces to later cards.  While it is not impossible to write DRI modules for Voodoo1/2 the hardware is not designed for windowed 3D
-
-Alan Cox has a glide-free XFree86 driver for Voodoo1/2 [[ftp://people.redhat.com/alan/XFree86/Voodoo|here]].  This driver has been integrated into Xorg.
-
-Important notes:
-  * 3dfx is now defunct.
-  * Hardware acceleration is only supported at 16bpp on the Voodoo 3 and the Banshee.
-  * 16bpp and 24bpp are supported on the Voodoo 5.
-  * The driver lacks a current maintainer.
-  * The driver needs significant work.
-  * SLI is currently not supported. We are looking for volunteers to complete the SLI work. Note that this is quite difficult to complete.
-  * AGP support in your kernel does not matter to the 3dfx driver, as it doesn't use AGP on Linux/BSD.
-
-The tdfx driver uses the Glide library as a HAL, so that needs to be installed before building.  This should be supplied by your distribution, but if not the build process goes like this:
-
-{{{
-cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/glide co -r glide-devel-branch Glide3
-cd Glide3
-./chores.3dfx --clean --generate
-./configure --help
-./configure # options here
-./build.3dfx
-su
-(enter root password)
-./build.3dfx install
-}}}
-
-The Glide build is known to be touchy.  Gentoo users will want to say `export WANT_AUTOMAKE=1.7` before running `chores.3dfx`.  If this branch doesn't build for you, you may have better luck by checking out the Glide trunk by omitting `-r glide-devel-branch` from the `cvs` command.  You'll need `nasm` installed in order to get the optimized assembly code.
-
-Good luck.
-
-== Future work ==
-
-Glide is very fragile, and using it as a wrapper layer means that the tdfx driver doesn't look much like the other drivers at the source code level.  This makes the tdfx driver rather hard to maintain.  We should rewrite it to talk to the hardware directly.
-
-Currently no one is working on this.
-
-== Specifications ==
-
-You can get them at http://www.medex.hu/~danthe/tdfx/.
-
-'''Note''': this link is now dead. It's mirrored on web.archive.org at: http://web.archive.org/web/20050311015540/http://www.medex.hu/~danthe/tdfx/.
-
-----
-CategoryGlossary, CategoryHardwareVendor
diff --git a/AGP.mdwn b/AGP.mdwn
new file mode 100644
index 0000000..14d530a
--- /dev/null
+++ b/AGP.mdwn
@@ -0,0 +1,104 @@
+
+
+# Accelerated Graphics Port (AGP)
+
+AGP is a dedicated high-speed bus that allows the graphics controller to fetch large amounts of data directly from system memory. It uses a Graphics Address Re-Mapping Table (GART) to provide a physically-contiguous view of scattered pages in system memory for DMA transfers. 
+
+With AGP, main memory is specifically used for advanced three-dimensional features, such as textures, alpha buffers, and ZBuffer``s. 
+
+There are two primary AGP usage models for 3D rendering that have to do with how data are partitioned and accessed, and the resultant interface data flow characteristics. 
+DMA
+: In the DMA model, the primary graphics memory is the local memory associated with the accelerator, referred to as the local frame buffer. 3D structures are stored in system memory, but are not used (or executed) directly from this memory; rather they are copied to primary (local) memory (the DMA operation) to which the rendering engine's address generator makes its references. This implies that the traffic on the AGP tends to be long, sequential transfers, serving the purpose of bulk data transport from system memory to primary graphics (local) memory. This sort of access model is amenable to a linked list of physical addresses provided by software (similar to the operation of a disk or network I/O device), and is generally not sensitive to a non-contiguous view of the memory space. 
+
+execute
+: In the execute model, the accelerator uses both the local memory and the system memory as primary graphics memory. From the accelerator's perspective, the two memory systems are logically equivalent; any data structure may be allocated in either memory, with performance optimization as the only criterion for selection. In general, structures in system memory space are not copied into the local memory prior to use by the accelerator, but are executed in place. This implies that the traffic on the AGP tends to be short, random accesses, which are not amenable to an access model based on software resolved lists of physical addresses. Because the accelerator generates direct references into system memory, a contiguous view of that space is essential; however, since system memory is dynamically allocated in random 4K pages, it is necessary in the execute model to provide an address mapping mechanism that maps random 4K pages into a single contiguous, physical address space. 
+
+
+**Note:** The AGP supports both the DMA and the execute model. However, since a primary motivation of the AGP is to reduce growth pressure on local memory, the execute model is the design focus. 
+
+AGP also allows to issue several access requests in a pipelined fashion while waiting for the data transfers to occur. Such pipelining of access requests results in having several read and/or write requests outstanding in the corelogic's request queue at any point in time. 
+
+
+## Resources
+
+   * [[AGP Technology Home|http://www.intel.com/technology/agp/index.htm]] 
+   * [[AGP Implementors Forum Q&A|http://www.agpforum.org/faq_ans.htm]] Link changed, [[archived version|http://web.archive.org/web/20021214224953/http://www.agpforum.org/faq_ans.htm]] 
+   * [[AGP Specification 2.0|http://www.intel.com/technology/agp/agp_index.htm]] Link changed, [[try this one|http://esd.cs.ucr.edu/webres/agp20.pdf]] 
+   * [[AGP 3.0 v1.0 spec|http://www.playtool.com/pages/agpcompat/agp30.pdf]] 
+
+## Frequently Asked Questions
+
+
+### Why not use the existing XFree86 AGP manipulation calls?
+
+You have to understand that the DRI functions have a different purpose than the ones in XFree86. The DRM has to know about AGP, so it talks to the AGP kernel module itself. It has to be able to protect certain regions of AGP memory from the client side 3D drivers, yet it has to export some regions of it as well. While most of this functionality (most, not all) can be accomplished with the `/dev/agpgart` interface, it makes sense to use the DRM's current authentication mechanism. This means that there is less complexity on the client side. If we used `/dev/agpgart`, then the client would have to open two devices, authenticate to both of them, and make half a dozen calls to agpgart, and only then care about the DRM device. 
+
+**Note:** As a side note, the XFree86 calls were written after the DRM functions. 
+
+Also to answer a previous question about not using XFree86 calls for memory mapping, you have to understand that under most OS's (probably Solaris as well), XFree86's functions will only work for root privileged processes. The whole point of the DRI is to allow processes that can connect to the X server to do some form of direct to hardware rendering. If we limited ourselves to using XFree86's functionality, we would not be able to do this. We don't want everyone to be root. 
+
+
+### How do I use AGP?
+
+You can also use [[this|http://dri.sourceforge.net/res/testgart.c]] test program as a bit more documentation as to how agpgart is used. 
+
+
+### How to allocate AGP memory?
+
+Generally programs do the following: 
+
+   1. open `/dev/agpgart` 
+   1. `ioctl(ACQUIRE)` 
+   1. `ioctl(INFO)` to determine amount of memory for AGP 
+   1. mmap the device 
+   1. `ioctl(SETUP)` to set the AGP mode 
+   1. `ioctl(ALLOCATE)` a chunk o memory, specifying offset in aperture 
+   1. `ioctl(BIND)` that same chunk o memory 
+Every time you update the GART, you have to flush the cache and/or TLB's. This is expensive. Therefore, you allocate and bind the pages you'll use, and `mmap()` just returns the right pages when needed. 
+
+Then you need to have a remap of the AGP aperture in the kernel which you can access. Use ioremap to do that. 
+
+After that you have access to the AGP memory. You probably want to make sure that there is a write-combining MTRR over the aperture. There is code in `mga_drv.c` in our kernel directory that shows you how to do that. 
+
+
+### If one has to insert pages in order to check for -EBUSY errors and loop through the entire GART, wouldn't it be better if the driver filled up ''pg_start'' of the ''agp_bind'' structure instead of the user filling it up?
+
+All this allocation should be done by only one process. If you need memory in the GART you should be asking the X server for it (or whatever your controlling process is). Things are implemented this way so that the controlling process can know intimate details of how memory is laid out. This is very important for the I810, since you want to set tiled memory on certain regions of the aperture. If you made the kernel do the layout, then you would have to create device specific code in the kernel to make sure that the backbuffer/dcache are aligned for tiled memory. This adds complexity to the kernel that doesn't need to be there, and imposes restrictions on what you can do with AGP memory. Also, the current X server implementation (4.0) actually locks out other applications from adding to the GART. While the X server is active, the X server is the only one who can add memory. Only the controlling process may add things to the GART, and while a controlling process is active, no other application can be the controlling process. 
+
+Microsoft's VGART does things like you are describing I believe. I think it's bad design. It enforces a policy on whoever uses it, and is not flexible. When you are designing low level system routines I think it is very important to make sure your design has the minimum of policy. Otherwise when you want to do something different you have to change the interface, or create custom drivers for each application that needs to do things differently. 
+
+
+### How does the DMA transfer mechanism works?
+
+Here's a proposal for an zero-ioctl (best case) DMA transfer mechanism. 
+
+Let's call it 'kernel ringbuffers'. The premise is to replace the calls to the 'fire-vertex-buffer' ioctl with code to write to a client-private mapping shared by the kernel (like the current SAREA, but for each client). 
+
+Starting from the beginning: 
+
+   * Each client has a private piece of AGP memory, into which it will put secure commands (typically vertices and texture data). The client may expand or shrink this region according to load. 
+   * Each client has a shared user/kernel region of cached memory. (Per-context SAREA). This is managed like a ring, with head and tail pointers. 
+   * The client emits vertices to AGP memory (as it currently does with DMA buffers). 
+   * When a state change, clear, swap, flush, or other event occurs, the client:Grabs the hardware lock.Re-emits any invalidated state to the head of the ring.Emits a command to fire the portion of AGP space as vertices.Updates the head pointer in the ring.Releases the lock. 
+   * The kernel is responsible for processing all of the rings. Several events might cause the kernel to examine active rings for commands to be dispatched: 
+         * A flush ioctl. (Called by impatient clients) 
+         * A periodic timer. (If this is low overhead?) 
+         * An interrupt previously emitted by the kernel. (If timers don't work) 
+Additionally, for those who've been paying attention, you'll notice that some of the assumptions that we currently use to manage hardware state between multiple active contexts are broken if client commands to hardware aren't executed serially in an order which is knowable to the clients. Otherwise, a client that grabs the heavy lock doesn't know what state has been invalidated or textures swapped out by other clients. 
+
+This could be solved by keeping per-context state in the kernel and implementing a proper texture manager. That's something we need to do anyway, but it's not a requirement for this mechanism to work. 
+
+Instead, force the kernel to fire all outstanding commands on client ringbuffers whenever the heavyweight lock changes hands. This provides the same serialized semantics as the current mechanism, and also simplifies the kernel's task as it knows that only a single context has an active ring buffer (the one last to hold the lock). 
+
+An additional mechanism is required to allow clients to know which pieces of their AGP buffer is pending execution by the hardware, and which pieces of the buffer are available to be reused. This is also exactly what _NV_vertex_array_range_ requires. 
+
+
+# Kernel patches
+
+Kernel patch to get AGP 8X working on a VIA KT400. The patch is for a 2.4.21pre5 but patches, compiles and runs perfectly in a 2.4.21. This patch is needed for this chipset because it works **only** in 8X when you plug a 8X card. 
+
+* [[Linux Kernel Mailing List|http://lists.insecure.org/lists/linux-kernel/2003/Mar/3999.html]] 
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]], [[CategoryFaq|CategoryFaq]] 
diff --git a/AGP.moin b/AGP.moin
deleted file mode 100644
index cac7940..0000000
--- a/AGP.moin
+++ /dev/null
@@ -1,192 +0,0 @@
-= Accelerated Graphics Port (AGP) =
- 
-AGP is a dedicated high-speed bus that allows the graphics controller to fetch
-large amounts of data directly from system memory. It uses a Graphics Address
-Re-Mapping Table (GART) to provide a physically-contiguous view of scattered
-pages in system memory for DMA transfers.
- 
-With AGP, main memory is specifically used for advanced three-dimensional
-features, such as textures, alpha buffers, and ZBuffer``s.
- 
-There are two primary AGP usage models for 3D rendering that have to do with
-how data are partitioned and accessed, and the resultant interface data
-flow characteristics.
- 
- DMA:: In the DMA model, the primary graphics memory is the local memory
- associated with the accelerator, referred to as the local frame buffer. 3D
- structures are stored in system memory, but are not used (or executed)
- directly from this memory; rather they are copied to primary (local) memory
- (the DMA operation) to which the rendering engine's address generator makes its
- references. This implies that the traffic on the AGP tends to be long,
- sequential transfers, serving the purpose of bulk data transport from system
- memory to primary graphics (local) memory. This sort of access model is
- amenable to a linked list of physical addresses provided by software (similar
- to the operation of a disk or network I/O device), and is generally not sensitive
- to a non-contiguous view of the memory space.
- 
- execute:: In the execute model, the accelerator uses both the local memory and
- the system memory as primary graphics memory. From the accelerator's
- perspective, the two memory systems are logically equivalent; any data
- structure may be allocated in either memory, with performance optimization as
- the only criterion for selection. In general, structures in system memory space
- are not copied into the local memory prior to use by the accelerator, but are
- executed in place. This implies that the traffic on the AGP tends to be
- short, random accesses, which are not amenable to an access model based on
- software resolved lists of physical addresses. Because the accelerator
- generates direct references into system memory, a contiguous view of that space
- is essential; however, since system memory is dynamically allocated in random
- 4K pages, it is necessary in the execute model to provide an address mapping
- mechanism that maps random 4K pages into a single contiguous, physical address
- space.
- 
-'''Note:''' The AGP supports both the DMA and the execute model. However, since
-a primary motivation of the AGP is to reduce growth pressure on local memory,
-the execute model is the design focus.
- 
-AGP also allows to issue several access requests in a pipelined fashion while
-waiting for the data transfers to occur. Such pipelining of access requests results
-in having several read and/or write requests outstanding in the corelogic's
-request queue at any point in time.
- 
-== Resources ==
- 
-  * [[http://www.intel.com/technology/agp/index.htm|AGP Technology Home]]
-  * [[http://www.agpforum.org/faq_ans.htm|AGP Implementors Forum Q&A]]
-  Link changed, [[ http://web.archive.org/web/20021214224953/http://www.agpforum.org/faq_ans.htm | archived version]]
-  * [[http://www.intel.com/technology/agp/agp_index.htm|AGP Specification 2.0]]
-  Link changed, [[http://esd.cs.ucr.edu/webres/agp20.pdf| try this one]]
-  * [[http://www.playtool.com/pages/agpcompat/agp30.pdf | AGP 3.0 v1.0 spec]]
- 
-== Frequently Asked Questions ==
- 
-=== Why not use the existing XFree86 AGP manipulation calls? ===
- 
-You have to understand that the DRI functions have a different purpose than the
-ones in XFree86. The DRM has to know about AGP, so it talks to the AGP kernel
-module itself. It has to be able to protect certain regions of AGP memory from
-the client side 3D drivers, yet it has to export some regions of it as well.
-While most of this functionality (most, not all) can be accomplished with the
-`/dev/agpgart` interface, it makes sense to use the DRM's current
-authentication mechanism. This means that there is less complexity on the
-client side. If we used `/dev/agpgart`, then the client would have to open two
-devices, authenticate to both of them, and make half a dozen calls to agpgart,
-and only then care about the DRM device.
- 
-'''Note:''' As a side note, the XFree86 calls were written after the DRM
-functions.
- 
- 
-Also to answer a previous question about not using XFree86 calls for memory
-mapping, you have to understand that under most OS's (probably Solaris as well),
-XFree86's functions will only work for root privileged processes. The whole
-point of the DRI is to allow processes that can connect to the X server to do
-some form of direct to hardware rendering. If we limited ourselves to using
-XFree86's functionality, we would not be able to do this. We don't want
-everyone to be root.
- 
-=== How do I use AGP? ===
- 
-You can also use [[http://dri.sourceforge.net/res/testgart.c|this]] test program
-as a bit more documentation as to how agpgart is used.
- 
-=== How to allocate AGP memory? ===
- 
-Generally programs do the following:
- 
-  1. open `/dev/agpgart`
-  1. `ioctl(ACQUIRE)`
-  1. `ioctl(INFO)` to determine amount of memory for AGP
-  1. mmap the device
-  1. `ioctl(SETUP)` to set the AGP mode
-  1. `ioctl(ALLOCATE)` a chunk o memory, specifying offset in aperture
-  1. `ioctl(BIND)` that same chunk o memory
- 
-Every time you update the GART, you have to flush the cache and/or TLB's. This
-is expensive. Therefore, you allocate and bind the pages you'll use, and `mmap()`
-just returns the right pages when needed.
- 
-Then you need to have a remap of the AGP aperture in the kernel which you can
-access. Use ioremap to do that.
- 
-After that you have access to the AGP memory. You probably want to make sure
-that there is a write-combining MTRR over the aperture. There is code in
-`mga_drv.c` in our kernel directory that shows you how to do that.
- 
-=== If one has to insert pages in order to check for -EBUSY errors and loop through the entire GART, wouldn't it be better if the driver filled up ''pg_start'' of the ''agp_bind'' structure instead of the user filling it up? ===
- 
-All this allocation should be done by only one process. If you need memory in
-the GART you should be asking the X server for it (or whatever your controlling
-process is). Things are implemented this way so that the controlling process
-can know intimate details of how memory is laid out. This is very important for
-the I810, since you want to set tiled memory on certain regions of the
-aperture. If you made the kernel do the layout, then you would have to create
-device specific code in the kernel to make sure that the backbuffer/dcache are
-aligned for tiled memory. This adds complexity to the kernel that doesn't need
-to be there, and imposes restrictions on what you can do with AGP memory. Also,
-the current X server implementation (4.0) actually locks out other applications
-from adding to the GART. While the X server is active, the X server is the only
-one who can add memory. Only the controlling process may add things to the GART,
-and while a controlling process is active, no other application can be the
-controlling process.
- 
-Microsoft's VGART does things like you are describing I believe. I think it's
-bad design. It enforces a policy on whoever uses it, and is not flexible. When
-you are designing low level system routines I think it is very important to
-make sure your design has the minimum of policy. Otherwise when you want to do
-something different you have to change the interface, or create custom drivers
-for each application that needs to do things differently.
- 
-=== How does the DMA transfer mechanism works? ===
- 
-Here's a proposal for an zero-ioctl (best case) DMA transfer mechanism.
- 
-Let's call it 'kernel ringbuffers'. The premise is to replace the calls to the
-'fire-vertex-buffer' ioctl with code to write to a client-private mapping
-shared by the kernel (like the current SAREA, but for each client).
- 
-Starting from the beginning:
- 
-  * Each client has a private piece of AGP memory, into which it will put secure commands (typically vertices and texture data). The client may expand or shrink this region according to load.
- 
-  * Each client has a shared user/kernel region of cached memory. (Per-context SAREA). This is managed like a ring, with head and tail pointers.
-  * The client emits vertices to AGP memory (as it currently does with DMA buffers).
- 
-  * When a state change, clear, swap, flush, or other event occurs, the client:Grabs the hardware lock.Re-emits any invalidated state to the head of the ring.Emits a command to fire the portion of AGP space as vertices.Updates the head pointer in the ring.Releases the lock.
- 
-  * The kernel is responsible for processing all of the rings. Several events might cause the kernel to examine active rings for commands to be dispatched:
- 
-    * A flush ioctl. (Called by impatient clients)
- 
-    * A periodic timer. (If this is low overhead?)
- 
-    * An interrupt previously emitted by the kernel. (If timers don't work)
- 
-Additionally, for those who've been paying attention, you'll notice that some
-of the assumptions that we currently use to manage hardware state between
-multiple active contexts are broken if client commands to hardware aren't
-executed serially in an order which is knowable to the clients. Otherwise, a
-client that grabs the heavy lock doesn't know what state has been invalidated
-or textures swapped out by other clients.
- 
-This could be solved by keeping per-context state in the kernel and
-implementing a proper texture manager. That's something we need to do anyway,
-but it's not a requirement for this mechanism to work.
- 
-Instead, force the kernel to fire all outstanding commands on client
-ringbuffers whenever the heavyweight lock changes hands. This provides the same
-serialized semantics as the current mechanism, and also simplifies the kernel's
-task as it knows that only a single context has an active ring buffer (the one
-last to hold the lock).
- 
-An additional mechanism is required to allow clients to know which pieces of
-their AGP buffer is pending execution by the hardware, and which pieces of the
-buffer are available to be reused. This is also exactly what
-''NV_vertex_array_range'' requires.
- 
-= Kernel patches =
- 
-Kernel patch to get AGP 8X working on a VIA KT400. The patch is for a 2.4.21pre5 but patches, compiles and runs perfectly in a 2.4.21. This patch is needed for this chipset because it works '''only''' in 8X when you plug a 8X card.
- 
-* [[http://lists.insecure.org/lists/linux-kernel/2003/Mar/3999.html|Linux Kernel Mailing List]]
-----
-CategoryGlossary, CategoryFaq
diff --git a/AGPBenchmarks.moin b/AGPBenchmarks.mdwn
index 05fcea0..996d931 100644
--- a/AGPBenchmarks.moin
+++ b/AGPBenchmarks.mdwn
@@ -1,91 +1,91 @@
-The effect of AGP settings on 3d performance comes up often, and I've always told people not to bother with tweaking AGP since it doesn't matter.  But I realized I should really make sure that what I say is true.  So, I've benchmarked a couple of things with AGP at 1x and 4x.  I chose quake3, since it's an old standby and I've got scripts for it, and ipers, since it's very vertex-dispatch intensive (though vtxfmt fallbacks may be hurting it a lot these days and making it a less useful test).  The machine was a P4 running at 1Ghz with a Radeon 64MB VIVO, with Options "AGPMode" "4" vs not in the xorg.conf.  Drivers were Mesa CVS as of around 2004-11-01. 
-
-Quake3 (640x480, defaults, running demofour script from idr):
-{{{
-x 1x
-+ 4x
-+--------------------------------------------------------------------------+
-|          x                                                   +          +|
-|x         x          x                              +         +          +|
-|   |______A_______|                                     |_____M_A________||
-+--------------------------------------------------------------------------+
-    N           Min           Max        Median           Avg        Stddev
-x   5         127.2         127.4         127.3         127.3   0.070710678
-+   5         127.7         127.9         127.8        127.82   0.083666003
-Difference at 95.0% confidence
-        0.52 +/- 0.11297
-        0.408484% +/- 0.0887435%
-        (Student's t, pooled s = 0.0774597)
-}}}
-
-So, there was a 0.4% improvement by going to AGP 4x.  However, what about the thrashing case?  I hacked the DDX to only allocate 1MB for on-card textures and re-ran the test.  (Note that with the default allocation of 8MB of AGP memory, this means I've got 5MB of space for textures available).
-
-{{{
-x 1x-1M
-+ 4x-1M
-+--------------------------------------------------------------------------+
-|x                                                                        +|
-|x                                                                        +|
-|x                                                                        +|
-|x                                                                        +|
-|A                                                                        A|
-+--------------------------------------------------------------------------+
-    N           Min           Max        Median           Avg        Stddev
-x   4          96.4          96.4          96.4          96.4             0
-+   4         125.3         125.4         125.4       125.375          0.05
-Difference at 95.0% confidence
-        28.975 +/- 0.061175
-        30.0571% +/- 0.0634595%
-        (Student's t, pooled s = 0.0353553)
-}}}
-
-A 30% difference in a serious texture thrashing case.  OK, interesting.  I dropped the first run of each of them because they were clearly outliers.  I can't explain why, but check the next test.  I used the RADEON_GARTTEXTURING_FORCE_DISABLE environment variable to disable GART texturing and re-ran, while at the 1M on-card texture size.
-
-{{{
-x 1x-1M-noagptex
-+ 4x-1M-noagptex
-+--------------------------------------------------------------------------+
-|x                                                                       + |
-|xx                                                                      ++|
-|xx                                                                      ++|
-|A|                                                                      A||
-+--------------------------------------------------------------------------+
-    N           Min           Max        Median           Avg        Stddev
-x   5          52.2          52.3          52.2         52.24   0.054772256
-+   5          60.3          60.4          60.3         60.34   0.054772256
-Difference at 95.0% confidence
-        8.1 +/- 0.0798822
-        15.5054% +/- 0.152914%
-        (Student's t, pooled s = 0.0547723)
-}}}
-
-Interestingly, these framerates are just what the outliers on the first runs of the previous test were.  Perhaps we've got a bug, where the first client doesn't get AGP texturing?   Odd, but possible.  Anyway, with no AGP texturing, we're seeing a 15% performance improvement from increased AGP speeds, probably because textures are being uploaded to the card as hostdata blits (the texture data is written to the command ring which is in AGP space, and sent to the card that way).
-
-How about the case of using AGP textures, with the card space being limited but AGP space being relatively large?  I set Options "AGPSize" "64", giving me 61M of AGP texture space.
-
-{{{
-x 1x-1M-61Magp
-+ 4x-1M-61Magp
-+--------------------------------------------------------------------------+
-|x                                                                        +|
-|x                                                                        +|
-|x                                                                        +|
-|x                                                                        +|
-|A                                                                        A|
-+--------------------------------------------------------------------------+
-    N           Min           Max        Median           Avg        Stddev
-x   4          95.4          95.4          95.4          95.4             0
-+   4         125.4         125.5         125.5        125.45   0.057735027
-Difference at 95.0% confidence
-        30.05 +/- 0.0706388
-        31.499% +/- 0.0740449%
-        (Student's t, pooled s = 0.0408248)
-}}}
-
-Again, I threw out the first run of each test for being outliers.  A 31% performance improvement, so I probably wasn't thrashing when I was running with AGP the first time.
-
-Unfortunately, ipers doesn't have any reporting mechanism, and its measurement is too imprecise to say much.  However, both at 1x and 4x the framerate flipped between 12.50 and 14.29 fps.
-
-It appears that for normal usage on cards where you aren't significantly restricted in terms of local memory, 4x AGP buys you almost nothing (.4%).  If you're needing to grab nearly all of your textures from AGP, it can be a performance improvement of as much as 30%, and it can improve texture upload performance to card memory sufficiently for a 15% improvement when that's made to be a bottleneck.
-
--- EricAnholt
+
+The effect of AGP settings on 3d performance comes up often, and I've always told people not to bother with tweaking AGP since it doesn't matter.  But I realized I should really make sure that what I say is true.  So, I've benchmarked a couple of things with AGP at 1x and 4x.  I chose quake3, since it's an old standby and I've got scripts for it, and ipers, since it's very vertex-dispatch intensive (though vtxfmt fallbacks may be hurting it a lot these days and making it a less useful test).  The machine was a P4 running at 1Ghz with a Radeon 64MB VIVO, with Options "AGPMode" "4" vs not in the xorg.conf.  Drivers were Mesa CVS as of around 2004-11-01.  
+
+Quake3 (640x480, defaults, running demofour script from idr): 
+[[!format txt """
+x 1x
++ 4x
++--------------------------------------------------------------------------+
+|          x                                                   +          +|
+|x         x          x                              +         +          +|
+|   |______A_______|                                     |_____M_A________||
++--------------------------------------------------------------------------+
+    N           Min           Max        Median           Avg        Stddev
+x   5         127.2         127.4         127.3         127.3   0.070710678
++   5         127.7         127.9         127.8        127.82   0.083666003
+Difference at 95.0% confidence
+        0.52 +/- 0.11297
+        0.408484% +/- 0.0887435%
+        (Student's t, pooled s = 0.0774597)
+"""]]
+So, there was a 0.4% improvement by going to AGP 4x.  However, what about the thrashing case?  I hacked the DDX to only allocate 1MB for on-card textures and re-ran the test.  (Note that with the default allocation of 8MB of AGP memory, this means I've got 5MB of space for textures available). 
+
+
+[[!format txt """
+x 1x-1M
++ 4x-1M
++--------------------------------------------------------------------------+
+|x                                                                        +|
+|x                                                                        +|
+|x                                                                        +|
+|x                                                                        +|
+|A                                                                        A|
++--------------------------------------------------------------------------+
+    N           Min           Max        Median           Avg        Stddev
+x   4          96.4          96.4          96.4          96.4             0
++   4         125.3         125.4         125.4       125.375          0.05
+Difference at 95.0% confidence
+        28.975 +/- 0.061175
+        30.0571% +/- 0.0634595%
+        (Student's t, pooled s = 0.0353553)
+"""]]
+A 30% difference in a serious texture thrashing case.  OK, interesting.  I dropped the first run of each of them because they were clearly outliers.  I can't explain why, but check the next test.  I used the RADEON_GARTTEXTURING_FORCE_DISABLE environment variable to disable GART texturing and re-ran, while at the 1M on-card texture size. 
+
+
+[[!format txt """
+x 1x-1M-noagptex
++ 4x-1M-noagptex
++--------------------------------------------------------------------------+
+|x                                                                       + |
+|xx                                                                      ++|
+|xx                                                                      ++|
+|A|                                                                      A||
++--------------------------------------------------------------------------+
+    N           Min           Max        Median           Avg        Stddev
+x   5          52.2          52.3          52.2         52.24   0.054772256
++   5          60.3          60.4          60.3         60.34   0.054772256
+Difference at 95.0% confidence
+        8.1 +/- 0.0798822
+        15.5054% +/- 0.152914%
+        (Student's t, pooled s = 0.0547723)
+"""]]
+Interestingly, these framerates are just what the outliers on the first runs of the previous test were.  Perhaps we've got a bug, where the first client doesn't get AGP texturing?   Odd, but possible.  Anyway, with no AGP texturing, we're seeing a 15% performance improvement from increased AGP speeds, probably because textures are being uploaded to the card as hostdata blits (the texture data is written to the command ring which is in AGP space, and sent to the card that way). 
+
+How about the case of using AGP textures, with the card space being limited but AGP space being relatively large?  I set Options "AGPSize" "64", giving me 61M of AGP texture space. 
+
+
+[[!format txt """
+x 1x-1M-61Magp
++ 4x-1M-61Magp
++--------------------------------------------------------------------------+
+|x                                                                        +|
+|x                                                                        +|
+|x                                                                        +|
+|x                                                                        +|
+|A                                                                        A|
++--------------------------------------------------------------------------+
+    N           Min           Max        Median           Avg        Stddev
+x   4          95.4          95.4          95.4          95.4             0
++   4         125.4         125.5         125.5        125.45   0.057735027
+Difference at 95.0% confidence
+        30.05 +/- 0.0706388
+        31.499% +/- 0.0740449%
+        (Student's t, pooled s = 0.0408248)
+"""]]
+Again, I threw out the first run of each test for being outliers.  A 31% performance improvement, so I probably wasn't thrashing when I was running with AGP the first time. 
+
+Unfortunately, ipers doesn't have any reporting mechanism, and its measurement is too imprecise to say much.  However, both at 1x and 4x the framerate flipped between 12.50 and 14.29 fps. 
+
+It appears that for normal usage on cards where you aren't significantly restricted in terms of local memory, 4x AGP buys you almost nothing (.4%).  If you're needing to grab nearly all of your textures from AGP, it can be a performance improvement of as much as 30%, and it can improve texture upload performance to card memory sufficiently for a 15% improvement when that's made to be a bottleneck. 
+
+-- [[EricAnholt|EricAnholt]] 
diff --git a/AMD.mdwn b/AMD.mdwn
new file mode 100644
index 0000000..1f1fdce
--- /dev/null
+++ b/AMD.mdwn
@@ -0,0 +1,65 @@
+
+
+# Advanced Micro Devices, Inc. (formerly ATI Technologies Inc.)
+
+
+## Status
+
+Supported chipsets: 
+
+   * [[Mach64|ATIMach64]] (Rage Pro) 
+   * [[Rage 128|ATIRage128]] (Standard, Pro, Mobility) 
+   * [[Radeon|ATIRadeon]] up to HD 5970-series (i.e. Radeon SDR/DDR, Radeon 7000-9800, and Radeon X300-X1250, Radeon X1300 - X1950, Radeon HD 2000 - HD 5970 are supported) 
+Important notes: 
+
+   * The [[Radeon naming scheme|http://dri.sourceforge.net/doc/radeon_naming.phtml]] explained. 
+   * For Radeon PCI support see the FAQ. 
+   * Rage Fury Maxx is NOT supported by the DRI. 
+   * The Radeon seems to have problems with certain early VIA chipsets. Your best bet is to try and see if it works. 
+   * 3D support for the Radeon 9500-9800 (R300 series), X300-X850 (R400 series) and X1300 - X1950 (R500 series) is via the r300_dri driver. For the HD series, 3D support is provided in the r600 driver, and there is both the classic DRI driver and Gallium driver in development. The stability has improved a lot since 2008, thanks to specifications released by AMD also for their (ATI's) older chipsets. 
+   * R500 series support is available in Mesa 7.0.4 release or newer 
+   * Radeon HD 6000 (R800) series does not yet have DRI 3D driver, see below for information about the specifications being released by AMD 
+Example graphics cards: 
+
+   * Radeon HD 4670 
+   * Radeon X1650 
+   * Radeon X700 
+   * Radeon 8500 
+   * Rage Fury 
+   * Rage Magnum 
+   * Xpert 2000 
+   * Xpert 128 
+   * Xpert 99 
+   * All-in-Wonder 128 
+
+### TVOut
+
+Check the [[radeonTV|http://www.x.org/wiki/radeonTV]] page at wiki.x.org for information about how TV-Out (and TV capture) for ATI cards got to official X.org drivers from the [[GATOS|http://gatos.sourceforge.net/]] project. TV-Out may now be enabled using Randr 1.2 ("xrandr" utility) for supported cards, by eg: 
+
+1. xrandr --addmode S-video 800x600 
+1. xrandr --output S-video --mode 800x600 
+1. xrandr --output S-video --set tv_standard ntsc 
+
+## Specifications
+
+
+### History
+
+ATI had a 'developer program'. Specifications of all ATI chips up to the Radeon 9200 were made available to DRI developers under NDA on an individual case basis. Please read carefully the NDA page before you consider applying. 
+
+
+### Currently
+
+For R500, R600, R700 and R800 (Radeon X1000- HD 6000 series) AMD/ATI has had a habit of releasing specifications from basic mode-setting all the way to shaders. AMD is also funding developers to develop fully open drivers "radeon" (X.Org DDX driver), "r300" and "r600" (Mesa 3D drivers and kernel DRM drivers) using the specifications together with the community, see for example [[http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati;a=summary|http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati;a=summary]] . 
+
+
+## Resources
+
+   * [[ATI homepage|http://www.ati.com/]] 
+   * [[ATI's Linux and XFree86 information|http://www.ati.com/support/faq/linux.html]] 
+   * [[ATI's proprietary Linux drivers|http://www.ati.com/support/driver.html]] 
+
+
+---
+
+ [[CategoryHardwareVendor|CategoryHardwareVendor]] [[TitleIndex|TitleIndex]] 
diff --git a/AMD.moin b/AMD.moin
deleted file mode 100644
index 60553e7..0000000
--- a/AMD.moin
+++ /dev/null
@@ -1,58 +0,0 @@
-= Advanced Micro Devices, Inc. (formerly ATI Technologies Inc.) =
-
-== Status ==
-
-Supported chipsets:
-  * [[ATIMach64| Mach64]] (Rage Pro)
-  * [[ATIRage128| Rage 128]] (Standard, Pro, Mobility)
-  * [[ATIRadeon| Radeon]] up to HD 5970-series (i.e. Radeon SDR/DDR, Radeon 7000-9800, and Radeon X300-X1250, Radeon X1300 - X1950, Radeon HD 2000 - HD 5970 are supported)
-
-Important notes:
-  * The [[http://dri.sourceforge.net/doc/radeon_naming.phtml|Radeon naming scheme]] explained.
-  * For Radeon PCI support see the FAQ.
-  * Rage Fury Maxx is NOT supported by the DRI.
-  * The Radeon seems to have problems with certain early VIA chipsets. Your best bet is to try and see if it works.
-  * 3D support for the Radeon 9500-9800 (R300 series), X300-X850 (R400 series) and X1300 - X1950 (R500 series) is via the r300_dri driver. For the HD series, 3D support is provided in the r600 driver, and there is both the classic DRI driver and Gallium driver in development. The stability has improved a lot since 2008, thanks to specifications released by AMD also for their (ATI's) older chipsets.
-  * R500 series support is available in Mesa 7.0.4 release or newer
-  * Radeon HD 6000 (R800) series does not yet have DRI 3D driver, see below for information about the specifications being released by AMD
-
-Example graphics cards:
-  * Radeon HD 4670
-  * Radeon X1650
-  * Radeon X700
-  * Radeon 8500
-  * Rage Fury
-  * Rage Magnum
-  * Xpert 2000
-  * Xpert 128
-  * Xpert 99
-  * All-in-Wonder 128
-
-=== TVOut ===
-
-Check the [[http://www.x.org/wiki/radeonTV|radeonTV]] page at wiki.x.org for information about how TV-Out (and TV capture) for ATI cards got to official X.org drivers from the [[http://gatos.sourceforge.net/|GATOS]] project. TV-Out may now be enabled using Randr 1.2 ("xrandr" utility) for supported cards, by eg:
-
- 1. xrandr --addmode S-video 800x600
- 1. xrandr --output S-video --mode 800x600
- 1. xrandr --output S-video --set tv_standard ntsc
-
-== Specifications ==
-
-=== History ===
-ATI had a 'developer program'. Specifications of all ATI chips up to the
-Radeon 9200 were made available to DRI developers under NDA on an individual case
-basis. Please read carefully the NDA page before you consider applying.
-
-=== Currently ===
-
-For R500, R600, R700 and R800 (Radeon X1000- HD 6000 series) AMD/ATI has had a habit of releasing specifications from basic mode-setting all the way to shaders. AMD is also funding developers to develop fully open drivers "radeon" (X.Org DDX driver), "r300" and "r600" (Mesa 3D drivers and kernel DRM drivers) using the specifications together with the community, see for example http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati;a=summary .
-
-== Resources ==
-
-  * [[http://www.ati.com/|ATI homepage]]
-  * [[http://www.ati.com/support/faq/linux.html|ATI's Linux and XFree86 information]]
-  * [[http://www.ati.com/support/driver.html|ATI's proprietary Linux drivers]]
-
-----
-CategoryHardwareVendor
-TitleIndex
diff --git a/API.mdwn b/API.mdwn
new file mode 100644
index 0000000..ab909e3
--- /dev/null
+++ b/API.mdwn
@@ -0,0 +1,11 @@
+
+
+## Application Programming Interface (API)
+
+Common name used to describe the interface a programmer uses to access a library. Common 3D API's include OpenGL, Direct3D, QuickDraw3D, Renderman, Glide, and there are dozens of other lesser known ones. The two most popular real-time 3D API's these days are OpenGL and Direct3D. Glide enjoyed a dominant but brief popularity on the PC platform in the late 1990s. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/API.moin b/API.moin
deleted file mode 100644
index f1f8e30..0000000
--- a/API.moin
+++ /dev/null
@@ -1,10 +0,0 @@
-== Application Programming Interface (API) ==
-
-Common name used to describe the interface a programmer uses to access a
-library. Common 3D API's include OpenGL, Direct3D, QuickDraw3D, Renderman,
-Glide, and there are dozens of other lesser known ones. The two most popular
-real-time 3D API's these days are OpenGL and Direct3D. Glide enjoyed a dominant
-but brief popularity on the PC platform in the late 1990s.
-
-----
-CategoryGlossary
diff --git a/ARB.mdwn b/ARB.mdwn
new file mode 100644
index 0000000..5f558ea
--- /dev/null
+++ b/ARB.mdwn
@@ -0,0 +1,9 @@
+
+
+## Architecture Review Board (ARB)
+
+The group of companies (including SGI, IBM, Intel, ATI, nVidia, Microsoft, and others) responsible for the continued refinement and improvement of the OpenGL specifications. It is largely because of the ARB that OpenGL remains a clean, consistent, portable, vendor-neutral API. 
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/ARB.moin b/ARB.moin
deleted file mode 100644
index a79e9a0..0000000
--- a/ARB.moin
+++ /dev/null
@@ -1,8 +0,0 @@
-== Architecture Review Board (ARB) ==
-
-The group of companies (including SGI, IBM, Intel, ATI, nVidia, Microsoft, and
-others) responsible for the continued refinement and improvement of the OpenGL
-specifications. It is largely because of the ARB that OpenGL remains a clean,
-consistent, portable, vendor-neutral API.
-----
-CategoryGlossary
diff --git a/FrontPage/17zvy4402.html b/ATI.mdwn
index e69de29..e69de29 100644
--- a/FrontPage/17zvy4402.html
+++ b/ATI.mdwn
diff --git a/ATI.moin b/ATI.moin
deleted file mode 100644
index df45524..0000000
--- a/ATI.moin
+++ /dev/null
@@ -1 +0,0 @@
-#REDIRECT AMD
diff --git a/ATIMach64.mdwn b/ATIMach64.mdwn
new file mode 100644
index 0000000..14b15b8
--- /dev/null
+++ b/ATIMach64.mdwn
@@ -0,0 +1,64 @@
+
+
+# ATI Mach64
+
+
+## Status
+
+**Warning!** linux-core was [[dropped|http://cgit.freedesktop.org/mesa/drm/commit/?id=9dd3613073aa2491cef440725fdfa0cf1e8f1a42]] from freedesktop drm git repo with mach64 module inside, and module doesn't appear in mainstream kernel, as of 17-09-2010. You can try to build it from external sources, provided by your distribution, but mainstream  situation is not good. 
+
+--- 
+
+DRI support for mach64 has been moved to the DRI and Mesa trunks. This means DRI works on any recent distribution as of 2007. 
+
+On Linux systems, the DRM module is not included in official kernels. At least Mandriva 2007 systems come with a patch to include the Mach64 DRM, but it has been dropped for 2008 release. (Please can someone indicate where is mach64 drm gone?) 
+
+All mach64 chips with a triangle setup engine are supported.  This includes the 3D Rage Pro, 3D Rage LT Pro, 3D Rage XL, 3D Rage XC, and 3D Rage Mobility.  Cards without a triangle setup engine cannot be supported; this includes VT chips, 3D Rage, 3D Rage II/II+/IIc, and 3D Rage LT. 
+
+[[LeifDelgass|LeifDelgass]] has a page describing the status of the old mach64 branch [[here|http://www.retinalburn.net/linux/dri_status.html]]. He also has a [[page|http://www.retinalburn.net/linux/test_results.html]] has links with the results of OpenGL conformance and performance tests on the mach64 branch.  
+
+
+### How do I build the mach64 branch?
+
+Follow the instructions on the Building page.  Mach64 is now on the DRI trunk. 
+
+Build instructions for older branches are in [[LeifDelgass|LeifDelgass]]' [[Compiling the mach64 branch of DRI mini-HOWTO|http://www.retinalburn.net/linux/dri_HOWTO.html]] . 
+
+
+### Why isn't Mach64 built by default?
+
+The reason the Mach64 driver isn't built by default yet is due to lack of proper security. At the moment, despite the fact that the client submitted buffers are checked and copied, a malicious client can change the buffer contents after the check/copy because _all_ buffers are mapped on client space. Therefore security can be compromised by using the Mach64 bus mastering abilities to read/write from/to system memory. 
+
+Things that need to be done: 
+
+   * Provide a mechanism to allocate private DMA buffers which aren't mapped into the clients. The current DRM DMA buffer API is both arcane and incomplete in this this aspect. A new API is being worked, and is useable if these private DMA buffers are allocated by the DRM instead of the DDX. I'm merging into Mach64 branch as I speak, so this point can be considered done. 
+   * Allocate and manage the private DMA buffers from above in Mach64 DRM. See [[http://sourceforge.net/mailarchive/forum.php?thread_id=1925221&forum_id=7177|http://sourceforge.net/mailarchive/forum.php?thread_id=1925221&forum_id=7177]] for a more detailed description of what to do. Besides having to basically write a new/separate buffer management code we also need to integrate it with the existing one. The reason we need to keep the current buffer management code is that plain texture/bitmap data is of no security concern and needs to be dispatched as fast as possible, which means no copying into private buffers. 
+There are more things were the Mach64 driver needs a little work but the items above are the ones preventing it to be merged into the DRI trunk, and upstream. 
+
+   * -- [[JoseFonseca|JoseFonseca]] 
+As an update, the driver is waiting for some changes I'm preparing for the DRM common code that will allow the managament of several DMA buffers pools. 
+
+I can't really give a timeframe to driver completion - my laptop went dead several months ago and it's no longer something that affects me directly. Still I'm commited to finish it as my time permits it. 
+
+   * -- [[JoseFonseca|JoseFonseca]] 
+
+### Latest status
+
+Posted on the dri-users list Dec 8, 2007: (doesn't show up in the archive for some reason) 
+
+* _The work to get Mach64 secure was already done by George ([[https://bugs.freedesktop.org/show_bug.cgi?id=6242|https://bugs.freedesktop.org/show_bug.cgi?id=6242]]). Dave Airlie had concerns with the blits, but I reviewed the code with him I found it to be secure (basically we don't let the client touch dma buffers -- it's not the most efficient way for blits, but is is simple as it doesn't imply maintaining two sets of buffers, one private another public). Now I've cleaned up the code a bit (especially eliminating some macros) and commented more, to make it easier to understand and maintain. Hopefully it will be merged soon. José_ 
+
+## Specifications
+
+Several DRI developers got specifications from ATI under individual NDA. 
+
+The driver from the UtahGLX project can also be used as a guide. 
+
+
+## Resources
+
+
+
+---
+
+ [[CategoryHardwareChipset|CategoryHardwareChipset]] 
diff --git a/ATIMach64.moin b/ATIMach64.moin
deleted file mode 100644
index 4bfda09..0000000
--- a/ATIMach64.moin
+++ /dev/null
@@ -1,88 +0,0 @@
-= ATI Mach64 =
-
-== Status ==
-
-'''Warning!''' linux-core was [[ http://cgit.freedesktop.org/mesa/drm/commit/?id=9dd3613073aa2491cef440725fdfa0cf1e8f1a42 | dropped ]] from freedesktop drm git repo with mach64 module inside, and module doesn't appear in mainstream kernel, as of 17-09-2010. You can try to build it from external sources, provided by your distribution, but mainstream  situation is not good.
-
-
----
-
-DRI support for mach64 has been moved to the DRI and Mesa trunks. This means DRI works on any recent distribution as of 2007.
-
-On Linux systems, the DRM module is not included in official kernels. At least Mandriva 2007 systems come with a patch to include the Mach64 DRM, but it has been dropped for 2008 release. (Please can someone indicate where is mach64 drm gone?)
-
-All mach64 chips with a triangle setup engine are supported.  This includes the 3D Rage Pro, 3D Rage LT Pro, 3D Rage XL, 3D Rage XC, and 3D Rage Mobility.  Cards without a triangle setup engine cannot be supported; this includes VT chips, 3D Rage, 3D Rage II/II+/IIc, and 3D Rage LT.
-
-LeifDelgass has a page describing the status of the old mach64 branch [[http://www.retinalburn.net/linux/dri_status.html|here]]. He also has a [[http://www.retinalburn.net/linux/test_results.html|page]] has links with the results of OpenGL conformance and performance tests on the mach64 branch. 
-
-=== How do I build the mach64 branch? ===
-
-Follow the instructions on the Building page.  Mach64 is now on the DRI trunk.
-
-Build instructions for older branches are in LeifDelgass' [[http://www.retinalburn.net/linux/dri_HOWTO.html|Compiling the mach64 branch of DRI mini-HOWTO]] .
-
-=== Why isn't Mach64 built by default? ===
-
-The reason the Mach64 driver isn't built by default
-yet is due to lack of proper security. At the moment, despite the fact that the client submitted
-buffers are checked and copied, a malicious client can change the buffer
-contents after the check/copy because _all_ buffers are mapped on client space.
-Therefore security can be compromised by using the Mach64 bus mastering abilities
-to read/write from/to system memory.
-
-Things that need to be done:
-
-  * Provide a mechanism to allocate private DMA buffers which aren't mapped into
-  the clients. The current DRM DMA buffer API is both arcane and incomplete in
-  this this aspect. A new API is being worked, and is useable if these private DMA
-  buffers are allocated by the DRM instead of the DDX. I'm merging into Mach64
-  branch as I speak, so this point can be considered done.
-
-  * Allocate and manage the private DMA buffers from above in Mach64 DRM. See
-  http://sourceforge.net/mailarchive/forum.php?thread_id=1925221&forum_id=7177 for
-  a more detailed description of what to do. Besides having to basically write a
-  new/separate buffer management code we also need to integrate it with the
-  existing one. The reason we need to keep the current buffer management code is
-  that plain texture/bitmap data is of no security concern and needs to be
-  dispatched as fast as possible, which means no copying into private buffers.
-
-There are more things were the Mach64 driver needs a little work but the items
-above are the ones preventing it to be merged into the DRI trunk, and upstream.
-
-  -- JoseFonseca
-
-As an update, the driver is waiting for some changes I'm preparing for the DRM
-common code that will allow the managament of several DMA buffers pools.
-
-I can't really give a timeframe to driver completion - my laptop went dead
-several months ago and it's no longer something that affects me directly. Still
-I'm commited to finish it as my time permits it.
-
-  -- JoseFonseca
-
-=== Latest status ===
-Posted on the dri-users list Dec 8, 2007: (doesn't show up in the archive for some reason)
- ''The work to get Mach64 secure was already done by George (https://bugs.freedesktop.org/show_bug.cgi?id=6242).
-
- Dave Airlie had concerns with the blits, but I reviewed the code with
- him I found it to be secure (basically we don't let the client touch dma
- buffers -- it's not the most efficient way for blits, but is is simple
- as it doesn't imply maintaining two sets of buffers, one private another
- public).
-
- Now I've cleaned up the code a bit (especially eliminating some macros)
- and commented more, to make it easier to understand and maintain.
- Hopefully it will be merged soon.
-
- José''
-
-== Specifications ==
-
-Several DRI developers got specifications from ATI under individual NDA.
-
-The driver from the UtahGLX project can also be used as a guide.
-
-== Resources ==
-
-----
-CategoryHardwareChipset
diff --git a/ATIRadeon.mdwn b/ATIRadeon.mdwn
new file mode 100644
index 0000000..f4d2bd7
--- /dev/null
+++ b/ATIRadeon.mdwn
@@ -0,0 +1,434 @@
+
+
+### Summary
+
+This page contains information about Radeon chipset naming, and some other, possibly outdated information. 
+
+The main portal for 3D acceleration on Radeon is aptly named [[Radeon|Radeon]]. 
+
+[[!toc ]] 
+
+
+### AMD/ATI Radeon chipset 3D support
+
+Note this tables mainly applies to x86 machines. We make a best effort to support PowerPC/Sun cards with [[OpenFirmware|OpenFirmware]], but we cannot always support these due to Apple/Sun hardcoding most of the details in their drivers. 
+
+
+#### driver radeon/radeon_dri.so
+
+_Stable._ 
+
+
+##### rv100 / M6
+
+Original Radeons: 
+
+* Radeon VE (1 texture pipeline, no TCL) 
+Rereleased Radeons: 
+
+* Radeon 7000 / M6 (1 texture pipeline, no TCL) 
+The only differences between the releases are more RAM and higher clock speeds (possible due to a manufacturing process shrink) on the 7000. 
+
+
+##### R100
+
+Original Radeons: 
+
+* Radeon SDR 
+* Radeon DDR / LE 
+Rereleased Radeons: 
+
+* Radeon 7200 (SDR / DDR) 
+The only differences between the releases are more RAM and higher clock speeds (possible due to a manufacturing process shrink) on the 7X00 cards. 
+
+
+##### rv200 / M7
+
+* Radeon 7500 (DDR) 
+* FireGL 7800 (Mobile) 
+The 7500 has a tweaked core, more RAM and higher clock speeds (possible due to a manufacturing process shrink). Despite the name (rv200), these cards are r100 based. 
+
+
+#### driver radeon/r200_dri.so
+
+_Stable._ 
+
+
+##### R200
+
+Radeon 2: 
+
+* Radeon 8500 LE 
+* Radeon 8500 
+* Radeon 9100 
+* FireGL 8700 
+* FireGL 8800 
+The difference between the 8500, 8500 LE, 8700, and the 8800 is clock speed. The 8500 LE is made by third party manufacturers. 
+
+The amounts of memory on these cards differs eg the 8800 has twice the memory as the 8700. 
+
+All are based on the R200 chipset (this is why they can all use the FireGL drivers) and have DDR. 
+
+The Radeon 9100 is a rerelease of the Radeon 8500 because it is faster than the Radeon 9000 (see below), the windows drivers offer "pixel shader supported video deblocking filtering" for this card. 
+
+
+##### rv250 / M9
+
+Radeon 2: 
+
+* Radeon 9000 
+* Radeon 9000 Pro 
+The 9000 cards use the Rv250 chipset which is a heavily modified R200 chip, the clock speed increased, the number of texture units per pipeline halved, while the windows drivers offer "pixel shader supported video deblocking filtering" for this card. 
+
+
+##### rv280 / M9+
+
+Radeon 2: 
+
+* Radeon 9200SE 
+* Radeon 9200 
+* Radeon 9250 
+The difference between the Rv250 and the Rv280 is that the R9200 has AGP 8x while the Rv250 has AGP 4x. 
+
+The 9200SE is a toned down version of the 9200 and has half the memory bandwidth (64 bit versus 128 bit) and lower clock speed (200 MHz versus 250 MHz). 
+
+One problem with the 9200SE is that some older XFree86 servers will not detect the chipset. To make this work, you can manually set the 
+
+* ChipID 0x5964 
+or 
+
+* ChipID 0x5961 
+to the Device line. 
+
+You may also read [[http://users.actrix.co.nz/michael/radeon9200.html|http://users.actrix.co.nz/michael/radeon9200.html]] 
+
+
+#### driver radeon/r300_dri.so
+
+Status (see also the [[r300 portal|R300_Portal]]) Unstable. 
+
+Started as [[r300 project|http://r300.sourceforge.net/]], currently maintained in Mesa 3D, 3D driver for r3xx-r5xx cards. To build the latest version see Building. 
+
+
+##### R300
+
+Radeon 3: 
+
+* Radeon 9500 
+* Radeon 9500 Pro 
+* Radeon 9700 
+* Radeon 9700 Pro 
+The main difference between the 9500 Pro, and the 9500 is the number or rendering pipelines, half have been disabled in the 9500. 
+
+The main difference between the 9500 cards, and the 9700 cards is the bus width, 128 bit for 9500's, 256 bit for 9700's. 
+
+The difference between the 9700 Pro, and the 9700 is clock speed. The 9700 is made by third party manufacturers. 
+
+All are based on the R300 chipset (this is probably why they can all use the FireGL drivers) and have DDR. 
+
+
+##### rv350 / M10
+
+Radeon 3: 
+
+* Radeon 9600 
+* Radeon 9600 Pro 
+The 9600 uses the Rv350 chipset which is a heavily modified R300 chip, the clock speed increased, the memory interface and Hyper-Z optimized, the number of pipelines halved, using a 0.13Âµm process. 
+
+
+##### R350
+
+Radeon 3: 
+
+* Radeon 9800 
+* Radeon 9800 Pro 
+Both these cards use the R350 chip which is a R300 chip which has been modified to be more efficient by improving its Hyper-Z implementation and colour compression algorithms, they also have a higher clock. 
+
+The difference between the 9800 Pro and the 9800 is clock speed. 
+
+
+##### rv360 / M11 / M12
+
+* Radeon 9600 XT 
+The only differences between the rv350 and the rv360 appear to be an improvement in the manufacturing process and a boost in speed. 
+
+
+##### R360
+
+* Radeon 9800 XT 
+
+##### RV370 / M22
+
+* Radeon Xpress 200M 
+* Radeon X300 
+* Radeon X550 
+* Radeon X1050 
+
+##### RV380 / M24
+
+* Radeon X600, M24 
+
+##### RS400
+
+* Radeon XPRESS 200/200M IGP 
+Broken memory initialisation for 2D/3D. ( git version has fixes for this  since June 2007, needs more testing on differing models ) 
+
+
+##### RV410 / M26
+
+* Radeon X700, M26 PCIE 
+
+##### R420 / M18
+
+* Radeon X800 AGP 
+
+##### R423/R430 / M28
+
+* Radeon X800, M28 PCIE 
+
+##### R480/R481
+
+* Radeon X850 PCIE/AGP 
+
+##### RV505
+
+* Radeon X1550, X1550 64bit 
+Cut off version both in size and power of the R520. 
+
+
+##### RV515 / M52 / M54 / M64
+
+* Radeon X1300, X1400, X1550, X1600; FireGL V3300, V3350 
+Cut off version both in size and power of the R520. 
+
+
+##### RV516
+
+* Radeon X1300, X1550, X1550 64bit, X1600; FireMV 2250 
+Cut off version both in size and power of the R520. 
+
+
+##### R520 / M58
+
+* Radeon X1800; FireGL V5300, V7200, V7300, V7350 
+New chip design and memory controller. See the [[R520 wikipedia page|http://en.wikipedia.org/wiki/Radeon_R520]] for more info. 
+
+
+##### RV530 / M54
+
+* Radeon X1300 XT, X1600, X1600 Pro, X1650; FireGL V3400, V5200 
+Same as R515, but with more pixel shaders and one vertex shader 
+
+
+##### RV535 / M64 / M66
+
+* Radeon X1300, X1650 
+Smaller build process from RV530 
+
+
+##### RV550 / M71
+
+* Radeon X2300 HD 
+
+##### RV560
+
+* Radeon X1650 
+
+##### RV570
+
+* Radeon X1950, X1950 GT; FireGL V7400 
+Smaller build process from R580 with less texture units and pixel shaders. Also the first to have a internal Crossfire connector 
+
+
+##### R580 / M59
+
+* Radeon X1900, X1950; AMD Stream Processor 
+Update the R520 design, changed the pixel shader processor to texture processor ratio for better performance. 
+
+
+#### driver radeon/r600_dri.so
+
+_Experimental._ Support has been merged to mesa 7.6 but still a lot of features are missing. 
+
+
+##### R600
+
+* Radeon HD 2900 GT/Pro/XT; FireGL V7600, V8600, V8650 
+New chip based in the "Unified shader model", different from previous chips. See [[R600 wikipedia|http://en.wikipedia.org/wiki/Radeon_R600]] for more info 
+
+
+##### RV610 / M72
+
+* Radeon HD 2350, HD 2400 Pro/XT, HD 2400 Pro AGP; FireGL V4000 
+RV610 variants have most of the shaders removed from the R600. 
+
+
+##### RV630 / M76
+
+* Radeon HD 2600 LE/Pro/XT, HD 2600 Pro/XT AGP; Gemini RV630; FireGL V3600/V5600 
+RV630 variants have many shaders removed from the R600. 
+
+
+##### RV670
+
+* Radeon HD 3800 
+
+##### R700 series
+
+* Radeon HD 4xxx 
+
+### AMD/ATI Radeon chipset 2D support
+
+
+#### Driver "radeon"
+
+_stable_ 
+
+All radeons have open source 2D support. Note that R600/R700 series chips (X2300, X4650 etc.) are only recently supported by the "radeon" driver. 
+
+As of September 2007, 6.7.194 driver may give better results with EXA output, instead of XAA. This will change DRI rendering performance also. 
+
+[[ati/radeon development|http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/]] 
+
+
+#### Driver "radeonhd"
+
+_under development_ 
+
+The new radeonhd driver was initially to offer the sole support for R500/R600/R700 cards, but nowadays also the radeon driver supports those. It's therefore overlapping with radeon's card support, and radeonhd might be merged to radeon at some point if there's no use for a separate "newer" driver. 
+
+[[radeonhd development|http://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/]] 
+
+
+#### Driver "vesa"
+
+_stable_ 
+
+The vesa driver can be used on most cards (no acceleration). 
+
+
+### Radeon card naming and support information
+
+You also get fancy versions of most of these cards, e.g. VIVO, AIW, etc. This is just added functionality, i.e. stick on a TV tuner, a couple of chips. 
+
+The reason for the renaming is to simplify matters for end users i.e. bigger number = better / faster. However rv#00 chipsets are cut down and thus slower versions of the R#00 chipsets with the same model number (and are often even slower than lower-numbered chipsets). The exception is the rv200 which is actually a faster version of the r100 core. 
+
+Furthermore: 
+
+   * _2D and 3D support available:_ 
+* 7000 denotes a rv100 based card. 
+* 7200 denotes a R100 based card. 
+* 7500 denotes a rv200 based card. 
+* 8X00 denotes a R200 based card. 
+* 9000 denotes a rv250 based card. 
+* 9100 denotes a R200 based card 
+* 9200 denotes a rv280 based card. 
+* 9500 denotes a R300 based card. 
+* 9600 denotes a rv350 or rv360 based card. 
+* 9700 denotes a R300 based card. 
+* 9800 denotes a R350 or R360 based card. 
+* X300 denotes a rv370 based card. 
+* X550 denotes a rv370 based card. 
+* X600 denotes a rv380 based card. 
+* X700 denotes a rv410 based card. 
+* X800 denotes a R420 or R423 or R430 based card. And some "X800 GTO" cards seems to be based on R480 too. 
+* X850 denotes a R480 or R481 based card. 
+* X1050 denotes a rv370 based card. 
+* X1200 denotes a RS690 based card. 
+* X1300 denotes a RV515, RV516 based card. XT are RV530, RV535 based card. 
+* X1550 denotes a RV505, RV515, RV516 based card. 
+* X1600 denotes a RV515, RV516 based card. Pro are RV530 based card. 
+* X1650 denotes a RV530, RV535, RV560 based card. 
+* X1800 denotes a R520 based card. 
+* X1900 denotes a R580 based card. 
+* X1950 denotes a RV570, R580 based card. 
+* X2300 denotes a RV550 based card. 
+   * _Cards below this point have new 3D acceleration support_ 
+* HD2350 denotes a RV610 based card. 
+* HD2400 denotes a RV610 based card. 
+* HD2600 denotes a RV630 based card. 
+* HD2900 denotes a R600 based card. 
+* HD3850 denotes a RV670 based card. 
+* HD3870 denotes a RV670 based card. 
+(also see [[Comparison of ATI GPU:s at Wikipedia|http://en.wikipedia.org/wiki/Comparison_of_ATI_graphics_processing_units]]) 
+
+Legend: 
+
+* SE = Stripped down version of the chip which has half the memory bandwidth (64 bit versus 128 bit). 
+* VE = Value Edition 
+* LE = Light Edition 
+* SDR = Single Data Rate (RAM) 
+* DDR = Double Data Rate (RAM) 
+
+#### IGP
+
+The Radeon IGP chipsets do not have discrete video ram. They share system ram much like the Intel i8xx chips, and VIA/S3 Pro``Savage/Twister chips. There is support for 2D and 3D acceleration for the IGP chipsets in DRI and Mesa CVS. There is  experimental 3D for Xpress 200M Northbridge integrated GPUs (june 2007). 
+
+
+#### Dualhead
+
+All Radeon's except the 7200 (r100) have two crtcs and a built-in LVDS/TMDS controller. Not all OEMs connect these to actual ports so you may see boards that only support 1 head. 
+
+Until driver version 6.7, if you wanted to use HW accelerated 3D on both heads of a dualheaded radeon card, you had to use the Radeon MergedFB option by [[AlexDeucher|AlexDeucher]]. Since version 6.7, the driver supports Randr 1.2, which allows screen hot (un)plugging, and dynamic multiheads. Just try "xrandr --auto" to get to biggest possible mode. A big "Virtual" option is needed to allow big multiheads. 
+### Configuration
+
+Also see 'radeon' and 'xorg.conf' manpages. 
+
+
+[[!format txt """
+Section "Module"
+ ...
+ Load  "glx"
+ Load  "dri"
+EndSection
+"""]]
+
+[[!format txt """
+Section "Device"
+ Identifier "name"                 # your alias
+ Driver "radeon"
+ Option "AccelMethod" "XAA"
+ # XAA/EXA
+ Option "AccelDFS"    "1"
+ # 1/0 On for PCIE, off for AGP
+ # Manpage: Use  or  don't  use accelerated EXA DownloadFromScreen hook
+ # when possible.
+ Option "AGPMode" "1"
+ # 1-8 Does not affect PCIE models.
+ Option "AGPFastWrite" "1"
+ # 1/0 Does not affect PCIE models. Not recommended.
+ Option "GARTSize" "64"
+ # 0-64 Megabytes of gart (system) memory used.
+ # Wrongly defaults to 8MB sometimes, see your logfile.
+ # Bigger seems better.
+ Option "EnablePageFlip" "1"
+ # 1/0 Increases 3D performance substantially
+ # seemingly in XAA mode only
+ Option "ColorTiling" "1"
+ # 1/0 Increases 3D performance substantially
+ # affected stability only positively on my system
+EndSection
+"""]]
+
+[[!format txt """
+Section "DRI"
+ Group        "video"
+ Mode         0660
+EndSection
+"""]]
+Further finer, and per application, user-space configuration is achieved with [[DriConf|DriConf]] 
+
+[[!img http://people.freedesktop.org/~fxkuehl/driconf/driconf.png] 
+
+
+### Other drivers
+
+Alternatively proprietary non-libre 2D and 3D support is available through ATI/AMD's [[Fire GL linux driver "fglrx"|http://wiki.x.org/wiki/ATIProprietaryDriver]] 
+
+
+
+---
+
+ 
+
+* [[CategoryHardwareChipset|CategoryHardwareChipset]] 
+\ No newline at end of file
diff --git a/ATIRadeon.moin b/ATIRadeon.moin
deleted file mode 100644
index 40aeee5..0000000
--- a/ATIRadeon.moin
+++ /dev/null
@@ -1,357 +0,0 @@
-=== Summary ===
-
-This page contains information about Radeon chipset naming, and some other, possibly outdated information.
-
-The main portal for 3D acceleration on Radeon is aptly named [[Radeon]].
-
-<<TableOfContents>>
-
-=== AMD/ATI Radeon chipset 3D support ===
-
-Note this tables mainly applies to x86 machines. We make a best effort to support PowerPC/Sun cards with OpenFirmware,
-but we cannot always support these due to Apple/Sun hardcoding most of the details in their drivers.
-
-==== driver radeon/radeon_dri.so ====
-''Stable.''
-
-===== rv100 / M6 =====
-Original Radeons:
-
- * Radeon VE (1 texture pipeline, no TCL)
-Rereleased Radeons:
-
- * Radeon 7000 / M6 (1 texture pipeline, no TCL)
-The only differences between the releases are more RAM and higher clock speeds (possible due to a manufacturing process shrink) on the 7000.
-
-===== R100 =====
-Original Radeons:
-
- * Radeon SDR
- * Radeon DDR / LE
-Rereleased Radeons:
-
- * Radeon 7200 (SDR / DDR)
-The only differences between the releases are more RAM and higher clock speeds (possible due to a manufacturing process shrink) on the 7X00 cards.
-
-===== rv200 / M7 =====
- * Radeon 7500 (DDR)
- * FireGL 7800 (Mobile)
-The 7500 has a tweaked core, more RAM and higher clock speeds (possible due to a manufacturing process shrink). Despite the name (rv200), these cards are r100 based.
-
-==== driver radeon/r200_dri.so ====
-''Stable.''
-
-===== R200 =====
-Radeon 2:
-
- * Radeon 8500 LE
- * Radeon 8500
- * Radeon 9100
- * FireGL 8700
- * FireGL 8800
-The difference between the 8500, 8500 LE, 8700, and the 8800 is clock speed. The 8500 LE is made by third party manufacturers.
-
-The amounts of memory on these cards differs eg the 8800 has twice the memory as the 8700.
-
-All are based on the R200 chipset (this is why they can all use the FireGL drivers) and have DDR.
-
-The Radeon 9100 is a rerelease of the Radeon 8500 because it is faster than the Radeon 9000 (see below), the windows drivers offer "pixel shader supported video deblocking filtering" for this card.
-
-===== rv250 / M9 =====
-Radeon 2:
-
- * Radeon 9000
- * Radeon 9000 Pro
-The 9000 cards use the Rv250 chipset which is a heavily modified R200 chip, the clock speed increased, the number of texture units per pipeline halved, while the windows drivers offer "pixel shader supported video deblocking filtering" for this card.
-
-===== rv280 / M9+ =====
-Radeon 2:
-
- * Radeon 9200SE
- * Radeon 9200
- * Radeon 9250
-The difference between the Rv250 and the Rv280 is that the R9200 has AGP 8x while the Rv250 has AGP 4x.
-
-The 9200SE is a toned down version of the 9200 and has half the memory bandwidth (64 bit versus 128 bit) and lower clock speed (200 MHz versus 250 MHz).
-
-One problem with the 9200SE is that some older XFree86 servers will not detect the chipset. To make this work, you can manually set the
-
- . ChipID 0x5964
-or
-
- . ChipID 0x5961
-to the Device line.
-
-You may also read http://users.actrix.co.nz/michael/radeon9200.html
-
-
-==== driver radeon/r300_dri.so ====
-Status (see also the [[R300_Portal|r300 portal]]) Unstable.
-
-Started as [[http://r300.sourceforge.net/|r300 project]], currently maintained in Mesa 3D, 3D driver for r3xx-r5xx cards. To build the latest version see Building.
-
-===== R300 =====
-Radeon 3:
-
- * Radeon 9500
- * Radeon 9500 Pro
- * Radeon 9700
- * Radeon 9700 Pro
-The main difference between the 9500 Pro, and the 9500 is the number or rendering pipelines, half have been disabled in the 9500.
-
-The main difference between the 9500 cards, and the 9700 cards is the bus width, 128 bit for 9500's, 256 bit for 9700's.
-
-The difference between the 9700 Pro, and the 9700 is clock speed. The 9700 is made by third party manufacturers.
-
-All are based on the R300 chipset (this is probably why they can all use the FireGL drivers) and have DDR.
-
-===== rv350 / M10 =====
-Radeon 3:
-
- * Radeon 9600
- * Radeon 9600 Pro
-The 9600 uses the Rv350 chipset which is a heavily modified R300 chip, the clock speed increased, the memory interface and Hyper-Z optimized, the number of pipelines halved, using a 0.13Âµm process.
-
-===== R350 =====
-Radeon 3:
-
- * Radeon 9800
- * Radeon 9800 Pro
-Both these cards use the R350 chip which is a R300 chip which has been modified to be more efficient by improving its Hyper-Z implementation and colour compression algorithms, they also have a higher clock.
-
-The difference between the 9800 Pro and the 9800 is clock speed.
-
-===== rv360 / M11 / M12 =====
- * Radeon 9600 XT
-The only differences between the rv350 and the rv360 appear to be an improvement in the manufacturing process and a boost in speed.
-
-===== R360 =====
- * Radeon 9800 XT
-===== RV370 / M22 =====
- * Radeon Xpress 200M
- * Radeon X300
- * Radeon X550
- * Radeon X1050
-===== RV380 / M24 =====
- * Radeon X600, M24
-===== RS400 =====
- * Radeon XPRESS 200/200M IGP
-Broken memory initialisation for 2D/3D. ( git version has fixes for this  since June 2007, needs more testing on differing models )
-
-===== RV410 / M26 =====
- * Radeon X700, M26 PCIE
-===== R420 / M18 =====
- * Radeon X800 AGP
-===== R423/R430 / M28  =====
- * Radeon X800, M28 PCIE
-===== R480/R481 =====
- * Radeon X850 PCIE/AGP
-
-===== RV505 =====
- * Radeon X1550, X1550 64bit
-
-Cut off version both in size and power of the R520.
-
-===== RV515 / M52 / M54 / M64 =====
- * Radeon X1300, X1400, X1550, X1600; FireGL V3300, V3350
-
-Cut off version both in size and power of the R520.
-
-===== RV516 =====
- * Radeon X1300, X1550, X1550 64bit, X1600; FireMV 2250
-
-Cut off version both in size and power of the R520.
-
-===== R520 / M58 =====
- * Radeon X1800; FireGL V5300, V7200, V7300, V7350
-
-New chip design and memory controller.
-See the [[http://en.wikipedia.org/wiki/Radeon_R520|R520 wikipedia page]] for more info.
-
-===== RV530 / M54 =====
- * Radeon X1300 XT, X1600, X1600 Pro, X1650; FireGL V3400, V5200
-
-Same as R515, but with more pixel shaders and one vertex shader
-
-===== RV535 / M64 / M66 =====
- * Radeon X1300, X1650
-
-Smaller build process from RV530
-
-===== RV550 / M71 =====
- * Radeon X2300 HD
-
-===== RV560 =====
- * Radeon X1650
-
-===== RV570 =====
- * Radeon X1950, X1950 GT; FireGL V7400
-
-Smaller build process from R580 with less texture units and pixel shaders. Also the first to have a internal Crossfire connector
-
-===== R580 / M59 =====
- * Radeon X1900, X1950; AMD Stream Processor
-
-Update the R520 design, changed the pixel shader processor to texture processor ratio for better performance.
-
-==== driver radeon/r600_dri.so ====
-''Experimental.'' Support has been merged to mesa 7.6 but still a lot of features are missing.
-
-===== R600 =====
- * Radeon HD 2900 GT/Pro/XT; FireGL V7600, V8600, V8650
-
-New chip based in the "Unified shader model", different from previous chips.
-See [[http://en.wikipedia.org/wiki/Radeon_R600|R600 wikipedia]] for more info
-
-===== RV610 / M72 =====
- * Radeon HD 2350, HD 2400 Pro/XT, HD 2400 Pro AGP; FireGL V4000
-
-RV610 variants have most of the shaders removed from the R600.
-
-===== RV630 / M76 =====
- * Radeon HD 2600 LE/Pro/XT, HD 2600 Pro/XT AGP; Gemini RV630; FireGL V3600/V5600
-
-RV630 variants have many shaders removed from the R600.
-
-===== RV670 =====
- * Radeon HD 3800
-
-===== R700 series =====
-
- * Radeon HD 4xxx
-
-=== AMD/ATI Radeon chipset 2D support ===
-==== Driver "radeon" ====
-''stable''
-
-All radeons have open source 2D support. Note that R600/R700 series chips (X2300, X4650 etc.) are only recently supported by the "radeon" driver.
-
-As of September 2007, 6.7.194 driver may give better results with EXA output, instead of XAA. This will change DRI rendering performance also.
-
-[[http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/|ati/radeon development]]
-
-==== Driver "radeonhd" ====
-''under development''
-
-The new radeonhd driver was initially to offer the sole support for R500/R600/R700 cards, but nowadays also the radeon driver supports those. It's therefore overlapping with radeon's card support, and radeonhd might be merged to radeon at some point if there's no use for a separate "newer" driver.
-
-[[http://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/|radeonhd development]]
-
-==== Driver "vesa" ====
-''stable''
-
-The vesa driver can be used on most cards (no acceleration).
-
-=== Radeon card naming and support information ===
-
-You also get fancy versions of most of these cards, e.g. VIVO, AIW, etc. This is just added functionality, i.e. stick on a TV tuner, a couple of chips.
-
-The reason for the renaming is to simplify matters for end users i.e. bigger number = better / faster. However rv#00 chipsets are cut down and thus slower versions of the R#00 chipsets with the same model number (and are often even slower than lower-numbered chipsets). The exception is the rv200 which is actually a faster version of the r100 core.
-
-Furthermore:
-
-  * ''2D and 3D support available:''
- * 7000 denotes a rv100 based card.
- * 7200 denotes a R100 based card.
- * 7500 denotes a rv200 based card.
- * 8X00 denotes a R200 based card.
- * 9000 denotes a rv250 based card.
- * 9100 denotes a R200 based card
- * 9200 denotes a rv280 based card.
- * 9500 denotes a R300 based card.
- * 9600 denotes a rv350 or rv360 based card.
- * 9700 denotes a R300 based card.
- * 9800 denotes a R350 or R360 based card.
- * X300 denotes a rv370 based card.
- * X550 denotes a rv370 based card.
- * X600 denotes a rv380 based card.
- * X700 denotes a rv410 based card.
- * X800 denotes a R420 or R423 or R430 based card. And some "X800 GTO" cards seems to be based on R480 too.
- * X850 denotes a R480 or R481 based card.
- * X1050 denotes a rv370 based card.
- * X1200 denotes a RS690 based card.
- * X1300 denotes a RV515, RV516 based card. XT are RV530, RV535 based card.
- * X1550 denotes a RV505, RV515, RV516 based card.
- * X1600 denotes a RV515, RV516 based card. Pro are RV530 based card.
- * X1650 denotes a RV530, RV535, RV560 based card.
- * X1800 denotes a R520 based card.
- * X1900 denotes a R580 based card.
- * X1950 denotes a RV570, R580 based card.
- * X2300 denotes a RV550 based card.
-  * ''Cards below this point have new 3D acceleration support''
- * HD2350 denotes a RV610 based card.
- * HD2400 denotes a RV610 based card.
- * HD2600 denotes a RV630 based card.
- * HD2900 denotes a R600 based card.
- * HD3850 denotes a RV670 based card.
- * HD3870 denotes a RV670 based card.
-
-(also see [[http://en.wikipedia.org/wiki/Comparison_of_ATI_graphics_processing_units|Comparison of ATI GPU:s at Wikipedia]])
-
-Legend:
-
- * SE = Stripped down version of the chip which has half the memory bandwidth (64 bit versus 128 bit).
- * VE = Value Edition
- * LE = Light Edition
- * SDR = Single Data Rate (RAM)
- * DDR = Double Data Rate (RAM)
-
-==== IGP ====
-The Radeon IGP chipsets do not have discrete video ram. They share system ram much like the Intel i8xx chips, and VIA/S3 Pro``Savage/Twister chips. There is support for 2D and 3D acceleration for the IGP chipsets in DRI and Mesa CVS. There is  experimental 3D for Xpress 200M Northbridge integrated GPUs (june 2007).
-
-==== Dualhead ====
-All Radeon's except the 7200 (r100) have two crtcs and a built-in LVDS/TMDS controller. Not all OEMs connect these to actual ports so you may see boards that only support 1 head.
-
-Until driver version 6.7, if you wanted to use HW accelerated 3D on both heads of a dualheaded radeon card, you had to use the Radeon MergedFB option by AlexDeucher.
-Since version 6.7, the driver supports Randr 1.2, which allows screen hot (un)plugging, and dynamic multiheads. Just try "xrandr --auto" to get to biggest possible mode. A big "Virtual" option is needed to allow big multiheads.
-=== Configuration ===
-Also see 'radeon' and 'xorg.conf' manpages.
-
-{{{
-Section "Module"
- ...
- Load  "glx"
- Load  "dri"
-EndSection
-}}}
-{{{
-Section "Device"
- Identifier "name"                 # your alias
- Driver "radeon"
- Option "AccelMethod" "XAA"
- # XAA/EXA
- Option "AccelDFS"    "1"
- # 1/0 On for PCIE, off for AGP
- # Manpage: Use  or  don't  use accelerated EXA DownloadFromScreen hook
- # when possible.
- Option "AGPMode" "1"
- # 1-8 Does not affect PCIE models.
- Option "AGPFastWrite" "1"
- # 1/0 Does not affect PCIE models. Not recommended.
- Option "GARTSize" "64"
- # 0-64 Megabytes of gart (system) memory used.
- # Wrongly defaults to 8MB sometimes, see your logfile.
- # Bigger seems better.
- Option "EnablePageFlip" "1"
- # 1/0 Increases 3D performance substantially
- # seemingly in XAA mode only
- Option "ColorTiling" "1"
- # 1/0 Increases 3D performance substantially
- # affected stability only positively on my system
-EndSection
-}}}
-{{{
-Section "DRI"
- Group        "video"
- Mode         0660
-EndSection
-}}}
-Further finer, and per application, user-space configuration is achieved with DriConf
-
-{{http://people.freedesktop.org/~fxkuehl/driconf/driconf.png}}
-
-=== Other drivers ===
-Alternatively proprietary non-libre 2D and 3D support is available through ATI/AMD's [[http://wiki.x.org/wiki/ATIProprietaryDriver|Fire GL linux driver "fglrx"]]
-
-----
- . CategoryHardwareChipset
diff --git a/ATIRage128.mdwn b/ATIRage128.mdwn
new file mode 100644
index 0000000..b1569a6
--- /dev/null
+++ b/ATIRage128.mdwn
@@ -0,0 +1,34 @@
+
+
+# ATI Rage 128
+
+
+## Status
+
+The ATI Rage128 desktop and mobility chips are supported by the DRI.  [[EricAnholt|EricAnholt]] recently added pageflipping support. You can enable pageflipping by adding this to your config: 
+
+
+[[!format txt """
+Option "EnablePageFlip" "true"
+"""]]
+It will give you a small boost in performance, but it causes problems for some people. 
+
+There is no support for suspend/resume for r128.  It shouldn't be too hard to add support.  Take a look at the radeon suspend/resume code.  I think Xv also needs some fixes for suspend/resume. 
+
+Todo: implement hardware-accelerated projective texturing 
+
+
+## Specifications
+
+The register documentation is available on Wikipedia 
+
+[[http://en.wikipedia.org/wiki/Rage_128|http://en.wikipedia.org/wiki/Rage_128]] 
+
+
+## Resources
+
+
+
+---
+
+ [[CategoryHardwareChipset|CategoryHardwareChipset]] 
diff --git a/ATIRage128.moin b/ATIRage128.moin
deleted file mode 100644
index 4a77377..0000000
--- a/ATIRage128.moin
+++ /dev/null
@@ -1,29 +0,0 @@
-= ATI Rage 128 =
-
-== Status ==
-
-The ATI Rage128 desktop and mobility chips are supported by the DRI.  EricAnholt recently added pageflipping support. You can enable pageflipping by adding this to your config:
-
-{{{
-Option "EnablePageFlip" "true"
-}}}
- 
-It will give you a small boost in performance, but it causes problems
-for some people.
-
-There is no support for suspend/resume for r128.  It shouldn't be too
-hard to add support.  Take a look at the radeon suspend/resume code.  I
-think Xv also needs some fixes for suspend/resume.
-
-Todo: implement hardware-accelerated projective texturing
-
-== Specifications ==
-
-The register documentation is available on Wikipedia
-
-http://en.wikipedia.org/wiki/Rage_128
-
-== Resources ==
-
-----
-CategoryHardwareChipset
diff --git a/AdamJackson.mdwn b/AdamJackson.mdwn
new file mode 100644
index 0000000..d0f8b08
--- /dev/null
+++ b/AdamJackson.mdwn
@@ -0,0 +1,8 @@
+
+DRI and X hacker, graphics archaeologist, beer snob. 
+
+Current DRI projects: 
+
+* [[NumberNine|NumberNine]] driver 
+* other stuff (TODO: fill me in) 
+[[web page|http://people.freedesktop.org/~ajax/]] 
diff --git a/AdamJackson.moin b/AdamJackson.moin
deleted file mode 100644
index b2d6ce7..0000000
--- a/AdamJackson.moin
+++ /dev/null
@@ -1,8 +0,0 @@
-DRI and X hacker, graphics archaeologist, beer snob.
-
-Current DRI projects:
-
- * [[NumberNine]] driver
- * other stuff (TODO: fill me in)
-
-[[http://people.freedesktop.org/~ajax/|web page]]
diff --git a/AdminGroup.mdwn b/AdminGroup.mdwn
new file mode 100644
index 0000000..e074ba7
--- /dev/null
+++ b/AdminGroup.mdwn
@@ -0,0 +1,9 @@
+
+People that administer this wiki: 
+
+* [[AdamJackson2|AdamJackson2]] 
+* [[AdamJackson|AdamJackson]] 
+* [[JoseFonseca|JoseFonseca]] 
+* [[DanielStone|DanielStone]] 
+* [[ZackRusin|ZackRusin]] 
+* [[TollefFogHeen|TollefFogHeen]] 
+\ No newline at end of file
diff --git a/AdminGroup.moin b/AdminGroup.moin
deleted file mode 100644
index 98555b7..0000000
--- a/AdminGroup.moin
+++ /dev/null
@@ -1,8 +0,0 @@
-#acl AdminGroup:admin,read,write All:read
-People that administer this wiki:
- * AdamJackson2
- * AdamJackson
- * JoseFonseca
- * DanielStone
- * ZackRusin
- * TollefFogHeen
diff --git a/AlanCox.mdwn b/AlanCox.mdwn
new file mode 100644
index 0000000..9dfdcef
--- /dev/null
+++ b/AlanCox.mdwn
@@ -0,0 +1,17 @@
+
+
+## Your Name
+Email
+: alan at redhat dot com 
+
+Homepage
+: 
+.[[http://www.linux.org.uk/diary|http://www.linux.org.uk/diary]] 
+
+
+
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/AlanCox.moin b/AlanCox.moin
deleted file mode 100644
index 3415d24..0000000
--- a/AlanCox.moin
+++ /dev/null
@@ -1,10 +0,0 @@
-== Your Name ==
-
- Email:: alan at redhat dot com
-
- Homepage:: .http://www.linux.org.uk/diary
-
-----
-CategoryHomepage
-
-
diff --git a/AlanHourihane.mdwn b/AlanHourihane.mdwn
new file mode 100644
index 0000000..ae4d3d9
--- /dev/null
+++ b/AlanHourihane.mdwn
@@ -0,0 +1,25 @@
+
+
+## Alan Hourihane
+
+[[!img http://www.tungstengraphics.com/photos/alan.jpg] 
+Email
+: alanh at fairlite dot demon dot co dot uk 
+
+Homepage
+: 
+[[http://www.xfree86.org/~alanh/|http://www.xfree86.org/~alanh/]] 
+
+
+Interests
+: 
+      * XFree86 
+      * 3Dlabs and Trident drivers 
+      * VNC 
+
+
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/AlanHourihane.moin b/AlanHourihane.moin
deleted file mode 100644
index f078758..0000000
--- a/AlanHourihane.moin
+++ /dev/null
@@ -1,15 +0,0 @@
-== Alan Hourihane ==
-
-{{http://www.tungstengraphics.com/photos/alan.jpg}}
-
- Email:: alanh at fairlite dot demon dot co dot uk
-
- Homepage:: http://www.xfree86.org/~alanh/
- 
- Interests::
-   * XFree86
-   * 3Dlabs and Trident drivers
-   * VNC
-
-----
-CategoryHomepage
diff --git a/AlecAri.moin b/AlecAri.mdwn
index e31ab64..feb9f06 100644
--- a/AlecAri.moin
+++ b/AlecAri.mdwn
@@ -1,13 +1,26 @@
-== Alec Ari ==
-
- Email:: neotheuser@ymail.com
-
- Homepage:: http://neo-technical.wikispaces.com
- Interests:: learning bits and peices of code all over cgit.freedesktop.org
-   * compiling things
-   * git
-
-Some people refer to me as Neo_The_User as that was my hacker alias back in the day when I was big on PS3 (Playstation 3) hacking. I wrote several different NAND flashers for PSP (Playstation Portable) along with a few other developers. I then started my own Playstation 3 development team along with some other people and then... it kinda just fell apart so now I just tinker with stuff.
-
-----
-CategoryHomepage
+
+
+## Alec Ari
+Email
+: 
+[[neotheuser@ymail.com|mailto:neotheuser@ymail.com]] 
+
+
+Homepage
+: 
+[[http://neo-technical.wikispaces.com|http://neo-technical.wikispaces.com]] 
+
+
+Interests
+: learning bits and peices of code all over cgit.freedesktop.org 
+      * compiling things 
+      * git 
+
+
+Some people refer to me as Neo_The_User as that was my hacker alias back in the day when I was big on PS3 (Playstation 3) hacking. I wrote several different NAND flashers for PSP (Playstation Portable) along with a few other developers. I then started my own Playstation 3 development team along with some other people and then... it kinda just fell apart so now I just tinker with stuff. 
+
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/AlexDeucher.mdwn b/AlexDeucher.mdwn
new file mode 100644
index 0000000..3a8df8d
--- /dev/null
+++ b/AlexDeucher.mdwn
@@ -0,0 +1,19 @@
+
+
+## Alex Deucher
+
+Email: agd5f at yahoo dot com 
+
+Developer and maintainer of MergedFB support for ATIRadeon hardware and general Xorg developer.   
+
+[[S3Savage|S3Savage]] DRI support - available in Xorg 6.9.0+ 
+
+[[S3Savage|S3Savage]] EXA support - available in xorg cvs 
+
+[[S3Savage|S3Savage]] [[Dualhead (Duoview) support|http://www.botchco.com/alex/new-savage/html/]] - available in Xorg 6.9.0+ 
+
+ATIRage128 [[Dualhead Support|http://www.botchco.com/alex/r128]] - available in Xorg 6.9.0+ 
+
+[[SiliconMotion|SiliconMotion]] Dualhead Support - in progress 
+
+ATIMach64 Dualhead Support - no hardware 
diff --git a/AlexDeucher.moin b/AlexDeucher.moin
deleted file mode 100644
index 4e9228b..0000000
--- a/AlexDeucher.moin
+++ /dev/null
@@ -1,17 +0,0 @@
-== Alex Deucher ==
-
-Email: agd5f at yahoo dot com
-
-Developer and maintainer of MergedFB support for ATIRadeon hardware and general Xorg developer.  
-
-S3Savage DRI support - available in Xorg 6.9.0+
-
-S3Savage EXA support - available in xorg cvs
-
-S3Savage [[http://www.botchco.com/alex/new-savage/html/|Dualhead (Duoview) support]] - available in Xorg 6.9.0+
-
-ATIRage128 [[http://www.botchco.com/alex/r128|Dualhead Support]] - available in Xorg 6.9.0+
-
-SiliconMotion Dualhead Support - in progress
-
-ATIMach64 Dualhead Support - no hardware
diff --git a/AlexanderStohr.mdwn b/AlexanderStohr.mdwn
new file mode 100644
index 0000000..ad54a98
--- /dev/null
+++ b/AlexanderStohr.mdwn
@@ -0,0 +1,2 @@
+
+[[http://www.dg3mmf.de|http://www.dg3mmf.de]] 
diff --git a/AlexanderStohr.moin b/AlexanderStohr.moin
deleted file mode 100644
index 6762016..0000000
--- a/AlexanderStohr.moin
+++ /dev/null
@@ -1 +0,0 @@
-http://www.dg3mmf.de
diff --git a/AndrewRandrianasulu.moin b/AndrewRandrianasulu.mdwn
index 5d911df..307a711 100644
--- a/AndrewRandrianasulu.moin
+++ b/AndrewRandrianasulu.mdwn
@@ -1,63 +1,68 @@
-== Andrew Randrianasulu ==
-
- Email:: randrianasulu_AT_yahoo.com
-
- Homepage:: none
- Interests::
-   * Graphics hardware
-   * Dogs, dolphins, and so on ...
-
-I have old rv280 (radeon 9200SE) videocard, and some old nvidia cards, all AGP.
-Mostly interested in speed optimization. See this data for some numbers:
-
-[[http://www.opensubscriber.com/message/dri-devel@lists.sourceforge.net/631188.html]]
-
-{{{
-
-AGP 1x, GART only,  best: 38 fps
-AGP 1x, GART only,  2nd:  50 fps
-AGP 1x, local only, best: 33 fps
-AGP 1x, local only, 2nd:  74 fps
-AGP 1x, GART+local, best: 54 fps
-AGP 1x, GART+local, 2nd:  75 fps
-
-AGP 2x, GART only,  best: 57 fps
-AGP 2x, GART only,  2nd:  70 fps
-AGP 2x, local only, best: 34 fps
-AGP 2x, local only, 2nd:  74 fps
-AGP 2x, GART+local, best: 64 fps
-AGP 2x, GART+local, 2nd:  74 fps
-
-}}}
-
-Where hw was described as
-
-{{{
-Celeron Tualatin 1000@1330 on bx-133 (note this has consequences for AGP
-speed, AGP 1x will actually have transfer rate of "AGP 1.33x", AGP 2x is
-"AGP 2.66x"), 1.06GB/s main memory bandwidth. Graphic card is a Radeon
-7200 SDR (@160Mhz, memory bandwidth is a paltry 2.05GB/s) 32MB.
-}}}
-
-and test was done using Q3 v1.32b
-
-{{{
-QuakeIII 1.32b, 800x600 windowed, timedemo demo four, with color tiling,
-with texture tiling (that's another story, btw...), with hyperz, without
-compressed textures, 32bit textures, trilinear. "best" means highest
-texture quality, "2nd" means I used the second-highest texture quality
-setting.
-}}}
-
-For me currently (09-02-2010) mesa 7.8 in KMS mode, with some  hyperz hacked in, gives roughly 20 fps in 1024x768x32 fullscreen. (but i have q3demo v1.11, and demo002)
-
-Hacks are:
-
-
-[[attachment:r200_hyper_hacks_not_working_yet_v5.diff]]
-
-
-[[attachment:r200_hyperz_kernel.patch]]
-
-----
-CategoryHomepage
+
+
+## Andrew Randrianasulu
+Email
+: randrianasulu_AT_yahoo.com 
+
+Homepage
+: none 
+
+Interests
+: 
+      * Graphics hardware 
+      * Dogs, dolphins, and so on ... 
+
+
+I have old rv280 (radeon 9200SE) videocard, and some old nvidia cards, all AGP. Mostly interested in speed optimization. See this data for some numbers: 
+
+[[http://www.opensubscriber.com/message/dri-devel@lists.sourceforge.net/631188.html|http://www.opensubscriber.com/message/dri-devel@lists.sourceforge.net/631188.html]] 
+
+
+[[!format txt """
+AGP 1x, GART only,  best: 38 fps
+AGP 1x, GART only,  2nd:  50 fps
+AGP 1x, local only, best: 33 fps
+AGP 1x, local only, 2nd:  74 fps
+AGP 1x, GART+local, best: 54 fps
+AGP 1x, GART+local, 2nd:  75 fps
+
+AGP 2x, GART only,  best: 57 fps
+AGP 2x, GART only,  2nd:  70 fps
+AGP 2x, local only, best: 34 fps
+AGP 2x, local only, 2nd:  74 fps
+AGP 2x, GART+local, best: 64 fps
+AGP 2x, GART+local, 2nd:  74 fps
+
+"""]]
+Where hw was described as 
+
+
+[[!format txt """
+Celeron Tualatin 1000@1330 on bx-133 (note this has consequences for AGP
+speed, AGP 1x will actually have transfer rate of "AGP 1.33x", AGP 2x is
+"AGP 2.66x"), 1.06GB/s main memory bandwidth. Graphic card is a Radeon
+7200 SDR (@160Mhz, memory bandwidth is a paltry 2.05GB/s) 32MB.
+"""]]
+and test was done using Q3 v1.32b 
+
+
+[[!format txt """
+QuakeIII 1.32b, 800x600 windowed, timedemo demo four, with color tiling,
+with texture tiling (that's another story, btw...), with hyperz, without
+compressed textures, 32bit textures, trilinear. "best" means highest
+texture quality, "2nd" means I used the second-highest texture quality
+setting.
+"""]]
+For me currently (09-02-2010) mesa 7.8 in KMS mode, with some  hyperz hacked in, gives roughly 20 fps in 1024x768x32 fullscreen. (but i have q3demo v1.11, and demo002) 
+
+Hacks are: 
+
+[[r200_hyper_hacks_not_working_yet_v5.diff|r200_hyper_hacks_not_working_yet_v5.diff]] 
+
+[[r200_hyperz_kernel.patch|r200_hyperz_kernel.patch]] 
+
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/AuthorshipAndAcknowledgements.mdwn b/AuthorshipAndAcknowledgements.mdwn
new file mode 100644
index 0000000..97e6175
--- /dev/null
+++ b/AuthorshipAndAcknowledgements.mdwn
@@ -0,0 +1,7 @@
+
+
+# Authorship and Acknowledgments
+
+This Wiki is maintained by [[JoseFonseca|JoseFonseca]], originally based on the _DRI Developer's FAQ_, which in turn was compiled from the posts and comments of the DRI developers mailing list subscribers. 
+
+**NOTE:** In the impossibility of getting every person permission to quote them, if you are the author of any material here and don't want its reproduction please contact the author and it will be promptly removed. 
diff --git a/AuthorshipAndAcknowledgements.moin b/AuthorshipAndAcknowledgements.moin
deleted file mode 100644
index 1834d25..0000000
--- a/AuthorshipAndAcknowledgements.moin
+++ /dev/null
@@ -1,5 +0,0 @@
-= Authorship and Acknowledgments =
-
-This Wiki is maintained by JoseFonseca, originally based on the ''DRI Developer's FAQ'', which in turn was compiled from the posts and comments of the DRI developers mailing list subscribers.
-
-'''NOTE:''' In the impossibility of getting every person permission to quote them, if you are the author of any material here and don't want its reproduction please contact the author and it will be promptly removed.
diff --git a/BSD.mdwn b/BSD.mdwn
new file mode 100644
index 0000000..23efeff
--- /dev/null
+++ b/BSD.mdwn
@@ -0,0 +1,11 @@
+
+
+# BSD
+
+See FreeBSD. 
+
+
+
+---
+
+ [[CategoryOperatingSystem|CategoryOperatingSystem]] 
diff --git a/BSD.moin b/BSD.moin
deleted file mode 100644
index b03dd3d..0000000
--- a/BSD.moin
+++ /dev/null
@@ -1,6 +0,0 @@
-= BSD =
-
-See FreeBSD.
-
-----
-CategoryOperatingSystem
diff --git a/BadContent.mdwn b/BadContent.mdwn
new file mode 100644
index 0000000..b40588f
--- /dev/null
+++ b/BadContent.mdwn
@@ -0,0 +1,9 @@
+
+([\w\-_.]+\.)?(l(so|os)tr)\.[a-z]{2,} (blow)[\w\-_.]*job[\w\-_.]*\.[a-z]{2,} (buy)[\w\-_.]*online[\w\-_.]*\.[a-z]{2,} (gambling|porn|busty|prescription|pharmacy|penis|pills|enlarge)[\w\-_.]*\.[a-z]{2,} (diet|penis)[\w\-_.]*(pills|enlargement)[\w\-_.]*\.[a-z]{2,} (annunci|tatuaggi|canzoni|musicali|scarica|sesso|hentai|ragazze|sonnerie)[\w\-_.]*\.[a-z]{2,} (i|la)-sonneries?[\w\-_.]*\.[a-z]{2,} (incest|beastiality)[\w\-_.]*\.[a-z]{2,3} (levitra|lolita|phentermine|viagra|vig-?rx|zyban|valtex|xenical|adipex|meridia\b)[\w\-_.]*\.[a-z]{2,} (magazine)[\w\-_.]*(finder|netfirms)[\w\-_.]*\.[a-z]{2,} (mike)[\w\-_.]*apartment[\w\-_.]*\.[a-z]{2,} (milf)[\w\-_.]*(hunter|moms|fucking)[\w\-_.]*\.[a-z]{2,} (online)[\w\-_.]*casino[\w\-_.]*\.[a-z]{2,} (paid|online)[\w\-_.]*surveys[\w\-_.]*\.[a-z]{2,} (prozac|zoloft|xanax|valium|hydrocodone|vicodin|paxil|vioxx)[\w\-_.]*\.[a-z]{2,} (puss(ie|y)|adult|sex|fuck|suck|cock|virgin)\S{0,15}\.info/ (ragazze)-?\w+\.[a-z]{2,} (ultram\b|\btenuate|tramadol|pheromones|phendimetrazine|ionamin|ortho.?tricyclen|retin.?a)[\w\-_.]*\.[a-z]{2,} (valtrex|zyrtec|\bhgh\b|ambien\b|flonase|allegra|didrex|renova\b|bontril|nexium)[\w\-_.]*\.[a-z]{2,} \.(chat|boom|fromru|hotmail|newmail|nightmail|nm|narod|pochta)\.ru \.[0-9]{5,}\.(com|net|org|us|biz|cn|ru) \.4t\.com \.51\.net \.6x\.to \.a\.la/ \.b3\.nu \.cameroun\.ws \.flywebs\.com \.free-25\.de \.gb.com \.hostrim\.com \.qn.com \.sbn\.bz \.shell\.la \.static\.net \.t35\.com \.uk\.to \.uni\.cc \.w28\.org \.wol\.bz \.wtf\.la \.xs3\.com \.ya\.com \.yadoo\.cn \bda\.ru\b \bde\.gg\b \bde\.nr\b \bde\.tc\b \bde\.tp\b \bgo\.ro\b \w+\.sh\.cn 0008888.com 000site\.com 0020.net 0030.net 00freehost\.com 01-beltonen.com 01-klingeltoene.at 01-klingeltoene.de 01-loghi.com 01-logot?.com 01-logotyper.com 01-melodias?.com 01mobile.com 01-ringe?tones?.com 01-ringe?tones?.us 01-ringsignaler.com 01ringtones.co.uk 01-soittoaanet.com 01-suonerie.com 01-toque.com 0adult-cartoon.com 0cartoon.com 0cartoon-sex.com 0catch.com 0livesex.com 0sex-toons.com 0sfondi.com 0sfondi-desktop.com 0suonerie.com 0toons.com 0xxx-cartoon.com 1000\-celebs\.com 100comm.com 100hgh.com 100-sex.com 100megsfree5\.com 108bikes.com 110fat.com 11126.com 123-sign-making-equipment-and-supplies.com 125mb.com 125we.com 148-law.com 150m\.com 158hk\.com\.cn 163ns.com 163school.com.cn 168Education.com 168marketing.com 168wire.com 16safe.com 17train.com 1816.net 18caixin.com 18ny.com 18show.cn 1accesshost\.com 1afm\.com 1asphost.com 1-bignaturals.com 1concerttickets.com 1-cumfiesta.com 1domiks\.org 1ebalo\.org 1foleks\.org 1footballtickets.com 1golod\.org 1hrens\.org 1ibanusiks\.org 1jolla\.org 1-klingeltone.com 1so.com.cn 1so\.net\.cn 1st-(auto-insurance-4u|phonecard|printer-ink-cartridge|shemale-sex).com 1st-host.org 1stindustrialdirectory.com 1stlookcd.com 1stop[\w-]*.com 1st-payday-loans.net 1sweethost\.com 1-texas-holdem.us 1und1-shopping.de 1-welivetogether.com 1-wholesale-distributor.com 1xp6z.com 2008travel.com 20fr.com 216.130.167.230 24-hour-fitness-online.com 269s.tinline.com 269s\.com 2ndmortgageinterestrates.com 2twinks.com 30-60-90-day-sales-plan\.com 321cigarettes.com 3333.ws 35tk\.com 365jp.com 3ccenter\.com 3host.com 3-sexy.com 3sheng.net 3sixtyfour.com 3yaoi.com 404host.com 41b.net 42tower.ws 4mg.com 4u-topshelfpussy.com 4womenoftheworld.com 5118.com 5118.net.cn 512j.com 5151office\.cn 51asa.com 51dragon.com 51nlp\.com 51weixing.com 51wisdom.com 51zhengxing.net 54eo.com 5782601.net 58798309dyb.com 591dy.com 625fang\.com 63174828.com 63dns.com 65.217.108.182 66.197.102.2 666house\.com 66battery.com 66cable.com 66cellphone.com 66ceramic.com 66floor.com 66interior.com 66logistics.com 66machine.com 66packing.com 66sculpture.com 66supply.com 66tools.com 68685633.com 68l.com 69.61.11.163 69yo.com 6p.org.uk 6x.to 71space\.[a-z]{2,} 7p.org.uk 8848flower.com 888cas.com 888jack.com 888steel.com 888-texas-holdem.com 88aabb.com 88feedstuff.com 88fiber.com 88telephone.com 8cx.net 8cx\.net 8k.com 8th\S*street\S*latina\S*\.[a-z]{2,} 911\.uni\.cc 9136\.cn 91dir.com 91xz.info 999777888.com/jkcy009 99bbcc.com 99caixin.com 99jl.net 9sf\.cn a1-mortgage-finder.com a-1-versicherungsvergleich.de a688.net aaaaaaaa.ru aaff.net aajj.net aaliyah\.ws aauu.net abc3x.com abcink\.com abnehmen-ganz-sicher.com abocams.de abymetro.org.uk ac8888.com academytrans.com accessories-car.com accompagnatrici.cc acme\-arts\.com acmetranslation\.com acornwebdesign.co.uk activeshow\.net acupuncturealliance\.org acyclovir.net ad.huwh.org aducasher.spb.ru adult\-categories\.info adult-dvds?-dot.com adultfreehosting.com adult-free-webcams.com adult-friend.info adultfriendfinder.com adultfriendfindernow.com adultfriendfindersite.com adultfriendsite.com adult-games.name adulthostpro.com adultlingerieuk.com adultnonstop.com adultpics.com adultserviceproviders.com adultshare.com advantage-quotes.com a--e.com aegean.net.cn aektschen.de aerohose.com aesthetics.co.il afreeserver.com agentsmax\.com agreatserver.com aids120.95.cn aimaiti.com aimite.com air520\.com airfare-links.net airshow-china.com.cn airtrip.com.cn akkx\.info alawna.blogspot.com alexanet.com alfago.com alhaurin.to all-debt-consolidation.org allfind.us all-fioricet.com allinsurancetype.com allmagic.ru allof.myphotos.cc alloha.info allohaweb.com all-porn.info all-rxdrugs.com all-we-live-together.com allwoodoxford.com almacenpc.com alprazolam-online.qn.com amateur-(lesbian|movie|naked|site).us amateurs.r00m.com amateursuite.com amateurs-xxx.us amateur-thumbs.net ambien-online-order.zx81.at ambien-prescription.qn.com americacashfast.com americancdduplication.com americanpaydayloans.net american-single-dating.com amoxicillin-online.net amoyplastic.com anacondasex\.info analloverz.com anal-sex-pictures.us anchuang.com.cn andyedf.de angenehmen-aufenthalt.de angrybirdsblog\.com animalsex-movies-archive.com animalsex-pics-gallery.com anime1.org anime-adult.us anlinet.com annuaire.biz.ly annuaire.tk anonymous-blogger.com antely.com anti-exploit.com antu.com.cn anxietydisorders.biz anything4health.com anzwers\.net anzwers\.org a-onedigitizing.com a-oneemb.com aotubang.com aotubangshi.net ap8\.com apa-redlion.com apicalsoft.com a-pics.net apollopatch.com appliances66.com apply-to-green-card.org appollo.org approachina.com approval-loan.com a-purfectdream-expression.com aquari.ru aquatyca.net arbat\.or\.at arcsecurity.co.uk area-code-npa-nxx.com argendrom.com armor2net.com aromacc.com arrecife.to arterydesign.com artsdeal.com asianbum.com asian-girls.name asian-nude.blogspot.com asian-sex-woman.com asp169.com ass-picture.us a-stories.com atetech.com.cn atkinsexpert.com auctionmoneymakers.com auktions-uebersicht.de austinlawteam\.com autodetailproducts.com autodirektversicherung.com autofinanzierung-autokredit.de autofinanzierung-zum-festzins.de autohandelsmarktplatz.de autoing.com\.cn autoing\.com\.cn auto-insurance-links.net autokredit-autofinanzierung.de autokredit-tipp.de auto-loans-usa.biz automotive.com autoversicherung-vergleichen.info autumn-jade.com avon-one.com awxk.net ayamonte.to ba2000.com babes-d.com babes-maidens\.info babes-plus.com baby-info\.org babymarktplatz-aktiv.de baby-perfekt.de background-check.info bad-movies.net bad-passion.com bahraichfun.com baidublog.com baifaa.cn balancingmachine.cn bali-dewadewi-tours.com balidiscovery.org bali-hotels.co.uk balivillas.net banialoba3w.150m.com bannedhome.com banned-pics.com barbate.to barcelona.to barcode555.com barcodes.cn bare.org barely-legald.com barely-legal-teenb.com bargeld-tipp.de barrym.co.uk bast3.ru batukaru\.[a-z]{2,} bayareabags\.com bbell.com bbs.csnec.net bccec.com.cn bccinet.org bc-printer.com bdi-bone.com bdsensors.com.cn bdsm-story.blogspot.com beast(iality|sex)-(movies|stories|animal-sex-stories).(com|net) beaumont-bar.co.uk beauty333.com beauty-farm.net beautysilk.net beer-china.com beijingkh.com belinking.com beltonen-logos-spel.com benalmadena-costa-del-sol.to benavista.to benessere.us benidorm.to bestasianteens.com best-buy-cialis.com best-cialis-source.com bestdvdclubs.com bestel.com.cn besthandever.com best-high-speed-internet.com bestialitylinks.org bestiality-pics.org bestialityzoo.sytes.net best-internet-bingo.com bestits.net best-make-money.com bestonline-medication.com bestonline-medication.net bestonline-shopping.com best-result-fast.com bet-on-horseracing.com better-56.com beverlyhillspimps?andhos.com bhs-design.com big-(black-butts|breast-success|hooters|natural-boobs|naturals-4u).(com|net|us|org) big(bras-club|moms|titchaz).com bigmag.com.ua big-rant.com bigsitecity.com bigxigua\.com bildmitteilung.us billigfluege-billige-fluege.de billleo.com bio-snoop.com birth-control-links.com bizhat.com bizhome\.org bj-?(acca|erwai|fusheng|fyhj|hchy|hsdx|cas|gift|khp|xhjy|sd|zufang).(cn|com) bj701.com bjdyzs\.com bjerwai.com bjfusheng.com bjhsdx.com bjicp.net bj-page.com bj-qsan\.com bjsister.com bjxin\.com bjzyy.com black-?jack-?(4u|777|dot|homepage|play-blackjack|site|winner)?.(net|com|fm) black-amateur-cock.net blackjack-123.com blackjack-p.com blahblah.tk blanes.to b-liver.com blk-web.de bllogspot.com blog.co.tz/dexters blogbus.com blogcn.com blogforbaby.com/blog/deepsea blogforbaby.com/blog/jbilder bloggersdream.com/ahorcar bloggersdream.com/emscience bloggingmadness.com/aufmerksamkeitsdefizitsyndrom bloglabs.biz blogman.biz blogmen.net blogspam.org blogspoint.com/kostas blogspoint.com/marklanegan blogstudio.net blog-tips.com blonde-(pussy|video|xxx).us blumengruss-onlineshop.de blumenshop-versand.de b-mailbox.com bnuol.com bochao.com.cn bodet-clocks.co.uk body-jewelry.reestr.net bodyjock.com body-piercing.softinterop.com bokaibj.com bolonia.to bondage-story.blogspot.com bon-referencement.com boobmorning.com boobspost.com booking-room.com book-translation\.com boom.ru boom\.ru boylaser\.com breast-augmentation.top-big-tits.com briana-banks-dot.com british-hardcore.net brownlion.com.cn brrddd.org budget-phonecards.co.uk bueroversand-xxl.de bugaboo-stroller.com buildermax\.com bulkemailsoft.com burda\.isgre\.at burningcar.net businessbloging.com/benzaldehyde businessbloging.com/gesetz business-grants.org butalbital.org butianshi.com buy.*\.qn\.com buy-[\w-]+-online\. buy-adult-sex-toys.com buy-adult-toys.biz buy-ambien.8bit.at buyambienonline\.blogspirit\.com buy-car-insurance-4-us.com buy-carisoprodol\.qo\.pl buy-cheap-soma\.ar\.gs buy-cialis.ws buy-cialis-1.qn.com buy-cialis-online.qn.com buy-codeine.bebto.com buy-codeine.qn.com buy-codeine-online.b3.nu buy-computer.us buy-computer-memory.net buy-discount-airline-tickets.com buy-hydrocodone.qn.com buy-hydrocodone-online.sinfree.net buy-hydrocodone-online.u4l.com buyhydrocodonewhere.bigsitecity.com buy-laptop.biz buy-levitra-1.qn.com buy-levitra-online.qn.com buy-order-cheap-online\.info buyphen375reviews\.net buy-rx-usa.com buy-sex-toys.net buystuffpayless.com buy-valium.imess.net buy-valium.qn.com buy-valium-online.enacre.net buy-vicodin.dd.vg buy-xanax.qn.com buy-zolpidem.qn.com buzz-hotels.co.uk bvicr\.cn b-witchedcentral.co.uk by-and-by.com byondart\.com byronbayinternet.com c911c\.com cabopino.to cadaques.to cadiz-andalucia.to cai4\.com caipiaowangzhi.com calahonda.to california.k9.pl callingcardchoice.com calling-phone-cards\.org calpe.to cambridgetherapynotebook.co.uk camemberts.org camera-cn.com canada-travel.cn canos-de-meca.to cantonfairhotelguangzhou.com cantonfairhotelguangzhou\.com cantwell2000.com CAPAZ MESMO, ISTO E UM FATO MALUCO capital-credit-cards.com captain-stabbin.blogspot.com captain-stabbin-4u.com cardsloansmortgages.com careersmax\.com car-financing-low-rates.biz car-fuck.net carcoverspal\.com carinsurancecomparisonhelp\.com carisoprodol.q03.net carisoprodolonline.bigsitecity.com carlack.cn carmenblue.com carnalhost.com carnumbers.ru car-rental-links.com car-rentals-2go.com car-rental-search.com cars-links.com cartama.to cartoni(-animati|erotici|giapponesi).com cartopia.com cashadvanceclub.com cash-advance-quick.com cashmerebiz.com casillas-del-angel.to casoft.com.cn castingagentur2004.de cast-shadow.com cat-guide\.org cbitech.com ccie130.com ccie-ccnie.com ccna130.com ccna-ccna.com ccnp130.com ccnp-ccnp.com cd21\.cn cdshop-guenstig.de cds-xxl.de cebooks.net cegcr\.cn celebritylust.blog-city.com celebritypics.ws celebskin.com celebtastic.com cell-phone-accessories-dot.com ceool\.cn ceramic168.com certificationking.net certified-(new|used)-(autos|cars|suvs).com cfeenet.com changweia.cn chaosmagic.com/weblog/catastrophic chaseonlinebankingcom\.com chat\.ru chat-l.de chatten.bilder-j.de chauffeurtours.co.uk cheap.*\.6x\.to cheap-4.com cheap-adult-sex-toys.com cheap-ambien.qn.com cheap-cialis.qn.com cheap-cigarettes.com cheaper-digital-cameras.uk.com cheapest-phone.co.uk cheap-levitra.qn.com cheap-valium.my-age.net cheapvpn\.org cheap-web-hosting-companies.com cheap-xanax.qn.com chem888.com cherrybrady.com chickz.com \.china\.com china0519.com chinaad-design.com china-af.com chinaaircatering.com china-am.com china-apt.com chinaaxletree.com china-cp.com china-digital-camera.com china-dope.com chinagoldcoininc.com chinahr.com chinalatex.com chinaqygl.com chinasensor\.info china-sports-kit.com chinaswk.com china-transformer.com china-vcr.com chinaw3.com china-wood-floor.com china-wp.com chindata.com chindmoz.com chipiona.to chloesworld.com choose-online-university.com chrislaker.co.uk chuanganqi.dzsc.com chuanqisuji.com chunmeng.com cialis.homeip.net cialis.incredishop.com cialis.xs3.com cialisapcalis.com cialis-buy.com cialis-dot.com cialis-express.com cialis-online.b3.nu cialis-online-1.qn.com cialisusa.bravehost.com ciscochina.com citicardscom\.net claireburgos.com clamber.de clanbov.com clarks-shoe.u4l.com classifiche-italiane.org claudiachristian.co.uk clayjames.com cleannbright.co.uk click\.hn\.org click-or-not.de clophillac.org.uk closed-network.com club69.net cmeontv.de cmmdc.com.cn cn80051.1816.net cnbess.com cnbjflower.com cn-clothing.com cn-computer.com cndevi.com cn-dynamotor.com cn-exhibition.com cn-fashion.com cnfibernet\.com\.cn cnfti.org.cn cngreat\.net cn-present.com cn-press.com cn-Satellite-tv.com cnsec.cn cntaiyangneng.com cntoplead.com cn-vcr.com cnvideomeeting.com co.tradeinfo.cn codeine.xs3.com codeine-online.imess.net coin-abndalucia.to college-girl-pic.com college-links.net coma-cn.com combaltec.com comeback.com cometo(japan|malaysia|singapore|thailand).com commovie-china.com competa.to completelycars.com completelyherbal.com comptershops-online.de computer666.com computer888.com computer-onlinebestellung.de computer-und-erotische-spiele-download.com computerversand-xxl.de confession-of.mine conil.to conjhost.com container-partner.de contake.com cool\.as cool-extreme.com coolgoose.com coolhost\.biz coolp.(biz|net|org) copy168.com cor-admin.co cor-admin.com coresleep.com cornishholidaysuk.com cosmetics2008.com cosmetics666.com costa-blanca-alicante.to costa-blanca-denia.to costa-blanca-elche.to costa-blanca-ibi.to costa-blanca-javea.to costa-blanca-torrevieja.to couponmountain.com cover-your-feet.com cpravo.ru cqychy.com craftwork2008.com cragrats-catering.co.uk cragrats-education.co.uk cragrats-inspiring.co.uk cragrats-react.co.uk cragratstraining.co.uk crazypussy.info crazyvirgin\.info creavic.com.cn creditcardpost.com credit-factor.com credit-links.net credit-report-links.net csnec.net cstarcom.com cszg\.net cum-facials.us cumfiesta-4u.com cumon.no-ip.org customer-reviews.org cvdiy.com cvdiy\.com cw92013.chinaw3.com cxcn\.info cyberfreehost.com cycatki.com cyclobenzaprine.00freehost.com cyclo-cross.co.uk cykanax.com czwin.com.cn dad-daughter-incest.com dadi009\.91\.tc dahongbao.com dailyliving.info damadaoju.com damianer.top-100.pl danni.com dapt\.org darest.de datasoon.com datestop.net dating-(choice|harmony|service-dating|services-dating-service).com dating999.com dating-online-dating.org day4sex.com deathblow debt-consolidation-care\.com debtconsolidationfirm.net debt-consolidation-kick-a.com debt-consolidation-low-rates.biz debt-consolidation-now-online.com debtconsolidationusa.org debt-disappear.com debtmanagementcompanyonline.com debt-solution-tips.com decorationsexport.com dedichepersonali.com deep-ice.com deikmann.de dela88.com delay-dva.com deli.net.cn dentalinsurancehealth.com department-storez.com desiraesworld.com destindia-internships\.com deutschlandweite-immobilienangebote.de devonanal.com devon-daniels.com diabetes-cn.com dianepoppos.com dianying8.net diarypeople.com diecastdot.com digitale-teile.de digital-projector.net dindon.cn dinmo.net directcarrental.com directcti.com directrape.com directringtones.com direct-tv-for-free.com dirty-story.blogspot.com discount-airfares-guide.com discount-cheap-dental-insurance.com discount-life-insurance.us discountprinterrefill.com discoveryofusa.com divorce-links.com dlctc.com dmoznet.com dmoznet.net dmoznet.org dnip.net dn-register.com dns\.com\.cn dns110.com do\.9jh\.com dogolz\.de domkino\.com\.ua dongdao\.net dont-lost-money\.info doo\.pl door168\.com dorka\.ifindex\.com dostweb.com dotas.com dotcomup.com dotmoment.com downloadzipcode.com downsms.com dr\.ag dragonball-?x*.biz dragonball-?x*.cc dressagehorseinternational.co.uk dress-cn.com drive-backup.com drochka.com drozd\.voxelperfect\.net drs.infosec.org.cn drugsexperts.com drugstore.blog-city.com drugstore.st drugstore-online.us drunk-girls-(flashing|party).(com|us) drupaliciousbot\.com dstmedia.com dudoctor\.com duducat.com dunecliffesaunton.co.uk duvx\.com/bbs\.php?bbs=vs dvd2.us dvd-copier.info dvd-home-theatre.com dwoq.com dzhsc.com e40.nl earphone168.com easy-money-investing.com easyrecorder.com easyseek.us ebackground-checks\.com ebaybusiness.net ebony-xxx.us ebookers.co.uk e-bookszone.com ec198.com ec51.cn ec51.com ec51.net ec51.org ec91.com ecar-rentals\.com ecblast.com eccentrix.com/members/casinotips echinabid.com echinabid\.com echofourdesign.com e-cialis.net ecologix.co.uk e-credit-card-debt.com ecredit-report\.com eden\.fx120\.net e-discus.com e-dishnetworks\.com edrugstore.md edwardbaskett.com effexor.cc effexor-web.com e-fioricet.com e-free-credit-reports.com eggesfordhotel.co.uk egyway.com einfach-wunschgewicht.com elcenter-s.ru eldorado.com.ua electromark-uk.co.uk electronics-info.com elegant-candles.com elektronikshop-xxl.de elie\.com\.cn elite-change.com elitecities.com eliulin.com elrocio.to elviria.to emedicalmarijuanacard\.com emmasarah.com emmss.com enacre.net ena-free-show\.info endns.net e-news.host.sk enine-pv.com envoyer-des-fleurs.com e-online-bingo.com eonsystems.com e-order-propecia.com epackshop.net e--pics.com eplastic-surgery\.com e-play-bingo.com epsystem.net erbium12.com erosway.com erotic4free.net eroticalservers.net erotic-free.com erotic-lesbian-story.blogspot.com erotic-video.us erotische-geschichten-portal.com errolware.com escort-links.net escorts-links.com eScrew is esmartdesign.com esmoz.com estepona.to ethixsouthwest.com etoo.cn etowns\.org e-tutor.com eutstore\.com evanstonpl.org event-kalendarium.de everyvoice.net evromaster.ru exdrawings.com execsoft-software.co.uk executive-chauffeur-hire.co.uk ex-machine.com exoticdvds.co.uk exoticmoms.com expatdream.com/blog/aclarar experienceflagstaff.com/blogs/xzchro extralife\.biz extrasms.de extreme-rape.org extreme-sex.org eye-laser.co.uk f2g.net f2s.be fabida.net fabricant-accessories.co.uk fabulos.de fabuloussextoys.com facial-skin-care-center.com fairchild.com.cn fairland.cn fairyblog.com/conect fakir\.zenno\.info family-incest.us fangso\.com fansjiaoab.blog.163.com fantasyfootballsportsbook.com farm-beastiality.com farmsx.com fasa\.jetco-ops\.com fashuo300.com fast-look\.com fast-fioricet.com fast-mortgage-4-u.com fat-cash.com fateback.com fat-lesbians.net fat-pussy-sex.net fatty-liver.cn fatwarfare.com favilon.net fda.com.cn fdl.net.cn feexpert.com feilun.com.cn female-orgasms.org ferta\.imlds\.com fielit.de figa.nu finance-world.net finanzen-marktplatz.de find-a-mortgage.co.uk findbookmakers.com find-cheap-dental-plans.com finddatingsites.com findsexmovie.info findsexxx.us find-u-that-mortgage.com findyouruni.com finger-bobs.com fioricet.batcave.net fioricet.bravehost.com fioricet.st fioricet-dot.com fioricet-web.com firefoxdownload\.us first-time-story.blogspot.com fishoilmiracle.com fitness-links.net fitnessx.net fittest\.250m.com flash77.com flatbedshipping.com fleet-drive.co.uk fleshlight.org flewblog.net flexbelthq\.com flexeril-web.com flirt08.de floraday\.com\.cn flowertobj.com flowerwish.com flug-und-mietwagen.de fly-sky.com fm360.net food-cn.com football-betting-nfl.com forceful.de forex.inc.ru forex[\w-]*\.info forex-online-now.com forlovedones.com forseo\. foto-gay.us found-money-investment.info franchise\.ws frangelicasplace.org frankpictures.com free(hostingpeople|webs|web-hosting).com free-adult-chat-room.com free-adult-check.com freeallsearch.com free-britney-spears-nude.biz free-debt-consolidation-online.us freedvdplayer.cjb.net freeeads.co.uk free-fast.net free-games-links.com free-gay-video-clip.com free-hilton-paris-sex-video.com free-horoscopes.biz free-incest-stories-site.com free-latina-mpg.com freemovie-cn.com free-net-sex.com freenetshopper.com freenudegallery.org free-paris-nikki-hilton.blogspot.com freepicsdaily.com free-registry-cleaners\.biz free-satellite-tv-directv-nocable.com free-satellite-tv-now.com freeteenpicsandmovies.com free-teens-galleries.com free-texas-?hold-?em.(biz|us) freewebpage.org freewhileshopping.com freshsexhosting.com friko.pl fromru.com fspv.com fssj.com fsyflower\.com fuck\-my\-ass\.info fuck-animals.com fuckfrompussy\.info fuelcellmarketplace.co.uk fuel-dispenser.com fuengirola-costa-del-sol.to fuerteventura.to fuhaidasha.com.cn fulongcn.com funasia.cn funmod.com funny-girls\.info fun-spass-game.de.ms furensteel.cn furensteel\.cn furniture135.com furrios.de furry-kinks-looking.com furry-kinks-looking.net futurenet.com.cn fzrr.com gagnerargent.com gals4all.com galsonbed.com gamble-on-football-online.com gambling\Sgames.cc gamefinder.de games-advanced.de gang-rape.org gangxing.com gaokao.net.cn garment-china.com garrywa.com gartenshopper.de garthfans.co.uk gaucin.to gay-b.com gaybloghosting.com/kushi gay-boy.us gayfunplaces.com gayhomes\.net gay-male-story.blogspot.com gay-nude.us gay--sex.org gay-sex-videos.com gays-sex-gay-sex-gays.us gay-twinks-sex.com gayx.us gcchq.com gdgc.org gelago.de gem2.de gemtienda.co.uk generic-ambien.qn.com generic-cialis.qn.com generic-levitra.qn.com generic-propecia.net generic-valium.512bit.at genimat.220v.org genimat.cjb.net geocities.com/alexgolddphumanrbriar geocities.com/avbmaxtirodpaulmatt geocities.com/brandtdleffmatthias7 geocities.com/cclibrannar_rover geocities.com/constpolonskaalniko7 geocities.com/forestavmiagdust geocities.com/free_satellite_tv_dish_system geocities.com/ofconvbdemikqfolium geocities.com/pashkabandtvcom geocities.com/pautovalexasha_kagal geocities.com/reutovoalexeypetrovseverin5 geocities.com/timryancompassmedius gerardoknutson.com germanytek.com gesundheitsshop-kosmetik.de gesundheit-total.com getapussy\.info get-cell-phone-accessories.com getdomainsandhosting.com get-free-catalogs.com get-freetrial.us get-hardcore-sex.com gethelp24x7.net get-insurance-quotes.com getitip.org getmoregiveless.com getrxscripts.biz get-satellite-tv-dish.com getstarted24x7.net getyourlyrics.com get-zoo.com gghggh.com gguu\.com ghettoinc.com giantipps.de gifs-clipart-smiley.de gilerarunner.8m.com giochi-online.us giochix.com girls\-pussies.info girlshost.net girlswantsmore\.info girls-with-cunts\.info giveramp.com give-u-the-perfect-mortgage.com glass8888.com glendajackson.co.uk global-phonecard.co.uk globalsearch.cn global-verreisen.de globalwebbrain.com globalwiremesh\.com glory-vision.com gloveboxes.com.cn gloveboxes\.com\.cn go.nease.net godere.org gogito.com gogoogle.net gogt\.info gojerk.com goldbuyerstrust\.com goldenholiday.com goldsenze\.com golfhq\.org gomvents.com gongi.pl gonzalesltd.com goodasses\.info goodlife2000-geheimtipp.com goodsexy.com goodwebsite.org/blog/elrincondelvago google8.net googleandbaidu.com googlebaidu.com googlepromotion.com google-seo.net googlesweb\.com googletosh.com go-pussy.titanhousing.com gotobiz.net gotooa.com government-grants.org government-grants.ws gpo4.com gpsplanet\.org grafit\.zenno\.info grancanaria.to grannypictgp.com grannysexthumbs.com great-cialis.com greatnow.com greecehotels-discount.com green-gradens\.org green-tx.com greewon\.com\.cn grinding-mill.net group-eurosex.com gt-lite.com guadalmina.to guardami.org guenstige-(krankenversicherung|onlineshops|sportartikel|versicherungstarife).(com|de) guizang.net guttermag.com gyhx.com gym-equipments\.org gyrohost.com/iboga h1\.ripway\.com/xz h2kmatrix.com haidianjiaxiao.com hainan35\.com hair-loss-cure.net hairy-pussy-sex.net haishun.net hallo-tierfreund.de hand-job.us handwerksartikel-xxl.de handy-klingeltoene.eu.tp handylogos-klingeltoene.net.ms handysprueche.de handytone.us hangchen.cn hangchen.com haole\.cn happyagency.com happy-shopping-online.com hardcore-(jpg|junky|pictures|pussy|sex|video).(com|us|bz|net) hardcorecash.net hard-sex-teen.com hardware123.com hardware888.com hartsflorist\.com haugeprint.co.uk hautesavoieimmobilier.com hchcinc.com hddata.com hdfix.com.cn headachetreatment.net healthmore.net healthrules.org heartbeatofhealing.org heavytools.webzdarma.cz heb-shuntong.com hebu.myrice.com hello\.to hentay.us herpies.net hewittlandscapes.co.uk heydo.com hg-fix\.com hgxweb.de high-risk-merchant-account.org hilton-nicky-paris.blogspot.com hion.cn hit168.net hit-melodias.com hits?-logos?-(games|klingeltone?|ringe?tone|suoneria).com hitslogosgames.com hjsos.com hk99689.com hk99w.com hkfor\.cn hkfor\.com hkfor\.net hkfor\.org hksaa\.net hksac\.org hlduanjian.com hmlaser.com hmxuan.com hnhqmj\.com hobbs-farm.com hogwatch\.org hold-em-big.com hold-pok.com hold-screen.com home.soufun.com home\.ro\b home\-trade\.net home4web.org/(hainan|fanguangcailiao|gongzuofu|niupixian|tuozhan) home-business-ideas-investment.info home-business-investments.info home-internet-business-investment.info homelivecams.com homenetworkingsolutions.co.uk home-secure\.org home-videos.net hongkong\.richful\.net hongkongcompanyregistry\.com horny-honey.com hornymoms.net hornypages.com horny-world.com horoskop-auswertung.de horse-racebetting.com horse-sex.ws hospitalonline\.cn hosting-server\.net hostingplus.com hostultra.com hotchina.org hot-cialis.com hotel\.altse\.com hotel\.netsuns\.net hotelbookingserver.com hotel-bordeaux.cjb.net hotelsaficionado.com hotelsplustours.com hot-escort-services.com hotfunsingles.com hot-mates.info hotmoko\.info hot-naked-guys.net hotsexys.com hotusa.org house222.com house263\.com houseclub.com.cn how-quit-smoking.com how-to-make-money-investment.info howtomakedubstep\.co\.uk hp-ibm.com hs168.com ht-sensor\.com https?://[^/\n]*8k\.com https?://[^/\n]*ap8\.com https?://[^/\n]*bare\.org https?://[^/\n]*danni\.com https?://[^/\n]*doo\.pl https?://[^/\n]*dr\.ag https?://[^/\n]*e40\.nl https?://[^/\n]*f2s\.be https?://[^/\n]*it\.tt https?://[^/\n]*t35\.com https?://[^/\n]*via\.net huafei7.cn huahuan.com hua-shun.com.cn huazhangmba.com huelva.to huihualin.com human-cn.com humangrowthhormone.org hunksandbabes.com hustler.bz hustlerw.com huyprossish\.pcadsl\.com\.tw hydrocodone.webzdarma.cz hydrocodone-online.hotusa.org hydrocodone-without-prescription.enacre.net hyip[\w-]*\.(info|com) hyper-sex.com hypnobabies.co.uk hzjl365.com hzn.cn ialmostdied\.com ibiza-island.to i-black-jack.com i-butalbital-fioricet.com i-buy-mortgage.com icpcn\.com idc2008\.cn idebtconsolidation.org i-directv.net i-dish-network.org ie\.isoso\.info i-flexeril.com ifreepages.com ig3.net ihongtai\.com i-horny.com i-ink-cartridges.com illegalhome.com illegalspace.com imeanit.org imess.net imitrex-web.com immobilien-?(auswaehlen|angebote-auswahl|makler-angebote|makler-l|-l).de immobilienmarkt-grundstuecke.de immobilierdessavoie.com immodev.com im-naked.com Imobissimo.com i-mortgage-online.com important\.as impotence-rx.biz incest-?((pics|photos?|stories|movies|videos)-?(collection|download|gallery|archive|library)?|reality|relations|taboo).(com|biz|net|ws) incest[0-9]\.org incest-pics--incest.com incest--stories.org inc-magazine.com incredishop.com indiainfotech\.com indiasilk.biz indiasilktradition.com industrialresource.biz industrial-testing-equipment.com i-need-money-ideas.info inescudna.com inexpensiverx.net infopoint.cn inforceable.com inforceables.com innfg.de insatax\.com insatiablepussy.com inspection-trips.com insurance.*\.go\.ro insurancehere.net insurance-quotes-fast.com interealty.es international-candle-shop.com international-cheese-shop.com internet-explorer\.ws internet-goulasch.com internette-anbieter.de interphone555.com interracial-sex.ws inter-ross.ru interseo\.com int-fed-aromatherapy.co.uk in-the-vip.org inthevip-4u.com inthevip-sex.com intking.com intlcr\.cn intlcr\.com intlcr\.net intlcr\.org intymnie.com investing-get-rich-quick.info investments-free-money.info inviare-mms.net invio-mms.us Invite-cn.com i-online-bingo.com ipaddressworld.com i-play-bingo.com i-play-blackjack.com ipmotor.com ipodnano\.cn ipodshop\.cn ipsnihongo.org iqwork.com irianjaya.co.uk isgre\.at i-shemale.com i-skelaxin.com islacanela.to islacristina.to isla-fisher\.com islantilla.to i-soma.net isourceindia.com isparkl.com ispycameltoe.com i-texas-hold-?em.(biz|com|info|us) itisok\.net it-mgz.ir/forfamilies itzhongguo.com iul-online.de i-university-guide.com ivoryvaughan.com iwebbroker.com i-wellbutrin.com i-will-find-the-best-mortgage-lead.com i-win-bingo.com iza.net/ jack-x.com jade.bilder-i.de jandia.to japan-partner.com jbbjcc.com jerez.to jewelry4navel.com jewelry666.com jforce.no-ip.org jgc-network.co.uk jgzhutanfang.com jhhkw.com jhyujik\.org jiadian666.com jialicn.com jialicn\.com jieju-china.com jingtong\.com.cn jinlong.co.uk jinxique.com jinyibei.com.cn jinyuetuan\.cn jipu.com.cn jk-999.com jnqidong.com jobbnu.com job-interview-questions-tips.com joes\.com johnhowesatty.com join-2008.com joinin-cn.com jokeria.de jp114\.cn js-chenguang.com jualvccmurah\.com judahskateboards.com juliamiles.co.uk jungfrauen-sex.com junyuan.com.cn justasex.com juziku.com jzhrb.com.cn jz-machine\.com kamerry.com kangdachemical.online.sh.cn kangxin.com kantorg.h10.ru karibubaskets.com karma.za.pl karmicdebtconsolidation.com kcufrecnac.com keikoasura.com keithandrew.co.uk kewler.net kewl-links.com kickme\.to kickmy.com ki-disease.com kinggimp.org kinkyhosting.com kiranthakrar.co.uk kitehost.com/decoratie kktthhyy\.org kleinkinder-shop.de klingeltoene-handylogos.de.be klingeltone-logo.com klingelton-logos-mms.de klitoris.ca kln.com.cn kmsenergy.com kohost.us koihoo.com kontaktanzeigen-bild.de.ms kontaktlinsen-kaufen.de.ms kontaktlinsen-partner.de korol.lir.dk kostenlose-sexkontakte.org kraskidliavas.ru kredite-online.de.ms kredite-portal.de kredite-sofortzusage.de kreditkarten-sofort.de.ms kredit-ratenkredit-sofortkredit.de kuangye.net kupibuket.ru kyfarmhouse.org kyny\.net labelcan\.com lablog.biz lach-ab.de lajares.to lakesideartonline.com lalinea.to lambethcouncil.com landscape-painting.as.ro langsrestaurant.com lannygordon.com lannythurman.com lanreport.com lantai.com.cn lanucia.to laptopy.biz.pl laser-eye.co.uk laser-eye-centre.co.uk laser-eye-correction.co.uk lasikclinic.co.uk lastminute-blitz.de lasvegas-real-estate.net las-vegas-real-estate-1.com lasvegasrealtor.com lasvegastourfinder.com latina-sex.ws lavalifedating.com lavinuela.to law-translation\.com lcd-cn.com leadbanx.com leanmusclexreview\.org leather168.com leatherfamous.com lechery-family.com left-page.com legalblonde.com leonabruno.com lesbian-girl.us lesbichex.com leseratten-wunderland.de letemgo.de letomol\.com leveltendesign.com lexapro-web.com lgt-clan.ru liaozhi\.org lifedna.com life-insurance-advisor.com lifeinsurancefinders.com lifeslittle-luxuries.co.uk lifuchao.com light518.com likesmature.com lindsaylife\.com lingerie-guide\.org lingerie-land.com link-dir.com linkedin\.com\.cn linkliste-geschenke.de linseysworld.com linuxwaves.net lipitordiscount.biz lipitordiscount.com list1st.com listbanx.com livetexasholdem.com livetreff.tv livevents.de livingchina.cn lizziemills.com lkcx\.com l-king.com.cn lliippoo\.org lloret.to lnhbsb\.com loaninfotoday.com loan-king.com loans.de.vu loans-4all.com loan-superstore.com locationcorse.free.fr logical-planet.co.uk logod-helinad-mangud.com logoer-mobil.com logos?-(beltonen|downloads|free|klingeltone|max|melodias|mobiel|mobile-repondeurs?|moviles|phones|repondeurs?-mobile|spiele|tones?).com logosik.pl logos-logos.be logos-melodijas-speles.com logotyper-mobil.com lolita-bbs.name longcrossgroup.co.uk longslabofjoy.com longsuncard.com lookforukhotels.com lop\.t28\.net loraxe.com lotye\.schillerstudent\.com love.csnec.net lowclass.de lowcost.us.com lowest-rates-mortgages.com ltjz2000.com lucking.com.cn luffassociates.co.uk luxus-gourmetartikel.de lvrealty.net lygweb.com lynskey-admiration.org.uk lyriclovers.com ly-yufeng.com lzbiz\.com ma-cabinet.com machine168.com machine88.com macinstruct.net magus1.net mail333.com mainentrypoint.com mainjob.ru majorapplewhite.info make-money-investment.info malaga-costa-del-sol.to mallorca-island.to mallorycoatings.co.uk man.interhousing.com management666.com map666\.com marriage666.com marshallsupersoft.com marteq-on.com matalascanas.to match-me-up.com matureacts.com mature-big-tits.net maturefolk.com mature-old-mature.com mature-women\.enter-in\.etowns\.org maxigenweb.com maxxsearch.com mba100.com mbgeezers.com medcenterstore.com mediaaustralia.com.au medications-4all.com medicine-supply.com meds-pill.com medyep.com meetpeopleforsex.com mega-spass.com melincs.org melodias-logos-juegos.com melucky.com members.fortunecity.com/kennetharmstrong members.lycos.co.uk/tramadol menexis.com mengfuxiang.com menguma.co.uk menguma.com menorca.to men-sex.us menzyme.com meoko.com mewqsd.org mercedesazcona.com.ar mercefina.com merditer.com merlinworld.com mesothelioma-asbestos-help.com mesothelioma-health.com metroshopperguide.com mfdy8\.cn mhgzs\.com micrasci.com microscope-cn.com midi\.99caixin\.com mietangebote-domain.de migraine-relief.com mijas.to mikebunton.com mikewsd.org milesscaffolding.co.uk millionaire-blogs.com/cosmeticdentistry minxinghb.com missoula.com/blog/occupation misterwolf.net mmorpg-headlines.com mms.coay.com mmsanimati.com mneuron.com mobilefor.com -mobile-phones.org mobilequicksale.com mobile-repondeurs?-logos?.com mobilesandringtones.com mode-domain.de mode-einkaufsbummel.de molding-tool.com moltobene.ru momcare.com.cn monarch.com.cn moneybg.com money-room.com montaguefineart.com mookyong.com mooo.com mortage-4all.com mortgage-info-center.com mortgage-rates-guide.net mortgages-links.net mortloan.com mostika.us mother-son-incest-sex.net moto-cn.com motonet.pl motor2008.com movie-online123.com movies6.com mp3download.bz mp3plane\.com mp3x.biz mpeg2pci.com mqblog.cn/user1/jipiao mqblog.cn/user1/qiufeng mqfzj.blog.ccidnet.com mrpiercing.com mujweb.cz mujweb\.cz multipurpose-plants.net multiservers.com multivision.com.hk murcia.to musica-gratis.biz musica-gratis.org musica-karaoke.net musical88.com musica-mp3.biz musicamp3.us musiccheap.us music-downloads-links.com musicenergy.com muxa.ru mxbearings.com mxzt.com my.nbip.net/homepage/nblulei/ my-age.net myasiahotels.com mybestclick.com mybooktown.com mycv.cn mycv.com.cn mycv\.com\.cn mydatingagency.com my-dating-agency.com mydear\.biz my-discount-cigarettes.com myeuropehotels.com myfavlinks.de myflooring\.org mygenericrx.com mymistake.biz mymixture.com my-mom.kicks-ass.net myricenet.com myrtlejones.com myseo.com.cn [[MyServer|MyServer]].org my-sex-toys-store.com myslimpatch.com mystify2001.com naar\.be nabm(il|li)or.com nabpak.org naked-gay.us naked-pussy.us naked-womens-wrestling-league-dvds.com naked-womens-wrestling-league-videos.com nancyflowerswilson.com nanyangcn.net narod.ru nasty-pages.com natel-mobiles.com natural-barleygreen.com natural-breasts-enhancement.net naturalknockers.net navinic\.com nazari.org nbflashlights.com nbip.net ne1\.net nease.net nebulax.net necsi.com.cn neiladams.org.uk nemarov.com nerja.to netbank.cn netfirms.com netisc\.net netizen.org netlogo.us net-mature.com netnetn.com netsuns.net netsuns\.net netsx.org net-von-dir.de neurogenics.co.uk neverback.com new-cialis.com newfurnishing.com newgallery.co.uk newideatrade.com newsnewsmedia.com newxwave.com nextdayid.co.uk nfl-football-tickets.biz nicepages.(biz|net|org) nice-pussy.us niceshemales.net nichehit.com nicolepeters.com nieruchomosci.biz.pl nifty-erotic-story-archive.blogspot.com nikechina.net nikeproduct.com nikeshoesshop.com nikeshoeswholesale.org nikesupplier.com nikkiwilliams.info njhma.com njlvtong.com njningri.com njunite.net njuyq.com nnyykkii\.org no-1.com.cn no-1.org.cn no1pics.com no-cavities.com nohassle-loans.com no-more.dyndns.org noni-?(jungbrunnen|top-chance|vitalgetraenk|expert).com nonstopsex.org noslip-picks.com notebook555.com no-title.de notsure.de novacspacetravel.com novosanctipetri.to nr-challenges.org nude-(black|movies?|videos?).us nude-teens.name nudevol.us nuevaandalucia.to nutritional-supplements.ws nutritionalsupplementstoday.com nwwl-dvds.com nwwl-videos.com nz.com.ua office-021\.com office-stock\.com officialdarajoy.com/wwwboard officialdentalplan.com officialsatellitetv.com offseasonelves.com ohamerica.org okings.com okuk.org oldgrannyfucking.com oliva.to olsenstyle.com omega-fatty-acid.com omeida.com omniagroup\.it one-cialis.com one-debt-consolidation.com onepiecex.net one-propecia.com oneseo.com one-soma.com onexone.org online-?hgh.com online-auction-tricks.com online-blackjack-online.com online-buy-plavix.com online-casino.descom.es online-ccc.com online-credit-report-online.com online-dating-singles-service.com online-deals99.com on-line-degree.org online-dot.com online-escort-service.com online-flexeril.com online-games24x7.com online-games24x7.net online-games-links.net onlinehgh.com online-investing-ideas.info on-line-kasino-de.com online-medications24x7.com online-photo-print.com onlineshop.us.com onlinesmoker.com online-texas-?hold-?em.(net|us) on-pok.com opensorcerer.org operazione-trionfo.net oraengel.com oral-sex-cum.com orangeyogi.net order-?(claritin|effexor|medicine|naturals).(com|net) order-ambien-1.qn.com order-cialis-1.qn.com order-codeine.deep-ice.com order-levitra-1.qn.com order-valium-online.deep-ice.com orlandodominguez.com oro-compro\.com orospu.us otito.com ottawavalleyag.org ourhealthylife.net our-planet.org outoff.de ovulation-kit.com owaceilings.co.uk owns1.com ownsthis.com oxford-english.com oxgm.com p105.ezboard.com/bdatingpersonalsadultdating p5.org.uk p7.org.uk p8.org.uk p9.org.uk pack001.com packing-machine.com pafu.w4.dns2008.cn page.zhongsou.com pagerealm.com pages4people.com paidsurveysforall.com pai-gow-keno.com paisleydevelopmentassociation.org paite.net pajara.to pandoraaustraliastockists\.com pandorajewelryco\.com panpanddc.com pantandsocks.co.uk paperscn.com paper-translation\.com paris-(movie|naked|nicky|nikki)-hilton.blogspot.com paris-and-nicky-hilton-pictures.blogspot.com paris-hilton-video-blog.com paris-hilton-videos.biz parkersexecutivecar.co.uk partnersmanager.com partnersuche-partnervermittlung.com partybingo.com passende-klamotten.de passion.org.cn passwordspussynudity.com pastramisandwich.us pasuquinio.com paybacksh\.com payday-loan\.de\.com payday-loan-payday.com paydayloans-guide\.com paysites.info pbali\.com pc-choices.com pcdweb.com pcpages.com pcpages.com/abyssal pcvr.com.cn pdxx.com peak-e.com peepissing.com penase\.org penelopeschenk.com peoplegrad\.gen\.in perepug\.ig3\.net perfect-dedicated-server.com perfect-mortgage-lead-4-u.com personalads.us.com personal-finance-tips.com personalfitnesstrainer\.co\.za personal-writer\.com personals-online-personals.com petlesbians.com petroglyphx.com pety-viagra.newmail.ru pfxb.com phantadu.de pharmaceicall.com phente.m...\.do\.nu phentermine phentermine.webzdarma.cz phone-cards-globe.pushline.com phono.co.il photobloggy.buzznet.com phrensy.org pickevents.com pickone.org picsfreesex.com pics--movies.com pics-stories.com picsteens.com pictures-movies.net piercing-auswaehlen.de piercing-magic.com piercingx.com pill(-buy|blue|chart|hub|hunt|inc|tip).com pimp(fans|hop|hos|space)\.com pinkzoo.com pinnaclepeakrealty.com pj-city.com planetluck.com plastic168.com playandwin777.com playandwinit777.net play-cash-bingo-online.com player-tech.com playgay.biz playmydvd.com play-texas-hold-?em.us play-texas-holdem-today.net playweb.blogspot.com plazaerotica.com plcm.com.cn plygms.de pm.tsinghua.edu.cn pocket-pussy\.org poizen.info pokemonx.biz polifoniczne.org polott.org polyphone.us pompini.nu Ponderosa ponytest.com pops.pp.ru portedeurope\.org post.baidu.com posters?-?shop.us power-rico.de power-tools.rx24.co.uk predictive-dialers.org pregnancy-guide\.org pregnant\.sumale\.net pregnant-sex-free.us p-reise.de pre-machine.com prepaid-telephonecards.co.uk prepaylegalinsurance.com preteen-(models|sex|young).(biz|info|net) prettypiste.com princeofprussia.org printer-cn.com prism-lupus.org privacy-online.biz private-krankenversicherung-uebersicht.com private-network.net pro-collegefootballbetting.com product-paradise.com profifachuebersetzungen\.de projector-me.com promindandbody.com prom-prepared.com propecia.bravehost.com propecia-for-hair-loss.com propecia-for-hair-loss.net propecia-info.net propecia-store.com property2u.com property2u\.com prosearchs.com protech.net.cn psearch.163.com pseudobreccia60.tripod.com.ve psites.(biz|net|org|us) puertaumbria.to puertobanus.to puertoreal.to punksongslyrics.com purchase-ambien.qn.com purchase-valium.hotusa.org pureteenz.com pushline.com pussy-(d|cum|movies).(com|us) pussy\.the-best\.etowns\.org qd-heli.com qiangzhe\.cn qianyijia.com qingchundoua.cn qitao.wy8.net qj100\.net qm0?0[0-9]\.com qmnet\.cn qmwa\.com qqba.com qqmei.com quangoweb.com quickchina.com.cn quickdomainnameregistration.com quick-drugs.biz quick-drugs.com quickie-quotes.com qumingqiming.com.cn qybalancingmachine.com qz168.com qzkfw.co racconti-gay.org radsport-artikel.de raf-ranking.com ragazze-?\w+\.[a-z]{2,} rampantrabbitvibrator.co.uk randysrealtyreview.com ranklink.org rape-(fantasy-pics|stories).(biz|com) rapid-merchant-account.com ratenkredit-center.de ratenkredit-shop.de raw-pussy.us raymondmill.biz rbfanz.com readytocopy\.com real.net.cn real-estate-investment-online.info realestate-max\.com realforexbroker\.com reality-sites.com reality-xxx.biz real-sex.us realtickling.com real-worldinternational.co.uk rebjorn.co.uk recycle.myrice.com redcentre.org redi.tk refinance-mortgage-home-equity-loan.com reggaeboyzfanz.com reggdr.org registerxonline.com reglament-np.ru reisen-domain.de relay888.com relievepain.org relocationmax\.com rentalcarsplus.com repondeurs-logos-mobile.com republika.pl restaurant-l.de reviewonlinedating.com rfhk\.cn rfhk\.net rfhk\.org rfhz\.com rfhz\.net rfhz\.org ricettegolose.com richshemales.com rincondelavictoria.to ringsguide\.org ringsignaler-ikon-spel.com ringtone-logo-game.com ringtoner-logoer-spill.com ringtonespy.com rittenhouse.ca rituo.com riyao.com.cn roboticmilking.com roche.to romane-buecher.de romeo-ent.com ronda.to room-ordering.com roscoeluna.com rota-andalucia.to rotek.com.cn roulette---online.com roulette-w.com royaladult.com royalfreehost.com/teen/amymiller royalprotectionplan\.com rr365.net rrank.net ru(send|idea)\.com ru21.to ruilong.com.cn rx4.mine.nu rxbkfw.com rx-central.net rx-lexapro.biz rxpainrelief.net rx-phentermine.newmail.ru rx-store.com rxweightloss.org rydoncycles.co.uk safetytech.cn salcia.co.uk salearnerslicense\.co\.za sandrabre.de sanfernando.to sanlucar.to sanpedro.to santamaria.to sarennasworld.com satellite.bravehost.com satellite-direct-for-you.com satellite-network-tv.com satellitetv-reviewed.tripod.com saveondentalplans.com saving-money-hyip.info saw-blade.net sba\.com\.cn sbdforum.com sbn\.bz sbt-scooter.com scent-shopper.com schanee.de schmuck-domain.de scottneiss.net scpv.net screencn.com scuba-guide\.com s-cyclobenzaprine.fromru.com sd-dq\.com sdsanrex.com search.online.sh.cn search.sohu.com search-1.info search722.com search-engine-optimization-4-us.com searchfix.net sec66.com sec-battery.co.uk secureroot.org security-result.com seitensprung-gratis.com selectedsex.com selena-u.ru selten-angeklickt.de sempo-tahoe.com sense.com.cn sensor168.com seodetails\.com seov.net seoy.com servicesmax\.com se-traf.com seven-card-stud.biz seven-card-stud.us sevilla-andalucia.to sewilla.de sex-(4you|bondagenet|lover|photos).org sex(ushost|webclub|websites).com sex--.*\.com --sex\.com sex4dollar.com sexbrides.com sexcia.com sexe.vc sexforfree.webzdarma.cz sex-friend.info sexglory.com sexiestserver.com sexingitup.com sexjobsonline\.com sex-livecam-erotik.net sex-mates.info sexmuch.com sexo9.com sex-pic-sex.com sexplanets.com sex-pussy.us sexschlucht.de sexshop.tk sexshop-sexeshop.com sex-toys-next-day.com sextoysportal.com sexual-shemales.com sexual-story.blogspot.com sexvoyager.com sexy-(ass|babes|lesbian|pussy).us sexy-celebrity-photos.com sexy-girls.org sexy-girls\.org sexynudea.com sfondi-desktop-gratis.com sfondi--gratis.com s-fuck.com shadowbaneguides.net shannon-e.co.uk shareint-store.com sheffield800.freeserve.co.uk shellbitumen.com.cn shemalesex.biz shemalesland.com shemalezhost.com shemalki.com Shemok shengdanuclei.com shenman.com shfldz\.com shfx-bj.com shimiana.cn shinylights\.org shirts-t-shirts.com shluhen.lir.dk shoesbuynow.com shoeswholesale.cn shop.tc shop24x7.net shop263.com shop-opyt.com shopping-cn.com shoppingideen-xxl.de shopping-liste.de shoppyix.com showsontv.com sh-shengde.com shtestm.com shtravel.net shunfeng-pioneer.com sh-xinping.com simplemeds.com simpsonowen.co.uk sina.com.cn sinfree.net singtaotor\.com sinoart.com.cn sino-bee.com sinodragon.freewebpage.org sinostrategy.com sinski.com sister8.com site\.neogen\.ro/xy[\w]+/files/ps_imagini\.php site-mortgage.com sitesarchive.com site-webarea.com sjdd.com.cn sjlstp\.com sjzyxh.com skf-baijia.com skidman.com ski-resorts-guide.com slimmobile.org slmj.com slng.de slotmachinesguide.net slot-machines-slots.com slots-w.com slowdownrelax.com slpblogs.com/expenditure slutcities.com slut-wife-story.blogspot.com smartdot.com smartonlineshop.com smeego.com/gettext smerfy.pl smutwebsites.com sneakysleuth.com s-norco.fromru.com so18.cn socoplan.org sofortkredit-tipps.de sofort-mitgewinnen.de soft.center.prv.pl soft-industry.com softsenior.com softwaredevelopmentindia.com software-einkaufsmarkt.de software-engine.org software-linkliste.de softwarematrix\.org software-review-center.org sohublog.com soittoaanet-logot-peli.com sol-web.de soma-(cheap-soma|solution|web).com soma.st somaspot.com somee.com sommerreisen-2004.de sonderpreis.de.com songshangroup\.com sorglos-kredit.de sorry\.yi\.org sotogrande.to sou23.com soulfulstencils.com source.dyndns.dk sowang\.com/translation\.htm spaces.msn.com/members/wangluoyingxiao/ spacige-domains.de spannende-spiele.de spassmaker.de speedy-insurance-quotes.com spiele-kostenlose.com spiele-planet.com sportartikel-auswahl.de sportecdigital.com sportlich-chic.de sports---betting.com sports-inter-action.com spp-net.de spy-patrol.com spyware-links.com spzd\.com ss-cn.com s-sites.net ssy-web.com staffordshires.net stars-laser.com stationery555.com stationfoundation\.org statusforsale.de steel168.com steelstockholder.co.uk stellenangebote-checken.de stellenangebote-l.de stevespoliceequipment.com stfc-isc.org sting.cc stock-cn.com stock-power.com stolb.net stop-depression.com stopp-hier.de stopthatfilthyhabit.com stories-adult.net stories--archive.com stories-inc.com striemline.de strivectinsd.com stst-cn.com studychannels\.com stunningsextoys.com styrax-benzoin.com submit-your-cock\.info success-biz-replica.com suckingsex\.info sudian.com.cn suma-eintragen.de sumaeintrag-xxl.de sunbandits.com sunnyby.com suonerie-(center|download|loghi-gratis).com suonerieloghix.com suoneriex.net suoyan.com super-celebs.com super-cialis.com surfe-und-staune.de susiewildin.com sutra-sex.com svitonline.com swan-storage.com sweet-?(horny|hotgirls).com sweetapussy\.info swiftcashforgold\.com swinger-story.blogspot.com swing-in-golf.com swissking\.net switch168.com switch88.com sxcoal.com sydney-harbour.info sylphiel.org sylviapanda.com sysaud.com szpromotion.com t35.com t3n.org tabsinc.com t-agency.com taifudamy\.com tailongjixie.com take-credit-cards.com taliesinfellows.org talkie.stce.net talktobabes.com tamsquare.com tang\.la tanganyikan-cichlids.co.uk tangzhengfa.com tapbuster.co.uk taremociecall.com targetingpain.net tarifa.to tattoo-entwuerfe.de tb-china.com tcom-control.co.uk tdk-n.com teajk\.com teardust.net/blog/bulletingboard techfeng.com teen-(babes|movie|video|xxx).us teenblog.org/alerts teenblog.org/handicrafts teen-boys-fuck-paysite.com teen-d.com teens7ever.info teensluts.org teenxxxpix.net teflontape.cn tejia\.net\.cn telechargement-logiciel.com telematicsone.com telematiksone.co.uk tenerife-info.to terminator-sales.com terra.es/personal testersedge.com testi.cc tests-shop.com tette.bz tettone.cc teulada.to texas-hold-em-(4u|555|winner).(com|net) texas-holdem-0.com texasholdem777.net texas-holdem-a.com texas-holdem-big.com texasholdem-flip-flop.com texasholdemking.com texas-holdem-now.com texasholdem-online.us texasholdemsite.net texas-hold-em-w.com textile88.com tgplist.us the1930shome.co.uk the-bestiality-stories.stories-movies.com theblackfoxes.com the-boysfirsttime.com theceleb.com thecraftersgallery.com the-date.com thefreecellphone.com thehadhams.net the-horsesex.stories-movies.com the-hun-site.com the-hun-yellow-page-tgp.com themadpiper.net the-pill-bottle.com the-proxy.com thepurplepitch.com thepussies\.info therosygarden.com the-sad-diary-of.mine.nu thesoftwaregarage.co.uk thespecialweb.com thewebbrains.com thfh\.com thorcarlson.com thoth\.cn thumbscape.com thuriam.com tianjinpump\.com ticket88.com ticket-marktplatz.de tickets4events.de tiere-futter.de tiffany-towers.com tikattack.com timead.net timeguru.org timescooter.com tips-1a.de tire-cn.com tits-center.com tits-cumshots.net tjht.net tjht\.net tjtools.com tjwatch.com tl800\.com tldyjc.com tmrr.com tofik.pl tokyojoes.info toner-cartridge\.mx\.gs tontian.com tonzh.com topaktuelle-tattos.de top-cialis.com topcities.com top-dedicated-servers.com top-des-rencontres.com top-fioricet.com top-internet-blackjack.com top-of-best.de top-online-slots.com top-point.net top-result.com.cn top-skelaxin.com top-soma.com top-the-best.de toques-logos-jogos.com torch.cc torredelmar.to torremolinos-costa-del-sol.to torrox.to toshain.com tossa.to totallyfreecreditreport.org total-verspielt.de touchweb\.com\.cn touchwoodmagazine.org.uk toy-china.com traceboard\.com.cn tracyhickey.com tradeba.com tradeinvests\.cn tradeinvests\.org traffic4bidz\.com training-one.co.uk tran4u.com tranny-pic-free.com trannysexmovie.com transcn.net transestore.com transpire.de traum-pcs.de trendsbuilder.com treocat.com triadindustries.co.uk troggen.de troie.bz trolliges.de trucchi-giochi.us trueuninstall.com ts998\.com ts-wood.com tt33tt.com tt7.org ttuuoopp\.org tuff-enuff.fnpsites.com tumor-cn.com tuofaa.cn tv-bazzar\.com tygef.org tyjyllrj.go1.icpcn.com tykh\.com\.cn tzonline.cn ua\-princeton.com ufosearch.net ukeas.com uk-virtual-office-solutions.com ultracet-web.com ultraseek.us unbeatablecellphones.com unbeatablemobiles.co.uk unbeatablerx.com unccd.ch underage-pussy.net undonet.com unexpectedmovement.b4net.lt uni-card.ru universalplastic.com unlockuriphonenow\.com unscramble.de unterm-rock.us uoo.com upoisoning.com ups123.com upsms.de urlaubssonne-tanken.de usa-birthday-flowers.com usa-car-insurance.com usa-car-loans.com usbitches.com us-cash.com uscashloan.com user1.7host.com us-meds.com uswebdata.com uusky.com uusky.net uusky.org uusky.zj.com uusky2.home.sunbo.net uvinewine.co.uk u-w-m.ru v(27|29|3).(net|be) vacation-rentals-guide.com vaiosony.com valentine-gifts.qn.com valeofglamorganconservatives.org valium-online.1024bit.at valium-online.sinfree.net venera-agency.com veranstaltungs-tickets.de vergleich-versicherungsangebote.de versicherungsangebote-vergleichen.de versicherungsvergleiche-xxl.de versteigerungs-festival.de verybrowse.com verycd.com verycheapdentalinsurance.com vfrrto.org viaggix.com viagra\.freespaces\.com viapaxton.com viasho.com video-n.com videoportfolios.com vietdiary.com/andromedical vilentium.de vilez\.zenno\.info villagesx.com villajoyosa.to villamara.net vindaloosystems\.com vip-condom.com vitamins-for-each.com vivalatinmag.com vivlart.com vixensisland.com vod-solutions.com voip99.com voip99.net voip-guide.org voyancegratuite\.com vttolldd.org vtsae.org vttthtgg.org waldner-msa.co.uk warblog.net wasblog.com/ascitis washere.de watches-sales.com watchonetreehill\.org waterbeds-dot.com waycn.com wblogs.com wcdma2000.com wcgaaa.org wchao.net wdc\.com\.cn wding.com we.rx.pp.ru weareconfused.org.uk wearethechampions.com weaver.com.cn web.csnec.net web3dchina.com webanfragen.de webblogs.biz webcam-erotiche.com webcenter.pl web-cialis.com webcopywizard.net w-ebony.com webpage-cn.com webpark.pl webrank.cn web-revenue.com websamba\.com websitedesigningpromotion.com website-expansion.com websitespace-cn.com webzdarma.cz wecony.com weddings-info.com weddings-links.com weedns.com weighlessrx.com weight-loss-central.org weight-loss-links.net weightlossplace.net weitere-stellenangebote.de welan\.com welding\.mx\.gs we-live-together-4u.com wellness-getraenk.de weroom.com westzh.com wet-?(4all|pussy|horny).(com|us) whitehouse.com white-shadow-nasty-story.blogspot.com whizzkidsuk.co.uk wholesalepocketbike.com willcommen.de wincmd.ru wincrestal.com windcomesdown.com wine-booking.com wine-shop001.com wirenorth.com wiset-online.com witch-watch.com witji.com witz-net.de wizardsoul.com wjmgy.com wol\.bz women-fitness\.org workfromhome-homebasedbusiness.com worldblognet.com/eurasia world-candle.com world-cheese.com worldmusic.com worldsexi.com worldwide-(deals|games|holdem).(com|net) worldwide.php5.sk wotcher.de wrrirk\.poes\.net wujing-eyes.com wuyue.cn ww\.\d+\.com www.bhcyts.cn www.bjicp.com www.bungee-international.com www.it01.com.cn www.lamp-expert.com www.richtone.com.cn www.sex-portal.us www.webcamss.com www\.76e\.net www\.8z\.cn www\.banzhao\.com www\.chat-live\.net www\.pasca\.info \.roth-401k-forum\.com www-sesso www-webspace.de wxals.com wxboall.cn wxfl.net wxwz.fwhost.com wxwz.tabrays.com x24.com.ru x8x.weedns.com x911\.net xanax.qn.com xanax-online.qn.com xaper.com xazl.net xazlkjh.blog.ccidnet.com x-baccarat.com x-baccarat.us x-beat.com x-bingo.com x-craps.com x-craps.us xdolar.com x-fioricet.com xfreehosting.com xgsm.org xhhj.com.cn xianggangjc.com xianliming.com xianwahl\.com xinchen.net.cn xin-web.de xinyifang.net xinyitong\.org x-jack.us xlboobs.net xmtmdart.com xnan2.91x.net xnan2.blogdriver.com xnxxx.com x-pictures.net x-pictures.org xpictx.com xprv.com xratedcities.com xrblog.com/ezetimib x-ring-?tones.com x-roulette.com x-roulette.us x-roullete.com xs3.com xsjby.cn x-slots.com x-slots.us x-stories.org xt[\w]+.proboards\d\d\.com xtnm.com xxshopadult.com xxx(chan|seeker|washington).com xxx-alt-sex-story.blogspot.com xxx-beastiality.com xxx-database.com xxx-dvd.biz xxx-erotic-sex-story.blogspot.com xxx-first-time-sex-story.blogspot.com xxx-free-erotic-sex-story.blogspot.com xxx-gay-sex-story.blogspot.com xxx-girls-sex.com xxx-password-web.com xxx-pussy.us xxx-rape.org xxx-sex-movies.org xxx-sex-story-post.blogspot.com xxx-spanking-story.blogspot.com xxx-stories.net xxx-story.blogspot.com xy[\w]+\.blogg.de xyu[\w]+\.easyjournal\.com xyxy.net xz[\w]+\.over-blog\.com xz9.com yaninediaz.com ycc-zipper.com.cn ychzn.com yculblog.com ygci.com yihongtai.com ying0.com yipu.com.cn yipu\.com\.cn yisounet.com yisounet.net yl-jx\.com ylqx.org ymf.name yoll.net you-date.com youll.com.cn young\-tender\.info young-ass.us yourdentalinsuranceonline.com yourowncolours.co.uk yourserver.com your-tattoo.de youyipu\.com yubatech.com yukka.inc.ru yunchou.com.cn yyhq.com z0rz.com zahara.to zahara-de-la-sierra.to zahara-de-los-atunes.to zazlibrary.com zbbz.com zcfounder.com zchb.com zenno\.info zeonline.com.cn zfgfz.net zgpt.cn zgqygl.com zgxbw\.cn zhiliaotuofa.com zhjx-sh.com zhkaw.com zhongzhou-sh.com zhqzw.com ziliaowang\.cn zipcodedownload.com zipcodesmap.com zithromax-online.net zjww\.com znpp.com zo.servehttp.com zoo(-zone|europe|fil).com zoo-?sex-?(pics|motion-videos|pictures)?.(com|biz) zoosx.net zorpia\.com/xt zpics.net zt148.com zum-bestpreis.de zxyzxy.com zybxg.net zy-image.com zzdh.com zzgj.net 
+
+abouthongkong\.asexblogs\.com/ abouthongkong\.bloggingmax\.com/ abouthongkong\.blogslinger\.com/ abouthongkong\.satublog\.com/ berko\.com\.au/merry/ blog\.bachhoacung\.ws/freey/ blog\.mogway\.com/abouthongkong/ blog\.myaliyah\.com/\?u=abouthongkong blogcharm\.com/huanger/ blogs\.thesubculture\.com/\?u=abouthongkong cancerblog\.com\.au/abouthongkong/ film4vn\.net/blog/\?w=lieey rockstart\.net/blog/\?u=abouthongkong smeego\.com/feier/ tornblog\.com/abouthongkong/ um\.com\.my/win/ vfwnjwebcom\.org/abouthongkong/ we-r-blogs\.com/\?w=drewer weblog\.statisticounter\.com/abouthongkong/ www\.asiannotes\.com/art/ www\.betterbrain\.com/blog/\?u=abouthongkong www\.billionaire-blogs\.com/abouthongkong/ www\.blarbitration\.com/lelby/ www\.blog3\.com/\?u=abouthongkong www\.blogfreely\.com/abouthongkong/ www\.blogstuff\.co\.uk/\?u=abouthongkong www\.blogtoowoomba\.com/\?w=homuy www\.earthtank\.com/diewu/ www\.elblog\.de/howue/ www\.freescrapblogs\.com/red/ www\.fsaalumni\.net/blog/\?u=abouthongkong www\.kosova\.ch/yourblog/\?u=abouthongkong www\.love2k\.com/weblogs/\?u=abouthongkong www\.mattian\.co\.uk/liuhcai/ www\.nukeblog\.info/\?u=abouthongkong]] www\.pandablogs\.com/xiangang www\.picturethisblog\.com/\?u=abouthongkong www\.sblnet\.co\.uk/sblogger/abouthongkong/ www\.skaffe\.com/weblog/abouthongkong/ www\.slickblogs\.com/abouthongkong/ www\.slpblogs\.com/abouthongkong/ www\.soccerblogger\.co\.uk/\?w=uowek www\.sovereigngracesingles\.com/sgs_blog/\?u=abouthongkong www\.spottersblog\.com/tremo/ www\.spweblog\.com/abouthongkong/ www\.stitch-studios\.com/weblogs/\?u=abouthongkong www\.stu-c\.com/blogs/abouthongkong/ www\.tatsulok\.com/yuer/ www\.teenblog\.org/abouthongkong/ www\.toiyeu\.net/nhatky/\?w=toiyew www\.totalvideogames\.com/blog/laner www\.vfwmowebcom\.org/nicer/ www\.weblogone\.com/dry/ www\.westwoodbapt\.org/blog/abouthongkong/ www\.worldblognet\.com/abouthongkong/ www\.ym1\.com/abouthongkong/ chio92\.com onlinepoker\.happyhost\.org kolloidales-silber\.at sonyy1\.com tdk14\.com nyteam\.info ethock\.info pepsi14\.info jiayinte\.cn moxor\.info maxor\.info chevy\.ws adoption\.ws carpetcleaning\.ws hrentut\.org icwak\.info humela\.info guoyong\.com ziyangwz\.com zhanziyang\.com ziyangshiwo\.com short\-termhealthinsurance\.com scooter\-web\.org bikesplanet\.org aishwaryalife\.com jessicaalbalife\.com shakiralife\.com terapatricklife\.com adrianalimapics\.org wifiguide\.org wifi-planet\.org wifi-world\.org teainfo\.org pizzaguide\.org coffee-guide\.us chocolateplanet\.org girls-xxx-party\.com trinitao\.com tjshenguang\.com liveadulthost\.com speedorado\.com sexsdreams\.com carpassion\.com neureich\.de v-ringtones\.com 4vti8\.com artsmediamag\.com ringtones\.konaxil\.be upcoming\.netteen\.net cfcsouthpugetsound\.org xultin\.info tidep\.info ythrip\.info yston\.info xution\.info gosle\.info tallygotmoves\.com sexstar2000\.com dante4all\.com q7voda\.com fetishrred\.spycams777\.com discovery\.teenorg\.net cosmo02\.net (cam|sex|gay|fuck|swingers|adult|dating|erotic|personal|ads|cum|wife-swap)[\w\-_.]*\.blogspot\.com irzar\.com gokdep\.com nittion\.com cheapwowgold\.co\.uk win\.com\.cn wowgoldworld\.com starsnak\.biz shop-now\.be whitewalker\.com beatroulette\.atspace\.com onlines-slots-game\.atspace\.com (friendlysearch|medchoice|freesearches|getmedicineeasy)\.bravehost\.com gihore\.info soseik\.info ithyr\.info letreal\.info efdmen\.info udwryp\.info bupyere\.info tagmyn\.info suogman\.info gegbyl\.info laww\.info plonehostingdemo\.nidelven-it\.no wiki\.opennetcf\.org/upload sprint\.zope\.it ssdcard\.info soujipiao\.com 5ijipiao\.com jipiao126\.com jipiaoair\.com canjipiao\.com bjxiongfei\.com SaNaLHaCKERLaR\.ORG jspit7\.info kokoxx\.info donte\.info lib/exe/fetch.php\?media= imhotep\.sphosting\.com 1-myspace-layout\.blogspot\.com dinmo\.cn 51education\.com sispc.com\.cn sh-dzgs\.com teyi21\.com yizhish\.com oa586\.com watesi\.com sh-shenhuang\.com guojikuaidi\.com lbjq2h\.com xingaoweixing\.com shyw\.com shnakano\.com ihtc\.cn chonggong\.com kkvalve\.com\.cn uwb1hhc\.info vzh5k87\.info mvuxq60z\.info bodybillboardz\.com blog\.lide\.cz teeenp0rn\.org creditcarddebt\.neo\.cx dhzilnwr\.com hntwzokt\.com xoyeeuqx\.com badcredpersloan\.new\.fr securedcreditcard\.neo\.li hometown\.aol\.com (creditcons|creditreport|freeannualcr1|freecreditro|freecredits|cealis)\.monforum\.com fishmls\.com localendar\.com/public/ \.maxblog\.pl \.phpbbx\.de foroswebgratis\.com (cabrini|annotation)\.bravepages\.com (asp|impaction|monocled|wriggle|maneating|migrations)\.1sweethost\.com (bailee|carrycot|webmasters|markab|homewards)\.dreamstation\.com (bohemians|encloses|gravel|verite|tenderfeet|sabers)\.exactpages\.com (drained|shuffles|diathermy)\.fcpages\.com (headland|similar|muffler|normalise|typologist|buckshots)\.741\.com (ctenophore|failles|whistle|mayflies|nestled|eunice)\.angelcities\.com (arcady|tulip|undreamt|impair|reamers|hokiest|catnapping)\.greatnow\.com (absolutely|bellman|kwangchow|fluctuant|trouping)\.wtcsites\.com (wafers|whensoever|prescient|spacious|acadia|toothsome|gasolines)\.envy\.nu (smuggles|showboat|ipecacs|skivvying|straying)\.150m\.com (suffixed|barbeques|dispersal)\.100freemb\.com (killer|grumbles|despoiler|termites)\.kogaryu\.com (adversely|militated)\.g0g\.net (brunettes|struts)\.o-f\.com (reconnect|clownishly)\.00freehost\.com (drygoods|fl|liberia)\.9cy\.com (membership|retarders|spoonfed|pointedly)\.freewebsitehosting\.com (unwiser|innervates|woofed)\.ibnsites\.com (goodnight|shortens|brokering)\.freewebpages\.org (epaulet|impotency|jewelries)\.1accesshost\.com homepage\.mac\.com/(nonreader|cartels|cornflour|docilities|unanswered|feelings1)/ (imagist|phosphor|hatecrime|landward)\.freecities\.com (ainsurance|diflucanmed|mypropecia|1creditrepair)\.proboards104\.com (carisoprodol|tadalafil)\.mybbland\.com (refinancingmortgage|cheapautoinsurance|autoinsurancequote)\.(forumactif|actifforum)\.com fioricetmed\.blogcu\.com the-sabotage\.org spygrup\.org gencnesil\.org \.(blogsitemaking|blogginpoint)\.info hjlxmosb\.com dohzqmod\.com dadbhpsu\.com supermegapizdetc\.com cjbqixzs\.com tacmbuqe\.com qcprkjgp\.com wwcldvob\.com nhdwinyg\.com pewddohw\.com x-uqur\.org toyota-corollailf\.blogspot\.com corolla-toyota730\.blogspot\.com staticstroke\.tr\.cx vuhavrva\.com nfzwzphv\.com ljhasdic\.com peoazsog\.com szsbqqdb\.com kvxkloks\.com turkatesi\.net megaturks\.com rnsgroup\.us turkstorm\.org (ladyboy|shemale)\.viptop\.org nxyvarpv\.com shlmsapu\.com wjmlwkvk\.com www\.umes\.edu/accsupport/ossd/ossdchat/ jiyxhkdf\.com hpdrsykw\.com wminyrxj\.com gucvfiuh\.com osgtpzde\.com szexqgix\.com susiesbeads\.net swliuxue\.com mindtouch\.com e-parishilton\.com \.vg\.edu euitaly\.info sprzedam\.pl wpi\.biz galadriel\.nmsu\.edu d007\.phpnet\.us todosvem\.info flowers-shop\.sitesfree\.com bcasinos1\.ovp\.pl \.greatkozel(site|world)\.info hack-e\.com eelive\.info asi\.0moola\.com Valintino.Guxxi web\.hit\.bg \.sportsinfoitaly\.info urlbee\.com site3\.info bdqt\.org \.svt\.pl ycaol\.com abunimah\.org aypp\.info poker\.blog\.drecom\.jp idisk\.mac\.com/ringtonesforyou chaco\.gov\.ar/meccyt/subsecyt/_act1 forourbano\.gov\.ar/_forodisc/ tx-bridge\.com beijingimpression\.com enrichuk\.com recphone\.cn kcmp\.cn pumppump\.cn officezx\.com vcd-dvd168\.com\.cn dinmoseo\.com wow-powerleveling-wow\.com e-fanyi\.net chongshang\.com\.cn radfort\.com eachost\.com bjjly\.net sino-(jipiao|liuxue|zufang|lvyou)\.com(\.cn)? citylight\.com\.cn e4u\.cn china-co\.com celsnet\.cn deqinfy\.com mycomb\.com dm-(baojie|jipiao)\.cn xttg\.cn cthb\.com\.cn china-byt\.com china(yuntong|lipin|yiyao)(\.com|\.net)?\.cn jinpack\.com xinyuanit\.com timeyiqi\.com\.cn mendean\.net zgpdw\.cn 5i8811sf\.com my-projector\.net bjlhj\.cn imperial\.edu/maria\.coronel/ vca\.org faculty\.chi\.devry\.edu/ksteinkr/ encyko\.bee\.pl (synthroid|cialis|depakote|zithromax|cipro|aciphex-meds|diflucan-777|lipitor|zocor|norvasc|propecia|imitrex)\.ca\.cx # this is the specific regex \.ca\.cx # if noone complains we'll just keep that fpoker\.abc\.pl ftpoker\.ir\.pl ftpoker\.blogjapan\.jp wxerqxad\.com mnwftplr\.com ixgqwyaj\.com lglpvgdi\.com khmifkyd\.com fnabdymv\.com maomzyex\.com iprnhyeb\.com qytkgqkk\.com supermeganah\.com xnjehmqg\.com koufoadi\.com palgdhek\.com kcqdqjiv\.com xxqzcrbx\.com ejulbpnr\.com dfywxiza\.com wjdvppas\.com qfoijpym\.com usphwxib\.com fawhongh\.com xjayjaqh\.com hmaugptw\.com saeoazbj\.com pnjugiiu\.com xpubccoq\.com umbmjyug\.com lqbguwrt\.com 1url\.org/go/1yolui uwrejaag\.com wjlnjljz\.com jacpusnk\.com 51ticket\.net galasale\.com bjcdmaker\.com sdcy\.com\.cn ukpass\.org archifashion\.com sino-ups\.com qwerty\.wblogs\.org/2007/06/ astroguia\.org/bitacoras/qwerty/2007/06/ trinilopez\.com/_msgbrd/00002992 thyoapan\.com qfrtsyrp\.com uooyqazf\.com websearchdir\.net firstwebdirect\.org webdironline\.org nwdirect\.org wwbol\.info maagrenn?a\.tripod\.com (trumtrum|bugaga)\.ifrance\.com (bugogo|damdan)\.ibelgique\.com (sukonah|tramtram)\.isuisse\.com (gurevin|grandan)\.awardspace\.com uubol\.info rrbol\.info iibol\.info qqbol\.info iibol\.info eoajx\.quotaless\.com hardcorerapecomics\.tripod\.com (qq|pp|yy)adv\.biz (dd|gg)coll\.info rietdekkersbedrijfscholten\.com taylorrain\.newsit\.es \.webdirext\.com (sh)?chfang\.com xianweijin\.com strawberrydelights\.com whichsideofthefence\.com it\.snhu\.edu free-online-dating sudu\.info shcbprint\.net toppowerlevel\.net mysiteup\.my2gig\.com globalceoforum\.com\.cn isefc\.com\.cn teamflyelectronic\.com hzmqzs\.com coolingame\.com mydofus\.com rs2myth\.com levelmyth\.com ankama\.us buy-dofus-kamas\.net vulturesknob\.com yournetexpert\.hostwq\.net fundorro\.net normalforce\.com sei-mein-bester-freund\.de titaniuexport\.kiev\.ua loveangelinajolie\.com movief\.5gbfree\.com ylhz\.net grendamix\.com 89bm\.net temaxd\.cn gglhctm\.cn xgswd\.cn ofcpa\.com netbai\.net power-level\.net e489d\.com lingollc\.com boinbb\.com fourw\.jp sweepdesign\.jp chn-job\.com\.cn xfgkj\.com houseso\.cn beijingxiezilou\.com xiezilouxinxi\.com kibonbarcode\.com xzhfblp\.com linuxbj\.com pr1ma\.info dom\d\.info cardz\d\.info hom\d\.info rossa\d\.info svx\d\.info bomb\d\.info filmes[\w\-_.]*sexo filmes[\w\-_.]*gratis video[\w\-_.]*sexo video[\w\-_.]*gratis foto[\w\-_.]*nudo seeyo\.info suphost\.info freehostss\.info hostzz\.info 19mb\.info freespase\.info host24h\.info cdq369\.com datangshutong\.com jonchn\.com\.cn sweepdesign\.jp bj5yuehua\.com jonchn\.com\.cn bjht888\.com zgxbzlw\.com 466tv\.cn sixnet\.com\.cn 99caigang\.cn cydjk\.com fstzb\.com znstudio\.net datangshutong\.com liaoxinbj\.com bjhrj\.cn flowervoice\.com jonchn\.com\.cn iiwezxmkwzht\.com miqiatwuypzw\.com hjigunxxrqaf\.com slondcnixlwj\.com bengfa168\.cn kaiquan\.com\.cn huigao-v\.com bgzb\.com spvalve\.com dltools\.cn rosement\.com\.cn stone-ebay\.com zgxbzlw\.com farfly\.com e-bjmelody\.cn adsmc\.com yhht-valve\.com qmtyblphlilu\.com qewojlupomxg\.com zoqecyrqdfhc\.com jbhazglyuzml\.com bodt\.com\.cnn bodt\.com\.cn onebedroomfurniture\.com 69bm\.com 69bm\.net cp788\.com 1k888\.com libfondo\.info nimerino\.info minutospa\.info ihtibel\.info akmandel\.info 168xh\.net posui\.net\.cn szgwjy\.com tcl\.com johnsonip\.cn szwanyang\.com lfhcn\.com 89bm\.com caishen\d*\.cn hcplasticmold\.com [[ViewMyLoan|ViewMyLoan]]\.com hotwetred\.info uniwuros\.com cbyanrbp\.com vmwtynhs\.com odosuz\.cn idakoxic\.cn ifom\.info omiducer\.cn isekecec\.cn hzylin\.cn vaqyjcqu\.com nvzisslp\.com jxzgdglq\.com wetwetwett\.info nudevidz\.info nunde4free\.info 668w\.com fregalz\.info hothothott\.info 163\.(com|net) ifux\.info jzups\.com\.cn longre\.com wecomesh\.com cjh120\.com cctv8168\.com meter17\.cn quntuo\.com bjjinshan\.com cccstandard\.com szlrwl\.cn deqinfy\.net ebakvqsq\.com adklnaum\.com gohzmgek\.com hypoq\.(org|info) cerbaq\.info vertyn\.info bjyyct\.com blt\.net\.cn qemlcnwg\.com hudwzsfh\.com ppyecsia\.com impactcrusher\.net\.cn hammercrushers\.com benconq\.com jawcrusher\.net\.cn raymondmill\.cn zenithcrusher\.com cnzenith\.com conecrushers\.com\.cn impactcrusher\.net\.cn beconq\.com benconq\.com crusher-cn\.com zenithcrusher\.com lemmings.dontexist\.com bjjjjgd\.cn mingshengximqm\.com shangguanhong\.(com|net) zooxtreme\.(com|net|org) beastplace\.(com|net|org) beastzone\.(com|net|org) beast-space\.(com|net|org) 3vindia\.info 2kool4u\.net 22web\.net isgreat\.org iblogger\.org talk4fun\.net prophp\.org totalh\.com xanga\.com stonecrusher\.net\.cn vone\.net\.cn aggregate-plant\.com grindingmill\.cn huili-cn\.com globalchineseedu\.com zgxbzlw\.com wahlee\.net lilyspring\.com wetlesbiansx\.com wetindians\.net sex4uonly\.net jxpump\.com bfjxkf\.com zzdehong\.com wet-n-hairy\.net pinkshaved\.net sweetttits\.com jxpump\.com uextkhveawym\.com ghzbstszrpgo\.com qsevvccxnzlb\.com ahxxugvpswym\.com cce-china\.cn cd8545\.com travelnursingdirect\.com cone-crusher\.org chinadrtv\.com jsd-coffee\.com flolon\.com sc818\.com seo315\.(net|cn) pkseo\.cn nabirbsb\.com oqholfwb\.com wjoupiyw\.com yejuntech\.com ngvvlxpwuqhh\.com opggdydlpwsx\.com jrrwpwbungrk\.com lmkjshlsejlh\.com lovewind\.cn jormabridal\.com(\.cn)? paddletotheheadwaters\.com muzica-mp3\.ro movie2b\.com (stone|jaw|impact|cone|hammer)[-]*crusher\.(org|com|net|cn) pfkf999\.com hnpjs\.cn pysz\.com\.cn dxb\.ha\.cn ganbing120\.com\.cn forexcentre\.org igad\.info 0516glass\.com liuhuaji\.com\.cn obsoletecomputermuseum\.org/forums/ bonahr\.com\.cn stevepinto\.com touguanshi\.godele\.com bobauv\.com sangya\.com wanbaolong\.cc 99k\.org clanteam\.com ztsousou\.com azresults\.com zxq\.net ckcf\.com\.cn wuhanbl\.com asp100\.cn xpcd\.net mygold123\.com onlinegoldsale\.com rhftsb\.com yfyc\.cn cz-wanjia\.com freewebtown\.com mix\.org\.cn cnlxj\.cn 56817\.net 99shijia\.com hailianlitong\.com zggcw\.net bj-hongyun\.com chushiji2008\.com symlhb\.com hndfzx\.(com|cn) vpn123\.com autovote\.cn warnlaser\.com google8\.com\.cn dlong\.com\.cn chinasolutionco\.com dy-bb\.com daiyun315\.cn bj-jbh\.com lunwen22\.com lun-wen\.com\.cn lunwenff\.com comegames\.com nicewow\.com ixtm\.net alexasir\.com itxb\.net seo315\.cn hnfbqz\.[xc]n oofay\.com igset\.com eqset\.com beijing-trip\.net czdipan\.cn 5-happy\.cn sc98\.cn keeprun\.com hydehr\.com jiuyew\.com thedentalassistantonline\.com lhosting\.info allyouneed\.pl szlrkj\.com idating\.cn runescape\.com runescape2\.cc xneo\.org feilin\.ha\.cn banj315\.cn sdii\.com\.cn zzssjx\.com ganfushui\.cn okfish\.com\.cn cddvdvcd\.com utbwjawnvdtj\.com iyvjvdvpwali\.com dfsuyhhwpanb\.com iurvgecemloj\.com csusa\.org\.au nofeehost\.com auxt\.info italia113\.info favorgame\.net italaska\.info italyhomes\.info italiaconsulting\.info italypasta\.info gyhongwei\.com gystjx\.com hnydzg\.cn e-rhonealpes\.net italyresorts\.info madeitaly\.info workinitaly\.info offkey\.info digitalnod\.info fst-lab\.com xilu\.com 0571ax\.com orkeor\.cn accurian\.cn beon\.ru lokerpoker\.com imeem\.com mycool\.com joetheisendds\.com digiadv\.co\.jp asianjazz\.ciao\.jp jkw\.name aaaoe\.com bjsfyj\.com cxlsx\.com ming-qing\.com gb-kontakt\.net gbkontakt\.info phpbb4you\.com fdtech\.biz hostofhosting\.com chinaliangzhu\.com suntop-fence\.com aaqtq\.cn hmxlzx\.cn ctexm\.com mc-subway\.cn netberg\.cn cannabin\.cn mcparking\.cn ezysearch\.cn mcfreestyle\.cn taobao\.com tangoing\.info ceroline\.info zhaoad\.cn nanhuachem\.com hhpumps*\.(com|cn|net|org) wowgold\.hk wowgoldvip\.com wowgold-sale\.com mmogcart\.com mygamesale\.com powerlevelings\.com power-levels\.com game-level\.com tongdeli\.com smt16\.cn hnkehai\.com gyfzjx\.com zzyl\.(com|cn) floopityjoop\.com tits\.cn eduoduo\.com\.cn hymarkets\.com cango\.com\.cn videolucho\.com baidu\.com 9fag\.cn 9nsk\.cn 9skf\.cn cnnsk\.cn fagchina\.cn fagweb\.cn nsk022\.cn nskcn\.com nskweb\.cn skf022\.cn skfweb\.cn tjnrzc\.cn zcskf\.cn zhouchengskf\.cn eileenmcgann\.net abra[0-9]\.com lunwendx\.com ghlxj\.com hyinvestment\.com clife365\.com szh168\.cn rose-wedding\.cn jhstbj\.(com|cn) wybb999\.com francebfl\.com cmpack\.cn dabaog\.cn hnccqz\.cn ultra-gear\.com cnzycp\.cn hnzxzx\.cn cnpjs\.cn changw\.com t-bond\.com\.cn zjghtbf\.cn 08kaoyan\.net netbai\.com ontsibvwjyhr\.com cevdvcpeomet\.com iahucbhvcqbg\.com dammagoxpvwx\.com tjzdxf\.cn shanghairuth\.com gupiao258\.(com|cn) snownes\.com bjbcl\.com korack\.cn cebiz\.cn anesd\.cn dianhualy\.com digseo\.net hzw1\.com kpwyxl\.com zjyihe\.com malatown\.com\.cn kmyuda\.com xowow\.com powerlevelingweb\.com 1kan\.net\.cn howview\.cn bczl\.com\.cn fangshui99\.com bjxsbt\.com\.cn chuxinrui\.cn slfr\.net hyhxsm\.cn wang666\.cn shbingluo\.com keslon\.com hpsell\.com\.cn chenghechuangye\.cn bjyuantuo\.cn jnjinli\.com flower18\.com\.cn dianhualy\.com ifcmbj\.com xbjk120\.net howview\.cn egri\.net\.cn digseo\.net hzst\.net\.cn 3movievideoclip\.com 51yd\.com\.cn homesoft\.com\.cn bjzktd\.com dlpy\.cn hkfeng\.com zhengstar\.com 99cars\.net szrona\.com keetouch\.com ipcam\.com\.cn ope888\.cn oktouch\.com 1king\.com\.cn plancool\.com\.cn tianguangroups\.com beautynet\.cn housing-on-line\.com xinhai-pd\.com bjpbx\.com fozhe\.com cp2y\.com windhorsetour\.com buy-runescapegold\.com cchello\.com lookee\.in kotick\.in honi-moon\.in thsale\.com power4game\.com stk-interlining\.com wowgoldprice\.org ceskecelebrity\.com bvu\.com\.cn fsouber\.com allotec\.com p-pass\.com teamsun\.com\.cn pass4sure\.com pass4exam\.com exam4sure\.com certay\.com huochepiao168\.cn chinabestop\.com smartsgarment\.com pcqshoes\.com bestoplingerie\.com china-sexy-lingerie\.com fashion-emart\.com bestopsolar\.com info\.bizhostings\.net isk-eve\.com quickpass\.org shdzbc\.net\.cn xltcpl\.cn taiad\.com\.cn bjpeilian\.net wow-*gold.*\.(com|org|net|cn) sino-strong\.com\.cn vanguardct\.com hzzrs\.com hfcxhw\.com toeic-world\.com\.tw toefl-expert\.com\.tw gept4u\.com\.tw kingcoder\.com\.cn ning-wang-fu\.cn zzhkjx\.com exam100\.org 76my\.com gamezmoney\.com 86xh\.com ab222\.cn yn666\.com flowerordercentral\.cn geocities\.com/hentaioza www021\.com\.cn chinakaba\.com zdzdm\.sqnet\.cn szhostar\.com pulverizer\.com\.cn szyasen\.com xkzs\.cn tudou56\.com xcb120\.cn aab-co\.com jsps\.cn yuanchangsh\.cn fen-zi-shai\.cn jsqmfg\.cn valve-hm\.com hu-xi-qi\.cn surecan\.com\.cn wowpower-leveling\.com no1health\.org handbagroom\.com caxa\.com dinmo\.org\.cn underwear-wholesaler\.com 17-china\.cn longhainet\.com quarry\-plant\.com\.cn rock\-crushers\.com\.cn brogame\.com pan-tibet\.com jxsb\.org\.cn fzpg\.net\.cn xxyd\.org\.cn fzfz\.org\.cn jmzj999\.com xbkf120\.cn inaturaldiet\.com osthair\.com yqyb\.org\.cn jjyp\.net\.cn lpsp\.net\.cn yybj\.net\.cn txcp\.net\.cn hrdzf\.com 17ftp\.cn ibuy-sell\.com itemrate\.com mul-t-lock\.com\.cn kevincostnerfans\.com lavigneavril\.net loveparishilton\.net lovebritneyspears\.net alpacino\.net\.cn bradpitt\.net\.cn robertdeniro\.net\.cn gosuperplayers\.com item4sale\.com hitop-mould\.com dghighcrown\.com junxingstone\.com adholes\.net bibliotecaitata\.com chapso\.de teamagazine\.com\.hk blogbox\.dk tunesonic\.com blogpager\.com casa-lavoro\.net chicodeguzman\.net designblog\.gr hartenergy\.com isdev\.odg\.cc jshyx1985 mode2testsite\.com mosentenem\.com myadulthosting\.net nosdivertimos\.com seniorsspace\.com megasexblog\.com blogsdevenezuela\.com islablog\.com go-cms\.info sportsfanstv\.com worldswatches\.com myblog\.g89\.org evsblogs\.com blogs\.omanana\.net gayteenresources\.org blog\.medigo\.pl blog\.thai-z\.com 3xblog\.ro jumpblog\.com blogs\.slis\.ua\.edu zteo\.com propertyblogging\.com tangotogether\.com my\.vipublog\.com htchx\.us horizonacademyblog\.com emeraldnova\.com monsterblogs\.net losblogs\.net blog\.cybercc\.sg mormonorgs\.com drumblogs\.com jshyx2003 kxy\.cn free-download-firefox\.net byzxw\.com 1573\.hk tiffanyin\.com all4kid\.com deppjohnny\.com monicabelluccifans\.com gamesmd\.com implantjapan\.com i-denki\.net lasik-hikaku\.jp naturalk\.jp babyrockets\.com ocn\.ne\.jp w-medicalnet\.com sky361\.com powerleveling123\.com greentec-sound\.com\.cn runescapegoldvip\.com grasoftseo\.com mygamestock\.com rsgold-rsgold\.com kidmannicole\.com googlesoftware\.net accountsbay\.com fangdaomen\.cc hbjinggong\.cn mj-net\.jp marucollet\.jp cashing-view\.com century-21\.co\.jp dzbc\.org baojianwang\.com zhangsaohan\.cn huoyingrengzhe\.cn ouzou\.com\.cn trustyelectronic-china\.com china01\.cn goldcheapest\.com itemchannel\.com cn-chong\.com bjjhj\.com 2artgallery\.com gdqingtian\.com tiffanyline\.com ggfou\.com jxmc\.com\.cn donba\.com oilpainting109\.com cnmolecular-sieve\.com bodahg\.com 5eba\.com 51zzw\.cn thecommercejournal\.com da-zhong-ban-chang\.com gl-firmenadressen\.(info|net) nyzhyq\.com veryge\.com fm965\.cn goleveling\.com cnwfyy\.com biaori\.com hangzhouhunqing\.com kwyf\.com\.cn g2gmart\.com baihelai\.com freetestking\.org sup-lotro-gold\.com warcus\.com mini-freegames\.com zalasoft\.com hollyginger\.com sitgame\.com jdllj\.com shevip\.com\.cn bacobolo\.com world-womans\.com 88gk\.cn imvub\.com gpkoo\.com s2789\.com yw17\.com rfyljx\.com\.cn pboy\.com\.cn fashioninchina\.net electroplating-equipment\.cn lxep\.com carpet-china\.com\.cn jixietg\.cn break-day\.com games8848\.com fesffonpourr\.com fmrxfqdmwlbl\.com hdwccaggguzm\.com pjpxjijenjam\.com rjvurgjybnjn\.com uynlhrrfljtb\.com xljdfoxuceuh\.com zdcoxwpzjmhn\.com hyperrealty\.com mamariano\.us www-clubseventeen\.com ig2t\.com iamgaolijun\.cn monternet\.com granitecountertops\.com\.cn kercap\.com cwb120\.com gravelline\.cn applesupport\.com\.cn fcsgame\.com just4gold\.com goodvk\.com selldofus-kamas\.cn seo-newline\.com\.cn hzhongtai\.cn ymiao\.cn runescape-items\.org gcadressen-db\.net bambwood\.com jt120\.org\.cn thelodger\.net osceolanaacp\.org chattababy\.com touslescommerces\.net thepoliticalwasteland\.com moshergallery\.com membrane-solutions\.com abmbzkdszdwj\.com fwmqvmirgxya\.com mcxnlhviuojw\.com ogeworld\.com db-adressen\.(info|net) bathroomremodeling\.buzznet\.com chanelhandbag\.blog\.hr chinausbflashdrives\.com xyenglish\.com xingbingchina\.com fuworld\.com bjhongda2008\.com nowaction\.net qmyyw\.com yuanqiaowenhua\.com bjjh2000\.com lawfirst\.com\.cn a-polo\.cn librich\.com kicksarea\.com hybenet\.net yuanqiaowenhua\.com buy-runescape-money-gold\.com mesothelioma-uk\.net adsclicking\.com eastcarpet\.com\.cn jdshiyanji\.cn pandaphone\.com runescape2-money\.org wcx88\.cn dvd1314\.com cenkx\.com cnblp\.cn davismicro\.com fanggead\.com karrylady\.cn macrown\.com\.cn mdcchj\.com\.cn newbst\.com shoes4days\.com yaojian\.com\.cn zj-xinhong\.com ccok11\.com elkf120\.cn quhong120\.com rfid789\.com szchuangjie\.com windowregulator\.net ydyxl\.com adressendb\.net gc-datenbanken\.info rzqncfvopsdi\.com hvnrueyuufhh\.com ocrrtustraht\.com gxfuiynpudtp\.com gprunescape2\.com gsyb.com\.cn hzsxjx\.cn jdaluminum\.com jshengfa\.com wx-fd\.com usfine\.com maplestoryer\.com gcdatenbanken\.(net|info) google\.com/notebook/public cnhld\.org xykavmjkiisc\.com stasppcbybco\.com lxkqozwybkue\.com jpxgbssdoait\.com cilanie\.com 8bio\.com goodpolisher\.com watchepay\.com airprice\.com bonnych\.com watchec\.com ele-art\.com sqsensor\.com mabinogi-gold\.org rohan-gold\.org webprogress-seo\.com webprogress-de\.info brandtrading\.net notebook-batteries\.org supply-batteries\.co\.uk casininio\.com feiyun8\.cn pastemark\.com storeingame\.com ymcmotor\.com\.cn 97sese-mm.cn 97sese-xxoo\.cn 97sese-xxoo\.com\.cn dancedressshop\.com famousbrandwatch\.com jiuqusese-mm\.cn jiuqusese-mm\.com\.cn rentiyishu9\.com\.cn replica031\.com thepowerlevel\.com bjktwx\.com ktwxbj\.com nikespaces\.com paris-hilton\.wikidot\.com cert-world\.com weebly\.com db-gcadressen\.info dbadressen\.com rezeptfrei-kaufen\.com armee\.roonk\.de easysixpack\.de agoodic\.com ugamegold\.com zglxjkw\.com ourdtv\.tv flowexpo\.com supakopi\.com ero-xxx-pimiw\.cn gloway\.de gamelee\.com gogoer\.com mmorpgtube\.com mygamegoods\.com player-kill\.com srogold\.com tbcgold\.com tibiacrystal\.com rsgold-accounts\.com sfs168\.cn sfsok\.com szsfs\.com vgoldzone\.com vgsgame\.com banchang160\.com banjia99\.com bjgs01\.cn diaoche160\.com tuoyun160\.com lvhang\.net oilpaintingscn\.com shbaojing\.com wansp\.cn yaliuya\.cn yayaliu\.cn csjqlts\.cn crltjqsplts\.cn luoliaosp\.cn qqmnsplts\.cn kaoyao\.net goldmine\.by\.ru tarkus01\.by\.ru newsmaestro 7vee\.info shoeshome\.net desiresecrets\.com toyline\.net sexyfancy\.net pleasuretoys\.biz jsjgjt\.com cuvyr\.com air\.io ecotect\.com azedresearch\.org eklmnhost\.com il\.mahidol\.ac\.th nmxxkmzgonko\.com johnmoan1\.freehostia\.com warezboard\.seothaithai\.com mooselodgeproductions\.com tenormedia\.com forums\.sellyoursitefast\.com forum\.dreamaboutchina\.com nikonisti\.ro redeseducativaspade\.com quantulus\.com guineaonline\.com globalunitedsavings\.com lakechelanalumni\.net forum\.fasanga\.com edinburgh\.craigslist\.co\.uk blogcelular\.net i0799\.com reagentcafe\.com leronimo\.com forum\.a2actors\.com forum\.money2take\.tk commsedu\.co\.uk long1985.byethost3\.com pictures-point\.nl ojodelaplata\.vox\.com dragon-tech\.org kotsos3\.livepage\.gr lifemind\.com canvaco\.org nightdomination\.altervista\.org alhorea\.com pardaan\.com tinavmurray\.com blazn360\.com gol\.mainwebsite\.org com-health\.com genius-entertainment\.com lydiadeetz\.vox\.com pilipino\.com faceroll\.se dustie\.com edicolantenews\.com xbox360achievements\.org 2dfighter\.com Girls-Next-Door elephantcarhire\.com rushessays?\.com bestessays?\.com bestdissertations?\.com cheappoolproducts\.com superiorpapers\.com bestessays\.ca mightystudents\.com term-paper-research\.com college-paper\.org kamin\.kilu\.de kaminscout24\.de poker-rooms-review\.org all-auto\.ro 517dv\.com casino.?spielen\.biz ktmboard\.com seospec\.net sexocuritiba\.com\.br webdesign63\.de websearchplanet\.info blog\.bitcomet\.com dissertationlab\.com bestessayhelp\.com bookwormlab\.com hollandandbarrett\.com bestcheapautoinsurance\.com profischnell\.com getcreditrepairtips4u\.com maketodaypayday\.co\.uk usfirepits\.com cheapautoinsurancekentucky\.com automobile-insurance\.com carinsuranceonline-\d\d\.com 4autoinsurancequote\.org essay-writer\.org essaywritingservices\.org iresearchpapers\.com domainname\.com\.au lifeinsurancequotes\.com\.au myfuneralinsurance\.com\.au giftbasketsplus\.com lifeinsurance\.net\.au online-poker-spielen\.biz lowinterestcreditcards\.com(\.au)? balancetransfercreditcards\.org dartsimaging\.com searchengineoptimi[zs](ing|ation)(world|australia)\.com(\.au)? webair\.com aext\.net njoyz\.com pokerenfrancais\.eu momswhothink\.com fortunebaby\.com blackpenguin\.net novatedleasedeals\.com\.au labradoodle-puppies-for-sale\.net allstartradingpins\.com lease-a-seo\.com offsidebet\.com ukppiclaims\.org learners\.in\.th orbitfm\.com thekoeniggroup\.com forexinsider\.co\.uk indiangoldrates\.com iwanttosellmydiamond\.net pacquiaomosley\.co\.cc hcg-injections\.org hcgdiet\.net communaute\.sstic\.org prlog\.org unlockiphone4\.com patioheater[sz]?\.com card-approvals\.co\.uk hamptonbayceilingfans\.net novolinespiele\.de novoline24\.eu diamondlinks\.net lol\.com mastersdissertation\.co\.uk mortgagecomparison\.com\.au i52\.photobucket\.com outdoorpropanefirepit\.net s3\.hubimg\.com antiquegasstoves\.info bohaute\.com ariplex\.com wroughtironpatiofurnituresale\.com payday-loans-online\.com\.au carinquotes\.com carinsurancecomparisonsites\.com 2wheelmotors\.info thegrio\.com outdoorfountains\.com profi-fachuebersetzung\.de uebersetzung-deutsch-englisch\.com xn--bersetzungsbro-frankfurt-uscm\.de shindiristudio\.com emailmarketingsoftwares\.org signalsforex\.org smebs\.blog\.com sme\.in essayhelppros\.co\.uk headlicetreatmentworld\.com logodesignmaestro\.com customessayhelp\.com pffchat\.com book-of-ra-spielen\.com dissertation-help\.co\.uk termpapers-guide\.com logodesignconsultant\.com mmcashloans\.co\.uk mmpaydayloans\.co\.uk my\.apexfitness\.com mystore\.24hourfitness\.com mycaal\.com mmtaxlawyer\.com mmtaxrelief\.com mmtaxhelp\.com mmtaxdebt\.com mmtaxattorney\.com waterproofmp3\.info juegosgratis\.de motorcyclegames\.us angry-birds-online\.com snipsly\.com scotties\.co\.nz nzhirecartoday\.info videofishingknots\.com cheapaudiobooks\.org bernardtips\.com buyphone4withoutcontract\.com auto-ready\.com lacapila\.com hotelsinamsterdam-netherlands\.com refrigeration-repair-tips\.com pandoracharm-uk\.com swissking\.net watchonetreehill\.org www-e-bad-credit-credit-cards\.com surgerythailand\.com pandoracharmsuksale\.net thomassabostockists\.com braceletsuk\.com kanayorecommends\.com goosejakkedk\.com kontaktlinserna\.com prestigeweddinginvitations\.com sum-security\.com pandoraaustraliastockists\.com angrybirdshub\.com onlinepokered\.com downloadfullgamesfree\.net hotwirelesscoupons\.com purecigs\.com trivology\.com biocig\.ro promocoder\.ne linkyoursite\.net geekzu\.com perfectclaims\.co\.uk tagesgeldzinsen\.tv bluegravityhosting\.com mywikibiz\.com sell-junkcars\.com jaycomm\.com\.au jualvccmurah\.com fashionreplicabags\.asia purifiedlife\.com carinsurancecomparisonshelp\.com faresoldisuinternet\.com itshumour\.blogspot\.com thefunnyquotessayings\.com coachoutletny\.com community\.remedygames\.com forums\.immigration\.com forums\.toucharcade\.com forum\.bbpixel\.com juristischer-uebersetzer\.profis\.info uebersetzung-deutsch-englisch\.4kp\.de uebersetzer-englisch-niederlaendisch\.at\.cr simultandolmetscher\.9gb\.de sprachenfokus\.eo3\.de open-mic\.tv missoldppi\.co texturedroots\.com ofen-nrw\.de personalinjuryclaimsadvice\.com coffeemakersreviewed\.net isabelmarantnlsneakers\.com raspberryketonepurenow\.com priorityappliances\.net vitrier-rueil-malmaison\.fr primavakantie\.nl miss-link\.net kontopoulos\.net bhgalleries\.com repairpartstock\.com ashlagbaroch\.org 
+
+
+
+
+
diff --git a/BadContent.moin b/BadContent.moin
deleted file mode 100644
index ddf2fca..0000000
--- a/BadContent.moin
+++ /dev/null
@@ -1,4805 +0,0 @@
-## Please edit system and help pages ONLY in the master wiki!
-## For more information, please see MoinMoin:MoinDev/Translation.
-##master-page:Unknown-Page
-##master-date:Unknown-Date
-#acl -All:write Default
-#format plain
-#language en
-([\w\-_.]+\.)?(l(so|os)tr)\.[a-z]{2,}
-(blow)[\w\-_.]*job[\w\-_.]*\.[a-z]{2,}
-(buy)[\w\-_.]*online[\w\-_.]*\.[a-z]{2,}
-(gambling|porn|busty|prescription|pharmacy|penis|pills|enlarge)[\w\-_.]*\.[a-z]{2,}
-(diet|penis)[\w\-_.]*(pills|enlargement)[\w\-_.]*\.[a-z]{2,}
-(annunci|tatuaggi|canzoni|musicali|scarica|sesso|hentai|ragazze|sonnerie)[\w\-_.]*\.[a-z]{2,}
-(i|la)-sonneries?[\w\-_.]*\.[a-z]{2,}
-(incest|beastiality)[\w\-_.]*\.[a-z]{2,3}
-(levitra|lolita|phentermine|viagra|vig-?rx|zyban|valtex|xenical|adipex|meridia\b)[\w\-_.]*\.[a-z]{2,}
-(magazine)[\w\-_.]*(finder|netfirms)[\w\-_.]*\.[a-z]{2,}
-(mike)[\w\-_.]*apartment[\w\-_.]*\.[a-z]{2,}
-(milf)[\w\-_.]*(hunter|moms|fucking)[\w\-_.]*\.[a-z]{2,}
-(online)[\w\-_.]*casino[\w\-_.]*\.[a-z]{2,}
-(paid|online)[\w\-_.]*surveys[\w\-_.]*\.[a-z]{2,}
-(prozac|zoloft|xanax|valium|hydrocodone|vicodin|paxil|vioxx)[\w\-_.]*\.[a-z]{2,}
-(puss(ie|y)|adult|sex|fuck|suck|cock|virgin)\S{0,15}\.info/
-(ragazze)-?\w+\.[a-z]{2,}
-(ultram\b|\btenuate|tramadol|pheromones|phendimetrazine|ionamin|ortho.?tricyclen|retin.?a)[\w\-_.]*\.[a-z]{2,}
-(valtrex|zyrtec|\bhgh\b|ambien\b|flonase|allegra|didrex|renova\b|bontril|nexium)[\w\-_.]*\.[a-z]{2,}
-\.(chat|boom|fromru|hotmail|newmail|nightmail|nm|narod|pochta)\.ru
-\.[0-9]{5,}\.(com|net|org|us|biz|cn|ru)
-\.4t\.com
-\.51\.net
-\.6x\.to
-\.a\.la/
-\.b3\.nu
-\.cameroun\.ws
-\.flywebs\.com
-\.free-25\.de
-\.gb.com
-\.hostrim\.com
-\.qn.com
-\.sbn\.bz
-\.shell\.la
-\.static\.net
-\.t35\.com
-\.uk\.to
-\.uni\.cc
-\.w28\.org
-\.wol\.bz
-\.wtf\.la
-\.xs3\.com
-\.ya\.com
-\.yadoo\.cn
-\bda\.ru\b
-\bde\.gg\b
-\bde\.nr\b
-\bde\.tc\b
-\bde\.tp\b
-\bgo\.ro\b
-\w+\.sh\.cn
-0008888.com
-000site\.com
-0020.net
-0030.net
-00freehost\.com
-01-beltonen.com
-01-klingeltoene.at
-01-klingeltoene.de
-01-loghi.com
-01-logot?.com
-01-logotyper.com
-01-melodias?.com
-01mobile.com
-01-ringe?tones?.com
-01-ringe?tones?.us
-01-ringsignaler.com
-01ringtones.co.uk
-01-soittoaanet.com
-01-suonerie.com
-01-toque.com
-0adult-cartoon.com
-0cartoon.com
-0cartoon-sex.com
-0catch.com
-0livesex.com
-0sex-toons.com
-0sfondi.com
-0sfondi-desktop.com
-0suonerie.com
-0toons.com
-0xxx-cartoon.com
-1000\-celebs\.com
-100comm.com
-100hgh.com
-100-sex.com
-100megsfree5\.com
-108bikes.com
-110fat.com
-11126.com
-123-sign-making-equipment-and-supplies.com
-125mb.com
-125we.com
-148-law.com
-150m\.com
-158hk\.com\.cn
-163ns.com
-163school.com.cn
-168Education.com
-168marketing.com
-168wire.com
-16safe.com
-17train.com
-1816.net
-18caixin.com
-18ny.com
-18show.cn
-1accesshost\.com
-1afm\.com
-1asphost.com
-1-bignaturals.com
-1concerttickets.com
-1-cumfiesta.com
-1domiks\.org
-1ebalo\.org
-1foleks\.org
-1footballtickets.com
-1golod\.org
-1hrens\.org
-1ibanusiks\.org
-1jolla\.org
-1-klingeltone.com
-1so.com.cn
-1so\.net\.cn
-1st-(auto-insurance-4u|phonecard|printer-ink-cartridge|shemale-sex).com
-1st-host.org
-1stindustrialdirectory.com
-1stlookcd.com
-1stop[\w-]*.com
-1st-payday-loans.net
-1sweethost\.com
-1-texas-holdem.us
-1und1-shopping.de
-1-welivetogether.com
-1-wholesale-distributor.com
-1xp6z.com
-2008travel.com
-20fr.com
-216.130.167.230
-24-hour-fitness-online.com
-269s.tinline.com
-269s\.com
-2ndmortgageinterestrates.com
-2twinks.com
-30-60-90-day-sales-plan\.com
-321cigarettes.com
-3333.ws
-35tk\.com
-365jp.com
-3ccenter\.com
-3host.com
-3-sexy.com
-3sheng.net
-3sixtyfour.com
-3yaoi.com
-404host.com
-41b.net
-42tower.ws
-4mg.com
-4u-topshelfpussy.com
-4womenoftheworld.com
-5118.com
-5118.net.cn
-512j.com
-5151office\.cn
-51asa.com
-51dragon.com
-51nlp\.com
-51weixing.com
-51wisdom.com
-51zhengxing.net
-54eo.com
-5782601.net
-58798309dyb.com
-591dy.com
-625fang\.com
-63174828.com
-63dns.com
-65.217.108.182
-66.197.102.2
-666house\.com
-66battery.com
-66cable.com
-66cellphone.com
-66ceramic.com
-66floor.com
-66interior.com
-66logistics.com
-66machine.com
-66packing.com
-66sculpture.com
-66supply.com
-66tools.com
-68685633.com
-68l.com
-69.61.11.163
-69yo.com
-6p.org.uk
-6x.to
-71space\.[a-z]{2,}
-7p.org.uk
-8848flower.com
-888cas.com
-888jack.com
-888steel.com
-888-texas-holdem.com
-88aabb.com
-88feedstuff.com
-88fiber.com
-88telephone.com
-8cx.net
-8cx\.net
-8k.com
-8th\S*street\S*latina\S*\.[a-z]{2,}
-911\.uni\.cc
-9136\.cn
-91dir.com
-91xz.info
-999777888.com/jkcy009
-99bbcc.com
-99caixin.com
-99jl.net
-9sf\.cn
-a1-mortgage-finder.com
-a-1-versicherungsvergleich.de
-a688.net
-aaaaaaaa.ru
-aaff.net
-aajj.net
-aaliyah\.ws
-aauu.net
-abc3x.com
-abcink\.com
-abnehmen-ganz-sicher.com
-abocams.de
-abymetro.org.uk
-ac8888.com
-academytrans.com
-accessories-car.com
-accompagnatrici.cc
-acme\-arts\.com
-acmetranslation\.com
-acornwebdesign.co.uk
-activeshow\.net
-acupuncturealliance\.org
-acyclovir.net
-ad.huwh.org
-aducasher.spb.ru
-adult\-categories\.info
-adult-dvds?-dot.com
-adultfreehosting.com
-adult-free-webcams.com
-adult-friend.info
-adultfriendfinder.com
-adultfriendfindernow.com
-adultfriendfindersite.com
-adultfriendsite.com
-adult-games.name
-adulthostpro.com
-adultlingerieuk.com
-adultnonstop.com
-adultpics.com
-adultserviceproviders.com
-adultshare.com
-advantage-quotes.com
-a--e.com
-aegean.net.cn
-aektschen.de
-aerohose.com
-aesthetics.co.il
-afreeserver.com
-agentsmax\.com
-agreatserver.com
-aids120.95.cn
-aimaiti.com
-aimite.com
-air520\.com
-airfare-links.net
-airshow-china.com.cn
-airtrip.com.cn
-akkx\.info
-alawna.blogspot.com
-alexanet.com
-alfago.com
-alhaurin.to
-all-debt-consolidation.org
-allfind.us
-all-fioricet.com
-allinsurancetype.com
-allmagic.ru
-allof.myphotos.cc
-alloha.info
-allohaweb.com
-all-porn.info
-all-rxdrugs.com
-all-we-live-together.com
-allwoodoxford.com
-almacenpc.com
-alprazolam-online.qn.com
-amateur-(lesbian|movie|naked|site).us
-amateurs.r00m.com
-amateursuite.com
-amateurs-xxx.us
-amateur-thumbs.net
-ambien-online-order.zx81.at
-ambien-prescription.qn.com
-americacashfast.com
-americancdduplication.com
-americanpaydayloans.net
-american-single-dating.com
-amoxicillin-online.net
-amoyplastic.com
-anacondasex\.info
-analloverz.com
-anal-sex-pictures.us
-anchuang.com.cn
-andyedf.de
-angenehmen-aufenthalt.de
-angrybirdsblog\.com
-animalsex-movies-archive.com
-animalsex-pics-gallery.com
-anime1.org
-anime-adult.us
-anlinet.com
-annuaire.biz.ly
-annuaire.tk
-anonymous-blogger.com
-antely.com
-anti-exploit.com
-antu.com.cn
-anxietydisorders.biz
-anything4health.com
-anzwers\.net
-anzwers\.org
-a-onedigitizing.com
-a-oneemb.com
-aotubang.com
-aotubangshi.net
-ap8\.com
-apa-redlion.com
-apicalsoft.com
-a-pics.net
-apollopatch.com
-appliances66.com
-apply-to-green-card.org
-appollo.org
-approachina.com
-approval-loan.com
-a-purfectdream-expression.com
-aquari.ru
-aquatyca.net
-arbat\.or\.at
-arcsecurity.co.uk
-area-code-npa-nxx.com
-argendrom.com
-armor2net.com
-aromacc.com
-arrecife.to
-arterydesign.com
-artsdeal.com
-asianbum.com
-asian-girls.name
-asian-nude.blogspot.com
-asian-sex-woman.com
-asp169.com
-ass-picture.us
-a-stories.com
-atetech.com.cn
-atkinsexpert.com
-auctionmoneymakers.com
-auktions-uebersicht.de
-austinlawteam\.com
-autodetailproducts.com
-autodirektversicherung.com
-autofinanzierung-autokredit.de
-autofinanzierung-zum-festzins.de
-autohandelsmarktplatz.de
-autoing.com\.cn
-autoing\.com\.cn
-auto-insurance-links.net
-autokredit-autofinanzierung.de
-autokredit-tipp.de
-auto-loans-usa.biz
-automotive.com
-autoversicherung-vergleichen.info
-autumn-jade.com
-avon-one.com
-awxk.net
-ayamonte.to
-ba2000.com
-babes-d.com
-babes-maidens\.info
-babes-plus.com
-baby-info\.org
-babymarktplatz-aktiv.de
-baby-perfekt.de
-background-check.info
-bad-movies.net
-bad-passion.com
-bahraichfun.com
-baidublog.com
-baifaa.cn
-balancingmachine.cn
-bali-dewadewi-tours.com
-balidiscovery.org
-bali-hotels.co.uk
-balivillas.net
-banialoba3w.150m.com
-bannedhome.com
-banned-pics.com
-barbate.to
-barcelona.to
-barcode555.com
-barcodes.cn
-bare.org
-barely-legald.com
-barely-legal-teenb.com
-bargeld-tipp.de
-barrym.co.uk
-bast3.ru
-batukaru\.[a-z]{2,}
-bayareabags\.com
-bbell.com
-bbs.csnec.net
-bccec.com.cn
-bccinet.org
-bc-printer.com
-bdi-bone.com
-bdsensors.com.cn
-bdsm-story.blogspot.com
-beast(iality|sex)-(movies|stories|animal-sex-stories).(com|net)
-beaumont-bar.co.uk
-beauty333.com
-beauty-farm.net
-beautysilk.net
-beer-china.com
-beijingkh.com
-belinking.com
-beltonen-logos-spel.com
-benalmadena-costa-del-sol.to
-benavista.to
-benessere.us
-benidorm.to
-bestasianteens.com
-best-buy-cialis.com
-best-cialis-source.com
-bestdvdclubs.com
-bestel.com.cn
-besthandever.com
-best-high-speed-internet.com
-bestialitylinks.org
-bestiality-pics.org
-bestialityzoo.sytes.net
-best-internet-bingo.com
-bestits.net
-best-make-money.com
-bestonline-medication.com
-bestonline-medication.net
-bestonline-shopping.com
-best-result-fast.com
-bet-on-horseracing.com
-better-56.com
-beverlyhillspimps?andhos.com
-bhs-design.com
-big-(black-butts|breast-success|hooters|natural-boobs|naturals-4u).(com|net|us|org)
-big(bras-club|moms|titchaz).com
-bigmag.com.ua
-big-rant.com
-bigsitecity.com
-bigxigua\.com
-bildmitteilung.us
-billigfluege-billige-fluege.de
-billleo.com
-bio-snoop.com
-birth-control-links.com
-bizhat.com
-bizhome\.org
-bj-?(acca|erwai|fusheng|fyhj|hchy|hsdx|cas|gift|khp|xhjy|sd|zufang).(cn|com)
-bj701.com
-bjdyzs\.com
-bjerwai.com
-bjfusheng.com
-bjhsdx.com
-bjicp.net
-bj-page.com
-bj-qsan\.com
-bjsister.com
-bjxin\.com
-bjzyy.com
-black-?jack-?(4u|777|dot|homepage|play-blackjack|site|winner)?.(net|com|fm)
-black-amateur-cock.net
-blackjack-123.com
-blackjack-p.com
-blahblah.tk
-blanes.to
-b-liver.com
-blk-web.de
-bllogspot.com
-blog.co.tz/dexters
-blogbus.com
-blogcn.com
-blogforbaby.com/blog/deepsea
-blogforbaby.com/blog/jbilder
-bloggersdream.com/ahorcar
-bloggersdream.com/emscience
-bloggingmadness.com/aufmerksamkeitsdefizitsyndrom
-bloglabs.biz
-blogman.biz
-blogmen.net
-blogspam.org
-blogspoint.com/kostas
-blogspoint.com/marklanegan
-blogstudio.net
-blog-tips.com
-blonde-(pussy|video|xxx).us
-blumengruss-onlineshop.de
-blumenshop-versand.de
-b-mailbox.com
-bnuol.com
-bochao.com.cn
-bodet-clocks.co.uk
-body-jewelry.reestr.net
-bodyjock.com
-body-piercing.softinterop.com
-bokaibj.com
-bolonia.to
-bondage-story.blogspot.com
-bon-referencement.com
-boobmorning.com
-boobspost.com
-booking-room.com
-book-translation\.com
-boom.ru
-boom\.ru
-boylaser\.com
-breast-augmentation.top-big-tits.com
-briana-banks-dot.com
-british-hardcore.net
-brownlion.com.cn
-brrddd.org
-budget-phonecards.co.uk
-bueroversand-xxl.de
-bugaboo-stroller.com
-buildermax\.com
-bulkemailsoft.com
-burda\.isgre\.at
-burningcar.net
-businessbloging.com/benzaldehyde
-businessbloging.com/gesetz
-business-grants.org
-butalbital.org
-butianshi.com
-buy.*\.qn\.com
-buy-[\w-]+-online\.
-buy-adult-sex-toys.com
-buy-adult-toys.biz
-buy-ambien.8bit.at
-buyambienonline\.blogspirit\.com
-buy-car-insurance-4-us.com
-buy-carisoprodol\.qo\.pl
-buy-cheap-soma\.ar\.gs
-buy-cialis.ws
-buy-cialis-1.qn.com
-buy-cialis-online.qn.com
-buy-codeine.bebto.com
-buy-codeine.qn.com
-buy-codeine-online.b3.nu
-buy-computer.us
-buy-computer-memory.net
-buy-discount-airline-tickets.com
-buy-hydrocodone.qn.com
-buy-hydrocodone-online.sinfree.net
-buy-hydrocodone-online.u4l.com
-buyhydrocodonewhere.bigsitecity.com
-buy-laptop.biz
-buy-levitra-1.qn.com
-buy-levitra-online.qn.com
-buy-order-cheap-online\.info
-buyphen375reviews\.net
-buy-rx-usa.com
-buy-sex-toys.net
-buystuffpayless.com
-buy-valium.imess.net
-buy-valium.qn.com
-buy-valium-online.enacre.net
-buy-vicodin.dd.vg
-buy-xanax.qn.com
-buy-zolpidem.qn.com
-buzz-hotels.co.uk
-bvicr\.cn
-b-witchedcentral.co.uk
-by-and-by.com
-byondart\.com
-byronbayinternet.com
-c911c\.com
-cabopino.to
-cadaques.to
-cadiz-andalucia.to
-cai4\.com
-caipiaowangzhi.com
-calahonda.to
-california.k9.pl
-callingcardchoice.com
-calling-phone-cards\.org
-calpe.to
-cambridgetherapynotebook.co.uk
-camemberts.org
-camera-cn.com
-canada-travel.cn
-canos-de-meca.to
-cantonfairhotelguangzhou.com
-cantonfairhotelguangzhou\.com
-cantwell2000.com
-CAPAZ MESMO, ISTO E UM FATO MALUCO
-capital-credit-cards.com
-captain-stabbin.blogspot.com
-captain-stabbin-4u.com
-cardsloansmortgages.com
-careersmax\.com
-car-financing-low-rates.biz
-car-fuck.net
-carcoverspal\.com
-carinsurancecomparisonhelp\.com
-carisoprodol.q03.net
-carisoprodolonline.bigsitecity.com
-carlack.cn
-carmenblue.com
-carnalhost.com
-carnumbers.ru
-car-rental-links.com
-car-rentals-2go.com
-car-rental-search.com
-cars-links.com
-cartama.to
-cartoni(-animati|erotici|giapponesi).com
-cartopia.com
-cashadvanceclub.com
-cash-advance-quick.com
-cashmerebiz.com
-casillas-del-angel.to
-casoft.com.cn
-castingagentur2004.de
-cast-shadow.com
-cat-guide\.org
-cbitech.com
-ccie130.com
-ccie-ccnie.com
-ccna130.com
-ccna-ccna.com
-ccnp130.com
-ccnp-ccnp.com
-cd21\.cn
-cdshop-guenstig.de
-cds-xxl.de
-cebooks.net
-cegcr\.cn
-celebritylust.blog-city.com
-celebritypics.ws
-celebskin.com
-celebtastic.com
-cell-phone-accessories-dot.com
-ceool\.cn
-ceramic168.com
-certificationking.net
-certified-(new|used)-(autos|cars|suvs).com
-cfeenet.com
-changweia.cn
-chaosmagic.com/weblog/catastrophic
-chaseonlinebankingcom\.com
-chat\.ru
-chat-l.de
-chatten.bilder-j.de
-chauffeurtours.co.uk
-cheap.*\.6x\.to
-cheap-4.com
-cheap-adult-sex-toys.com
-cheap-ambien.qn.com
-cheap-cialis.qn.com
-cheap-cigarettes.com
-cheaper-digital-cameras.uk.com
-cheapest-phone.co.uk
-cheap-levitra.qn.com
-cheap-valium.my-age.net
-cheapvpn\.org
-cheap-web-hosting-companies.com
-cheap-xanax.qn.com
-chem888.com
-cherrybrady.com
-chickz.com
-\.china\.com
-china0519.com
-chinaad-design.com
-china-af.com
-chinaaircatering.com
-china-am.com
-china-apt.com
-chinaaxletree.com
-china-cp.com
-china-digital-camera.com
-china-dope.com
-chinagoldcoininc.com
-chinahr.com
-chinalatex.com
-chinaqygl.com
-chinasensor\.info
-china-sports-kit.com
-chinaswk.com
-china-transformer.com
-china-vcr.com
-chinaw3.com
-china-wood-floor.com
-china-wp.com
-chindata.com
-chindmoz.com
-chipiona.to
-chloesworld.com
-choose-online-university.com
-chrislaker.co.uk
-chuanganqi.dzsc.com
-chuanqisuji.com
-chunmeng.com
-cialis.homeip.net
-cialis.incredishop.com
-cialis.xs3.com
-cialisapcalis.com
-cialis-buy.com
-cialis-dot.com
-cialis-express.com
-cialis-online.b3.nu
-cialis-online-1.qn.com
-cialisusa.bravehost.com
-ciscochina.com
-citicardscom\.net
-claireburgos.com
-clamber.de
-clanbov.com
-clarks-shoe.u4l.com
-classifiche-italiane.org
-claudiachristian.co.uk
-clayjames.com
-cleannbright.co.uk
-click\.hn\.org
-click-or-not.de
-clophillac.org.uk
-closed-network.com
-club69.net
-cmeontv.de
-cmmdc.com.cn
-cn80051.1816.net
-cnbess.com
-cnbjflower.com
-cn-clothing.com
-cn-computer.com
-cndevi.com
-cn-dynamotor.com
-cn-exhibition.com
-cn-fashion.com
-cnfibernet\.com\.cn
-cnfti.org.cn
-cngreat\.net
-cn-present.com
-cn-press.com
-cn-Satellite-tv.com
-cnsec.cn
-cntaiyangneng.com
-cntoplead.com
-cn-vcr.com
-cnvideomeeting.com
-co.tradeinfo.cn
-codeine.xs3.com
-codeine-online.imess.net
-coin-abndalucia.to
-college-girl-pic.com
-college-links.net
-coma-cn.com
-combaltec.com
-comeback.com
-cometo(japan|malaysia|singapore|thailand).com
-commovie-china.com
-competa.to
-completelycars.com
-completelyherbal.com
-comptershops-online.de
-computer666.com
-computer888.com
-computer-onlinebestellung.de
-computer-und-erotische-spiele-download.com
-computerversand-xxl.de
-confession-of.mine
-conil.to
-conjhost.com
-container-partner.de
-contake.com
-cool\.as
-cool-extreme.com
-coolgoose.com
-coolhost\.biz
-coolp.(biz|net|org)
-copy168.com
-cor-admin.co
-cor-admin.com
-coresleep.com
-cornishholidaysuk.com
-cosmetics2008.com
-cosmetics666.com
-costa-blanca-alicante.to
-costa-blanca-denia.to
-costa-blanca-elche.to
-costa-blanca-ibi.to
-costa-blanca-javea.to
-costa-blanca-torrevieja.to
-couponmountain.com
-cover-your-feet.com
-cpravo.ru
-cqychy.com
-craftwork2008.com
-cragrats-catering.co.uk
-cragrats-education.co.uk
-cragrats-inspiring.co.uk
-cragrats-react.co.uk
-cragratstraining.co.uk
-crazypussy.info
-crazyvirgin\.info
-creavic.com.cn
-creditcardpost.com
-credit-factor.com
-credit-links.net
-credit-report-links.net
-csnec.net
-cstarcom.com
-cszg\.net
-cum-facials.us
-cumfiesta-4u.com
-cumon.no-ip.org
-customer-reviews.org
-cvdiy.com
-cvdiy\.com
-cw92013.chinaw3.com
-cxcn\.info
-cyberfreehost.com
-cycatki.com
-cyclobenzaprine.00freehost.com
-cyclo-cross.co.uk
-cykanax.com
-czwin.com.cn
-dad-daughter-incest.com
-dadi009\.91\.tc
-dahongbao.com
-dailyliving.info
-damadaoju.com
-damianer.top-100.pl
-danni.com
-dapt\.org
-darest.de
-datasoon.com
-datestop.net
-dating-(choice|harmony|service-dating|services-dating-service).com
-dating999.com
-dating-online-dating.org
-day4sex.com
-deathblow
-debt-consolidation-care\.com
-debtconsolidationfirm.net
-debt-consolidation-kick-a.com
-debt-consolidation-low-rates.biz
-debt-consolidation-now-online.com
-debtconsolidationusa.org
-debt-disappear.com
-debtmanagementcompanyonline.com
-debt-solution-tips.com
-decorationsexport.com
-dedichepersonali.com
-deep-ice.com
-deikmann.de
-dela88.com
-delay-dva.com
-deli.net.cn
-dentalinsurancehealth.com
-department-storez.com
-desiraesworld.com
-destindia-internships\.com
-deutschlandweite-immobilienangebote.de
-devonanal.com
-devon-daniels.com
-diabetes-cn.com
-dianepoppos.com
-dianying8.net
-diarypeople.com
-diecastdot.com
-digitale-teile.de
-digital-projector.net
-dindon.cn
-dinmo.net
-directcarrental.com
-directcti.com
-directrape.com
-directringtones.com
-direct-tv-for-free.com
-dirty-story.blogspot.com
-discount-airfares-guide.com
-discount-cheap-dental-insurance.com
-discount-life-insurance.us
-discountprinterrefill.com
-discoveryofusa.com
-divorce-links.com
-dlctc.com
-dmoznet.com
-dmoznet.net
-dmoznet.org
-dnip.net
-dn-register.com
-dns\.com\.cn
-dns110.com
-do\.9jh\.com
-dogolz\.de
-domkino\.com\.ua
-dongdao\.net
-dont-lost-money\.info
-doo\.pl
-door168\.com
-dorka\.ifindex\.com
-dostweb.com
-dotas.com
-dotcomup.com
-dotmoment.com
-downloadzipcode.com
-downsms.com
-dr\.ag
-dragonball-?x*.biz
-dragonball-?x*.cc
-dressagehorseinternational.co.uk
-dress-cn.com
-drive-backup.com
-drochka.com
-drozd\.voxelperfect\.net
-drs.infosec.org.cn
-drugsexperts.com
-drugstore.blog-city.com
-drugstore.st
-drugstore-online.us
-drunk-girls-(flashing|party).(com|us)
-drupaliciousbot\.com
-dstmedia.com
-dudoctor\.com
-duducat.com
-dunecliffesaunton.co.uk
-duvx\.com/bbs\.php?bbs=vs
-dvd2.us
-dvd-copier.info
-dvd-home-theatre.com
-dwoq.com
-dzhsc.com
-e40.nl
-earphone168.com
-easy-money-investing.com
-easyrecorder.com
-easyseek.us
-ebackground-checks\.com
-ebaybusiness.net
-ebony-xxx.us
-ebookers.co.uk
-e-bookszone.com
-ec198.com
-ec51.cn
-ec51.com
-ec51.net
-ec51.org
-ec91.com
-ecar-rentals\.com
-ecblast.com
-eccentrix.com/members/casinotips
-echinabid.com
-echinabid\.com
-echofourdesign.com
-e-cialis.net
-ecologix.co.uk
-e-credit-card-debt.com
-ecredit-report\.com
-eden\.fx120\.net
-e-discus.com
-e-dishnetworks\.com
-edrugstore.md
-edwardbaskett.com
-effexor.cc
-effexor-web.com
-e-fioricet.com
-e-free-credit-reports.com
-eggesfordhotel.co.uk
-egyway.com
-einfach-wunschgewicht.com
-elcenter-s.ru
-eldorado.com.ua
-electromark-uk.co.uk
-electronics-info.com
-elegant-candles.com
-elektronikshop-xxl.de
-elie\.com\.cn
-elite-change.com
-elitecities.com
-eliulin.com
-elrocio.to
-elviria.to
-emedicalmarijuanacard\.com
-emmasarah.com
-emmss.com
-enacre.net
-ena-free-show\.info
-endns.net
-e-news.host.sk
-enine-pv.com
-envoyer-des-fleurs.com
-e-online-bingo.com
-eonsystems.com
-e-order-propecia.com
-epackshop.net
-e--pics.com
-eplastic-surgery\.com
-e-play-bingo.com
-epsystem.net
-erbium12.com
-erosway.com
-erotic4free.net
-eroticalservers.net
-erotic-free.com
-erotic-lesbian-story.blogspot.com
-erotic-video.us
-erotische-geschichten-portal.com
-errolware.com
-escort-links.net
-escorts-links.com
-eScrew is
-esmartdesign.com
-esmoz.com
-estepona.to
-ethixsouthwest.com
-etoo.cn
-etowns\.org
-e-tutor.com
-eutstore\.com
-evanstonpl.org
-event-kalendarium.de
-everyvoice.net
-evromaster.ru
-exdrawings.com
-execsoft-software.co.uk
-executive-chauffeur-hire.co.uk
-ex-machine.com
-exoticdvds.co.uk
-exoticmoms.com
-expatdream.com/blog/aclarar
-experienceflagstaff.com/blogs/xzchro
-extralife\.biz
-extrasms.de
-extreme-rape.org
-extreme-sex.org
-eye-laser.co.uk
-f2g.net
-f2s.be
-fabida.net
-fabricant-accessories.co.uk
-fabulos.de
-fabuloussextoys.com
-facial-skin-care-center.com
-fairchild.com.cn
-fairland.cn
-fairyblog.com/conect
-fakir\.zenno\.info
-family-incest.us
-fangso\.com
-fansjiaoab.blog.163.com
-fantasyfootballsportsbook.com
-farm-beastiality.com
-farmsx.com
-fasa\.jetco-ops\.com
-fashuo300.com
-fast-look\.com
-fast-fioricet.com
-fast-mortgage-4-u.com
-fat-cash.com
-fateback.com
-fat-lesbians.net
-fat-pussy-sex.net
-fatty-liver.cn
-fatwarfare.com
-favilon.net
-fda.com.cn
-fdl.net.cn
-feexpert.com
-feilun.com.cn
-female-orgasms.org
-ferta\.imlds\.com
-fielit.de
-figa.nu
-finance-world.net
-finanzen-marktplatz.de
-find-a-mortgage.co.uk
-findbookmakers.com
-find-cheap-dental-plans.com
-finddatingsites.com
-findsexmovie.info
-findsexxx.us
-find-u-that-mortgage.com
-findyouruni.com
-finger-bobs.com
-fioricet.batcave.net
-fioricet.bravehost.com
-fioricet.st
-fioricet-dot.com
-fioricet-web.com
-firefoxdownload\.us
-first-time-story.blogspot.com
-fishoilmiracle.com
-fitness-links.net
-fitnessx.net
-fittest\.250m.com
-flash77.com
-flatbedshipping.com
-fleet-drive.co.uk
-fleshlight.org
-flewblog.net
-flexbelthq\.com
-flexeril-web.com
-flirt08.de
-floraday\.com\.cn
-flowertobj.com
-flowerwish.com
-flug-und-mietwagen.de
-fly-sky.com
-fm360.net
-food-cn.com
-football-betting-nfl.com
-forceful.de
-forex.inc.ru
-forex[\w-]*\.info
-forex-online-now.com
-forlovedones.com
-forseo\.
-foto-gay.us
-found-money-investment.info
-franchise\.ws
-frangelicasplace.org
-frankpictures.com
-free(hostingpeople|webs|web-hosting).com
-free-adult-chat-room.com
-free-adult-check.com
-freeallsearch.com
-free-britney-spears-nude.biz
-free-debt-consolidation-online.us
-freedvdplayer.cjb.net
-freeeads.co.uk
-free-fast.net
-free-games-links.com
-free-gay-video-clip.com
-free-hilton-paris-sex-video.com
-free-horoscopes.biz
-free-incest-stories-site.com
-free-latina-mpg.com
-freemovie-cn.com
-free-net-sex.com
-freenetshopper.com
-freenudegallery.org
-free-paris-nikki-hilton.blogspot.com
-freepicsdaily.com
-free-registry-cleaners\.biz
-free-satellite-tv-directv-nocable.com
-free-satellite-tv-now.com
-freeteenpicsandmovies.com
-free-teens-galleries.com
-free-texas-?hold-?em.(biz|us)
-freewebpage.org
-freewhileshopping.com
-freshsexhosting.com
-friko.pl
-fromru.com
-fspv.com
-fssj.com
-fsyflower\.com
-fuck\-my\-ass\.info
-fuck-animals.com
-fuckfrompussy\.info
-fuelcellmarketplace.co.uk
-fuel-dispenser.com
-fuengirola-costa-del-sol.to
-fuerteventura.to
-fuhaidasha.com.cn
-fulongcn.com
-funasia.cn
-funmod.com
-funny-girls\.info
-fun-spass-game.de.ms
-furensteel.cn
-furensteel\.cn
-furniture135.com
-furrios.de
-furry-kinks-looking.com
-furry-kinks-looking.net
-futurenet.com.cn
-fzrr.com
-gagnerargent.com
-gals4all.com
-galsonbed.com
-gamble-on-football-online.com
-gambling\Sgames.cc
-gamefinder.de
-games-advanced.de
-gang-rape.org
-gangxing.com
-gaokao.net.cn
-garment-china.com
-garrywa.com
-gartenshopper.de
-garthfans.co.uk
-gaucin.to
-gay-b.com
-gaybloghosting.com/kushi
-gay-boy.us
-gayfunplaces.com
-gayhomes\.net
-gay-male-story.blogspot.com
-gay-nude.us
-gay--sex.org
-gay-sex-videos.com
-gays-sex-gay-sex-gays.us
-gay-twinks-sex.com
-gayx.us
-gcchq.com
-gdgc.org
-gelago.de
-gem2.de
-gemtienda.co.uk
-generic-ambien.qn.com
-generic-cialis.qn.com
-generic-levitra.qn.com
-generic-propecia.net
-generic-valium.512bit.at
-genimat.220v.org
-genimat.cjb.net
-geocities.com/alexgolddphumanrbriar
-geocities.com/avbmaxtirodpaulmatt
-geocities.com/brandtdleffmatthias7
-geocities.com/cclibrannar_rover
-geocities.com/constpolonskaalniko7
-geocities.com/forestavmiagdust
-geocities.com/free_satellite_tv_dish_system
-geocities.com/ofconvbdemikqfolium
-geocities.com/pashkabandtvcom
-geocities.com/pautovalexasha_kagal
-geocities.com/reutovoalexeypetrovseverin5
-geocities.com/timryancompassmedius
-gerardoknutson.com
-germanytek.com
-gesundheitsshop-kosmetik.de
-gesundheit-total.com
-getapussy\.info
-get-cell-phone-accessories.com
-getdomainsandhosting.com
-get-free-catalogs.com
-get-freetrial.us
-get-hardcore-sex.com
-gethelp24x7.net
-get-insurance-quotes.com
-getitip.org
-getmoregiveless.com
-getrxscripts.biz
-get-satellite-tv-dish.com
-getstarted24x7.net
-getyourlyrics.com
-get-zoo.com
-gghggh.com
-gguu\.com
-ghettoinc.com
-giantipps.de
-gifs-clipart-smiley.de
-gilerarunner.8m.com
-giochi-online.us
-giochix.com
-girls\-pussies.info
-girlshost.net
-girlswantsmore\.info
-girls-with-cunts\.info
-giveramp.com
-give-u-the-perfect-mortgage.com
-glass8888.com
-glendajackson.co.uk
-global-phonecard.co.uk
-globalsearch.cn
-global-verreisen.de
-globalwebbrain.com
-globalwiremesh\.com
-glory-vision.com
-gloveboxes.com.cn
-gloveboxes\.com\.cn
-go.nease.net
-godere.org
-gogito.com
-gogoogle.net
-gogt\.info
-gojerk.com
-goldbuyerstrust\.com
-goldenholiday.com
-goldsenze\.com
-golfhq\.org
-gomvents.com
-gongi.pl
-gonzalesltd.com
-goodasses\.info
-goodlife2000-geheimtipp.com
-goodsexy.com
-goodwebsite.org/blog/elrincondelvago
-google8.net
-googleandbaidu.com
-googlebaidu.com
-googlepromotion.com
-google-seo.net
-googlesweb\.com
-googletosh.com
-go-pussy.titanhousing.com
-gotobiz.net
-gotooa.com
-government-grants.org
-government-grants.ws
-gpo4.com
-gpsplanet\.org
-grafit\.zenno\.info
-grancanaria.to
-grannypictgp.com
-grannysexthumbs.com
-great-cialis.com
-greatnow.com
-greecehotels-discount.com
-green-gradens\.org
-green-tx.com
-greewon\.com\.cn
-grinding-mill.net
-group-eurosex.com
-gt-lite.com
-guadalmina.to
-guardami.org
-guenstige-(krankenversicherung|onlineshops|sportartikel|versicherungstarife).(com|de)
-guizang.net
-guttermag.com
-gyhx.com
-gym-equipments\.org
-gyrohost.com/iboga
-h1\.ripway\.com/xz
-h2kmatrix.com
-haidianjiaxiao.com
-hainan35\.com
-hair-loss-cure.net
-hairy-pussy-sex.net
-haishun.net
-hallo-tierfreund.de
-hand-job.us
-handwerksartikel-xxl.de
-handy-klingeltoene.eu.tp
-handylogos-klingeltoene.net.ms
-handysprueche.de
-handytone.us
-hangchen.cn
-hangchen.com
-haole\.cn
-happyagency.com
-happy-shopping-online.com
-hardcore-(jpg|junky|pictures|pussy|sex|video).(com|us|bz|net)
-hardcorecash.net
-hard-sex-teen.com
-hardware123.com
-hardware888.com
-hartsflorist\.com
-haugeprint.co.uk
-hautesavoieimmobilier.com
-hchcinc.com
-hddata.com
-hdfix.com.cn
-headachetreatment.net
-healthmore.net
-healthrules.org
-heartbeatofhealing.org
-heavytools.webzdarma.cz
-heb-shuntong.com
-hebu.myrice.com
-hello\.to
-hentay.us
-herpies.net
-hewittlandscapes.co.uk
-heydo.com
-hg-fix\.com
-hgxweb.de
-high-risk-merchant-account.org
-hilton-nicky-paris.blogspot.com
-hion.cn
-hit168.net
-hit-melodias.com
-hits?-logos?-(games|klingeltone?|ringe?tone|suoneria).com
-hitslogosgames.com
-hjsos.com
-hk99689.com
-hk99w.com
-hkfor\.cn
-hkfor\.com
-hkfor\.net
-hkfor\.org
-hksaa\.net
-hksac\.org
-hlduanjian.com
-hmlaser.com
-hmxuan.com
-hnhqmj\.com
-hobbs-farm.com
-hogwatch\.org
-hold-em-big.com
-hold-pok.com
-hold-screen.com
-home.soufun.com
-home\.ro\b
-home\-trade\.net
-home4web.org/(hainan|fanguangcailiao|gongzuofu|niupixian|tuozhan)
-home-business-ideas-investment.info
-home-business-investments.info
-home-internet-business-investment.info
-homelivecams.com
-homenetworkingsolutions.co.uk
-home-secure\.org
-home-videos.net
-hongkong\.richful\.net
-hongkongcompanyregistry\.com
-horny-honey.com
-hornymoms.net
-hornypages.com
-horny-world.com
-horoskop-auswertung.de
-horse-racebetting.com
-horse-sex.ws
-hospitalonline\.cn
-hosting-server\.net
-hostingplus.com
-hostultra.com
-hotchina.org
-hot-cialis.com
-hotel\.altse\.com
-hotel\.netsuns\.net
-hotelbookingserver.com
-hotel-bordeaux.cjb.net
-hotelsaficionado.com
-hotelsplustours.com
-hot-escort-services.com
-hotfunsingles.com
-hot-mates.info
-hotmoko\.info
-hot-naked-guys.net
-hotsexys.com
-hotusa.org
-house222.com
-house263\.com
-houseclub.com.cn
-how-quit-smoking.com
-how-to-make-money-investment.info
-howtomakedubstep\.co\.uk
-hp-ibm.com
-hs168.com
-ht-sensor\.com
-https?://[^/\n]*8k\.com
-https?://[^/\n]*ap8\.com
-https?://[^/\n]*bare\.org
-https?://[^/\n]*danni\.com
-https?://[^/\n]*doo\.pl
-https?://[^/\n]*dr\.ag
-https?://[^/\n]*e40\.nl
-https?://[^/\n]*f2s\.be
-https?://[^/\n]*it\.tt
-https?://[^/\n]*t35\.com
-https?://[^/\n]*via\.net
-huafei7.cn
-huahuan.com
-hua-shun.com.cn
-huazhangmba.com
-huelva.to
-huihualin.com
-human-cn.com
-humangrowthhormone.org
-hunksandbabes.com
-hustler.bz
-hustlerw.com
-huyprossish\.pcadsl\.com\.tw
-hydrocodone.webzdarma.cz
-hydrocodone-online.hotusa.org
-hydrocodone-without-prescription.enacre.net
-hyip[\w-]*\.(info|com)
-hyper-sex.com
-hypnobabies.co.uk
-hzjl365.com
-hzn.cn
-ialmostdied\.com
-ibiza-island.to
-i-black-jack.com
-i-butalbital-fioricet.com
-i-buy-mortgage.com
-icpcn\.com
-idc2008\.cn
-idebtconsolidation.org
-i-directv.net
-i-dish-network.org
-ie\.isoso\.info
-i-flexeril.com
-ifreepages.com
-ig3.net
-ihongtai\.com
-i-horny.com
-i-ink-cartridges.com
-illegalhome.com
-illegalspace.com
-imeanit.org
-imess.net
-imitrex-web.com
-immobilien-?(auswaehlen|angebote-auswahl|makler-angebote|makler-l|-l).de
-immobilienmarkt-grundstuecke.de
-immobilierdessavoie.com
-immodev.com
-im-naked.com
-Imobissimo.com
-i-mortgage-online.com
-important\.as
-impotence-rx.biz
-incest-?((pics|photos?|stories|movies|videos)-?(collection|download|gallery|archive|library)?|reality|relations|taboo).(com|biz|net|ws)
-incest[0-9]\.org
-incest-pics--incest.com
-incest--stories.org
-inc-magazine.com
-incredishop.com
-indiainfotech\.com
-indiasilk.biz
-indiasilktradition.com
-industrialresource.biz
-industrial-testing-equipment.com
-i-need-money-ideas.info
-inescudna.com
-inexpensiverx.net
-infopoint.cn
-inforceable.com
-inforceables.com
-innfg.de
-insatax\.com
-insatiablepussy.com
-inspection-trips.com
-insurance.*\.go\.ro
-insurancehere.net
-insurance-quotes-fast.com
-interealty.es
-international-candle-shop.com
-international-cheese-shop.com
-internet-explorer\.ws
-internet-goulasch.com
-internette-anbieter.de
-interphone555.com
-interracial-sex.ws
-inter-ross.ru
-interseo\.com
-int-fed-aromatherapy.co.uk
-in-the-vip.org
-inthevip-4u.com
-inthevip-sex.com
-intking.com
-intlcr\.cn
-intlcr\.com
-intlcr\.net
-intlcr\.org
-intymnie.com
-investing-get-rich-quick.info
-investments-free-money.info
-inviare-mms.net
-invio-mms.us
-Invite-cn.com
-i-online-bingo.com
-ipaddressworld.com
-i-play-bingo.com
-i-play-blackjack.com
-ipmotor.com
-ipodnano\.cn
-ipodshop\.cn
-ipsnihongo.org
-iqwork.com
-irianjaya.co.uk
-isgre\.at
-i-shemale.com
-i-skelaxin.com
-islacanela.to
-islacristina.to
-isla-fisher\.com
-islantilla.to
-i-soma.net
-isourceindia.com
-isparkl.com
-ispycameltoe.com
-i-texas-hold-?em.(biz|com|info|us)
-itisok\.net
-it-mgz.ir/forfamilies
-itzhongguo.com
-iul-online.de
-i-university-guide.com
-ivoryvaughan.com
-iwebbroker.com
-i-wellbutrin.com
-i-will-find-the-best-mortgage-lead.com
-i-win-bingo.com
-iza.net/
-jack-x.com
-jade.bilder-i.de
-jandia.to
-japan-partner.com
-jbbjcc.com
-jerez.to
-jewelry4navel.com
-jewelry666.com
-jforce.no-ip.org
-jgc-network.co.uk
-jgzhutanfang.com
-jhhkw.com
-jhyujik\.org
-jiadian666.com
-jialicn.com
-jialicn\.com
-jieju-china.com
-jingtong\.com.cn
-jinlong.co.uk
-jinxique.com
-jinyibei.com.cn
-jinyuetuan\.cn
-jipu.com.cn
-jk-999.com
-jnqidong.com
-jobbnu.com
-job-interview-questions-tips.com
-joes\.com
-johnhowesatty.com
-join-2008.com
-joinin-cn.com
-jokeria.de
-jp114\.cn
-js-chenguang.com
-jualvccmurah\.com
-judahskateboards.com
-juliamiles.co.uk
-jungfrauen-sex.com
-junyuan.com.cn
-justasex.com
-juziku.com
-jzhrb.com.cn
-jz-machine\.com
-kamerry.com
-kangdachemical.online.sh.cn
-kangxin.com
-kantorg.h10.ru
-karibubaskets.com
-karma.za.pl
-karmicdebtconsolidation.com
-kcufrecnac.com
-keikoasura.com
-keithandrew.co.uk
-kewler.net
-kewl-links.com
-kickme\.to
-kickmy.com
-ki-disease.com
-kinggimp.org
-kinkyhosting.com
-kiranthakrar.co.uk
-kitehost.com/decoratie
-kktthhyy\.org
-kleinkinder-shop.de
-klingeltoene-handylogos.de.be
-klingeltone-logo.com
-klingelton-logos-mms.de
-klitoris.ca
-kln.com.cn
-kmsenergy.com
-kohost.us
-koihoo.com
-kontaktanzeigen-bild.de.ms
-kontaktlinsen-kaufen.de.ms
-kontaktlinsen-partner.de
-korol.lir.dk
-kostenlose-sexkontakte.org
-kraskidliavas.ru
-kredite-online.de.ms
-kredite-portal.de
-kredite-sofortzusage.de
-kreditkarten-sofort.de.ms
-kredit-ratenkredit-sofortkredit.de
-kuangye.net
-kupibuket.ru
-kyfarmhouse.org
-kyny\.net
-labelcan\.com
-lablog.biz
-lach-ab.de
-lajares.to
-lakesideartonline.com
-lalinea.to
-lambethcouncil.com
-landscape-painting.as.ro
-langsrestaurant.com
-lannygordon.com
-lannythurman.com
-lanreport.com
-lantai.com.cn
-lanucia.to
-laptopy.biz.pl
-laser-eye.co.uk
-laser-eye-centre.co.uk
-laser-eye-correction.co.uk
-lasikclinic.co.uk
-lastminute-blitz.de
-lasvegas-real-estate.net
-las-vegas-real-estate-1.com
-lasvegasrealtor.com
-lasvegastourfinder.com
-latina-sex.ws
-lavalifedating.com
-lavinuela.to
-law-translation\.com
-lcd-cn.com
-leadbanx.com
-leanmusclexreview\.org
-leather168.com
-leatherfamous.com
-lechery-family.com
-left-page.com
-legalblonde.com
-leonabruno.com
-lesbian-girl.us
-lesbichex.com
-leseratten-wunderland.de
-letemgo.de
-letomol\.com
-leveltendesign.com
-lexapro-web.com
-lgt-clan.ru
-liaozhi\.org
-lifedna.com
-life-insurance-advisor.com
-lifeinsurancefinders.com
-lifeslittle-luxuries.co.uk
-lifuchao.com
-light518.com
-likesmature.com
-lindsaylife\.com
-lingerie-guide\.org
-lingerie-land.com
-link-dir.com
-linkedin\.com\.cn
-linkliste-geschenke.de
-linseysworld.com
-linuxwaves.net
-lipitordiscount.biz
-lipitordiscount.com
-list1st.com
-listbanx.com
-livetexasholdem.com
-livetreff.tv
-livevents.de
-livingchina.cn
-lizziemills.com
-lkcx\.com
-l-king.com.cn
-lliippoo\.org
-lloret.to
-lnhbsb\.com
-loaninfotoday.com
-loan-king.com
-loans.de.vu
-loans-4all.com
-loan-superstore.com
-locationcorse.free.fr
-logical-planet.co.uk
-logod-helinad-mangud.com
-logoer-mobil.com
-logos?-(beltonen|downloads|free|klingeltone|max|melodias|mobiel|mobile-repondeurs?|moviles|phones|repondeurs?-mobile|spiele|tones?).com
-logosik.pl
-logos-logos.be
-logos-melodijas-speles.com
-logotyper-mobil.com
-lolita-bbs.name
-longcrossgroup.co.uk
-longslabofjoy.com
-longsuncard.com
-lookforukhotels.com
-lop\.t28\.net
-loraxe.com
-lotye\.schillerstudent\.com
-love.csnec.net
-lowclass.de
-lowcost.us.com
-lowest-rates-mortgages.com
-ltjz2000.com
-lucking.com.cn
-luffassociates.co.uk
-luxus-gourmetartikel.de
-lvrealty.net
-lygweb.com
-lynskey-admiration.org.uk
-lyriclovers.com
-ly-yufeng.com
-lzbiz\.com
-ma-cabinet.com
-machine168.com
-machine88.com
-macinstruct.net
-magus1.net
-mail333.com
-mainentrypoint.com
-mainjob.ru
-majorapplewhite.info
-make-money-investment.info
-malaga-costa-del-sol.to
-mallorca-island.to
-mallorycoatings.co.uk
-man.interhousing.com
-management666.com
-map666\.com
-marriage666.com
-marshallsupersoft.com
-marteq-on.com
-matalascanas.to
-match-me-up.com
-matureacts.com
-mature-big-tits.net
-maturefolk.com
-mature-old-mature.com
-mature-women\.enter-in\.etowns\.org
-maxigenweb.com
-maxxsearch.com
-mba100.com
-mbgeezers.com
-medcenterstore.com
-mediaaustralia.com.au
-medications-4all.com
-medicine-supply.com
-meds-pill.com
-medyep.com
-meetpeopleforsex.com
-mega-spass.com
-melincs.org
-melodias-logos-juegos.com
-melucky.com
-members.fortunecity.com/kennetharmstrong
-members.lycos.co.uk/tramadol
-menexis.com
-mengfuxiang.com
-menguma.co.uk
-menguma.com
-menorca.to
-men-sex.us
-menzyme.com
-meoko.com
-mewqsd.org
-mercedesazcona.com.ar
-mercefina.com
-merditer.com
-merlinworld.com
-mesothelioma-asbestos-help.com
-mesothelioma-health.com
-metroshopperguide.com
-mfdy8\.cn
-mhgzs\.com
-micrasci.com
-microscope-cn.com
-midi\.99caixin\.com
-mietangebote-domain.de
-migraine-relief.com
-mijas.to
-mikebunton.com
-mikewsd.org
-milesscaffolding.co.uk
-millionaire-blogs.com/cosmeticdentistry
-minxinghb.com
-missoula.com/blog/occupation
-misterwolf.net
-mmorpg-headlines.com
-mms.coay.com
-mmsanimati.com
-mneuron.com
-mobilefor.com
--mobile-phones.org
-mobilequicksale.com
-mobile-repondeurs?-logos?.com
-mobilesandringtones.com
-mode-domain.de
-mode-einkaufsbummel.de
-molding-tool.com
-moltobene.ru
-momcare.com.cn
-monarch.com.cn
-moneybg.com
-money-room.com
-montaguefineart.com
-mookyong.com
-mooo.com
-mortage-4all.com
-mortgage-info-center.com
-mortgage-rates-guide.net
-mortgages-links.net
-mortloan.com
-mostika.us
-mother-son-incest-sex.net
-moto-cn.com
-motonet.pl
-motor2008.com
-movie-online123.com
-movies6.com
-mp3download.bz
-mp3plane\.com
-mp3x.biz
-mpeg2pci.com
-mqblog.cn/user1/jipiao
-mqblog.cn/user1/qiufeng
-mqfzj.blog.ccidnet.com
-mrpiercing.com
-mujweb.cz
-mujweb\.cz
-multipurpose-plants.net
-multiservers.com
-multivision.com.hk
-murcia.to
-musica-gratis.biz
-musica-gratis.org
-musica-karaoke.net
-musical88.com
-musica-mp3.biz
-musicamp3.us
-musiccheap.us
-music-downloads-links.com
-musicenergy.com
-muxa.ru
-mxbearings.com
-mxzt.com
-my.nbip.net/homepage/nblulei/
-my-age.net
-myasiahotels.com
-mybestclick.com
-mybooktown.com
-mycv.cn
-mycv.com.cn
-mycv\.com\.cn
-mydatingagency.com
-my-dating-agency.com
-mydear\.biz
-my-discount-cigarettes.com
-myeuropehotels.com
-myfavlinks.de
-myflooring\.org
-mygenericrx.com
-mymistake.biz
-mymixture.com
-my-mom.kicks-ass.net
-myricenet.com
-myrtlejones.com
-myseo.com.cn
-MyServer.org
-my-sex-toys-store.com
-myslimpatch.com
-mystify2001.com
-naar\.be
-nabm(il|li)or.com
-nabpak.org
-naked-gay.us
-naked-pussy.us
-naked-womens-wrestling-league-dvds.com
-naked-womens-wrestling-league-videos.com
-nancyflowerswilson.com
-nanyangcn.net
-narod.ru
-nasty-pages.com
-natel-mobiles.com
-natural-barleygreen.com
-natural-breasts-enhancement.net
-naturalknockers.net
-navinic\.com
-nazari.org
-nbflashlights.com
-nbip.net
-ne1\.net
-nease.net
-nebulax.net
-necsi.com.cn
-neiladams.org.uk
-nemarov.com
-nerja.to
-netbank.cn
-netfirms.com
-netisc\.net
-netizen.org
-netlogo.us
-net-mature.com
-netnetn.com
-netsuns.net
-netsuns\.net
-netsx.org
-net-von-dir.de
-neurogenics.co.uk
-neverback.com
-new-cialis.com
-newfurnishing.com
-newgallery.co.uk
-newideatrade.com
-newsnewsmedia.com
-newxwave.com
-nextdayid.co.uk
-nfl-football-tickets.biz
-nicepages.(biz|net|org)
-nice-pussy.us
-niceshemales.net
-nichehit.com
-nicolepeters.com
-nieruchomosci.biz.pl
-nifty-erotic-story-archive.blogspot.com
-nikechina.net
-nikeproduct.com
-nikeshoesshop.com
-nikeshoeswholesale.org
-nikesupplier.com
-nikkiwilliams.info
-njhma.com
-njlvtong.com
-njningri.com
-njunite.net
-njuyq.com
-nnyykkii\.org
-no-1.com.cn
-no-1.org.cn
-no1pics.com
-no-cavities.com
-nohassle-loans.com
-no-more.dyndns.org
-noni-?(jungbrunnen|top-chance|vitalgetraenk|expert).com
-nonstopsex.org
-noslip-picks.com
-notebook555.com
-no-title.de
-notsure.de
-novacspacetravel.com
-novosanctipetri.to
-nr-challenges.org
-nude-(black|movies?|videos?).us
-nude-teens.name
-nudevol.us
-nuevaandalucia.to
-nutritional-supplements.ws
-nutritionalsupplementstoday.com
-nwwl-dvds.com
-nwwl-videos.com
-nz.com.ua
-office-021\.com
-office-stock\.com
-officialdarajoy.com/wwwboard
-officialdentalplan.com
-officialsatellitetv.com
-offseasonelves.com
-ohamerica.org
-okings.com
-okuk.org
-oldgrannyfucking.com
-oliva.to
-olsenstyle.com
-omega-fatty-acid.com
-omeida.com
-omniagroup\.it
-one-cialis.com
-one-debt-consolidation.com
-onepiecex.net
-one-propecia.com
-oneseo.com
-one-soma.com
-onexone.org
-online-?hgh.com
-online-auction-tricks.com
-online-blackjack-online.com
-online-buy-plavix.com
-online-casino.descom.es
-online-ccc.com
-online-credit-report-online.com
-online-dating-singles-service.com
-online-deals99.com
-on-line-degree.org
-online-dot.com
-online-escort-service.com
-online-flexeril.com
-online-games24x7.com
-online-games24x7.net
-online-games-links.net
-onlinehgh.com
-online-investing-ideas.info
-on-line-kasino-de.com
-online-medications24x7.com
-online-photo-print.com
-onlineshop.us.com
-onlinesmoker.com
-online-texas-?hold-?em.(net|us)
-on-pok.com
-opensorcerer.org
-operazione-trionfo.net
-oraengel.com
-oral-sex-cum.com
-orangeyogi.net
-order-?(claritin|effexor|medicine|naturals).(com|net)
-order-ambien-1.qn.com
-order-cialis-1.qn.com
-order-codeine.deep-ice.com
-order-levitra-1.qn.com
-order-valium-online.deep-ice.com
-orlandodominguez.com
-oro-compro\.com
-orospu.us
-otito.com
-ottawavalleyag.org
-ourhealthylife.net
-our-planet.org
-outoff.de
-ovulation-kit.com
-owaceilings.co.uk
-owns1.com
-ownsthis.com
-oxford-english.com
-oxgm.com
-p105.ezboard.com/bdatingpersonalsadultdating
-p5.org.uk
-p7.org.uk
-p8.org.uk
-p9.org.uk
-pack001.com
-packing-machine.com
-pafu.w4.dns2008.cn
-page.zhongsou.com
-pagerealm.com
-pages4people.com
-paidsurveysforall.com
-pai-gow-keno.com
-paisleydevelopmentassociation.org
-paite.net
-pajara.to
-pandoraaustraliastockists\.com
-pandorajewelryco\.com
-panpanddc.com
-pantandsocks.co.uk
-paperscn.com
-paper-translation\.com
-paris-(movie|naked|nicky|nikki)-hilton.blogspot.com
-paris-and-nicky-hilton-pictures.blogspot.com
-paris-hilton-video-blog.com
-paris-hilton-videos.biz
-parkersexecutivecar.co.uk
-partnersmanager.com
-partnersuche-partnervermittlung.com
-partybingo.com
-passende-klamotten.de
-passion.org.cn
-passwordspussynudity.com
-pastramisandwich.us
-pasuquinio.com
-paybacksh\.com
-payday-loan\.de\.com
-payday-loan-payday.com
-paydayloans-guide\.com
-paysites.info
-pbali\.com
-pc-choices.com
-pcdweb.com
-pcpages.com
-pcpages.com/abyssal
-pcvr.com.cn
-pdxx.com
-peak-e.com
-peepissing.com
-penase\.org
-penelopeschenk.com
-peoplegrad\.gen\.in
-perepug\.ig3\.net
-perfect-dedicated-server.com
-perfect-mortgage-lead-4-u.com
-personalads.us.com
-personal-finance-tips.com
-personalfitnesstrainer\.co\.za
-personal-writer\.com
-personals-online-personals.com
-petlesbians.com
-petroglyphx.com
-pety-viagra.newmail.ru
-pfxb.com
-phantadu.de
-pharmaceicall.com
-phente.m...\.do\.nu
-phentermine
-phentermine.webzdarma.cz
-phone-cards-globe.pushline.com
-phono.co.il
-photobloggy.buzznet.com
-phrensy.org
-pickevents.com
-pickone.org
-picsfreesex.com
-pics--movies.com
-pics-stories.com
-picsteens.com
-pictures-movies.net
-piercing-auswaehlen.de
-piercing-magic.com
-piercingx.com
-pill(-buy|blue|chart|hub|hunt|inc|tip).com
-pimp(fans|hop|hos|space)\.com
-pinkzoo.com
-pinnaclepeakrealty.com
-pj-city.com
-planetluck.com
-plastic168.com
-playandwin777.com
-playandwinit777.net
-play-cash-bingo-online.com
-player-tech.com
-playgay.biz
-playmydvd.com
-play-texas-hold-?em.us
-play-texas-holdem-today.net
-playweb.blogspot.com
-plazaerotica.com
-plcm.com.cn
-plygms.de
-pm.tsinghua.edu.cn
-pocket-pussy\.org
-poizen.info
-pokemonx.biz
-polifoniczne.org
-polott.org
-polyphone.us
-pompini.nu
-Ponderosa
-ponytest.com
-pops.pp.ru
-portedeurope\.org
-post.baidu.com
-posters?-?shop.us
-power-rico.de
-power-tools.rx24.co.uk
-predictive-dialers.org
-pregnancy-guide\.org
-pregnant\.sumale\.net
-pregnant-sex-free.us
-p-reise.de
-pre-machine.com
-prepaid-telephonecards.co.uk
-prepaylegalinsurance.com
-preteen-(models|sex|young).(biz|info|net)
-prettypiste.com
-princeofprussia.org
-printer-cn.com
-prism-lupus.org
-privacy-online.biz
-private-krankenversicherung-uebersicht.com
-private-network.net
-pro-collegefootballbetting.com
-product-paradise.com
-profifachuebersetzungen\.de
-projector-me.com
-promindandbody.com
-prom-prepared.com
-propecia.bravehost.com
-propecia-for-hair-loss.com
-propecia-for-hair-loss.net
-propecia-info.net
-propecia-store.com
-property2u.com
-property2u\.com
-prosearchs.com
-protech.net.cn
-psearch.163.com
-pseudobreccia60.tripod.com.ve
-psites.(biz|net|org|us)
-puertaumbria.to
-puertobanus.to
-puertoreal.to
-punksongslyrics.com
-purchase-ambien.qn.com
-purchase-valium.hotusa.org
-pureteenz.com
-pushline.com
-pussy-(d|cum|movies).(com|us)
-pussy\.the-best\.etowns\.org
-qd-heli.com
-qiangzhe\.cn
-qianyijia.com
-qingchundoua.cn
-qitao.wy8.net
-qj100\.net
-qm0?0[0-9]\.com
-qmnet\.cn
-qmwa\.com
-qqba.com
-qqmei.com
-quangoweb.com
-quickchina.com.cn
-quickdomainnameregistration.com
-quick-drugs.biz
-quick-drugs.com
-quickie-quotes.com
-qumingqiming.com.cn
-qybalancingmachine.com
-qz168.com
-qzkfw.co
-racconti-gay.org
-radsport-artikel.de
-raf-ranking.com
-ragazze-?\w+\.[a-z]{2,}
-rampantrabbitvibrator.co.uk
-randysrealtyreview.com
-ranklink.org
-rape-(fantasy-pics|stories).(biz|com)
-rapid-merchant-account.com
-ratenkredit-center.de
-ratenkredit-shop.de
-raw-pussy.us
-raymondmill.biz
-rbfanz.com
-readytocopy\.com
-real.net.cn
-real-estate-investment-online.info
-realestate-max\.com
-realforexbroker\.com
-reality-sites.com
-reality-xxx.biz
-real-sex.us
-realtickling.com
-real-worldinternational.co.uk
-rebjorn.co.uk
-recycle.myrice.com
-redcentre.org
-redi.tk
-refinance-mortgage-home-equity-loan.com
-reggaeboyzfanz.com
-reggdr.org
-registerxonline.com
-reglament-np.ru
-reisen-domain.de
-relay888.com
-relievepain.org
-relocationmax\.com
-rentalcarsplus.com
-repondeurs-logos-mobile.com
-republika.pl
-restaurant-l.de
-reviewonlinedating.com
-rfhk\.cn
-rfhk\.net
-rfhk\.org
-rfhz\.com
-rfhz\.net
-rfhz\.org
-ricettegolose.com
-richshemales.com
-rincondelavictoria.to
-ringsguide\.org
-ringsignaler-ikon-spel.com
-ringtone-logo-game.com
-ringtoner-logoer-spill.com
-ringtonespy.com
-rittenhouse.ca
-rituo.com
-riyao.com.cn
-roboticmilking.com
-roche.to
-romane-buecher.de
-romeo-ent.com
-ronda.to
-room-ordering.com
-roscoeluna.com
-rota-andalucia.to
-rotek.com.cn
-roulette---online.com
-roulette-w.com
-royaladult.com
-royalfreehost.com/teen/amymiller
-royalprotectionplan\.com
-rr365.net
-rrank.net
-ru(send|idea)\.com
-ru21.to
-ruilong.com.cn
-rx4.mine.nu
-rxbkfw.com
-rx-central.net
-rx-lexapro.biz
-rxpainrelief.net
-rx-phentermine.newmail.ru
-rx-store.com
-rxweightloss.org
-rydoncycles.co.uk
-safetytech.cn
-salcia.co.uk
-salearnerslicense\.co\.za
-sandrabre.de
-sanfernando.to
-sanlucar.to
-sanpedro.to
-santamaria.to
-sarennasworld.com
-satellite.bravehost.com
-satellite-direct-for-you.com
-satellite-network-tv.com
-satellitetv-reviewed.tripod.com
-saveondentalplans.com
-saving-money-hyip.info
-saw-blade.net
-sba\.com\.cn
-sbdforum.com
-sbn\.bz
-sbt-scooter.com
-scent-shopper.com
-schanee.de
-schmuck-domain.de
-scottneiss.net
-scpv.net
-screencn.com
-scuba-guide\.com
-s-cyclobenzaprine.fromru.com
-sd-dq\.com
-sdsanrex.com
-search.online.sh.cn
-search.sohu.com
-search-1.info
-search722.com
-search-engine-optimization-4-us.com
-searchfix.net
-sec66.com
-sec-battery.co.uk
-secureroot.org
-security-result.com
-seitensprung-gratis.com
-selectedsex.com
-selena-u.ru
-selten-angeklickt.de
-sempo-tahoe.com
-sense.com.cn
-sensor168.com
-seodetails\.com
-seov.net
-seoy.com
-servicesmax\.com
-se-traf.com
-seven-card-stud.biz
-seven-card-stud.us
-sevilla-andalucia.to
-sewilla.de
-sex-(4you|bondagenet|lover|photos).org
-sex(ushost|webclub|websites).com
-sex--.*\.com
---sex\.com
-sex4dollar.com
-sexbrides.com
-sexcia.com
-sexe.vc
-sexforfree.webzdarma.cz
-sex-friend.info
-sexglory.com
-sexiestserver.com
-sexingitup.com
-sexjobsonline\.com
-sex-livecam-erotik.net
-sex-mates.info
-sexmuch.com
-sexo9.com
-sex-pic-sex.com
-sexplanets.com
-sex-pussy.us
-sexschlucht.de
-sexshop.tk
-sexshop-sexeshop.com
-sex-toys-next-day.com
-sextoysportal.com
-sexual-shemales.com
-sexual-story.blogspot.com
-sexvoyager.com
-sexy-(ass|babes|lesbian|pussy).us
-sexy-celebrity-photos.com
-sexy-girls.org
-sexy-girls\.org
-sexynudea.com
-sfondi-desktop-gratis.com
-sfondi--gratis.com
-s-fuck.com
-shadowbaneguides.net
-shannon-e.co.uk
-shareint-store.com
-sheffield800.freeserve.co.uk
-shellbitumen.com.cn
-shemalesex.biz
-shemalesland.com
-shemalezhost.com
-shemalki.com
-Shemok
-shengdanuclei.com
-shenman.com
-shfldz\.com
-shfx-bj.com
-shimiana.cn
-shinylights\.org
-shirts-t-shirts.com
-shluhen.lir.dk
-shoesbuynow.com
-shoeswholesale.cn
-shop.tc
-shop24x7.net
-shop263.com
-shop-opyt.com
-shopping-cn.com
-shoppingideen-xxl.de
-shopping-liste.de
-shoppyix.com
-showsontv.com
-sh-shengde.com
-shtestm.com
-shtravel.net
-shunfeng-pioneer.com
-sh-xinping.com
-simplemeds.com
-simpsonowen.co.uk
-sina.com.cn
-sinfree.net
-singtaotor\.com
-sinoart.com.cn
-sino-bee.com
-sinodragon.freewebpage.org
-sinostrategy.com
-sinski.com
-sister8.com
-site\.neogen\.ro/xy[\w]+/files/ps_imagini\.php
-site-mortgage.com
-sitesarchive.com
-site-webarea.com
-sjdd.com.cn
-sjlstp\.com
-sjzyxh.com
-skf-baijia.com
-skidman.com
-ski-resorts-guide.com
-slimmobile.org
-slmj.com
-slng.de
-slotmachinesguide.net
-slot-machines-slots.com
-slots-w.com
-slowdownrelax.com
-slpblogs.com/expenditure
-slutcities.com
-slut-wife-story.blogspot.com
-smartdot.com
-smartonlineshop.com
-smeego.com/gettext
-smerfy.pl
-smutwebsites.com
-sneakysleuth.com
-s-norco.fromru.com
-so18.cn
-socoplan.org
-sofortkredit-tipps.de
-sofort-mitgewinnen.de
-soft.center.prv.pl
-soft-industry.com
-softsenior.com
-softwaredevelopmentindia.com
-software-einkaufsmarkt.de
-software-engine.org
-software-linkliste.de
-softwarematrix\.org
-software-review-center.org
-sohublog.com
-soittoaanet-logot-peli.com
-sol-web.de
-soma-(cheap-soma|solution|web).com
-soma.st
-somaspot.com
-somee.com
-sommerreisen-2004.de
-sonderpreis.de.com
-songshangroup\.com
-sorglos-kredit.de
-sorry\.yi\.org
-sotogrande.to
-sou23.com
-soulfulstencils.com
-source.dyndns.dk
-sowang\.com/translation\.htm
-spaces.msn.com/members/wangluoyingxiao/
-spacige-domains.de
-spannende-spiele.de
-spassmaker.de
-speedy-insurance-quotes.com
-spiele-kostenlose.com
-spiele-planet.com
-sportartikel-auswahl.de
-sportecdigital.com
-sportlich-chic.de
-sports---betting.com
-sports-inter-action.com
-spp-net.de
-spy-patrol.com
-spyware-links.com
-spzd\.com
-ss-cn.com
-s-sites.net
-ssy-web.com
-staffordshires.net
-stars-laser.com
-stationery555.com
-stationfoundation\.org
-statusforsale.de
-steel168.com
-steelstockholder.co.uk
-stellenangebote-checken.de
-stellenangebote-l.de
-stevespoliceequipment.com
-stfc-isc.org
-sting.cc
-stock-cn.com
-stock-power.com
-stolb.net
-stop-depression.com
-stopp-hier.de
-stopthatfilthyhabit.com
-stories-adult.net
-stories--archive.com
-stories-inc.com
-striemline.de
-strivectinsd.com
-stst-cn.com
-studychannels\.com
-stunningsextoys.com
-styrax-benzoin.com
-submit-your-cock\.info
-success-biz-replica.com
-suckingsex\.info
-sudian.com.cn
-suma-eintragen.de
-sumaeintrag-xxl.de
-sunbandits.com
-sunnyby.com
-suonerie-(center|download|loghi-gratis).com
-suonerieloghix.com
-suoneriex.net
-suoyan.com
-super-celebs.com
-super-cialis.com
-surfe-und-staune.de
-susiewildin.com
-sutra-sex.com
-svitonline.com
-swan-storage.com
-sweet-?(horny|hotgirls).com
-sweetapussy\.info
-swiftcashforgold\.com
-swinger-story.blogspot.com
-swing-in-golf.com
-swissking\.net
-switch168.com
-switch88.com
-sxcoal.com
-sydney-harbour.info
-sylphiel.org
-sylviapanda.com
-sysaud.com
-szpromotion.com
-t35.com
-t3n.org
-tabsinc.com
-t-agency.com
-taifudamy\.com
-tailongjixie.com
-take-credit-cards.com
-taliesinfellows.org
-talkie.stce.net
-talktobabes.com
-tamsquare.com
-tang\.la
-tanganyikan-cichlids.co.uk
-tangzhengfa.com
-tapbuster.co.uk
-taremociecall.com
-targetingpain.net
-tarifa.to
-tattoo-entwuerfe.de
-tb-china.com
-tcom-control.co.uk
-tdk-n.com
-teajk\.com
-teardust.net/blog/bulletingboard
-techfeng.com
-teen-(babes|movie|video|xxx).us
-teenblog.org/alerts
-teenblog.org/handicrafts
-teen-boys-fuck-paysite.com
-teen-d.com
-teens7ever.info
-teensluts.org
-teenxxxpix.net
-teflontape.cn
-tejia\.net\.cn
-telechargement-logiciel.com
-telematicsone.com
-telematiksone.co.uk
-tenerife-info.to
-terminator-sales.com
-terra.es/personal
-testersedge.com
-testi.cc
-tests-shop.com
-tette.bz
-tettone.cc
-teulada.to
-texas-hold-em-(4u|555|winner).(com|net)
-texas-holdem-0.com
-texasholdem777.net
-texas-holdem-a.com
-texas-holdem-big.com
-texasholdem-flip-flop.com
-texasholdemking.com
-texas-holdem-now.com
-texasholdem-online.us
-texasholdemsite.net
-texas-hold-em-w.com
-textile88.com
-tgplist.us
-the1930shome.co.uk
-the-bestiality-stories.stories-movies.com
-theblackfoxes.com
-the-boysfirsttime.com
-theceleb.com
-thecraftersgallery.com
-the-date.com
-thefreecellphone.com
-thehadhams.net
-the-horsesex.stories-movies.com
-the-hun-site.com
-the-hun-yellow-page-tgp.com
-themadpiper.net
-the-pill-bottle.com
-the-proxy.com
-thepurplepitch.com
-thepussies\.info
-therosygarden.com
-the-sad-diary-of.mine.nu
-thesoftwaregarage.co.uk
-thespecialweb.com
-thewebbrains.com
-thfh\.com
-thorcarlson.com
-thoth\.cn
-thumbscape.com
-thuriam.com
-tianjinpump\.com
-ticket88.com
-ticket-marktplatz.de
-tickets4events.de
-tiere-futter.de
-tiffany-towers.com
-tikattack.com
-timead.net
-timeguru.org
-timescooter.com
-tips-1a.de
-tire-cn.com
-tits-center.com
-tits-cumshots.net
-tjht.net
-tjht\.net
-tjtools.com
-tjwatch.com
-tl800\.com
-tldyjc.com
-tmrr.com
-tofik.pl
-tokyojoes.info
-toner-cartridge\.mx\.gs
-tontian.com
-tonzh.com
-topaktuelle-tattos.de
-top-cialis.com
-topcities.com
-top-dedicated-servers.com
-top-des-rencontres.com
-top-fioricet.com
-top-internet-blackjack.com
-top-of-best.de
-top-online-slots.com
-top-point.net
-top-result.com.cn
-top-skelaxin.com
-top-soma.com
-top-the-best.de
-toques-logos-jogos.com
-torch.cc
-torredelmar.to
-torremolinos-costa-del-sol.to
-torrox.to
-toshain.com
-tossa.to
-totallyfreecreditreport.org
-total-verspielt.de
-touchweb\.com\.cn
-touchwoodmagazine.org.uk
-toy-china.com
-traceboard\.com.cn
-tracyhickey.com
-tradeba.com
-tradeinvests\.cn
-tradeinvests\.org
-traffic4bidz\.com
-training-one.co.uk
-tran4u.com
-tranny-pic-free.com
-trannysexmovie.com
-transcn.net
-transestore.com
-transpire.de
-traum-pcs.de
-trendsbuilder.com
-treocat.com
-triadindustries.co.uk
-troggen.de
-troie.bz
-trolliges.de
-trucchi-giochi.us
-trueuninstall.com
-ts998\.com
-ts-wood.com
-tt33tt.com
-tt7.org
-ttuuoopp\.org
-tuff-enuff.fnpsites.com
-tumor-cn.com
-tuofaa.cn
-tv-bazzar\.com
-tygef.org
-tyjyllrj.go1.icpcn.com
-tykh\.com\.cn
-tzonline.cn
-ua\-princeton.com
-ufosearch.net
-ukeas.com
-uk-virtual-office-solutions.com
-ultracet-web.com
-ultraseek.us
-unbeatablecellphones.com
-unbeatablemobiles.co.uk
-unbeatablerx.com
-unccd.ch
-underage-pussy.net
-undonet.com
-unexpectedmovement.b4net.lt
-uni-card.ru
-universalplastic.com
-unlockuriphonenow\.com
-unscramble.de
-unterm-rock.us
-uoo.com
-upoisoning.com
-ups123.com
-upsms.de
-urlaubssonne-tanken.de
-usa-birthday-flowers.com
-usa-car-insurance.com
-usa-car-loans.com
-usbitches.com
-us-cash.com
-uscashloan.com
-user1.7host.com
-us-meds.com
-uswebdata.com
-uusky.com
-uusky.net
-uusky.org
-uusky.zj.com
-uusky2.home.sunbo.net
-uvinewine.co.uk
-u-w-m.ru
-v(27|29|3).(net|be)
-vacation-rentals-guide.com
-vaiosony.com
-valentine-gifts.qn.com
-valeofglamorganconservatives.org
-valium-online.1024bit.at
-valium-online.sinfree.net
-venera-agency.com
-veranstaltungs-tickets.de
-vergleich-versicherungsangebote.de
-versicherungsangebote-vergleichen.de
-versicherungsvergleiche-xxl.de
-versteigerungs-festival.de
-verybrowse.com
-verycd.com
-verycheapdentalinsurance.com
-vfrrto.org
-viaggix.com
-viagra\.freespaces\.com
-viapaxton.com
-viasho.com
-video-n.com
-videoportfolios.com
-vietdiary.com/andromedical
-vilentium.de
-vilez\.zenno\.info
-villagesx.com
-villajoyosa.to
-villamara.net
-vindaloosystems\.com
-vip-condom.com
-vitamins-for-each.com
-vivalatinmag.com
-vivlart.com
-vixensisland.com
-vod-solutions.com
-voip99.com
-voip99.net
-voip-guide.org
-voyancegratuite\.com
-vttolldd.org
-vtsae.org
-vttthtgg.org
-waldner-msa.co.uk
-warblog.net
-wasblog.com/ascitis
-washere.de
-watches-sales.com
-watchonetreehill\.org
-waterbeds-dot.com
-waycn.com
-wblogs.com
-wcdma2000.com
-wcgaaa.org
-wchao.net
-wdc\.com\.cn
-wding.com
-we.rx.pp.ru
-weareconfused.org.uk
-wearethechampions.com
-weaver.com.cn
-web.csnec.net
-web3dchina.com
-webanfragen.de
-webblogs.biz
-webcam-erotiche.com
-webcenter.pl
-web-cialis.com
-webcopywizard.net
-w-ebony.com
-webpage-cn.com
-webpark.pl
-webrank.cn
-web-revenue.com
-websamba\.com
-websitedesigningpromotion.com
-website-expansion.com
-websitespace-cn.com
-webzdarma.cz
-wecony.com
-weddings-info.com
-weddings-links.com
-weedns.com
-weighlessrx.com
-weight-loss-central.org
-weight-loss-links.net
-weightlossplace.net
-weitere-stellenangebote.de
-welan\.com
-welding\.mx\.gs
-we-live-together-4u.com
-wellness-getraenk.de
-weroom.com
-westzh.com
-wet-?(4all|pussy|horny).(com|us)
-whitehouse.com
-white-shadow-nasty-story.blogspot.com
-whizzkidsuk.co.uk
-wholesalepocketbike.com
-willcommen.de
-wincmd.ru
-wincrestal.com
-windcomesdown.com
-wine-booking.com
-wine-shop001.com
-wirenorth.com
-wiset-online.com
-witch-watch.com
-witji.com
-witz-net.de
-wizardsoul.com
-wjmgy.com
-wol\.bz
-women-fitness\.org
-workfromhome-homebasedbusiness.com
-worldblognet.com/eurasia
-world-candle.com
-world-cheese.com
-worldmusic.com
-worldsexi.com
-worldwide-(deals|games|holdem).(com|net)
-worldwide.php5.sk
-wotcher.de
-wrrirk\.poes\.net
-wujing-eyes.com
-wuyue.cn
-ww\.\d+\.com
-www.bhcyts.cn
-www.bjicp.com
-www.bungee-international.com
-www.it01.com.cn
-www.lamp-expert.com
-www.richtone.com.cn
-www.sex-portal.us
-www.webcamss.com
-www\.76e\.net
-www\.8z\.cn
-www\.banzhao\.com
-www\.chat-live\.net
-www\.pasca\.info
-\.roth-401k-forum\.com
-www-sesso
-www-webspace.de
-wxals.com
-wxboall.cn
-wxfl.net
-wxwz.fwhost.com
-wxwz.tabrays.com
-x24.com.ru
-x8x.weedns.com
-x911\.net
-xanax.qn.com
-xanax-online.qn.com
-xaper.com
-xazl.net
-xazlkjh.blog.ccidnet.com
-x-baccarat.com
-x-baccarat.us
-x-beat.com
-x-bingo.com
-x-craps.com
-x-craps.us
-xdolar.com
-x-fioricet.com
-xfreehosting.com
-xgsm.org
-xhhj.com.cn
-xianggangjc.com
-xianliming.com
-xianwahl\.com
-xinchen.net.cn
-xin-web.de
-xinyifang.net
-xinyitong\.org
-x-jack.us
-xlboobs.net
-xmtmdart.com
-xnan2.91x.net
-xnan2.blogdriver.com
-xnxxx.com
-x-pictures.net
-x-pictures.org
-xpictx.com
-xprv.com
-xratedcities.com
-xrblog.com/ezetimib
-x-ring-?tones.com
-x-roulette.com
-x-roulette.us
-x-roullete.com
-xs3.com
-xsjby.cn
-x-slots.com
-x-slots.us
-x-stories.org
-xt[\w]+.proboards\d\d\.com
-xtnm.com
-xxshopadult.com
-xxx(chan|seeker|washington).com
-xxx-alt-sex-story.blogspot.com
-xxx-beastiality.com
-xxx-database.com
-xxx-dvd.biz
-xxx-erotic-sex-story.blogspot.com
-xxx-first-time-sex-story.blogspot.com
-xxx-free-erotic-sex-story.blogspot.com
-xxx-gay-sex-story.blogspot.com
-xxx-girls-sex.com
-xxx-password-web.com
-xxx-pussy.us
-xxx-rape.org
-xxx-sex-movies.org
-xxx-sex-story-post.blogspot.com
-xxx-spanking-story.blogspot.com
-xxx-stories.net
-xxx-story.blogspot.com
-xy[\w]+\.blogg.de
-xyu[\w]+\.easyjournal\.com
-xyxy.net
-xz[\w]+\.over-blog\.com
-xz9.com
-yaninediaz.com
-ycc-zipper.com.cn
-ychzn.com
-yculblog.com
-ygci.com
-yihongtai.com
-ying0.com
-yipu.com.cn
-yipu\.com\.cn
-yisounet.com
-yisounet.net
-yl-jx\.com
-ylqx.org
-ymf.name
-yoll.net
-you-date.com
-youll.com.cn
-young\-tender\.info
-young-ass.us
-yourdentalinsuranceonline.com
-yourowncolours.co.uk
-yourserver.com
-your-tattoo.de
-youyipu\.com
-yubatech.com
-yukka.inc.ru
-yunchou.com.cn
-yyhq.com
-z0rz.com
-zahara.to
-zahara-de-la-sierra.to
-zahara-de-los-atunes.to
-zazlibrary.com
-zbbz.com
-zcfounder.com
-zchb.com
-zenno\.info
-zeonline.com.cn
-zfgfz.net
-zgpt.cn
-zgqygl.com
-zgxbw\.cn
-zhiliaotuofa.com
-zhjx-sh.com
-zhkaw.com
-zhongzhou-sh.com
-zhqzw.com
-ziliaowang\.cn
-zipcodedownload.com
-zipcodesmap.com
-zithromax-online.net
-zjww\.com
-znpp.com
-zo.servehttp.com
-zoo(-zone|europe|fil).com
-zoo-?sex-?(pics|motion-videos|pictures)?.(com|biz)
-zoosx.net
-zorpia\.com/xt
-zpics.net
-zt148.com
-zum-bestpreis.de
-zxyzxy.com
-zybxg.net
-zy-image.com
-zzdh.com
-zzgj.net
-
-abouthongkong\.asexblogs\.com/
-abouthongkong\.bloggingmax\.com/
-abouthongkong\.blogslinger\.com/
-abouthongkong\.satublog\.com/
-berko\.com\.au/merry/
-blog\.bachhoacung\.ws/freey/
-blog\.mogway\.com/abouthongkong/
-blog\.myaliyah\.com/\?u=abouthongkong
-blogcharm\.com/huanger/
-blogs\.thesubculture\.com/\?u=abouthongkong
-cancerblog\.com\.au/abouthongkong/
-film4vn\.net/blog/\?w=lieey
-rockstart\.net/blog/\?u=abouthongkong
-smeego\.com/feier/
-tornblog\.com/abouthongkong/
-um\.com\.my/win/
-vfwnjwebcom\.org/abouthongkong/
-we-r-blogs\.com/\?w=drewer
-weblog\.statisticounter\.com/abouthongkong/
-www\.asiannotes\.com/art/
-www\.betterbrain\.com/blog/\?u=abouthongkong
-www\.billionaire-blogs\.com/abouthongkong/
-www\.blarbitration\.com/lelby/
-www\.blog3\.com/\?u=abouthongkong
-www\.blogfreely\.com/abouthongkong/
-www\.blogstuff\.co\.uk/\?u=abouthongkong
-www\.blogtoowoomba\.com/\?w=homuy
-www\.earthtank\.com/diewu/
-www\.elblog\.de/howue/
-www\.freescrapblogs\.com/red/
-www\.fsaalumni\.net/blog/\?u=abouthongkong
-www\.kosova\.ch/yourblog/\?u=abouthongkong
-www\.love2k\.com/weblogs/\?u=abouthongkong
-www\.mattian\.co\.uk/liuhcai/
-www\.nukeblog\.info/\?u=abouthongkong]]
-www\.pandablogs\.com/xiangang
-www\.picturethisblog\.com/\?u=abouthongkong
-www\.sblnet\.co\.uk/sblogger/abouthongkong/
-www\.skaffe\.com/weblog/abouthongkong/
-www\.slickblogs\.com/abouthongkong/
-www\.slpblogs\.com/abouthongkong/
-www\.soccerblogger\.co\.uk/\?w=uowek
-www\.sovereigngracesingles\.com/sgs_blog/\?u=abouthongkong
-www\.spottersblog\.com/tremo/
-www\.spweblog\.com/abouthongkong/
-www\.stitch-studios\.com/weblogs/\?u=abouthongkong
-www\.stu-c\.com/blogs/abouthongkong/
-www\.tatsulok\.com/yuer/
-www\.teenblog\.org/abouthongkong/
-www\.toiyeu\.net/nhatky/\?w=toiyew
-www\.totalvideogames\.com/blog/laner
-www\.vfwmowebcom\.org/nicer/
-www\.weblogone\.com/dry/
-www\.westwoodbapt\.org/blog/abouthongkong/
-www\.worldblognet\.com/abouthongkong/
-www\.ym1\.com/abouthongkong/
-chio92\.com
-onlinepoker\.happyhost\.org
-kolloidales-silber\.at
-sonyy1\.com
-tdk14\.com
-nyteam\.info
-ethock\.info
-pepsi14\.info
-jiayinte\.cn
-moxor\.info
-maxor\.info
-chevy\.ws
-adoption\.ws
-carpetcleaning\.ws
-hrentut\.org
-icwak\.info
-humela\.info
-guoyong\.com
-ziyangwz\.com
-zhanziyang\.com
-ziyangshiwo\.com
-short\-termhealthinsurance\.com
-scooter\-web\.org
-bikesplanet\.org
-aishwaryalife\.com
-jessicaalbalife\.com
-shakiralife\.com
-terapatricklife\.com
-adrianalimapics\.org
-wifiguide\.org
-wifi-planet\.org
-wifi-world\.org
-teainfo\.org
-pizzaguide\.org
-coffee-guide\.us
-chocolateplanet\.org
-girls-xxx-party\.com
-trinitao\.com
-tjshenguang\.com
-liveadulthost\.com
-speedorado\.com
-sexsdreams\.com
-carpassion\.com
-neureich\.de
-v-ringtones\.com
-4vti8\.com
-artsmediamag\.com
-ringtones\.konaxil\.be
-upcoming\.netteen\.net
-cfcsouthpugetsound\.org
-xultin\.info
-tidep\.info
-ythrip\.info
-yston\.info
-xution\.info
-gosle\.info
-tallygotmoves\.com
-sexstar2000\.com
-dante4all\.com
-q7voda\.com
-fetishrred\.spycams777\.com
-discovery\.teenorg\.net
-cosmo02\.net
-(cam|sex|gay|fuck|swingers|adult|dating|erotic|personal|ads|cum|wife-swap)[\w\-_.]*\.blogspot\.com
-irzar\.com
-gokdep\.com
-nittion\.com
-cheapwowgold\.co\.uk
-win\.com\.cn
-wowgoldworld\.com
-starsnak\.biz
-shop-now\.be
-whitewalker\.com
-beatroulette\.atspace\.com
-onlines-slots-game\.atspace\.com
-(friendlysearch|medchoice|freesearches|getmedicineeasy)\.bravehost\.com
-gihore\.info
-soseik\.info
-ithyr\.info
-letreal\.info
-efdmen\.info
-udwryp\.info
-bupyere\.info
-tagmyn\.info
-suogman\.info
-gegbyl\.info
-laww\.info
-plonehostingdemo\.nidelven-it\.no
-wiki\.opennetcf\.org/upload
-sprint\.zope\.it
-ssdcard\.info
-soujipiao\.com
-5ijipiao\.com
-jipiao126\.com
-jipiaoair\.com
-canjipiao\.com
-bjxiongfei\.com
-SaNaLHaCKERLaR\.ORG
-jspit7\.info
-kokoxx\.info
-donte\.info
-lib/exe/fetch.php\?media=
-imhotep\.sphosting\.com
-1-myspace-layout\.blogspot\.com
-dinmo\.cn
-51education\.com
-sispc.com\.cn
-sh-dzgs\.com
-teyi21\.com
-yizhish\.com
-oa586\.com
-watesi\.com
-sh-shenhuang\.com
-guojikuaidi\.com
-lbjq2h\.com
-xingaoweixing\.com
-shyw\.com
-shnakano\.com
-ihtc\.cn
-chonggong\.com
-kkvalve\.com\.cn
-uwb1hhc\.info
-vzh5k87\.info
-mvuxq60z\.info
-bodybillboardz\.com
-blog\.lide\.cz
-teeenp0rn\.org
-creditcarddebt\.neo\.cx
-dhzilnwr\.com
-hntwzokt\.com
-xoyeeuqx\.com
-badcredpersloan\.new\.fr
-securedcreditcard\.neo\.li
-hometown\.aol\.com
-(creditcons|creditreport|freeannualcr1|freecreditro|freecredits|cealis)\.monforum\.com
-fishmls\.com
-localendar\.com/public/
-\.maxblog\.pl
-\.phpbbx\.de
-foroswebgratis\.com
-(cabrini|annotation)\.bravepages\.com
-(asp|impaction|monocled|wriggle|maneating|migrations)\.1sweethost\.com
-(bailee|carrycot|webmasters|markab|homewards)\.dreamstation\.com
-(bohemians|encloses|gravel|verite|tenderfeet|sabers)\.exactpages\.com
-(drained|shuffles|diathermy)\.fcpages\.com
-(headland|similar|muffler|normalise|typologist|buckshots)\.741\.com
-(ctenophore|failles|whistle|mayflies|nestled|eunice)\.angelcities\.com
-(arcady|tulip|undreamt|impair|reamers|hokiest|catnapping)\.greatnow\.com
-(absolutely|bellman|kwangchow|fluctuant|trouping)\.wtcsites\.com
-(wafers|whensoever|prescient|spacious|acadia|toothsome|gasolines)\.envy\.nu
-(smuggles|showboat|ipecacs|skivvying|straying)\.150m\.com
-(suffixed|barbeques|dispersal)\.100freemb\.com
-(killer|grumbles|despoiler|termites)\.kogaryu\.com
-(adversely|militated)\.g0g\.net
-(brunettes|struts)\.o-f\.com
-(reconnect|clownishly)\.00freehost\.com
-(drygoods|fl|liberia)\.9cy\.com
-(membership|retarders|spoonfed|pointedly)\.freewebsitehosting\.com
-(unwiser|innervates|woofed)\.ibnsites\.com
-(goodnight|shortens|brokering)\.freewebpages\.org
-(epaulet|impotency|jewelries)\.1accesshost\.com
-homepage\.mac\.com/(nonreader|cartels|cornflour|docilities|unanswered|feelings1)/
-(imagist|phosphor|hatecrime|landward)\.freecities\.com
-(ainsurance|diflucanmed|mypropecia|1creditrepair)\.proboards104\.com
-(carisoprodol|tadalafil)\.mybbland\.com
-(refinancingmortgage|cheapautoinsurance|autoinsurancequote)\.(forumactif|actifforum)\.com
-fioricetmed\.blogcu\.com
-the-sabotage\.org
-spygrup\.org
-gencnesil\.org
-\.(blogsitemaking|blogginpoint)\.info
-hjlxmosb\.com
-dohzqmod\.com
-dadbhpsu\.com
-supermegapizdetc\.com
-cjbqixzs\.com
-tacmbuqe\.com
-qcprkjgp\.com
-wwcldvob\.com
-nhdwinyg\.com
-pewddohw\.com
-x-uqur\.org
-toyota-corollailf\.blogspot\.com
-corolla-toyota730\.blogspot\.com
-staticstroke\.tr\.cx
-vuhavrva\.com
-nfzwzphv\.com
-ljhasdic\.com
-peoazsog\.com
-szsbqqdb\.com
-kvxkloks\.com
-turkatesi\.net
-megaturks\.com
-rnsgroup\.us
-turkstorm\.org
-(ladyboy|shemale)\.viptop\.org
-nxyvarpv\.com
-shlmsapu\.com
-wjmlwkvk\.com
-www\.umes\.edu/accsupport/ossd/ossdchat/
-jiyxhkdf\.com
-hpdrsykw\.com
-wminyrxj\.com
-gucvfiuh\.com
-osgtpzde\.com
-szexqgix\.com
-susiesbeads\.net
-swliuxue\.com
-mindtouch\.com
-e-parishilton\.com
-\.vg\.edu
-euitaly\.info
-sprzedam\.pl
-wpi\.biz
-galadriel\.nmsu\.edu
-d007\.phpnet\.us
-todosvem\.info
-flowers-shop\.sitesfree\.com
-bcasinos1\.ovp\.pl
-\.greatkozel(site|world)\.info
-hack-e\.com
-eelive\.info
-asi\.0moola\.com
-Valintino.Guxxi
-web\.hit\.bg
-\.sportsinfoitaly\.info
-urlbee\.com
-site3\.info
-bdqt\.org
-\.svt\.pl
-ycaol\.com
-abunimah\.org
-aypp\.info
-poker\.blog\.drecom\.jp
-idisk\.mac\.com/ringtonesforyou
-chaco\.gov\.ar/meccyt/subsecyt/_act1
-forourbano\.gov\.ar/_forodisc/
-tx-bridge\.com
-beijingimpression\.com
-enrichuk\.com
-recphone\.cn
-kcmp\.cn
-pumppump\.cn
-officezx\.com
-vcd-dvd168\.com\.cn
-dinmoseo\.com
-wow-powerleveling-wow\.com
-e-fanyi\.net
-chongshang\.com\.cn
-radfort\.com
-eachost\.com
-bjjly\.net
-sino-(jipiao|liuxue|zufang|lvyou)\.com(\.cn)?
-citylight\.com\.cn
-e4u\.cn
-china-co\.com
-celsnet\.cn
-deqinfy\.com
-mycomb\.com
-dm-(baojie|jipiao)\.cn
-xttg\.cn
-cthb\.com\.cn
-china-byt\.com
-china(yuntong|lipin|yiyao)(\.com|\.net)?\.cn
-jinpack\.com
-xinyuanit\.com
-timeyiqi\.com\.cn
-mendean\.net
-zgpdw\.cn
-5i8811sf\.com
-my-projector\.net
-bjlhj\.cn
-imperial\.edu/maria\.coronel/
-vca\.org
-faculty\.chi\.devry\.edu/ksteinkr/
-encyko\.bee\.pl
-(synthroid|cialis|depakote|zithromax|cipro|aciphex-meds|diflucan-777|lipitor|zocor|norvasc|propecia|imitrex)\.ca\.cx # this is the specific regex
-\.ca\.cx # if noone complains we'll just keep that
-fpoker\.abc\.pl
-ftpoker\.ir\.pl
-ftpoker\.blogjapan\.jp
-wxerqxad\.com
-mnwftplr\.com
-ixgqwyaj\.com
-lglpvgdi\.com
-khmifkyd\.com
-fnabdymv\.com
-maomzyex\.com
-iprnhyeb\.com
-qytkgqkk\.com
-supermeganah\.com
-xnjehmqg\.com
-koufoadi\.com
-palgdhek\.com
-kcqdqjiv\.com
-xxqzcrbx\.com
-ejulbpnr\.com
-dfywxiza\.com
-wjdvppas\.com
-qfoijpym\.com
-usphwxib\.com
-fawhongh\.com
-xjayjaqh\.com
-hmaugptw\.com
-saeoazbj\.com
-pnjugiiu\.com
-xpubccoq\.com
-umbmjyug\.com
-lqbguwrt\.com
-1url\.org/go/1yolui
-uwrejaag\.com
-wjlnjljz\.com
-jacpusnk\.com
-51ticket\.net
-galasale\.com
-bjcdmaker\.com
-sdcy\.com\.cn
-ukpass\.org
-archifashion\.com
-sino-ups\.com
-qwerty\.wblogs\.org/2007/06/
-astroguia\.org/bitacoras/qwerty/2007/06/
-trinilopez\.com/_msgbrd/00002992
-thyoapan\.com
-qfrtsyrp\.com
-uooyqazf\.com
-websearchdir\.net
-firstwebdirect\.org
-webdironline\.org
-nwdirect\.org
-wwbol\.info
-maagrenn?a\.tripod\.com
-(trumtrum|bugaga)\.ifrance\.com
-(bugogo|damdan)\.ibelgique\.com
-(sukonah|tramtram)\.isuisse\.com
-(gurevin|grandan)\.awardspace\.com
-uubol\.info
-rrbol\.info
-iibol\.info
-qqbol\.info
-iibol\.info
-eoajx\.quotaless\.com
-hardcorerapecomics\.tripod\.com
-(qq|pp|yy)adv\.biz
-(dd|gg)coll\.info
-rietdekkersbedrijfscholten\.com
-taylorrain\.newsit\.es
-\.webdirext\.com
-(sh)?chfang\.com
-xianweijin\.com
-strawberrydelights\.com
-whichsideofthefence\.com
-it\.snhu\.edu
-free-online-dating
-sudu\.info
-shcbprint\.net
-toppowerlevel\.net
-mysiteup\.my2gig\.com
-globalceoforum\.com\.cn
-isefc\.com\.cn
-teamflyelectronic\.com
-hzmqzs\.com
-coolingame\.com
-mydofus\.com
-rs2myth\.com
-levelmyth\.com
-ankama\.us
-buy-dofus-kamas\.net
-vulturesknob\.com
-yournetexpert\.hostwq\.net
-fundorro\.net
-normalforce\.com
-sei-mein-bester-freund\.de
-titaniuexport\.kiev\.ua
-loveangelinajolie\.com
-movief\.5gbfree\.com
-ylhz\.net
-grendamix\.com
-89bm\.net
-temaxd\.cn
-gglhctm\.cn
-xgswd\.cn
-ofcpa\.com
-netbai\.net
-power-level\.net
-e489d\.com
-lingollc\.com
-boinbb\.com
-fourw\.jp
-sweepdesign\.jp
-chn-job\.com\.cn
-xfgkj\.com
-houseso\.cn
-beijingxiezilou\.com
-xiezilouxinxi\.com
-kibonbarcode\.com
-xzhfblp\.com
-linuxbj\.com
-pr1ma\.info
-dom\d\.info
-cardz\d\.info
-hom\d\.info
-rossa\d\.info
-svx\d\.info
-bomb\d\.info
-filmes[\w\-_.]*sexo
-filmes[\w\-_.]*gratis
-video[\w\-_.]*sexo
-video[\w\-_.]*gratis
-foto[\w\-_.]*nudo
-seeyo\.info
-suphost\.info
-freehostss\.info
-hostzz\.info
-19mb\.info
-freespase\.info
-host24h\.info
-cdq369\.com
-datangshutong\.com
-jonchn\.com\.cn
-sweepdesign\.jp
-bj5yuehua\.com
-jonchn\.com\.cn
-bjht888\.com
-zgxbzlw\.com
-466tv\.cn
-sixnet\.com\.cn
-99caigang\.cn
-cydjk\.com
-fstzb\.com
-znstudio\.net
-datangshutong\.com
-liaoxinbj\.com
-bjhrj\.cn
-flowervoice\.com
-jonchn\.com\.cn
-iiwezxmkwzht\.com
-miqiatwuypzw\.com
-hjigunxxrqaf\.com
-slondcnixlwj\.com
-bengfa168\.cn
-kaiquan\.com\.cn
-huigao-v\.com
-bgzb\.com
-spvalve\.com
-dltools\.cn
-rosement\.com\.cn
-stone-ebay\.com
-zgxbzlw\.com
-farfly\.com
-e-bjmelody\.cn
-adsmc\.com
-yhht-valve\.com
-qmtyblphlilu\.com
-qewojlupomxg\.com
-zoqecyrqdfhc\.com
-jbhazglyuzml\.com
-bodt\.com\.cnn
-bodt\.com\.cn
-onebedroomfurniture\.com
-69bm\.com
-69bm\.net
-cp788\.com
-1k888\.com
-libfondo\.info
-nimerino\.info
-minutospa\.info
-ihtibel\.info
-akmandel\.info
-168xh\.net
-posui\.net\.cn
-szgwjy\.com
-tcl\.com
-johnsonip\.cn
-szwanyang\.com
-lfhcn\.com
-89bm\.com
-caishen\d*\.cn
-hcplasticmold\.com
-ViewMyLoan\.com
-hotwetred\.info
-uniwuros\.com
-cbyanrbp\.com
-vmwtynhs\.com
-odosuz\.cn
-idakoxic\.cn
-ifom\.info
-omiducer\.cn
-isekecec\.cn
-hzylin\.cn
-vaqyjcqu\.com
-nvzisslp\.com
-jxzgdglq\.com
-wetwetwett\.info
-nudevidz\.info
-nunde4free\.info
-668w\.com
-fregalz\.info
-hothothott\.info
-163\.(com|net)
-ifux\.info
-jzups\.com\.cn
-longre\.com
-wecomesh\.com
-cjh120\.com
-cctv8168\.com
-meter17\.cn
-quntuo\.com
-bjjinshan\.com
-cccstandard\.com
-szlrwl\.cn
-deqinfy\.net
-ebakvqsq\.com
-adklnaum\.com
-gohzmgek\.com
-hypoq\.(org|info)
-cerbaq\.info
-vertyn\.info
-bjyyct\.com
-blt\.net\.cn
-qemlcnwg\.com
-hudwzsfh\.com
-ppyecsia\.com
-impactcrusher\.net\.cn
-hammercrushers\.com
-benconq\.com
-jawcrusher\.net\.cn
-raymondmill\.cn
-zenithcrusher\.com
-cnzenith\.com
-conecrushers\.com\.cn
-impactcrusher\.net\.cn
-beconq\.com
-benconq\.com
-crusher-cn\.com
-zenithcrusher\.com
-lemmings.dontexist\.com
-bjjjjgd\.cn
-mingshengximqm\.com
-shangguanhong\.(com|net)
-zooxtreme\.(com|net|org)
-beastplace\.(com|net|org)
-beastzone\.(com|net|org)
-beast-space\.(com|net|org)
-3vindia\.info
-2kool4u\.net
-22web\.net
-isgreat\.org
-iblogger\.org
-talk4fun\.net
-prophp\.org
-totalh\.com
-xanga\.com
-stonecrusher\.net\.cn
-vone\.net\.cn
-aggregate-plant\.com
-grindingmill\.cn
-huili-cn\.com
-globalchineseedu\.com
-zgxbzlw\.com
-wahlee\.net
-lilyspring\.com
-wetlesbiansx\.com
-wetindians\.net
-sex4uonly\.net
-jxpump\.com
-bfjxkf\.com
-zzdehong\.com
-wet-n-hairy\.net
-pinkshaved\.net
-sweetttits\.com
-jxpump\.com
-uextkhveawym\.com
-ghzbstszrpgo\.com
-qsevvccxnzlb\.com
-ahxxugvpswym\.com
-cce-china\.cn
-cd8545\.com
-travelnursingdirect\.com
-cone-crusher\.org
-chinadrtv\.com
-jsd-coffee\.com
-flolon\.com
-sc818\.com
-seo315\.(net|cn)
-pkseo\.cn
-nabirbsb\.com
-oqholfwb\.com
-wjoupiyw\.com
-yejuntech\.com
-ngvvlxpwuqhh\.com
-opggdydlpwsx\.com
-jrrwpwbungrk\.com
-lmkjshlsejlh\.com
-lovewind\.cn
-jormabridal\.com(\.cn)?
-paddletotheheadwaters\.com
-muzica-mp3\.ro
-movie2b\.com
-(stone|jaw|impact|cone|hammer)[-]*crusher\.(org|com|net|cn)
-pfkf999\.com
-hnpjs\.cn
-pysz\.com\.cn
-dxb\.ha\.cn
-ganbing120\.com\.cn
-forexcentre\.org
-igad\.info
-0516glass\.com
-liuhuaji\.com\.cn
-obsoletecomputermuseum\.org/forums/
-bonahr\.com\.cn
-stevepinto\.com
-touguanshi\.godele\.com
-bobauv\.com
-sangya\.com
-wanbaolong\.cc
-99k\.org
-clanteam\.com
-ztsousou\.com
-azresults\.com
-zxq\.net
-ckcf\.com\.cn
-wuhanbl\.com
-asp100\.cn
-xpcd\.net
-mygold123\.com
-onlinegoldsale\.com
-rhftsb\.com
-yfyc\.cn
-cz-wanjia\.com
-freewebtown\.com
-mix\.org\.cn
-cnlxj\.cn
-56817\.net
-99shijia\.com
-hailianlitong\.com
-zggcw\.net
-bj-hongyun\.com
-chushiji2008\.com
-symlhb\.com
-hndfzx\.(com|cn)
-vpn123\.com
-autovote\.cn
-warnlaser\.com
-google8\.com\.cn
-dlong\.com\.cn
-chinasolutionco\.com
-dy-bb\.com
-daiyun315\.cn
-bj-jbh\.com
-lunwen22\.com
-lun-wen\.com\.cn
-lunwenff\.com
-comegames\.com
-nicewow\.com
-ixtm\.net
-alexasir\.com
-itxb\.net
-seo315\.cn
-hnfbqz\.[xc]n
-oofay\.com
-igset\.com
-eqset\.com
-beijing-trip\.net
-czdipan\.cn
-5-happy\.cn
-sc98\.cn
-keeprun\.com
-hydehr\.com
-jiuyew\.com
-thedentalassistantonline\.com
-lhosting\.info
-allyouneed\.pl
-szlrkj\.com
-idating\.cn
-runescape\.com
-runescape2\.cc
-xneo\.org
-feilin\.ha\.cn
-banj315\.cn
-sdii\.com\.cn
-zzssjx\.com
-ganfushui\.cn
-okfish\.com\.cn
-cddvdvcd\.com
-utbwjawnvdtj\.com
-iyvjvdvpwali\.com
-dfsuyhhwpanb\.com
-iurvgecemloj\.com
-csusa\.org\.au
-nofeehost\.com
-auxt\.info
-italia113\.info
-favorgame\.net
-italaska\.info
-italyhomes\.info
-italiaconsulting\.info
-italypasta\.info
-gyhongwei\.com
-gystjx\.com
-hnydzg\.cn
-e-rhonealpes\.net
-italyresorts\.info
-madeitaly\.info
-workinitaly\.info
-offkey\.info
-digitalnod\.info
-fst-lab\.com
-xilu\.com
-0571ax\.com
-orkeor\.cn
-accurian\.cn
-beon\.ru
-lokerpoker\.com
-imeem\.com
-mycool\.com
-joetheisendds\.com
-digiadv\.co\.jp
-asianjazz\.ciao\.jp
-jkw\.name
-aaaoe\.com
-bjsfyj\.com
-cxlsx\.com
-ming-qing\.com
-gb-kontakt\.net
-gbkontakt\.info
-phpbb4you\.com
-fdtech\.biz
-hostofhosting\.com
-chinaliangzhu\.com
-suntop-fence\.com
-aaqtq\.cn
-hmxlzx\.cn
-ctexm\.com
-mc-subway\.cn
-netberg\.cn
-cannabin\.cn
-mcparking\.cn
-ezysearch\.cn
-mcfreestyle\.cn
-taobao\.com
-tangoing\.info
-ceroline\.info
-zhaoad\.cn
-nanhuachem\.com
-hhpumps*\.(com|cn|net|org)
-wowgold\.hk
-wowgoldvip\.com
-wowgold-sale\.com
-mmogcart\.com
-mygamesale\.com
-powerlevelings\.com
-power-levels\.com
-game-level\.com
-tongdeli\.com
-smt16\.cn
-hnkehai\.com
-gyfzjx\.com
-zzyl\.(com|cn)
-floopityjoop\.com
-tits\.cn
-eduoduo\.com\.cn
-hymarkets\.com
-cango\.com\.cn
-videolucho\.com
-baidu\.com
-9fag\.cn
-9nsk\.cn
-9skf\.cn
-cnnsk\.cn
-fagchina\.cn
-fagweb\.cn
-nsk022\.cn
-nskcn\.com
-nskweb\.cn
-skf022\.cn
-skfweb\.cn
-tjnrzc\.cn
-zcskf\.cn
-zhouchengskf\.cn
-eileenmcgann\.net
-abra[0-9]\.com
-lunwendx\.com
-ghlxj\.com
-hyinvestment\.com
-clife365\.com
-szh168\.cn
-rose-wedding\.cn
-jhstbj\.(com|cn)
-wybb999\.com
-francebfl\.com
-cmpack\.cn
-dabaog\.cn
-hnccqz\.cn
-ultra-gear\.com
-cnzycp\.cn
-hnzxzx\.cn
-cnpjs\.cn
-changw\.com
-t-bond\.com\.cn
-zjghtbf\.cn
-08kaoyan\.net
-netbai\.com
-ontsibvwjyhr\.com
-cevdvcpeomet\.com
-iahucbhvcqbg\.com
-dammagoxpvwx\.com
-tjzdxf\.cn
-shanghairuth\.com
-gupiao258\.(com|cn)
-snownes\.com
-bjbcl\.com
-korack\.cn
-cebiz\.cn
-anesd\.cn
-dianhualy\.com
-digseo\.net
-hzw1\.com
-kpwyxl\.com
-zjyihe\.com
-malatown\.com\.cn
-kmyuda\.com
-xowow\.com
-powerlevelingweb\.com
-1kan\.net\.cn
-howview\.cn
-bczl\.com\.cn
-fangshui99\.com
-bjxsbt\.com\.cn
-chuxinrui\.cn
-slfr\.net
-hyhxsm\.cn
-wang666\.cn
-shbingluo\.com
-keslon\.com
-hpsell\.com\.cn
-chenghechuangye\.cn
-bjyuantuo\.cn
-jnjinli\.com
-flower18\.com\.cn
-dianhualy\.com
-ifcmbj\.com
-xbjk120\.net
-howview\.cn
-egri\.net\.cn
-digseo\.net
-hzst\.net\.cn
-3movievideoclip\.com
-51yd\.com\.cn
-homesoft\.com\.cn
-bjzktd\.com
-dlpy\.cn
-hkfeng\.com
-zhengstar\.com
-99cars\.net
-szrona\.com
-keetouch\.com
-ipcam\.com\.cn
-ope888\.cn
-oktouch\.com
-1king\.com\.cn
-plancool\.com\.cn
-tianguangroups\.com
-beautynet\.cn
-housing-on-line\.com
-xinhai-pd\.com
-bjpbx\.com
-fozhe\.com
-cp2y\.com
-windhorsetour\.com
-buy-runescapegold\.com
-cchello\.com
-lookee\.in
-kotick\.in
-honi-moon\.in
-thsale\.com
-power4game\.com
-stk-interlining\.com
-wowgoldprice\.org
-ceskecelebrity\.com
-bvu\.com\.cn
-fsouber\.com
-allotec\.com
-p-pass\.com
-teamsun\.com\.cn
-pass4sure\.com
-pass4exam\.com
-exam4sure\.com
-certay\.com
-huochepiao168\.cn
-chinabestop\.com
-smartsgarment\.com
-pcqshoes\.com
-bestoplingerie\.com
-china-sexy-lingerie\.com
-fashion-emart\.com
-bestopsolar\.com
-info\.bizhostings\.net
-isk-eve\.com
-quickpass\.org
-shdzbc\.net\.cn
-xltcpl\.cn
-taiad\.com\.cn
-bjpeilian\.net
-wow-*gold.*\.(com|org|net|cn)
-sino-strong\.com\.cn
-vanguardct\.com
-hzzrs\.com
-hfcxhw\.com
-toeic-world\.com\.tw
-toefl-expert\.com\.tw
-gept4u\.com\.tw
-kingcoder\.com\.cn
-ning-wang-fu\.cn
-zzhkjx\.com
-exam100\.org
-76my\.com
-gamezmoney\.com
-86xh\.com
-ab222\.cn
-yn666\.com
-flowerordercentral\.cn
-geocities\.com/hentaioza
-www021\.com\.cn
-chinakaba\.com
-zdzdm\.sqnet\.cn
-szhostar\.com
-pulverizer\.com\.cn
-szyasen\.com
-xkzs\.cn
-tudou56\.com
-xcb120\.cn
-aab-co\.com
-jsps\.cn
-yuanchangsh\.cn
-fen-zi-shai\.cn
-jsqmfg\.cn
-valve-hm\.com
-hu-xi-qi\.cn
-surecan\.com\.cn
-wowpower-leveling\.com
-no1health\.org
-handbagroom\.com
-caxa\.com
-dinmo\.org\.cn
-underwear-wholesaler\.com
-17-china\.cn
-longhainet\.com
-quarry\-plant\.com\.cn
-rock\-crushers\.com\.cn
-brogame\.com
-pan-tibet\.com
-jxsb\.org\.cn
-fzpg\.net\.cn
-xxyd\.org\.cn
-fzfz\.org\.cn
-jmzj999\.com
-xbkf120\.cn
-inaturaldiet\.com
-osthair\.com
-yqyb\.org\.cn
-jjyp\.net\.cn
-lpsp\.net\.cn
-yybj\.net\.cn
-txcp\.net\.cn
-hrdzf\.com
-17ftp\.cn
-ibuy-sell\.com
-itemrate\.com
-mul-t-lock\.com\.cn
-kevincostnerfans\.com
-lavigneavril\.net
-loveparishilton\.net
-lovebritneyspears\.net
-alpacino\.net\.cn
-bradpitt\.net\.cn
-robertdeniro\.net\.cn
-gosuperplayers\.com
-item4sale\.com
-hitop-mould\.com
-dghighcrown\.com
-junxingstone\.com
-adholes\.net
-bibliotecaitata\.com
-chapso\.de
-teamagazine\.com\.hk
-blogbox\.dk
-tunesonic\.com
-blogpager\.com
-casa-lavoro\.net
-chicodeguzman\.net
-designblog\.gr
-hartenergy\.com
-isdev\.odg\.cc
-jshyx1985
-mode2testsite\.com
-mosentenem\.com
-myadulthosting\.net
-nosdivertimos\.com
-seniorsspace\.com
-megasexblog\.com
-blogsdevenezuela\.com
-islablog\.com
-go-cms\.info
-sportsfanstv\.com
-worldswatches\.com
-myblog\.g89\.org
-evsblogs\.com
-blogs\.omanana\.net
-gayteenresources\.org
-blog\.medigo\.pl
-blog\.thai-z\.com
-3xblog\.ro
-jumpblog\.com
-blogs\.slis\.ua\.edu
-zteo\.com
-propertyblogging\.com
-tangotogether\.com
-my\.vipublog\.com
-htchx\.us
-horizonacademyblog\.com
-emeraldnova\.com
-monsterblogs\.net
-losblogs\.net
-blog\.cybercc\.sg
-mormonorgs\.com
-drumblogs\.com
-jshyx2003
-kxy\.cn
-free-download-firefox\.net
-byzxw\.com
-1573\.hk
-tiffanyin\.com
-all4kid\.com
-deppjohnny\.com
-monicabelluccifans\.com
-gamesmd\.com
-implantjapan\.com
-i-denki\.net
-lasik-hikaku\.jp
-naturalk\.jp
-babyrockets\.com
-ocn\.ne\.jp
-w-medicalnet\.com
-sky361\.com
-powerleveling123\.com
-greentec-sound\.com\.cn
-runescapegoldvip\.com
-grasoftseo\.com
-mygamestock\.com
-rsgold-rsgold\.com
-kidmannicole\.com
-googlesoftware\.net
-accountsbay\.com
-fangdaomen\.cc
-hbjinggong\.cn
-mj-net\.jp
-marucollet\.jp
-cashing-view\.com
-century-21\.co\.jp
-dzbc\.org
-baojianwang\.com
-zhangsaohan\.cn
-huoyingrengzhe\.cn
-ouzou\.com\.cn
-trustyelectronic-china\.com
-china01\.cn
-goldcheapest\.com
-itemchannel\.com
-cn-chong\.com
-bjjhj\.com
-2artgallery\.com
-gdqingtian\.com
-tiffanyline\.com
-ggfou\.com
-jxmc\.com\.cn
-donba\.com
-oilpainting109\.com
-cnmolecular-sieve\.com
-bodahg\.com
-5eba\.com
-51zzw\.cn
-thecommercejournal\.com
-da-zhong-ban-chang\.com
-gl-firmenadressen\.(info|net)
-nyzhyq\.com
-veryge\.com
-fm965\.cn
-goleveling\.com
-cnwfyy\.com
-biaori\.com
-hangzhouhunqing\.com
-kwyf\.com\.cn
-g2gmart\.com
-baihelai\.com
-freetestking\.org
-sup-lotro-gold\.com
-warcus\.com
-mini-freegames\.com
-zalasoft\.com
-hollyginger\.com
-sitgame\.com
-jdllj\.com
-shevip\.com\.cn
-bacobolo\.com
-world-womans\.com
-88gk\.cn
-imvub\.com
-gpkoo\.com
-s2789\.com
-yw17\.com
-rfyljx\.com\.cn
-pboy\.com\.cn
-fashioninchina\.net
-electroplating-equipment\.cn
-lxep\.com
-carpet-china\.com\.cn
-jixietg\.cn
-break-day\.com
-games8848\.com
-fesffonpourr\.com
-fmrxfqdmwlbl\.com
-hdwccaggguzm\.com
-pjpxjijenjam\.com
-rjvurgjybnjn\.com
-uynlhrrfljtb\.com
-xljdfoxuceuh\.com
-zdcoxwpzjmhn\.com
-hyperrealty\.com
-mamariano\.us
-www-clubseventeen\.com
-ig2t\.com
-iamgaolijun\.cn
-monternet\.com
-granitecountertops\.com\.cn
-kercap\.com
-cwb120\.com
-gravelline\.cn
-applesupport\.com\.cn
-fcsgame\.com
-just4gold\.com
-goodvk\.com
-selldofus-kamas\.cn
-seo-newline\.com\.cn
-hzhongtai\.cn
-ymiao\.cn
-runescape-items\.org
-gcadressen-db\.net
-bambwood\.com
-jt120\.org\.cn
-thelodger\.net
-osceolanaacp\.org
-chattababy\.com
-touslescommerces\.net
-thepoliticalwasteland\.com
-moshergallery\.com
-membrane-solutions\.com
-abmbzkdszdwj\.com
-fwmqvmirgxya\.com
-mcxnlhviuojw\.com
-ogeworld\.com
-db-adressen\.(info|net)
-bathroomremodeling\.buzznet\.com
-chanelhandbag\.blog\.hr
-chinausbflashdrives\.com
-xyenglish\.com
-xingbingchina\.com
-fuworld\.com
-bjhongda2008\.com
-nowaction\.net
-qmyyw\.com
-yuanqiaowenhua\.com
-bjjh2000\.com
-lawfirst\.com\.cn
-a-polo\.cn
-librich\.com
-kicksarea\.com
-hybenet\.net
-yuanqiaowenhua\.com
-buy-runescape-money-gold\.com
-mesothelioma-uk\.net
-adsclicking\.com
-eastcarpet\.com\.cn
-jdshiyanji\.cn
-pandaphone\.com
-runescape2-money\.org
-wcx88\.cn
-dvd1314\.com
-cenkx\.com
-cnblp\.cn
-davismicro\.com
-fanggead\.com
-karrylady\.cn
-macrown\.com\.cn
-mdcchj\.com\.cn
-newbst\.com
-shoes4days\.com
-yaojian\.com\.cn
-zj-xinhong\.com
-ccok11\.com
-elkf120\.cn
-quhong120\.com
-rfid789\.com
-szchuangjie\.com
-windowregulator\.net
-ydyxl\.com
-adressendb\.net
-gc-datenbanken\.info
-rzqncfvopsdi\.com
-hvnrueyuufhh\.com
-ocrrtustraht\.com
-gxfuiynpudtp\.com
-gprunescape2\.com
-gsyb.com\.cn
-hzsxjx\.cn
-jdaluminum\.com
-jshengfa\.com
-wx-fd\.com
-usfine\.com
-maplestoryer\.com
-gcdatenbanken\.(net|info)
-google\.com/notebook/public
-cnhld\.org
-xykavmjkiisc\.com
-stasppcbybco\.com
-lxkqozwybkue\.com
-jpxgbssdoait\.com
-cilanie\.com
-8bio\.com
-goodpolisher\.com
-watchepay\.com
-airprice\.com
-bonnych\.com
-watchec\.com
-ele-art\.com
-sqsensor\.com
-mabinogi-gold\.org
-rohan-gold\.org
-webprogress-seo\.com
-webprogress-de\.info
-brandtrading\.net
-notebook-batteries\.org
-supply-batteries\.co\.uk
-casininio\.com
-feiyun8\.cn
-pastemark\.com
-storeingame\.com
-ymcmotor\.com\.cn
-97sese-mm.cn
-97sese-xxoo\.cn
-97sese-xxoo\.com\.cn
-dancedressshop\.com
-famousbrandwatch\.com
-jiuqusese-mm\.cn
-jiuqusese-mm\.com\.cn
-rentiyishu9\.com\.cn
-replica031\.com
-thepowerlevel\.com
-bjktwx\.com
-ktwxbj\.com
-nikespaces\.com
-paris-hilton\.wikidot\.com
-cert-world\.com
-weebly\.com
-db-gcadressen\.info
-dbadressen\.com
-rezeptfrei-kaufen\.com
-armee\.roonk\.de
-easysixpack\.de
-agoodic\.com
-ugamegold\.com
-zglxjkw\.com
-ourdtv\.tv
-flowexpo\.com
-supakopi\.com
-ero-xxx-pimiw\.cn
-gloway\.de
-gamelee\.com
-gogoer\.com
-mmorpgtube\.com
-mygamegoods\.com
-player-kill\.com
-srogold\.com
-tbcgold\.com
-tibiacrystal\.com
-rsgold-accounts\.com
-sfs168\.cn
-sfsok\.com
-szsfs\.com
-vgoldzone\.com
-vgsgame\.com
-banchang160\.com
-banjia99\.com
-bjgs01\.cn
-diaoche160\.com
-tuoyun160\.com
-lvhang\.net
-oilpaintingscn\.com
-shbaojing\.com
-wansp\.cn
-yaliuya\.cn
-yayaliu\.cn
-csjqlts\.cn
-crltjqsplts\.cn
-luoliaosp\.cn
-qqmnsplts\.cn
-kaoyao\.net
-goldmine\.by\.ru
-tarkus01\.by\.ru
-newsmaestro
-7vee\.info
-shoeshome\.net
-desiresecrets\.com
-toyline\.net
-sexyfancy\.net
-pleasuretoys\.biz
-jsjgjt\.com
-cuvyr\.com
-air\.io
-ecotect\.com
-azedresearch\.org
-eklmnhost\.com
-il\.mahidol\.ac\.th
-nmxxkmzgonko\.com
-johnmoan1\.freehostia\.com
-warezboard\.seothaithai\.com
-mooselodgeproductions\.com
-tenormedia\.com
-forums\.sellyoursitefast\.com
-forum\.dreamaboutchina\.com
-nikonisti\.ro
-redeseducativaspade\.com
-quantulus\.com
-guineaonline\.com
-globalunitedsavings\.com
-lakechelanalumni\.net
-forum\.fasanga\.com
-edinburgh\.craigslist\.co\.uk
-blogcelular\.net
-i0799\.com
-reagentcafe\.com
-leronimo\.com
-forum\.a2actors\.com
-forum\.money2take\.tk
-commsedu\.co\.uk
-long1985.byethost3\.com
-pictures-point\.nl
-ojodelaplata\.vox\.com
-dragon-tech\.org
-kotsos3\.livepage\.gr
-lifemind\.com
-canvaco\.org
-nightdomination\.altervista\.org
-alhorea\.com
-pardaan\.com
-tinavmurray\.com
-blazn360\.com
-gol\.mainwebsite\.org
-com-health\.com
-genius-entertainment\.com
-lydiadeetz\.vox\.com
-pilipino\.com
-faceroll\.se
-dustie\.com
-edicolantenews\.com
-xbox360achievements\.org
-2dfighter\.com
-Girls-Next-Door
-elephantcarhire\.com
-rushessays?\.com
-bestessays?\.com
-bestdissertations?\.com
-cheappoolproducts\.com
-superiorpapers\.com
-bestessays\.ca
-mightystudents\.com
-term-paper-research\.com
-college-paper\.org
-kamin\.kilu\.de
-kaminscout24\.de
-poker-rooms-review\.org
-all-auto\.ro
-517dv\.com
-casino.?spielen\.biz
-ktmboard\.com
-seospec\.net
-sexocuritiba\.com\.br
-webdesign63\.de
-websearchplanet\.info
-blog\.bitcomet\.com
-dissertationlab\.com
-bestessayhelp\.com
-bookwormlab\.com
-hollandandbarrett\.com
-bestcheapautoinsurance\.com
-profischnell\.com
-getcreditrepairtips4u\.com
-maketodaypayday\.co\.uk
-usfirepits\.com
-cheapautoinsurancekentucky\.com
-automobile-insurance\.com
-carinsuranceonline-\d\d\.com
-4autoinsurancequote\.org
-essay-writer\.org
-essaywritingservices\.org
-iresearchpapers\.com
-domainname\.com\.au
-lifeinsurancequotes\.com\.au
-myfuneralinsurance\.com\.au
-giftbasketsplus\.com
-lifeinsurance\.net\.au
-online-poker-spielen\.biz
-lowinterestcreditcards\.com(\.au)?
-balancetransfercreditcards\.org
-dartsimaging\.com
-searchengineoptimi[zs](ing|ation)(world|australia)\.com(\.au)?
-webair\.com
-aext\.net
-njoyz\.com
-pokerenfrancais\.eu
-momswhothink\.com
-fortunebaby\.com
-blackpenguin\.net
-novatedleasedeals\.com\.au
-labradoodle-puppies-for-sale\.net
-allstartradingpins\.com
-lease-a-seo\.com
-offsidebet\.com
-ukppiclaims\.org
-learners\.in\.th
-orbitfm\.com
-thekoeniggroup\.com
-forexinsider\.co\.uk
-indiangoldrates\.com
-iwanttosellmydiamond\.net
-pacquiaomosley\.co\.cc
-hcg-injections\.org
-hcgdiet\.net
-communaute\.sstic\.org
-prlog\.org
-unlockiphone4\.com
-patioheater[sz]?\.com
-card-approvals\.co\.uk
-hamptonbayceilingfans\.net
-novolinespiele\.de
-novoline24\.eu
-diamondlinks\.net
-lol\.com
-mastersdissertation\.co\.uk
-mortgagecomparison\.com\.au
-i52\.photobucket\.com
-outdoorpropanefirepit\.net
-s3\.hubimg\.com
-antiquegasstoves\.info
-bohaute\.com
-ariplex\.com
-wroughtironpatiofurnituresale\.com
-payday-loans-online\.com\.au
-carinquotes\.com
-carinsurancecomparisonsites\.com
-2wheelmotors\.info
-thegrio\.com
-outdoorfountains\.com
-profi-fachuebersetzung\.de
-uebersetzung-deutsch-englisch\.com
-xn--bersetzungsbro-frankfurt-uscm\.de
-shindiristudio\.com
-emailmarketingsoftwares\.org
-signalsforex\.org
-smebs\.blog\.com
-sme\.in
-essayhelppros\.co\.uk
-headlicetreatmentworld\.com
-logodesignmaestro\.com
-customessayhelp\.com
-pffchat\.com
-book-of-ra-spielen\.com
-dissertation-help\.co\.uk
-termpapers-guide\.com
-logodesignconsultant\.com
-mmcashloans\.co\.uk
-mmpaydayloans\.co\.uk
-my\.apexfitness\.com
-mystore\.24hourfitness\.com
-mycaal\.com
-mmtaxlawyer\.com
-mmtaxrelief\.com
-mmtaxhelp\.com
-mmtaxdebt\.com
-mmtaxattorney\.com
-waterproofmp3\.info
-juegosgratis\.de
-motorcyclegames\.us
-angry-birds-online\.com
-snipsly\.com
-scotties\.co\.nz
-nzhirecartoday\.info
-videofishingknots\.com
-cheapaudiobooks\.org
-bernardtips\.com
-buyphone4withoutcontract\.com
-auto-ready\.com
-lacapila\.com
-hotelsinamsterdam-netherlands\.com
-refrigeration-repair-tips\.com
-pandoracharm-uk\.com
-swissking\.net
-watchonetreehill\.org
-www-e-bad-credit-credit-cards\.com
-surgerythailand\.com
-pandoracharmsuksale\.net
-thomassabostockists\.com
-braceletsuk\.com
-kanayorecommends\.com
-goosejakkedk\.com
-kontaktlinserna\.com
-prestigeweddinginvitations\.com
-sum-security\.com
-pandoraaustraliastockists\.com
-angrybirdshub\.com
-onlinepokered\.com
-downloadfullgamesfree\.net
-hotwirelesscoupons\.com
-purecigs\.com
-trivology\.com
-biocig\.ro
-promocoder\.ne
-linkyoursite\.net
-geekzu\.com
-perfectclaims\.co\.uk
-tagesgeldzinsen\.tv
-bluegravityhosting\.com
-mywikibiz\.com
-sell-junkcars\.com
-jaycomm\.com\.au
-jualvccmurah\.com
-fashionreplicabags\.asia
-purifiedlife\.com
-carinsurancecomparisonshelp\.com
-faresoldisuinternet\.com
-itshumour\.blogspot\.com
-thefunnyquotessayings\.com
-coachoutletny\.com
-community\.remedygames\.com
-forums\.immigration\.com
-forums\.toucharcade\.com
-forum\.bbpixel\.com
-juristischer-uebersetzer\.profis\.info
-uebersetzung-deutsch-englisch\.4kp\.de
-uebersetzer-englisch-niederlaendisch\.at\.cr
-simultandolmetscher\.9gb\.de
-sprachenfokus\.eo3\.de
-open-mic\.tv
-missoldppi\.co
-texturedroots\.com
-ofen-nrw\.de
-personalinjuryclaimsadvice\.com
-coffeemakersreviewed\.net
-isabelmarantnlsneakers\.com
-raspberryketonepurenow\.com
-priorityappliances\.net
-vitrier-rueil-malmaison\.fr
-primavakantie\.nl
-miss-link\.net
-kontopoulos\.net
-bhgalleries\.com
-repairpartstock\.com
-ashlagbaroch\.org
-
-## ===========================================================================================
-## Please keep this comment at the end. Please note:
-## MoinMoin >=1.6 has TextCHAs for spam prevention and they are currently very effective (no
-## spam any more since switching to 1.6). So if you still suffer from spam, consider updating.
-## ===========================================================================================
diff --git a/Benchmarking.mdwn b/Benchmarking.mdwn
new file mode 100644
index 0000000..fdf8c9a
--- /dev/null
+++ b/Benchmarking.mdwn
@@ -0,0 +1,121 @@
+
+
+## Blender
+
+The blender developers wrote a script for benchmarking their app.  Download [[benchmark.blend|http://peach.blender.org/wp-content/uploads/movies/benchmark.blend]].  Run blender with ` blender ~/benchmark.blend `, then press alt-P. 
+
+
+## Nexuiz
+
+
+[[!format txt """
+nexuiz-glx -benchmark demos/demo1 -nosound 2>&1 | egrep -e '[0-9]+ frames'
+"""]]
+Or, you can open the console by pressing '`' (or shift + escape) and enter: 
+[[!format txt """
+timedemo demos/demo1.dem
+"""]]
+Available demos: demo1-5, bench1, piece-o-cake. 
+
+If you want to run demos in a loop, run `nexuiz-glx -nosound` and enter in console: 
+[[!format txt """
+startdemos demos/demo1 demos/demo2
+demos
+"""]]
+
+## Xonotic
+
+
+[[!format txt """
+xonotic-glx -benchmark demos/the-big-keybench 2>&1 | egrep -e '[0-9]+ frames'
+"""]]
+
+## OpenArena
+
+anholt recorded a timedemo for use.  The developers may include a canonical timedemo in a future release. 
+
+Place [[anholt.cfg|http://people.freedesktop.org/~airlied/scratch/anholt.cfg]] in `~/.openarena/baseoa/` 
+
+Place  [[anholt.dm_68|anholt.dm_68]] in `~/.openarena/baseoa/demos` 
+
+Run openarena using: 
+[[!format txt """
+openarena +exec anholt 2>&1 | egrep -e '[0-9]+ frames'
+"""]]
+
+## Quake3 Demo
+
+Install Quake 3 Demo 
+[[!format txt """
+wget ftp://ftp.idsoftware.com/idstuff/quake3/linux/linuxq3ademo-1.11-6.x86.gz.sh
+chmod a+x linuxq3ademo-1.11-6.x86.gz.sh
+./linuxq3ademo-1.11-6.x86.gz.sh -target ~/q3
+cd ~/q3
+cp bin/x86/glibc-2.0/q3demo .
+./q3demo
+"""]]
+The timedemo we use is DEMO001.  Place the following script in `~/.q3a/demoq3/demo.cfg` 
+[[!format txt """
+timedemo 1
+set demodone  "quit"
+set demoloop1 "demo DEMO001; set nextdemo vstr demodone"
+vstr demoloop1
+"""]]
+Run Quake3 Demo using: 
+[[!format txt """
+cd /q3 && ./q3demo +exec demo 2>&1 | egrep -e '[0-9]+ frames'
+"""]]
+
+## Quake3
+
+The timedemo we use is demofour.  Place the following script in `~/.q3a/baseq3/demofour.cfg`: 
+[[!format txt """
+timedemo 1
+set demodone  "quit"
+set demoloop1 "demo four; set nextdemo vstr demodone"
+vstr demoloop1
+"""]]
+Run quake3 using: 
+[[!format txt """
+cd /usr/games/quake3 && ./quake3.x86 +exec demofour 2>&1 | egrep -e '[0-9]+ frames'
+"""]]
+
+## Enemy Territory
+
+The timedemo we use is "Radar", located at [[http://www.3dcenter.org/downloads/enemy-territory-radar.php|http://www.3dcenter.org/downloads/enemy-territory-radar.php]].   Place the demo in `~/.etwolf/etmain/demos`. 
+
+Place the following script in `~/.etwolf/etmain/radar.cfg` 
+[[!format txt """
+timedemo 1
+set demodone  "quit"
+set demoloop1 "demo radar; set nextdemo vstr demodone"
+vstr demoloop1
+"""]]
+Run et using: 
+[[!format txt """
+et +exec radar 2>&1 | egrep -e '[0-9]+ frames'
+"""]]
+To show fps at runtime, hit '~' and type: 
+[[!format txt """
+/cg_drawfps 1
+"""]]
+
+## Doom3 (not the demo)
+
+Go to the console and type 
+[[!format txt """
+timedemo demo001 usecache
+"""]]
+
+## UT2004
+
+Set [[MinDesiredFramerate|MinDesiredFramerate]] to 0 in your UT2004.ini in `~/.ut2004/System/UT2004.ini`.  You probably also want to set `UseVBO=True` if your driver supports VBOs (UT doesn't automatically set this if the extension is exposed, for some reason). 
+
+Then, start a benchmark botmatch with: 
+[[!format txt """
+ut2004 "br-bridgeoffate?spectatoronly=1?numbots=8?quickstart=1?attractcam=1" -benchmark -seconds=60 -nosound
+"""]]
+The framerate is appended to `~/.ut2004/Benchmark/benchmark.log`: 
+[[!format txt """
+tail -n 1 ~/.ut2004/Benchmark/benchmark.log | awk '{print $5}'
+"""]]
+\ No newline at end of file
diff --git a/Benchmarking.moin b/Benchmarking.moin
deleted file mode 100644
index 4e640dc..0000000
--- a/Benchmarking.moin
+++ /dev/null
@@ -1,117 +0,0 @@
-== Blender ==
-The blender developers wrote a script for benchmarking their app.  Download [[http://peach.blender.org/wp-content/uploads/movies/benchmark.blend|benchmark.blend]].  Run blender with
-{{{ blender ~/benchmark.blend }}}, then press alt-P.
-
-== Nexuiz ==
-{{{
-nexuiz-glx -benchmark demos/demo1 -nosound 2>&1 | egrep -e '[0-9]+ frames'
-}}}
-Or, you can open the console by pressing '`' (or shift + escape) and enter:
-{{{
-timedemo demos/demo1.dem
-}}}
-Available demos: demo1-5, bench1, piece-o-cake.
-
-If you want to run demos in a loop, run {{{nexuiz-glx -nosound}}} and enter in console:
-{{{
-startdemos demos/demo1 demos/demo2
-demos
-}}}
-
-== Xonotic ==
-{{{
-xonotic-glx -benchmark demos/the-big-keybench 2>&1 | egrep -e '[0-9]+ frames'
-}}}
-
-== OpenArena ==
-anholt recorded a timedemo for use.  The developers may include a canonical timedemo in a future release.
-
-Place [[http://people.freedesktop.org/~airlied/scratch/anholt.cfg|anholt.cfg]] in {{{~/.openarena/baseoa/}}}
-
-Place  [[attachment:anholt.dm_68]] in {{{~/.openarena/baseoa/demos}}}
-
-
-
-Run openarena using:
-{{{
-openarena +exec anholt 2>&1 | egrep -e '[0-9]+ frames'
-}}}
-
-== Quake3 Demo ==
-Install Quake 3 Demo
-{{{
-wget ftp://ftp.idsoftware.com/idstuff/quake3/linux/linuxq3ademo-1.11-6.x86.gz.sh
-chmod a+x linuxq3ademo-1.11-6.x86.gz.sh
-./linuxq3ademo-1.11-6.x86.gz.sh -target ~/q3
-cd ~/q3
-cp bin/x86/glibc-2.0/q3demo .
-./q3demo
-}}}
-
-The timedemo we use is DEMO001.  Place the following script in {{{~/.q3a/demoq3/demo.cfg}}}
-{{{
-timedemo 1
-set demodone  "quit"
-set demoloop1 "demo DEMO001; set nextdemo vstr demodone"
-vstr demoloop1
-}}}
-
-Run Quake3 Demo using:
-{{{
-cd /q3 && ./q3demo +exec demo 2>&1 | egrep -e '[0-9]+ frames'
-}}}
-
-== Quake3 ==
-The timedemo we use is demofour.  Place the following script in {{{~/.q3a/baseq3/demofour.cfg}}}:
-{{{
-timedemo 1
-set demodone  "quit"
-set demoloop1 "demo four; set nextdemo vstr demodone"
-vstr demoloop1
-}}}
-
-Run quake3 using:
-{{{
-cd /usr/games/quake3 && ./quake3.x86 +exec demofour 2>&1 | egrep -e '[0-9]+ frames'
-}}}
-
-== Enemy Territory ==
-
-The timedemo we use is "Radar", located at [[http://www.3dcenter.org/downloads/enemy-territory-radar.php]].   Place the demo in {{{~/.etwolf/etmain/demos}}}.
-
-Place the following script in {{{~/.etwolf/etmain/radar.cfg}}}
-{{{
-timedemo 1
-set demodone  "quit"
-set demoloop1 "demo radar; set nextdemo vstr demodone"
-vstr demoloop1
-}}}
-
-Run et using:
-{{{
-et +exec radar 2>&1 | egrep -e '[0-9]+ frames'
-}}}
-
-To show fps at runtime, hit '~' and type:
-{{{
-/cg_drawfps 1
-}}}
-
-== Doom3 (not the demo) ==
-Go to the console and type
-{{{
-timedemo demo001 usecache
-}}}
-
-== UT2004 ==
-Set MinDesiredFramerate to 0 in your UT2004.ini in {{{~/.ut2004/System/UT2004.ini}}}.  You probably also want to set {{{UseVBO=True}}} if your driver supports VBOs (UT doesn't automatically set this if the extension is exposed, for some reason).
-
-Then, start a benchmark botmatch with:
-{{{
-ut2004 "br-bridgeoffate?spectatoronly=1?numbots=8?quickstart=1?attractcam=1" -benchmark -seconds=60 -nosound
-}}}
-
-The framerate is appended to {{{~/.ut2004/Benchmark/benchmark.log}}}:
-{{{
-tail -n 1 ~/.ut2004/Benchmark/benchmark.log | awk '{print $5}'
-}}}
diff --git a/BinaryCompatability.mdwn b/BinaryCompatability.mdwn
new file mode 100644
index 0000000..25c4dcf
--- /dev/null
+++ b/BinaryCompatability.mdwn
@@ -0,0 +1,108 @@
+
+
+## Binary compatibility
+
+This section is about the binary compatibility within the several parts that make a DRI driver.  
+
+
+### What does binary compatibility means?
+
+It means that that driver binaries made on previous releases should work with newer versions. 
+
+
+### Why is it so important?
+
+To avoid potential havoc. For example: 
+
+   * If a user installs that latest version of XFree86 -- they don't always know they need a new kernel module too -- and end up running with the older ones. 
+   * A vendor has intellectual property they don't want to release. Binary only components can be released, but they will need to support many different flavors of release. 
+   * To support driver suite binary releases created by DRI development team. 
+
+### Binary compatibility in practice.
+
+Proper use of individual versioning components is important. The version number is comprised of three fields separated by dots ".". The first field is the major number, the second the minor number and the third is the patch level. 
+
+Generally, the service provider sets the version number, and the initial revision is 1.0.0. 
+
+The service user checks the versioning with logic like: 
+
+   * [[!format txt """
+if (major_number != major_expected || minor_number < minor_expected) {
+        Report Incompatibility
+        Return Failure
+}
+"""]]
+If the interface between service provider and service user does not change, then the patch level is the only number that needs to be incremented in order to reflect internal bug fixes and/or updates. 
+
+When interface changes are made, care should be taken to preserve the ability for the new service provider to still work with older service users. Incrementing the minor revision number will account for this type of interface change. This is the backwards compatibility the we must strive for. 
+
+In the event compatibility must be destroyed, incrementing the major version number will be required. This option is highly discouraged. 
+
+The following sections outline a list of service providers, and which components utilize these sections. 
+
+
+#### Of the Device Specific Kernel DRM Driver...
+
+We have to maintain one direction of compatibility in order to stay in the Linux kernel release. This can be accomplished by: 
+
+   * semantic change should create a new ioctl and leave support for the old semantics in the DRM module as well 
+   * bumping the minor revision number to give a mechanism to know if the new semantics were available 
+**Note:** Check for different versions and fail gracefully is not a viable scenario according to Linus. 
+
+**Note:** Even when we ignore this and break compatibility completely -- we have to use versioning properly or we don't even get warnings and disabling. We get **crashes**!!! 
+
+Versioning set by (service provider): 
+
+   * Kernel DRM Driver (`programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/<driver>.h`) 
+Versioning checked by (service user): 
+
+   * 2D Driver (`xc/programs/Xserver/hw/xfree86/drivers/<driver>/<driver>_dri.c`) 
+   * 3D Driver (`xc/lib/GL/mesa/src/drv/<driver>/<driver>_screen.c`) 
+
+#### In the SAREA...
+
+This is not a service provider by itself, rather it's a communication mechanism used by service providers. The versioning of the service provider should reflect any changes to the SAREA. Additions to the end would typically result in a backwards compatible minor number bump. Removal of fields would result in an incompatible major number bump, and are highly discouraged. 
+
+
+#### Of the 2D Driver...
+
+These are less likely to get out of sync as the DRM module -- but it's still possible. Again, having good revision checking can save a lot of headaches later. If the versioning isn't accounted for we get hangs and crashes with mismatches. 
+
+We need to account for older versions, but not necessarily fully support -- we could fail gracefully --, although a driver suite supporter could decide to support older versions of one module or the other -- at their options. For example, let's say a hardware vendor released a binary DDX module for a special video out mode, then it would be nice if the 3D open source component worked with that module for as many versions as the initial interface allowed. So, even though we did many updates and releases, the old closed-source binary still worked. 
+
+Versioning set by (service provider): 
+
+   * 2D Driver (`programs/Xserver/hw/xfree86/drivers/<driver>/<driver>_dri.c`) 
+Versioning checked by: 
+
+   * 3D Driver (`lib/GL/mesa/src/drv/<driver>/<driver>_screen.c`) 
+
+#### Of the Device Independent DRM Library...
+
+Unlike the individual device dependent components in the kernel, this versioning reflects the overall DRM Library API supported by the `libdrm.a` component. A few device extensions were added to this API, and have since been converted to use the generic _drmCommand_ mechanism. All new extensions should exclusively use drmCommand. The older existing device extensions are still available strictly for backwards compatibility. 
+
+The 3D Driver does not check this because this module is staticly linked, and consequently is always the matching version. 
+
+Versioning set by (service provider): 
+
+   * DRM Library (`programs/Xserver/hw/xfree86/os-support/<os>/drm/xf86drm.c`) 
+Versioning checked by: 
+
+   * 2D Driver (`programs/Xserver/hw/xfree86/drivers/<driver>/<driver>_dri.c`) 
+
+#### Of the DRI Server Extension...
+
+This reflects the version of the DRI X11 protocol extension. 
+
+Versioning set by (service provider): 
+
+   * DRI Extension Module (`programs/Xserver/GL/dri/dri.c`) 
+Versioning checked by: 
+
+   * 3D Driver (`lib/GL/mesa/src/drv/<driver>/<driver>_screen.c`) 
+
+#### Of the 3D Driver...
+
+The 3D driver is used by the libGL library. Versioning does not exist for this interface, yet. However, great care should be taken to not change the interface between the libGL library and the 3D drivers. 
+
+-- [[JensOwen|JensOwen]] 
diff --git a/BinaryCompatability.moin b/BinaryCompatability.moin
deleted file mode 100644
index 54562db..0000000
--- a/BinaryCompatability.moin
+++ /dev/null
@@ -1,147 +0,0 @@
-== Binary compatibility ==
-
-This section is about the binary compatibility within the several parts that make a DRI driver. 
-
-=== What does binary compatibility means? ===
-
-It means that that driver binaries made on previous releases should work with newer versions.
-
-=== Why is it so important? ===
-
-To avoid potential havoc. For example:
-
-  * If a user installs that latest version of XFree86 -- they don't always know they need a new kernel module too -- and end up running with the older ones.
-
-  * A vendor has intellectual property they don't want to release. Binary only components can be released, but they will need to support many different flavors of release.
-
-  * To support driver suite binary releases created by DRI development team.
-
-=== Binary compatibility in practice. ===
-
-Proper use of individual versioning components is important. The version number
-is comprised of three fields separated by dots ".". The first field is the
-major number, the second the minor number and the third is the patch level.
-
-Generally, the service provider sets the version number, and the initial
-revision is 1.0.0.
-
-The service user checks the versioning with logic like:
-
-  {{{
-if (major_number != major_expected || minor_number < minor_expected) {
-	Report Incompatibility
-	Return Failure
-}
-}}}
-
-If the interface between service provider and service user does not change,
-then the patch level is the only number that needs to be incremented in order
-to reflect internal bug fixes and/or updates.
-
-When interface changes are made, care should be taken to preserve the ability
-for the new service provider to still work with older service users.
-Incrementing the minor revision number will account for this type of interface
-change. This is the backwards compatibility the we must strive for.
-
-In the event compatibility must be destroyed, incrementing the major version
-number will be required. This option is highly discouraged.
-
-The following sections outline a list of service providers, and which
-components utilize these sections.
-
-==== Of the Device Specific Kernel DRM Driver... ====
-
-We have to maintain one direction of compatibility in order to stay in the
-Linux kernel release. This can be accomplished by:
-
-  * semantic change should create a new ioctl and leave support for the old semantics in the DRM module as well
-
-  * bumping the minor revision number to give a mechanism to know if the new semantics were available
-
-'''Note:''' Check for different versions and fail gracefully is not a viable scenario according to Linus.
-
-'''Note:''' Even when we ignore this and break compatibility completely -- we
-have to use versioning properly or we don't even get warnings and disabling. We
-get '''crashes'''!!!
-
-Versioning set by (service provider):
-
-  * Kernel DRM Driver (`programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/<driver>.h`)
-
-Versioning checked by (service user):
-
-  * 2D Driver (`xc/programs/Xserver/hw/xfree86/drivers/<driver>/<driver>_dri.c`)
-
-  * 3D Driver (`xc/lib/GL/mesa/src/drv/<driver>/<driver>_screen.c`)
-
-==== In the SAREA... ====
-
-This is not a service provider by itself, rather it's a communication mechanism
-used by service providers. The versioning of the service provider should
-reflect any changes to the SAREA. Additions to the end would typically result
-in a backwards compatible minor number bump. Removal of fields would result in
-an incompatible major number bump, and are highly discouraged.
-
-==== Of the 2D Driver... ====
-
-These are less likely to get out of sync as the DRM module -- but it's still
-possible. Again, having good revision checking can save a lot of headaches
-later. If the versioning isn't accounted for we get hangs and crashes with
-mismatches.
-
-We need to account for older versions, but not necessarily fully support -- we
-could fail gracefully --, although a driver suite supporter could decide to
-support older versions of one module or the other -- at their options. For
-example, let's say a hardware vendor released a binary DDX module for a special
-video out mode, then it would be nice if the 3D open source component worked
-with that module for as many versions as the initial interface allowed. So,
-even though we did many updates and releases, the old closed-source binary
-still worked.
-
-Versioning set by (service provider):
-
-  * 2D Driver (`programs/Xserver/hw/xfree86/drivers/<driver>/<driver>_dri.c`)
-
-Versioning checked by:
-
-  * 3D Driver (`lib/GL/mesa/src/drv/<driver>/<driver>_screen.c`)
-
-==== Of the Device Independent DRM Library... ====
-
-Unlike the individual device dependent components in the kernel, this
-versioning reflects the overall DRM Library API supported by the `libdrm.a`
-component. A few device extensions were added to this API, and have since been
-converted to use the generic ''drmCommand'' mechanism. All new extensions should
-exclusively use drmCommand. The older existing device extensions are still
-available strictly for backwards compatibility.
-
-The 3D Driver does not check this because this module is staticly linked, and
-consequently is always the matching version.
-
-Versioning set by (service provider):
-
-  * DRM Library (`programs/Xserver/hw/xfree86/os-support/<os>/drm/xf86drm.c`)
-
-Versioning checked by:
-
-  * 2D Driver (`programs/Xserver/hw/xfree86/drivers/<driver>/<driver>_dri.c`)
-
-==== Of the DRI Server Extension... ====
-
-This reflects the version of the DRI X11 protocol extension.
-
-Versioning set by (service provider):
-
-  * DRI Extension Module (`programs/Xserver/GL/dri/dri.c`)
-
-Versioning checked by:
-
-  * 3D Driver (`lib/GL/mesa/src/drv/<driver>/<driver>_screen.c`)
-
-==== Of the 3D Driver... ====
-
-The 3D driver is used by the libGL library. Versioning does not exist
-for this interface, yet. However, great care should be taken to not change the
-interface between the libGL library and the 3D drivers.
-
--- JensOwen
diff --git a/BrianPaul.mdwn b/BrianPaul.mdwn
new file mode 100644
index 0000000..13e30d4
--- /dev/null
+++ b/BrianPaul.mdwn
@@ -0,0 +1,19 @@
+
+
+## Brian Paul
+
+[[!img http://www.tungstengraphics.com/photos/brian.jpg] 
+Email
+: brianp at tungstengraphics dot com 
+
+Interests
+: 
+      * Mesa 
+      * Chromium 
+
+
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/BrianPaul.moin b/BrianPaul.moin
deleted file mode 100644
index 87f8a7e..0000000
--- a/BrianPaul.moin
+++ /dev/null
@@ -1,12 +0,0 @@
-== Brian Paul ==
-
-{{http://www.tungstengraphics.com/photos/brian.jpg}}
-
- Email:: brianp at tungstengraphics dot com
-
- Interests::
-   * Mesa
-   * Chromium
-
-----
-CategoryHomepage
diff --git a/BugZilla.mdwn b/BugZilla.mdwn
new file mode 100644
index 0000000..38dd7e6
--- /dev/null
+++ b/BugZilla.mdwn
@@ -0,0 +1,6 @@
+
+BugZilla is a commonly used bug report management system. 
+
+DRI and Mesa bugs should be submitted at [[freedesktop.org's Bugzilla|http://bugs.freedesktop.org/]].  Bug reports submitted in this fashion will be automatically forwarded to the dri-devel mailing list.  Please submit all new bugs here. 
+
+There are also older bug databases for DRI at [[xfree86.org|http://bugs.xfree86.org/]] and [[sourceforge.net|http://sourceforge.net/tracker/?atid=100387&group_id=387&func=browse]], but these are deprecated, and should not be used for submitting new bugs. 
diff --git a/BugZilla.moin b/BugZilla.moin
deleted file mode 100644
index 89aee88..0000000
--- a/BugZilla.moin
+++ /dev/null
@@ -1,5 +0,0 @@
-BugZilla is a commonly used bug report management system.
-
-DRI and Mesa bugs should be submitted at [[http://bugs.freedesktop.org/|freedesktop.org's Bugzilla]].  Bug reports submitted in this fashion will be automatically forwarded to the dri-devel mailing list.  Please submit all new bugs here.
-
-There are also older bug databases for DRI at [[http://bugs.xfree86.org/|xfree86.org]] and [[http://sourceforge.net/tracker/?atid=100387&group_id=387&func=browse|sourceforge.net]], but these are deprecated, and should not be used for submitting new bugs.
diff --git a/Building.moin b/Building.mdwn
index f6f5ad6..7a1a58b 100644
--- a/Building.moin
+++ b/Building.mdwn
@@ -1,292 +1,286 @@
-#pragma section-numbers on
-
-'''Contents'''
-<<TableOfContents>>
-
-= Building the DRI with X.org and Mesa =
-
-This is a basic guide to building DRI from source.  This guide '''only''' covers building the client-side 3D drivers.  Since the transition to the modular X.org build, building an X-server and 2D drivers is beyond the scope of this document.  That information can be found in the [[http://wiki.x.org/wiki/ModularDevelopersGuide|X.org Modular Developer Guide]]. An important aspect is to compile X-server with the {{{--with-mesa-source=/path/to/mesa}}} option, to include glx/OpenGL support. You will most probably need to (re)compile also at least the keyboard and mouse drivers, in addition to a video card 2D driver.
-
-KDrive servers are not supported at this time.  Please report any problems with these instructions on the dri-users mailing list or on IRC.
-
-The 2D drivers with DRI support, server-side GLX support and the GL library capable of loading DRI 3D drivers are developed in X.org's CVS. The 3D drivers, though, live in the Mesa tree, so you will have to check out the Mesa git tree.  You should also get the DRM git tree for up-to-date kernel modules. The following instructions will guide you through the process step by step.
-
-'''Warning:''' In case you didn't notice, you are about to compile and install experimental software. This will allow you to test the latest features and bug fixes. It may, however, also introduce new bugs. Be prepared for problems every now and then.
-
-== Dependencies ==
-
-You need a current version (7.4, ie. xserver 1.5 as of this writing) of X.org (core and development packages) installed on your system. In particular, you need these X.org components:
-
- * proto/glproto [[http://xorg.freedesktop.org/releases/individual/proto/glproto-1.4.14.tar.bz2|1.4.14]] or `git://anongit.freedesktop.org/git/xorg/proto/glproto`
- * proto/xf86vidmodeproto `git://anongit.freedesktop.org/git/xorg/proto/xf86vidmodeproto`
- * lib/libXxf86vm `git://anongit.freedesktop.org/git/xorg/lib/libXxf86vm`
- * lib/libXmu `git://anongit.freedesktop.org/git/xorg/lib/libXmu`
- * dri2proto [[http://xorg.freedesktop.org/releases/individual/proto/dri2proto-2.6.tar.bz2|2.6]] or `git://anongit.freedesktop.org/xorg/proto/dri2proto`
-
-=== On Debian/Ubuntu ===
-
-If you are using Debian or Ubuntu you can install the packages with:
-
-{{{
-apt-get build-dep libdrm mesa
-apt-get install linux-headers-`uname -r`
-apt-get install libxi-dev libxmu-dev x11proto-xf86vidmode-dev
-apt-get install git-core autoconf automake libtool
-}}}
-
-== Getting the latest source trees ==
-
-Get the source trees using two `git` commands.  These commands should be run in the same directory.  When they've run, you will have two new subdirectories: `mesa`, and `drm`.
-
-=== Getting DRM and libdrm ===
-
-The clean DRM source tree takes about 4MB of disk space.
-
-{{{
-git clone git://anongit.freedesktop.org/git/mesa/drm
-}}}
-
-=== Getting Mesa ===
-
-The clean Mesa source tree takes about 32MB of disk space.
-
-{{{
-git clone git://anongit.freedesktop.org/git/mesa/mesa
-}}}
-
-== Building libdrm ==
-
-The Mesa drivers now require `libdrm` to be installed. Do the following to build `libdrm`:
-
-{{{
-cd drm
-./autogen.sh
-}}}
-
-'''Note:''' `libdrm` installs to `/usr/local/lib` by default.  To install in `/usr/lib` run:
-{{{
-./configure --prefix=/usr
-}}}
-
-Now you're ready to compile it:
-{{{
-make
-}}}
-
-Then as root, to install:
-{{{
-make install
-}}}
-
-== Building Mesa 3D drivers ==
-
-The DRI 3D drivers are now built from the Mesa source.
-
-{{{
-cd mesa
-./autogen.sh
-}}}
-
-'''Note:''' `mesa` installs to `/usr/local/lib` by default.  To install in `/usr/lib` run:
-{{{
-./configure --prefix=/usr
-}}}
-
-Choose the right configure options depending on the hardware architecture you're compiling for. <<BR>>
-See http://www.mesa3d.org/autoconf.html for more information about configuring mesa
-or read the output from:
-{{{
-./configure --help
-}}}
-
-'''Note:''' You will need to install `libdrm` for Mesa to build properly. You should have done that at step 1.3 when doing the "make install".
-
-'''Note:''' You will need to update PKG_CONFIG_PATH if you installed `libdrm` in `/usr/local/lib`. For example, `export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH`.
-
-Now you're ready to compile it:
-
-{{{
-make
-}}}
-
-== Installing the 3D drivers ==
-
-After compiling the Mesa tree, the 3D drivers can be found in `mesa/lib`. There are two ways of using them: installing them in the destined place, or telling X where to find them.
-
-1. Install the drivers to `/usr/lib/`:
-
-Run as root, to install:
-
-{{{
-make install
-}}}
-
-2. Or set the environment variable LIBGL_DRIVERS_PATH to point to `<path to Mesa>/lib`, and also preload the newly built `libGL.so`:
-
-{{{
-export LIBGL_DRIVERS_PATH=<path to Mesa>/lib
-export LD_PRELOAD=<path to Mesa>/lib/libGL.so.1
-}}}
-
-To make these settings persistent, you'll have to add them to `.bashrc` or a similar login script.
-
-== Building the DRM ==
-
-The DRM is shipped with the kernel on both Linux and FreeBSD, so you shouldn't have to build it explicitly. If you want to build it or develop it, the kernel building and development rules apply.
-
-== Finishing up ==
-
-There are two things you have to do if you compiled X.org for the first time and were using XFree86 before. There should be a symbolic link `/etc/X11/X` that points to `/usr/X11R6/bin/XFree86`. You should make that link point to `/usr/X11R6/bin/Xorg`.
-
-{{{
-cd /etc/X11
-mv X X.backup
-ln -s /usr/X11R6/bin/Xorg X
-}}}
-
-Copy your `XF86Config-4` or `XF86Config` to `xorg.conf`, and in this file change the keyboard driver from `keyboard` to `kbd`.
-
-{{{
-Section "Input"
-    # ...
-    Driver "kbd"
-    # ...
-EndSection
-}}}
-
-In order to activate 3D acceleration make sure your `xorg.conf` is set up right.
-In particular, make sure the GLX and DRI modules are being loaded:
-
-{{{
-Section "Module"
-    # ...
-    Load "glx"
-    Load "dri"
-    # ...
-EndSection
-}}}
-
-and set the permissions for DRI appropriately.  To allow anyone to use DRI, do:
-{{{
-Section "DRI"
-    Mode 0666
-EndSection
-}}}
-
-To restrict DRI access to a certain group, find on your system the name of the group that is for video hardware access. (Have a look in `/etc/group`. It is often called `video`.) Add the users that may access the video hardware to that group. Then put this into `xorg.conf`:
-{{{
-Section "DRI"
-    Group "video"
-    Mode 0660
-EndSection
-}}}
-
-On Linux 2.4.x make sure the agpgart kernel module is loaded before you start X.  On Linux 2.6.x make sure both agpgart and the agp chipset specific driver for your motherboard (via_agp, intel_agp, et al.) are loaded before you start X.  To make the agp modules load automatically add these lines to your `modules.conf`:
-
-2.4.x kernels:
-{{{
-pre-install <drm module> /sbin/modprobe "-k" "agpgart"
-}}}
-
-2.6.x kernels:
-{{{
-pre-install <drm module> /sbin/modprobe "-k" "agpgart"
-pre-install agpgart /sbin/modprobe "-k" "<agp chipset driver>"
-}}}
-
-Replace <drm module> with the name of the drm module for your video card (e.g., radeon, mga, savage, etc.).
-Replace <agp chipset driver> with the name of the agp driver for your motherboard (e.g., via_agp, intel_agp, etc.).
-
-For all kernels, make sure the DRM module is loaded before you start X.
-
-Remember to restart X so the server will use the new modules.
-
-
-= Troubleshooting =
-
-If your issue isn't covered here, please report it on `#dri` on IRC or on the dri-users mailing list.  This section only covers build-time troubleshooting; for run-time issues see DriTroubleshooting.
-
-== I cannot load my new DRM module on Linux Kernel 2.6.1 ==
-
-{{{
-FATAL: Error inserting via (/lib/modules/2.6.1/kernel/
-drivers/char/drm/<module name>.ko): Unknown symbol in module,
-or unknown parameter (see dmesg)
-}}}
-
-This error occurs because there are some missing symbols in the 2.6.1 kernel source. One way to get around this problem is to upgrade your kernel to a newer version... (You *might* be able to patch the DRM code to avoid this... Not sure about this, though!)
-
-
-== Can't find 'X11/Xlibint.h' ==
-
-You need to have the headers for your current X version installed.  How you install these depends on how you installed X in the first place:
-
- * If you downloaded a binary from xfree86.org, the headers are in {{{Xprog.tgz}}}.
-
- * For Slackware the package is called {{{xfree86-devel}}}.
-
- * Redhat/Fedora and SuSE users should install the appropriate {{{XFree86-devel}}} package.
-
- * Mandrake calls this package {{{libxfree86-devel}}} for some reason.
-
- * Debian users should use {{{xlibs-dev}}}.
-
- * Gentoo users only need to make sure `xfree` or `xorg-x11` have already been emerged.
-
-== Compilation fails when building the kernel modules ==
-
-When building the kernel modules, the compilation might fail for some modules. In a recent CVS snapshot, I got the following:
-
-{{{
-savage_drv.c: In function `savage_alloc_continuous_mem':
-savage_drv.c:106: warning: passing arg 1 of `remap_page_range_Rc414bdc2' makes pointer from integer without a cast
-savage_drv.c:106: incompatible type for argument 4 of `remap_page_range_Rc414bdc2'
-savage_drv.c:106: too few arguments to function `remap_page_range_Rc414bdc2'
-savage_drv.c: In function `savage_get_physics_address':
-savage_drv.c:170: warning: implicit declaration of function `pte_offset'
-savage_drv.c:170: warning: assignment makes pointer from integer without a cast
-make[2]: *** [savage_drv.o] Error 1
-}}}
-
-You can avoid this problem by only building the modules you need.  See the DRM section above for the bit about the `DRM_MODULES` variable.
-
-== xf86cfg doesn't compile/link ==
-
-xf86cfg requires libXaw (and appropriate headers) to be installed in order to build.  You can either install the relevant packages for your distribution, or else add the line:
-
-{{{
-#define BuildXFree86ConfigTools NO
-}}}
-
-to your `config/cf/host.def` and rerun `make World`.
-
-ToDo: fill this in with package names, as above.
-
-== I'm using Gentoo and... ==
-
-Gentoo has its own How-To on their website -- http://www.gentoo.org/doc/en/dri-howto.xml
-
-For those who enabled DRI via the instructions here...
-
-There is a known issue with Gentoo's Open``GL package switch; when the `opengl-update` package is installed, Gentoo places Open``GL libraries and header files under `/usr/lib/opengl` and uses symlinks to make everything appear in the normal place.  As a result the normal install process doesn't always work.
-
-Try setting up a "fake" Open``GL package, and switch into it:
-{{{
-cd /usr/lib/opengl
-mkdir mesa-cvs
-cd mesa-cvs
-ln -s ../../../local/lib
-ln -s ../../../local/include
-ln -s ../xorg-x11/extensions
-opengl-update mesa-cvs
-}}}
-This assumes you installed Mesa (including lib``GL) into `/usr/local`, which is the default. Also, you may like to remove everything in `/usr/local/lib` from Mesa that isn't either `libGL.*` or `libGLU.*` -- things like `libGLw.*` can cause problems.
-
-If you set things up differently, a way to check whether you are affected by `opengl-update` is to strace any Open``GL based program (for example: `glxgears`) and to see which `libGL.so` it loads. Despite all symlinks it should load `/usr/lib/libGL.so.1.2`. If it doesn't correct the symlinks in `/usr/lib` to point to `/usr/lib/libGL.so.1.2`. After that '''don't run `opengl-update`''' -- it will only break things.
-
-= References =
-
-- [[http://www.atomicmpc.com.au/forums.asp?s=2&c=16&t=1501|Guide by snakeoil]]
-
-- [[http://dri.sourceforge.net/doc/building.html|Old DRI building guide]]
-http://dri.sourceforge.net/cgi-bin/moin.cgi/RecentChanges
+
+**Contents** [[!toc ]] 
+
+
+# Building the DRI with X.org and Mesa
+
+This is a basic guide to building DRI from source.  This guide **only** covers building the client-side 3D drivers.  Since the transition to the modular X.org build, building an X-server and 2D drivers is beyond the scope of this document.  That information can be found in the [[X.org Modular Developer Guide|http://wiki.x.org/wiki/ModularDevelopersGuide]]. An important aspect is to compile X-server with the `--with-mesa-source=/path/to/mesa` option, to include glx/OpenGL support. You will most probably need to (re)compile also at least the keyboard and mouse drivers, in addition to a video card 2D driver. 
+
+KDrive servers are not supported at this time.  Please report any problems with these instructions on the dri-users mailing list or on IRC. 
+
+The 2D drivers with DRI support, server-side GLX support and the GL library capable of loading DRI 3D drivers are developed in X.org's CVS. The 3D drivers, though, live in the Mesa tree, so you will have to check out the Mesa git tree.  You should also get the DRM git tree for up-to-date kernel modules. The following instructions will guide you through the process step by step. 
+
+**Warning:** In case you didn't notice, you are about to compile and install experimental software. This will allow you to test the latest features and bug fixes. It may, however, also introduce new bugs. Be prepared for problems every now and then. 
+
+
+## Dependencies
+
+You need a current version (7.4, ie. xserver 1.5 as of this writing) of X.org (core and development packages) installed on your system. In particular, you need these X.org components: 
+
+* proto/glproto [[1.4.14|http://xorg.freedesktop.org/releases/individual/proto/glproto-1.4.14.tar.bz2]] or `git://anongit.freedesktop.org/git/xorg/proto/glproto` 
+* proto/xf86vidmodeproto `git://anongit.freedesktop.org/git/xorg/proto/xf86vidmodeproto` 
+* lib/libXxf86vm `git://anongit.freedesktop.org/git/xorg/lib/libXxf86vm` 
+* lib/libXmu `git://anongit.freedesktop.org/git/xorg/lib/libXmu` 
+* dri2proto [[2.6|http://xorg.freedesktop.org/releases/individual/proto/dri2proto-2.6.tar.bz2]] or `git://anongit.freedesktop.org/xorg/proto/dri2proto` 
+
+### On Debian/Ubuntu
+
+If you are using Debian or Ubuntu you can install the packages with: 
+
+
+[[!format txt """
+apt-get build-dep libdrm mesa
+apt-get install linux-headers-`uname -r`
+apt-get install libxi-dev libxmu-dev x11proto-xf86vidmode-dev
+apt-get install git-core autoconf automake libtool
+"""]]
+
+## Getting the latest source trees
+
+Get the source trees using two `git` commands.  These commands should be run in the same directory.  When they've run, you will have two new subdirectories: `mesa`, and `drm`. 
+
+
+### Getting DRM and libdrm
+
+The clean DRM source tree takes about 4MB of disk space. 
+
+
+[[!format txt """
+git clone git://anongit.freedesktop.org/git/mesa/drm
+"""]]
+
+### Getting Mesa
+
+The clean Mesa source tree takes about 32MB of disk space. 
+
+
+[[!format txt """
+git clone git://anongit.freedesktop.org/git/mesa/mesa
+"""]]
+
+## Building libdrm
+
+The Mesa drivers now require `libdrm` to be installed. Do the following to build `libdrm`: 
+
+
+[[!format txt """
+cd drm
+./autogen.sh
+"""]]
+**Note:** `libdrm` installs to `/usr/local/lib` by default.  To install in `/usr/lib` run: 
+[[!format txt """
+./configure --prefix=/usr
+"""]]
+Now you're ready to compile it: 
+[[!format txt """
+make
+"""]]
+Then as root, to install: 
+[[!format txt """
+make install
+"""]]
+
+## Building Mesa 3D drivers
+
+The DRI 3D drivers are now built from the Mesa source. 
+
+
+[[!format txt """
+cd mesa
+./autogen.sh
+"""]]
+**Note:** `mesa` installs to `/usr/local/lib` by default.  To install in `/usr/lib` run: 
+[[!format txt """
+./configure --prefix=/usr
+"""]]
+Choose the right configure options depending on the hardware architecture you're compiling for.   
+ See [[http://www.mesa3d.org/autoconf.html|http://www.mesa3d.org/autoconf.html]] for more information about configuring mesa or read the output from: 
+[[!format txt """
+./configure --help
+"""]]
+**Note:** You will need to install `libdrm` for Mesa to build properly. You should have done that at step 1.3 when doing the "make install". 
+
+**Note:** You will need to update PKG_CONFIG_PATH if you installed `libdrm` in `/usr/local/lib`. For example, `export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH`. 
+
+Now you're ready to compile it: 
+
+
+[[!format txt """
+make
+"""]]
+
+## Installing the 3D drivers
+
+After compiling the Mesa tree, the 3D drivers can be found in `mesa/lib`. There are two ways of using them: installing them in the destined place, or telling X where to find them. 
+
+1. Install the drivers to `/usr/lib/`: 
+
+Run as root, to install: 
+
+
+[[!format txt """
+make install
+"""]]
+2. Or set the environment variable LIBGL_DRIVERS_PATH to point to `<path to Mesa>/lib`, and also preload the newly built `libGL.so`: 
+
+
+[[!format txt """
+export LIBGL_DRIVERS_PATH=<path to Mesa>/lib
+export LD_PRELOAD=<path to Mesa>/lib/libGL.so.1
+"""]]
+To make these settings persistent, you'll have to add them to `.bashrc` or a similar login script. 
+
+
+## Building the DRM
+
+The DRM is shipped with the kernel on both Linux and FreeBSD, so you shouldn't have to build it explicitly. If you want to build it or develop it, the kernel building and development rules apply. 
+
+
+## Finishing up
+
+There are two things you have to do if you compiled X.org for the first time and were using XFree86 before. There should be a symbolic link `/etc/X11/X` that points to `/usr/X11R6/bin/XFree86`. You should make that link point to `/usr/X11R6/bin/Xorg`. 
+
+
+[[!format txt """
+cd /etc/X11
+mv X X.backup
+ln -s /usr/X11R6/bin/Xorg X
+"""]]
+Copy your `XF86Config-4` or `XF86Config` to `xorg.conf`, and in this file change the keyboard driver from `keyboard` to `kbd`. 
+
+
+[[!format txt """
+Section "Input"
+    # ...
+    Driver "kbd"
+    # ...
+EndSection
+"""]]
+In order to activate 3D acceleration make sure your `xorg.conf` is set up right. In particular, make sure the GLX and DRI modules are being loaded: 
+
+
+[[!format txt """
+Section "Module"
+    # ...
+    Load "glx"
+    Load "dri"
+    # ...
+EndSection
+"""]]
+and set the permissions for DRI appropriately.  To allow anyone to use DRI, do: 
+[[!format txt """
+Section "DRI"
+    Mode 0666
+EndSection
+"""]]
+To restrict DRI access to a certain group, find on your system the name of the group that is for video hardware access. (Have a look in `/etc/group`. It is often called `video`.) Add the users that may access the video hardware to that group. Then put this into `xorg.conf`: 
+[[!format txt """
+Section "DRI"
+    Group "video"
+    Mode 0660
+EndSection
+"""]]
+On Linux 2.4.x make sure the agpgart kernel module is loaded before you start X.  On Linux 2.6.x make sure both agpgart and the agp chipset specific driver for your motherboard (via_agp, intel_agp, et al.) are loaded before you start X.  To make the agp modules load automatically add these lines to your `modules.conf`: 
+
+2.4.x kernels: 
+[[!format txt """
+pre-install <drm module> /sbin/modprobe "-k" "agpgart"
+"""]]
+2.6.x kernels: 
+[[!format txt """
+pre-install <drm module> /sbin/modprobe "-k" "agpgart"
+pre-install agpgart /sbin/modprobe "-k" "<agp chipset driver>"
+"""]]
+Replace <drm module> with the name of the drm module for your video card (e.g., radeon, mga, savage, etc.). Replace <agp chipset driver> with the name of the agp driver for your motherboard (e.g., via_agp, intel_agp, etc.). 
+
+For all kernels, make sure the DRM module is loaded before you start X. 
+
+Remember to restart X so the server will use the new modules. 
+
+
+# Troubleshooting
+
+If your issue isn't covered here, please report it on `#dri` on IRC or on the dri-users mailing list.  This section only covers build-time troubleshooting; for run-time issues see [[DriTroubleshooting|DriTroubleshooting]]. 
+
+
+## I cannot load my new DRM module on Linux Kernel 2.6.1
+
+
+[[!format txt """
+FATAL: Error inserting via (/lib/modules/2.6.1/kernel/
+drivers/char/drm/<module name>.ko): Unknown symbol in module,
+or unknown parameter (see dmesg)
+"""]]
+This error occurs because there are some missing symbols in the 2.6.1 kernel source. One way to get around this problem is to upgrade your kernel to a newer version... (You *might* be able to patch the DRM code to avoid this... Not sure about this, though!) 
+
+
+## Can't find 'X11/Xlibint.h'
+
+You need to have the headers for your current X version installed.  How you install these depends on how you installed X in the first place: 
+
+* If you downloaded a binary from xfree86.org, the headers are in `Xprog.tgz`. 
+* For Slackware the package is called `xfree86-devel`. 
+* Redhat/Fedora and SuSE users should install the appropriate `XFree86-devel` package. 
+* Mandrake calls this package `libxfree86-devel` for some reason. 
+* Debian users should use `xlibs-dev`. 
+* Gentoo users only need to make sure `xfree` or `xorg-x11` have already been emerged. 
+
+## Compilation fails when building the kernel modules
+
+When building the kernel modules, the compilation might fail for some modules. In a recent CVS snapshot, I got the following: 
+
+
+[[!format txt """
+savage_drv.c: In function `savage_alloc_continuous_mem':
+savage_drv.c:106: warning: passing arg 1 of `remap_page_range_Rc414bdc2' makes pointer from integer without a cast
+savage_drv.c:106: incompatible type for argument 4 of `remap_page_range_Rc414bdc2'
+savage_drv.c:106: too few arguments to function `remap_page_range_Rc414bdc2'
+savage_drv.c: In function `savage_get_physics_address':
+savage_drv.c:170: warning: implicit declaration of function `pte_offset'
+savage_drv.c:170: warning: assignment makes pointer from integer without a cast
+make[2]: *** [savage_drv.o] Error 1
+"""]]
+You can avoid this problem by only building the modules you need.  See the DRM section above for the bit about the `DRM_MODULES` variable. 
+
+
+## xf86cfg doesn't compile/link
+
+xf86cfg requires libXaw (and appropriate headers) to be installed in order to build.  You can either install the relevant packages for your distribution, or else add the line: 
+
+
+[[!format txt """
+#define BuildXFree86ConfigTools NO
+"""]]
+to your `config/cf/host.def` and rerun `make World`. 
+
+[[ToDo|ToDo]]: fill this in with package names, as above. 
+
+
+## I'm using Gentoo and...
+
+Gentoo has its own How-To on their website -- [[http://www.gentoo.org/doc/en/dri-howto.xml|http://www.gentoo.org/doc/en/dri-howto.xml]] 
+
+For those who enabled DRI via the instructions here... 
+
+There is a known issue with Gentoo's Open``GL package switch; when the `opengl-update` package is installed, Gentoo places Open``GL libraries and header files under `/usr/lib/opengl` and uses symlinks to make everything appear in the normal place.  As a result the normal install process doesn't always work. 
+
+Try setting up a "fake" Open``GL package, and switch into it: 
+[[!format txt """
+cd /usr/lib/opengl
+mkdir mesa-cvs
+cd mesa-cvs
+ln -s ../../../local/lib
+ln -s ../../../local/include
+ln -s ../xorg-x11/extensions
+opengl-update mesa-cvs
+"""]]
+This assumes you installed Mesa (including lib``GL) into `/usr/local`, which is the default. Also, you may like to remove everything in `/usr/local/lib` from Mesa that isn't either `libGL.*` or `libGLU.*` -- things like `libGLw.*` can cause problems. 
+
+If you set things up differently, a way to check whether you are affected by `opengl-update` is to strace any Open``GL based program (for example: `glxgears`) and to see which `libGL.so` it loads. Despite all symlinks it should load `/usr/lib/libGL.so.1.2`. If it doesn't correct the symlinks in `/usr/lib` to point to `/usr/lib/libGL.so.1.2`. After that **don't run `opengl-update`** -- it will only break things. 
+
+
+# References
+
+- [[Guide by snakeoil|http://www.atomicmpc.com.au/forums.asp?s=2&c=16&t=1501]] 
+
+- [[Old DRI building guide|http://dri.sourceforge.net/doc/building.html]] [[http://dri.sourceforge.net/cgi-bin/moin.cgi/RecentChanges|http://dri.sourceforge.net/cgi-bin/moin.cgi/RecentChanges]] 
diff --git a/BuildingWithLLVM.moin b/BuildingWithLLVM.mdwn
index 26b50ee..5cd3707 100644
--- a/BuildingWithLLVM.moin
+++ b/BuildingWithLLVM.mdwn
@@ -1,31 +1,33 @@
-This page describes how to build mesa with llvm support.
-
-First build llvm from svn with clang support:
-
-{{{
-svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
-cd llvm
-./configure --enable-pic
-make
-make install
-cd tools
-svn co http://llvm.org/svn/llvm-project/cfe/trunk clang
-cd clang
-make
-make install
-}}}
-
-Next build mesa with llvm support:
-
-{{{
-git clone git+ssh://marcheu@git.freedesktop.org/git/mesa/mesa
-cd mesa
-git checkout --track -b gallium-0.2 origin/gallium-0.2
-make linux-llvm
-}}}
-
-Mesa-7.9 [still unreleased as of 17-09-2010, but already branched from master] has configure switch for autoconf-based build system: 
-
-{{{
---enable-gallium-llvm
-}}}
+
+This page describes how to build mesa with llvm support. 
+
+First build llvm from svn with clang support: 
+
+
+[[!format txt """
+svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
+cd llvm
+./configure --enable-pic
+make
+make install
+cd tools
+svn co http://llvm.org/svn/llvm-project/cfe/trunk clang
+cd clang
+make
+make install
+"""]]
+Next build mesa with llvm support: 
+
+
+[[!format txt """
+git clone git+ssh://marcheu@git.freedesktop.org/git/mesa/mesa
+cd mesa
+git checkout --track -b gallium-0.2 origin/gallium-0.2
+make linux-llvm
+"""]]
+Mesa-7.9 [still unreleased as of 17-09-2010, but already branched from master] has configure switch for autoconf-based build system:  
+
+
+[[!format txt """
+--enable-gallium-llvm
+"""]]
+\ No newline at end of file
diff --git a/CAS.moin b/CAS.mdwn
index ee6f164..221c3f1 100644
--- a/CAS.moin
+++ b/CAS.mdwn
@@ -1,8 +1,13 @@
-== Check And Set (CAS) ==
-
-CAS, meaning "Check and Set" or "Compare and Swap," is used by the DRI for the fast locking it uses.  The DRM_CAS macro is located in xc/programs/Xserver/hw/xfree86/os-support/xf86drm.h and is really Check and Set.  It takes a pointer to the lock, the possible old value, the new value, and a place to store the result to.  Then, atomically, the lock is checked for the old value and set to the new value if equal.  If this passes, the return value is set to 1, else 0.
-
-The DRM's locking is based on this.  To lock from userland, a CAS is tried with the old value being the context ID and the new value being the context ID ORed with DRM_LOCK_HELD.  If this passes, then the client holds the lock.  If not, then drmGetLock is called, which goes into the kernel, tries to get the lock, and sleeps on the lock if it's held.
-
-----
-CategoryGlossary
+
+
+## Check And Set (CAS)
+
+CAS, meaning "Check and Set" or "Compare and Swap," is used by the DRI for the fast locking it uses.  The DRM_CAS macro is located in xc/programs/Xserver/hw/xfree86/os-support/xf86drm.h and is really Check and Set.  It takes a pointer to the lock, the possible old value, the new value, and a place to store the result to.  Then, atomically, the lock is checked for the old value and set to the new value if equal.  If this passes, the return value is set to 1, else 0. 
+
+The DRM's locking is based on this.  To lock from userland, a CAS is tried with the old value being the context ID and the new value being the context ID ORed with DRM_LOCK_HELD.  If this passes, then the client holds the lock.  If not, then drmGetLock is called, which goes into the kernel, tries to get the lock, and sleeps on the lock if it's held. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/CVSView.mdwn b/CVSView.mdwn
new file mode 100644
index 0000000..757b303
--- /dev/null
+++ b/CVSView.mdwn
@@ -0,0 +1,8 @@
+
+To browse the CVS repository online and view the complete history of any file in the repository. 
+
+For Mesa see [[http://freedesktop.org/cgi-bin/viewcvs.cgi/mesa/|http://freedesktop.org/cgi-bin/viewcvs.cgi/mesa/]] 
+
+For DRI see [[http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/|http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/]] 
+
+See CVS, [[CvsPolicy|CvsPolicy]], and [[CvsBranches|CvsBranches]] for more information on using the CVS repositories. 
diff --git a/CVSView.moin b/CVSView.moin
deleted file mode 100644
index 57ef524..0000000
--- a/CVSView.moin
+++ /dev/null
@@ -1,7 +0,0 @@
-To browse the CVS repository online and view the complete history of any file in the repository.
-
-For Mesa see http://freedesktop.org/cgi-bin/viewcvs.cgi/mesa/
-
-For DRI see http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/
-
-See CVS, CvsPolicy, and CvsBranches for more information on using the CVS repositories.
diff --git a/CVSup.moin b/CVSup.mdwn
index 56269a9..c68d379 100644
--- a/CVSup.moin
+++ b/CVSup.mdwn
@@ -1,23 +1,24 @@
-CVSup is a tool which allows quick checkouts of CVS branches or mirroring of a CVS repository.
-
-To use it, first install cvsup. It can be installed using "apt-get install cvsup" on debian, "yum install cvsup" on fedora, "portupgrade -RiN cvsup" on FreeBSD, or downloaded and installed manually from http://www.cvsup.org/ . Then grab the [[http://dri.freedesktop.org/~dri/dri-supfile|dri-supfile]].
-
-Next, edit your dri-supfile for your configuration. The example dri-supfile tells cvsup to place checked out files in /usr/src/dri and cvsup's extra state in /etc/cvsup/drisup. If you wish to check out a branch other than the trunk of CVS, edit the tag in the line:
-
-{{{    * default release=cvs tag=.  }}}
-
-to the name of your branch, for example:
-
-{{{    * default release=cvs tag=mach64-0-0-6-branch }}}
-
-If you want to check out the entire CVS repository, remove the "tag=." line entirely. If you choose to do that, you can then check out CVS from your local machine using:
-
-{{{ cvs -d/usr/src/dri checkout xc }}}
-
-This allows for fast checkouts and diffing without hitting the network.
-
-Below that is the collection name, "dri-xc." Two collections are offered. The "dri-xc" collection contains just the xc/ directory, which is what most people want from DRI CVS. Changing that to the "dri" collection will get you all of CVS, including the agpgart WIP and other projects.
-
-When you are finished configuring, run "cvsup dri-supfile". You may want to check out the cvsup manpage for extra flags to add.  My standard set is "cvsup -s -g -L 2 dri-supfile". The process can be killed and restarted as necessary, if your connection is slow. 
-
-See CVS, CvsPolicy, and CvsBranches for more information on using the DRI CVS repository.
+
+CVSup is a tool which allows quick checkouts of CVS branches or mirroring of a CVS repository. 
+
+To use it, first install cvsup. It can be installed using "apt-get install cvsup" on debian, "yum install cvsup" on fedora, "portupgrade -RiN cvsup" on FreeBSD, or downloaded and installed manually from [[http://www.cvsup.org/|http://www.cvsup.org/]] . Then grab the [[dri-supfile|http://dri.freedesktop.org/~dri/dri-supfile]]. 
+
+Next, edit your dri-supfile for your configuration. The example dri-supfile tells cvsup to place checked out files in /usr/src/dri and cvsup's extra state in /etc/cvsup/drisup. If you wish to check out a branch other than the trunk of CVS, edit the tag in the line: 
+
+`    * default release=cvs tag=.  ` 
+
+to the name of your branch, for example: 
+
+`    * default release=cvs tag=mach64-0-0-6-branch ` 
+
+If you want to check out the entire CVS repository, remove the "tag=." line entirely. If you choose to do that, you can then check out CVS from your local machine using: 
+
+` cvs -d/usr/src/dri checkout xc ` 
+
+This allows for fast checkouts and diffing without hitting the network. 
+
+Below that is the collection name, "dri-xc." Two collections are offered. The "dri-xc" collection contains just the xc/ directory, which is what most people want from DRI CVS. Changing that to the "dri" collection will get you all of CVS, including the agpgart WIP and other projects. 
+
+When you are finished configuring, run "cvsup dri-supfile". You may want to check out the cvsup manpage for extra flags to add.  My standard set is "cvsup -s -g -L 2 dri-supfile". The process can be killed and restarted as necessary, if your connection is slow.  
+
+See CVS, [[CvsPolicy|CvsPolicy]], and [[CvsBranches|CvsBranches]] for more information on using the DRI CVS repository. 
diff --git a/CategoryFaq.mdwn b/CategoryFaq.mdwn
new file mode 100644
index 0000000..4c0eccc
--- /dev/null
+++ b/CategoryFaq.mdwn
@@ -0,0 +1,19 @@
+
+
+# Frequently Asked Questions
+
+Here is a list of pages with frequently asked questions: 
+
+[[!inline pages="link(CategoryFaq)" quick feeds="no" archive="yes"]] 
+
+
+
+---
+
+ See also the [[old FAQ|http://dri.sourceforge.net/old/faq.phtml]]. 
+
+
+
+---
+
+ [[CategoryCategory|CategoryCategory]] 
diff --git a/CategoryFaq.moin b/CategoryFaq.moin
deleted file mode 100644
index 5818f39..0000000
--- a/CategoryFaq.moin
+++ /dev/null
@@ -1,11 +0,0 @@
-= Frequently Asked Questions =
-
-Here is a list of pages with frequently asked questions:
-
-<<FullSearch(CategoryFaq)>>
-
-----
-See also the [[http://dri.sourceforge.net/old/faq.phtml|old FAQ]].
-
-----
-CategoryCategory
diff --git a/CategoryGlossary.mdwn b/CategoryGlossary.mdwn
new file mode 100644
index 0000000..6cc492f
--- /dev/null
+++ b/CategoryGlossary.mdwn
@@ -0,0 +1,7 @@
+
+
+# Glossary
+
+Here is a list of pages with glossary definitions: 
+
+[[!inline pages="link(CategoryGlossary)" quick feeds="no" archive="yes"]] 
diff --git a/CategoryGlossary.moin b/CategoryGlossary.moin
deleted file mode 100644
index d84d023..0000000
--- a/CategoryGlossary.moin
+++ /dev/null
@@ -1,5 +0,0 @@
-= Glossary =
-
-Here is a list of pages with glossary definitions:
-
-<<FullSearch(CategoryGlossary)>>
diff --git a/CategoryHardware.mdwn b/CategoryHardware.mdwn
new file mode 100644
index 0000000..5a8fa0c
--- /dev/null
+++ b/CategoryHardware.mdwn
@@ -0,0 +1,2 @@
+
+Here is a list of pages covering hardware specific details: [[!inline pages="link(CategoryHardware)" quick feeds="no" archive="yes"]] 
diff --git a/CategoryHardware.moin b/CategoryHardware.moin
deleted file mode 100644
index d912e1e..0000000
--- a/CategoryHardware.moin
+++ /dev/null
@@ -1,2 +0,0 @@
-Here is a list of pages covering hardware specific details:
-<<FullSearch(CategoryHardware)>>
diff --git a/CategoryHardwareChipset.mdwn b/CategoryHardwareChipset.mdwn
new file mode 100644
index 0000000..da20b95
--- /dev/null
+++ b/CategoryHardwareChipset.mdwn
@@ -0,0 +1,11 @@
+
+
+## Chipsets
+
+[[!inline pages="link(CategoryHardwareChipset)" quick feeds="no" archive="yes"]] 
+
+
+
+---
+
+ [[CategoryCategory|CategoryCategory]] 
diff --git a/CategoryHardwareChipset.moin b/CategoryHardwareChipset.moin
deleted file mode 100644
index f740840..0000000
--- a/CategoryHardwareChipset.moin
+++ /dev/null
@@ -1,6 +0,0 @@
-== Chipsets ==
-
-<<FullSearch(CategoryHardwareChipset)>>
-
-----
-CategoryCategory
diff --git a/CategoryHardwareVendor.mdwn b/CategoryHardwareVendor.mdwn
new file mode 100644
index 0000000..3dd1f61
--- /dev/null
+++ b/CategoryHardwareVendor.mdwn
@@ -0,0 +1,11 @@
+
+
+## Independent Hardware Vendors
+
+[[!inline pages="link(CategoryHardwareVendor)" quick feeds="no" archive="yes"]] 
+
+
+
+---
+
+ [[CategoryCategory|CategoryCategory]] 
diff --git a/CategoryHardwareVendor.moin b/CategoryHardwareVendor.moin
deleted file mode 100644
index e7360a8..0000000
--- a/CategoryHardwareVendor.moin
+++ /dev/null
@@ -1,6 +0,0 @@
-== Independent Hardware Vendors ==
-
-<<FullSearch(CategoryHardwareVendor)>>
-
-----
-CategoryCategory
diff --git a/CategoryHelpWanted.mdwn b/CategoryHelpWanted.mdwn
new file mode 100644
index 0000000..d08a652
--- /dev/null
+++ b/CategoryHelpWanted.mdwn
@@ -0,0 +1,9 @@
+
+
+## Help Wanted
+
+This is a list of potential enhancements that can be incorporated into the DRI project. 
+
+If you are interested in developing or funding any DRI enhancements, simply post your interest to the [[DRI Developers list|http://lists.sourceforge.net/mailman/listinfo/dri-devel]] or contact [[JensOwen|JensOwen]] at Tungsten Graphics. 
+
+[[!inline pages="link(CategoryHelpWanted)" quick feeds="no" archive="yes"]] 
diff --git a/CategoryHelpWanted.moin b/CategoryHelpWanted.moin
deleted file mode 100644
index 3919c77..0000000
--- a/CategoryHelpWanted.moin
+++ /dev/null
@@ -1,7 +0,0 @@
-== Help Wanted ==
-
-This is a list of potential enhancements that can be incorporated into the DRI project.
-
-If you are interested in developing or funding any DRI enhancements, simply post your interest to the [[http://lists.sourceforge.net/mailman/listinfo/dri-devel|DRI Developers list]] or contact JensOwen at Tungsten Graphics.
-
-<<FullSearch(CategoryHelpWanted)>>
diff --git a/CategoryOperatingSystem.mdwn b/CategoryOperatingSystem.mdwn
new file mode 100644
index 0000000..d71fe70
--- /dev/null
+++ b/CategoryOperatingSystem.mdwn
@@ -0,0 +1,11 @@
+
+
+## Operating Systems
+
+[[!inline pages="link(CategoryOperatingSystem)" quick feeds="no" archive="yes"]] 
+
+
+
+---
+
+ [[CategoryCategory|CategoryCategory]] 
diff --git a/CategoryOperatingSystem.moin b/CategoryOperatingSystem.moin
deleted file mode 100644
index 9ea9d14..0000000
--- a/CategoryOperatingSystem.moin
+++ /dev/null
@@ -1,6 +0,0 @@
-== Operating Systems ==
-
-<<FullSearch(CategoryOperatingSystem)>>
-
-----
-CategoryCategory
diff --git a/CategoryTemplate.mdwn b/CategoryTemplate.mdwn
new file mode 100644
index 0000000..d156735
--- /dev/null
+++ b/CategoryTemplate.mdwn
@@ -0,0 +1,14 @@
+
+Describe the pages in this category... 
+
+To add a page to this category, add a link to this page on the last line of the page. You can add multiple categories to a page. 
+
+**List of pages in this category:** 
+
+[[!inline pages="link(CategoryTemplate)" quick feeds="no" archive="yes"]] 
+
+
+
+---
+
+ [[CategoryCategory|CategoryCategory]] 
diff --git a/CategoryTemplate.moin b/CategoryTemplate.moin
deleted file mode 100644
index 6a6a603..0000000
--- a/CategoryTemplate.moin
+++ /dev/null
@@ -1,17 +0,0 @@
-## Please edit system and help pages ONLY in the moinmaster wiki! For more
-## information, please see MoinMaster:MoinPagesEditorGroup.
-##master-page:CategoryTemplate
-##master-date:Unknown-Date
-#format wiki
-#language en
-
-Describe the pages in this category...
-
-To add a page to this category, add a link to this page on the last line of the page. You can add multiple categories to a page.
-
-'''List of pages in this category:'''
-
-<<FullSearchCached(CategoryTemplate)>>
-
-----
-CategoryCategory
diff --git a/CategoryTroubleshooting.mdwn b/CategoryTroubleshooting.mdwn
new file mode 100644
index 0000000..98cfd80
--- /dev/null
+++ b/CategoryTroubleshooting.mdwn
@@ -0,0 +1,11 @@
+
+
+## Troubleshooting
+
+ 
+
+
+
+---
+
+ [[CategoryCategory|CategoryCategory]] 
diff --git a/CategoryTroubleshooting.moin b/CategoryTroubleshooting.moin
deleted file mode 100644
index 9495e78..0000000
--- a/CategoryTroubleshooting.moin
+++ /dev/null
@@ -1,6 +0,0 @@
-== Troubleshooting ==
-
-<<FullSearch>>
-
-----
-CategoryCategory
diff --git a/CirrusLogic.mdwn b/CirrusLogic.mdwn
new file mode 100644
index 0000000..2f1d073
--- /dev/null
+++ b/CirrusLogic.mdwn
@@ -0,0 +1,26 @@
+
+
+# Cirrus Logic
+
+**Chipsets** [[!map pages="^Vendor.+"]] 
+
+
+## Status
+
+Documentation exists but no current driver support. 
+
+
+## Specifications
+
+Publically available for the 5465 series devices. These have basic textured triangle engines and not much else. 
+
+
+## Resources
+
+A primitive Cirrus driver, called "mondello", was available in Mesa 1.2.8, which can still be found on ftp sites. ([[Example|http://www.ibiblio.org/pub/linux/libs/X/Mesa-1.2.8.src.tgz]]) 
+
+
+
+---
+
+ [[CategoryHardwareVendor|CategoryHardwareVendor]] [[http://dri.sourceforge.net/cgi-bin/moin.cgi/RecentChanges|http://dri.sourceforge.net/cgi-bin/moin.cgi/RecentChanges]] 
diff --git a/CirrusLogic.moin b/CirrusLogic.moin
deleted file mode 100644
index 8a87fd3..0000000
--- a/CirrusLogic.moin
+++ /dev/null
@@ -1,20 +0,0 @@
-= Cirrus Logic =
-
-'''Chipsets'''
-<<PageList(^Vendor.+)>>
-
-== Status ==
-
-Documentation exists but no current driver support.
-
-== Specifications ==
-
-Publically available for the 5465 series devices. These have basic textured triangle engines and not much else.
-
-== Resources ==
-
-A primitive Cirrus driver, called "mondello", was available in Mesa 1.2.8, which can still be found on ftp sites. ([[http://www.ibiblio.org/pub/linux/libs/X/Mesa-1.2.8.src.tgz | Example]])
-
-----
-CategoryHardwareVendor
-http://dri.sourceforge.net/cgi-bin/moin.cgi/RecentChanges
diff --git a/CommunicationSchemes.mdwn b/CommunicationSchemes.mdwn
new file mode 100644
index 0000000..60635c4
--- /dev/null
+++ b/CommunicationSchemes.mdwn
@@ -0,0 +1,18 @@
+
+
+# Communication schemes
+
+[[!inline pages="PIO" quick="yes" raw="yes"]] 
+
+[[!inline pages="MMIO" quick="yes" raw="yes"]] 
+
+[[!inline pages="DMA" quick="yes" raw="yes"]] 
+
+
+## Summary
+
+All of these communication schemes was originally used with disk I/O before graphics entered the picture, so you may wish to view them in that light. It makes it more obvious how they fit together in terms of efficiency. In PIO, you had to write a loop to write a chunk of data to one address in I/O space with outb or outw.   
+
+With MMIO, you could use a simple _memcpy_ call and take advantage of all of the optimizations inherent in that.   
+
+With DMA, you wrote a few bytes to an I/O address to tell an external chip to "go to town" on data you had already composed. Meanwhile, you could work on getting the next chunk ready. Most simultaneous work getting done in the latter case. 
diff --git a/CommunicationSchemes.moin b/CommunicationSchemes.moin
deleted file mode 100644
index bb1e94d..0000000
--- a/CommunicationSchemes.moin
+++ /dev/null
@@ -1,23 +0,0 @@
-= Communication schemes =
-
-<<Include(PIO)>>
-
-<<Include(MMIO)>>
-
-<<Include(DMA)>>
-
-== Summary ==
-
-All of these communication schemes was originally used with disk I/O before
-graphics entered the picture, so you may wish to view them in that light. It
-makes it more obvious how they fit together in terms of efficiency. In PIO, you
-had to write a loop to write a chunk of data to one address in I/O space with
-outb or outw.  
-
-With MMIO, you could use a simple ''memcpy'' call and take advantage of all of
-the optimizations inherent in that.  
-
-With DMA, you wrote a few bytes to an I/O address to tell an external chip to
-"go to town" on data you had already composed. Meanwhile, you could work on
-getting the next chunk ready. Most simultaneous work getting done in the latter
-case.
diff --git a/CompiledVertexArray.mdwn b/CompiledVertexArray.mdwn
new file mode 100644
index 0000000..71cfca0
--- /dev/null
+++ b/CompiledVertexArray.mdwn
@@ -0,0 +1,13 @@
+
+
+# Generic Optimization for EXT_compiled_vertex_array
+
+It should be possible to provide generic optimization for [[compiled vertex arrays|http://www.opengl.org/registry/specs/EXT/compiled_vertex_array.txt]].  These optimizations should be implementable for both indirect rendering and direct rendering.  For the direct rendering case, Mesa should provide generic paths that drivers can enable or disable.  These paths are only useful for drivers that implement [[vertex buffer objects|http://www.opengl.org/registry/specs/ARB/vertex_buffer_object.txt]] and have hardware T&L units. 
+
+When glLockArraysEXT is called, a buffer is created that is large enough to hold all of the currently known array state.  All arrays for which data has been set (e.g., via glVertexPointer, glColorPointer, etc) is included in the calculation.  It is possible that the application may enable or disable additional arrays.  The calculated size includes only the range specified by the "count" parameter of glLockArraysEXT. 
+
+At this time, a flag is set within libGL to note that the library is in the special CVA mode.  If any pointer function is called, the buffer object is destroyed and the flag is cleared. 
+
+In the CVA case, all element data will come from client memory either via calls to glArrayElement, glDrawArrays, or the pointer supplied to glDrawElements.  This implies that all the indexes will pass through libGL. When the data passes through libGL, the library can re-base the data from the "first" parameter of glLockArraysEXT.  The net effect is that the library will tell the server that "first" is element zero in all arrays. This implies, of course, that elements less than "first" won't work.  This is not a problem since the EXT_compiled_vertex_array specification clearly states this may not work. 
+
+When a draw call made and the CVA flag is set, buffer object protocol is used to perform the drawing. 
diff --git a/CompiledVertexArray.moin b/CompiledVertexArray.moin
deleted file mode 100644
index 7c933d6..0000000
--- a/CompiledVertexArray.moin
+++ /dev/null
@@ -1,27 +0,0 @@
-= Generic Optimization for EXT_compiled_vertex_array =
-
-It should be possible to provide generic optimization for [[http://www.opengl.org/registry/specs/EXT/compiled_vertex_array.txt|compiled vertex arrays]].  These optimizations should be implementable for both indirect rendering and direct rendering.  For the direct rendering case, Mesa should provide generic paths that drivers can enable or disable.  These paths are only useful for drivers that implement [[http://www.opengl.org/registry/specs/ARB/vertex_buffer_object.txt|vertex buffer objects]] and have hardware T&L units.
-
-When glLockArraysEXT is called, a buffer is created that is large enough to
-hold all of the currently known array state.  All arrays for which data
-has been set (e.g., via glVertexPointer, glColorPointer, etc) is included in
-the calculation.  It is possible that the application may enable or disable
-additional arrays.  The calculated size includes only the range specified by
-the "count" parameter of glLockArraysEXT.
-
-At this time, a flag is set within libGL to note that the library is in the
-special CVA mode.  If any pointer function is called, the buffer object is
-destroyed and the flag is cleared.
-
-In the CVA case, all element data will come from client memory either via
-calls to glArrayElement, glDrawArrays, or the pointer supplied to
-glDrawElements.  This implies that all the indexes will pass through libGL.
-When the data passes through libGL, the library can re-base the data from
-the "first" parameter of glLockArraysEXT.  The net effect is that the
-library will tell the server that "first" is element zero in all arrays.
-This implies, of course, that elements less than "first" won't work.  This
-is not a problem since the EXT_compiled_vertex_array specification clearly
-states this may not work.
-
-When a draw call made and the CVA flag is set, buffer object protocol is
-used to perform the drawing.
diff --git a/CompositeSwap.mdwn b/CompositeSwap.mdwn
new file mode 100644
index 0000000..da74814
--- /dev/null
+++ b/CompositeSwap.mdwn
@@ -0,0 +1,211 @@
+
+
+## Issues
+
+X and GL applications need to control how their data is displayed for several reasons:  
+
+   * preventing distracting artifacts - ugly "tearing" or partial drawing for example 
+   * smoothness - constant, predictable frame rates are a requirement for animation, video and high end simulation programs 
+   * performance - apps need to know how well they're keeping up with their desired frame rate so they can throttle back or simplify drawing as needed 
+Plain X doesn't have many ways of doing the above (it mostly assumes immediate mode drawing to the visible frame buffer), but GLX provides many extensions related to handling the actual display of buffers on the user visible screen, these extensions need to be supported in DRI2 for the Linux graphics stack to really shine. 
+
+There are also issues related to memory consumption, swap behavior, and performance that can be addressed: 
+
+
+### Memory savings
+
+   * memory consumption could be reduced if the private back/front pair was reduced to just a private back with the compositor copy acting as front (though there are issues with front buffer rendering in this case). 
+         * This can be implemented purely client side through the addition of compositor<->client protocols. 
+   * it could also be reduced by throwing away the private back buffer in between frame rendering. 
+         * This can happen automatically with some additions to the DRI2 protocol and client/server behavior. 
+
+### Performance
+
+   * performance could be significantly improved on low bandwidth platform if buffer swaps could be simple pointer exchanges when windowed (similar to the way page flips work for full screen applications) 
+         * requires window managers to draw decorations independent of application window (i.e. exchange is only possible if front & back window pixmaps are the same size) 
+   * page flipping for full screen swaps is also a significant win on bandwidth limited platforms 
+
+### Behavior
+
+   * some applications want to control how buffer swaps occur (e.g. to preserve back buffer contents after a swap) 
+   * triple buffering should be available to applications that need it, with configurable behavior for discard vs. queue if the buffers are rendered faster than can be displayed 
+
+## OpenGL and GLX swap and throttling related extensions
+
+Under a compositor, the behavior of these routines could change, or additional compositor<->client protocol added to support similar behavior.  Changes noted below, though in general "video frame" should be thought of as a virtualized compositor frame rate rather than a monitor refresh (e.g. the compositor may report 60fps to applications even though it only updates the screen when recompositing is needed): 
+
+   * [[SGI_swap_control|http://www.opengl.org/registry/specs/SGI/swap_control.txt]] - controls how frequently glXSwapBuffers swaps occur (in frames) 
+         1. for redirected windows, interval is in compositor frames rather than monitor video frames 
+   * [[SGI_video_sync|http://www.opengl.org/registry/specs/SGI/video_sync.txt]] - allows clients to query frame counts and wait on specific counts or divisor/remainders thereof 
+         1. for redirected windows, glXGetVideoSyncSGI returns the compositor frame count rather than the monitor frame count 
+         1. for redirected windows, glXWaitVideoSyncSGI will block until the compositor frame count satisfies the specified conditions 
+   * [[OML_sync_control|http://www.opengl.org/registry/specs/OML/glx_sync_control.txt]] - combines the above and adds the notion of a "swap count" and frame timestamp, allowing applications to closely monitor their performance and swap frequency 
+         1. for redirected windows, MSC represents the compositor frame count; likewise UST indicates the time when the compositor last generated a frame 
+         1. for redirected windows, SBC could be incremented when the compositor copies a buffer rather than when the buffer is copied from back to front 
+   * [[OML_swap_method|http://www.opengl.org/registry/specs/OML/glx_swap_method.txt]] - exposes swap method (whether copy, exchange or undefined) to the FBconfig 
+         1. the way X and compositors work now make it hard to report anything other than 'unknown' as the swap method; page flipping is opportunistic, and exchange is difficult for windows (redirected or not) due to reparenting by window managers 
+   * [[SGIX_swap_group|http://www.opengl.org/registry/specs/SGIX/swap_group.txt]]/[[NV_swap_group|http://www.opengl.org/registry/specs/NV/glx_swap_group.txt]] - allow clients to swap in a synchronized manner 
+         1. for redirected windows, swap groups could depend on compositor copies (see SBC count above) 
+   * [[SGIX_swap_barrier|http://www.opengl.org/registry/specs/SGIX/swap_barrier.txt]] - controls swap group behavior 
+         1. should be unaffected 
+   * TBD_swap_control - allow selection triple/N buffering 
+         1. needs to be defined, can fail if driver can't handle requested number of buffers 
+   * [[INTEL_swap_event|http://people.freedesktop.org/~jbarnes/swapbufferevent.txt]] - deliver swap information to clients after a swap completes, useful for integrating swap based throttling into client event loops 
+
+## Compositor extensions
+
+To support the above, feedback from the currently active compositor is necessary.  Compositor<->client protocol is needed for: 
+
+   * [[CompositeNotifyPixmapCopied|CompositeNotifyPixmapCopied]](pixmap) - compositor notifies server that pixmap has been copied, unblocks clients blocked on swapping or rendering to front 
+         * should be doable with xsync already, as a defined protocol between the compositor and clients 
+   * [[NotifyPixmapReady|NotifyPixmapReady]](pixmap) - server notifies compositor that an application has a new frame is ready (e.g. after a glXSwapBuffers) 
+         * should be similar to a damage event, maybe damage is sufficient? 
+   * [[CompositeNotifyFrameDone|CompositeNotifyFrameDone]] - compositor notifies client that the compositor has finished drawing a new frame; clients blocked on frame related events can continue. 
+         * again, should be doable with xsync 
+
+## Triple buffering
+
+Triple buffering means different things to different people.  For convenience, we list the types we're concerned about for this discussion here.  All have a high memory cost and should generally only be enabled for a small number of clients at a time. 
+
+   1. compositor based - compositor keeps a private copy of each application's front buffer; this means it always has a consistent, fully drawn pixmap to use for creating screen frames.  glXSwapBuffers updates the redirected front and notifies the compositor a new one is ready to pick up as its private copy. 
+            * good for avoiding ugly partial drawing artifacts 
+   1. server based - server keeps last ready client buffer around and returns available buffers to the client after a glXSwapBuffers occurs 
+            * can help keep clients busy at the cost of extra memory (good to keep frame rates up while preserving vblank sync'd swapping) 
+   1. client based - server returns 3 buffers to the client, which somehow requests copies between various of them using glXSwapBuffers 
+            * like (2) but totally client side. 
+Another factor for triple buffering is how to handle extra frames.  If frames are rendered faster than can be displayed, some applications may want to discard the extra frames, while others may want to queue them (and likely be throttled). 
+
+
+## New code
+
+All of this means new DRI2, display server and compositor code, but it should be doable.  In particular we may want: 
+
+   * DRI2 proto for waiting on a given swap or frame count 
+   * DRI2 swapbuffers support for frame count & divisor/remainder delayed swaps 
+   * new server code for handling swap groups 
+   * new server code for handling indirect clients doing frame count or swap buffer count waits 
+
+### Implementation: SGI_swap_control for the X server
+
+The SGI_swap_control extension allows applications to control their glXSwapBuffers frequency.  The glXSwapIntervalSGI call lets clients specify how frequently, in frames, their buffer swaps should occur.  Implementing this requires server support, since with DRI2 the server is responsible for performing swaps.  The basic flow is as follows: 
+
+   1. When an application calls glXSwapBuffers, a swap is scheduled in the server for the current frame count plus the interval count (though if the swap is to be a page flip, it's scheduled to be scheduled, since flips occur at the next vblank after being queued). 
+   1. The server calls into the DDX driver's ->[[ScheduleSwap|ScheduleSwap]] routine, which is responsible for requesting a kernel frame event for when the swap should occur 
+   1. Control is returned to the client immediately 
+         1. Note: any futher GLX calls requiring a GLX context to be bound will block until the swap completes 
+   1. When the DDX receives the associated frame event, it will perform all the scheduled swap 
+   1. The swap count will increase 
+   1. The client will be unblocked if necessary 
+
+### Implementation: SGI_video_sync for the X server
+
+SGI_video_sync gives clients control over their framerate by exposing the frame count and allowing apps to wait on a given frame count.  glXGetVideoSyncSGI returns the current frame count for the display the drawable is on, and glXWaitVideoSyncSGI allows a client to block until a given frame count is reached on its drawable's display.  Flow in the server & client for glXGetVideoSyncSGI direct rendered case: 
+
+   1. Client calls glXGetVideoSyncSGI 
+   1. Mesa code receives the request and turns it into a DRI2GetMSCReq protocol request 
+   1. display server receives the request and calls DDX driver's ->GetMSC hook 
+   1. DDX driver returns frame count based on drawable location (count is returned for the CRTC with the greatest intersection with the drawable), or 0 if the drawable is currently offscreen (the GLX spec should be updated to reflect this), note this could also return an error ([[BadDrawable|BadDrawable]] possibly). 
+   1. display server returns a DRI2GetMSCReply with the current MSC count to the client 
+Flow for glXWaitVideoSyncSGI direct rendered case: 
+
+   1. Client calls glXWaitVideoSyncSGI 
+   1. Mesa code receives the request and turns it into a DRI2WaitMSCReq protocol request 
+   1. display server receives the request and calls DDX driver's ->ScheduleWaitMSC hook which is responsible for requesting a kernel frame event for the specified [[WaitVideoSync|WaitVideoSync]] values 
+   1. DDX blocks the client until the requested frame is received (which could be immediate if the frame has already passed) 
+   1. DDX receives the event and unblocks the client, calling into the server to complete the reply 
+   1. display server returns a DRI2WaitMSCReply with current MSC, SBC to the client 
+Again, if the window is redirected or the drawable is offscreen, the client won't block; an MSC reply with all zeros will be returned (again, could also return [[BadDrawable|BadDrawable]]). 
+
+
+### Testing
+
+The code for the above is present in several repos and patches: 
+
+   1. kernel - 2.6.33-rc 
+   1. libdrm - 2.4.17 or newer 
+   1. dri2proto - 2.2 or newer 
+   1. glproto - 1.4.11 or newer 
+   1. mesa - master branch (will be in 7.8) 
+   1. xserver - master branch (will be in 1.9) 
+   1. xf86-video-intel - master branch (will be in 2.11) 
+See [[Graphics stack git development|http://wiki.x.org/wiki/Development/git]] for information on how to build a stack with the above. 
+
+The direct rendered cases outlined in the implementation notes above are complete, but there's a bug in the async glXSwapBuffers that sometimes causes clients to hang after swapping rather than continue. 
+
+
+#### Open issues
+
+This implementation does not guarantee tear free drawing in the non-composited, non-fullscreen (flip) case, but does provide the throttling feature implicit in SGI_swap_control.  For a tear-free guarantee, the application must be performing full screen swaps eligible for page filpping or a compositor using page flipping must be present and the application's window redirected.  Alternately, the driver can synchronize its blit activity with the scanout position to avoid tearing.  However this approach can negatively affect performance. 
+
+The implementation also needs screen from the the compositor in the case of redirected windows, so it can request a vblank event from the kernel for the correct CRTC. 
+
+
+# Using the new code
+
+Some Linux applications may assume that glXSwapBuffers blocks until the swap has completed.  With the above code, that's no longer the case (it's also not the case on other GLX implementations, so it's a non-portable assumption). 
+
+Similarly, some code may assume no throttling of swaps occurs.  Now this behavior can be controlled with glXSwapInterval or through using glXSwapBuffersMscOML. 
+
+See below for specific use cases. 
+
+
+## Avoiding tearing
+
+Tearing occurs when blits or scanout buffer changes aren't synchronized with vertical retrace, causing two frames to appear adjacent to one another in the vertical (see [[Screen_tearing|http://en.wikipedia.org/wiki/Screen_tearing]] for an example).  Since vertical blank periods are often very short (especially in LCD panels) and CPU scheduling between processes can be highly variable, simply blocking until a vertical retrace completes (e.g. using glXWaitForMscOML or glXWaitVideoSyncSGI) is not a reliable way of avoiding tearing. 
+
+Some DDX drivers provide an option to synchronize DRI2CopyRegion requests (generated by glXCopySubBufferMESA calls and some paths in glXSwapBuffers calls); this can prevent tearing at a potentially significant performance cost since some GPUs will stall until the vertical retrace is outside the region to be copied. 
+
+Another way to avoid tearing, assuming you're running a kernel with page flipping support, is to run your application full screen or under a compositing manager.  If your app or compositing manager uses glXSwapBuffers to display new frames (as opposed to using glXCopySubBufferMESA without driver vertical retrace synchronization), the DDX and server should coordinate to flip whole new scanout buffers through the kernel, which synchronizes the flip to vertical retrace. 
+
+
+## Throttling rendering
+
+Use SGI_video_sync, SGI_swap_control, OML_sync_control or ARB_sync extensions to render at a constant rate.  Depending on the application, it may be appropriate to throttle your rendering to a factor of the refresh rate (using SGI_swap_control or OML_sync_control) if you can't keep up with it; this avoids a variable frame rate which can be visually distracting.  However, for many animations, especially those simulating physical activities (e.g. a bounce or slide), maintaining refresh rate rendering is critical to visual quality, so reducing quality may be a better option than dropping frames or displaying every other frame in those cases where your application can't keep up with the refresh rate. 
+
+
+## Controlling buffer swap behavior
+
+Use a TBD_swap_method_control to select triple buffering, blit or exchange methods. 
+
+
+## Mutter
+
+* When memory isn't a concern: 
+   * Triple buffer all composited applications: 
+      * 1) busy being used as part of the compositors next render. 
+      * 2) a front buffer for the application to queue render commands against; swaping with 3 when done. 
+      * 3) a back buffer waiting to be picked up by the compositor, and swap with 1) 
+      * Ideally the compositor never has to wait to pick up the applications next front buffer, and no copying is required. 
+   * use the SGI_swap_control extension to set glXSwapInterval (1) in applications and compositor. 
+      * compositor "video frame periods" are defined - as normal - so we flip at the first vblank after a render completes.  
+      * Allow the compositor to drive the video frame period of redirected applications (I.e. consider the compositor to be a pseudo display for redirected drawables) 
+      * (Lets assume the compositor is rendering to multiple windows to cover multiple displays - because the full size of the monitors exceeds the GPU render target limits) 
+      * The compositor can use a swap group to ensure each of these windows presents in sync. 
+      * A new fence/sync object like extension could be implemented that allows the compositor to say: "when my sync group becomes ready and swaps, please notify all these composited-drawables of a video frame progression". 
+      * I'm not sure what the best way to link composited drawables to a compositor are a.t.m 
+      * when the compositors group swap completes I imagine it would be possible to avoid having to wait for the compositor to be scheduled  to send a DRI2 request to the X server, to send events to clients. I.e. instead of using new DRI2 protocol to send the notification can it not be dealt with by the drm driver that would presumably know when the compositors group swap completes, it would then know to increment the video frame period for some other set of associated composited-drawables and if they pass their designated swap interval they can be unblocked. (or if we have asynchronous swap buffers - see below - an event could be sent by writing to the device file) 
+      * asynchronous glXSwapBuffers and swap-buffers-complete events. 
+         * Although the applications shouldn't run ahead of the compositor, since there's no point rendering more frames than the compositor can keep up with, applications also shouldn't be blocked from queueing up commands for the next frame. If we had asynchronous swapping + poll-able event notifications for swap-completion the application could stop itself painting when it knows it is two frames ahead of the compositor.  
+
+### Misc notes (rib Thu Sep  3 20:40:43 BST 2009)
+
+* It seems that composited apps should never need to know about real world screen vblank issues, that's only relevant to non-redirected windows including the compositor's. When dealing with a redirected window it seems it would be acceptable to come up with an entirely fake number for all existing extensions that care about vblanks. Somehow tying it to the render/swap-complete of the current compositor seems reasonable. 
+* Assuming we have the compositor generating a fake swap interval as above, and the compositor itself is responsible for synchronizing all windows it's responsible for it seems like all the swap group related extensions may just work. 
+   * Walking through a hypothetical example of a composited flightgear simulator across multiple monitors seems to add up... 
+   * Lets say the compositor has two windows across two monitors (assuming it would exceed render target limits to just have one) 
+   * Say flightgear also creates two windows for the same reason and wants to use a swap group to ensure they get presented at the same time. 
+   * Assume the compositor is itself also using a swap group to ensure all it's windows get presented at the same time and it drives the video frame period according to it own swap group becoming ready and completing. 
+   * If the first flightgear window is drawn too and a swap issued it becomes ready but doesn't actually swap yet (so the compositor wont see it) 
+   * The compositor may at this point complete it's current frame and swap and the latest flightgear window won't be shown. 
+   * The second flightgear window can be drawn too and a swap issued which makes the group ready so now both windows are swapped and become available to the compositor. 
+   * The compositor will pick up the new window contents and since it is itself using a a swap group both windows will be presented in sync. 
+* I can't see how GLX_OML_swap_method can be supported at all, given that GLX doesn't know ahead of time if any glx window will be later redirected? 
+
+## Reference
+
+For reference: 
+
+   * [[Apple GL Programming Guide|http://developer.apple.com/mac/library/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_intro/opengl_intro.html]] - covers best practices for GL programmers in Apple's composited environment 
+   * [[Overview of triple buffering from a gamer perspective|http://www.ocworkbench.com/2006/articles/DXtweaker/]] 
+   * [[Android Developer's Guide|http://developer.android.com/guide/index.html]] 
+   * [[DirectX Programmer's Guide|http://msdn.microsoft.com/en-us/library/bb173024(VS.85).aspx]] 
+\ No newline at end of file
diff --git a/CompositeSwap.moin b/CompositeSwap.moin
deleted file mode 100644
index fc5552c..0000000
--- a/CompositeSwap.moin
+++ /dev/null
@@ -1,192 +0,0 @@
-== Issues ==
-X and GL applications need to control how their data is displayed for several reasons: 
-  * preventing distracting artifacts - ugly "tearing" or partial drawing for example
-  * smoothness - constant, predictable frame rates are a requirement for animation, video and high end simulation programs
-  * performance - apps need to know how well they're keeping up with their desired frame rate so they can throttle back or simplify drawing as needed
-Plain X doesn't have many ways of doing the above (it mostly assumes immediate mode drawing to the visible frame buffer), but GLX provides many extensions related to handling the actual display of buffers on the user visible screen, these extensions need to be supported in DRI2 for the Linux graphics stack to really shine.
-
-There are also issues related to memory consumption, swap behavior, and performance that can be addressed:
-
-=== Memory savings ===
-  * memory consumption could be reduced if the private back/front pair was reduced to just a private back with the compositor copy acting as front (though there are issues with front buffer rendering in this case).
-    * This can be implemented purely client side through the addition of compositor<->client protocols.
-  * it could also be reduced by throwing away the private back buffer in between frame rendering.
-    * This can happen automatically with some additions to the DRI2 protocol and client/server behavior.
-
-=== Performance ===
-  * performance could be significantly improved on low bandwidth platform if buffer swaps could be simple pointer exchanges when windowed (similar to the way page flips work for full screen applications)
-    * requires window managers to draw decorations independent of application window (i.e. exchange is only possible if front & back window pixmaps are the same size)
-  * page flipping for full screen swaps is also a significant win on bandwidth limited platforms
-
-=== Behavior ===
-  * some applications want to control how buffer swaps occur (e.g. to preserve back buffer contents after a swap)
-  * triple buffering should be available to applications that need it, with configurable behavior for discard vs. queue if the buffers are rendered faster than can be displayed
-
-== OpenGL and GLX swap and throttling related extensions ==
-
-Under a compositor, the behavior of these routines could change, or additional compositor<->client protocol added to support similar behavior.  Changes noted below, though in general "video frame" should be thought of as a virtualized compositor frame rate rather than a monitor refresh (e.g. the compositor may report 60fps to applications even though it only updates the screen when recompositing is needed):
-
-  * [[http://www.opengl.org/registry/specs/SGI/swap_control.txt|SGI_swap_control]] - controls how frequently glXSwapBuffers swaps occur (in frames)
-    1. for redirected windows, interval is in compositor frames rather than monitor video frames
-  * [[http://www.opengl.org/registry/specs/SGI/video_sync.txt|SGI_video_sync]] - allows clients to query frame counts and wait on specific counts or divisor/remainders thereof
-    1. for redirected windows, glXGetVideoSyncSGI returns the compositor frame count rather than the monitor frame count
-    1. for redirected windows, glXWaitVideoSyncSGI will block until the compositor frame count satisfies the specified conditions
-  * [[http://www.opengl.org/registry/specs/OML/glx_sync_control.txt|OML_sync_control]] - combines the above and adds the notion of a "swap count" and frame timestamp, allowing applications to closely monitor their performance and swap frequency
-    1. for redirected windows, MSC represents the compositor frame count; likewise UST indicates the time when the compositor last generated a frame
-    1. for redirected windows, SBC could be incremented when the compositor copies a buffer rather than when the buffer is copied from back to front
-  * [[http://www.opengl.org/registry/specs/OML/glx_swap_method.txt|OML_swap_method]] - exposes swap method (whether copy, exchange or undefined) to the FBconfig
-    1. the way X and compositors work now make it hard to report anything other than 'unknown' as the swap method; page flipping is opportunistic, and exchange is difficult for windows (redirected or not) due to reparenting by window managers
-  * [[http://www.opengl.org/registry/specs/SGIX/swap_group.txt|SGIX_swap_group]]/[[http://www.opengl.org/registry/specs/NV/glx_swap_group.txt|NV_swap_group]] - allow clients to swap in a synchronized manner
-    1. for redirected windows, swap groups could depend on compositor copies (see SBC count above)
-  * [[http://www.opengl.org/registry/specs/SGIX/swap_barrier.txt|SGIX_swap_barrier]] - controls swap group behavior
-    1. should be unaffected
-  * TBD_swap_control - allow selection triple/N buffering
-    1. needs to be defined, can fail if driver can't handle requested number of buffers
-  * [[http://people.freedesktop.org/~jbarnes/swapbufferevent.txt|INTEL_swap_event]] - deliver swap information to clients after a swap completes, useful for integrating swap based throttling into client event loops
-
-== Compositor extensions ==
-
-To support the above, feedback from the currently active compositor is necessary.  Compositor<->client protocol is needed for:
-  * CompositeNotifyPixmapCopied(pixmap) - compositor notifies server that pixmap has been copied, unblocks clients blocked on swapping or rendering to front
-    * should be doable with xsync already, as a defined protocol between the compositor and clients
-  * NotifyPixmapReady(pixmap) - server notifies compositor that an application has a new frame is ready (e.g. after a glXSwapBuffers)
-    * should be similar to a damage event, maybe damage is sufficient?
-  * CompositeNotifyFrameDone - compositor notifies client that the compositor has finished drawing a new frame; clients blocked on frame related events can continue.
-    * again, should be doable with xsync
-
-== Triple buffering ==
-
-Triple buffering means different things to different people.  For convenience, we list the types we're concerned about for this discussion here.  All have a high memory cost and should generally only be enabled for a small number of clients at a time.
-
-  1. compositor based - compositor keeps a private copy of each application's front buffer; this means it always has a consistent, fully drawn pixmap to use for creating screen frames.  glXSwapBuffers updates the redirected front and notifies the compositor a new one is ready to pick up as its private copy.
-     * good for avoiding ugly partial drawing artifacts
-  1. server based - server keeps last ready client buffer around and returns available buffers to the client after a glXSwapBuffers occurs
-     * can help keep clients busy at the cost of extra memory (good to keep frame rates up while preserving vblank sync'd swapping)
-  1. client based - server returns 3 buffers to the client, which somehow requests copies between various of them using glXSwapBuffers
-     * like (2) but totally client side.
-
-Another factor for triple buffering is how to handle extra frames.  If frames are rendered faster than can be displayed, some applications may want to discard the extra frames, while others may want to queue them (and likely be throttled).
-
-== New code ==
-
-All of this means new DRI2, display server and compositor code, but it should be doable.  In particular we may want:
-  * DRI2 proto for waiting on a given swap or frame count
-  * DRI2 swapbuffers support for frame count & divisor/remainder delayed swaps
-  * new server code for handling swap groups
-  * new server code for handling indirect clients doing frame count or swap buffer count waits
-
-=== Implementation: SGI_swap_control for the X server ===
-
-The SGI_swap_control extension allows applications to control their glXSwapBuffers frequency.  The glXSwapIntervalSGI call lets clients specify how frequently, in frames, their buffer swaps should occur.  Implementing this requires server support, since with DRI2 the server is responsible for performing swaps.  The basic flow is as follows:
-  1. When an application calls glXSwapBuffers, a swap is scheduled in the server for the current frame count plus the interval count (though if the swap is to be a page flip, it's scheduled to be scheduled, since flips occur at the next vblank after being queued).
-  1. The server calls into the DDX driver's ->ScheduleSwap routine, which is responsible for requesting a kernel frame event for when the swap should occur
-  1. Control is returned to the client immediately
-    i. Note: any futher GLX calls requiring a GLX context to be bound will block until the swap completes
-  1. When the DDX receives the associated frame event, it will perform all the scheduled swap
-  1. The swap count will increase
-  1. The client will be unblocked if necessary
-
-=== Implementation: SGI_video_sync for the X server ===
-
-SGI_video_sync gives clients control over their framerate by exposing the frame count and allowing apps to wait on a given frame count.  glXGetVideoSyncSGI returns the current frame count for the display the drawable is on, and glXWaitVideoSyncSGI allows a client to block until a given frame count is reached on its drawable's display.  Flow in the server & client for glXGetVideoSyncSGI direct rendered case:
-  1. Client calls glXGetVideoSyncSGI
-  1. Mesa code receives the request and turns it into a DRI2GetMSCReq protocol request
-  1. display server receives the request and calls DDX driver's ->GetMSC hook
-  1. DDX driver returns frame count based on drawable location (count is returned for the CRTC with the greatest intersection with the drawable), or 0 if the drawable is currently offscreen (the GLX spec should be updated to reflect this), note this could also return an error (BadDrawable possibly).
-  1. display server returns a DRI2GetMSCReply with the current MSC count to the client
-
-Flow for glXWaitVideoSyncSGI direct rendered case:
-  1. Client calls glXWaitVideoSyncSGI
-  1. Mesa code receives the request and turns it into a DRI2WaitMSCReq protocol request
-  1. display server receives the request and calls DDX driver's ->ScheduleWaitMSC hook which is responsible for requesting a kernel frame event for the specified WaitVideoSync values
-  1. DDX blocks the client until the requested frame is received (which could be immediate if the frame has already passed)
-  1. DDX receives the event and unblocks the client, calling into the server to complete the reply
-  1. display server returns a DRI2WaitMSCReply with current MSC, SBC to the client
-Again, if the window is redirected or the drawable is offscreen, the client won't block; an MSC reply with all zeros will be returned (again, could also return BadDrawable).
-
-=== Testing ===
-
-The code for the above is present in several repos and patches:
-  1. kernel - 2.6.33-rc
-  1. libdrm - 2.4.17 or newer
-  1. dri2proto - 2.2 or newer
-  1. glproto - 1.4.11 or newer
-  1. mesa - master branch (will be in 7.8)
-  1. xserver - master branch (will be in 1.9)
-  1. xf86-video-intel - master branch (will be in 2.11)
-
-See [[http://wiki.x.org/wiki/Development/git|Graphics stack git development]] for information on how to build a stack with the above.
-
-The direct rendered cases outlined in the implementation notes above are complete, but there's a bug in the async glXSwapBuffers that sometimes causes clients to hang after swapping rather than continue.
-
-==== Open issues ====
-
-This implementation does not guarantee tear free drawing in the non-composited, non-fullscreen (flip) case, but does provide the throttling feature implicit in SGI_swap_control.  For a tear-free guarantee, the application must be performing full screen swaps eligible for page filpping or a compositor using page flipping must be present and the application's window redirected.  Alternately, the driver can synchronize its blit activity with the scanout position to avoid tearing.  However this approach can negatively affect performance.
-
-The implementation also needs screen from the the compositor in the case of redirected windows, so it can request a vblank event from the kernel for the correct CRTC.
-
-= Using the new code =
-
-Some Linux applications may assume that glXSwapBuffers blocks until the swap has completed.  With the above code, that's no longer the case (it's also not the case on other GLX implementations, so it's a non-portable assumption).
-
-Similarly, some code may assume no throttling of swaps occurs.  Now this behavior can be controlled with glXSwapInterval or through using glXSwapBuffersMscOML.
-
-See below for specific use cases.
-
-== Avoiding tearing ==
-
-Tearing occurs when blits or scanout buffer changes aren't synchronized with vertical retrace, causing two frames to appear adjacent to one another in the vertical (see [[http://en.wikipedia.org/wiki/Screen_tearing|Screen_tearing]] for an example).  Since vertical blank periods are often very short (especially in LCD panels) and CPU scheduling between processes can be highly variable, simply blocking until a vertical retrace completes (e.g. using glXWaitForMscOML or glXWaitVideoSyncSGI) is not a reliable way of avoiding tearing.
-
-Some DDX drivers provide an option to synchronize DRI2CopyRegion requests (generated by glXCopySubBufferMESA calls and some paths in glXSwapBuffers calls); this can prevent tearing at a potentially significant performance cost since some GPUs will stall until the vertical retrace is outside the region to be copied.
-
-Another way to avoid tearing, assuming you're running a kernel with page flipping support, is to run your application full screen or under a compositing manager.  If your app or compositing manager uses glXSwapBuffers to display new frames (as opposed to using glXCopySubBufferMESA without driver vertical retrace synchronization), the DDX and server should coordinate to flip whole new scanout buffers through the kernel, which synchronizes the flip to vertical retrace.
-
-== Throttling rendering ==
-
-Use SGI_video_sync, SGI_swap_control, OML_sync_control or ARB_sync extensions to render at a constant rate.  Depending on the application, it may be appropriate to throttle your rendering to a factor of the refresh rate (using SGI_swap_control or OML_sync_control) if you can't keep up with it; this avoids a variable frame rate which can be visually distracting.  However, for many animations, especially those simulating physical activities (e.g. a bounce or slide), maintaining refresh rate rendering is critical to visual quality, so reducing quality may be a better option than dropping frames or displaying every other frame in those cases where your application can't keep up with the refresh rate.
-
-== Controlling buffer swap behavior ==
-
-Use a TBD_swap_method_control to select triple buffering, blit or exchange methods.
-
-== Mutter ==
-
- * When memory isn't a concern:
-  * Triple buffer all composited applications:
-   * 1) busy being used as part of the compositors next render.
-   * 2) a front buffer for the application to queue render commands against; swaping with 3 when done.
-   * 3) a back buffer waiting to be picked up by the compositor, and swap with 1)
-   * Ideally the compositor never has to wait to pick up the applications next front buffer, and no copying is required.
-  * use the SGI_swap_control extension to set glXSwapInterval (1) in applications and compositor.
-   * compositor "video frame periods" are defined - as normal - so we flip at the first vblank after a render completes. 
-   * Allow the compositor to drive the video frame period of redirected applications (I.e. consider the compositor to be a pseudo display for redirected drawables)
-   * (Lets assume the compositor is rendering to multiple windows to cover multiple displays - because the full size of the monitors exceeds the GPU render target limits)
-   * The compositor can use a swap group to ensure each of these windows presents in sync.
-   * A new fence/sync object like extension could be implemented that allows the compositor to say: "when my sync group becomes ready and swaps, please notify all these composited-drawables of a video frame progression".
-   * I'm not sure what the best way to link composited drawables to a compositor are a.t.m
-   * when the compositors group swap completes I imagine it would be possible to avoid having to wait for the compositor to be scheduled  to send a DRI2 request to the X server, to send events to clients. I.e. instead of using new DRI2 protocol to send the notification can it not be dealt with by the drm driver that would presumably know when the compositors group swap completes, it would then know to increment the video frame period for some other set of associated composited-drawables and if they pass their designated swap interval they can be unblocked. (or if we have asynchronous swap buffers - see below - an event could be sent by writing to the device file)
-   * asynchronous glXSwapBuffers and swap-buffers-complete events.
-    * Although the applications shouldn't run ahead of the compositor, since there's no point rendering more frames than the compositor can keep up with, applications also shouldn't be blocked from queueing up commands for the next frame. If we had asynchronous swapping + poll-able event notifications for swap-completion the application could stop itself painting when it knows it is two frames ahead of the compositor. 
-
-=== Misc notes (rib Thu Sep  3 20:40:43 BST 2009) ===
-
- * It seems that composited apps should never need to know about real world screen vblank issues, that's only relevant to non-redirected windows including the compositor's. When dealing with a redirected window it seems it would be acceptable to come up with an entirely fake number for all existing extensions that care about vblanks. Somehow tying it to the render/swap-complete of the current compositor seems reasonable.
- * Assuming we have the compositor generating a fake swap interval as above, and the compositor itself is responsible for synchronizing all windows it's responsible for it seems like all the swap group related extensions may just work.
-  * Walking through a hypothetical example of a composited flightgear simulator across multiple monitors seems to add up...
-  * Lets say the compositor has two windows across two monitors (assuming it would exceed render target limits to just have one)
-  * Say flightgear also creates two windows for the same reason and wants to use a swap group to ensure they get presented at the same time.
-  * Assume the compositor is itself also using a swap group to ensure all it's windows get presented at the same time and it drives the video frame period according to it own swap group becoming ready and completing.
-  * If the first flightgear window is drawn too and a swap issued it becomes ready but doesn't actually swap yet (so the compositor wont see it)
-  * The compositor may at this point complete it's current frame and swap and the latest flightgear window won't be shown.
-  * The second flightgear window can be drawn too and a swap issued which makes the group ready so now both windows are swapped and become available to the compositor.
-  * The compositor will pick up the new window contents and since it is itself using a a swap group both windows will be presented in sync.
-
- * I can't see how GLX_OML_swap_method can be supported at all, given that GLX doesn't know ahead of time if any glx window will be later redirected?
-
-== Reference ==
-
-For reference:
-  * [[http://developer.apple.com/mac/library/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_intro/opengl_intro.html|Apple GL Programming Guide]] - covers best practices for GL programmers in Apple's composited environment
-  * [[http://www.ocworkbench.com/2006/articles/DXtweaker/|Overview of triple buffering from a gamer perspective]]
-  * [[http://developer.android.com/guide/index.html|Android Developer's Guide]]
-  * [[http://msdn.microsoft.com/en-us/library/bb173024(VS.85).aspx|DirectX Programmer's Guide]]
diff --git a/ConfigurationForDevelopers.mdwn b/ConfigurationForDevelopers.mdwn
new file mode 100644
index 0000000..98f2347
--- /dev/null
+++ b/ConfigurationForDevelopers.mdwn
@@ -0,0 +1,101 @@
+
+
+# How to make a driver configurable
+
+[[ToDo|ToDo]] 
+
+
+# How to add a new configuration option
+
+Steps: 
+
+1. Define the new option 
+1. Add the option to the common option pool (optional) 
+      1. Add the new option to common/xmlpool/t_options.h 
+      1. Update common/xmlpool/options.h 
+1. Add the new option to `__driConfigOptions` 
+1. Query the option in a convenient place 
+
+## 1. Define the new option
+
+Configuration options are described to the driver and external configuration tools in XML. A set of macros in src/mesa/drivers/dri/common/xmlpool.h helps building such descriptions. 
+
+An option description always starts with `DRI_CONF_OPT_BEGIN` or `DRI_CONF_OPT_BEGIN_V` depending on whether you intend to limit the valid range of option values. These macros have 3 or 4 parameters respecitively: _name_, _type_, _default value_ and optionally _valid range_. 
+
+An option description ends with `DRI_CONF_OPT_END`. Inbetween you can place verbal descriptions of your options in any number of languages. In the simplest case a description looks like this: `DRI_CONF_DESC(lang,"text")`. 
+
+**Note:** Descriptions must be UTF-8 encoded. 
+
+If you are describing enum type options then you start a description with `DRI_CONF_DESC_BEGIN(lang,"text")` and end it with `DRI_CONF_DESC_END`. Inbetween you can place descriptions of different values of the enum option like `DRI_CONF_ENUM(value,"text")`. 
+
+For enum options it is recommended that you also define macros to give option values symbolic names to be used in the driver. 
+
+
+## 2. Add the option to the common option pool (optional)
+
+It is recommended that new options that are likely to be used by more than one driver are added to the common pool of configuration options. This makes maintainance easier and increases the chances of the option description being translated to more languages. 
+
+
+### 2.1. Add the new option to common/xmlpool/t_options.h
+
+Common options are defined in common/xmlpool/t_options.h. This file is not directly used by drivers, it is only a template containing macros with option definitions and their English descriptions. There is a Python script that generates common/xmlpool/options.h by filling in all available translations. 
+
+You add an option by defining a macro that expands to the entire option description as outlined in the previous section. In order to get your option description translated to other languages, translatable strings must be wrapped in `gettext(...)`. You may choose to make the default value a parameter of this macro so that the driver can choose an appropriate default value. For some options it may also make sense to make the valid range of values a parameter. 
+
+
+### 2.2. Update common/xmlpool/options.h
+
+Option definitions in t_options.h are not directly available to drivers. You need to update common/xmlpool/options.h. This is done automatically by running `make` in common/xmlpool. The actual work is done by a Python script, so you need Python installed on your system. 
+
+Now the option will have only an English description. It's the translators job to update the translations. If your native language is not English then you may want to add a translation for your native language yourself. See Section _How to translate option descriptions_ below for details. 
+
+Finally you should commit the new common/xmlpool/t_options.h and common/xmlpool/options.h to CVS. 
+
+
+## 3. Add the new option to __driConfigOptions
+
+In order to inform the driver and external configuration tools about the new option it has to be added to the XML document that advertises the driver's configuration options. It is stored in the global variable `__driConfigOptions` which is usually found in _driver__screen.c or _driver__xmesa.c. 
+
+If you added the option to the common pool of options then you just use the macro defined there. Otherwise you fill in the entire option description here. Related options are grouped in sections in `__driConfigOptions`. Either choose an appropriate section or add a new one if the new options doesn't fit in an existing one. 
+
+Finally, don't forget to increment the value of `__driNConfigOptions` after adding a new option. If you do, the driver will output an error message that reminds you. 
+
+
+## 4. Query the option in a convenient place
+
+Now you can query the option value. This must happen after `driParseOptionInfo` and `driParseConfigFiles` have been called. This means that you can't query an option before context creation. There are three functions `driQueryOption[bif]` for querying options for boolean, integer and floating point options respectively. Enum options are queried like integer options. 
+
+The query functions take two arguments, a _pointer to the option cache_ in the driver's context record and the _name_ of the option to be queried as a string. If you need the option value very frequently then it is best to query the option once during context creation and store its value in the driver's context record. 
+
+If you try to query an option that is not available or has a different type then an assertion fails. Therefore common code that is linked to different drivers should first check if an option is really available. This is done with `driCheckOption`. It takes three arguments, a _pointer to the option cache_, the _option name_ and the _type_. It returns a boolean indicating if an option with matching name and type is available. 
+
+
+# How to translate option descriptions
+
+Option descriptions in the common option pool in common/xmlpool are managed by GNU gettext. This should make it easy to manage translations even for translators without programming experience. There is one _.po_-file for each language for which there is a translation. If there is a translation for your language and you just want to update it for new or changed options or fix a typo somewhere, you can skip the next section and continue with _Updating existing translations_. Otherwise read on here. 
+
+
+## Adding new translations
+
+The Makefile common/xmlpool/Makefile is used to manage translations of option descriptions. Near the start of the file, below a longish comment with instructions, there is a variable definition looking like this: 
+
+
+[[!format txt """
+POS=de.po
+"""]]
+... and hopefully many more languages soon. Add a new _.po_-file for your language here. For example, if you want to make a french translation, add `fr.po`: 
+
+
+[[!format txt """
+POS=de.po fr.po
+"""]]
+
+## Updating existing translations
+
+Run `make po` in common/xmlpool. This will update existing _.po_-files from common/xmlpool/t_options.h or initialize new ones for added languages. Now you can edit the _.po_-file for your language, fixing fuzzy translations or translating new options. I'm assuming that you're familiar with GNU gettext and the _.po_-file syntax. 
+
+When you're done, save the file and run `make` in common/xmlpool. This will update common/xmlpool/options.h with new translations. Finally you can recompile the DRI drivers. After that they will contain option descriptions with your updated translations. When you run `DriConf` in the right locale you should see your updated option descriptions. 
+
+If you have CVS write access, you can commit your updated _.po_-file and common/xmlpool/options.h to CVS. Otherwise send the _.po_-file to [[dri-devel@lists.sourceforge.net|mailto:dri-devel@lists.sourceforge.net]] and someone will take care of updating it in CVS. 
+
+-- [[FelixKuehling|FelixKuehling]] 
diff --git a/ConfigurationForDevelopers.moin b/ConfigurationForDevelopers.moin
deleted file mode 100644
index 9dd3f68..0000000
--- a/ConfigurationForDevelopers.moin
+++ /dev/null
@@ -1,90 +0,0 @@
-= How to make a driver configurable =
-
-ToDo
-
-= How to add a new configuration option =
-
-Steps:
-
- 1. Define the new option
- 2. Add the option to the common option pool (optional)
-   1. Add the new option to common/xmlpool/t_options.h
-   2. Update common/xmlpool/options.h
- 3. Add the new option to {{{__driConfigOptions}}}
- 4. Query the option in a convenient place
-
-== 1. Define the new option ==
-
-Configuration options are described to the driver and external configuration tools in XML. A set of macros in src/mesa/drivers/dri/common/xmlpool.h helps building such descriptions.
-
-An option description always starts with {{{DRI_CONF_OPT_BEGIN}}} or {{{DRI_CONF_OPT_BEGIN_V}}} depending on whether you intend to limit the valid range of option values. These macros have 3 or 4 parameters respecitively: ''name'', ''type'', ''default value'' and optionally ''valid range''.
-
-An option description ends with {{{DRI_CONF_OPT_END}}}. Inbetween you can place verbal descriptions of your options in any number of languages. In the simplest case a description looks like this: {{{DRI_CONF_DESC(lang,"text")}}}.
-
-'''Note:''' Descriptions must be UTF-8 encoded.
-
-If you are describing enum type options then you start a description with {{{DRI_CONF_DESC_BEGIN(lang,"text")}}} and end it with {{{DRI_CONF_DESC_END}}}. Inbetween you can place descriptions of different values of the enum option like {{{DRI_CONF_ENUM(value,"text")}}}.
-
-For enum options it is recommended that you also define macros to give option values symbolic names to be used in the driver.
-
-== 2. Add the option to the common option pool (optional) ==
-
-It is recommended that new options that are likely to be used by more than one driver are added to the common pool of configuration options. This makes maintainance easier and increases the chances of the option description being translated to more languages.
-
-=== 2.1. Add the new option to common/xmlpool/t_options.h ===
-
-Common options are defined in common/xmlpool/t_options.h. This file is not directly used by drivers, it is only a template containing macros with option definitions and their English descriptions. There is a Python script that generates common/xmlpool/options.h by filling in all available translations.
-
-You add an option by defining a macro that expands to the entire option description as outlined in the previous section. In order to get your option description translated to other languages, translatable strings must be wrapped in {{{gettext(...)}}}. You may choose to make the default value a parameter of this macro so that the driver can choose an appropriate default value. For some options it may also make sense to make the valid range of values a parameter.
-
-=== 2.2. Update common/xmlpool/options.h ===
-
-Option definitions in t_options.h are not directly available to drivers. You need to update common/xmlpool/options.h. This is done automatically by running {{{make}}} in common/xmlpool. The actual work is done by a Python script, so you need Python installed on your system.
-
-Now the option will have only an English description. It's the translators job to update the translations. If your native language is not English then you may want to add a translation for your native language yourself. See Section ''How to translate option descriptions'' below for details.
-
-Finally you should commit the new common/xmlpool/t_options.h and common/xmlpool/options.h to CVS.
-
-== 3. Add the new option to __driConfigOptions ==
-
-In order to inform the driver and external configuration tools about the new option it has to be added to the XML document that advertises the driver's configuration options. It is stored in the global variable {{{__driConfigOptions}}} which is usually found in ''driver''_screen.c or ''driver''_xmesa.c.
-
-If you added the option to the common pool of options then you just use the macro defined there. Otherwise you fill in the entire option description here. Related options are grouped in sections in {{{__driConfigOptions}}}. Either choose an appropriate section or add a new one if the new options doesn't fit in an existing one.
-
-Finally, don't forget to increment the value of {{{__driNConfigOptions}}} after adding a new option. If you do, the driver will output an error message that reminds you.
-
-== 4. Query the option in a convenient place ==
-
-Now you can query the option value. This must happen after {{{driParseOptionInfo}}} and {{{driParseConfigFiles}}} have been called. This means that you can't query an option before context creation. There are three functions {{{driQueryOption[bif]}}} for querying options for boolean, integer and floating point options respectively. Enum options are queried like integer options.
-
-The query functions take two arguments, a ''pointer to the option cache'' in the driver's context record and the ''name'' of the option to be queried as a string. If you need the option value very frequently then it is best to query the option once during context creation and store its value in the driver's context record.
-
-If you try to query an option that is not available or has a different type then an assertion fails. Therefore common code that is linked to different drivers should first check if an option is really available. This is done with {{{driCheckOption}}}. It takes three arguments, a ''pointer to the option cache'', the ''option name'' and the ''type''. It returns a boolean indicating if an option with matching name and type is available.
-
-= How to translate option descriptions =
-
-Option descriptions in the common option pool in common/xmlpool are managed by GNU gettext. This should make it easy to manage translations even for translators without programming experience. There is one ''.po''-file for each language for which there is a translation. If there is a translation for your language and you just want to update it for new or changed options or fix a typo somewhere, you can skip the next section and continue with ''Updating existing translations''. Otherwise read on here.
-
-== Adding new translations ==
-
-The Makefile common/xmlpool/Makefile is used to manage translations of option descriptions. Near the start of the file, below a longish comment with instructions, there is a variable definition looking like this:
-
-{{{
-POS=de.po
-}}}
-
-... and hopefully many more languages soon. Add a new ''.po''-file for your language here. For example, if you want to make a french translation, add {{{fr.po}}}:
-
-{{{
-POS=de.po fr.po
-}}}
-
-== Updating existing translations ==
-
-Run {{{make po}}} in common/xmlpool. This will update existing ''.po''-files from common/xmlpool/t_options.h or initialize new ones for added languages. Now you can edit the ''.po''-file for your language, fixing fuzzy translations or translating new options. I'm assuming that you're familiar with GNU gettext and the ''.po''-file syntax.
-
-When you're done, save the file and run {{{make}}} in common/xmlpool. This will update common/xmlpool/options.h with new translations. Finally you can recompile the DRI drivers. After that they will contain option descriptions with your updated translations. When you run {{{DriConf}}} in the right locale you should see your updated option descriptions.
-
-If you have CVS write access, you can commit your updated ''.po''-file and common/xmlpool/options.h to CVS. Otherwise send the ''.po''-file to [[mailto:dri-devel@lists.sourceforge.net|dri-devel@lists.sourceforge.net]] and someone will take care of updating it in CVS.
-
--- FelixKuehling
diff --git a/ConfigurationInfrastructure.moin b/ConfigurationInfrastructure.mdwn
index 69bbccb..32762a7 100644
--- a/ConfigurationInfrastructure.moin
+++ b/ConfigurationInfrastructure.mdwn
@@ -1,65 +1,72 @@
-= Configuration Infrastructure =
-
-== Introduction ==
-
-Since 9th October 2003 the new configuration infrastructure is part of the main trunk of the DRI CVS repository. It introduces a consistent mechanism for configuring all DRI drivers using an XML-based configuration file. It further provides an interface for configuration GUIs to find out about the ConfigurationOptions of installed drivers. Option descriptions are available in multiple languages. The first GUI configuration tool that uses the new infrastructure is DriConf.
-
-DriConf is by far the easiest and most user-friendly way to edit the configuration. On the page ConfigurationOptions you find more detailed descriptions of common configuration options. If instead you prefer to edit the configuration file with a text editor, then read on. ConfigurationForDevelopers describes how to make drivers configurable and how to add new options to drivers. For those interested in the technical details there is a [[http://dri.freedesktop.org/~fxkuehl/driconf/dri_config_design_rev4.html|design document]].
-
-== System-wide and per-user configuration files ==
-
-There is a system-wide configuration file /etc/drirc that applies to all users. Those settings can be overridden by a user's configuration file $HOME/.drirc. Both files have exactly the same format.
-
-== Example for a single-headed setup ==
-
-Let's start with an example of a configuration file for a single-headed setup, where you have only one graphics card and one monitor installed.
-
-{{{
-<driconf>
-   <device screen="0" driver="radeon">
-      <application name="all">
-         <!-- Always synchronize with vertical refresh to avoid tearing -->
-         <option name="vblank_mode" value="3"/>
-      </application>
-      <application name="glxgears" executable="glxgears">
-         <!-- glxgears should not synchronize with vertical refresh, show full fps -->
-         <option name="vblank_mode" value="0"/>
-      </application>
-      <application name="tuxracer" executable="tuxracer">
-         <!-- Tuxrace has some artifacts with hardware TCL -->
-         <option name="tcl_mode" value="0"/>
-      </application>
-   </device>
-</driconf>
-}}}
-
-Comments start with <!-- and end with -->. Indentation is optional but makes the configuration file more readable. Each configuration file starts with <driconf> and ends with </driconf>. 
-
-== Devices ==
-
-Between the <driconf> and </driconf> tags there can be a device section for each graphics device you have installed in your system. In the example there is only one device section. The opening tag contains two attributes "screen" and "driver". They are used to identify the device that this section applies to. In most cases only one of them should be necessary but specifying both doesn't hurt. "screen" gives the X screen number. On a single-headed display this is always 0. "driver" specifies the name of the 3D driver. At the time of this writing the following drivers support the configuration infrastructure:
-
- * mga (Matrox cards)
- * r128 (ATI Rage 128 and some Mobility chips)
- * radeon (ATI Radeon 7000, 7200, 7500 and some Mobility chips)
- * r200 (ATI Radeon 8500, 9000, 9200)
-
-If you are not sure which driver is the correct one for you, then you can find out with xdriinfo. If you type xdriinfo in the shell, you will get a list of all direct rendering capable screens with their drivers.
-
-== Applications ==
-
-In each device section there can be any number of application sections that contain the configuration of different applications. The opening tag can contain the attributes "name" and "executable". The name is merely a descriptive string. If no executable attribute is present then the section applies to all applications. Otherwise the section only applies to the specified application.
-
-'''Caution:''' The executable that you specify in the executable attribute may differ from what you type in the shell. For instance the command q3demo is a shell script. The actual executable that runs the game is called q3demo.x86.
-
-== Options ==
-
-Options are specified as empty element tags. This is indicated by the slash before the closing bracket. They have two attributes, "name" and "value". Their meaning should be obvious. The set of available options, their types and ranges of valid values depend on the driver and are subject to changes. Hopefully the most common change will be the addition of new options. But sometimes options may be removed or replaced by different options with different semantics.
-
-An up-to-date description of available options can be obtained with the program xdriinfo, which is included in the DRI CVS repository and in recent binary snapshots. In the shell type
-
-{{{
-xdriinfo options <screen number or driver name>
-}}}
-
-You will see a rather long XML document that formally describes all available options and also includes verbal descriptions in multiple languages. This format is not exactly easily readable. Its main purpose is to be automatically processed by configuration GUIs. But it may also serve as a reference to the "power user".
+
+
+# Configuration Infrastructure
+
+
+## Introduction
+
+Since 9th October 2003 the new configuration infrastructure is part of the main trunk of the DRI CVS repository. It introduces a consistent mechanism for configuring all DRI drivers using an XML-based configuration file. It further provides an interface for configuration GUIs to find out about the [[ConfigurationOptions|ConfigurationOptions]] of installed drivers. Option descriptions are available in multiple languages. The first GUI configuration tool that uses the new infrastructure is [[DriConf|DriConf]]. 
+
+[[DriConf|DriConf]] is by far the easiest and most user-friendly way to edit the configuration. On the page [[ConfigurationOptions|ConfigurationOptions]] you find more detailed descriptions of common configuration options. If instead you prefer to edit the configuration file with a text editor, then read on. [[ConfigurationForDevelopers|ConfigurationForDevelopers]] describes how to make drivers configurable and how to add new options to drivers. For those interested in the technical details there is a [[design document|http://dri.freedesktop.org/~fxkuehl/driconf/dri_config_design_rev4.html]]. 
+
+
+## System-wide and per-user configuration files
+
+There is a system-wide configuration file /etc/drirc that applies to all users. Those settings can be overridden by a user's configuration file $HOME/.drirc. Both files have exactly the same format. 
+
+
+## Example for a single-headed setup
+
+Let's start with an example of a configuration file for a single-headed setup, where you have only one graphics card and one monitor installed. 
+
+
+[[!format txt """
+<driconf>
+   <device screen="0" driver="radeon">
+      <application name="all">
+         <!-- Always synchronize with vertical refresh to avoid tearing -->
+         <option name="vblank_mode" value="3"/>
+      </application>
+      <application name="glxgears" executable="glxgears">
+         <!-- glxgears should not synchronize with vertical refresh, show full fps -->
+         <option name="vblank_mode" value="0"/>
+      </application>
+      <application name="tuxracer" executable="tuxracer">
+         <!-- Tuxrace has some artifacts with hardware TCL -->
+         <option name="tcl_mode" value="0"/>
+      </application>
+   </device>
+</driconf>
+"""]]
+Comments start with <!-- and end with -->. Indentation is optional but makes the configuration file more readable. Each configuration file starts with <driconf> and ends with </driconf>.  
+
+
+## Devices
+
+Between the <driconf> and </driconf> tags there can be a device section for each graphics device you have installed in your system. In the example there is only one device section. The opening tag contains two attributes "screen" and "driver". They are used to identify the device that this section applies to. In most cases only one of them should be necessary but specifying both doesn't hurt. "screen" gives the X screen number. On a single-headed display this is always 0. "driver" specifies the name of the 3D driver. At the time of this writing the following drivers support the configuration infrastructure: 
+
+* mga (Matrox cards) 
+* r128 (ATI Rage 128 and some Mobility chips) 
+* radeon (ATI Radeon 7000, 7200, 7500 and some Mobility chips) 
+* r200 (ATI Radeon 8500, 9000, 9200) 
+If you are not sure which driver is the correct one for you, then you can find out with xdriinfo. If you type xdriinfo in the shell, you will get a list of all direct rendering capable screens with their drivers. 
+
+
+## Applications
+
+In each device section there can be any number of application sections that contain the configuration of different applications. The opening tag can contain the attributes "name" and "executable". The name is merely a descriptive string. If no executable attribute is present then the section applies to all applications. Otherwise the section only applies to the specified application. 
+
+**Caution:** The executable that you specify in the executable attribute may differ from what you type in the shell. For instance the command q3demo is a shell script. The actual executable that runs the game is called q3demo.x86. 
+
+
+## Options
+
+Options are specified as empty element tags. This is indicated by the slash before the closing bracket. They have two attributes, "name" and "value". Their meaning should be obvious. The set of available options, their types and ranges of valid values depend on the driver and are subject to changes. Hopefully the most common change will be the addition of new options. But sometimes options may be removed or replaced by different options with different semantics. 
+
+An up-to-date description of available options can be obtained with the program xdriinfo, which is included in the DRI CVS repository and in recent binary snapshots. In the shell type 
+
+
+[[!format txt """
+xdriinfo options <screen number or driver name>
+"""]]
+You will see a rather long XML document that formally describes all available options and also includes verbal descriptions in multiple languages. This format is not exactly easily readable. Its main purpose is to be automatically processed by configuration GUIs. But it may also serve as a reference to the "power user". 
diff --git a/ConfigurationOptions.moin b/ConfigurationOptions.mdwn
index b18a71d..5ea9c99 100644
--- a/ConfigurationOptions.moin
+++ b/ConfigurationOptions.mdwn
@@ -1,101 +1,98 @@
-= Common Configuration Options =
- 
-Below you find detailed descriptions of common configuration options. Along with the documentation of each option you find the name and the numeric option values to be used if you edit the configuration file in a text editor.
- 
-== Performance Options ==
- 
-=== TCL mode (Transformation, Clipping, Lighting) ===
- 
- * Name: tcl_mode
- * Drivers: r200, radeon
- 
-This option defines whether a hardware TCL-unit is used and how the implementation uses it. Four settings are supported:
- 
- 0 = Software<<BR>>
- 1 = TCL stage in MESA pipeline<<BR>>
- 2 = Bypass MESA's pipeline<<BR>>
- 3 = Bypass MESA's pipeline with state-based code generation
- 
-The default setting is 3 which results in best performance. If you experience rendering errors try a lower setting and report a bug, stating which setting results in what kind of rendering problems.
- 
-'''Note:''' One well known problem is "depth fighting" observed in e.g. Tux Racer. We believe that the application is broken in this case. Set tcl_mode to 0 (Software) as a workaround.
- 
-'''Note 2:''' As usual before reporting a bug please make sure that it is not a known problem.
- 
-=== Frame Throttling ===
- 
- * Name: fthrottle_mode
- * Drivers: r200, radeon
- 
-This option defines what happens, if the application submits rendering commands faster than the graphics engine can execute them. Without limitations the graphics engine could be several seconds behind the application's command stream. In an interactive application this is not acceptable. Imagine a simulation in which you turn the steering wheel and it takes one second before your car reacts. Therefore the application is forced to wait if it gets more than one frame ahead of the graphics engine. This waiting can be done in three different ways:
- 
- 0 = Busy waiting<<BR>>
- 1 = Usleeps<<BR>>
- 2 = Software IRQs
- 
-The default setting (Software IRQs) should be fine for most users. Usleeps can reduce the frame rate. Busy waiting doesn't reduce the frame rate but wastes CPU cycles in busy waiting loops (as the name indicates).
- 
-=== Synchronization with vertical refresh (swap intervals) ===
- 
- * Name: vblank_mode
- * Drivers: mga, r128, r200, radeon
- 
-Synchronization with the vertical refresh can avoid visual "tearing" with fast motion. At the same time it limits the frame rate to (a fraction of) the vertical refresh rate. Applications can set a "swap interval" which means that buffer swaps occur no earlier than n vertical blanks after the previous swap. With this option you can disable swap intervals, choose a default swap interval of 0 or 1 or you can force the application to always wait for a vertical blank on every buffer swap:
- 
- 0 = Never, FPS rulez!<<BR>>
- 1 = Application preference, default interval 0<<BR>>
- 2 = Application preference, default interval 1<<BR>>
- 3 = Application preference, always synchronize with refresh
- 
-== Image Quality Options ==
- 
-=== Texture color depth ===
- 
- * Name: texture_depth
- * Drivers: mga, r128, r200, radeon
- 
-This option influences the choice of the internal texture format based on the application-supplied texture data and the application's preference for the interal texture format.
- 
- 0 = Prefer frame buffer color depth<<BR>>
- 1 = Prefer 32 bits<<BR>>
- 2 = Prefer 16 bits<<BR>>
- 3 = Force 16 bits
- 
-The first three settings affect the choice only if the application doesn't specify an internal texture color depth. The default setting 0 will prefer the same color depth as the frame buffer. The last setting forces 16 bit internal color depth even if the application requests a higher color depth.
- 
-There is a trade-off between image quality and performance here. A higher color depth means higher demands for memory size and bandwidth. Low texture color depth is most noticable if your application has textures with smooth gradients on them.
- 
-=== Default color reduction method ===
- 
- * Name: color_reduction
- * Drivers: mga, r128, r200, radeon
- 
-On a 16 bit frame buffer color reduction can take place in different ways. Colors can be rounded or truncated which means that if there is no perfect match for the desired color you will see a color that comes more or less close to it. This leads to visible edges in smooth gradients. The alternative color dithering can lead to large improvements of the visual quality. However, it may also introduce noise or a visible dithering pattern. The best choice may depend on the application.
- 
- 0 = Round or truncate<<BR>>
- 1 = Dither
- 
-=== Round or truncate colors ===
- 
- * Name: round_mode
- * Drivers: r128, r200, radeon
- 
-If colors are rounded then this option decides how the displayed color is chosen if there is no perfect match for the desired color.
- 
- 0 = Truncate<<BR>>
- 1 = Round
- 
-Truncate will round each color component to the closest value that is still lower than the desired value. Round will choose the closest available value.
- 
-=== Color dithering ===
- 
- * Name: dither_mode
- * Drivers: r128, r200, radeon
- 
-If colors are dithered then this option chooses the dithering algorithm.
- 
- 0 = Horizontal error diffusion<<BR>>
- 1 = Horizontal error diffusion, reset error at line start<<BR>>
- 2 = Ordered 2D dithering
- 
-The default setting 0 tries to compensate the rounding error of one pixel by biasing the rounding of the next pixel in the row. This may lead to a slightly noisy image and may introduce visible vertical patterns. Setting 1 is a variation that resets the error at the beginning of each new row. However, this setting looks broken on my Radeon 7500. Setting 2 uses a static pattern of rounding biases. This avoids the noise observed with setting 0 but the static pattern can be annoying espcially with low resolutions.
+
+
+# Common Configuration Options
+
+Below you find detailed descriptions of common configuration options. Along with the documentation of each option you find the name and the numeric option values to be used if you edit the configuration file in a text editor. 
+
+
+## Performance Options
+
+
+### TCL mode (Transformation, Clipping, Lighting)
+
+* Name: tcl_mode 
+* Drivers: r200, radeon 
+This option defines whether a hardware TCL-unit is used and how the implementation uses it. Four settings are supported: 
+
+* 0 = Software  
+ 1 = TCL stage in MESA pipeline  
+ 2 = Bypass MESA's pipeline  
+ 3 = Bypass MESA's pipeline with state-based code generation 
+The default setting is 3 which results in best performance. If you experience rendering errors try a lower setting and report a bug, stating which setting results in what kind of rendering problems. 
+
+**Note:** One well known problem is "depth fighting" observed in e.g. Tux Racer. We believe that the application is broken in this case. Set tcl_mode to 0 (Software) as a workaround. 
+
+**Note 2:** As usual before reporting a bug please make sure that it is not a known problem. 
+
+
+### Frame Throttling
+
+* Name: fthrottle_mode 
+* Drivers: r200, radeon 
+This option defines what happens, if the application submits rendering commands faster than the graphics engine can execute them. Without limitations the graphics engine could be several seconds behind the application's command stream. In an interactive application this is not acceptable. Imagine a simulation in which you turn the steering wheel and it takes one second before your car reacts. Therefore the application is forced to wait if it gets more than one frame ahead of the graphics engine. This waiting can be done in three different ways: 
+
+* 0 = Busy waiting  
+ 1 = Usleeps  
+ 2 = Software IRQs 
+The default setting (Software IRQs) should be fine for most users. Usleeps can reduce the frame rate. Busy waiting doesn't reduce the frame rate but wastes CPU cycles in busy waiting loops (as the name indicates). 
+
+
+### Synchronization with vertical refresh (swap intervals)
+
+* Name: vblank_mode 
+* Drivers: mga, r128, r200, radeon 
+Synchronization with the vertical refresh can avoid visual "tearing" with fast motion. At the same time it limits the frame rate to (a fraction of) the vertical refresh rate. Applications can set a "swap interval" which means that buffer swaps occur no earlier than n vertical blanks after the previous swap. With this option you can disable swap intervals, choose a default swap interval of 0 or 1 or you can force the application to always wait for a vertical blank on every buffer swap: 
+
+* 0 = Never, FPS rulez!  
+ 1 = Application preference, default interval 0  
+ 2 = Application preference, default interval 1  
+ 3 = Application preference, always synchronize with refresh 
+
+## Image Quality Options
+
+
+### Texture color depth
+
+* Name: texture_depth 
+* Drivers: mga, r128, r200, radeon 
+This option influences the choice of the internal texture format based on the application-supplied texture data and the application's preference for the interal texture format. 
+
+* 0 = Prefer frame buffer color depth  
+ 1 = Prefer 32 bits  
+ 2 = Prefer 16 bits  
+ 3 = Force 16 bits 
+The first three settings affect the choice only if the application doesn't specify an internal texture color depth. The default setting 0 will prefer the same color depth as the frame buffer. The last setting forces 16 bit internal color depth even if the application requests a higher color depth. 
+
+There is a trade-off between image quality and performance here. A higher color depth means higher demands for memory size and bandwidth. Low texture color depth is most noticable if your application has textures with smooth gradients on them. 
+
+
+### Default color reduction method
+
+* Name: color_reduction 
+* Drivers: mga, r128, r200, radeon 
+On a 16 bit frame buffer color reduction can take place in different ways. Colors can be rounded or truncated which means that if there is no perfect match for the desired color you will see a color that comes more or less close to it. This leads to visible edges in smooth gradients. The alternative color dithering can lead to large improvements of the visual quality. However, it may also introduce noise or a visible dithering pattern. The best choice may depend on the application. 
+
+* 0 = Round or truncate  
+ 1 = Dither 
+
+### Round or truncate colors
+
+* Name: round_mode 
+* Drivers: r128, r200, radeon 
+If colors are rounded then this option decides how the displayed color is chosen if there is no perfect match for the desired color. 
+
+* 0 = Truncate  
+ 1 = Round 
+Truncate will round each color component to the closest value that is still lower than the desired value. Round will choose the closest available value. 
+
+
+### Color dithering
+
+* Name: dither_mode 
+* Drivers: r128, r200, radeon 
+If colors are dithered then this option chooses the dithering algorithm. 
+
+* 0 = Horizontal error diffusion  
+ 1 = Horizontal error diffusion, reset error at line start  
+ 2 = Ordered 2D dithering 
+The default setting 0 tries to compensate the rounding error of one pixel by biasing the rounding of the next pixel in the row. This may lead to a slightly noisy image and may introduce visible vertical patterns. Setting 1 is a variation that resets the error at the beginning of each new row. However, this setting looks broken on my Radeon 7500. Setting 2 uses a static pattern of rounding biases. This avoids the noise observed with setting 0 but the static pattern can be annoying espcially with low resolutions. 
diff --git a/Contributing.mdwn b/Contributing.mdwn
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/Contributing.mdwn
diff --git a/Contributing.moin b/Contributing.moin
deleted file mode 100644
index d9db1ab..0000000
--- a/Contributing.moin
+++ /dev/null
@@ -1 +0,0 @@
-#REDIRECT Development
diff --git a/CurrentDevelopers.mdwn b/CurrentDevelopers.mdwn
new file mode 100644
index 0000000..08c9ef9
--- /dev/null
+++ b/CurrentDevelopers.mdwn
@@ -0,0 +1,48 @@
+
+
+### Current DRI developers
+
+* [[AlanHourihane|AlanHourihane]] 
+* [[AlexDeucher|AlexDeucher]] 
+* [[AllenAkin|AllenAkin]] 
+* [[BrianPaul|BrianPaul]] 
+* [[DaveAirlie|DaveAirlie]] 
+* [[EricAnholt|EricAnholt]] 
+* [[FelixKuehling|FelixKuehling]] 
+* [[IanRomanick|IanRomanick]] 
+* [[JonSmirl|JonSmirl]] 
+* [[JoseFonseca|JoseFonseca]] 
+* [[KeithWhitwell|KeithWhitwell]] 
+* [[LeifDelgass|LeifDelgass]] 
+* [[MichelDaenzer|MichelDaenzer]] 
+* [[VilleSyrjala|VilleSyrjala]] 
+
+### Former DRI developers
+
+(Listed as developers at sourceforge.net but haven't requested freedesktop.org accounts) 
+
+* [[AndreasKarrenbauer|AndreasKarrenbauer]] 
+* [[DaryllStrauss|DaryllStrauss]] 
+* [[FrankEarl|FrankEarl]] 
+* [[GarethHughes|GarethHughes]] 
+* [[JeffHartmann|JeffHartmann]] 
+* [[JensOwen|JensOwen]] 
+* [[KevinMartin|KevinMartin]] 
+* [[MaxLingua|MaxLingua]] 
+* [[RikFaith|RikFaith]] 
+* [[SuzyDeffeyes|SuzyDeffeyes]] 
+* [[TimSmith|TimSmith]] 
+
+### Contributors
+
+* [[FrankWorsley|FrankWorsley]] 
+* [[LiamSmit|LiamSmit]] 
+
+### Framework Developers and Contributors
+
+* [[SourceForge|SourceForge]].net 
+* [[OpenDesktop|OpenDesktop]].org 
+* [[LiamSmit|LiamSmit]] (web design) 
+* [[AlexanderStohr|AlexanderStohr]] (mailing list admin) 
+* [[MikeHarris|MikeHarris]] (mailing list admin) 
+* [[MichelDaenzer|MichelDaenzer]] (mailing list admin) 
+\ No newline at end of file
diff --git a/CurrentDevelopers.moin b/CurrentDevelopers.moin
deleted file mode 100644
index cd3d510..0000000
--- a/CurrentDevelopers.moin
+++ /dev/null
@@ -1,41 +0,0 @@
-=== Current DRI developers ===
- * AlanHourihane
- * AlexDeucher
- * AllenAkin
- * BrianPaul
- * DaveAirlie
- * EricAnholt
- * FelixKuehling
- * IanRomanick
- * JonSmirl
- * JoseFonseca
- * KeithWhitwell
- * LeifDelgass
- * MichelDaenzer
- * VilleSyrjala
-
-=== Former DRI developers ===
-(Listed as developers at sourceforge.net but haven't requested freedesktop.org accounts)
- * AndreasKarrenbauer
- * DaryllStrauss
- * FrankEarl
- * GarethHughes
- * JeffHartmann
- * JensOwen
- * KevinMartin
- * MaxLingua
- * RikFaith
- * SuzyDeffeyes
- * TimSmith
-
-=== Contributors ===
- * FrankWorsley
- * LiamSmit
-
-=== Framework Developers and Contributors ===
- * SourceForge.net
- * OpenDesktop.org
- * LiamSmit (web design)
- * AlexanderStohr (mailing list admin)
- * MikeHarris (mailing list admin)
- * MichelDaenzer (mailing list admin)
diff --git a/CvsBranches.mdwn b/CvsBranches.mdwn
new file mode 100644
index 0000000..a9f9dcd
--- /dev/null
+++ b/CvsBranches.mdwn
@@ -0,0 +1,146 @@
+
+
+# DRI CVS Branches
+
+We're using CVS quite heavily and have a fairly structured layout of the repository. This document should explain how we're using CVS and what material is stored where. 
+
+When you do a normal checkout of a CVS tree, you get a default set of files. This set of files is called the trunk. CVS also supports a concept called branches. Branches are named sections of the CVS tree that diverge from the trunk code. 
+
+In our repository, the trunk will always be the latest code that is believed to be stable and work. Changes made in any of the branches will be merged into the trunk when they are deemed ready. As a developer who isn't writing code you should normally be doing your checkouts from the trunk. Each developer who is writing new code in the tree will be working in a branch. They will be doing frequent checkins to their branch. Because of this it is likely that the code they check in may not work at any given point in time. They do frequent checkins to have saved copies of their work and so that other developers who might want to examine the code can do so. It should be a rare case that any developer looks at another developers branch. 
+
+Since there are several projects underway in the same source tree, there are a number of branches under development.  Most of them are documented here. 
+
+
+## Current Branches
+
+These are branches under active development. 
+trunk
+: This is the main branch of working code. Generally, only bug fixes get checked into this branch. Major development is done on other branches. As of February 2003, the trunk is based on Mesa 5.0.x. 
+
+cle266-0-0-1-branch
+: This is the branch for integration of the VIA CLE266 driver. 
+
+i865-agp-0-1-branch
+: This is the branch for i865 driver development. 
+
+
+
+## Sleeping Branches
+
+These are branches that were active at one time but that haven't seen action in a while.  They probably need work to get them working again. 
+gamma-2-0-0-branch
+: This is the current branch for the 3DLabs Oxygen GMX2000 development. 
+
+s3virge-0-0-1-branch
+: This is the development branch for a from-scratch S3 Virge driver. 
+
+tdlabs-0-0-1-branch
+: This is the development branch for 3Dlabs Permedia/2/3 chips. 
+
+
+As of right now, these branches need to account for at least the following changes before they can work in the trunk: 
+
+* [[DRM reorganization|http://marc.theaimsgroup.com/?l=dri-devel&m=107949788914600&w=2]] [[driinterface branch merge|http://marc.theaimsgroup.com/?l=dri-devel&m=107646323812972&w=2]] [[newmesa branch merge|http://marc.theaimsgroup.com/?l=dri-devel&m=107098273417272&w=2]] 
+
+## Merged Branches
+
+These branches have been merged to the trunk.  They are no longer interesting.  All development relevant to these is now taking place on the trunk. 
+ati-4-0-0-branch, ati-4-0-1-branch, ati-4-1-0-branch
+: The initial ATI Rage 128 driver development was carried out on these branches. 
+
+ati-4-1-1-branch
+: This was the branch for the enhanced ATI Rage 128/Rage 128 Pro driver development. 
+
+ati-5-0-0-branch
+: This was the branch for the latest ATI Radeon and Rage 128/128 Pro development. 
+
+bsd-4-0-0-branch
+: BSD support, follow-on to bsd-3-0-0-branch. 
+
+bsd-3-0-0-branch
+: This branch contains changes to support FreeBSD 4.0 and to port the Linux mga driver. 
+
+bsd-1-0-0-branch
+: This branch contained a variety of changes for FreeBSD support. 
+
+config-0-0-1-branch
+: This was a branch for creation of a general DRI configuration mechanism to replace card-specific environment variables. 
+
+dispatch-0-0-1-branch
+: This is the branch for the Mesa dynamic dispatching work. 
+
+glxmisc-1-0-0-branch
+: This branch fixed a variety of GLX-related issues such as visual configuration. 
+
+glxmisc-2-0-0-branch
+: This branch overhauled the XMesa/DRI client-side code; XMesa is no longer used. 
+
+glxmisc-3-0-0-branch
+: This branch fixed several DRI, DRM and GLX bugs, added version checking to the DRI components, fixed potential memory leaks in DRI drivers, and updated to Mesa 3.3. 
+
+m3-0-0-1-branch
+: This branch contained changes to support the ATI Rage 128 Mobility (M3/M4). 
+
+mach64-0-0-7-branch
+: This was the branch for the ATI Rage Pro driver development. 
+
+mga-0-0-1-branch, mga-0-0-2-branch, mga-0-0-3-branch
+: These branches housed the development of the Matrox G200/G400 and the Intel i810 drivers. 
+
+r200-0-1-branch
+: This was the development branch for the Radeon R200 driver. 
+
+radeon-1-0-0-branch
+: This branch contained support the ATI Radeon development. 
+
+savage-1_0_0-branch, savage-2-0-0-branch
+: This is the branch for integration of the VIA/S3 Savage driver. 
+
+sse-1-0-0-branch
+: This was an experimental branch, looking at optimizations of both core Mesa and the hardware drivers for the Pentium III processor. 
+
+tcl-0-0-branch
+: This branch hosted the Radeon Transform/Clip/Lighting works. 
+
+tdfx-1-1
+: This was the experimental branch for the 3dfx Voodoo Banshee/Voodoo3 development. 
+
+tdfx-2-0-branch
+: This was the experimental branch for the 3dfx Voodoo4/Voodoo5 development. 
+
+tdfx-2-1-branch
+: tdfx development for SLI and T-buffers was being done on this branch. 
+
+tdfx-3-0-0-branch
+: This branch implemented the tdfx driver overhaul, initiated by Gareth. 
+
+texmem-0-0-1
+: Texture memory management improvements. 
+
+
+
+## Abandoned Branches
+
+These branches have been abandoned for one reason or another.  No development is taking place on these. 
+dmx-0-1-branch
+: 
+This is the Distributed Xinerama branch. The DMX project has its own [[SourceForge|SourceForge]] CVS tree now. See [[the DMX homepage|http://dmx.sourceforge.net/]] . 
+
+
+mesa-3-5-branch
+: This branch was for Mesa 3.5 development, including porting of the DRI drivers to Mesa 3.5. 
+
+mesa-4-0-4-branch
+: DRI based on Mesa 4.0.4, used during the XFree86 4.2.99.x series so Mesa 5.0 work could continue on trunk and stable fixes get merged. 
+
+ppc-1-0-0-branch
+: This branch was dedicated to porting the DRI to Linux (and maybe other OSs) on PowerPC processors. PPC support for ATI Rage128 chips has finally hit the trunk with the merge of the ati-pcigart-1-0-0-branch. 
+
+smt-0-0-1-branch, smt-0-0-2-branch
+: 
+This was the branch for the shared memory transport work.  SMT was completed in 1 March 2000, and was not found to provide more than a 10% performance increase using modern graphics cards on modern machines. This level of performance improvement does not justify inclusion of the SMT patches into the main XFree86 distribution, so this branch has been abandoned. A complete discussion is available on the [[SharedMemoryTransport|SharedMemoryTransport]] page; [[Patches|http://www.precisioninsight.com/smt/smt-3.9.18.diff.gz]] (against XFree86 3.9.18) used to exist... 
+
+
+video-1-0-0-branch
+: This branch was for experimental video work that is no longer in progress. There's nothing interesting on this branch. 
+
diff --git a/CvsBranches.moin b/CvsBranches.moin
deleted file mode 100644
index b38c62b..0000000
--- a/CvsBranches.moin
+++ /dev/null
@@ -1,106 +0,0 @@
-= DRI CVS Branches =
-
-We're using CVS quite heavily and have a fairly structured layout of the repository. This document should explain how we're using CVS and what material is stored where.
-
-When you do a normal checkout of a CVS tree, you get a default set of files. This set of files is called the trunk. CVS also supports a concept called branches. Branches are named sections of the CVS tree that diverge from the trunk code.
-
-In our repository, the trunk will always be the latest code that is believed to be stable and work. Changes made in any of the branches will be merged into the trunk when they are deemed ready. As a developer who isn't writing code you should normally be doing your checkouts from the trunk. Each developer who is writing new code in the tree will be working in a branch. They will be doing frequent checkins to their branch. Because of this it is likely that the code they check in may not work at any given point in time. They do frequent checkins to have saved copies of their work and so that other developers who might want to examine the code can do so. It should be a rare case that any developer looks at another developers branch.
-
-Since there are several projects underway in the same source tree, there are a number of branches under development.  Most of them are documented here.
-
-== Current Branches ==
-
-These are branches under active development.
-
- trunk:: This is the main branch of working code. Generally, only bug fixes get checked into this branch. Major development is done on other branches. As of February 2003, the trunk is based on Mesa 5.0.x.
-
- cle266-0-0-1-branch:: This is the branch for integration of the VIA CLE266 driver.
-
- i865-agp-0-1-branch:: This is the branch for i865 driver development.
-
-== Sleeping Branches ==
-
-These are branches that were active at one time but that haven't seen action in a while.  They probably need work to get them working again.
-
- gamma-2-0-0-branch:: This is the current branch for the 3DLabs Oxygen GMX2000 development.
-
- s3virge-0-0-1-branch:: This is the development branch for a from-scratch S3 Virge driver.
-
- tdlabs-0-0-1-branch:: This is the development branch for 3Dlabs Permedia/2/3 chips.
-
-As of right now, these branches need to account for at least the following changes before they can work in the trunk:
-
- [[http://marc.theaimsgroup.com/?l=dri-devel&m=107949788914600&w=2|DRM reorganization]]
-
- [[http://marc.theaimsgroup.com/?l=dri-devel&m=107646323812972&w=2|driinterface branch merge]]
-
- [[http://marc.theaimsgroup.com/?l=dri-devel&m=107098273417272&w=2|newmesa branch merge]]
-
-== Merged Branches ==
-
-These branches have been merged to the trunk.  They are no longer interesting.  All development relevant to these is now taking place on the trunk.
-
- ati-4-0-0-branch, ati-4-0-1-branch, ati-4-1-0-branch:: The initial ATI Rage 128 driver development was carried out on these branches.
-
- ati-4-1-1-branch:: This was the branch for the enhanced ATI Rage 128/Rage 128 Pro driver development.
-
- ati-5-0-0-branch:: This was the branch for the latest ATI Radeon and Rage 128/128 Pro development.
-
- bsd-4-0-0-branch:: BSD support, follow-on to bsd-3-0-0-branch.
-
- bsd-3-0-0-branch:: This branch contains changes to support FreeBSD 4.0 and to port the Linux mga driver.
-
- bsd-1-0-0-branch:: This branch contained a variety of changes for FreeBSD support.
-
- config-0-0-1-branch:: This was a branch for creation of a general DRI configuration mechanism to replace card-specific environment variables.
-
- dispatch-0-0-1-branch:: This is the branch for the Mesa dynamic dispatching work.
-
- glxmisc-1-0-0-branch:: This branch fixed a variety of GLX-related issues such as visual configuration.
-
- glxmisc-2-0-0-branch:: This branch overhauled the XMesa/DRI client-side code; XMesa is no longer used.
-
- glxmisc-3-0-0-branch:: This branch fixed several DRI, DRM and GLX bugs, added version checking to the DRI components, fixed potential memory leaks in DRI drivers, and updated to Mesa 3.3.
-
- m3-0-0-1-branch:: This branch contained changes to support the ATI Rage 128 Mobility (M3/M4).
-
- mach64-0-0-7-branch:: This was the branch for the ATI Rage Pro driver development.
-
- mga-0-0-1-branch, mga-0-0-2-branch, mga-0-0-3-branch:: These branches housed the development of the Matrox G200/G400 and the Intel i810 drivers.
-
- r200-0-1-branch:: This was the development branch for the Radeon R200 driver.
-
- radeon-1-0-0-branch:: This branch contained support the ATI Radeon development.
-
- savage-1_0_0-branch, savage-2-0-0-branch:: This is the branch for integration of the VIA/S3 Savage driver.
-
- sse-1-0-0-branch:: This was an experimental branch, looking at optimizations of both core Mesa and the hardware drivers for the Pentium III processor.
-
- tcl-0-0-branch:: This branch hosted the Radeon Transform/Clip/Lighting works.
-
- tdfx-1-1:: This was the experimental branch for the 3dfx Voodoo Banshee/Voodoo3 development.
-
- tdfx-2-0-branch:: This was the experimental branch for the 3dfx Voodoo4/Voodoo5 development.
-
- tdfx-2-1-branch:: tdfx development for SLI and T-buffers was being done on this branch.
-
- tdfx-3-0-0-branch:: This branch implemented the tdfx driver overhaul, initiated by Gareth.
-
- texmem-0-0-1:: Texture memory management improvements.
-
-
-== Abandoned Branches ==
-
-These branches have been abandoned for one reason or another.  No development is taking place on these.
-
- dmx-0-1-branch:: This is the Distributed Xinerama branch. The DMX project has its own SourceForge CVS tree now. See [[http://dmx.sourceforge.net/|the DMX homepage]] .
-
- mesa-3-5-branch:: This branch was for Mesa 3.5 development, including porting of the DRI drivers to Mesa 3.5.
-
- mesa-4-0-4-branch:: DRI based on Mesa 4.0.4, used during the XFree86 4.2.99.x series so Mesa 5.0 work could continue on trunk and stable fixes get merged.
-
- ppc-1-0-0-branch:: This branch was dedicated to porting the DRI to Linux (and maybe other OSs) on PowerPC processors. PPC support for ATI Rage128 chips has finally hit the trunk with the merge of the ati-pcigart-1-0-0-branch.
-
- smt-0-0-1-branch, smt-0-0-2-branch:: This was the branch for the shared memory transport work.  SMT was completed in 1 March 2000, and was not found to provide more than a 10% performance increase using modern graphics cards on modern machines. This level of performance improvement does not justify inclusion of the SMT patches into the main XFree86 distribution, so this branch has been abandoned. A complete discussion is available on the SharedMemoryTransport page; [[http://www.precisioninsight.com/smt/smt-3.9.18.diff.gz|Patches]] (against XFree86 3.9.18) used to exist...
-
- video-1-0-0-branch:: This branch was for experimental video work that is no longer in progress. There's nothing interesting on this branch.
diff --git a/CvsPolicy.mdwn b/CvsPolicy.mdwn
new file mode 100644
index 0000000..461c480
--- /dev/null
+++ b/CvsPolicy.mdwn
@@ -0,0 +1,192 @@
+
+**Contents** [[!toc ]] 
+
+**OUT OF DATE: CURRENTLY GIT IS USED:   
+ [[http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=summary|http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=summary]] - mesa includes the DRI drivers  
+ [[http://gitweb.freedesktop.org/?p=mesa/drm.git;a=summary|http://gitweb.freedesktop.org/?p=mesa/drm.git;a=summary]] - own repository for DRM (Direct Rendering Manager) kernel drivers ** 
+
+
+## Overview
+
+The DRI project has several development policies which all developers are required to observe: 
+
+   1. All code development is to be done on CVS branches, not the trunk. 
+   1. Branches are not merged into the trunk until the code as been well tested. 
+   1. CVS tags follow a consistant naming convention. 
+   1. Merges to the trunk must be timed so that they do not upset scheduled releases. 
+Potential developers must accept these policies before joining the project. Anyone who does not follow these policies and causes problems will lose their CVS write privileges immediately, and probably forever. 
+
+
+## Introduction
+
+The DRI CVS tree is a subset of the XFree86 development tree.  The DRI tree omits documentation and font directories which are outside the scope of the DRI project. 
+
+When XFree86 releases a new public snapshot we will update the DRI tree to match the snapshot. 
+
+Prior to XFree86 releases we generate a patch file in order to submit our latest DRI code back to XFree86. 
+
+Since the DRI developers each have specific development projects, it's imperative that the check-ins which one developer commits does not interfere with the work of the others.  Also, it's very important that the main DRI trunk be a stable code base so that users can download and use it successfully at any time. 
+
+For these reasons, all code development is to be done on branches.  The rest of this document explains in detail how branches are to be managed. 
+
+We do make exceptions to this rule, however, when making one or two-line bug fixes.  It seems overkill to make a branch in order to commit a trivial bug fix. 
+
+Finally, the DRI project is tied to the schedules and deadlines of the XFree86 project and corporate contracts.  For that reason, merges into the trunk must be timed so that schedules aren't upset.  We will try to keep the DRI developers informed of these schedules. 
+
+
+## Branch tag naming scheme
+
+Branches are symbolic tags that are used to anchor a branch as a specific tree revision.  We'll use the following format for branch tags: 
+
+   * `<keyword>-<revision>-branch` 
+where: 
+
+   * `<keyword> ::= { tdfx, ati, i740, dri, smt, glxmisc, ... }` 
+   * `<revision> ::= <major>-<minor>-<patch>`  (e.g., `0-0-1`) 
+Note that hyphens (`-`) are used, not underscores.  Periods (`.`) are never used because they upset CVS's branch naming. 
+
+
+## Non-branch tag naming scheme
+
+We use non-branch tags for three things: 
+
+   1. syncing with XFree86, Mesa, etc. 
+   1. merging branches 
+   1. miscellaneous tags (e.g., to remember a specific stopping point) 
+
+### Format for syncing
+
+   * [[!format txt """
+<keyword>-<revision>-<date>
+
+<keyword> ::= { xfree, mesa, ... }
+
+<revision> ::= project-specific revision (e.g., 3-9-16e)
+
+<date> ::= <year><month><day>   (e.g., 19991206)
+"""]]
+
+### Format for merges
+
+On the branch, **before the merge**, use the following tag: 
+
+   * `<keyword>-<revision>-<date>` 
+On the main trunk, **after the merge**, use the following tag: 
+
+   * `<keyword>-<revision>-<date>-merge` 
+
+### Format for miscellaneous tags
+
+   * `<keyword>-<revision>-<date>-<comment>` 
+
+## How to check out the main trunk
+
+   * [[!format txt """
+export CVS_RSH=ssh
+
+cvs -z3 -dDEVELOPERNAME@cvs.dri.sourceforge.net:/cvsroot/dri co xc
+"""]]
+
+## How to check out a branch
+
+   * [[!format txt """
+cvs co -r <keyword>-<revision>-branch xc
+"""]]
+
+## How to make a branch
+
+
+### You have no checked out trees
+
+If you want to use the main trunk as the anchor for your branch: 
+
+   * [[!format txt """
+cvs rtag -b <keyword>-<revision>-branch
+cvs co -b <keyword>-<revision>-branch
+"""]]
+If you want to use some other tag as the anchor for your branch: 
+
+   * [[!format txt """
+cvs rtag -b -r <tag> <keyword>-<revision>-branch
+cvs co -b <keyword>-<revision>-branch
+"""]]
+
+### You have a checked out trunk, and you want to tag it and start using it as a branch
+
+* [[!format txt """
+cd <root-of-your-checked-out-tree>
+cvs tag -b <keyword>-<revision>-branch
+cvs update -r <keyword>-<revision>-branch
+"""]]
+This makes the `<keyword>-<revision>-branch` tag sticky.  You can verify this by using `cvs status`, for example in `XFree39/xc`, do this: 
+
+   * [[!format txt """
+cvs status Makefile
+"""]]
+or 
+
+   * [[!format txt """
+cvs status -v Makefile
+"""]]
+
+## How to merge the trunk into your branch
+
+Before you merge your code into the trunk you should first merge the latest trunk code into your branch.  After merged code has been tested on your branch, merging into the trunk should be simple. 
+
+   1. Be sure all the changes on your branch are checked in. 
+   1. Tag your branch with a 'freeze' tag: 
+         * [[!format txt """
+cvs tag <keyword>-<revision>-<date>-freeze
+"""]]
+   1. Merge from the trunk: 
+         * [[!format txt """
+cvs update -d -j HEAD
+"""]]
+   1. Resolve any conflicts from the merge. 
+   1. Recompile and build your branch.  Test it. 
+   1. Check in your changes from the merge. 
+   1. Tag your branch with a merge tag: 
+         * [[!format txt """
+cvs tag <keyword>-<revision>-<date>
+"""]]
+
+## How to merge your branch to the main trunk
+
+   1. Be sure your <keyword>-<revision>-<date>-merge tag (on the branch) is up to date (i.e., in case you changed some files from between the time you merged the trunk onto the branch until you merged the branch onto the trunk). You can make the tag with: 
+         * [[!format txt """
+cvs tag <keyword>-<revision>-<date>
+"""]]
+   1. Revert your working tree to the main trunk: 
+         * [[!format txt """
+cvs update -A
+"""]](Alternatively, you can just check out a new copy of the main trunk.) 
+   1. Merge in the changes from your branch: 
+         * [[!format txt """
+cvs update -j <keyword>-<revision>-branch
+"""]]
+   1. Test your merged tree 
+   1. Check in your merged tree to the main branch; 
+         * [[!format txt """
+cvs commit -m 'Merged <keyword>-<revision>'
+"""]]
+   1. Tag your merge so we can find it again: 
+         * [[!format txt """
+cvs tag <keyword>-<revision>-<date>-merge
+"""]]
+   1. Now you can make diffs to send to XFree86 
+Say you keep hacking on your branch after the merge to test a few extra things and you want to merge again.  You get the main trunk checked out, as in step 1, then you merge only those changes between your last merge and the most recent revision in your branch: 
+
+   * [[!format txt """
+cvs update -j <keyword>-<revision>-<date> \
+           -j <keyword>-<revision>-branch
+"""]]
+
+### How to turn off logging of large check-ins to the mailing list
+
+   * [[!format txt """
+cvs co CVSROOT
+"""]]
+   * edit loginfo to comment out the mail notification line 
+   * check in loginfo 
+   * do your merge 
+   * undo the change to loginfo 
+\ No newline at end of file
diff --git a/CvsPolicy.moin b/CvsPolicy.moin
deleted file mode 100644
index 0c4a3e4..0000000
--- a/CvsPolicy.moin
+++ /dev/null
@@ -1,263 +0,0 @@
-'''Contents'''
-<<TableOfContents>>
-
-'''OUT OF DATE: CURRENTLY GIT IS USED: <<BR>>
-http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=summary - mesa includes the DRI drivers<<BR>>
-http://gitweb.freedesktop.org/?p=mesa/drm.git;a=summary - own repository for DRM (Direct Rendering Manager) kernel drivers
-'''
-
-== Overview ==
-
-The DRI project has several development policies which all developers are
-required to observe:
-
-  1. All code development is to be done on CVS branches, not the trunk.
-
-  2. Branches are not merged into the trunk until the code as been well
-  tested.
-
-  3. CVS tags follow a consistant naming convention.
-
-  4. Merges to the trunk must be timed so that they do not upset scheduled
-  releases.
-
-Potential developers must accept these policies before joining the project.
-Anyone who does not follow these policies and causes problems will lose their
-CVS write privileges immediately, and probably forever.
-
-== Introduction ==
-
-The DRI CVS tree is a subset of the XFree86 development tree.  The DRI tree
-omits documentation and font directories which are outside the scope of the DRI
-project.
-
-When XFree86 releases a new public snapshot we will update the DRI tree to
-match the snapshot.
-
-Prior to XFree86 releases we generate a patch file in order to submit our
-latest DRI code back to XFree86.
-
-Since the DRI developers each have specific development projects, it's
-imperative that the check-ins which one developer commits does not interfere
-with the work of the others.  Also, it's very important that the main DRI trunk
-be a stable code base so that users can download and use it successfully at any
-time.
-
-For these reasons, all code development is to be done on branches.  The rest of
-this document explains in detail how branches are to be managed.
-
-We do make exceptions to this rule, however, when making one or two-line bug
-fixes.  It seems overkill to make a branch in order to commit a trivial bug
-fix.
-
-Finally, the DRI project is tied to the schedules and deadlines of the XFree86
-project and corporate contracts.  For that reason, merges into the trunk must
-be timed so that schedules aren't upset.  We will try to keep the DRI
-developers informed of these schedules.
-
-== Branch tag naming scheme ==
-
-Branches are symbolic tags that are used to anchor a branch as a specific tree
-revision.  We'll use the following format for branch tags:
-
-  `<keyword>-<revision>-branch`
-
-where:
-
-  * `<keyword> ::= { tdfx, ati, i740, dri, smt, glxmisc, ... }`
-
-  * `<revision> ::= <major>-<minor>-<patch>`  (e.g., `0-0-1`)
-
-Note that hyphens (`-`) are used, not underscores.  Periods (`.`) are never
-used because they upset CVS's branch naming.
-
-== Non-branch tag naming scheme ==
-
-We use non-branch tags for three things:
-
-  1. syncing with XFree86, Mesa, etc.
-
-  2. merging branches
-
-  3. miscellaneous tags (e.g., to remember a specific stopping point)
-
-
-=== Format for syncing ===
-
-  {{{
-<keyword>-<revision>-<date>
-
-<keyword> ::= { xfree, mesa, ... }
-
-<revision> ::= project-specific revision (e.g., 3-9-16e)
-
-<date> ::= <year><month><day>   (e.g., 19991206)
-}}}
-
-=== Format for merges ===
-
-On the branch, '''before the merge''', use the following tag:
-
-  {{{<keyword>-<revision>-<date>}}}
-
-On the main trunk, '''after the merge''', use the following tag:
-
-  {{{<keyword>-<revision>-<date>-merge}}}
-
-
-=== Format for miscellaneous tags ===
-
-  {{{<keyword>-<revision>-<date>-<comment>}}}
-
-== How to check out the main trunk ==
-
-  {{{
-export CVS_RSH=ssh
-
-cvs -z3 -dDEVELOPERNAME@cvs.dri.sourceforge.net:/cvsroot/dri co xc
-}}}
-
-== How to check out a branch ==
-
-  {{{
-cvs co -r <keyword>-<revision>-branch xc
-}}}
-
-== How to make a branch ==
-
-=== You have no checked out trees ===
-
-If you want to use the main trunk as the anchor for your branch:
-
-  {{{
-cvs rtag -b <keyword>-<revision>-branch
-cvs co -b <keyword>-<revision>-branch
-}}}
-
-If you want to use some other tag as the anchor for your branch:
-
-  {{{
-cvs rtag -b -r <tag> <keyword>-<revision>-branch
-cvs co -b <keyword>-<revision>-branch
-}}}
-
-=== You have a checked out trunk, and you want to tag it and start using it as a branch ===
-
- {{{
-cd <root-of-your-checked-out-tree>
-cvs tag -b <keyword>-<revision>-branch
-cvs update -r <keyword>-<revision>-branch
-}}}
-
-This makes the {{{<keyword>-<revision>-branch}}} tag sticky.  You can verify this by
-using {{{cvs status}}}, for example in `XFree39/xc`, do this:
-
-  {{{
-cvs status Makefile
-}}}
-
-or
-
-  {{{
-cvs status -v Makefile
-}}}
-
-== How to merge the trunk into your branch ==
-
-Before you merge your code into the trunk you should first merge
-the latest trunk code into your branch.  After merged code has been
-tested on your branch, merging into the trunk should be simple.
-
-  1. Be sure all the changes on your branch are checked in.
-
-  1. Tag your branch with a 'freeze' tag:
-
-    {{{
-cvs tag <keyword>-<revision>-<date>-freeze
-}}}
-
-  1. Merge from the trunk:
-
-    {{{
-cvs update -d -j HEAD
-}}}
-
-  1. Resolve any conflicts from the merge.
-
-  1. Recompile and build your branch.  Test it.
-
-  1. Check in your changes from the merge.
-
-  1. Tag your branch with a merge tag:
-
-    {{{
-cvs tag <keyword>-<revision>-<date>
-}}}
-
-== How to merge your branch to the main trunk ==
-
-  1. Be sure your <keyword>-<revision>-<date>-merge tag (on the branch) is up
-  to date (i.e., in case you changed some files from between the time you
-  merged the trunk onto the branch until you merged the branch onto the
-  trunk).
-
-  You can make the tag with:
-
-    {{{
-cvs tag <keyword>-<revision>-<date>
-}}}
-
-  1. Revert your working tree to the main trunk:
-
-    {{{
-cvs update -A
-}}}
-
-  (Alternatively, you can just check out a new copy of the main
-  trunk.)
-
-  1. Merge in the changes from your branch:
-
-    {{{
-cvs update -j <keyword>-<revision>-branch
-}}}
-
-  1. Test your merged tree
-
-  1. Check in your merged tree to the main branch;
-
-    {{{
-cvs commit -m 'Merged <keyword>-<revision>'
-}}}
-
-  1. Tag your merge so we can find it again:
-
-    {{{
-cvs tag <keyword>-<revision>-<date>-merge
-}}}
-
-  1. Now you can make diffs to send to XFree86
-
-Say you keep hacking on your branch after the merge to test a few extra
-things and you want to merge again.  You get the main trunk checked
-out, as in step 1, then you merge only those changes between your
-last merge and the most recent revision in your branch:
-
-  {{{
-cvs update -j <keyword>-<revision>-<date> \
-           -j <keyword>-<revision>-branch
-}}}
-
-=== How to turn off logging of large check-ins to the mailing list ===
-
-  * {{{
-cvs co CVSROOT
-}}}
-
-  * edit loginfo to comment out the mail notification line
-
-  * check in loginfo
-
-  * do your merge
-
-  * undo the change to loginfo
diff --git a/CvsRepository.mdwn b/CvsRepository.mdwn
new file mode 100644
index 0000000..5dcec32
--- /dev/null
+++ b/CvsRepository.mdwn
@@ -0,0 +1,83 @@
+
+The DRI project has moved its CVS services to [[http://dri.freedesktop.org/|http://dri.freedesktop.org/]] , to reduce the pains related to [[SourceForge|SourceForge]]'s overloaded CVS services.  The DRI project's CVS tree remains the upstream provider of the DRM (and is thus what is referred to as "DRM CVS"), but the xc tree is now obsolete and X.Org is the canonical source of DRI-enabled DDX drivers and GLX support. 
+
+To check out DRM CVS from freedesktop.org anonymously, first you must login: 
+
+   * [[!format txt """
+cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/dri login
+"""]]
+Hit `Enter` for the password. 
+
+Then, check out the `drm` module: 
+
+   * [[!format txt """
+cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/dri co drm
+"""]]
+If you wish to check out a [[branch|CvsBranches]] of the old `xc` DRI CVS, use the `-r tag`, e.g.: 
+
+   * [[!format txt """
+cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/dri co -rmach64-0-0-6-branch xc
+"""]]
+You'll also need a copy of the Mesa CVS tree: 
+
+   * [[!format txt """
+cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/mesa login  
+ 
+cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/mesa co Mesa 
+"""]]
+If you are a developer, CVS access is through ssh. Set `CVS_RSH=ssh` in your environment. Then, you can check out using 
+
+   * [[!format txt """
+cvs -z3 -d:ext:username@dri.freedesktop.org:/cvs/dri co xc
+cvs -z3 -d:ext:username@dri.freedesktop.org:/cvs/dri co drm
+cvs -z3 -d:ext:username@dri.freedesktop.org:/cvs/mesa co Mesa
+"""]]
+
+
+---
+
+ 
+
+Parameter Overview: 
+
+      * [[!format txt """
+SERVER=dri.freedesktop.org
+USER=anonymous
+PASSWORD=
+
+PROJECT_HOME=cvs
+PROJECT=dri
+
+MODULE=xc
+# other modules: something 
+
+BRANCH=              
+#BRANCH="-r something"
+"""]]
+
+
+---
+
+ 
+
+Generic Usage: 
+
+      * [[!format txt """
+CVSROOT=:pserver:$USER@$SERVER:/$PROJECT_HOME/$PROJECT
+export CVSROOT
+cvs login
+if [ ! -e $MODULE ]
+then
+        cvs checkout $BRANCH $MODULE
+else
+        cvs update -d -A -P $BRANCH $MODULE
+fi
+cvs logout
+"""]]
+
+
+---
+
+ 
+
+See CVSup, [[CvsPolicy|CvsPolicy]], and [[CvsBranches|CvsBranches]] for more information on using the DRI CVS repository. 
diff --git a/CvsRepository.moin b/CvsRepository.moin
deleted file mode 100644
index 5300add..0000000
--- a/CvsRepository.moin
+++ /dev/null
@@ -1,72 +0,0 @@
-The DRI project has moved its CVS services to http://dri.freedesktop.org/ , to reduce the pains related to SourceForge's overloaded CVS services.  The DRI project's CVS tree remains the upstream provider of the DRM (and is thus what is referred to as "DRM CVS"), but the xc tree is now obsolete and X.Org is the canonical source of DRI-enabled DDX drivers and GLX support.
-
-To check out DRM CVS from freedesktop.org anonymously, first you must login:
-
-  {{{
-cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/dri login
-}}}
-
-Hit `Enter` for the password.
-
-Then, check out the `drm` module:
-
-  {{{
-cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/dri co drm
-}}}
-
-If you wish to check out a [[CvsBranches|branch]] of the old `xc` DRI CVS, use the `-r tag`, e.g.:
-
-  {{{
-cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/dri co -rmach64-0-0-6-branch xc
-}}}
-
-You'll also need a copy of the Mesa CVS tree:
-
-  {{{
-cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/mesa login  
- 
-cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/mesa co Mesa }}}
-
-If you are a developer, CVS access is through ssh. Set `CVS_RSH=ssh` in your environment. Then, you can check out using
-
-  {{{
-cvs -z3 -d:ext:username@dri.freedesktop.org:/cvs/dri co xc
-cvs -z3 -d:ext:username@dri.freedesktop.org:/cvs/dri co drm
-cvs -z3 -d:ext:username@dri.freedesktop.org:/cvs/mesa co Mesa
-}}}
-
-----
-
-Parameter Overview:
-   {{{
-SERVER=dri.freedesktop.org
-USER=anonymous
-PASSWORD=
-
-PROJECT_HOME=cvs
-PROJECT=dri
-
-MODULE=xc
-# other modules: something 
-
-BRANCH=              
-#BRANCH="-r something"
-}}}
-----
-
-Generic Usage:
-   {{{
-CVSROOT=:pserver:$USER@$SERVER:/$PROJECT_HOME/$PROJECT
-export CVSROOT
-cvs login
-if [ ! -e $MODULE ]
-then
-        cvs checkout $BRANCH $MODULE
-else
-        cvs update -d -A -P $BRANCH $MODULE
-fi
-cvs logout
-}}}
-----
-
-See CVSup, CvsPolicy, and CvsBranches for more information on using the DRI CVS repository.
diff --git a/DDX.mdwn b/DDX.mdwn
new file mode 100644
index 0000000..0a89cb9
--- /dev/null
+++ b/DDX.mdwn
@@ -0,0 +1,23 @@
+
+
+## DDX
+
+For each type of graphics card there is a Device Dependent X (DDX) driver which does initialization, manages the display and performs 2D rendering. XFree86 4.0 introduced a new device driver interface called XAA which should allow XFree86 drivers to be backward compatible with future versions of the X server. 
+
+Each 2D driver has a bit of code to bootstrap the 3D / DRI features. 
+
+
+### Where does the DDX driver resides?
+
+The DDX drivers reside in a package called `xf86-video-foo`, where `foo` is usually the company that produces the hardware, or the hardware brand name, or something related (e.g. xf86-video-intel, xf86-video-ati, xf86-video-nouveau). The open source drivers are developed using [[Git|Git]] and hosted on `git.freedesktop.org`, which is accessible via a web interface at [[http://cgit.freedesktop.org/|http://cgit.freedesktop.org/]]. 
+
+The source code to the part of the DDX which is relevant to DRI and thus 3D acceleration is typically in files called `*_dri.[ch]`. 
+
+
+### Possible future developments
+
+With the introduction of [[Kernel Mode Setting|Kernel Mode Setting]], it has become possible to write a generic DDX, called `xf86-video-modesetting`. This is only an experiment as of this writing (October 2008). The generic DDX would use a Gallium3D backend for hardware acceleration purposes. 
+
+At XDC 2009, it was suggested to move many of the "main" DDX back into the X server Git repository. 
+
+**Todo**: Merge/Link this page to something in the main X.org Wiki to avoid redundancy? 
diff --git a/DDX.moin b/DDX.moin
deleted file mode 100644
index b7d5066..0000000
--- a/DDX.moin
+++ /dev/null
@@ -1,22 +0,0 @@
-== DDX ==
-
-For each type of graphics card there is a Device Dependent X (DDX) driver which
-does initialization, manages the display and performs 2D rendering. XFree86 4.0
-introduced a new device driver interface called XAA which should allow XFree86
-drivers to be backward compatible with future versions of the X server.
-
-Each 2D driver has a bit of code to bootstrap the 3D / DRI features.
-
-=== Where does the DDX driver resides? ===
-
-The DDX drivers reside in a package called `xf86-video-foo`, where `foo` is usually the company that produces the hardware, or the hardware brand name, or something related (e.g. xf86-video-intel, xf86-video-ati, xf86-video-nouveau). The open source drivers are developed using [[Git]] and hosted on `git.freedesktop.org`, which is accessible via a web interface at [[http://cgit.freedesktop.org/|http://cgit.freedesktop.org/]].
-
-The source code to the part of the DDX which is relevant to DRI and thus 3D acceleration is typically in files called `*_dri.[ch]`.
-
-=== Possible future developments ===
-
-With the introduction of [[Kernel Mode Setting]], it has become possible to write a generic DDX, called `xf86-video-modesetting`. This is only an experiment as of this writing (October 2008). The generic DDX would use a Gallium3D backend for hardware acceleration purposes.
-
-At XDC 2009, it was suggested to move many of the "main" DDX back into the X server Git repository.
-
-'''Todo''': Merge/Link this page to something in the main X.org Wiki to avoid redundancy?
diff --git a/DMA.mdwn b/DMA.mdwn
new file mode 100644
index 0000000..8dc0250
--- /dev/null
+++ b/DMA.mdwn
@@ -0,0 +1,11 @@
+
+
+## Direct Memory Access (DMA)
+
+This is the most complex of the data-transfer systems as both the host and the slave can access each others memory in any way they chose. As most !CS or !CprE people can quickly see, that only leads to more problems. So, DMA programming is the most complex of the three normal types of memory access. With DMA, an external chip/processor (let's be honest, a 3D processor counts as an external processor in its own right) can see anything in out memory space and we can see anything in its memory space -- barring limitations from things like the GART. With DMA, a typical interaction with an external chip/ processor is "here's an address at which you can find a complex data structure in my memory space in which you can find the commands and data to describe the operation which I wish you to perform. Have fun. Oh, tell me when you're done." DMA will normally allow the highest level of performance, but it does require some compromises that may sacrifice some latency for bandwidth.   
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/DMA.moin b/DMA.moin
deleted file mode 100644
index 4a946f4..0000000
--- a/DMA.moin
+++ /dev/null
@@ -1,18 +0,0 @@
-== Direct Memory Access (DMA) ==
-
-This is the most complex of the data-transfer systems as both the host and the
-slave can access each others memory in any way they chose. As most !CS or !CprE
-people can quickly see, that only leads to more problems. So, DMA programming
-is the most complex of the three normal types of memory access. With DMA, an
-external chip/processor (let's be honest, a 3D processor counts as an external
-processor in its own right) can see anything in out memory space and we can see
-anything in its memory space -- barring limitations from things like the GART.
-With DMA, a typical interaction with an external chip/ processor is "here's an
-address at which you can find a complex data structure in my memory space in
-which you can find the commands and data to describe the operation which I wish
-you to perform. Have fun. Oh, tell me when you're done." DMA will normally
-allow the highest level of performance, but it does require some compromises
-that may sacrifice some latency for bandwidth.  
-
-----
-CategoryGlossary
diff --git a/DONETemplate.mdwn b/DONETemplate.mdwn
new file mode 100644
index 0000000..41ddc7f
--- /dev/null
+++ b/DONETemplate.mdwn
@@ -0,0 +1,3 @@
+[[!table header="no" class="mointable" data="""
+DONE
+"""]]
diff --git a/DONETemplate.moin b/DONETemplate.moin
deleted file mode 100644
index ede56ec..0000000
--- a/DONETemplate.moin
+++ /dev/null
@@ -1 +0,0 @@
-||<bgcolor="lightgreen">DONE||
diff --git a/DRI.mdwn b/DRI.mdwn
new file mode 100644
index 0000000..e3d75f3
--- /dev/null
+++ b/DRI.mdwn
@@ -0,0 +1,11 @@
+
+
+## Direct Rendering Infrastructure (DRI)
+
+One of the problems with Direct Rendering is that other applications (say the X11 server, or other OpenGL clients) might want to talk to the hardware at the same time. In addition there can be problems with security, multiple users, and several other things caused by the complexity of Unix. An intricate software design called the Direct Rendering Infrastructure coordinates everything and prevents problems. The DRI used on Linux was designed and implemented by Precision Insight (who were recently bought by VA Software, former VA Linux). The DRI was integrated into XFree86 4.0 and is available in that and all subsequent releases; current development is concentrating on Xorg instead of XFree86. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/DRI.moin b/DRI.moin
deleted file mode 100644
index ea91753..0000000
--- a/DRI.moin
+++ /dev/null
@@ -1,14 +0,0 @@
-== Direct Rendering Infrastructure (DRI) ==
-
-One of the problems with Direct Rendering
-is that other applications (say the X11 server, or other OpenGL clients) might
-want to talk to the hardware at the same time. In addition there can be
-problems with security, multiple users, and several other things caused by the
-complexity of Unix. An intricate software design called the Direct Rendering
-Infrastructure coordinates everything and prevents problems. The DRI used on
-Linux was designed and implemented by Precision Insight (who were recently
-bought by VA Software, former VA Linux). The DRI was integrated into XFree86 4.0 and is available
-in that and all subsequent releases; current development is concentrating on Xorg instead of XFree86.
-
-----
-CategoryGlossary
diff --git a/DRI2.mdwn b/DRI2.mdwn
new file mode 100644
index 0000000..72001e4
--- /dev/null
+++ b/DRI2.mdwn
@@ -0,0 +1,4 @@
+
+DRI2 information is available in the X.org wiki: 
+
+[[http://wiki.x.org/wiki/DRI2|http://wiki.x.org/wiki/DRI2]] 
diff --git a/DRI2.moin b/DRI2.moin
deleted file mode 100644
index add89c1..0000000
--- a/DRI2.moin
+++ /dev/null
@@ -1,3 +0,0 @@
-DRI2 information is available in the X.org wiki:
-
-http://wiki.x.org/wiki/DRI2
diff --git a/DRILocking.moin b/DRILocking.mdwn
index 78b8ae1..fc59d8e 100644
--- a/DRILocking.moin
+++ b/DRILocking.mdwn
@@ -1,68 +1,78 @@
-The DRI uses a fairly straightforward locking scheme to arbitrate access to the hardware.  The old design docs are a bit out of date by now, so this page attempts to record how it works.
-
-NOTE: This page is a work in progress.  If it looks like a mess, it is.
-
-== Context locking ==
-
-The primary arbitration mechanism is the DRM context lock.  This guards access to a hardware context, allowing it to be shared among multiple rendering contexts.  This is essential for single-context hardware, which includes most pre-DX9 cards.  
-
-DRM clients - that is, any process using DRM services, including the X server - take the lock whenever they modify the state of that context.  The lock is advisory; clients are not required to take it before touching the card, but if they don't, madness will follow.  The unoptimized version of the lock is just an ioctl operation on the DRM device itself.  While one client is holding the lock, other clients will block in the ioctl call until the holding client unlocks, at which point the kernel schedules in the next client.
-
-Most DRI drivers only take the lock right as they're about to submit commands to the card.  The X server takes it every time it wakes up to process requests from X clients (during the so-called WakeupHandler) and releases it before executing any possibly-blocking select call (the BlockHandler).
-
-== Optimized context locking ==
-
-On most architectures, there is an optimization layer above this.  The context lock itself is stored as a single dword in the SAREA, a shared mapping page owned by the kernel and mapped into the address space of every DRM client.  Most of this word is devoted to the context ID, a small positive integer uniquely identifying a given context.  The high bits are used to indicate two lock conditions: held, and contended.  When a process goes to take the lock for the first time, it ioctls.  The kernel then sets the context ID appropriately, and sets the HELD flag.  At unlock, the client performs an atomic compare-and-swap on the lock: if the lock value is still the original context ID plus the HELD flag, it is atomically replaced with just the context ID, otherwise the client ioctls to the kernel to unlock.  If the CAS succeeded, the next time the client attempts to take the lock, it does the same CAS operation in reverse: if the lock is just the context ID, set the held flag, else ioctl to acquire the lock.  If the kernel receives a lock ioctl while the lock is already held, it sets the CONTENDED bit in the lock, thus ensuring that the holding client will ioctl to unlock and allow the next DRM client to schedule in.
-
-Okay, so that sounds pretty complex.  What's the result for the client?
-
- * If the context is about to lock, and it was the last context to hold the lock, it can re-take it entirely in userspace, and can be assured that no card state has changed.
- * If the context is about to lock but was not the last context to hold the lock, it must ioctl to acquire the lock.  This is potentially a blocking operation, and when the client continues it must re-emit state.
- * If the context is about to unlock, but no one is waiting for the lock, the lock is released with no kernel notification.
- * If the context is about to unlock and another context is waiting for the lock, the context must ioctl to the kernel to release it.
-
-== Drawable lock ==
-
-The above description is slightly simplified, because there's one other piece of 3D state that is involved.
-
-The window system maintains a clip list, which describes the overlaps among windows.  In order for a direct rendering client to draw to the screen correctly, it must respect the server's ideas of window boundaries.  To achieve this, the server maintains a small table in the SAREA of timestamps for each direct rendered drawable.  Currently the limit is 256 direct rendered drawables.
-
-The SAREA also contains a drawable lock.  This lock is logically after the context lock described above; it may only be taken by a context that already holds the context lock.  The server takes this lock just before it modifies the clip list for any direct rendered drawable, and releases it during BlockHandler (that is, just before processing the next client request).  After taking the drawable lock, the timestamp for that drawable is incremented.
-
-Once a GLX client has taken the DRM context lock, it needs to verify that its copy of the cliplist is current.  It takes the drawable lock, and then verifies that the timestamp for the drawable it's about to draw to matches the last timestamp it saw.  If the timestamp has changed, the cliplist has changed; the client then drops the drawable lock, then the context lock, and then sends DRI protocol to the X server to request the new cliplist for the drawable.  Once it has received the reply, the sequence repeats, until the timestamp received in the DRI protocol reply matches the timestamp in the SAREA.
-
-== Context Switch Modes ==
-
-DRI_SERVER_SWAP, DRI_KERNEL_SWAP, DRI_HIDE_X_CONTEXT.  TODO: remember what these are and write them down.
-
-== Multi-context hardware ==
-
-=== More than one, but finite, hardware contexts ===
-
-We don't currently have any drivers like this; glint may have worked this way, need to check.  Would also be good to note here what hardware falls into this class.
-
-One way to handle this kind of hardware would be to use the base DRM context lock as the mechanism for creating new contexts and protecting the drawable lock (and for the server's context, I suppose), and to create auxiliary context locks in the SAREA for each hardware context.  If you ever failed the CAS and had to ioctl for access to the context, you'd try to grab the master context and let the kernel assign you your next hardware context.
-
-=== Infinite hardware contexts but shared cliplist ===
-
-We don't currently have any finished drivers like this, but nouveau might behave this way.  TODO: other hardware fitting this model?
-
-In this model you basically never need to hold the context lock except for cliplist validation.
-
-== Interaction with AIGLX ==
-
-The DRI driver is normally the component that takes the context lock.  In the AIGLX server model, GLX rendering is handled in the server by the DRI driver, but the server also takes the lock.  Clearly a handoff is needed.
-
-The X server takes the lock in WakeupHandler, and then attempts to dispatch into the GLX code.  GLX notices that a DRI driver is loaded, and unlocks the DRM by calling '''just''' the BlockHandler for the DRI.  If the DRI driver ever needs to take the lock it will now succeed (albeit with an ioctl, since the X server was the last DRM client to hold the lock).  Once the request has finished dispatch, the GLX core calls the DRI's WakeupHandler so the server can reacquire the context lock.
-
-Note that since the ioctl is potentially a blocking operation, this does give greedy clients a chance to starve the X server of time.  Thus far the consensus seems to be "don't do that then".
-
-== Interaction with multiple screens ==
-
-The X server takes one lock per X screen.  Note that this means screen as in the protocol-visible object; :0.0 and :0.1 are different screens on the same display.  MergedFB mode presents one screen per card.  Zaphod mode presents one screen per output.  As a result, for multiscreen systems, the X server can present some interesting scheduling challenges.  This probably needs to be re-thought for the future.
-
-== Future optimization ideas ==
-
-The AIGLX handoff can be made slightly more robust in the face of greedy direct clients, by making the server set an additional property on the DRM lock when it first acquires it.  This flag would instruct the kernel to block any other process from acquiring the DRM context until the server released it for good.  This would have the pleasant side effect of fixing glucose correctness.
-
-If the DRM were significantly smarter, it could do away with the context lock for state emission altogether.  DRM clients would simply submit all rendering commands to the DRM and let the kernel schedule their dispatch.  Cliplist changes would simply be represented as reordering barriers in scheduling.
+
+The DRI uses a fairly straightforward locking scheme to arbitrate access to the hardware.  The old design docs are a bit out of date by now, so this page attempts to record how it works. 
+
+NOTE: This page is a work in progress.  If it looks like a mess, it is. 
+
+
+## Context locking
+
+The primary arbitration mechanism is the DRM context lock.  This guards access to a hardware context, allowing it to be shared among multiple rendering contexts.  This is essential for single-context hardware, which includes most pre-DX9 cards.   
+
+DRM clients - that is, any process using DRM services, including the X server - take the lock whenever they modify the state of that context.  The lock is advisory; clients are not required to take it before touching the card, but if they don't, madness will follow.  The unoptimized version of the lock is just an ioctl operation on the DRM device itself.  While one client is holding the lock, other clients will block in the ioctl call until the holding client unlocks, at which point the kernel schedules in the next client. 
+
+Most DRI drivers only take the lock right as they're about to submit commands to the card.  The X server takes it every time it wakes up to process requests from X clients (during the so-called [[WakeupHandler|WakeupHandler]]) and releases it before executing any possibly-blocking select call (the [[BlockHandler|BlockHandler]]). 
+
+
+## Optimized context locking
+
+On most architectures, there is an optimization layer above this.  The context lock itself is stored as a single dword in the SAREA, a shared mapping page owned by the kernel and mapped into the address space of every DRM client.  Most of this word is devoted to the context ID, a small positive integer uniquely identifying a given context.  The high bits are used to indicate two lock conditions: held, and contended.  When a process goes to take the lock for the first time, it ioctls.  The kernel then sets the context ID appropriately, and sets the HELD flag.  At unlock, the client performs an atomic compare-and-swap on the lock: if the lock value is still the original context ID plus the HELD flag, it is atomically replaced with just the context ID, otherwise the client ioctls to the kernel to unlock.  If the CAS succeeded, the next time the client attempts to take the lock, it does the same CAS operation in reverse: if the lock is just the context ID, set the held flag, else ioctl to acquire the lock.  If the kernel receives a lock ioctl while the lock is already held, it sets the CONTENDED bit in the lock, thus ensuring that the holding client will ioctl to unlock and allow the next DRM client to schedule in. 
+
+Okay, so that sounds pretty complex.  What's the result for the client? 
+
+* If the context is about to lock, and it was the last context to hold the lock, it can re-take it entirely in userspace, and can be assured that no card state has changed. 
+* If the context is about to lock but was not the last context to hold the lock, it must ioctl to acquire the lock.  This is potentially a blocking operation, and when the client continues it must re-emit state. 
+* If the context is about to unlock, but no one is waiting for the lock, the lock is released with no kernel notification. 
+* If the context is about to unlock and another context is waiting for the lock, the context must ioctl to the kernel to release it. 
+
+## Drawable lock
+
+The above description is slightly simplified, because there's one other piece of 3D state that is involved. 
+
+The window system maintains a clip list, which describes the overlaps among windows.  In order for a direct rendering client to draw to the screen correctly, it must respect the server's ideas of window boundaries.  To achieve this, the server maintains a small table in the SAREA of timestamps for each direct rendered drawable.  Currently the limit is 256 direct rendered drawables. 
+
+The SAREA also contains a drawable lock.  This lock is logically after the context lock described above; it may only be taken by a context that already holds the context lock.  The server takes this lock just before it modifies the clip list for any direct rendered drawable, and releases it during [[BlockHandler|BlockHandler]] (that is, just before processing the next client request).  After taking the drawable lock, the timestamp for that drawable is incremented. 
+
+Once a GLX client has taken the DRM context lock, it needs to verify that its copy of the cliplist is current.  It takes the drawable lock, and then verifies that the timestamp for the drawable it's about to draw to matches the last timestamp it saw.  If the timestamp has changed, the cliplist has changed; the client then drops the drawable lock, then the context lock, and then sends DRI protocol to the X server to request the new cliplist for the drawable.  Once it has received the reply, the sequence repeats, until the timestamp received in the DRI protocol reply matches the timestamp in the SAREA. 
+
+
+## Context Switch Modes
+
+DRI_SERVER_SWAP, DRI_KERNEL_SWAP, DRI_HIDE_X_CONTEXT.  TODO: remember what these are and write them down. 
+
+
+## Multi-context hardware
+
+
+### More than one, but finite, hardware contexts
+
+We don't currently have any drivers like this; glint may have worked this way, need to check.  Would also be good to note here what hardware falls into this class. 
+
+One way to handle this kind of hardware would be to use the base DRM context lock as the mechanism for creating new contexts and protecting the drawable lock (and for the server's context, I suppose), and to create auxiliary context locks in the SAREA for each hardware context.  If you ever failed the CAS and had to ioctl for access to the context, you'd try to grab the master context and let the kernel assign you your next hardware context. 
+
+
+### Infinite hardware contexts but shared cliplist
+
+We don't currently have any finished drivers like this, but nouveau might behave this way.  TODO: other hardware fitting this model? 
+
+In this model you basically never need to hold the context lock except for cliplist validation. 
+
+
+## Interaction with AIGLX
+
+The DRI driver is normally the component that takes the context lock.  In the AIGLX server model, GLX rendering is handled in the server by the DRI driver, but the server also takes the lock.  Clearly a handoff is needed. 
+
+The X server takes the lock in [[WakeupHandler|WakeupHandler]], and then attempts to dispatch into the GLX code.  GLX notices that a DRI driver is loaded, and unlocks the DRM by calling **just** the [[BlockHandler|BlockHandler]] for the DRI.  If the DRI driver ever needs to take the lock it will now succeed (albeit with an ioctl, since the X server was the last DRM client to hold the lock).  Once the request has finished dispatch, the GLX core calls the DRI's [[WakeupHandler|WakeupHandler]] so the server can reacquire the context lock. 
+
+Note that since the ioctl is potentially a blocking operation, this does give greedy clients a chance to starve the X server of time.  Thus far the consensus seems to be "don't do that then". 
+
+
+## Interaction with multiple screens
+
+The X server takes one lock per X screen.  Note that this means screen as in the protocol-visible object; :0.0 and :0.1 are different screens on the same display.  MergedFB mode presents one screen per card.  Zaphod mode presents one screen per output.  As a result, for multiscreen systems, the X server can present some interesting scheduling challenges.  This probably needs to be re-thought for the future. 
+
+
+## Future optimization ideas
+
+The AIGLX handoff can be made slightly more robust in the face of greedy direct clients, by making the server set an additional property on the DRM lock when it first acquires it.  This flag would instruct the kernel to block any other process from acquiring the DRM context until the server released it for good.  This would have the pleasant side effect of fixing glucose correctness. 
+
+If the DRM were significantly smarter, it could do away with the context lock for state emission altogether.  DRM clients would simply submit all rendering commands to the DRM and let the kernel schedule their dispatch.  Cliplist changes would simply be represented as reordering barriers in scheduling. 
diff --git a/DRM.mdwn b/DRM.mdwn
new file mode 100644
index 0000000..27fb9a7
--- /dev/null
+++ b/DRM.mdwn
@@ -0,0 +1,89 @@
+
+
+## Direct Rendering Manager (DRM)
+
+The DRM is a kernel module that gives direct hardware access to DRI clients. 
+
+This module deals with DMA, AGP memory management, resource locking, and secure hardware access. In order to support multiple, simultaneous 3D applications the 3D graphics hardware must be treated as a shared resource. Locking is required to provide mutual exclusion. DMA transfers and the AGP interface are used to send buffers of graphics commands to the hardware. Finally, there must be security to prevent clients from escalating privilege using the graphics hardware. 
+
+
+### Where does the DRM reside?
+
+Since internal Linux kernel interfaces and data structures may be changed at any time, DRI kernel modules must be specially compiled for a particular kernel version. The DRI kernel modules reside in the `/lib/modules/.../kernel/drivers/gpu/drm` directory.  (The kernel modules were in the `/lib/modules/.../kernel/drivers/char/drm` directory before version 2.6.26.)  Normally, the X server automatically loads whatever DRI kernel modules are needed. 
+
+For each 3D hardware driver there is a kernel module, each of which requires the generic DRM support code. 
+
+The source code is at git://anongit.freedesktop.org/git/mesa/drm 
+
+
+### In what way does the DRM support the DRI?
+
+The DRM supports the DRI in three major ways: 
+
+   1. The DRM provides synchronized access to the graphics hardware. The direct rendering system has multiple entities (i.e., the X server, multiple direct-rendering clients, and the kernel) competing for direct access to the graphics hardware. Hardware that is currently available for PC-class machines will lock up if more than one entity is accessing the hardware (e.g., if two clients intermingle requests in the command FIFO or (on some hardware) if one client reads the framebuffer while another writes the command FIFO). The DRM provides a single per-device hardware lock to synchronize access to the hardware. The hardware lock may be required when the X server performs 2D rendering, when a direct-rendering client is performing a software fallback that must read or write the frame buffer, or when the kernel is dispatching DMA buffers. This hardware lock may not be required for all hardware (e.g., high-end hardware may be able to intermingle command requests from multiple clients) or for all implementations (e.g., one that uses a page fault mechanism instead of an explicit lock). In the later case, the DRM would be extended to provide support for this mechanism. For more details on the hardware lock requirements and a discussion of the performance implications and implementation details, please see [FOM99]. 
+   1. The DRM enforces the DRI security policy for access to the graphics hardware. The X server, running as root, usually obtains access to the frame buffer and MMIO regions on the graphics hardware by mapping these regions using `/dev/mem`. The direct-rendering clients, however, do not run as root, but still require similar mappings. Like `/dev/mem`, the DRM device interface allows clients to create these mappings, but with the following restrictions: 
+         * The client may only map regions if it has a current connection to the X server. This forces direct-rendering clients to obey the normal X server security policy (e.g., using `xauth`). 
+         * The client may only map regions if it can open `/dev/drm?`, which is only accessible by root and by a group specified in the XF86Config file (a file that only root can edit). This allows the system administrator to restrict direct rendering access to a group of trusted users. 
+         * The client may only map regions that the X server allows to be mapped. The X server may also restrict those mappings to be read-only. This allows regions with security implications (e.g., those containing registers that can start DMA) to be restricted. 
+   1. The DRM provides a generic DMA engine. Most modern PC-class graphics hardware provides for DMA access to the command FIFO. Often, DMA access has been optimized so that it provides significantly better throughput than does MMIO access. For these cards, the DRM provides a DMA engine with the following features: 
+         * The X server can specify multiple pools of different sized buffers which are allocated and locked down. 
+         * The direct-rendering client maps these buffers into its virtual address space, using the DRM API. 
+         * The direct-rendering client reserves some of these buffers from the DRM, fills the buffers with commands, and requests that the DRM send the buffers to the graphics hardware. Small buffers are used to ensure that the X server can get the lock between buffer dispatches, thereby providing X server interactivity. Typical 40MB/s PCI transfer rates may require 10000 4kB buffer dispatches per second. 
+         * The DRM manages a queue of DMA buffers for each OpenGL GLXContext, and detects when a GLXContext switch is necessary. Hooks are provided so that a device-specific driver can perform the GLXContext switch in kernel-space, and a callback to the X server is provided when a device-specific driver is not available (for the sample implementation, the callback mechanism is used because it provides an example of the most generic method for GLXContext switching). The DRM also performs simple scheduling of DMA buffer requests to prevent GLXContext thrashing. When a DMA is swapped a significant amount of data must be read from and/or written to the graphics device (between 4kB and 64kB for typical hardware). 
+         * The DMA engine is generic in the sense that the X server provides information at run-time on how to perform DMA operations for the specific hardware installed on the machine. The X server does all of the hardware detection and setup. This allows easy bootstrapping for new graphics hardware under the DRI, while providing for later performance and capability enhancements through the use of a device-specific kernel driver. 
+
+### Is it possible to make a DRI driver without a DRM driver in a piece of hardware whereby we do all accelerations in PIO mode?
+
+The kernel provides three main things: 
+
+   1. the ability to wait on a contended lock (the waiting process is put to sleep), and to free the lock of a dead process; 
+   1. the ability to mmap areas of memory that non-root processes can't usually map; 
+   1. the ability to handle hardware interruptions and a DMA queue. 
+All of these are hard to do outside the kernel, but they aren't required components of a DRM driver. For example, the tdfx driver doesn't use hardware interrupts at all -- it is one of the simplest DRM drivers, and would be a good model for the hardware you are thinking about (in it's current form, it is quite generic). 
+
+**Note:**  DRI was designed with a very wide range of hardware in mind, ranging from very low-end PC graphics cards through very high-end SGI-like hardware (which may not even need the lock). The DRI is an infrastructure or framework that is very flexible -- most of the example drivers we have use hardware interrupts, but that isn't a requirement. 
+
+
+### Has the DRM driver support for or loading sub-drivers?
+
+Although the [Faith99] states that the DRM driver has support for loading sub-drivers by calling drmCreateSub, Linus didn't like that approach. He wanted all drivers to be independent, so the top-level "DRM" module no longer exists and each DRM module is independent. 
+
+
+### Is it possible to use floating point on the kernel?
+
+You _can_ use FP, but you have to jump through hoops to do so, especially if you're in an asynchronous context (i.e. interrupt or similar). 
+
+In process context (i.e. ioctl code) you could just decide that part of the calling convention of the ioctl is that the FP register state is corrupted, and use FP fairly freely - but realizing that FP usage is basically the same as "access to user mode" and can cause traps. 
+
+Oh, and getting an FP exception in the kernel is _definitely_ illegal, and can (and does) cause a hung box. The FP exception handling depends on a signal handler cleaning the thing up. 
+
+In general, the rule would be: don't do it. It's possible, but there are a lot of cases you have to worry about, and it would be a _lot_ better to do the FP (including any coordinate snapping) in mesa in user mode, and maybe just verify the values in the kernel (which can be done with fairly simple integer arithmetic). 
+
+   * -- [[LinusTorvalds|LinusTorvalds]] 
+
+### When to use semaphores?
+
+   * _The problem appears to be that the DRM people are used to using semaphores to protect kernel data structures. That is **wrong**._ 
+Follow-up, just in case somebody asks "what are semaphores there for then?" 
+
+There are reasons to use semaphores, but they are not about protecting data structures. They are mainly useful for protecting whole subsystems of code, notably in filesystems where we use semaphores extensively to protect things like concurrent access to a directory while doing lookups on it. 
+
+Examples: 
+
+* directory cache lookups (kernel "dcache" data structure): protected by "dcache_lock" spinlock 
+* VFS callback into filesystem to do a lookup that wasn't cached protected by per-directory inode semaphore 
+Basically, spinlocks protect data, while semaphores are more of a high-level "protect the concept" thing. 
+
+I suspect that there is very little in the DRI code that would ever have a good reason to use a semaphore, they just shouldn't be used at that kind of low level (they might be useful for doing things like serializing device opening etc, so I'm not saying that DRI should never ever use one, but you get the idea). 
+
+   * -- [[LinusTorvalds|LinusTorvalds]] 
+
+### What future changes are going to be made to the DRM?
+
+There is a [[NextDRMVersion|NextDRMVersion]] page to put ideas for changes to be made to the DRM if we should ever decide to eliminate compatibility with previous versions. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]], [[CategoryFaq|CategoryFaq]] 
diff --git a/DRM.moin b/DRM.moin
deleted file mode 100644
index 18f5d29..0000000
--- a/DRM.moin
+++ /dev/null
@@ -1,135 +0,0 @@
-== Direct Rendering Manager (DRM) ==
-
-The DRM is a kernel module that gives direct hardware access to DRI clients.
-
-This module deals with DMA, AGP memory management, resource locking, and secure
-hardware access. In order to support multiple, simultaneous 3D applications the
-3D graphics hardware must be treated as a shared resource. Locking is required
-to provide mutual exclusion. DMA transfers and the AGP interface are used to
-send buffers of graphics commands to the hardware. Finally, there must be
-security to prevent clients from escalating privilege using the graphics
-hardware.
-
-=== Where does the DRM reside? ===
-
-Since internal Linux kernel interfaces and data structures may be changed at any time, DRI kernel modules must be specially compiled for a particular kernel version. The DRI kernel modules reside in the `/lib/modules/.../kernel/drivers/gpu/drm` directory.  (The kernel modules were in the `/lib/modules/.../kernel/drivers/char/drm` directory before version 2.6.26.)  Normally, the X server automatically loads whatever DRI kernel modules are needed.
-
-For each 3D hardware driver there is a kernel module, each of which requires the generic DRM support code.
-
-The source code is at git://anongit.freedesktop.org/git/mesa/drm
-
-=== In what way does the DRM support the DRI? ===
-
-The DRM supports the DRI in three major ways:
-
-  1. The DRM provides synchronized access to the graphics hardware.
-
-  The direct rendering system has multiple entities (i.e., the X server, multiple direct-rendering clients, and the kernel) competing for direct access to the graphics hardware. Hardware that is currently available for PC-class machines will lock up if more than one entity is accessing the hardware (e.g., if two clients intermingle requests in the command FIFO or (on some hardware) if one client reads the framebuffer while another writes the command FIFO).
-
-  The DRM provides a single per-device hardware lock to synchronize access to the hardware. The hardware lock may be required when the X server performs 2D rendering, when a direct-rendering client is performing a software fallback that must read or write the frame buffer, or when the kernel is dispatching DMA buffers.
-
-  This hardware lock may not be required for all hardware (e.g., high-end hardware may be able to intermingle command requests from multiple clients) or for all implementations (e.g., one that uses a page fault mechanism instead of an explicit lock). In the later case, the DRM would be extended to provide support for this mechanism.
-
-  For more details on the hardware lock requirements and a discussion of the performance implications and implementation details, please see [FOM99].
-
-  1. The DRM enforces the DRI security policy for access to the graphics hardware.
-
-  The X server, running as root, usually obtains access to the frame buffer and MMIO regions on the graphics hardware by mapping these regions using `/dev/mem`. The direct-rendering clients, however, do not run as root, but still require similar mappings. Like `/dev/mem`, the DRM device interface allows clients to create these mappings, but with the following restrictions:
-    * The client may only map regions if it has a current connection to the X server. This forces direct-rendering clients to obey the normal X server security policy (e.g., using `xauth`).
-    * The client may only map regions if it can open `/dev/drm?`, which is only accessible by root and by a group specified in the XF86Config file (a file that only root can edit). This allows the system administrator to restrict direct rendering access to a group of trusted users.
-    * The client may only map regions that the X server allows to be mapped. The X server may also restrict those mappings to be read-only. This allows regions with security implications (e.g., those containing registers that can start DMA) to be restricted.
-
-  1. The DRM provides a generic DMA engine.
-
-  Most modern PC-class graphics hardware provides for DMA access to the command FIFO. Often, DMA access has been optimized so that it provides significantly better throughput than does MMIO access. For these cards, the DRM provides a DMA engine with the following features:
-
-    * The X server can specify multiple pools of different sized buffers which are allocated and locked down.
-    * The direct-rendering client maps these buffers into its virtual address space, using the DRM API.
-    * The direct-rendering client reserves some of these buffers from the DRM, fills the buffers with commands, and requests that the DRM send the buffers to the graphics hardware. Small buffers are used to ensure that the X server can get the lock between buffer dispatches, thereby providing X server interactivity. Typical 40MB/s PCI transfer rates may require 10000 4kB buffer dispatches per second.
-    * The DRM manages a queue of DMA buffers for each OpenGL GLXContext, and detects when a GLXContext switch is necessary. Hooks are provided so that a device-specific driver can perform the GLXContext switch in kernel-space, and a callback to the X server is provided when a device-specific driver is not available (for the sample implementation, the callback mechanism is used because it provides an example of the most generic method for GLXContext switching). The DRM also performs simple scheduling of DMA buffer requests to prevent GLXContext thrashing. When a DMA is swapped a significant amount of data must be read from and/or written to the graphics device (between 4kB and 64kB for typical hardware).
-    * The DMA engine is generic in the sense that the X server provides information at run-time on how to perform DMA operations for the specific hardware installed on the machine. The X server does all of the hardware detection and setup. This allows easy bootstrapping for new graphics hardware under the DRI, while providing for later performance and capability enhancements through the use of a device-specific kernel driver.
-
-
-=== Is it possible to make a DRI driver without a DRM driver in a piece of hardware whereby we do all accelerations in PIO mode? ===
-
-The kernel provides three main things:
-
-  1. the ability to wait on a contended lock (the waiting process is put to sleep), and to free the lock of a dead process;
-
-  1. the ability to mmap areas of memory that non-root processes can't usually map;
-
-  1. the ability to handle hardware interruptions and a DMA queue.
-
-
-All of these are hard to do outside the kernel, but they aren't required components of a DRM driver. For example, the tdfx driver doesn't use hardware interrupts at all -- it is one of the simplest DRM drivers, and would be a good model for the hardware you are thinking about (in it's current form, it is quite generic).
-
-'''Note:'''  DRI was designed with a very wide range of hardware in mind, ranging from very low-end PC graphics cards through very high-end SGI-like hardware (which may not even need the lock). The DRI is an infrastructure or framework that is very flexible -- most of the example drivers we have use hardware interrupts, but that isn't a requirement.
-
-
-=== Has the DRM driver support for or loading sub-drivers? ===
-
-Although the [Faith99] states that the DRM driver has support for loading sub-drivers by calling drmCreateSub, Linus didn't like that approach. He wanted all drivers to be independent, so the top-level "DRM" module no longer exists and each DRM module is independent.
-
-=== Is it possible to use floating point on the kernel? ===
-
-You ''can'' use FP, but you have to jump through hoops to do so, especially
-if you're in an asynchronous context (i.e. interrupt or similar).
-
-In process context (i.e. ioctl code) you could just decide that part of
-the calling convention of the ioctl is that the FP register state is
-corrupted, and use FP fairly freely - but realizing that FP usage is
-basically the same as "access to user mode" and can cause traps.
-
-Oh, and getting an FP exception in the kernel is ''definitely'' illegal, and
-can (and does) cause a hung box. The FP exception handling depends on a
-signal handler cleaning the thing up.
-
-In general, the rule would be: don't do it. It's possible, but there are a
-lot of cases you have to worry about, and it would be a ''lot'' better to do
-the FP (including any coordinate snapping) in mesa in user mode, and maybe
-just verify the values in the kernel (which can be done with fairly simple
-integer arithmetic).
-
-  -- LinusTorvalds
-
-=== When to use semaphores? ===
-
-  ''The problem appears to be that the DRM people are used to using semaphores
-  to protect kernel data structures. That is '''wrong'''.''
-
-Follow-up, just in case somebody asks "what are semaphores there for
-then?"
-
-There are reasons to use semaphores, but they are not about protecting
-data structures. They are mainly useful for protecting whole subsystems of
-code, notably in filesystems where we use semaphores extensively to
-protect things like concurrent access to a directory while doing lookups
-on it.
-
-Examples:
-
- * directory cache lookups (kernel "dcache" data structure):
-
- protected by "dcache_lock" spinlock
-
- * VFS callback into filesystem to do a lookup that wasn't cached
-
- protected by per-directory inode semaphore
-
-Basically, spinlocks protect data, while semaphores are more of a
-high-level "protect the concept" thing.
-
-I suspect that there is very little in the DRI code that would ever have a
-good reason to use a semaphore, they just shouldn't be used at that kind
-of low level (they might be useful for doing things like serializing
-device opening etc, so I'm not saying that DRI should never ever use one,
-but you get the idea).
-
-  -- LinusTorvalds
-
-=== What future changes are going to be made to the DRM? ===
-There is a [[NextDRMVersion]] page to put ideas for changes to be made to the DRM
-if we should ever decide to eliminate compatibility with previous versions.
-
-----
-CategoryGlossary, CategoryFaq
diff --git a/DRMAccessControl.moin b/DRMAccessControl.mdwn
index a32961d..0681be2 100644
--- a/DRMAccessControl.moin
+++ b/DRMAccessControl.mdwn
@@ -1,13 +1,15 @@
-= DRM Access Control =
-
-''' What clients can access the DRM? '''
-
-Any client that can access the X server can access the DRM. This is not a security issue because a client can interfere with the display just as much with the X server as with the DRM.
-
-''' How does the client access the DRM? '''
-
-The client requests access to the X server. If this access is granted, the X server gives both the client and the DRM the same cookie. Next, the client opens the DRM device, passing the cookie to the DRM.  The DRM compares the cookie it received from the client and the one it received from the X server. If they match, the DRM allows the client to access it in more useful ways.
-
-''' What prevents multiple clients of the DRM from interfering with one another? '''
-
-A well-behaved client would use the lock to regulate access. This ioctl-based lock blocks the client until the lock is released.  However, this lock is cooperative, and a buggy or malicious client may ignore it.
+
+
+# DRM Access Control
+
+** What clients can access the DRM? ** 
+
+Any client that can access the X server can access the DRM. This is not a security issue because a client can interfere with the display just as much with the X server as with the DRM. 
+
+** How does the client access the DRM? ** 
+
+The client requests access to the X server. If this access is granted, the X server gives both the client and the DRM the same cookie. Next, the client opens the DRM device, passing the cookie to the DRM.  The DRM compares the cookie it received from the client and the one it received from the X server. If they match, the DRM allows the client to access it in more useful ways. 
+
+** What prevents multiple clients of the DRM from interfering with one another? ** 
+
+A well-behaved client would use the lock to regulate access. This ioctl-based lock blocks the client until the lock is released.  However, this lock is cooperative, and a buggy or malicious client may ignore it. 
diff --git a/DRMProcess.moin b/DRMProcess.mdwn
index 9cfae0c..2341df2 100644
--- a/DRMProcess.moin
+++ b/DRMProcess.mdwn
@@ -1,51 +1,46 @@
-= DRM Development Process (Proposed) =
-
-1. Master branch in Linux tree style with links for BSD etc.
-
-2. Always compatible with current release Linux kernel + with backwards compat *where* practical for older kernels. We should probably limit the back compat
-   to like 6 kernel revisions or something.
-
-3. Macros for BSD compat to wrap Linux APIs. So we minimise the nightmare of macros in driver code. no more DRM_ if they can be avoided.
-
-== Patches ==
-1. All patches to be sent to the mailing list with S-O-B, no patches to be committed to master branch. Nothing goes upstream or into master without Signed-off-by and maintainers Signed-off-by.
-2. Do not mix cleanup and developement ever. If you move a bunch of registers or code into a separate file, do just that in one patch.
-3. Backwards compat patches in separate patches. So first patch should be upstreamable, backwards compat patches should be in sequence.
-
-== Upstream first policy ==
-
-This policy places a restriction on users of the drm, i.e. Mesa, DDX, X server. No upstream release should include code that hasn't been included in a Linux kernel release cycle. Upstream can use a --enable-experimental-kernel-api type flag but default build should never require any unreleased kernel/drm API to build or run. Distros should not enable experimental APIs in releases, unless they are willing to version their kernel and other components against each other and deal with the fallout of API changes.
-
-All userspace APIs need to be submitted to dri-devel and to the Linux kernel list, also all patches which need exports or use new non-drm kernel functionality should be reviewed by both lists.
-
-Note: Do not expect because your code works that you won't have to re-write it all for upstream. So upstream ideas early esp when you interface to other kernel components.
-
-== Development ==
-
-1. For large features or new drivers create a new branch in drm tree. Stay in the branch, these branches will never ever get merged ever. ever. When the developers feel the branch is suitable for upstream, they need to create a clean set of patches following the rules above. All API additions need to be reviewed and feedback taken on board. If this involves another round of development, nuke the old branch and/or start a new one from the patchset. Repeat cycle.
-When patches are approved by anyone who cares they will get merged into the drm master and into the upstream drm-next queue. Backwards compat patches will be merged into drm master.
-
-2. For minor cleanups and fixes, patches should be sent to dri-devel.
-
-3. If a patch gets reverted from upstream kernel for a regression it will also be reverted from the drm master branch.
-
-4. If someone gets in the queue and you conflict you get to keep the mess.
-
-== DRM tree layout (plans) ==
-
-1. Create drivers/gpu/drm/ exactly a mirror of current upstream.
-2. Add backwards compat cleanly on top of this tree with some patches.
-3. Add BSD compat in places that need it.
-4. Migrate BSD to using the upstream src files instead of the shared-core ones.
-5. Evict all non-upstream patches to branches, currently
-         - GEM
-         - TTM
-         - vblank-rework
-         - i915 various bits, mmio oq interface.
-
-
-== Suggestions + help needed ==
-
-In the future we may find we need a transitory drm-testing branch that merges all the currently in development branches. This might
-help in resolving conflicts before they happen.
-It would be nice to tinderbox build the drm mainline and drm-testing against the last 6 released kernels.
+
+
+# DRM Development Process (Proposed)
+
+1. Master branch in Linux tree style with links for BSD etc. 
+
+2. Always compatible with current release Linux kernel + with backwards compat *where* practical for older kernels. We should probably limit the back compat 
+
+      * to like 6 kernel revisions or something. 
+3. Macros for BSD compat to wrap Linux APIs. So we minimise the nightmare of macros in driver code. no more DRM_ if they can be avoided. 
+
+
+## Patches
+
+1. All patches to be sent to the mailing list with S-O-B, no patches to be committed to master branch. Nothing goes upstream or into master without Signed-off-by and maintainers Signed-off-by. 2. Do not mix cleanup and developement ever. If you move a bunch of registers or code into a separate file, do just that in one patch. 3. Backwards compat patches in separate patches. So first patch should be upstreamable, backwards compat patches should be in sequence. 
+
+
+## Upstream first policy
+
+This policy places a restriction on users of the drm, i.e. Mesa, DDX, X server. No upstream release should include code that hasn't been included in a Linux kernel release cycle. Upstream can use a --enable-experimental-kernel-api type flag but default build should never require any unreleased kernel/drm API to build or run. Distros should not enable experimental APIs in releases, unless they are willing to version their kernel and other components against each other and deal with the fallout of API changes. 
+
+All userspace APIs need to be submitted to dri-devel and to the Linux kernel list, also all patches which need exports or use new non-drm kernel functionality should be reviewed by both lists. 
+
+Note: Do not expect because your code works that you won't have to re-write it all for upstream. So upstream ideas early esp when you interface to other kernel components. 
+
+
+## Development
+
+1. For large features or new drivers create a new branch in drm tree. Stay in the branch, these branches will never ever get merged ever. ever. When the developers feel the branch is suitable for upstream, they need to create a clean set of patches following the rules above. All API additions need to be reviewed and feedback taken on board. If this involves another round of development, nuke the old branch and/or start a new one from the patchset. Repeat cycle. When patches are approved by anyone who cares they will get merged into the drm master and into the upstream drm-next queue. Backwards compat patches will be merged into drm master. 
+
+2. For minor cleanups and fixes, patches should be sent to dri-devel. 
+
+3. If a patch gets reverted from upstream kernel for a regression it will also be reverted from the drm master branch. 
+
+4. If someone gets in the queue and you conflict you get to keep the mess. 
+
+
+## DRM tree layout (plans)
+
+1. Create drivers/gpu/drm/ exactly a mirror of current upstream. 2. Add backwards compat cleanly on top of this tree with some patches. 3. Add BSD compat in places that need it. 4. Migrate BSD to using the upstream src files instead of the shared-core ones. 5. Evict all non-upstream patches to branches, currently 
+
+                        * - GEM - TTM - vblank-rework - i915 various bits, mmio oq interface. 
+
+## Suggestions + help needed
+
+In the future we may find we need a transitory drm-testing branch that merges all the currently in development branches. This might help in resolving conflicts before they happen. It would be nice to tinderbox build the drm mainline and drm-testing against the last 6 released kernels. 
diff --git a/DRMRedesign.moin b/DRMRedesign.mdwn
index b6ebd1f..671d67e 100644
--- a/DRMRedesign.moin
+++ b/DRMRedesign.mdwn
@@ -1,20 +1,30 @@
-This is an explanation of where I think the DRM needs to go for modesetting + TTM to provide a flexible interface for users.
-
-{{http://people.freedesktop.org/~airlied/drm_new_design.png}}
-
-= DRM Device: =
-This is the central DRM device. There is one instance of this per GPU and consists of the GPU driver alog with drm core code. The DRM device exposes an interface to userspace via device minors. There will be 3 types of minors exposed.
-
-== Legacy Minor: ==
-Old style DRM interface for older drivers to use also if this is opened for a card it will block newer uses of the card until closed. Vice-versa if the control node has been used to setup other nodes then this node will not be openable. The X server by default will use this node to try and enable DRI for all devices.
-== Control Minor: ==
-The control node will act like a pts master. This node can be used by a system user manager to create a render node, that can be assigned modesetting resources such as a crtc/outputs. If no rendering resources are assigned to
-this node then it will be used for GPGPU type applications. The system user manager can then pass the render node to the render leader (i.e. the X server) via a command line option or env variable. The X server will then run as the user and open the correct render minor to gain access to the modesetting resources and rendering functionality. The control node can also be used to switch render nodes in and out of focus. Output resources can only be assigned to one render leader at a time. While the render leader isn't focused it can be suspended or can keep consuming resources in the background with no output displaying. This is under the control of the user manager.
-== Render Minor: ==
-The render node is what the user render leader connects to. The system can be configured with either a single render node with all crtcs/outputs available to a single user, or a render node per crtc with a set of configured outputs for multiple users to use. Also render nodes with no output resources can exist.
-
-= Locking and SAREA: =
-The current DRM design has one large single lock and a single sarea. With this new scheme the actual access to hw is locked within the kernel, clients must prepare buffers and submit them to the drm kernel driver for scheduling. Each render leader has its own private sarea based on DRI2 work, which is used to store cliprects and the lock protecting the cliprects.
-
-= Interrupt handling: =
-The main area under DRI2 is if we have in-kernel cliprect users we need to make sure the correct sarea is being accessed for the swap buffers. This could be two sareas as we may have a different render leader on each crtc.
+
+This is an explanation of where I think the DRM needs to go for modesetting + TTM to provide a flexible interface for users. 
+
+[[!img http://people.freedesktop.org/~airlied/drm_new_design.png] 
+
+
+# DRM Device:
+
+This is the central DRM device. There is one instance of this per GPU and consists of the GPU driver alog with drm core code. The DRM device exposes an interface to userspace via device minors. There will be 3 types of minors exposed. 
+
+
+## Legacy Minor:
+
+Old style DRM interface for older drivers to use also if this is opened for a card it will block newer uses of the card until closed. Vice-versa if the control node has been used to setup other nodes then this node will not be openable. The X server by default will use this node to try and enable DRI for all devices. 
+## Control Minor:
+
+The control node will act like a pts master. This node can be used by a system user manager to create a render node, that can be assigned modesetting resources such as a crtc/outputs. If no rendering resources are assigned to this node then it will be used for GPGPU type applications. The system user manager can then pass the render node to the render leader (i.e. the X server) via a command line option or env variable. The X server will then run as the user and open the correct render minor to gain access to the modesetting resources and rendering functionality. The control node can also be used to switch render nodes in and out of focus. Output resources can only be assigned to one render leader at a time. While the render leader isn't focused it can be suspended or can keep consuming resources in the background with no output displaying. This is under the control of the user manager. 
+## Render Minor:
+
+The render node is what the user render leader connects to. The system can be configured with either a single render node with all crtcs/outputs available to a single user, or a render node per crtc with a set of configured outputs for multiple users to use. Also render nodes with no output resources can exist. 
+
+
+# Locking and SAREA:
+
+The current DRM design has one large single lock and a single sarea. With this new scheme the actual access to hw is locked within the kernel, clients must prepare buffers and submit them to the drm kernel driver for scheduling. Each render leader has its own private sarea based on DRI2 work, which is used to store cliprects and the lock protecting the cliprects. 
+
+
+# Interrupt handling:
+
+The main area under DRI2 is if we have in-kernel cliprect users we need to make sure the correct sarea is being accessed for the swap buffers. This could be two sareas as we may have a different render leader on each crtc. 
diff --git a/DRMTemplates.mdwn b/DRMTemplates.mdwn
new file mode 100644
index 0000000..ca510f6
--- /dev/null
+++ b/DRMTemplates.mdwn
@@ -0,0 +1,121 @@
+
+
+## What is templated DRM code?
+
+It was first discussed in a email about what Gareth had done to bring up the mach64 kernel module. 
+
+Not wanting to simply copy-and-paste another version of __drv.[ch]_, __context.c_, __bufs.s_ and so on, Gareth did some refactoring along the lines of what him and Rik Faith had discussed a long time ago. 
+
+This is very much along the lines of a lot of Mesa code, where there exists a template header file that can be customized with a few defines. At the time, it was done __drv.c_ and __context.c_, creating _driver_tmp.h_ and _context_tmp.h_ that could be used to build up the core module. 
+
+An inspection of _mach64_drv.c_ on the mach64-0-0-1-branch reveals the following code: 
+
+   * [[!format txt """
+#define DRIVER_AUTHOR           "Gareth Hughes"
+
+#define DRIVER_NAME             "mach64"
+#define DRIVER_DESC             "DRM module for the ATI Rage Pro"
+#define DRIVER_DATE             "20001203"
+
+#define DRIVER_MAJOR            1
+#define DRIVER_MINOR            0
+#define DRIVER_PATCHLEVEL       0
+
+
+static drm_ioctl_desc_t         mach64_ioctls[] = {
+        [DRM_IOCTL_NR(DRM_IOCTL_VERSION)]       = { mach64_version,    0, 0 },
+        [DRM_IOCTL_NR(DRM_IOCTL_GET_UNIQUE)]    = { drm_getunique,     0, 0 },
+        [DRM_IOCTL_NR(DRM_IOCTL_GET_MAGIC)]     = { drm_getmagic,      0, 0 },
+        [DRM_IOCTL_NR(DRM_IOCTL_IRQ_BUSID)]     = { drm_irq_busid,     0, 1 },
+
+        [DRM_IOCTL_NR(DRM_IOCTL_SET_UNIQUE)]    = { drm_setunique,     1, 1 },
+        [DRM_IOCTL_NR(DRM_IOCTL_BLOCK)]         = { drm_block,         1, 1 },
+        [DRM_IOCTL_NR(DRM_IOCTL_UNBLOCK)]       = { drm_unblock,       1, 1 },
+        [DRM_IOCTL_NR(DRM_IOCTL_AUTH_MAGIC)]    = { drm_authmagic,     1, 1 },
+        [DRM_IOCTL_NR(DRM_IOCTL_ADD_MAP)]       = { drm_addmap,        1, 1 },
+
+        [DRM_IOCTL_NR(DRM_IOCTL_ADD_BUFS)]      = { drm_addbufs,       1, 1 },
+        [DRM_IOCTL_NR(DRM_IOCTL_MARK_BUFS)]     = { drm_markbufs,      1, 1 },
+        [DRM_IOCTL_NR(DRM_IOCTL_INFO_BUFS)]     = { drm_infobufs,      1, 0 },
+        [DRM_IOCTL_NR(DRM_IOCTL_MAP_BUFS)]      = { drm_mapbufs,       1, 0 },
+        [DRM_IOCTL_NR(DRM_IOCTL_FREE_BUFS)]     = { drm_freebufs,      1, 0 },
+
+        [DRM_IOCTL_NR(DRM_IOCTL_ADD_CTX)]       = { mach64_addctx,     1, 1 },
+        [DRM_IOCTL_NR(DRM_IOCTL_RM_CTX)]        = { mach64_rmctx,      1, 1 },
+        [DRM_IOCTL_NR(DRM_IOCTL_MOD_CTX)]       = { mach64_modctx,     1, 1 },
+        [DRM_IOCTL_NR(DRM_IOCTL_GET_CTX)]       = { mach64_getctx,     1, 0 },
+        [DRM_IOCTL_NR(DRM_IOCTL_SWITCH_CTX)]    = { mach64_switchctx,  1, 1 },
+        [DRM_IOCTL_NR(DRM_IOCTL_NEW_CTX)]       = { mach64_newctx,     1, 1 },
+        [DRM_IOCTL_NR(DRM_IOCTL_RES_CTX)]       = { mach64_resctx,     1, 0 },
+        [DRM_IOCTL_NR(DRM_IOCTL_ADD_DRAW)]      = { drm_adddraw,       1, 1 },
+        [DRM_IOCTL_NR(DRM_IOCTL_RM_DRAW)]       = { drm_rmdraw,        1, 1 },
+        [DRM_IOCTL_NR(DRM_IOCTL_LOCK)]          = { mach64_lock,       1, 0 },
+        [DRM_IOCTL_NR(DRM_IOCTL_UNLOCK)]        = { mach64_unlock,     1, 0 },
+        [DRM_IOCTL_NR(DRM_IOCTL_FINISH)]        = { drm_finish,        1, 0 },
+
+#if defined(CONFIG_AGP) || defined(CONFIG_AGP_MODULE)
+        [DRM_IOCTL_NR(DRM_IOCTL_AGP_ACQUIRE)]   = { drm_agp_acquire,   1, 1 },
+        [DRM_IOCTL_NR(DRM_IOCTL_AGP_RELEASE)]   = { drm_agp_release,   1, 1 },
+        [DRM_IOCTL_NR(DRM_IOCTL_AGP_ENABLE)]    = { drm_agp_enable,    1, 1 },
+        [DRM_IOCTL_NR(DRM_IOCTL_AGP_INFO)]      = { drm_agp_info,      1, 0 },
+        [DRM_IOCTL_NR(DRM_IOCTL_AGP_ALLOC)]     = { drm_agp_alloc,     1, 1 },
+        [DRM_IOCTL_NR(DRM_IOCTL_AGP_FREE)]      = { drm_agp_free,      1, 1 },
+        [DRM_IOCTL_NR(DRM_IOCTL_AGP_BIND)]      = { drm_agp_bind,      1, 1 },
+        [DRM_IOCTL_NR(DRM_IOCTL_AGP_UNBIND)]    = { drm_agp_unbind,    1, 1 },
+#endif
+
+        [DRM_IOCTL_NR(DRM_IOCTL_MACH64_INIT)]   = { mach64_dma_init,   1, 1 },
+        [DRM_IOCTL_NR(DRM_IOCTL_MACH64_CLEAR)]  = { mach64_dma_clear,  1, 0 },
+        [DRM_IOCTL_NR(DRM_IOCTL_MACH64_SWAP)]   = { mach64_dma_swap,   1, 0 },
+        [DRM_IOCTL_NR(DRM_IOCTL_MACH64_IDLE)]   = { mach64_dma_idle,   1, 0 },
+};
+
+#define DRIVER_IOCTL_COUNT      DRM_ARRAY_SIZE( mach64_ioctls )
+
+#define HAVE_CTX_BITMAP         1
+
+#define TAG(x) mach64_##x
+#include "driver_tmp.h"
+"""]]
+And that's all you need. A trivial amount of code is needed for the context handling: 
+
+   * [[!format txt """
+#define __NO_VERSION__
+#include "drmP.h"
+#include "mach64_drv.h"
+
+#define TAG(x) mach64_##x
+#include "context_tmp.h"
+"""]]
+And as far as I can tell, the only thing that's keeping this out of _mach64_drv.c_ is the **<ins>NO_VERSION</ins>**, which is a 2.2 thing and is not used in 2.4 (right?). 
+
+To enable all the context bitmap code, we see the 
+
+   * [[!format txt """
+#define HAVE_CTX_BITMAP 1
+"""]]
+* To enable things like AGP, MTRR's and DMA management, the author simply needs to define the correct symbols. With less than five minutes of mach64-specific coding, I had a full kernel module that would do everything a basic driver requires -- enough to bring up a software-fallback driver. The above code is all that is needed for the tdfx driver, with appropriate name changes. Indeed, any card that doesn't do kernel-based DMA can have a fully functional DRM module with the above code. DMA-based drivers will need more, of course. 
+The plan is to extend this to basic DMA setup and buffer management, so that the creation of PCI or AGP  DMA buffers, installation of IRQs and so on is as trivial as this. What will then be left is the hardware-specific parts of the DRM module that deal with actually programming the card to do things, such as setting state for rendering or kicking off DMA buffers. That is, the interesting stuff. 
+
+A couple of points: 
+
+   * Why was it done like this, and not with C++ features like virtual functions (i.e. why don't I do it in C++)? Because it's the Linux kernel, dammit! No offense to any C++ fan who may be reading this :-) Besides, a lot of the initialization is order-dependent, so inserting or removing blocks of code with **#defines** is a nice way to achieve the desired result, at least in this situation. 
+   * Much of the core DRM code (like _bufs.c_, _context.c_ and _dma.c_) will essentially move into these template headers. I feel that this is a better way to handle the common code. Take _context.c_ as a trivial example -- the i810, mga, tdfx, r128 and mach64 drivers have exactly the same code, with name changes. Take _bufs.c_ as a slightly more interesting example -- some drivers map only AGP buffers, some do both AGP and PCI, some map differently depending on their DMA queue management and so on. Again, rather than cutting and pasting the code from drm_addbufs into my driver, removing the sections I don't need and leaving it at that, I think keeping the core functionality in _bufs_tmp.h_ and allowing this to be customized at compile time is a cleaner and more maintainable solution. 
+This it has the possibility to make keeping the other OS's code up to date a lot easier. 
+
+The current mach64 branch is only using one template in the driver. 
+
+Check out the r128 driver from the trunk, for a good example. Notice there are files in there such as _r128_tritmp.h_. This is a template that gets included in _r128_tris.c_. What it does basically is consolidate code that is largely reproduced over several functions, so that you set a few macros. For example: 
+
+   * [[!format txt """
+#define IND (R128_TWOSIDE_BIT)
+#define TAG(x) x##_twoside
+"""]]
+followed by 
+
+   * [[!format txt """
+#include "r128_tritmp.h"
+"""]]
+Notice the inline function's name defined in _r128_tritmp.h_ is the result of the TAG macro, as well the function's content is dependent on what IND value is defined. So essentially the inline function is a template for various functions that have a bit in common. That way you consolidate common code and keep things consistent. 
+
+Look at e.g. [[xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/r128.h|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/r128.h?rev=HEAD&content-type=text/vnd.viewcvs-markup]] though. That's the template architecture at its beauty. Most of the code is shared between the drivers, customized with a few defines. Compare that to the duplication and inconsistency before. 
diff --git a/DRMTemplates.moin b/DRMTemplates.moin
deleted file mode 100644
index 87d765d..0000000
--- a/DRMTemplates.moin
+++ /dev/null
@@ -1,126 +0,0 @@
-== What is templated DRM code? ==
-
-It was first discussed in a email about what Gareth had done to bring up the mach64 kernel module.
-
-Not wanting to simply copy-and-paste another version of ''_drv.[ch]'', ''_context.c'', ''_bufs.s'' and so on, Gareth did some refactoring along the lines of what him and Rik Faith had discussed a long time ago.
-
-This is very much along the lines of a lot of Mesa code, where there exists a template header file that can be customized with a few defines. At the time, it was done ''_drv.c'' and ''_context.c'', creating ''driver_tmp.h'' and ''context_tmp.h'' that could be used to build up the core module.
-
-An inspection of ''mach64_drv.c'' on the mach64-0-0-1-branch reveals the following code:
-
-  {{{
-#define DRIVER_AUTHOR           "Gareth Hughes"
-
-#define DRIVER_NAME             "mach64"
-#define DRIVER_DESC             "DRM module for the ATI Rage Pro"
-#define DRIVER_DATE             "20001203"
-
-#define DRIVER_MAJOR            1
-#define DRIVER_MINOR            0
-#define DRIVER_PATCHLEVEL       0
-
-
-static drm_ioctl_desc_t         mach64_ioctls[] = {
-	[DRM_IOCTL_NR(DRM_IOCTL_VERSION)]       = { mach64_version,    0, 0 },
-	[DRM_IOCTL_NR(DRM_IOCTL_GET_UNIQUE)]    = { drm_getunique,     0, 0 },
-	[DRM_IOCTL_NR(DRM_IOCTL_GET_MAGIC)]     = { drm_getmagic,      0, 0 },
-	[DRM_IOCTL_NR(DRM_IOCTL_IRQ_BUSID)]     = { drm_irq_busid,     0, 1 },
-
-	[DRM_IOCTL_NR(DRM_IOCTL_SET_UNIQUE)]    = { drm_setunique,     1, 1 },
-	[DRM_IOCTL_NR(DRM_IOCTL_BLOCK)]         = { drm_block,         1, 1 },
-	[DRM_IOCTL_NR(DRM_IOCTL_UNBLOCK)]       = { drm_unblock,       1, 1 },
-	[DRM_IOCTL_NR(DRM_IOCTL_AUTH_MAGIC)]    = { drm_authmagic,     1, 1 },
-	[DRM_IOCTL_NR(DRM_IOCTL_ADD_MAP)]       = { drm_addmap,        1, 1 },
-
-	[DRM_IOCTL_NR(DRM_IOCTL_ADD_BUFS)]      = { drm_addbufs,       1, 1 },
-	[DRM_IOCTL_NR(DRM_IOCTL_MARK_BUFS)]     = { drm_markbufs,      1, 1 },
-	[DRM_IOCTL_NR(DRM_IOCTL_INFO_BUFS)]     = { drm_infobufs,      1, 0 },
-	[DRM_IOCTL_NR(DRM_IOCTL_MAP_BUFS)]      = { drm_mapbufs,       1, 0 },
-	[DRM_IOCTL_NR(DRM_IOCTL_FREE_BUFS)]     = { drm_freebufs,      1, 0 },
-
-	[DRM_IOCTL_NR(DRM_IOCTL_ADD_CTX)]       = { mach64_addctx,     1, 1 },
-	[DRM_IOCTL_NR(DRM_IOCTL_RM_CTX)]        = { mach64_rmctx,      1, 1 },
-	[DRM_IOCTL_NR(DRM_IOCTL_MOD_CTX)]       = { mach64_modctx,     1, 1 },
-	[DRM_IOCTL_NR(DRM_IOCTL_GET_CTX)]       = { mach64_getctx,     1, 0 },
-	[DRM_IOCTL_NR(DRM_IOCTL_SWITCH_CTX)]    = { mach64_switchctx,  1, 1 },
-	[DRM_IOCTL_NR(DRM_IOCTL_NEW_CTX)]       = { mach64_newctx,     1, 1 },
-	[DRM_IOCTL_NR(DRM_IOCTL_RES_CTX)]       = { mach64_resctx,     1, 0 },
-	[DRM_IOCTL_NR(DRM_IOCTL_ADD_DRAW)]      = { drm_adddraw,       1, 1 },
-	[DRM_IOCTL_NR(DRM_IOCTL_RM_DRAW)]       = { drm_rmdraw,        1, 1 },
-	[DRM_IOCTL_NR(DRM_IOCTL_LOCK)]          = { mach64_lock,       1, 0 },
-	[DRM_IOCTL_NR(DRM_IOCTL_UNLOCK)]        = { mach64_unlock,     1, 0 },
-	[DRM_IOCTL_NR(DRM_IOCTL_FINISH)]        = { drm_finish,        1, 0 },
-
-#if defined(CONFIG_AGP) || defined(CONFIG_AGP_MODULE)
-	[DRM_IOCTL_NR(DRM_IOCTL_AGP_ACQUIRE)]   = { drm_agp_acquire,   1, 1 },
-	[DRM_IOCTL_NR(DRM_IOCTL_AGP_RELEASE)]   = { drm_agp_release,   1, 1 },
-	[DRM_IOCTL_NR(DRM_IOCTL_AGP_ENABLE)]    = { drm_agp_enable,    1, 1 },
-	[DRM_IOCTL_NR(DRM_IOCTL_AGP_INFO)]      = { drm_agp_info,      1, 0 },
-	[DRM_IOCTL_NR(DRM_IOCTL_AGP_ALLOC)]     = { drm_agp_alloc,     1, 1 },
-	[DRM_IOCTL_NR(DRM_IOCTL_AGP_FREE)]      = { drm_agp_free,      1, 1 },
-	[DRM_IOCTL_NR(DRM_IOCTL_AGP_BIND)]      = { drm_agp_bind,      1, 1 },
-	[DRM_IOCTL_NR(DRM_IOCTL_AGP_UNBIND)]    = { drm_agp_unbind,    1, 1 },
-#endif
-
-	[DRM_IOCTL_NR(DRM_IOCTL_MACH64_INIT)]   = { mach64_dma_init,   1, 1 },
-	[DRM_IOCTL_NR(DRM_IOCTL_MACH64_CLEAR)]  = { mach64_dma_clear,  1, 0 },
-	[DRM_IOCTL_NR(DRM_IOCTL_MACH64_SWAP)]   = { mach64_dma_swap,   1, 0 },
-	[DRM_IOCTL_NR(DRM_IOCTL_MACH64_IDLE)]   = { mach64_dma_idle,   1, 0 },
-};
-
-#define DRIVER_IOCTL_COUNT      DRM_ARRAY_SIZE( mach64_ioctls )
-
-#define HAVE_CTX_BITMAP         1
-
-#define TAG(x) mach64_##x
-#include "driver_tmp.h"
-}}}
-
-And that's all you need. A trivial amount of code is needed for the context handling:
-
-  {{{
-#define __NO_VERSION__
-#include "drmP.h"
-#include "mach64_drv.h"
-
-#define TAG(x) mach64_##x
-#include "context_tmp.h"
-}}}
-
-And as far as I can tell, the only thing that's keeping this out of ''mach64_drv.c'' is the '''__NO_VERSION__''', which is a 2.2 thing and is not used in 2.4 (right?).
-
-To enable all the context bitmap code, we see the
-  {{{
-#define HAVE_CTX_BITMAP 1
-}}}
-
- To enable things like AGP, MTRR's and DMA management, the author simply needs to define the correct symbols. With less than five minutes of mach64-specific coding, I had a full kernel module that would do everything a basic driver requires -- enough to bring up a software-fallback driver. The above code is all that is needed for the tdfx driver, with appropriate name changes. Indeed, any card that doesn't do kernel-based DMA can have a fully functional DRM module with the above code. DMA-based drivers will need more, of course.
-
-The plan is to extend this to basic DMA setup and buffer management, so that the creation of PCI or AGP  DMA buffers, installation of IRQs and so on is as trivial as this. What will then be left is the hardware-specific parts of the DRM module that deal with actually programming the card to do things, such as setting state for rendering or kicking off DMA buffers. That is, the interesting stuff.
-
-A couple of points:
-
-  * Why was it done like this, and not with C++ features like virtual functions (i.e. why don't I do it in C++)? Because it's the Linux kernel, dammit! No offense to any C++ fan who may be reading this :-) Besides, a lot of the initialization is order-dependent, so inserting or removing blocks of code with '''#defines''' is a nice way to achieve the desired result, at least in this situation.
-  * Much of the core DRM code (like ''bufs.c'', ''context.c'' and ''dma.c'') will essentially move into these template headers. I feel that this is a better way to handle the common code. Take ''context.c'' as a trivial example -- the i810, mga, tdfx, r128 and mach64 drivers have exactly the same code, with name changes. Take ''bufs.c'' as a slightly more interesting example -- some drivers map only AGP buffers, some do both AGP and PCI, some map differently depending on their DMA queue management and so on. Again, rather than cutting and pasting the code from drm_addbufs into my driver, removing the sections I don't need and leaving it at that, I think keeping the core functionality in ''bufs_tmp.h'' and allowing this to be customized at compile time is a cleaner and more maintainable solution.
-
-This it has the possibility to make keeping the other OS's code up to date a lot easier.
-
-The current mach64 branch is only using one template in the driver.
-
-Check out the r128 driver from the trunk, for a good example. Notice there are files in there such as ''r128_tritmp.h''. This is a template that gets included in ''r128_tris.c''. What it does basically is consolidate code that is largely reproduced over several functions, so that you set a few macros. For example:
-
-  {{{
-#define IND (R128_TWOSIDE_BIT)
-#define TAG(x) x##_twoside
-}}}
-
-followed by
-
-  {{{
-#include "r128_tritmp.h"
-}}}
-
-Notice the inline function's name defined in ''r128_tritmp.h'' is the result of the TAG macro, as well the function's content is dependent on what IND value is defined. So essentially the inline function is a template for various functions that have a bit in common. That way you consolidate common code and keep things consistent.
-
-Look at e.g. [[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/r128.h?rev=HEAD&content-type=text/vnd.viewcvs-markup|xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/r128.h]] though. That's the template architecture at its beauty. Most of the code is shared between the drivers, customized with a few defines. Compare that to the duplication and inconsistency before.
-
diff --git a/DanMcCabe.mdwn b/DanMcCabe.mdwn
new file mode 100644
index 0000000..73630b7
--- /dev/null
+++ b/DanMcCabe.mdwn
@@ -0,0 +1,26 @@
+
+
+## Dan McCabe
+Email
+: zen3d.linux *AT* gmail *DOT* com 
+
+Homepage
+: TBD 
+
+Interests
+: 
+      * 3D graphics hardware architectures 
+      * 3D graphics system software 
+      * 3D graphics applications 
+      * Physics simulation 
+      * Audio processing 
+      * Playing electric guitar with LOTS of distortion 
+
+
+I am OS agnostic and a contrarian, although most of my professional career has been spent within the sphere of influence of a certain small software company in Washington State. In all likelihood, you have probably used software that I have written. But take that with a grain of salt. I certainly do. 
+
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/DanMcCabe.moin b/DanMcCabe.moin
deleted file mode 100644
index b475c62..0000000
--- a/DanMcCabe.moin
+++ /dev/null
@@ -1,18 +0,0 @@
-== Dan McCabe ==
-
- Email:: zen3d.linux *AT* gmail *DOT* com
-
- Homepage:: TBD
-
- Interests::
-   * 3D graphics hardware architectures
-   * 3D graphics system software
-   * 3D graphics applications
-   * Physics simulation
-   * Audio processing
-   * Playing electric guitar with LOTS of distortion
-
-I am OS agnostic and a contrarian, although most of my professional career has been spent within the sphere of influence of a certain small software company in Washington State. In all likelihood, you have probably used software that I have written. But take that with a grain of salt. I certainly do.
-
-----
-CategoryHomepage
diff --git a/DanielStone.mdwn b/DanielStone.mdwn
new file mode 100644
index 0000000..cc568b1
--- /dev/null
+++ b/DanielStone.mdwn
@@ -0,0 +1,2 @@
+
+'hacker, iterant idiot' 
diff --git a/DanielStone.moin b/DanielStone.moin
deleted file mode 100644
index 47efa29..0000000
--- a/DanielStone.moin
+++ /dev/null
@@ -1 +0,0 @@
-'hacker, iterant idiot'
diff --git a/DanilKutkevich.mdwn b/DanilKutkevich.mdwn
new file mode 100644
index 0000000..0015958
--- /dev/null
+++ b/DanilKutkevich.mdwn
@@ -0,0 +1,29 @@
+
+
+## Danil Kutkevich
+
+
+<div style="display:none">Email
+:  
+
+</div>Homepage
+: 
+[[http://www.kutkevich.org/|http://www.kutkevich.org/]] 
+
+
+Interests
+: 
+      * Free Software 
+      * Sport 
+
+
+
+### My Bookmarks
+
+* [[OpenGLFeatures|OpenGLFeatures]] 
+* [[ATIRadeon|ATIRadeon]] 
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/DanilKutkevich.moin b/DanilKutkevich.moin
deleted file mode 100644
index bc2176b..0000000
--- a/DanilKutkevich.moin
+++ /dev/null
@@ -1,18 +0,0 @@
-== Danil Kutkevich ==
-
-{{{#!wiki comment/dotted
- Email:: 
-}}}
- Homepage:: http://www.kutkevich.org/
-
- Interests::
-   * Free Software
-   * Sport
-
-=== My Bookmarks ===
-
- * [[OpenGLFeatures]]
- * [[ATIRadeon]]
-
-----
-CategoryHomepage
diff --git a/DaveAirlie.mdwn b/DaveAirlie.mdwn
new file mode 100644
index 0000000..71c962a
--- /dev/null
+++ b/DaveAirlie.mdwn
@@ -0,0 +1,29 @@
+
+
+## Dave Airlie
+
+[[!img http://www.skynet.ie/~airlied/pics/airlied.gif] 
+
+Maintaining i810/mach64 along with Linux 2.6 DRM maintainer. 
+Email
+: airlied at linux dot ie 
+
+Homepage
+: 
+[[http://www.skynet.ie/~airlied/|http://www.skynet.ie/~airlied/]] 
+
+
+Interests
+: 
+         * Linux 2.6 DRM Maintainer 
+         * I830 Driver 
+         * Mach64 Driver 
+         * I810 Driver 
+         * Radeon Driver 
+
+
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/DaveAirlie.moin b/DaveAirlie.moin
deleted file mode 100644
index 561767d..0000000
--- a/DaveAirlie.moin
+++ /dev/null
@@ -1,22 +0,0 @@
-== Dave Airlie ==
-
-{{http://www.skynet.ie/~airlied/pics/airlied.gif}}
-
-Maintaining i810/mach64 along with Linux 2.6 DRM maintainer.
-
- Email:: airlied at linux dot ie
-
- Homepage:: http://www.skynet.ie/~airlied/
-
- Interests::
-    * Linux 2.6 DRM Maintainer
-    * I830 Driver
-    * Mach64 Driver
-    * I810 Driver
-    * Radeon Driver
-
-----
-CategoryHomepage
-
-
-
diff --git a/DenisKrivosheev.mdwn b/DenisKrivosheev.mdwn
new file mode 100644
index 0000000..14e0476
--- /dev/null
+++ b/DenisKrivosheev.mdwn
@@ -0,0 +1,22 @@
+
+
+## xxx
+Email
+: 
+[[xxx@xxx.com|mailto:xxx@xxx.com]] 
+
+
+Homepage
+: ... 
+
+Interests
+: 
+      * ...  
+      * ... 
+
+
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/DenisKrivosheev.moin b/DenisKrivosheev.moin
deleted file mode 100644
index 809d367..0000000
--- a/DenisKrivosheev.moin
+++ /dev/null
@@ -1,12 +0,0 @@
-== xxx ==
-
- Email:: xxx@xxx.com
-
- Homepage:: ...
-
- Interests::
-   * ... 
-   * ...
-
-----
-CategoryHomepage
diff --git a/DevelopingForMesa.mdwn b/DevelopingForMesa.mdwn
new file mode 100644
index 0000000..f8d3d5b
--- /dev/null
+++ b/DevelopingForMesa.mdwn
@@ -0,0 +1,30 @@
+
+
+# Developing for Mesa
+
+Want to test your application on mesa? Please follow these instructions. 
+
+
+## Testing
+
+* Install your distribution mesa packages 
+* Make sure you're running mesa (glxinfo) 
+* Test your app 
+
+## Bug reporting
+
+If you app is broken in some way: 
+
+* Try mesa from git either built from sources or using distro-provided packages 
+* Tell us on IRC (#dri-devel on freenode), you may get a fast solution or a temporary work around. 
+* If it is a bug, please report it on [[https://bugs.freedesktop.org|https://bugs.freedesktop.org]]: 
+   * Product: Mesa 
+   * Component: Choose the driver you are using (as reported by glxinfo) 
+   * Version: Write the first to be known broken 
+* Fill in your bug report. Include a description of the problem, Xorg logs, dmesg output, any mesa output and if it is applicable, please enclose a picture of the problem.  Identify how to reproduce the problem.  If possible, identify a small test-case (either in your application or a small demo). 
+Now if you're brave enough to do so, write a piglit test (you can ask for help on IRC) to expose the situation or feature combinations that are problematic. 
+
+
+## Conclusion
+
+Thanks for caring about Mesa and open source drivers. 
diff --git a/DevelopingForMesa.moin b/DevelopingForMesa.moin
deleted file mode 100644
index c21127a..0000000
--- a/DevelopingForMesa.moin
+++ /dev/null
@@ -1,26 +0,0 @@
-= Developing for Mesa =
-
-Want to test your application on mesa? Please follow these instructions.
-
-== Testing ==
-
- * Install your distribution mesa packages
- * Make sure you're running mesa (glxinfo)
- * Test your app
-
-== Bug reporting ==
-
-If you app is broken in some way:
- * Try mesa from git either built from sources or using distro-provided packages
- * Tell us on IRC (#dri-devel on freenode), you may get a fast solution or a temporary work around.
- * If it is a bug, please report it on https://bugs.freedesktop.org:
-  * Product: Mesa
-  * Component: Choose the driver you are using (as reported by glxinfo)
-  * Version: Write the first to be known broken
- * Fill in your bug report. Include a description of the problem, Xorg logs, dmesg output, any mesa output and if it is applicable, please enclose a picture of the problem.  Identify how to reproduce the problem.  If possible, identify a small test-case (either in your application or a small demo).
-
-Now if you're brave enough to do so, write a piglit test (you can ask for help on IRC) to expose the situation or feature combinations that are problematic.
-
-== Conclusion ==
-
-Thanks for caring about Mesa and open source drivers.
diff --git a/Development.mdwn b/Development.mdwn
new file mode 100644
index 0000000..274bd63
--- /dev/null
+++ b/Development.mdwn
@@ -0,0 +1,39 @@
+
+
+## Development
+
+General resources: 
+
+   * [[GettingStarted|GettingStarted]]: getting started with DRI development 
+   * [[DriArchitecture|DriArchitecture]]: the DRI architecture explained 
+   * [[CategoryGlossary|CategoryGlossary]]: glossary 
+   * [[References|References]]: links to other sites 
+   * [[CategoryHardware|CategoryHardware]]: hardware specific information 
+   * [[CommunicationSchemes|CommunicationSchemes]] 
+Community/contact information: 
+
+   * [[MailingLists|MailingLists]] 
+   * [[BugZilla|BugZilla]] [[Bugzilla Bug Reporting System at freedesktop.org|http://bugs.freedesktop.org]] 
+   * [[IRCMeetings|IRCMeetings]] 
+   * [[CurrentDevelopers|CurrentDevelopers]] 
+   * [[DRI Project Homepage at Sourceforge|http://sourceforge.net/projects/dri/]] (hosts mailing lists at the moment) 
+Policy issues: 
+
+   * [[BinaryCompatability|BinaryCompatability]]: binary compatibility policy 
+   * [[CvsPolicy|CvsPolicy]]: CVS repository policy - note that GIT is nowadays used for [[Mesa & DRI drivers|http://cgit.freedesktop.org/mesa/mesa/]] (inside mesa code) and [[DRM kernel drivers|http://cgit.freedesktop.org/mesa/drm/]] (Direct Rendering Manager) 
+   * [[NewDeveloperAccount|NewDeveloperAccount]]: how new accounts get added to the DRI project. 
+   * [[NDA|NDA]]: non disclosure agreements 
+Special topics: 
+
+   * [[DRILocking|DRILocking]] 
+   * [[DRI2|DRI2]] - information about DRI2 
+   * [[DriWithoutX|DriWithoutX]]: DRI without an X server 
+   * [[DrmModesetting|DrmModesetting]]: Enhancing DRM with modesetting and output configuration capabilities 
+   * [[RadeonsiToDo|RadeonsiToDo]]: Radeonsi To Do list 
+   * [[R600ToDo|R600ToDo]]: R600 To Do list 
+   * [[R300ToDo|R300ToDo]]: R300 To Do list 
+   * Benchmarks: [[R300Benchmark|R300Benchmark]], [[AGPBenchmarks|AGPBenchmarks]] 
+   * [[PowerManagement|PowerManagement]]: power management support 
+   * [[StereoSupport|StereoSupport]]: stereoscopic 3D support 
+   * [[ConfigurationInfrastructure|ConfigurationInfrastructure]]: (GUI) configuration of the 3D drivers 
+See also [[Documentation|Documentation]]. 
diff --git a/Development.moin b/Development.moin
deleted file mode 100644
index acbf502..0000000
--- a/Development.moin
+++ /dev/null
@@ -1,38 +0,0 @@
-== Development ==
-
-General resources:
-  * GettingStarted: getting started with DRI development
-  * DriArchitecture: the DRI architecture explained
-  * CategoryGlossary: glossary
-  * [[References]]: links to other sites
-  * CategoryHardware: hardware specific information
-  * CommunicationSchemes
-
-Community/contact information:
-  * MailingLists
-  * BugZilla [[http://bugs.freedesktop.org|Bugzilla Bug Reporting System at freedesktop.org]]
-  * [[IRCMeetings]]
-  * CurrentDevelopers
-  * [[http://sourceforge.net/projects/dri/|DRI Project Homepage at Sourceforge]] (hosts mailing lists at the moment)
-
-Policy issues:
-  * BinaryCompatability: binary compatibility policy
-  * CvsPolicy: CVS repository policy - note that GIT is nowadays used for [[http://cgit.freedesktop.org/mesa/mesa/|Mesa & DRI drivers]] (inside mesa code) and [[http://cgit.freedesktop.org/mesa/drm/|DRM kernel drivers]] (Direct Rendering Manager)
-  * NewDeveloperAccount: how new accounts get added to the DRI project.
-  * [[NDA]]: non disclosure agreements
-  
-Special topics:
-
-  * [[DRILocking]]
-  * [[DRI2]] - information about DRI2
-  * [[DriWithoutX]]: DRI without an X server
-  * [[DrmModesetting]]: Enhancing DRM with modesetting and output configuration capabilities
-  * [[RadeonsiToDo]]: Radeonsi To Do list
-  * [[R600ToDo]]: R600 To Do list
-  * [[R300ToDo]]: R300 To Do list
-  * Benchmarks: R300Benchmark, [[AGPBenchmarks]]
-  * PowerManagement: power management support
-  * StereoSupport: stereoscopic 3D support
-  * ConfigurationInfrastructure: (GUI) configuration of the 3D drivers
-
-See also [[Documentation]].
diff --git a/Direct3D.mdwn b/Direct3D.mdwn
new file mode 100644
index 0000000..838cf83
--- /dev/null
+++ b/Direct3D.mdwn
@@ -0,0 +1,11 @@
+
+
+## Direct3D (D3D)
+
+Microsoft's proprietary 3D API. It was originally written by Render``Morphics and was acquired by Microsoft in 1995. Direct3D is available only on the Windows series of operating systems. Direct3D  has captured the mindshare among most Windows developers, mostly due to the complete lack of any viable alternatives on the PC platform. Microsoft has been pushing Direct3D over OpenGL for many years, sometimes against the opposing wishes of Windows developers. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/Direct3D.moin b/Direct3D.moin
deleted file mode 100644
index 37d350b..0000000
--- a/Direct3D.moin
+++ /dev/null
@@ -1,12 +0,0 @@
-== Direct3D (D3D) ==
-
-Microsoft's proprietary 3D API. It was originally written by
-Render``Morphics and was acquired by Microsoft in 1995. Direct3D is available
-only on the Windows series of operating systems. Direct3D  has captured the
-mindshare among most Windows developers, mostly due to the complete lack of any
-viable alternatives on the PC platform. Microsoft has been pushing Direct3D
-over OpenGL for many years, sometimes against the opposing wishes of Windows
-developers.
-
-----
-CategoryGlossary
diff --git a/DirectFB.mdwn b/DirectFB.mdwn
new file mode 100644
index 0000000..135685f
--- /dev/null
+++ b/DirectFB.mdwn
@@ -0,0 +1,20 @@
+
+
+## DirectFB
+
+DirectFB is a thin library that provides hardware graphics acceleration, input device handling and abstraction, integrated windowing system with support for translucent windows and multiple display layers on top of the Linux Framebuffer Device. It is a complete hardware abstraction layer with software fallbacks for every graphics operation that is not supported by the underlying hardware. 
+
+
+### Resources
+
+   * [[DirectFB project homepage|http://www.directfb.org/]] 
+   * [[DirectFB on DRI|http://www.directfb.org/directfbgl.xml]] 
+
+### See also
+
+   * DriWithoutX 
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/DirectFB.moin b/DirectFB.moin
deleted file mode 100644
index 88714c6..0000000
--- a/DirectFB.moin
+++ /dev/null
@@ -1,19 +0,0 @@
-== DirectFB ==
-
-DirectFB is a thin library that provides hardware graphics acceleration, input
-device handling and abstraction, integrated windowing system with support for
-translucent windows and multiple display layers on top of the Linux Framebuffer
-Device. It is a complete hardware abstraction layer with software fallbacks for
-every graphics operation that is not supported by the underlying hardware.
-
-=== Resources ===
-
-  * [[http://www.directfb.org/|DirectFB project homepage]]
-  * [[http://www.directfb.org/directfbgl.xml|DirectFB on DRI]]
-
-=== See also ===
-
-  * DriWithoutX
-
-----
-CategoryGlossary
diff --git a/DirectRendering.mdwn b/DirectRendering.mdwn
new file mode 100644
index 0000000..04b94ff
--- /dev/null
+++ b/DirectRendering.mdwn
@@ -0,0 +1,11 @@
+
+
+## Direct Rendering
+
+Direct Rendering lets an OpenGL client write to the 3D hardware without passing commands through the X Server. This is much faster than [[IndirectRendering|IndirectRendering]] but it can be very complicated to achieve, especially on multi-user systems like Unix. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/DirectRendering.moin b/DirectRendering.moin
deleted file mode 100644
index 121c163..0000000
--- a/DirectRendering.moin
+++ /dev/null
@@ -1,6 +0,0 @@
-== Direct Rendering ==
-
-Direct Rendering lets an OpenGL client write to the 3D hardware without passing commands through the X Server. This is much faster than IndirectRendering but it can be very complicated to achieve, especially on multi-user systems like Unix.
-
-----
-CategoryGlossary
diff --git a/DirectRenderingToRedirectedWindows.mdwn b/DirectRenderingToRedirectedWindows.mdwn
new file mode 100644
index 0000000..429def7
--- /dev/null
+++ b/DirectRenderingToRedirectedWindows.mdwn
@@ -0,0 +1,33 @@
+
+This page lays out a plan how correctly handling direct rendering (and consequently accelerated indirect rendering with AIGLX) to windows redirected using the Composite extension could be implemented. Parts of it may also apply to rendering to GLXPixmaps, implementing GLX_EXT_texture_from_pixmap with direct texturing out of pixmap memory or providing per-drawable back and depth buffers. Others are encouraged to add or refine items, but please use the dri-devel mailing list for discussion to avoid cluttering up this page. 
+
+The plan is structured by various events and the flow of control between the DRI components when they occur. 
+
+Work on a prototype implementation of this is happening in airlied and krh's xserver and xf86-video-intel git repos. 
+
+* Pixmap allocation in X server 
+   * EXA/glucose/... calls 2D driver hook. 
+   * 2D driver allocates from unified memory manager, e.g. TTM. May need to share memory manager objects between smaller pixmaps for performance. 
+* DRI drawable creation 
+   * Client calls new variant of DRICreateDrawable which informs the DRI module that the client can handle redirection. 
+   * DRI module calls 2D driver hook to allocate renderbuffers (only covering the bounding box of the drawable cliprects for back and depth) and retrieve memory manager IDs. May want to allow for several back buffers. 
+   * DRI module pushes memory manager IDs (as opaque u64s) and additional information (offset from start of each memory manager object, pitch, drawable deltas from upper left corner of backing pixmap, ?) to DRM via [[UpdateDrawableInfo|UpdateDrawableInfo]]. 
+* Context binding 
+   * Client retrieves memory manager IDs and additional information from DRM. 
+* Buffer swap 
+   * Client blits back buffer to drawable backing pixmap. 
+   * May want to track swap counter, e.g. for flipping when the drawable occupies the whole backing pixmap or for several back buffers. 
+   * 3D driver makes Damage extension request to generate damage. 
+* glFlush 
+   * When rendering to front buffer, 3D driver makes Damage extension request to generate damage. 
+* Window resizing 
+   * DRI module repeats appropriate steps (reallocate renderbuffers if necessary and push new MM IDs and additional info to DRM) from DRI drawable creation item. 
+   * DRI module and/or 2D driver may reduce number of renderbuffer allocations, e.g. by reducing granularity of size deltas, for performance. 
+   * 3D driver repeats appropriate steps from Context binding item. 
+* Window (un)redirection 
+   * DRI module (de)allocates renderbuffers and pushes/pulls memory manager IDs and additional information to/from the DRM. 
+   * **XXX**: Where to hook this into? KRH: We need notification when a drawble get new backing BOs anyway - e.g. when a redirected window pixmap is resized. Unredirection is pretty much the same case: we move the drawable from one set of backing BOs (those backing the redirected window) to another (those backing the root window). 
+* X hardware rendering 
+   * 2D driver binds pixmap memory manager objects into GPU space in accel hooks. 
+* X software rendering 
+   * 2D driver maps pixmap memory manager objects into CPU space in (equivalent of) [[PrepareAccess|PrepareAccess]] hook. 
+\ No newline at end of file
diff --git a/DirectRenderingToRedirectedWindows.moin b/DirectRenderingToRedirectedWindows.moin
deleted file mode 100644
index 07d647e..0000000
--- a/DirectRenderingToRedirectedWindows.moin
+++ /dev/null
@@ -1,32 +0,0 @@
-This page lays out a plan how correctly handling direct rendering (and consequently accelerated indirect rendering with AIGLX) to windows redirected using the Composite extension could be implemented. Parts of it may also apply to rendering to GLXPixmaps, implementing GLX_EXT_texture_from_pixmap with direct texturing out of pixmap memory or providing per-drawable back and depth buffers. Others are encouraged to add or refine items, but please use the dri-devel mailing list for discussion to avoid cluttering up this page.
-
-The plan is structured by various events and the flow of control between the DRI components when they occur.
-
-Work on a prototype implementation of this is happening in airlied and krh's xserver and xf86-video-intel git repos.
-
- * Pixmap allocation in X server
-  * EXA/glucose/... calls 2D driver hook.
-  * 2D driver allocates from unified memory manager, e.g. TTM. May need to share memory manager objects between smaller pixmaps for performance.
- * DRI drawable creation
-  * Client calls new variant of DRICreateDrawable which informs the DRI module that the client can handle redirection.
-  * DRI module calls 2D driver hook to allocate renderbuffers (only covering the bounding box of the drawable cliprects for back and depth) and retrieve memory manager IDs. May want to allow for several back buffers.
-  * DRI module pushes memory manager IDs (as opaque u64s) and additional information (offset from start of each memory manager object, pitch, drawable deltas from upper left corner of backing pixmap, ?) to DRM via UpdateDrawableInfo.
- * Context binding
-  * Client retrieves memory manager IDs and additional information from DRM.
- * Buffer swap
-  * Client blits back buffer to drawable backing pixmap.
-  * May want to track swap counter, e.g. for flipping when the drawable occupies the whole backing pixmap or for several back buffers.
-  * 3D driver makes Damage extension request to generate damage.
- * glFlush
-  * When rendering to front buffer, 3D driver makes Damage extension request to generate damage.
- * Window resizing
-  * DRI module repeats appropriate steps (reallocate renderbuffers if necessary and push new MM IDs and additional info to DRM) from DRI drawable creation item.
-  * DRI module and/or 2D driver may reduce number of renderbuffer allocations, e.g. by reducing granularity of size deltas, for performance.
-  * 3D driver repeats appropriate steps from Context binding item.
- * Window (un)redirection
-  * DRI module (de)allocates renderbuffers and pushes/pulls memory manager IDs and additional information to/from the DRM.
-  * '''XXX''': Where to hook this into? KRH: We need notification when a drawble get new backing BOs anyway - e.g. when a redirected window pixmap is resized. Unredirection is pretty much the same case: we move the drawable from one set of backing BOs (those backing the redirected window) to another (those backing the root window).
- * X hardware rendering
-  * 2D driver binds pixmap memory manager objects into GPU space in accel hooks.
- * X software rendering
-  * 2D driver maps pixmap memory manager objects into CPU space in (equivalent of) PrepareAccess hook.
diff --git a/Documentation.mdwn b/Documentation.mdwn
new file mode 100644
index 0000000..cf8d3ec
--- /dev/null
+++ b/Documentation.mdwn
@@ -0,0 +1,55 @@
+
+
+# Documentation
+
+
+## End-User Documentation
+
+   * [[Building|Building]] the DRI Instructions for building the DRI on your own machine. 
+   * [[DriTroubleshooting|DriTroubleshooting]] This page covers the most common issues with configuring the DRI for Linux and FreeBSD. 
+   * [[ConfigurationInfrastructure|ConfigurationInfrastructure]] This page describes the configuration file format and contains links to a configuration GUI. 
+   * [[DriverFiles|DriverFiles]] This page describes the files that make up the 2D and 3D drivers and DRM for each driver. 
+   * [[DRI Debugging Guide|http://gatos.sf.net/dri-debug.php]] This guide explains how to debug a DRI installation that is not working. Thanks to Vladimir Dergachev and the LiViD folks for putting it together. 
+
+## General Developer Documentation
+
+   * [[Development|Development]] This page collects various information related to development of the DRI. 
+   * [[Linux DRM Developer's Guide|http://www.kernel.org/doc/htmldocs/drm/]] Incomplete, but much more recent (2009) than most of the other docs here - new enough to mention TTM and GEM. 
+   * [[Introduction to the Direct Rendering Infrastructure|http://dri.sourceforge.net/doc/DRIintro.html]] This document was written for a tutorial session at [[LinuxWorld|LinuxWorld]] 2000 (San Jose) and explains the DRI at a high level. 
+   * [[CvsBranches|CvsBranches]] This page lists the active branches of DRI CVS. 
+   * [[CvsPolicy|CvsPolicy]] This document explains the rules for DRI development and how CVS branches are to be used. 
+   * [[Managing Graphics Hardware Vendor Relationships in the Linux Developer Community|http://dri.sourceforge.net/doc/vendor_relationships_paper.html]] A paper presented at the Linux World Conference and Expo in San Jose, CA on March 4, 1999. This paper offers guidelines to anyone who is responsible for establishing or maintaining business relationships. Although the paper is written to describe a specific type of business relationship, it can be applicable to many similar situations. 
+
+## High-Level Design Documents and Diagrams
+
+   * [[Data Flow Diagram - with explanation|http://dri.sourceforge.net/doc/dri_data_flow.html]] 
+   * [[Control Flow Diagram - with explanation|http://dri.sourceforge.net/doc/dri_control_flow.html]] 
+   * [[Data Flow Diagram|http://dri.sourceforge.net/doc/images/data_flow.jpg]] 
+   * [[Control Flow Diagram|http://dri.sourceforge.net/doc/images/control_flow.jpg]] 
+   * [[Control Flow Diagram (Poster Size)|http://dri.sourceforge.net/doc/images/control_flow_poster.jpg]] 
+   * [[A Multipipe Direct Rendering Architecture for 3D, High-Level Design Document|http://dri.sourceforge.net/doc/design_high_level.html]] 
+
+## Low-Level Design Documents
+
+   * [[Direct Rendering Infrastructure, Low Level Design Document|http://dri.sourceforge.net/doc/design_low_level.html]] 
+   * [[The Direct Rendering Manager, Kernel Support for the Direct Rendering Infrastructure|http://dri.sourceforge.net/doc/drm_low_level.html]] 
+   * [[Hardware Locking for the Direct Rendering Infrastructure|http://dri.sourceforge.net/doc/hardware_locking_low_level.html]] 
+   * [[A Security Analysis of the Direct Rendering Infrastructure|http://dri.sourceforge.net/doc/security_low_level.html]] 
+   * [[DRI Extensions for supporting the Direct Rendering Protocol Specification|http://dri.sourceforge.net/doc/dri_extensions_low_level.txt]] 
+   * [[The DRM Memory manager|http://www.tungstengraphics.com/mm.pdf]] ([[archive|http://web.archive.org/web/20070703024247/http://www.tungstengraphics.com/mm.pdf]]) 
+   * [[TTMFencing|http://dri.freedesktop.org/wiki/TTMFencing]] - Information on fencing and flushes using TTM 
+
+## Other Documents
+
+   * [[Updated Radeon 9000 driver comparison - from R.Scheidegger|http://homepage.hispeed.ch/rscheidegger/atilinux_oct03/ati_linux_comp_oct03.html]] 
+   * [[Original driver comparison|http://homepage.hispeed.ch/rscheidegger/atilinux/ati_linux_comp.html]] 
+   * [[X Server Multi-rendering for OpenGL and PEX|http://www.realitydiluted.com/mirrors/reality.sgi.com/mjk/multirender/multirender.html]] (from SGI doesn't apply to DRI but interesting read) ([[archive|http://web.archive.org/web/20000819072931/http://reality.sgi.com/mjk/multirender/multirender.html]]) 
+
+## Deprecated Documents
+
+These documents refer to older versions of the DRI.  They may still be useful, but they are not entirely accurate anymore.  Most of the information in these is being merged into the wiki. 
+
+   * [[DRI Beginner's Guide|http://dri.sourceforge.net/doc/DRIbeginner.html]] A short, step-by-step guide on how to setup the DRI. Read this guide to get started, then refer to the user guide for more information. 
+   * [[DRI User Guide|http://dri.sourceforge.net/doc/DRIuserguide.html]] This guide explains how to use the DRI and troubleshoot common problems. Please read this document before reporting problems on the DRI mailing lists.  
+   * [[DRI Compilation Guide|http://dri.sourceforge.net/doc/DRIcompile.html]] **This guide is outdated!**. Please see Building for updated information. This guide explains how to download, compile and install the XFree86 X server with DRI 3D acceleration.  
+* [[Compiling Glide3 for the Voodoo 5|http://dri.sourceforge.net/doc/GlideVoodoo5.txt]] Instructions for compiling Glide3 for the Voodoo5 for DRI.  The 3dfx page has better information. 
+\ No newline at end of file
diff --git a/Documentation.moin b/Documentation.moin
deleted file mode 100644
index 6c3db65..0000000
--- a/Documentation.moin
+++ /dev/null
@@ -1,107 +0,0 @@
-= Documentation =
- 
-== End-User Documentation ==
- 
-  * [[Building]] the DRI
- 
-  Instructions for building the DRI on your own machine.
-
-  * DriTroubleshooting
- 
-  This page covers the most common issues with configuring the DRI for Linux and FreeBSD.
- 
-  * ConfigurationInfrastructure
- 
-  This page describes the configuration file format and contains links to a configuration GUI.
-
-  * DriverFiles
-
-  This page describes the files that make up the 2D and 3D drivers and DRM for each driver.
- 
-  * [[http://gatos.sf.net/dri-debug.php|DRI Debugging Guide]]
- 
-  This guide explains how to debug a DRI installation that is not working. Thanks to Vladimir Dergachev and the LiViD folks for putting it together.
- 
-== General Developer Documentation ==
- 
-  * [[Development]]
- 
-  This page collects various information related to development of the DRI.
-
-  * [[http://www.kernel.org/doc/htmldocs/drm/|Linux DRM Developer's Guide]]
-
-  Incomplete, but much more recent (2009) than most of the other docs here - new enough to mention TTM and GEM.
- 
-  * [[http://dri.sourceforge.net/doc/DRIintro.html|Introduction to the Direct Rendering Infrastructure]]
- 
-  This document was written for a tutorial session at LinuxWorld 2000 (San Jose) and explains the DRI at a high level.
-
-  * CvsBranches
- 
-  This page lists the active branches of DRI CVS.
- 
-  * CvsPolicy
- 
-  This document explains the rules for DRI development and how CVS branches are to be used.
- 
-  * [[http://dri.sourceforge.net/doc/vendor_relationships_paper.html|Managing Graphics Hardware Vendor Relationships in the Linux Developer Community]]
- 
-  A paper presented at the Linux World Conference and Expo in San Jose, CA on March 4, 1999. This paper offers guidelines to anyone who is responsible for establishing or maintaining business relationships. Although the paper is written to describe a specific type of business relationship, it can be applicable to many similar situations.
- 
-== High-Level Design Documents and Diagrams ==
- 
-  * [[http://dri.sourceforge.net/doc/dri_data_flow.html|Data Flow Diagram - with explanation]]
- 
-  * [[http://dri.sourceforge.net/doc/dri_control_flow.html|Control Flow Diagram - with explanation]]
- 
-  * [[http://dri.sourceforge.net/doc/images/data_flow.jpg|Data Flow Diagram]]
- 
-  * [[http://dri.sourceforge.net/doc/images/control_flow.jpg|Control Flow Diagram]]
- 
-  * [[http://dri.sourceforge.net/doc/images/control_flow_poster.jpg|Control Flow Diagram (Poster Size)]]
- 
-  * [[http://dri.sourceforge.net/doc/design_high_level.html|A Multipipe Direct Rendering Architecture for 3D, High-Level Design Document]]
- 
-== Low-Level Design Documents ==
- 
-  * [[http://dri.sourceforge.net/doc/design_low_level.html|Direct Rendering Infrastructure, Low Level Design Document]]
- 
-  * [[http://dri.sourceforge.net/doc/drm_low_level.html|The Direct Rendering Manager, Kernel Support for the Direct Rendering Infrastructure]]
- 
-  * [[http://dri.sourceforge.net/doc/hardware_locking_low_level.html|Hardware Locking for the Direct Rendering Infrastructure]]
- 
-  * [[http://dri.sourceforge.net/doc/security_low_level.html|A Security Analysis of the Direct Rendering Infrastructure]]
- 
-  * [[http://dri.sourceforge.net/doc/dri_extensions_low_level.txt|DRI Extensions for supporting the Direct Rendering Protocol Specification]]
- 
-  * [[http://www.tungstengraphics.com/mm.pdf|The DRM Memory manager]] ([[http://web.archive.org/web/20070703024247/http://www.tungstengraphics.com/mm.pdf |archive]])
-
-  * [[http://dri.freedesktop.org/wiki/TTMFencing|TTMFencing]] - Information on fencing and flushes using TTM
- 
-== Other Documents ==
- 
-  * [[http://homepage.hispeed.ch/rscheidegger/atilinux_oct03/ati_linux_comp_oct03.html|Updated Radeon 9000 driver comparison - from R.Scheidegger]]
-  * [[http://homepage.hispeed.ch/rscheidegger/atilinux/ati_linux_comp.html|Original driver comparison]]
-  * [[http://www.realitydiluted.com/mirrors/reality.sgi.com/mjk/multirender/multirender.html|X Server Multi-rendering for OpenGL and PEX]] (from SGI doesn't apply to DRI but interesting read) ([[http://web.archive.org/web/20000819072931/http://reality.sgi.com/mjk/multirender/multirender.html|archive]])
- 
-== Deprecated Documents ==
-
-These documents refer to older versions of the DRI.  They may still be useful, but they are not entirely accurate anymore.  Most of the information in these is being merged into the wiki.
-
-  * [[http://dri.sourceforge.net/doc/DRIbeginner.html|DRI Beginner's Guide]]
- 
-  A short, step-by-step guide on how to setup the DRI. Read this guide to get started, then refer to the user guide for more information.
- 
-  * [[http://dri.sourceforge.net/doc/DRIuserguide.html|DRI User Guide]]
- 
-  This guide explains how to use the DRI and troubleshoot common problems. Please read this document before reporting problems on the DRI mailing lists. 
- 
-  * [[http://dri.sourceforge.net/doc/DRIcompile.html|DRI Compilation Guide]]
- 
-  '''This guide is outdated!'''. Please see Building for updated information.
-
-  This guide explains how to download, compile and install the XFree86 X server with DRI 3D acceleration. 
-
- * [[http://dri.sourceforge.net/doc/GlideVoodoo5.txt|Compiling Glide3 for the Voodoo 5]]
-
- Instructions for compiling Glide3 for the Voodoo5 for DRI.  The 3dfx page has better information.
diff --git a/Download.mdwn b/Download.mdwn
new file mode 100644
index 0000000..bf31d67
--- /dev/null
+++ b/Download.mdwn
@@ -0,0 +1,113 @@
+
+**Contents** [[!toc ]] 
+# Source
+
+The components of the DRI have been moved into their respective upstream repositories.  The DRI drivers reside within Mesa, and the 2D drivers reside in [X.Org [[http://www.x.org/|http://www.x.org/]]].  The remaining component is the DRM, which is maintained in a git tree on freedesktop.org. 
+
+
+## git
+
+To check out the drm code: 
+
+
+[[!format txt """
+git clone git://anongit.freedesktop.org/git/mesa/drm
+"""]]
+
+## cgit
+
+The source and history can be viewed on the web at [[http://cgit.freedesktop.org/mesa/drm/|http://cgit.freedesktop.org/mesa/drm/]] 
+
+
+## Building from git
+
+See the [[Building|Building]] page. 
+
+
+## Releases
+
+The release tarballs are available at [[http://dri.freedesktop.org/libdrm/|http://dri.freedesktop.org/libdrm/]] 
+
+
+# Binaries
+
+
+## Snapshots
+
+**Note: Binary snapshots that are currently available for download are not up-to-date.** They are likely to have bugs that are fixed in CVS/GIT in the mean time. **Please do not report bugs against them.** 
+
+**Note: Binary snapshots are currently not being built.** The value of binary snapshots with modular Xorg is questionable and technical problems make it very hard to build one snapshot that works with both modular and monolithic Xorg. 
+
+Nightly snapshots of the DRI drivers for Linux are available from [[http://dri.freedesktop.org/snapshots/|http://dri.freedesktop.org/snapshots/]]. You need to download and install the correct snapshot for your graphics card and a "common" snapshot in order to get all new DRI features. The "common" snapshot does not need to be updated as frequently as the card-specific snapshot. 
+
+**Note:** If you are using a radeon 8500 or higher (8500, 8700, 9000, 9100, 9200, IGP9100, etc.) choose the r200 shapshot, otherwise choose radeon (7000, 7200, 7500, IGP320, IGP340, etc.). 
+
+**Note:** If you have a i830/45/55 graphics chip you now need the i915 snapshot. The i830 driver is deprecated and no new snapshots are produced for it. 
+
+
+### Upgrading to X.org 6.9 CVS
+
+Binary snapshots only work with a recent X.org X server. If you're running a version of XFree86 or X.org older than 6.9 RC1 then you must install an [[X.org server (Xorg.bz2)|http://dri.freedesktop.org/snapshots/extras/Xorg.bz2]] and [[driver modules (Xorg-modules.tar.bz2)|http://dri.freedesktop.org/snapshots/extras/modules.tar.bz2]]. 
+
+**Note:** It is important that you install X.org _before_ you install the actual binary snapshots. 
+
+**Note:** After installing this upgrade X.org will have no graphics drivers. You need to install the snapshots (both common and the one for your graphics card) in order to make X.org work. 
+
+This is how you install Xorg and modules.tar.bz2: 
+
+* Download `Xorg.bz2` and `modules.tar.bz2`. 
+* Make a backup of `/usr/X11R6/lib/modules` and `usr/X11R6/bin/Xorg` (if present) and move them out of the way. 
+* Uncompress `Xorg.bz2`, copy it to `/usr/X11R6/bin` and set permissions. 
+* Uncompress `Xorg-modules.tar.bz2` in `/usr/X11R6/lib`. 
+* Make a symbolic link from `/etc/X11/X` to `/usr/X11R6/bin/Xorg` if it's not there yet or points somewhere else. 
+* If needed copy `XF86Config-4` to `xorg.conf` and change the keyboard driver from "keyboard" to "kbd". 
+The following sequence of commands should work in bash: 
+
+
+[[!format txt """
+wget http://dri.freedesktop.org/snapshots/extras/Xorg.bz2
+wget http://dri.freedesktop.org/snapshots/extras/modules.tar.bz2
+ 
+mv -f /usr/X11R6/bin/Xorg /usr/X11R6/bin/Xorg.backup
+bzip2 -d Xorg.bz2
+cp Xorg /usr/X11R6/bin
+chmod 4755 /usr/X11R6/bin/Xorg
+ 
+mv /usr/X11R6/lib/modules /usr/X11R6/lib/modules.backup
+tar -C /usr/X11R6/lib -xjf modules.tar.bz2
+ 
+cd /etc/X11
+rm X
+ln -s /usr/X11R6/bin/Xorg X
+if [ -f XF86Config-4 ]; then cp XF86Config-4 xorg.conf; fi
+<edit xorg.conf>
+"""]]
+
+## Debian packages
+
+The Xorg packages in Debian unstable can be used with the binary snapshots. 
+
+
+[[!format txt """
+# cat >> /etc/apt/sources.list
+deb http://ftp.debian.org/debian/ unstable main
+^D
+# apt-get update
+# apt-get -t unstable install xserver-xorg
+"""]]
+You'll need the linux-headers package for your kernel installed in order to compile the kernel modules: 
+
+
+[[!format txt """
+# apt-get install linux-headers-`uname -r`
+"""]]
+Then just follow the instructions for installing the snapshots as above. 
+
+
+# Configuration GUI
+
+The DRI configuration GUI [[DriConf|DriConf]] is available for download from [[http://dri.freedesktop.org/~fxkuehl/driconf|http://dri.freedesktop.org/~fxkuehl/driconf]]. There are versions available for gtk-1.2 and gtk-2. If you're unsure which version to download check out the [[DriConf|DriConf]] page. It also contains installation instructions and links to the most recent versions. 
+
+---
+
+ [[http://dri.sourceforge.net/cgi-bin/moin.cgi/RecentChanges|http://dri.sourceforge.net/cgi-bin/moin.cgi/RecentChanges]] 
diff --git a/Download.moin b/Download.moin
deleted file mode 100644
index 82a8166..0000000
--- a/Download.moin
+++ /dev/null
@@ -1,102 +0,0 @@
-'''Contents'''
-<<TableOfContents>>
-= Source =
-The components of the DRI have been moved into their respective upstream repositories.  The DRI drivers reside within Mesa, and the 2D drivers reside in [X.Org http://www.x.org/].  The remaining component is the DRM, which is maintained in a git tree on freedesktop.org.
-
-== git ==
-
-To check out the drm code:
-
-{{{
-git clone git://anongit.freedesktop.org/git/mesa/drm
-}}}
-
-== cgit ==
- 
-The source and history can be viewed on the web at http://cgit.freedesktop.org/mesa/drm/
-  
-== Building from git ==
-
-See the [[Building]] page.
- 
-== Releases ==
-
-The release tarballs are available at http://dri.freedesktop.org/libdrm/
-
-= Binaries =
- 
-== Snapshots ==
-
-'''Note: Binary snapshots that are currently available for download are not up-to-date.''' They are likely to have bugs that are fixed in CVS/GIT in the mean time. '''Please do not report bugs against them.'''
-
-'''Note: Binary snapshots are currently not being built.''' The value of binary snapshots with modular Xorg is questionable and technical problems make it very hard to build one snapshot that works with both modular and monolithic Xorg.
-
-Nightly snapshots of the DRI drivers for Linux are available from [[http://dri.freedesktop.org/snapshots/]]. You need to download and install the correct snapshot for your graphics card and a "common" snapshot in order to get all new DRI features. The "common" snapshot does not need to be updated as frequently as the card-specific snapshot.
- 
-'''Note:''' If you are using a radeon 8500 or higher (8500, 8700, 9000, 9100, 9200, IGP9100, etc.) choose the r200 shapshot, otherwise choose radeon (7000, 7200, 7500, IGP320, IGP340, etc.).
- 
-'''Note:''' If you have a i830/45/55 graphics chip you now need the i915 snapshot. The i830 driver is deprecated and no new snapshots are produced for it.
- 
-=== Upgrading to X.org 6.9 CVS ===
- 
-Binary snapshots only work with a recent X.org X server. If you're running a version of XFree86 or X.org older than 6.9 RC1 then you must install an [[http://dri.freedesktop.org/snapshots/extras/Xorg.bz2|X.org server (Xorg.bz2)]] and [[http://dri.freedesktop.org/snapshots/extras/modules.tar.bz2|driver modules (Xorg-modules.tar.bz2)]].
- 
-'''Note:''' It is important that you install X.org ''before'' you install the actual binary snapshots.
- 
-'''Note:''' After installing this upgrade X.org will have no graphics drivers. You need to install the snapshots (both common and the one for your graphics card) in order to make X.org work.
- 
-This is how you install Xorg and modules.tar.bz2:
- 
- * Download `Xorg.bz2` and `modules.tar.bz2`.
- * Make a backup of `/usr/X11R6/lib/modules` and `usr/X11R6/bin/Xorg` (if present) and move them out of the way.
- * Uncompress `Xorg.bz2`, copy it to `/usr/X11R6/bin` and set permissions.
- * Uncompress `Xorg-modules.tar.bz2` in `/usr/X11R6/lib`.
- * Make a symbolic link from `/etc/X11/X` to `/usr/X11R6/bin/Xorg` if it's not there yet or points somewhere else.
- * If needed copy `XF86Config-4` to `xorg.conf` and change the keyboard driver from "keyboard" to "kbd".
- 
-The following sequence of commands should work in bash:
- 
-{{{
-wget http://dri.freedesktop.org/snapshots/extras/Xorg.bz2
-wget http://dri.freedesktop.org/snapshots/extras/modules.tar.bz2
- 
-mv -f /usr/X11R6/bin/Xorg /usr/X11R6/bin/Xorg.backup
-bzip2 -d Xorg.bz2
-cp Xorg /usr/X11R6/bin
-chmod 4755 /usr/X11R6/bin/Xorg
- 
-mv /usr/X11R6/lib/modules /usr/X11R6/lib/modules.backup
-tar -C /usr/X11R6/lib -xjf modules.tar.bz2
- 
-cd /etc/X11
-rm X
-ln -s /usr/X11R6/bin/Xorg X
-if [ -f XF86Config-4 ]; then cp XF86Config-4 xorg.conf; fi
-<edit xorg.conf>
-}}}
- 
-== Debian packages ==
-
-The Xorg packages in Debian unstable can be used with the binary snapshots.
-
-{{{
-# cat >> /etc/apt/sources.list
-deb http://ftp.debian.org/debian/ unstable main
-^D
-# apt-get update
-# apt-get -t unstable install xserver-xorg
-}}}
-
-You'll need the linux-headers package for your kernel installed in order to compile the kernel modules:
-
-{{{
-# apt-get install linux-headers-`uname -r`
-}}}
-
-Then just follow the instructions for installing the snapshots as above.
-
-= Configuration GUI =
-
-The DRI configuration GUI DriConf is available for download from http://dri.freedesktop.org/~fxkuehl/driconf. There are versions available for gtk-1.2 and gtk-2. If you're unsure which version to download check out the DriConf page. It also contains installation instructions and links to the most recent versions.
-----
-http://dri.sourceforge.net/cgi-bin/moin.cgi/RecentChanges
diff --git a/DriArchitecture.mdwn b/DriArchitecture.mdwn
new file mode 100644
index 0000000..fe83dbd
--- /dev/null
+++ b/DriArchitecture.mdwn
@@ -0,0 +1,14 @@
+
+
+# DRI Architecture
+
+   * [[DriDriver|DriDriver]] 
+         * XFree86 extensions: 
+               * GLXExtension 
+               * GLcoreExtension 
+               * [[DriExtension|DriExtension]] 
+         * libGL 
+               * libGLDriver 
+                     * [[MesaDriver|MesaDriver]] 
+         * DRM 
+               * DRMTemplates 
+\ No newline at end of file
diff --git a/DriArchitecture.moin b/DriArchitecture.moin
deleted file mode 100644
index 8ba6464..0000000
--- a/DriArchitecture.moin
+++ /dev/null
@@ -1,12 +0,0 @@
-= DRI Architecture =
-
-  * DriDriver
-    * XFree86 extensions:
-      * GLXExtension
-      * GLcoreExtension
-      * DriExtension
-    * libGL
-      * libGLDriver
-        * MesaDriver
-    * DRM
-      * DRMTemplates
diff --git a/DriConf.mdwn b/DriConf.mdwn
new file mode 100644
index 0000000..427facc
--- /dev/null
+++ b/DriConf.mdwn
@@ -0,0 +1,318 @@
+
+
+# DRI Configuration Applet
+
+DRIconf is a configuration applet for the Direct Rendering Infrastructure. It allows customizing performance and visual quality settings of OpenGL drivers on a per-driver, per-screen and/or per-application level. 
+
+The settings are stored in system wide and per-user XML configuration files, which are parsed by the OpenGL drivers on startup. For more details see [[ConfigurationInfrastructure|ConfigurationInfrastructure]]. 
+
+DRIConf is written in Python with the python-gtk toolkit bindings. 
+
+
+## Download
+
+* [[driconf-0.9.1.tar.gz|http://people.freedesktop.org/~fxkuehl/driconf/driconf-0.9.1.tar.gz]] (source) 
+* [[http://people.eecs.ku.edu/~dhageman/driconf/|http://people.eecs.ku.edu/~dhageman/driconf/]] (rpms) 
+* [[http://www.sisyphus.ru/srpm/driconf|http://www.sisyphus.ru/srpm/driconf]] (ALTLinux rpms) 
+
+### Debian & Ubuntu Packages
+
+Debian packages are available in Debian "etch" and unstable. Ubuntu has driconf in the "universe" repository. 
+
+
+### Older Releases
+
+* [[driconf-0.1.2.tar.gz|http://people.freedesktop.org/~fxkuehl/driconf/driconf-0.1.2.tar.gz]] (gtk-1.2, discontinued) 
+* [[More old releases|http://people.freedesktop.org/~fxkuehl/driconf]] 
+
+### SourceForge
+
+DRIconf is now hosted on [[SourceForge|http://sourceforge.net/projects/driconf]]. The source code and the entire history (since version 0.0.2) is available in a Subversion repository and future releases will be available there as well. 
+
+
+## Screenshot
+
+[[!img http://people.freedesktop.org/~fxkuehl/driconf/driconf.png]   
+ _Version 0.9.0_ 
+
+
+## Installation Instructions
+
+Pre-packaged versions of DRIConf are available for different Linux Distributions. Alternatively you can download the source tarball above and follow these instructions for installation. Before installing make sure that a Python version (>= 2.3) and the matching packages xml.parsers.expat and python-gtk2 version 2.4 or newer are installed. The installation uses Python's distutils package. 
+
+Extract the archive and change into the source directory: 
+
+
+[[!format txt """
+tar -xzf driconfig-x.y.z.tar.gz
+cd driconf-x.y.z
+"""]]
+By default driconf will be installed into various subdirectories under /usr/local. You can change this behaviour in setup.cfg. In that case you may also have to adjust the driconf startup script accordingly. 
+
+To start the installation run the following command as root: 
+
+
+[[!format txt """
+python setup.py install
+"""]]
+If everything goes well you should see something like this: 
+
+
+[[!format txt """
+running install
+running build
+running build_py
+creating build
+creating build/lib
+copying dri.py -> build/lib
+copying driconf.py -> build/lib
+copying driconf_commonui.py -> build/lib
+copying driconf_complexui.py -> build/lib
+copying driconf_simpleui.py -> build/lib
+running build_scripts
+creating build/scripts-2.3
+copying and adjusting driconf -> build/scripts-2.3
+changing mode of build/scripts-2.3/driconf from 644 to 755
+running install_lib
+creating /usr/local/lib/driconf
+copying build/lib/driconf.py -> /usr/local/lib/driconf
+copying build/lib/driconf_commonui.py -> /usr/local/lib/driconf
+copying build/lib/dri.py -> /usr/local/lib/driconf
+copying build/lib/driconf_simpleui.py -> /usr/local/lib/driconf
+copying build/lib/driconf_complexui.py -> /usr/local/lib/driconf
+byte-compiling /usr/local/lib/driconf/driconf.py to driconf.pyc
+byte-compiling /usr/local/lib/driconf/driconf_commonui.py to driconf_commonui.pyc
+byte-compiling /usr/local/lib/driconf/dri.py to dri.pyc
+byte-compiling /usr/local/lib/driconf/driconf_simpleui.py to driconf_simpleui.pyc
+byte-compiling /usr/local/lib/driconf/driconf_complexui.py to driconf_complexui.pyc
+running install_scripts
+copying build/scripts-2.3/driconf -> /usr/local/bin
+changing mode of /usr/local/bin/driconf to 755
+running install_data
+creating /usr/local/share/driconf
+copying card.png -> /usr/local/share/driconf
+copying screen.png -> /usr/local/share/driconf
+copying screencard.png -> /usr/local/share/driconf
+copying drilogo.jpg -> /usr/local/share/driconf
+creating /usr/local/share/locale/de
+creating /usr/local/share/locale/de/LC_MESSAGES
+copying de/LC_MESSAGES/driconf.mo -> /usr/local/share/locale/de/LC_MESSAGES
+creating /usr/local/share/locale/es
+creating /usr/local/share/locale/es/LC_MESSAGES
+copying es/LC_MESSAGES/driconf.mo -> /usr/local/share/locale/es/LC_MESSAGES
+creating /usr/local/share/locale/it
+creating /usr/local/share/locale/it/LC_MESSAGES
+copying it/LC_MESSAGES/driconf.mo -> /usr/local/share/locale/it/LC_MESSAGES
+creating /usr/local/share/locale/ru
+creating /usr/local/share/locale/ru/LC_MESSAGES
+copying ru/LC_MESSAGES/driconf.mo -> /usr/local/share/locale/ru/LC_MESSAGES
+"""]]
+After successful installation you can run driconf from the shell or install it in a menu of your window manager or desktop environment. Version 0.9.1 includes a driconf.desktop file that adds DRIconf to your Settings menu if you copy it to /usr/share/applications/driconf.desktop. 
+
+
+## History
+
+
+### Gtk-2 Versions
+
+
+#### driconf-0.9.1: Sun Sep 17 22:04:22 EDT 2006
+
+* Updated Russian translation by Konstantin A. Lepikhov. 
+* Added Dutch translation by Benno Schulenberg. 
+* Fixed a mistake in an English string (Benno Schulenberg). 
+* Added an icon and a .desktop file by Pascal de Bruijn. 
+
+#### driconf-0.9.0: Thu Jan 26 22:39:20 EST 2006
+
+* This version introduces a completely redesigned user interface. If the old user interface looked more like the GNOME configuration editor then the new one is more like a configuration applet. The old user interface is still available as "expert mode". 
+* Now requires pygtk 2.4 or newer. 
+* Translations need updates! 
+Changes in the old user interface (expert mode): 
+
+* New and Delete buttons in Unknown tabs renamed to Add and Remove. 
+* Only allow adding and renaming of unknown options if there is no driver information available. 
+* Automatically turn entries into appropriate widgets when invalid values are replaced with valid ones by the user. 
+* Fixed: prevent editing/adding/removing of unknown options in read-only files. 
+
+#### driconf-0.2.7: Thu Aug 11 18:47:39 EDT 2005
+
+* Italian translation by Giampaolo Bozzali. 
+* Russian translation by Konstantin A. Lepikhov. 
+* Changed installation. Python modules are now installed into /usr/local/lib/driconf. 
+
+#### driconf-0.2.6: Thu Apr 14 01:08:41 CEST 2005
+
+* Spanish translation by David Rubio Miguélez. 
+* .po-files included in the source release. 
+* Look for translations in the current directory first. This makes it easier to test new translations when older ones are installed in the standard place. 
+* Use gtk-2.6 About``Dialog if available. 
+* Changed handling of long tab labels. This gets rid of visual artifacts on truncated tab labels+tooltips with some gtk themes. 
+* Fixed: lots of deprecation warnings with pygtk 2.6 about gtk.TRUE and gtk.FALSE. Now using True and False, requires Python 2.3. 
+* Fixed: small problems with the Makefile for maintaining translations. 
+
+#### driconf-0.2.5: Sun Mar 27 15:32:59 CEST 2005
+
+* I18N support, initial German translation. More translations are welcome. 
+* Eye-candy: icons, bold configuration file names in the configuration tree, bold application frame label. 
+* Slightly larger initial window size, but allow resizing to smaller sizes. 
+* No more annoying popup-dialog about unknown options. The "Unknown" page was moved to the first place for attention and contains a help-button that displays a short help text. 
+* Unknown options are now editable, both their names and values, new settings can be added to the list of unknown options. 
+* Allow configuration of unkown drivers the same way as unknown options of known drivers. 
+* Allow changing the screen and driver of existing device configurations. 
+* Invalid settings are no longer highlighted when disabled. 
+* Fixed: spin-buttons for integers had a decimal point. 
+* Fixed: markup in the configuration tree was broken (only visible with invalid settings). 
+* Fixed: assertion failure when deleting driver or application configurations. 
+* Fixed: escape all text that is passed to Pango as markup. 
+* Fixed: there was a possibility that a read-only configuration was selected on startup even though a writable one existed. 
+
+#### driconf-0.2.4: Fri Mar 18 12:50:22 CET 2005
+
+* Added an "About" dialog. 
+* Added some instructive text to device and application name dialogs. 
+* Made the executable attribute more similar to a regular option. 
+* Truncate long tab labels and add a tooltip with the full description. 
+* More concise device descriptions in the configuration tree. 
+* Updated README. 
+* Fixed: Problem when closing the DRIconf window through the window manager. 
+* Fixed: Wrong button activation after saving a configuration file. 
+
+#### driconf-0.2.3: Mon Mar 14 02:13:30 CET 2005
+
+* Added a new widget for float and integer ranges: spin button + slider. (The slider is not shown on small integer ranges.) 
+* Usability improvements: Automatically select new nodes. Adjust scrolling of the configuration tree when the selection is changed automatically. 
+* Updated README. Added a little help for getting started. 
+* Fixed: A bad bug when entry widgets get used. 
+* Fixed: Some (not all) deprecation warnings with gtk+ 2.6. 
+* Fixed: Saving when a file node was selected in the configuration tree. 
+
+#### driconf-0.2.2: Mon Jan  5 03:51:35 CET 2004
+
+* Fixed a problem with floating point options that specify a list of valid values, like the new def_max_anisotropy. 
+
+#### driconf-0.2.1: Sat Nov 15 10:04:37 CET 2003
+
+* Select the first writable application configuration on startup with the nice side effect that the window doesn't grow later. 
+* White background behind the logo. 
+* Replaced the deprecated (in gtk2) CTree and CList widgets with Tree``Views. 
+* Completely rewired checking for invalid user input in Entry widgets. 
+
+#### driconf-0.2.0: Tue Oct 28 15:10:20 CET 2003
+
+* Ported driconf to gtk-2.0. 
+* Made the configuration tree scrollable. 
+* Allow multiple selection in unknown section page. 
+* Fixed: reloading didn't work when a config file was selected. 
+
+### Gtk-1.2 Versions
+
+The Gtk-1.2 series of DRIconf has been discontinued. 
+
+
+#### driconf-0.1.2: Mon Jan  5 03:56:51 CET 2004
+
+* Fixed a problem with floating point options that specify a list of valid values, like the new def_max_anisotropy. 
+
+#### driconf-0.1.1: Sat Nov 15 10:08:13 CET 2003
+
+* Select the first writable application configuration on startup with the nice side effect that the window doesn't grow later. 
+* White background behind the logo. 
+* Completely rewired checking for invalid user input in Entry widgets. 
+
+#### driconf-0.1.0: Tue Oct 28 15:15:34 CET 2003
+
+* Made the configuration tree scrollable. 
+* Allow multiple selection in unknown section page. 
+* Fixed: reloading didn't work when a config file was selected. 
+
+### Versions before the fork of separate Gtk-2 and Gtk-1.2 versions
+
+
+#### driconf-0.0.11: Thu Oct 23 00:20:06 CEST 2003
+
+* Toggle buttons: "True", "False" -> "Yes", "No". 
+* Pushing "New" while an application is selected creates a new application in the same device. 
+* Fixed: Handle options without any description. 
+* Fixed: Entry widget always marked the configuration as modified. 
+* Fixed: Message dialogs opened before the main window was created crashed. 
+* Fixed: Segfault reloading a config file while an application was selected. 
+
+#### driconf-0.0.10: Sat Oct 11 23:37:19 CEST 2003
+
+* Added a "reload" button to reload a configuration from disk. 
+* Added spaces to the toolbar. 
+* Fixed: rename applications caused an exception (Michel Dänzer). 
+* Fixed: Select gtk version 1.2 on systems that support version selection (Michel Dänzer). 
+* Fixed: use getlocale(LC_MESSAGES) to select the language of option descriptions (Michel Dänzer) 
+
+#### driconf-0.0.9: Fri Oct  3 14:16:21 CEST 2003
+
+* Save button is only sensitive on modified configs. 
+* No more annoying message box after saving successfully. 
+* Ask before losing changes on exit. 
+* Load configuration files before opening the main window. 
+* Show a message box if the driver's config info has errors. 
+* Make all dialogs transient windows for the main window. 
+* Fixed: workaround for a segfault in libgtk when deleting application entries. 
+
+#### driconf-0.0.8: Sun Sep 28 12:31:48 CEST 2003
+
+* Added a special section page for options that appear in a configuration file but are unknown to the driver (only shows up if necessary). 
+* Improved error handling/reporting in case of invalid driver config info. 
+* Improved handling of invalid option values. 
+* Highlight applications with invalid options in the configuration tree. 
+* Ask before saving a configuration with invalid entries. 
+
+#### driconf-0.0.7: Mon Aug 25 23:43:34 CEST 2003
+
+* If an application or device is selected the save button saves the containing configuration file. 
+* Tries to write the default configuration for non-existing configuration files on startup showing a message dialog if successful. 
+* Non-existent and non-creatable config files don't show up in the config tree. 
+* Existing but non-writable config files are read-only, all the toolbar buttons and configuration widgets are unsensitive. 
+* Fixed: Error message about failed xdriinfo generated an exception itself :-/ 
+
+#### driconf-0.0.6: Thu Aug 21 03:40:37 CEST 2003
+
+* Added a custom Gtk``Option``Menu-like widget for enums that wraps lines 
+* Display options' XML elements as tooltip 
+* Make widgets of disabled options unsensitive 
+* Fixed: workaround for a strange problem with a modal dialog opened in the select_row callback of a ctree with selection mode SELECTION_BROWSE. It locked up the entire X session in a way that no more input was accepted! 
+* Fixed: popen2.Popen3 didn't seem to work from inside gtk callbacks. 
+
+#### driconf-0.0.5: Sat Aug 16 15:41:12 CEST 2003
+
+* Adjust toolbar button sensitivity to selected config tree item 
+* Reset individual options to their default value 
+* Display translated description as option label, name and type as tooltip 
+* Use popen2.Popen3 so that xdriinfo's stderr can be captured to produce more helpful error messages 
+* Fixed: show an error message dialog if xdriinfo fails on program startup 
+
+#### driconf-0.0.4: Mon Jul 28 23:20:16 CEST 2003
+
+* Support for enum options 
+* Fixed: top level element must be <driconf> not <dri> 
+
+#### driconf-0.0.3: Mon Jul 21 00:37:56 CEST 2003
+
+* Appropriate widgets for specific option types and valid ranges 
+* Changed options get activated automatically 
+* Added a DRI logo 
+* Installation using Python's distutils 
+* Handles invalid configuration files gracefully 
+
+#### driconf-0.0.2: Sun Jul 13 23:35:00 CEST 2003
+
+* For non-existent files create one device per screen each with one empty application config 
+* Fixed: Select a default language (en) and encoding (iso-8859-1) if not defined by the locale (e.g. "C") 
+
+#### driconf-0.0.1: Sun Jul 13 19:29:12 CEST 2003
+
+* Added CHANGELOG 
+* Added TODO 
+* Fixed: Forgot to commit changed entries before saving 
+* Fixed: Install to $PREFIX/lib/$PYTHON/site-packages. It seems .pyo files are ignored. Install .pyc files instead. 
+
+#### driconf-0.0.0: Sun Jul 13 17:00:00 CEST 2003
+
+First release 
diff --git a/DriConf.moin b/DriConf.moin
deleted file mode 100644
index 9a3e998..0000000
--- a/DriConf.moin
+++ /dev/null
@@ -1,308 +0,0 @@
-= DRI Configuration Applet =
-
-DRIconf is a configuration applet for the Direct Rendering Infrastructure. It allows customizing performance and visual quality settings of OpenGL drivers on a per-driver, per-screen and/or per-application level.
-
-The settings are stored in system wide and per-user XML configuration files, which are parsed by the OpenGL drivers on startup. For more details see ConfigurationInfrastructure.
-
-DRIConf is written in Python with the python-gtk toolkit bindings.
-
-== Download ==
-
- * [[http://people.freedesktop.org/~fxkuehl/driconf/driconf-0.9.1.tar.gz|driconf-0.9.1.tar.gz]] (source)
- * [[http://people.eecs.ku.edu/~dhageman/driconf/]] (rpms)
- * [[http://www.sisyphus.ru/srpm/driconf]] (ALTLinux rpms)
-
-=== Debian & Ubuntu Packages ===
-
-Debian packages are available in Debian "etch" and unstable. Ubuntu has driconf in the "universe" repository.
-
-=== Older Releases ===
-
- * [[http://people.freedesktop.org/~fxkuehl/driconf/driconf-0.1.2.tar.gz|driconf-0.1.2.tar.gz]] (gtk-1.2, discontinued)
- * [[http://people.freedesktop.org/~fxkuehl/driconf|More old releases]]
-
-=== SourceForge ===
-
-DRIconf is now hosted on [[http://sourceforge.net/projects/driconf|SourceForge]]. The source code and the entire history (since version 0.0.2) is available in a Subversion repository and future releases will be available there as well.
-
-== Screenshot ==
-
-{{http://people.freedesktop.org/~fxkuehl/driconf/driconf.png}} <<BR>>
-''Version 0.9.0''
-
-== Installation Instructions ==
-
-Pre-packaged versions of DRIConf are available for different Linux Distributions. Alternatively you can download the source tarball above and follow these instructions for installation. Before installing make sure that a Python version (>= 2.3) and the matching packages xml.parsers.expat and python-gtk2 version 2.4 or newer are installed. The installation uses Python's distutils package.
-
-Extract the archive and change into the source directory:
-
-{{{
-tar -xzf driconfig-x.y.z.tar.gz
-cd driconf-x.y.z
-}}}
-
-By default driconf will be installed into various subdirectories under /usr/local. You can change this behaviour in setup.cfg. In that case you may also have to adjust the driconf startup script accordingly.
-
-To start the installation run the following command as root:
-
-{{{
-python setup.py install
-}}}
-
-If everything goes well you should see something like this:
-
-{{{
-running install
-running build
-running build_py
-creating build
-creating build/lib
-copying dri.py -> build/lib
-copying driconf.py -> build/lib
-copying driconf_commonui.py -> build/lib
-copying driconf_complexui.py -> build/lib
-copying driconf_simpleui.py -> build/lib
-running build_scripts
-creating build/scripts-2.3
-copying and adjusting driconf -> build/scripts-2.3
-changing mode of build/scripts-2.3/driconf from 644 to 755
-running install_lib
-creating /usr/local/lib/driconf
-copying build/lib/driconf.py -> /usr/local/lib/driconf
-copying build/lib/driconf_commonui.py -> /usr/local/lib/driconf
-copying build/lib/dri.py -> /usr/local/lib/driconf
-copying build/lib/driconf_simpleui.py -> /usr/local/lib/driconf
-copying build/lib/driconf_complexui.py -> /usr/local/lib/driconf
-byte-compiling /usr/local/lib/driconf/driconf.py to driconf.pyc
-byte-compiling /usr/local/lib/driconf/driconf_commonui.py to driconf_commonui.pyc
-byte-compiling /usr/local/lib/driconf/dri.py to dri.pyc
-byte-compiling /usr/local/lib/driconf/driconf_simpleui.py to driconf_simpleui.pyc
-byte-compiling /usr/local/lib/driconf/driconf_complexui.py to driconf_complexui.pyc
-running install_scripts
-copying build/scripts-2.3/driconf -> /usr/local/bin
-changing mode of /usr/local/bin/driconf to 755
-running install_data
-creating /usr/local/share/driconf
-copying card.png -> /usr/local/share/driconf
-copying screen.png -> /usr/local/share/driconf
-copying screencard.png -> /usr/local/share/driconf
-copying drilogo.jpg -> /usr/local/share/driconf
-creating /usr/local/share/locale/de
-creating /usr/local/share/locale/de/LC_MESSAGES
-copying de/LC_MESSAGES/driconf.mo -> /usr/local/share/locale/de/LC_MESSAGES
-creating /usr/local/share/locale/es
-creating /usr/local/share/locale/es/LC_MESSAGES
-copying es/LC_MESSAGES/driconf.mo -> /usr/local/share/locale/es/LC_MESSAGES
-creating /usr/local/share/locale/it
-creating /usr/local/share/locale/it/LC_MESSAGES
-copying it/LC_MESSAGES/driconf.mo -> /usr/local/share/locale/it/LC_MESSAGES
-creating /usr/local/share/locale/ru
-creating /usr/local/share/locale/ru/LC_MESSAGES
-copying ru/LC_MESSAGES/driconf.mo -> /usr/local/share/locale/ru/LC_MESSAGES
-}}}
-
-After successful installation you can run driconf from the shell or install it in a menu of your window manager or desktop environment. Version 0.9.1 includes a driconf.desktop file that adds DRIconf to your Settings menu if you copy it to /usr/share/applications/driconf.desktop.
-
-== History ==
-
-=== Gtk-2 Versions ===
-
-==== driconf-0.9.1: Sun Sep 17 22:04:22 EDT 2006 ====
-
- * Updated Russian translation by Konstantin A. Lepikhov.
- * Added Dutch translation by Benno Schulenberg.
- * Fixed a mistake in an English string (Benno Schulenberg).
- * Added an icon and a .desktop file by Pascal de Bruijn.
-
-==== driconf-0.9.0: Thu Jan 26 22:39:20 EST 2006 ====
-
- * This version introduces a completely redesigned user interface. If the old user interface looked more like the GNOME configuration editor then the new one is more like a configuration applet. The old user interface is still available as "expert mode".
- * Now requires pygtk 2.4 or newer.
- * Translations need updates!
-
-Changes in the old user interface (expert mode):
-
- * New and Delete buttons in Unknown tabs renamed to Add and Remove.
- * Only allow adding and renaming of unknown options if there is no driver information available.
- * Automatically turn entries into appropriate widgets when invalid values are replaced with valid ones by the user.
- * Fixed: prevent editing/adding/removing of unknown options in read-only files.
-
-==== driconf-0.2.7: Thu Aug 11 18:47:39 EDT 2005 ====
-
- * Italian translation by Giampaolo Bozzali.
- * Russian translation by Konstantin A. Lepikhov.
- * Changed installation. Python modules are now installed into /usr/local/lib/driconf.
-
-==== driconf-0.2.6: Thu Apr 14 01:08:41 CEST 2005 ====
-
- * Spanish translation by David Rubio Miguélez.
- * .po-files included in the source release.
- * Look for translations in the current directory first. This makes it easier to test new translations when older ones are installed in the standard place.
- * Use gtk-2.6 About``Dialog if available.
- * Changed handling of long tab labels. This gets rid of visual artifacts on truncated tab labels+tooltips with some gtk themes.
- * Fixed: lots of deprecation warnings with pygtk 2.6 about gtk.TRUE and gtk.FALSE. Now using True and False, requires Python 2.3.
- * Fixed: small problems with the Makefile for maintaining translations.
-
-==== driconf-0.2.5: Sun Mar 27 15:32:59 CEST 2005 ====
-
- * I18N support, initial German translation. More translations are welcome.
- * Eye-candy: icons, bold configuration file names in the configuration tree, bold application frame label.
- * Slightly larger initial window size, but allow resizing to smaller sizes.
- * No more annoying popup-dialog about unknown options. The "Unknown" page was moved to the first place for attention and contains a help-button that displays a short help text.
- * Unknown options are now editable, both their names and values, new settings can be added to the list of unknown options.
- * Allow configuration of unkown drivers the same way as unknown options of known drivers.
- * Allow changing the screen and driver of existing device configurations.
- * Invalid settings are no longer highlighted when disabled.
- * Fixed: spin-buttons for integers had a decimal point.
- * Fixed: markup in the configuration tree was broken (only visible with invalid settings).
- * Fixed: assertion failure when deleting driver or application configurations.
- * Fixed: escape all text that is passed to Pango as markup.
- * Fixed: there was a possibility that a read-only configuration was selected on startup even though a writable one existed.
-
-==== driconf-0.2.4: Fri Mar 18 12:50:22 CET 2005 ====
- 
- * Added an "About" dialog.
- * Added some instructive text to device and application name dialogs.
- * Made the executable attribute more similar to a regular option.
- * Truncate long tab labels and add a tooltip with the full description.
- * More concise device descriptions in the configuration tree.
- * Updated README.
- * Fixed: Problem when closing the DRIconf window through the window manager.
- * Fixed: Wrong button activation after saving a configuration file.
-
-==== driconf-0.2.3: Mon Mar 14 02:13:30 CET 2005 ====
-
- * Added a new widget for float and integer ranges: spin button + slider. (The slider is not shown on small integer ranges.)
- * Usability improvements: Automatically select new nodes. Adjust scrolling of the configuration tree when the selection is changed automatically.
- * Updated README. Added a little help for getting started.
- * Fixed: A bad bug when entry widgets get used.
- * Fixed: Some (not all) deprecation warnings with gtk+ 2.6.
- * Fixed: Saving when a file node was selected in the configuration tree.
-
-==== driconf-0.2.2: Mon Jan  5 03:51:35 CET 2004 ====
-
- * Fixed a problem with floating point options that specify a list of valid values, like the new def_max_anisotropy.
-
-==== driconf-0.2.1: Sat Nov 15 10:04:37 CET 2003 ====
- 
- * Select the first writable application configuration on startup with the nice side effect that the window doesn't grow later.
- * White background behind the logo.
- * Replaced the deprecated (in gtk2) CTree and CList widgets with Tree``Views.
- * Completely rewired checking for invalid user input in Entry widgets.
-
-==== driconf-0.2.0: Tue Oct 28 15:10:20 CET 2003 ====
- 
- * Ported driconf to gtk-2.0.
- * Made the configuration tree scrollable.
- * Allow multiple selection in unknown section page.
- * Fixed: reloading didn't work when a config file was selected.
-
-=== Gtk-1.2 Versions ===
-
-The Gtk-1.2 series of DRIconf has been discontinued.
-
-==== driconf-0.1.2: Mon Jan  5 03:56:51 CET 2004 ====
-
- * Fixed a problem with floating point options that specify a list of valid values, like the new def_max_anisotropy.
-
-==== driconf-0.1.1: Sat Nov 15 10:08:13 CET 2003 ====
- 
- * Select the first writable application configuration on startup with the nice side effect that the window doesn't grow later.
- * White background behind the logo.
- * Completely rewired checking for invalid user input in Entry widgets.
-
-==== driconf-0.1.0: Tue Oct 28 15:15:34 CET 2003 ====
-
- * Made the configuration tree scrollable.
- * Allow multiple selection in unknown section page.
- * Fixed: reloading didn't work when a config file was selected.
-
-=== Versions before the fork of separate Gtk-2 and Gtk-1.2 versions ===
-
-==== driconf-0.0.11: Thu Oct 23 00:20:06 CEST 2003 ====
-
- * Toggle buttons: "True", "False" -> "Yes", "No".
- * Pushing "New" while an application is selected creates a new application in the same device.
- * Fixed: Handle options without any description.
- * Fixed: Entry widget always marked the configuration as modified.
- * Fixed: Message dialogs opened before the main window was created crashed.
- * Fixed: Segfault reloading a config file while an application was selected.
-
-==== driconf-0.0.10: Sat Oct 11 23:37:19 CEST 2003 ====
-
- * Added a "reload" button to reload a configuration from disk.
- * Added spaces to the toolbar.
- * Fixed: rename applications caused an exception (Michel Dänzer).
- * Fixed: Select gtk version 1.2 on systems that support version selection (Michel Dänzer).
- * Fixed: use getlocale(LC_MESSAGES) to select the language of option descriptions (Michel Dänzer)
-
-==== driconf-0.0.9: Fri Oct  3 14:16:21 CEST 2003 ====
-
- * Save button is only sensitive on modified configs.
- * No more annoying message box after saving successfully.
- * Ask before losing changes on exit.
- * Load configuration files before opening the main window.
- * Show a message box if the driver's config info has errors.
- * Make all dialogs transient windows for the main window.
- * Fixed: workaround for a segfault in libgtk when deleting application entries.
-
-==== driconf-0.0.8: Sun Sep 28 12:31:48 CEST 2003 ====
-
- * Added a special section page for options that appear in a configuration file but are unknown to the driver (only shows up if necessary).
- * Improved error handling/reporting in case of invalid driver config info.
- * Improved handling of invalid option values.
- * Highlight applications with invalid options in the configuration tree.
- * Ask before saving a configuration with invalid entries.
-
-==== driconf-0.0.7: Mon Aug 25 23:43:34 CEST 2003 ====
-
- * If an application or device is selected the save button saves the containing configuration file.
- * Tries to write the default configuration for non-existing configuration files on startup showing a message dialog if successful.
- * Non-existent and non-creatable config files don't show up in the config tree.
- * Existing but non-writable config files are read-only, all the toolbar buttons and configuration widgets are unsensitive.
- * Fixed: Error message about failed xdriinfo generated an exception itself :-/
-
-==== driconf-0.0.6: Thu Aug 21 03:40:37 CEST 2003 ====
-
- * Added a custom Gtk``Option``Menu-like widget for enums that wraps lines
- * Display options' XML elements as tooltip
- * Make widgets of disabled options unsensitive
- * Fixed: workaround for a strange problem with a modal dialog opened in the select_row callback of a ctree with selection mode SELECTION_BROWSE. It locked up the entire X session in a way that no more input was accepted!
- * Fixed: popen2.Popen3 didn't seem to work from inside gtk callbacks.
-
-==== driconf-0.0.5: Sat Aug 16 15:41:12 CEST 2003 ====
-
- * Adjust toolbar button sensitivity to selected config tree item
- * Reset individual options to their default value
- * Display translated description as option label, name and type as tooltip
- * Use popen2.Popen3 so that xdriinfo's stderr can be captured to produce more helpful error messages
- * Fixed: show an error message dialog if xdriinfo fails on program startup
-
-==== driconf-0.0.4: Mon Jul 28 23:20:16 CEST 2003 ====
-
- * Support for enum options
- * Fixed: top level element must be <driconf> not <dri>
-
-==== driconf-0.0.3: Mon Jul 21 00:37:56 CEST 2003 ====
-
- * Appropriate widgets for specific option types and valid ranges
- * Changed options get activated automatically
- * Added a DRI logo
- * Installation using Python's distutils
- * Handles invalid configuration files gracefully
-
-==== driconf-0.0.2: Sun Jul 13 23:35:00 CEST 2003 ====
-
- * For non-existent files create one device per screen each with one empty application config
- * Fixed: Select a default language (en) and encoding (iso-8859-1) if not defined by the locale (e.g. "C")
-
-==== driconf-0.0.1: Sun Jul 13 19:29:12 CEST 2003 ====
-
- * Added CHANGELOG
- * Added TODO
- * Fixed: Forgot to commit changed entries before saving
- * Fixed: Install to $PREFIX/lib/$PYTHON/site-packages. It seems .pyo files are ignored. Install .pyc files instead.
-
-==== driconf-0.0.0: Sun Jul 13 17:00:00 CEST 2003 ====
-
-First release
diff --git a/DriDriver.mdwn b/DriDriver.mdwn
new file mode 100644
index 0000000..d5b7a90
--- /dev/null
+++ b/DriDriver.mdwn
@@ -0,0 +1,9 @@
+
+
+## DRI Driver
+
+All DRI drivers are made up of 3 parts: 
+
+   * A DRI aware 2D driver which lives in [[xc/programs/Xserver/hw/xfree86/drivers/|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/]] usually in a file _*_dri.[ch]_. 
+   * A DRI aware 3D driver based on Mesa which lives in [[xc/lib/GL/mesa/src/drv/|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/mesa/src/drv/]] 
+   * A kernel module which lives in [[xc/programs/Xserver/hw/xfree86/os-support/linux/drm/|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/]] 
+\ No newline at end of file
diff --git a/DriDriver.moin b/DriDriver.moin
deleted file mode 100644
index 3ce740c..0000000
--- a/DriDriver.moin
+++ /dev/null
@@ -1,9 +0,0 @@
-== DRI Driver ==
-
-All DRI drivers are made up of 3 parts:
-
-  * A DRI aware 2D driver which lives in [[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/|xc/programs/Xserver/hw/xfree86/drivers/]] usually in a file ''*_dri.[ch]''.
-  * A DRI aware 3D driver based on Mesa which lives in [[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/mesa/src/drv/|xc/lib/GL/mesa/src/drv/]]
-  * A kernel module which lives in [[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/|xc/programs/Xserver/hw/xfree86/os-support/linux/drm/]]
-
-
diff --git a/DriExtension.mdwn b/DriExtension.mdwn
new file mode 100644
index 0000000..878db01
--- /dev/null
+++ b/DriExtension.mdwn
@@ -0,0 +1,17 @@
+
+
+### DRI Extension
+
+
+#### What does the XFree86 DRI extension?
+
+The XFree86-DRI X server extension is basically used for communication between the other DRI components (the X server, the kernel module, _libGL.so_ and the 3D DRI drivers). 
+
+The XFree86-DRI module maintains DRI-specific data structures related to screens, windows, and rendering contexts. When the user moves a window, for example, the other DRI components need to be informed so that rendering appears in the right place. 
+
+
+#### Where does the XFree86 DRI extension resides?
+
+The DRI extension module usually resides at _/usr/X``11R6/lib/modules/extensions/libdri.a_. 
+
+The DRI extension source code resides at [[xc/programs/Xserver/GL/dri/|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/GL/dri/]] . 
diff --git a/DriExtension.moin b/DriExtension.moin
deleted file mode 100644
index efe067b..0000000
--- a/DriExtension.moin
+++ /dev/null
@@ -1,14 +0,0 @@
-=== DRI Extension ===
-
-==== What does the XFree86 DRI extension? ====
-
-The XFree86-DRI X server extension is basically used for communication between the other DRI components (the X server, the kernel module, ''libGL.so'' and the 3D DRI drivers).
-
-The XFree86-DRI module maintains DRI-specific data structures related to screens, windows, and rendering contexts. When the user moves a window, for example, the other DRI components need to be informed so that rendering appears in the right place.
-
-==== Where does the XFree86 DRI extension resides? ====
-
-The DRI extension module usually resides at ''/usr/X``11R6/lib/modules/extensions/libdri.a''.
-
-The DRI extension source code resides at [[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/GL/dri/|xc/programs/Xserver/GL/dri/]] .
-
diff --git a/DriHistory.mdwn b/DriHistory.mdwn
new file mode 100644
index 0000000..786ba6e
--- /dev/null
+++ b/DriHistory.mdwn
@@ -0,0 +1,240 @@
+
+
+## The DRI project history
+
+
+### Executive summary
+
+The DRI was initially developed by Precision Insight, Inc. (PI) in cooperation with, and partially funded by Red Hat Inc., and SGI. Since PI's merger with VA Linux, and VA Linux' subsequent exit from Linux, the DRI is being maintained by Tungsten Graphics Inc., a company formed by some of the initial DRI developers from PI. Tungsten Graphics is the current focal point for DRI development, and many open source developers continue to contribute to the project through the DRI project. 
+
+
+### Details
+
+This is mostly a history of the DRI. If you're interested, print it out and snuggle up by the fire... 
+
+At [[SigGraph|SigGraph]] of '98 (August 1998) there was a Linux 3D BOF. Brian, Daryll and others gave good talks at this meeting. I had a short talk near the end where I basically asked for any community members interested in developing a direct rendering infrastructure to contact me. From this, I got two responses with no follow up. 
+
+So, Kevin and I sat down and wrote the [[high level design document|http://dri.sourceforge.net/doc/design_high_level.html]], which outlined many alternatives and recommended a single path for implementing direct rendering. This document was released less than two months after my [[SigGraph|SigGraph]] plea for involvement. We posted the following e-mail to the [[devel@xfree86.org|mailto:devel@xfree86.org]] mailing list in September of 1998: 
+
+   * [[!format txt """
+Subject: Direct Rendering for 3D
+From: Jens Owen (jens@precisioninsight.com)
+Date: Sun, 20 Sep 1998 12:40:07 -0600
+
+We have released our high-level design document which describes a
+direct rendering architecture for 3D applications. This document
+can be found at:
+
+http://www.precisioninsight.com/dr/dr.html
+
+Our intention is to create a sample implementation of the 3D
+infrastructure using Mesa and XFree86 with full source available
+under an XFree86-style license.
+
+We are sending this e-mail to XFree86, Mesa, and kernel developers
+in an effort to receive feedback on the high level design. We
+would like to receive comments back by 12 Oct 98 as we plan to
+start on the low level design at that point.
+
+Regards,
+Jens Owen and Kevin E. Martin
+"""]]
+This e-mail received no responses on the devel list. However, Alan Akin did see this and reply with some excellent comments directly to Kevin and myself. After a couple of months with no feedback we pushed on. We were able to hire Rik Faith in November and by early December dedicated a couple of weeks to working together to come up with a low level design document. Allen Akin volunteered his time in that effort, and the four of us spent every other day for two weeks on the phone and the off days thinking over and writing up our design. 
+
+By the end of 1998, we had a small amount of funding (relative to the size of the project) and a low level design in hand; however, we were still missing some key components. We needed a reference implementation of OpenGL to base our 3D drivers on. SGI had sample implementation, but they weren't ready to release it in open source, yet. They did however, release their GLX library which was very helpful. They also gave us an initial round of funding -- but they understood the problem; and shared with us (after the fact) that they didn't think it could be done on the aggressive schedule and shoe string budget we had to work with. Red Hat also funded this effort. Red Hat was new to 3D graphics, and didn't realize the mountain we were trying to climb -- still their support was invaluable. 
+
+The two key pieces of technology that came our way (just in time) was SGI's GLX release and Brian Paul's willingness to give us a Mesa license that was compatible with XFree86. With the two missing pieces to the puzzle finally available, we posted to the [[devel@xfree86.org|mailto:devel@xfree86.org]] list again in February of '99. Here is a copy of our post: 
+
+   * [[!format txt """
+Subject: SGI's GLX Source Release
+From: Jens Owen (jens@precisioninsight.com)
+Date: Tue, 16 Feb 1999 16:18:32 -0700
+
+SGI has announced their GLX source release to the open source
+community. You can read the press release at
+http://www.sgi.com/newsroom/press_releases/1999/february/opengl.html
+
+Precision Insight is working with SGI to incorporate their GLX source
+base into XFree86. We are also working on integrating the SGI's GLX
+code base and Brian Paul's Mesa core rendering functionality within
+the XFree86 4.0 X Server development branch.
+
+This initial GLX/Mesa integration is an effort to quickly get an early
+version of software only indirect rendering into the XFree86 4.0
+development tree. That will then be the basis for our Direct Rendering
+Infrastructure (DRI) development which will be available in mid '99.
+
+If you would like more detailed information about our Direct Rendering
+Infrastructure, we have posted an updated project description at
+http://www.precisioninsight.com/DRI021699.html
+
+Regards,
+Jens Owen
+"""]]
+This was exciting. We still didn't get much community involvement -- but we did have enough money in hand to fund 3 full time developers to crank this out by the end of June of 1999. We each took a driver component and pushed forward as fast as we could. Kevin took the 3D component and tied the GLX, Mesa and a hardware implementation together. Rik took the kernel component and developed the DRMlib and our first DRM hardware implementation. I took the X Server piece and developed the DRI server extension and extended a DDX driver to be "DRI aware". We burned the midnight oil at a pace that would make Gareth proud:-) We knew we had a huge task ahead. We had committed to a demo at the Linux show in the middle of May and needed to wrap up the project by the end of June (when our funded ran out). One slip up by any of us and we weren't going to be able to pull this off. We hadn't been getting much feedback from the open source community -- so we just put our heads down and developed like mad men. 
+
+By the middle of May, we had a handful of design documents and we were ready for the trade show demo. We posted this to [[devel@xfree86.org|mailto:devel@xfree86.org]]: 
+
+   * [[!format txt """
+Subject: Direct Rendering Design Docs Available
+From: Jens Owen (jens@precisioninsight.com)
+Date: Wed, 12 May 1999 17:09:23 -0600
+
+Pointers to our DRI design docs can be found at
+http://www.precisioninsight.com/piinsights.com
+
+Please direct comments to glx@xfree86.org
+
+Regards,
+Jens
+"""]]
+The only feedback we received was two posts to correct the URL we posted. I admit we weren't too surprised. We hadn't gotten any feedback on the early designs -- so why should the more detailed documents be any different. We pulled off our demo and pushed on. We needed to clean up the sources enough to get them into XFree86. We thought, if design documents aren't helping other developers understand our work; maybe the sources will. By the middle of June 1999, we had an alpha release submitted to XFree86. Here's the old announcement: 
+
+   * [[!format txt """
+Subject: README for Direct Rendering
+From: Jens Owen (jens@precisioninsight.com)
+Date: Sat, 12 Jun 1999 22:51:59 -0600
+
+Attached is the README for the alpha release of our Direct Rendering
+Infrastructure that has been submitted to XFree86. Look for the code
+in an upcoming 3.9 alpha patch release.
+
+Regards,
+Jens Owen
+
+  Direct Rendering Infrastructure Alpha release
+  ---------------------------------------------
+
+  Patches for the alpha release of Precision Insight's Direct Rendering
+  Infrastructure (DRI) have been submitted to XFree86. The final sample
+  implementation (SI) will be available at the end of June. The purpose
+  of this release is to allow XFree86 and others to start evaluating the
+  code.
+
+  *NOTE* This is an alpha release and there will be changes between now
+  and the final SI release.
+
+  Please direct all comments about this release to glx@xfree86.org.
+
+  * What comes with this release?
+
+        There are four main parts of this patch:
+
+        1. the client- and server-side DRI,
+        2. a 2D DDX driver for 3Dlabs' GMX2000,
+        3. an OpenGL client side direct rendering driver for the GMX2000, and
+        4. a generic kernel driver for Linux 2.2.x.
+
+        The DRI handles the communication and synchronization between the X
+        server, the client driver and the kernel driver.
+
+        The 3Dlabs XFree86 DDX driver has been enhanced to support the
+        GMX2000. It has also been extended to communicate with and provide
+        callbacks for the DRI.
+
+        The client driver implements a subset of OpenGL. The subset required
+        for id Software's Quake 2 was chosen to demonstrate the capabilities
+        of the DRI. This driver communicates with the device by filling DMA
+        buffers and sending them to the kernel driver. Note that the Gamma
+        chip implements OpenGL 1.1 in hardware, and therefore, does not use
+        the Mesa internals at this time. However, support for the majority
+        of current generation of 3D hardware devices will require
+        integration with Mesa, so an example DRI driver using the Mesa
+        software-only pipeline was implemented (and is mostly complete for
+        the alpha release).
+
+        The generic kernel driver handles the allocation of the DMA buffers,
+        distribution of the buffers to the clients, sending the buffers to
+        the device, and the management of synchronization between the client
+        driver, the X server, and the kernel driver (this includes the
+        device lock and a shared memory region). Note that hardware that
+        does not support DMA or that does support special synchronization
+        methods will only make use of a subset of these capabilities.
+
+  * What are the known problems and/or limitations of the alpha
+        release?
+
+        We are actively working on fixing the items listed below, and will
+        attempt to fix as many of them as possible before the SI release.
+
+        - The X server seg faults due to a context switching bug when there
+          are 10 or more 3D clients running simultaneously
+        - Dynamic loading of the OpenGL client driver is not yet implemented
+        - 3D client death while holding the drawable lock causes deadlock
+        - The kernel module only works with Linux kernels 2.2.[0-5]
+        - A better authentication mechanism needs to be implemented
+        - A better DMA buffer queuing algorithm needs to be implemented
+        - A device specific shared memory region needs to be added to SAREA
+        - The DRI protocol request for the framebuffer layout needs to be
+          extended to support FB width and depth information (for 24 vs. 32
+          bpp, 8+24 layouts, etc)
+        - Add options for the DRI to XF86Config
+
+        Here are other problems that we are not going to have time to fix
+        for the SI. However, we and other open source developers are going
+        to continue developing and extending the DRI in follow-on projects.
+
+        - Direct rendering to a pixmap is not supported
+        - A more sophisticated texture management routine is required to
+          handle texture swapping efficiently
+        - Multi-threaded OpenGL clients are not supported
+        - glXCopyContext and glXUseXFont are not supported in the DRI
+        - SwapBuffers does not wait on vertical retrace
+        - Support wait for vertical retrace in kernel driver
+        - Handling overlays is not currently supported
+        - Integrate with DBE
+        - Completing the software-only Mesa example driver
+        - Completing the other OpenGL paths for the GMX2000
+        - Support for video modes other than 640x480 in both the GMX2000 2D
+          DDX driver and the 3D client driver
+        - More than minimal 2D acceleration of the GMX2000 2D DDX driver
+          should be implemented
+        - Implement finer grained locking scheme in X server to improve
+          interactivity
+        - Only grab the drawable lock and update the drawable stamp when a
+          3D window is altered
+        - The viewport does not scale properly when a 3D window is resized
+        - Double buffered 3D windows are not clipped to the screen
+        - glXSwapBuffers is not clipped to the client's viewport
+        - Only one client is allowed to use texture memory
+        - glFinish does not wait until the HW completes processing the
+          outstanding DMA buffers
+        - Version numbers of the DDX and kernel driver are not verified
+        - Make lock available during SIGSTOP
+        - Make drmFinish work while holding the device lock
+        - Improve /proc/drm
+        - Improve documentation
+        - Improve example device-specific kernel driver (not used for SI)
+
+  * Where can I get more information?
+
+        We have made our design and implementation documents available on
+        our website:
+
+                http://www.precisioninsight.com/piinsights.html
+
+        More documentation will be available with the SI release.
+
+  * Where should I send comments?
+
+        Please send all comments and questions to the glx@xfree86.org list
+"""]]
+Wow, we had made it. The base DRI infrastructure had been released on an near impossible budget and dead line. We were excited to have crossed this bridge -- but from the list of limitations outlined in our `README` above, we knew there was still a lot of work to be done. We needed more funding, more work on the infrastructure and more complete driver implementations to move the DRI forward. Daryll Strauss had joined our team just before the trade show in May and was quickly ramping up on the DRI. As the initial 3 developers collapsed in a heap by the end of June; Daryll was able to pick up the slack and push the DRI on another amazing evolution with an impossible schedule. 3dfx hired us to develop a DRI driver for the Banshee and Voodoo2 chipsets and they wanted a demo by the [[SigGraph|SigGraph]] trade show in August of 1999. This seemed impossible in my opinion -- but Daryll had the experience of implementing the first complete hardware accelerated OpenGL under Mesa for Linux under his belt. In the past, he had used 3dfx's Glide library to achieve great results. Now, he attacked the DRI, learned it strengths, and molded around it's weaknesses to developed a demo of the first complete 3D driver for the DRI in just two short months. 
+
+That summer, Intel had also commissioned us to develop a 3D driver for the i810 chipset. They didn't have the head start of existing 2D drivers and a ported Glide library -- but they were serious about doing Linux right. They wanted complete 2D drivers for the current XFree86 release, first. We were able to bring Keith Whitwell onto the team. Keith knew Mesa well, and had been a key contributor to the first native Mesa drivers under the UtahGLX project. Keith spun up on 2D XFree86 drivers in no time flat and developed Intel's i810 2D drivers for XFree86 3.3 and 4.0. Then, when the 2D drivers were complete he used his wizardry to develop the first cut of fully native Mesa DRI driver in just a few short weeks. Keith's focus on performance and ability to quickly generate complex 3D drivers was nothing short of amazing -- however, it is his consummated dedication to open development that helped move the DRI forward the most. Keith saw first hand how well a simple framework like the UtahGLX project was able to foster new graphics talent -- and he was the initial driving force behind the DRI project being moved to completely open source repository and mailing lists. The entire team embraced his ideals; and the DRI Source Forge project was born. 
+
+By the end of the summer of 1999; Wall Street had found Linux and no less than four major graphics hardware vendors had secured our services for a 3D driver under Linux. We had committed to have complete driver suites in place for the latest chipsets from 3dfx, Intel, ATI and Matrox by early 2000. This required a large effort across the team and some new hands as well. We picked up Jeff Hartmann, an AGP specialist -- who enabled us to utilized true AGP busmastering for our drivers. Next we added Brian Paul to our team -- as the author of Mesa, his knowledge was second to none and his dedication to OpenGL conformance helped our drivers reach a higher level of completeness and quality. 
+
+Brian had a history of working well with members of the OpenGL Architecture Review Board and usually provided the first implementations of new ARB approved extensions via his Mesa software renderer. He was able to quickly drive forward a standard for dynamically resolving driver extensions at run time and implement a nice jump table mechanism to allow multiple DRI drivers to be handled via a single OpenGL library. These mechanisms were integrated into our drivers and OpenGL library just in time for the XFree86 4.0 release. 
+
+The XFree86 4.0 release had been our target platform since the early design days of the DRI. We wanted (and needed) to be closely integrated with the standard for open source windowing software -- XFree86. David Dawes, a founding member and president of XFree86, joined our team in January of 2000 and helped us bring the DRI project into even closer alignment with the needs of XFree86. 
+
+With a heroic effort by Kevin, Rik, Daryll, Keith, Jeff, Brian and David we were able to deliver no less than 4 complete driver suites for the XFree86 4.0 release in early 2000. This moved the DRI from the status of "sample framework" to a solid 3D platform in eight short months. We had moved from a "make announcements" on progress every few months mode to a fully open development process hosted at [[SourceForge|http://dri.sourceforge.net]]. 
+
+A few months later Precision Insight was acquired by VA Linux Systems. The team grew further to include some additional fantastic developers: Gareth Hughes, Alan Hourihane and Nathan Hand. We took more steps forward in the progression of the DRI -- but alas VA was not meant to be in the 3D Linux business. 
+
+Today, the team has split up and moved forward in a few different directions. Some of the team went to work for Red Hat (Alan, Kevin and Rik); Gareth is working for nVidia; and Brian, Keith and David have started a new company called Tungsten Graphics (TG) with Frank Lamonica and myself. Jeff has gone back to school and Nathan is working on other projects from Australia. 
+
+Hopefully this background can give you a perspective for how the DRI has always been rooted in the open source community and how we have evolved to using more and more effective open development techniques. I sincerely hope we can find and provide the needed catalysts for bringing new developers into the exciting technical area of 3D graphics development. 
+
+-- [[JensOwen|JensOwen]] 
diff --git a/DriHistory.moin b/DriHistory.moin
deleted file mode 100644
index b7d7d50..0000000
--- a/DriHistory.moin
+++ /dev/null
@@ -1,355 +0,0 @@
-== The DRI project history ==
-
-=== Executive summary ===
-
-The DRI was initially developed by Precision Insight, Inc. (PI) in cooperation with, and partially funded by Red Hat Inc., and SGI. Since PI's merger with VA Linux, and VA Linux' subsequent exit from Linux, the DRI is being maintained by Tungsten Graphics Inc., a company formed by some of the initial DRI developers from PI. Tungsten Graphics is the current focal point for DRI development, and many open source developers continue to contribute to the project through the DRI project.
-
-=== Details ===
-
-This is mostly a history of the DRI.
-If you're interested, print it out and snuggle up by the fire...
-
-At SigGraph of '98 (August 1998) there was a Linux 3D BOF. Brian, Daryll and
-others gave good talks at this meeting. I had a short talk near the end where I
-basically asked for any community members interested in developing a direct
-rendering infrastructure to contact me. From this, I got two responses with no
-follow up.
-
-So, Kevin and I sat down and wrote the
-[[http://dri.sourceforge.net/doc/design_high_level.html|high level design document]],
-which outlined many alternatives and recommended a single path for
-implementing direct rendering. This document was released less than two months
-after my SigGraph plea for involvement. We posted the following e-mail to the
-devel@xfree86.org mailing list in September of 1998:
-
-  {{{
-Subject: Direct Rendering for 3D
-From: Jens Owen (jens@precisioninsight.com)
-Date: Sun, 20 Sep 1998 12:40:07 -0600
-
-We have released our high-level design document which describes a
-direct rendering architecture for 3D applications. This document
-can be found at:
-
-http://www.precisioninsight.com/dr/dr.html
-
-Our intention is to create a sample implementation of the 3D
-infrastructure using Mesa and XFree86 with full source available
-under an XFree86-style license.
-
-We are sending this e-mail to XFree86, Mesa, and kernel developers
-in an effort to receive feedback on the high level design. We
-would like to receive comments back by 12 Oct 98 as we plan to
-start on the low level design at that point.
-
-Regards,
-Jens Owen and Kevin E. Martin
-}}}
-
-This e-mail received no responses on the devel list. However, Alan Akin did see
-this and reply with some excellent comments directly to Kevin and myself. After
-a couple of months with no feedback we pushed on. We were able to hire Rik
-Faith in November and by early December dedicated a couple of weeks to working
-together to come up with a low level design document. Allen Akin volunteered
-his time in that effort, and the four of us spent every other day for two weeks
-on the phone and the off days thinking over and writing up our design.
-
-By the end of 1998, we had a small amount of funding (relative to the size of
-the project) and a low level design in hand; however, we were still missing
-some key components. We needed a reference implementation of OpenGL to base our
-3D drivers on. SGI had sample implementation, but they weren't ready to release
-it in open source, yet. They did however, release their GLX library which was
-very helpful. They also gave us an initial round of funding -- but they
-understood the problem; and shared with us (after the fact) that they didn't
-think it could be done on the aggressive schedule and shoe string budget we had
-to work with. Red Hat also funded this effort. Red Hat was new to 3D graphics,
-and didn't realize the mountain we were trying to climb -- still their support
-was invaluable.
-
-The two key pieces of technology that came our way (just in time) was SGI's GLX
-release and Brian Paul's willingness to give us a Mesa license that was
-compatible with XFree86. With the two missing pieces to the puzzle finally
-available, we posted to the devel@xfree86.org list again in February of '99.
-Here is a copy of our post:
-
-  {{{
-Subject: SGI's GLX Source Release
-From: Jens Owen (jens@precisioninsight.com)
-Date: Tue, 16 Feb 1999 16:18:32 -0700
-
-SGI has announced their GLX source release to the open source
-community. You can read the press release at
-http://www.sgi.com/newsroom/press_releases/1999/february/opengl.html
-
-Precision Insight is working with SGI to incorporate their GLX source
-base into XFree86. We are also working on integrating the SGI's GLX
-code base and Brian Paul's Mesa core rendering functionality within
-the XFree86 4.0 X Server development branch.
-
-This initial GLX/Mesa integration is an effort to quickly get an early
-version of software only indirect rendering into the XFree86 4.0
-development tree. That will then be the basis for our Direct Rendering
-Infrastructure (DRI) development which will be available in mid '99.
-
-If you would like more detailed information about our Direct Rendering
-Infrastructure, we have posted an updated project description at
-http://www.precisioninsight.com/DRI021699.html
-
-Regards,
-Jens Owen
-}}}
-
-This was exciting. We still didn't get much community involvement -- but we did
-have enough money in hand to fund 3 full time developers to crank this out by
-the end of June of 1999. We each took a driver component and pushed forward as
-fast as we could. Kevin took the 3D component and tied the GLX, Mesa and a
-hardware implementation together. Rik took the kernel component and developed
-the DRMlib and our first DRM hardware implementation. I took the X Server piece
-and developed the DRI server extension and extended a DDX driver to be "DRI
-aware". We burned the midnight oil at a pace that would make Gareth proud:-) We
-knew we had a huge task ahead. We had committed to a demo at the Linux show in
-the middle of May and needed to wrap up the project by the end of June (when
-our funded ran out). One slip up by any of us and we weren't going to be able
-to pull this off. We hadn't been getting much feedback from the open source
-community -- so we just put our heads down and developed like mad men.
-
-By the middle of May, we had a handful of design documents and we were ready
-for the trade show demo. We posted this to devel@xfree86.org:
-
-  {{{
-Subject: Direct Rendering Design Docs Available
-From: Jens Owen (jens@precisioninsight.com)
-Date: Wed, 12 May 1999 17:09:23 -0600
-
-Pointers to our DRI design docs can be found at
-http://www.precisioninsight.com/piinsights.com
-
-Please direct comments to glx@xfree86.org
-
-Regards,
-Jens
-}}}
-
-The only feedback we received was two posts to correct the URL we posted. I
-admit we weren't too surprised. We hadn't gotten any feedback on the early
-designs -- so why should the more detailed documents be any different. We
-pulled off our demo and pushed on. We needed to clean up the sources enough to
-get them into XFree86. We thought, if design documents aren't helping other
-developers understand our work; maybe the sources will. By the middle of June
-1999, we had an alpha release submitted to XFree86. Here's the old
-announcement:
-
-  {{{
-Subject: README for Direct Rendering
-From: Jens Owen (jens@precisioninsight.com)
-Date: Sat, 12 Jun 1999 22:51:59 -0600
-
-Attached is the README for the alpha release of our Direct Rendering
-Infrastructure that has been submitted to XFree86. Look for the code
-in an upcoming 3.9 alpha patch release.
-
-Regards,
-Jens Owen
-
-  Direct Rendering Infrastructure Alpha release
-  ---------------------------------------------
-
-  Patches for the alpha release of Precision Insight's Direct Rendering
-  Infrastructure (DRI) have been submitted to XFree86. The final sample
-  implementation (SI) will be available at the end of June. The purpose
-  of this release is to allow XFree86 and others to start evaluating the
-  code.
-
-  *NOTE* This is an alpha release and there will be changes between now
-  and the final SI release.
-
-  Please direct all comments about this release to glx@xfree86.org.
-
-  * What comes with this release?
-
-	There are four main parts of this patch:
-
-	1. the client- and server-side DRI,
-	2. a 2D DDX driver for 3Dlabs' GMX2000,
-	3. an OpenGL client side direct rendering driver for the GMX2000, and
-	4. a generic kernel driver for Linux 2.2.x.
-
-	The DRI handles the communication and synchronization between the X
-	server, the client driver and the kernel driver.
-
-	The 3Dlabs XFree86 DDX driver has been enhanced to support the
-	GMX2000. It has also been extended to communicate with and provide
-	callbacks for the DRI.
-
-	The client driver implements a subset of OpenGL. The subset required
-	for id Software's Quake 2 was chosen to demonstrate the capabilities
-	of the DRI. This driver communicates with the device by filling DMA
-	buffers and sending them to the kernel driver. Note that the Gamma
-	chip implements OpenGL 1.1 in hardware, and therefore, does not use
-	the Mesa internals at this time. However, support for the majority
-	of current generation of 3D hardware devices will require
-	integration with Mesa, so an example DRI driver using the Mesa
-	software-only pipeline was implemented (and is mostly complete for
-	the alpha release).
-
-	The generic kernel driver handles the allocation of the DMA buffers,
-	distribution of the buffers to the clients, sending the buffers to
-	the device, and the management of synchronization between the client
-	driver, the X server, and the kernel driver (this includes the
-	device lock and a shared memory region). Note that hardware that
-	does not support DMA or that does support special synchronization
-	methods will only make use of a subset of these capabilities.
-
-  * What are the known problems and/or limitations of the alpha
-	release?
-
-	We are actively working on fixing the items listed below, and will
-	attempt to fix as many of them as possible before the SI release.
-
-	- The X server seg faults due to a context switching bug when there
-	  are 10 or more 3D clients running simultaneously
-	- Dynamic loading of the OpenGL client driver is not yet implemented
-	- 3D client death while holding the drawable lock causes deadlock
-	- The kernel module only works with Linux kernels 2.2.[0-5]
-	- A better authentication mechanism needs to be implemented
-	- A better DMA buffer queuing algorithm needs to be implemented
-	- A device specific shared memory region needs to be added to SAREA
-	- The DRI protocol request for the framebuffer layout needs to be
-	  extended to support FB width and depth information (for 24 vs. 32
-	  bpp, 8+24 layouts, etc)
-	- Add options for the DRI to XF86Config
-
-	Here are other problems that we are not going to have time to fix
-	for the SI. However, we and other open source developers are going
-	to continue developing and extending the DRI in follow-on projects.
-
-	- Direct rendering to a pixmap is not supported
-	- A more sophisticated texture management routine is required to
-	  handle texture swapping efficiently
-	- Multi-threaded OpenGL clients are not supported
-	- glXCopyContext and glXUseXFont are not supported in the DRI
-	- SwapBuffers does not wait on vertical retrace
-	- Support wait for vertical retrace in kernel driver
-	- Handling overlays is not currently supported
-	- Integrate with DBE
-	- Completing the software-only Mesa example driver
-	- Completing the other OpenGL paths for the GMX2000
-	- Support for video modes other than 640x480 in both the GMX2000 2D
-	  DDX driver and the 3D client driver
-	- More than minimal 2D acceleration of the GMX2000 2D DDX driver
-	  should be implemented
-	- Implement finer grained locking scheme in X server to improve
-	  interactivity
-	- Only grab the drawable lock and update the drawable stamp when a
-	  3D window is altered
-	- The viewport does not scale properly when a 3D window is resized
-	- Double buffered 3D windows are not clipped to the screen
-	- glXSwapBuffers is not clipped to the client's viewport
-	- Only one client is allowed to use texture memory
-	- glFinish does not wait until the HW completes processing the
-	  outstanding DMA buffers
-	- Version numbers of the DDX and kernel driver are not verified
-	- Make lock available during SIGSTOP
-	- Make drmFinish work while holding the device lock
-	- Improve /proc/drm
-	- Improve documentation
-	- Improve example device-specific kernel driver (not used for SI)
-
-  * Where can I get more information?
-
-	We have made our design and implementation documents available on
-	our website:
-
-		http://www.precisioninsight.com/piinsights.html
-
-	More documentation will be available with the SI release.
-
-  * Where should I send comments?
-
-	Please send all comments and questions to the glx@xfree86.org list
-}}}
-
-Wow, we had made it. The base DRI infrastructure had been released on an near
-impossible budget and dead line. We were excited to have crossed this bridge --
-but from the list of limitations outlined in our `README` above, we knew there
-was still a lot of work to be done. We needed more funding, more work on the
-infrastructure and more complete driver implementations to move the DRI
-forward. Daryll Strauss had joined our team just before the trade show in May
-and was quickly ramping up on the DRI. As the initial 3 developers collapsed in
-a heap by the end of June; Daryll was able to pick up the slack and push the
-DRI on another amazing evolution with an impossible schedule. 3dfx hired us to
-develop a DRI driver for the Banshee and Voodoo2 chipsets and they wanted a
-demo by the SigGraph trade show in August of 1999. This seemed impossible in my
-opinion -- but Daryll had the experience of implementing the first complete
-hardware accelerated OpenGL under Mesa for Linux under his belt. In the past,
-he had used 3dfx's Glide library to achieve great results. Now, he attacked the
-DRI, learned it strengths, and molded around it's weaknesses to developed a
-demo of the first complete 3D driver for the DRI in just two short months.
-
-That summer, Intel had also commissioned us to develop a 3D driver for the i810
-chipset. They didn't have the head start of existing 2D drivers and a ported
-Glide library -- but they were serious about doing Linux right. They wanted
-complete 2D drivers for the current XFree86 release, first. We were able to
-bring Keith Whitwell onto the team. Keith knew Mesa well, and had been a key
-contributor to the first native Mesa drivers under the UtahGLX project. Keith
-spun up on 2D XFree86 drivers in no time flat and developed Intel's i810 2D
-drivers for XFree86 3.3 and 4.0. Then, when the 2D drivers were complete he
-used his wizardry to develop the first cut of fully native Mesa DRI driver in
-just a few short weeks. Keith's focus on performance and ability to quickly
-generate complex 3D drivers was nothing short of amazing -- however, it is his
-consummated dedication to open development that helped move the DRI forward the
-most. Keith saw first hand how well a simple framework like the UtahGLX
-project was able to foster new graphics talent -- and he was the initial
-driving force behind the DRI project being moved to completely open source
-repository and mailing lists. The entire team embraced his ideals; and the DRI
-Source Forge project was born.
-
-By the end of the summer of 1999; Wall Street had found Linux and no less than
-four major graphics hardware vendors had secured our services for a 3D driver
-under Linux. We had committed to have complete driver suites in place for the
-latest chipsets from 3dfx, Intel, ATI and Matrox by early 2000. This required a
-large effort across the team and some new hands as well. We picked up Jeff
-Hartmann, an AGP specialist -- who enabled us to utilized true AGP busmastering
-for our drivers. Next we added Brian Paul to our team -- as the author of Mesa,
-his knowledge was second to none and his dedication to OpenGL conformance
-helped our drivers reach a higher level of completeness and quality.
-
-Brian had a history of working well with members of the OpenGL Architecture
-Review Board and usually provided the first implementations of new ARB approved
-extensions via his Mesa software renderer. He was able to quickly drive forward
-a standard for dynamically resolving driver extensions at run time and
-implement a nice jump table mechanism to allow multiple DRI drivers to be
-handled via a single OpenGL library. These mechanisms were integrated into our
-drivers and OpenGL library just in time for the XFree86 4.0 release.
-
-The XFree86 4.0 release had been our target platform since the early design
-days of the DRI. We wanted (and needed) to be closely integrated with the
-standard for open source windowing software -- XFree86. David Dawes, a founding
-member and president of XFree86, joined our team in January of 2000 and helped
-us bring the DRI project into even closer alignment with the needs of XFree86.
-
-With a heroic effort by Kevin, Rik, Daryll, Keith, Jeff, Brian and David we
-were able to deliver no less than 4 complete driver suites for the XFree86 4.0
-release in early 2000. This moved the DRI from the status of "sample framework"
-to a solid 3D platform in eight short months. We had moved from a "make
-announcements" on progress every few months mode to a fully open development
-process hosted at [[http://dri.sourceforge.net|SourceForge]].
-
-A few months later Precision Insight was acquired by VA Linux Systems. The team
-grew further to include some additional fantastic developers: Gareth Hughes,
-Alan Hourihane and Nathan Hand. We took more steps forward in the progression
-of the DRI -- but alas VA was not meant to be in the 3D Linux business.
-
-Today, the team has split up and moved forward in a few different directions.
-Some of the team went to work for Red Hat (Alan, Kevin and Rik); Gareth is
-working for nVidia; and Brian, Keith and David have started a new company
-called Tungsten Graphics (TG) with Frank Lamonica and myself. Jeff has gone
-back to school and Nathan is working on other projects from Australia.
-
-Hopefully this background can give you a perspective for how the DRI has always
-been rooted in the open source community and how we have evolved to using more
-and more effective open development techniques. I sincerely hope we can find
-and provide the needed catalysts for bringing new developers into the exciting
-technical area of 3D graphics development.
-
--- JensOwen
diff --git a/DriMemoryManagerDesign.mdwn b/DriMemoryManagerDesign.mdwn
new file mode 100644
index 0000000..7db4978
--- /dev/null
+++ b/DriMemoryManagerDesign.mdwn
@@ -0,0 +1,256 @@
+
+_**DRI Memory Manager Design**_ 
+
+**Contents:** [[!toc ]] 
+
+
+## Introduction
+
+The memory manager is roughly divided into two portions.  There is a small portion in the kernel, and the remainder resides in the user-mode driver.  This division is made for two reasons that are worth noting here.  By having a majority of the memory manager in user-mode avoids calling into the kernel for each memory operation.  On recent Linux kernels the cost of calling into the kernel has been greatly reduced, so this isn't as much of an issue as it once was. 
+
+There is bigger issue driving this design decision.  The division of code between kernel and user roughly matches the division of mechanism and policy.  All of the policy decisions regarding which memory is allocated are made in user-mode. 
+
+
+## Memory Manager Interface
+
+The userspace portion of the memory manager will live in libdrm. This means we can abstract the inner-working of the memory manager described below from the interface offered to X.org DDX and Mesa DRI drivers. This interface is open for discussion.  
+
+Feel very free to change these descriptions (Dave Airlie). 
+
+
+### drmMMCreate
+
+
+[[!format txt """
+void *drmMMCreate(int fd);
+"""]]
+Create a instance of the DRM memory manager for the DRM open on the file descriptor fd. Before calling this the DRM driver must have been bootstrapped and the pools created by the DRM. This function just initialises all the memory manager userspace structures needed. 
+
+
+### drmMMDestroy
+
+
+[[!format txt """
+void drmMMDestroy(void *mm_handle);
+"""]]
+Destroy an instance of the DRM memory manager. Free any internal structures allocated. 
+
+
+### drmMMAllocRegion
+
+
+[[!format txt """
+#define DRM_MM_ATTRIB_PINNED 0x1
+#define DRM_MM_ATTRIB_ADDMAP 0x2
+#define DRM_MM_ATTRIB_BACKED 0x4
+
+drm_region_id_t drmMMAllocRegion(void *mm_handle, int pool_id, unsigned int size, int alignment, unsigned int attributes, void *backing);
+"""]]
+Allocate a region for this process from the pool identified by pool_id, of size size aligned with alignment. 
+
+Pinned attribute makes the memory unmovable, this may need to be a privileged operation or not, scanout buffers need to be pinned. Addmap attribute will cause the DRM to add a mapping for this block, (not sure if useful just a suggestion) - may need to be pinned. Backed attribute means the client is providing a block of memory to back the area via the *backing pointer. - again suggestion only. 
+
+Memory used by the driver as DMA or vertex buffers will have to be pinned, at least for the current usage where commands can be placed in DMA buffers without the lock held.  Any memory passed by the driver to the client will also have to be pinned, at least for as long as the client has access to it.  Once the DMA buffer is enqueued for execution, or retrieved from the client, the pinned attribute can be removed.  (So we'll need a call to do that?) 
+
+
+### drmMMFreeRegion
+
+
+[[!format txt """
+void drmMMFreeRegion(void *mm_handle, drm_region_id_t region_id)
+"""]]
+Free the region of memory specified by region_id. 
+
+
+### drmMMGetRegionPointer
+
+
+[[!format txt """
+void *drmMMGetRegionPointer(void *mm_handle, drm_region_id_t region_id)
+"""]]
+Return a pointer to the actual memory behind the region. (These pointers should not be stored across lock drops). 
+
+
+### drmMMGetHandleMappedRegion
+
+
+[[!format txt """
+drm_handle_t drmMMGetHandleMappedRegion(void *mm_handle, drm_region_id_t region_id);
+"""]]
+Returns a DRM handle for an area that has been allocated using the ADDMAP attribute. 
+
+
+### drmMMMSetRegionAttributes
+
+
+[[!format txt """
+int drmMMSetRegionAttributes(void *mm_handle, drm_region_id_t region_id, unsigned int new_attribs);
+"""]]
+Set the new attributes on the region. 
+
+
+### drmMMGetRegionAttributes
+
+
+[[!format txt """
+unsigned int drmMMGetRegionAttributes(void *mm_handle, drm_region_id_t region_id)
+"""]]
+Return the current attributes of a region. 
+
+
+### drmMMSetRegionFence
+
+
+[[!format txt """
+int drmMMSetRegionFence(void *mm_handle, drm_region_id_t region_id, unsigned int condition);
+"""]]
+Set the condition of a fence on the region specified by region_id. (Do multiple fences on a region make any sense?? or does the only last fence setting matter...) 
+
+
+### drmMMTestFence
+
+
+[[!format txt """
+int drmMMTestRegionFence(void *mm_handle, drm_region_id_t region_id);
+"""]]
+Test the fence on a region_id. 
+
+
+### drmMMWaitFence
+
+
+[[!format txt """
+int drmMMWaitRegionFence(void *mm_handle, drm_region_id_t region_id);
+"""]]
+Wait until the region fence is completed. (Unsure if this is needed - do we really want to wait in the drmMM layer - maybe needs a higher level interface). 
+
+
+## Memory Manager Concepts
+
+The memory manager is based around the concept of allocating a block of memory to a named object.  The object and the associated block of memory is called a _region._  Each region has an associated ID.  This ID is a simple unsigned integer that is unique _per-device._ 
+
+By allocating memory to a named object, the owner of that object can be notified when portions of that object have been removed from memory by another process.  For example, a process can allocate memory for a texture object.  Another process can later over-write part of that object with its own object.  Before the first process can reuse that texture, it needs to be sure that all of the texture is still in memory. 
+
+For objects that cannot just be "dumped" from memory, such as buffers used as rendering targets, a region of _backing storage_ can be attached.  These regions are called _precious._  When another process needs to reclaim a block of memory from a precious region, it must first copy the data out of the region into the backing store. 
+
+Changes to the state of memory are track via a log.  As a process allocates memory, frees memory, or changes the attributes of a region, it writes that information to a circular buffer in shared memory.  Each process independently processes the data in the log to keep its local view of the memory state up to date.  In distributed computing, this is a concept known as [[virtual synchrony|http://en.wikipedia.org/wiki/Virtual_synchrony]]. 
+
+
+## Kernel Interface
+
+The interface to the kernel portion of the memory manager consists of only five ioctls.  These ioctls are used to query parameters about memory pools, allocate region IDs, release region IDs, configure backing store for regions, and backing up regions to their backing store.  Of these five, only three will actually be implemented in the first phase of the implementation. 
+
+
+### Bootstrapping Memory Pools
+
+There is no direct user / kernel interface for bootstrapping the kernel portion of the memory manager.  Rather than providing interfaces for a user-mode controller process (e.g., the X-server) to configure the available memory pools, this task is handled by the device-specific bootstrap process.  For example, in the MGA DRM code, the function mga_do_dma_bootstrap (in [[mga_dma.c|http://cvs.freedesktop.org/dri/drm/shared-core/mga_dma.c?view=markup]]) knows what memory pools are available (e.g., on-card and AGP for AGP cards and on-card for PCI cards), how big they are, and why types of data can be stored in them.  This is _exactly_ the information that is needed to bootstrap the memory manager.  Since the kernel already has all the required information, there is no reason to add new interfaces. 
+
+Once the device-dependent code has initialized all of the memory pools that are available, it must create the logs.  The log data is stored in a series of pages in a shared memory area.  The first page describes where the log data can be found in the remaining pages.  The format of this data is an array of structures.  The array is indexed by pool ID. 
+
+
+[[!format txt """
+struct drm_mmgr_pool_log_descriptor {
+    unsigned int first_page;  /**< First page containing log data. */
+    unsigned int page_count;  /**< Number of pages containing log data. */
+};
+"""]]
+
+### Management of Region IDs
+
+Region IDs are allocated from the DRM via the `DRM_IOCTL_MMGR_ALLOC_IDS` ioctl.  Region IDs are given to processes in fairly large, fixed size blocks.  Internally region IDs are tracked by a two page bitmap.  On common processors, this 65,536 region ID blocks.  Since a region ID consists of 30-bits, each block represents 16,384 IDs.  The first ID allocated and the count of IDs allocated is returned in the `drm_mmgr_region_id_range_t` structure by the `DRM_IOCTL_MMGR_ALLOC_IDS` ioctl. 
+
+
+[[!format txt """
+typedef struct drm_mmgr_region_id_range {
+        unsigned int base_id;  /**< First region ID. */
+        unsigned int count;    /**< Number of IDs. */
+} drm_mmgr_region_id_range_t;
+"""]]
+Once a block of IDs has been allocated to a process, it is the responsibility of the device-specific DRM code to track.  When the process closes the DRM file handle, all ID blocks used by the process must be released. 
+
+Processes can also release blocks of IDs by calling the `DRM_IOCTL_MMGR_RELEASE_IDS` ioctl.  Since IDs are always allocated in fixed size blocks, only the base ID of the block being released is passed to this ioctl. 
+
+
+### Querying Pool Values
+
+There are two types off data about the memory manager that user-mode can query from the kernel.  Both types of query are done via the `DRM_IOCTL_MMGR_GETPARAM` ioctl.  User-mode can query information about per-device memory manager state and per-pool memory manager state. 
+
+All `DRM_IOCTL_MMGR_GETPARAM` queries use the `drm_mmgr_getparam_t` structure.  For per-device queries the `pool_id` field is not used and should be set to zero.  The size and type of data pointed to by `value` varies with the query. 
+
+
+[[!format txt """
+typedef struct drm_mmgr_getparam {
+        /**
+         * Name of the parameter.  See \c drm_mmgr_getparam_mode_t.
+         */
+        unsigned int param;
+
+        unsigned int pool_id;  /**< ID of the pool being queried. */
+        void __user * value;   /**< Storage for the value being queried. */
+} drm_mmgr_getparam_t;
+"""]]
+A typical bootstrap procedure is for the user-mode device driver to query `DRM_MMGR_PARAM_NUM_POOLS` for the device, then query `DRM_MMGR_PARAM_POOL_IDS`.  The initial `DRM_MMGR_PARAM_NUM_POOLS` query is required so that the driver knows how much data will be returned in `value` by the `DRM_MMGR_PARAM_POOL_IDS` query.  The pool ID values are unique within a system.  That is, if a system has four graphics cards the each memory pool will have an ID that is unique across all cards. 
+
+Once the IDs of the available pools are known, the size (via `DRM_MMGR_PARAM_POOL_SIZE`) and attribute bits (via `DRM_MMGR_PARAM_POOL_ATTRIBUTES`) are queried. 
+
+The initial state of pool memory (i.e., which portions of memory are allocated or free) are queried via the `DRM_MMGR_PARAM_POOL_STATE_SIZE` / `DRM_MMGR_PARAM_POOL_STATE`.  The former is used to determine the amount of data, measured in bytes, returned by the later.  `DRM_MMGR_PARAM_POOL_STATE` returns an array of `drm_mmgr_puddle_data_t` structures in `value`.  This array is then used to initialize the driver's internal representation of memory.  `DRM_MMGR_PARAM_POOL_STATE_SIZE` must always return an integer multiple of `sizeof( drm_mmgr_puddle_data_t )`. 
+
+
+[[!format txt """
+typedef struct drm_mmgr_puddle_data {
+        unsigned int size;       /**< Size, in bytes, of the puddle. */
+        unsigned int region_id;  /**< Region ID owning the puddle.  A region
+                                  * ID of zero means that the puddle is not
+                                  * allocated.
+                                  */
+} drm_mmgr_puddle_data_t;
+"""]]
+The final bootstrap step is for the user-mode driver to get a handle for the pool's logs.  The handle for the logs and size of the logs are queried via `DRM_MMGR_PARAM_LOG_HANDLE` and `DRM_MMGR_PARAM_LOG_SIZE`, respectively.  `DRM_MMGR_PARAM_LOG_SIZE` is measured in bytes but must be an integer multiple of the system's page size.  The first page is an array, indexed by pool ID, of `drm_mmgr_log_header_t` structures.  The remaining pages make up the log data.  The log data for each pool will always begin at a page boundary.  The log data will also always have a size that is a power of two. 
+
+
+[[!format txt """
+typedef struct drm_mmgr_log_header {
+        unsigned int size;       /**< Size, in bytes, of the pool's log. */
+        unsigned int offset;     /**< Offset, in bytes, from the start of the
+                                  * log data pages to the pool's log.
+                                  */
+        volatile uint64_t index; /**< Index to next position in log. */
+
+        /**
+         * Last index value processed by the kernel.
+         */
+        volatile uint64_t kernel_index;
+} drm_mmgr_log_header_t;
+"""]]
+
+### The Log
+
+The log isn't strictly a kernel interface, but it is created by and obtained from the kernel.  However, the kernel does 'not' write data to the log.  Each process maintains a local 64-bit counter representing the last index into the log that it has processed.  Before accessing a region, the process must compare its local counter with the `drm_mmgr_log_header_t::index` for the pool containing the region.  If the values are not equal, the process much "play back" instructions from the log until they are equal. 
+
+Each instruction in the log begins with an `unsigned int` header containing two pieces of data.  The least-significant 2-bits of the value specify the instruction, and the next 30-bits contain the associated region ID.  On architectures where `unsigned int` is more than 32-bits, the most-significant bits must be zero.  Depending on the instruction, the initial `unsigned int` may be followed by one or more additional `unsigned int` fields. 
+
+When accessing the log, the index `current_index & (log->size - 1)` is used.  If the value of `log->index & ~(log->size - 1)` is greater than `current_index & ~(log->size - 1)` and the value of `log->index & (log->size - 1)` is greater than `current_index & (log->size - 1)` the log has wrapped around since the last time the process played back log data.  This means that the process has missed some instructions.  This means that the process must re-bootstrap its view of memory by querying `DRM_MMGR_PARAM_POOL_STATE_SIZE` and `DRM_MMGR_PARAM_POOL_STATE`. 
+
+A process can also determine if a memory operation will wrap the log for the kernel.  Since the kernel's view of memory is used to bootstrap (and re-bootstrap) new processes, it is critical that the log **never** wraps for the kernel.  By performing a similar comparison using `log->kernel_index` and `current_index` the process can determine if a wrap is about to occur.  If the log is about to wrap for the kernel, the process can prevent this cataclysmic event by querying `DRM_MMGR_PARAM_POOL_STATE_SIZE`.  In order to calculate the value for this query the kernel must play the entire log.  Making this query can trick the kernel into catching up thereby avoiding a wrap. 
+
+
+#### DRM_MMGR_LOG_ALLOCATE
+
+This instruction is used to allocate or free a block of memory.  If the region ID is non-zero, the instruction allocates a block of memory and associates it with the specified region ID.  If the region ID is zero, the instruction releases a block of memory.  Immediately following the initial `unsigned int` are two additional `unsigned int` fields.  The first specifies the offset of the memory block, and the second specifies the size of the memory block. 
+
+
+#### DRM_MMGR_LOG_SET_ATTRIBUTE
+
+This instruction is used to specify the attribute bits associated with a region ID.  It is invalid to specify a region ID of zero with this instruction.  No attribute bits are currently specified.  In the (near) future bits for "precious" or "pin" will be specified.  It is also possible that additional "hints", such as "region fragmented" or "region won't be used again", can be created.  Beyond a few common attributes the remaining bits will be available for device-specific uses. 
+
+
+#### DRM_MMGR_LOG_SET_FENCE
+
+This instruction is used to specify the attribute bits associated with a region ID.  It is invalid to specify a region ID of zero with this instruction.  Fences are similar in concept to the texture aging mechanism used in most open-source DRI drivers.  The DRM for each device maintains a monotonically increasing counter.  This counter increases when the hardware completes some operation.  Some hardware automatically maintains this counter, whereas other hardware notifies the driver to increment the counter via an interrupt.  The mechanism by which the counter is incremented is not important.  The important issue is that the user-mode driver be able to predict what the value of this counter will be when the hardware is finished using a region.  The predicted value is then set as the _fence_ for that region.  If the current counter is greater than or equal to the fence, then the hardware is finished using that region. 
+
+By communicating these fence values in the log, the user-mode drivers can correctly order memory operations.  Some cards (e.g., Radeon cards) can pipeline texture uploads.  On cards with this ability can safely ignore the fence value for texture allocations.  However, even on cards that can pipeline texture uploads other data, such as secondary command buffers, are not pipelined.  A block of memory allocated for one of these regions must not contain a region with a pending fence. 
+
+
+### Backing Objects to Main Memory
+
+To be completed. 
diff --git a/DriMemoryManagerDesign.moin b/DriMemoryManagerDesign.moin
deleted file mode 100644
index 8670dbc..0000000
--- a/DriMemoryManagerDesign.moin
+++ /dev/null
@@ -1,232 +0,0 @@
-#pragma section-numbers on
-'''''DRI Memory Manager Design'''''
-
-'''Contents:'''
-<<TableOfContents>>
-
-== Introduction ==
-
-The memory manager is roughly divided into two portions.  There is a small portion in the kernel, and the remainder resides in the user-mode driver.  This division is made for two reasons that are worth noting here.  By having a majority of the memory manager in user-mode avoids calling into the kernel for each memory operation.  On recent Linux kernels the cost of calling into the kernel has been greatly reduced, so this isn't as much of an issue as it once was.
-
-There is bigger issue driving this design decision.  The division of code between kernel and user roughly matches the division of mechanism and policy.  All of the policy decisions regarding which memory is allocated are made in user-mode.
-
-== Memory Manager Interface ==
-
-The userspace portion of the memory manager will live in libdrm. This means we can abstract the inner-working of the memory manager described below from the interface offered to X.org DDX and Mesa DRI drivers.
-This interface is open for discussion. 
-
-Feel very free to change these descriptions (Dave Airlie).
-
-=== drmMMCreate ===
-
-{{{
-void *drmMMCreate(int fd);
-}}}
-
-Create a instance of the DRM memory manager for the DRM open on the file descriptor fd. Before calling this the DRM driver must have been bootstrapped and the pools created by the DRM. This function
-just initialises all the memory manager userspace structures needed.
-
-=== drmMMDestroy ===
-
-{{{
-void drmMMDestroy(void *mm_handle);
-}}}
-
-Destroy an instance of the DRM memory manager. Free any internal structures allocated.
-
-=== drmMMAllocRegion ===
-
-{{{
-#define DRM_MM_ATTRIB_PINNED 0x1
-#define DRM_MM_ATTRIB_ADDMAP 0x2
-#define DRM_MM_ATTRIB_BACKED 0x4
-
-drm_region_id_t drmMMAllocRegion(void *mm_handle, int pool_id, unsigned int size, int alignment, unsigned int attributes, void *backing);
-}}}
-
-Allocate a region for this process from the pool identified by pool_id, of size size aligned with alignment.
-
-Pinned attribute makes the memory unmovable, this may need to be a privileged operation or not, scanout buffers need to be pinned.
-Addmap attribute will cause the DRM to add a mapping for this block, (not sure if useful just a suggestion) - may need to be pinned.
-Backed attribute means the client is providing a block of memory to back the area via the *backing pointer. - again suggestion only.
-
-Memory used by the driver as DMA or vertex buffers will have to be pinned, at least for the current usage where commands can be placed in DMA buffers without the lock held.  Any memory passed by the driver to the client will also have to be pinned, at least for as long as the client has access to it.  Once the DMA buffer is enqueued for execution, or retrieved from the client, the pinned attribute can be removed.  (So we'll need a call to do that?)
-
-=== drmMMFreeRegion ===
-
-{{{
-void drmMMFreeRegion(void *mm_handle, drm_region_id_t region_id)
-}}}
-
-Free the region of memory specified by region_id.
-
-=== drmMMGetRegionPointer ===
-
-{{{
-void *drmMMGetRegionPointer(void *mm_handle, drm_region_id_t region_id)
-}}}
-
-Return a pointer to the actual memory behind the region. (These pointers should not be stored across lock drops).
-
-=== drmMMGetHandleMappedRegion ===
-{{{
-drm_handle_t drmMMGetHandleMappedRegion(void *mm_handle, drm_region_id_t region_id);
-}}}
-
-Returns a DRM handle for an area that has been allocated using the ADDMAP attribute.
-
-=== drmMMMSetRegionAttributes ===
-{{{
-int drmMMSetRegionAttributes(void *mm_handle, drm_region_id_t region_id, unsigned int new_attribs);
-}}}
-
-Set the new attributes on the region.
-
-=== drmMMGetRegionAttributes ===
-{{{
-unsigned int drmMMGetRegionAttributes(void *mm_handle, drm_region_id_t region_id)
-}}}
-
-Return the current attributes of a region.
-
-=== drmMMSetRegionFence ===
-{{{
-int drmMMSetRegionFence(void *mm_handle, drm_region_id_t region_id, unsigned int condition);
-}}}
-
-Set the condition of a fence on the region specified by region_id. (Do multiple fences on a region make any sense?? or does the only last fence setting matter...)
-
-=== drmMMTestFence ===
-{{{
-int drmMMTestRegionFence(void *mm_handle, drm_region_id_t region_id);
-}}}
-
-Test the fence on a region_id.
-
-=== drmMMWaitFence ===
-{{{
-int drmMMWaitRegionFence(void *mm_handle, drm_region_id_t region_id);
-}}}
-
-Wait until the region fence is completed. (Unsure if this is needed - do we really want to wait in the drmMM layer - maybe needs a higher level interface).
-
-== Memory Manager Concepts ==
-
-The memory manager is based around the concept of allocating a block of memory to a named object.  The object and the associated block of memory is called a ''region.''  Each region has an associated ID.  This ID is a simple unsigned integer that is unique ''per-device.''
-
-By allocating memory to a named object, the owner of that object can be notified when portions of that object have been removed from memory by another process.  For example, a process can allocate memory for a texture object.  Another process can later over-write part of that object with its own object.  Before the first process can reuse that texture, it needs to be sure that all of the texture is still in memory.
-
-For objects that cannot just be "dumped" from memory, such as buffers used as rendering targets, a region of ''backing storage'' can be attached.  These regions are called ''precious.''  When another process needs to reclaim a block of memory from a precious region, it must first copy the data out of the region into the backing store.
-
-Changes to the state of memory are track via a log.  As a process allocates memory, frees memory, or changes the attributes of a region, it writes that information to a circular buffer in shared memory.  Each process independently processes the data in the log to keep its local view of the memory state up to date.  In distributed computing, this is a concept known as [[http://en.wikipedia.org/wiki/Virtual_synchrony|virtual synchrony]].
-
-== Kernel Interface ==
-
-The interface to the kernel portion of the memory manager consists of only five ioctls.  These ioctls are used to query parameters about memory pools, allocate region IDs, release region IDs, configure backing store for regions, and backing up regions to their backing store.  Of these five, only three will actually be implemented in the first phase of the implementation.
-
-=== Bootstrapping Memory Pools ===
-
-There is no direct user / kernel interface for bootstrapping the kernel portion of the memory manager.  Rather than providing interfaces for a user-mode controller process (e.g., the X-server) to configure the available memory pools, this task is handled by the device-specific bootstrap process.  For example, in the MGA DRM code, the function mga_do_dma_bootstrap (in [[http://cvs.freedesktop.org/dri/drm/shared-core/mga_dma.c?view=markup|mga_dma.c]]) knows what memory pools are available (e.g., on-card and AGP for AGP cards and on-card for PCI cards), how big they are, and why types of data can be stored in them.  This is ''exactly'' the information that is needed to bootstrap the memory manager.  Since the kernel already has all the required information, there is no reason to add new interfaces.
-
-Once the device-dependent code has initialized all of the memory pools that are available, it must create the logs.  The log data is stored in a series of pages in a shared memory area.  The first page describes where the log data can be found in the remaining pages.  The format of this data is an array of structures.  The array is indexed by pool ID.
-
-{{{
-struct drm_mmgr_pool_log_descriptor {
-    unsigned int first_page;  /**< First page containing log data. */
-    unsigned int page_count;  /**< Number of pages containing log data. */
-};
-}}}
-
-=== Management of Region IDs ===
-
-Region IDs are allocated from the DRM via the {{{DRM_IOCTL_MMGR_ALLOC_IDS}}} ioctl.  Region IDs are given to processes in fairly large, fixed size blocks.  Internally region IDs are tracked by a two page bitmap.  On common processors, this 65,536 region ID blocks.  Since a region ID consists of 30-bits, each block represents 16,384 IDs.  The first ID allocated and the count of IDs allocated is returned in the {{{drm_mmgr_region_id_range_t}}} structure by the {{{DRM_IOCTL_MMGR_ALLOC_IDS}}} ioctl.
-
-{{{
-typedef struct drm_mmgr_region_id_range {
-	unsigned int base_id;  /**< First region ID. */
-	unsigned int count;    /**< Number of IDs. */
-} drm_mmgr_region_id_range_t;
-}}}
-
-Once a block of IDs has been allocated to a process, it is the responsibility of the device-specific DRM code to track.  When the process closes the DRM file handle, all ID blocks used by the process must be released.
-
-Processes can also release blocks of IDs by calling the {{{DRM_IOCTL_MMGR_RELEASE_IDS}}} ioctl.  Since IDs are always allocated in fixed size blocks, only the base ID of the block being released is passed to this ioctl.
-
-=== Querying Pool Values ===
-
-There are two types off data about the memory manager that user-mode can query from the kernel.  Both types of query are done via the {{{DRM_IOCTL_MMGR_GETPARAM}}} ioctl.  User-mode can query information about per-device memory manager state and per-pool memory manager state.
-
-All {{{DRM_IOCTL_MMGR_GETPARAM}}} queries use the {{{drm_mmgr_getparam_t}}} structure.  For per-device queries the {{{pool_id}}} field is not used and should be set to zero.  The size and type of data pointed to by {{{value}}} varies with the query.
-
-{{{
-typedef struct drm_mmgr_getparam {
-	/**
-	 * Name of the parameter.  See \c drm_mmgr_getparam_mode_t.
-	 */
-	unsigned int param;
-
-	unsigned int pool_id;  /**< ID of the pool being queried. */
-	void __user * value;   /**< Storage for the value being queried. */
-} drm_mmgr_getparam_t;
-}}}
-
-A typical bootstrap procedure is for the user-mode device driver to query {{{DRM_MMGR_PARAM_NUM_POOLS}}} for the device, then query {{{DRM_MMGR_PARAM_POOL_IDS}}}.  The initial {{{DRM_MMGR_PARAM_NUM_POOLS}}} query is required so that the driver knows how much data will be returned in {{{value}}} by the {{{DRM_MMGR_PARAM_POOL_IDS}}} query.  The pool ID values are unique within a system.  That is, if a system has four graphics cards the each memory pool will have an ID that is unique across all cards.
-
-Once the IDs of the available pools are known, the size (via {{{DRM_MMGR_PARAM_POOL_SIZE}}}) and attribute bits (via {{{DRM_MMGR_PARAM_POOL_ATTRIBUTES}}}) are queried.
-
-The initial state of pool memory (i.e., which portions of memory are allocated or free) are queried via the {{{DRM_MMGR_PARAM_POOL_STATE_SIZE}}} / {{{DRM_MMGR_PARAM_POOL_STATE}}}.  The former is used to determine the amount of data, measured in bytes, returned by the later.  {{{DRM_MMGR_PARAM_POOL_STATE}}} returns an array of {{{drm_mmgr_puddle_data_t}}} structures in {{{value}}}.  This array is then used to initialize the driver's internal representation of memory.  {{{DRM_MMGR_PARAM_POOL_STATE_SIZE}}} must always return an integer multiple of {{{sizeof( drm_mmgr_puddle_data_t )}}}.
-
-{{{
-typedef struct drm_mmgr_puddle_data {
-	unsigned int size;       /**< Size, in bytes, of the puddle. */
-	unsigned int region_id;  /**< Region ID owning the puddle.  A region
-				  * ID of zero means that the puddle is not
-				  * allocated.
-				  */
-} drm_mmgr_puddle_data_t;
-}}}
-
-The final bootstrap step is for the user-mode driver to get a handle for the pool's logs.  The handle for the logs and size of the logs are queried via {{{DRM_MMGR_PARAM_LOG_HANDLE}}} and {{{DRM_MMGR_PARAM_LOG_SIZE}}}, respectively.  {{{DRM_MMGR_PARAM_LOG_SIZE}}} is measured in bytes but must be an integer multiple of the system's page size.  The first page is an array, indexed by pool ID, of {{{drm_mmgr_log_header_t}}} structures.  The remaining pages make up the log data.  The log data for each pool will always begin at a page boundary.  The log data will also always have a size that is a power of two.
-
-{{{
-typedef struct drm_mmgr_log_header {
-	unsigned int size;       /**< Size, in bytes, of the pool's log. */
-	unsigned int offset;     /**< Offset, in bytes, from the start of the
-				  * log data pages to the pool's log.
-				  */
-	volatile uint64_t index; /**< Index to next position in log. */
-
-	/**
-	 * Last index value processed by the kernel.
-	 */
-	volatile uint64_t kernel_index;
-} drm_mmgr_log_header_t;
-}}}
-
-=== The Log ===
-
-The log isn't strictly a kernel interface, but it is created by and obtained from the kernel.  However, the kernel does 'not' write data to the log.  Each process maintains a local 64-bit counter representing the last index into the log that it has processed.  Before accessing a region, the process must compare its local counter with the {{{drm_mmgr_log_header_t::index}}} for the pool containing the region.  If the values are not equal, the process much "play back" instructions from the log until they are equal.
-
-Each instruction in the log begins with an {{{unsigned int}}} header containing two pieces of data.  The least-significant 2-bits of the value specify the instruction, and the next 30-bits contain the associated region ID.  On architectures where {{{unsigned int}}} is more than 32-bits, the most-significant bits must be zero.  Depending on the instruction, the initial {{{unsigned int}}} may be followed by one or more additional {{{unsigned int}}} fields.
-
-When accessing the log, the index {{{current_index & (log->size - 1)}}} is used.  If the value of {{{log->index & ~(log->size - 1)}}} is greater than {{{current_index & ~(log->size - 1)}}} and the value of {{{log->index & (log->size - 1)}}} is greater than {{{current_index & (log->size - 1)}}} the log has wrapped around since the last time the process played back log data.  This means that the process has missed some instructions.  This means that the process must re-bootstrap its view of memory by querying {{{DRM_MMGR_PARAM_POOL_STATE_SIZE}}} and {{{DRM_MMGR_PARAM_POOL_STATE}}}.
-
-A process can also determine if a memory operation will wrap the log for the kernel.  Since the kernel's view of memory is used to bootstrap (and re-bootstrap) new processes, it is critical that the log '''never''' wraps for the kernel.  By performing a similar comparison using {{{log->kernel_index}}} and {{{current_index}}} the process can determine if a wrap is about to occur.  If the log is about to wrap for the kernel, the process can prevent this cataclysmic event by querying {{{DRM_MMGR_PARAM_POOL_STATE_SIZE}}}.  In order to calculate the value for this query the kernel must play the entire log.  Making this query can trick the kernel into catching up thereby avoiding a wrap.
-
-==== DRM_MMGR_LOG_ALLOCATE ====
-
-This instruction is used to allocate or free a block of memory.  If the region ID is non-zero, the instruction allocates a block of memory and associates it with the specified region ID.  If the region ID is zero, the instruction releases a block of memory.  Immediately following the initial {{{unsigned int}}} are two additional {{{unsigned int}}} fields.  The first specifies the offset of the memory block, and the second specifies the size of the memory block.
-
-==== DRM_MMGR_LOG_SET_ATTRIBUTE ====
-
-This instruction is used to specify the attribute bits associated with a region ID.  It is invalid to specify a region ID of zero with this instruction.  No attribute bits are currently specified.  In the (near) future bits for "precious" or "pin" will be specified.  It is also possible that additional "hints", such as "region fragmented" or "region won't be used again", can be created.  Beyond a few common attributes the remaining bits will be available for device-specific uses.
-
-==== DRM_MMGR_LOG_SET_FENCE ====
-
-This instruction is used to specify the attribute bits associated with a region ID.  It is invalid to specify a region ID of zero with this instruction.  Fences are similar in concept to the texture aging mechanism used in most open-source DRI drivers.  The DRM for each device maintains a monotonically increasing counter.  This counter increases when the hardware completes some operation.  Some hardware automatically maintains this counter, whereas other hardware notifies the driver to increment the counter via an interrupt.  The mechanism by which the counter is incremented is not important.  The important issue is that the user-mode driver be able to predict what the value of this counter will be when the hardware is finished using a region.  The predicted value is then set as the ''fence'' for that region.  If the current counter is greater than or equal to the fence, then the hardware is finished using that region.
-
-By communicating these fence values in the log, the user-mode drivers can correctly order memory operations.  Some cards (e.g., Radeon cards) can pipeline texture uploads.  On cards with this ability can safely ignore the fence value for texture allocations.  However, even on cards that can pipeline texture uploads other data, such as secondary command buffers, are not pipelined.  A block of memory allocated for one of these regions must not contain a region with a pending fence.
-
-=== Backing Objects to Main Memory ===
-
-To be completed.
diff --git a/DriTroubleshooting.mdwn b/DriTroubleshooting.mdwn
new file mode 100644
index 0000000..4ac758b
--- /dev/null
+++ b/DriTroubleshooting.mdwn
@@ -0,0 +1,253 @@
+
+This is a process for troubleshooting the DRI. It only works if you do it in order. OS names prefix OS-specific parts. 
+
+This process assumes you have XFree86 4.3.0 or newer installed. If not, update to any version of X.Org, or XFree86 4.3.0 or newer, before starting. 
+
+**Contents** [[!toc ]] 
+
+
+## Kernel Setup
+
+
+### AGP
+
+If you have a PCI card you may skip this section (DRM will load the AGP driver to resolve symbols, but otherwise doesn't need it).  If you have a non-Intel PCIE chipset you may also skip this step. 
+
+Check that AGP has been set up properly.  If you have a PCI or PCIE card you may skip this step.  Otherwise, if `dmesg | grep agp` returns nothing, you need to fix it. 
+
+FreeBSD: 
+
+* If `dmesg | grep agp` doesn't show anything about agp, make sure you have device agp in your kernel (it's default in -stable and -current). AGP does not work when loaded as a module after boot until FreeBSD 7.0-current. 
+* If your AGP module is loaded according to kldload but it didn't show up, probes fine, then you may have device agp in the kernel and loaded from loader.conf. This doesn't work, so remove it from loader.conf. 
+* If you aren't using RELENG_6 (note: not RELENG_6_0), you may need to update to get support for your AGP chipset. 
+* If you have device agp in the kernel but not in loader.conf, and are using RELENG_6 or newer, and it still doesn't probe, please file a PR containing the output of scanpci and your dmesg. 
+Linux: 
+
+* If there are no agpgart: lines, compile agpgart into your kernel or load it as a module. 
+* If it complains about an unsupported chipset/bridge, make sure you included your chipset-specific AGP support when you configured the kernel.  This chipset support is for your motherboard, not for your video card, so if you have a Radeon on an Intel motherboard, you need intel-agp.ko, not ati-agp.ko. 
+
+### DRM
+
+Check that the DRM (Direct Rendering Module, the kernel module) is loaded and has found your card. Do `dmesg | grep drm`. You should have several lines of info, with samples below: 
+
+FreeBSD: 
+
+
+[[!format txt """
+drm0: <ATI Radeon QL R200 8500 LE> port 0x9000-0x90ff mem 0xed000000-0xed00ffff,0xe0000000-0xe7ffffff irq 10 at device 0.0 on pci1
+info: [drm] AGP at 0xe8000000 64MB
+info: [drm] Initialized radeon 1.9.0 20020828 on minor 0
+info: [drm] Loading R200 Microcode
+"""]]
+Linux: 
+
+
+[[!format txt """
+[drm] AGP 0.99 on Intel i815 @ 0xe8000000 64MB
+[drm] Initialized radeon 1.1.1 20010405 on minor 0
+"""]]
+Note that 64MB is not the size of the card's memory; it's the size of the AGP aperture (how much system memory can be accessed by the card if X chooses to use that much). 
+
+FreeBSD: 
+
+* If kldload <card> (card being one of mga, r128, radeon, sis, tdfx) says `Exec format error`, check your dmesg for complaints about unresolved symbols. If the unresolved symbols are agp, look at the AGP instructions above. 
+* If kldstat shows your card module is loaded but nothing shows up in `dmesg | grep drm`, you may not have a supported card, or it may not be getting probed due to the PCI ID being missing from the driver. 
+Linux: 
+
+* If you get DRM version output but not your card-specific DRM version output, you may not have a supported card, or it may not be getting probed due to the PCI ID being missing from the driver. 
+If your card isn't getting probed, please make sure you are using current DRM CVS sources before submitting a report of missing support.  Instructions for building the DRM are at: Building. 
+
+If you are using current DRM sources and your card should be supported by an existing driver but isn't, please submit a report to [[http://bugs.freedesktop.org/|http://bugs.freedesktop.org/]] with the output of `scanpci` 
+
+
+## X server setup
+
+At this point DRM should be set up correctly.  Start the X server and `grep -i "Direct rendering" /var/log/Xorg.0.log`.  If that grep returns "Direct rendering enabled", skip ahead to the next section. 
+
+If that grep returns nothing, make sure you have lines for `Load "dri"` and `Load "glx"` in the Modules section of xorg.conf.  If your changes to xorg.conf have no effect, make sure the xorg.conf you are editing matches the one being used according to `grep config\ file /var/log/Xorg.0.log` 
+
+Next, make sure that X works with the DRM correctly. Look at the bottom of the X log where it has lines with [dri], [drm], [agp], etc. If there are any (EE) errors in there, look at those. 
+
+If you get a message like this: 
+
+
+[[!format txt """
+(EE) [dri] RADEONDRIScreenInit failed because of a version mismatch
+(EE) [dri] libdri version is 4.2.0 but version 5.0.0 is needed.
+(EE) [dri] Disabling DRI.
+"""]]
+then your libdri module is too old.  If you installed from a snapshot, be sure to update the common module.  If the version numbers are the other way around (version is 5.0 but version 4.2 is needed) then you updated your server without updating your 2D driver as well. 
+
+If it complains about the kernel module version, you have to update your kernel modules. For FreeBSD, this means either modules from -current or from -stable as described in the install section. For Linux, the kernel DRM is updated semi-regularly, and [[Alan Hourihane's website|http://www.xfree86.org/~alanh/]] also has kernel modules. 
+
+Linux: 
+
+* If you get this error message: [[!format txt """
+[agp] AGP not available
+"""]]despite the fact that the agpgart module loaded and initialized without problems, ensure that agpgart loads **before** the driver module for your chipset (like the radeon module). If agpgart loads later, the driver module will not see the AGP bus. As well, make sure the kernel module for your AGP bridge loads before the driver module for your chipset. For example, if your AGP bridge is an AMD Irongate (this can be determined via `lspci -v` and looking for the line containing AGP), make sure that amd_k7_agp is loaded before the driver module (say radeon). 
+* If you thought you had updated your kernel module and the updated version shows up after you modprobe the appropriate <card>.o, make sure your kernel doesn't have the DRM compiled in. If you `dmesg | grep drm`, it will show that multiple versions were loaded. Recompile your kernel without the DRM, and install the updated module again. 
+* If it says: [[!format txt """
+[drm] drmSetBusid failed (7, PCI:1:0:0), Permission denied
+"""]]people have said that it's because the modules were built with a different gcc version than the kernel. Make sure they are in sync. Also, `dmesg` output should show something about version magic mismatches if this is the case. Another possibility (for the i915/i810 chipsets) is that you have an old buggy version of the i810 driver. Be sure to upgrade to the latest and "greatest". **NOTE: There is at least one known case with the radeon driver where the gcc-version cause theory is not true.** 
+* If at this point, dmesg says: [[!format txt """
+[drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
+"""]]then you missed the part above about having the correct AGP modules loaded. 2.6 users need to make sure both the `agpgart` core module and the appropriate chipset-specific module are loaded. Run `lspci | grep "AGP bridge"` to find out what sort of AGP chipset you have. Intel needs `intel-agp`, VIA needs `via-agp`, etc. 
+If you find a line saying: 
+
+
+[[!format txt """
+(EE) RADEON(0): [dri] RADEONInitVisualConfigs failed (depth 8 not supported). Disabling DRI.
+"""]]
+or something along those lines, this is because none of the DRI drivers support rendering in 8-bit mode. If you have a Voodoo3, it only works in 16-bit mode and will say something similar if you try 32-bit. Change your depth appropriately by adding: 
+
+
+[[!format txt """
+   DefaultDepth 16
+"""]]
+or 
+
+
+[[!format txt """
+   DefaultDepth 24
+   DefaultFbBpp 32
+"""]]
+as appropriate to your xorg.conf's Screen section. 
+
+If there are no [dri] lines and it says Direct Rendering disabled, you may be trying to use too high a resolution. `grep Static\ buffer /var/log/Xorg.0.log` will find a line like: 
+
+
+[[!format txt """
+(WW) ATI(0): DRI static buffer allocation failed -- need at least 4608 kB video memory
+"""]]
+If so, reduce your resolution or color depth. The video ram necessary for a given resolution/depth is width*height*(depth/8)*3 kilobytes. (The 3 is for front, back, and depth buffers). 
+
+If you are using Intel i8xx hardware and it says: 
+
+
+[[!format txt """
+(WW) I810(0): xf86AllocateGARTMemory: allocation of 1024 pages failed
+   (Cannot allocate memory)
+"""]]
+You need to have X.Org allocate more system memory to the integrated graphics. In the Device section of xorg.conf, set VideoRam to something higher, for example:. 
+
+
+[[!format txt """
+   VideoRam 32768
+"""]]
+If you see messages about: 
+
+
+[[!format txt """
+Symbol __glXActiveScreens from module /usr/X11R6/lib/modules/extensions/libdri.a is unresolved!
+"""]]
+make sure you have Load "glx" in your xorg.conf's modules section. If you do have Load "glx", make sure you don't have any parts of the nvidia binary driver installed, particularly libglx.so*. Remove those, and reinstall X.Org if you continue to have problems. 
+
+
+## Userspace setup
+
+Next, look at a GL program. Set the environment variable LIBGL_DEBUG to verbose, i.e. `setenv LIBGL_DEBUG verbose` for csh-based shells or `export LIBGL_DEBUG=verbose` for bash-based shells. Run glxinfo, which should be included with X.Org. At the top it should show libGL trying to load the driver-specific hardware rendering library, like: 
+
+
+[[!format txt """
+libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/radeon_dri.so.
+"""]]
+If it isn't doing that, you have replaced your X.Org-provided libGL with some other libGL, or it's finding an old libGL from somewhere.  Run `ldd /usr/X11R6/bin/glxinfo` and see which libGL it's finding. Make sure it's the one in `/usr/X11R6/lib/libGL`, or a link in `/usr/lib` to the one in `/usr/X11R6/lib`. You shouldn't have any libMesaGL* on your system. 
+
+If the driver complains about unresolved symbols: 
+
+
+[[!format txt """
+libGL error: dlopen /usr/X11R6/lib/modules/dri/radeon_dri.so failed
+   (/usr/X11R6/lib/modules/dri/radeon_dri.so: undefined symbol: _glapi_noop_enable_warnings)
+"""]]
+then your libGL is out of sync with your DRI drivers.  Because APIs change, you typically need a libGL from the latest X.Org release to run DRI drivers, and sometimes you need a libGL from X.Org CVS for the latest drivers.  Reinstall both your drivers and your libGL from sources from the same date. 
+
+If you get: 
+
+
+[[!format txt """
+libGL error: failed to open DRM: Operation not permitted
+libGL error: reverting to (slow) indirect rendering
+"""]]
+then you are trying to run as a user that doesn't have permission to use the DRI (root is the default allowed user). To let all users access the DRI, add the following section to your xorg.conf: 
+
+
+[[!format txt """
+Section "DRI"
+    Mode 0666
+EndSection
+"""]]
+If you get (the driver name may vary): 
+
+
+[[!format txt """
+libGL error: dlopen /usr/X11R6/lib/modules/dri/r200_dri.so failed \
+(libexpat.so.1 : cannot open shared object file: No such file or directory)
+libGL error: unable to find driver: r200_dri.so
+"""]]
+then make sure that you have libexpat.so.1 installed. Binary snapshots now come with a statically linked libexpat, so this should no longer be a problem. 
+
+If you get (the driver name may vary): 
+
+
+[[!format txt """
+libGL error: dlopen /usr/X11R6/lib/modules/dri/r200_dri.so failed \
+(r200_dri.so : cannot open shared object file: No such file or directory)
+"""]]
+then make sure you have compiled the appropriate dri module for your card. It it could be either in a separate file (r200_dri.so in this case), or bundled in libGL.so. Edit `xc/config/cf/host.def` and make sure you list at least your driver (if not all available) in a line:\ \ 
+
+
+[[!format txt """
+#define BuildXF86DRI YES
+/* 2D accel drivers are: ati mga glint s3virge sis savage nv tga rendition tdfx vga i810 sunffb sunleo suncg6 suncg3 suncg14 suntcx */
+#define XF86CardDrivers ati
+/* the next line DriDrivers defines dri modules. Valid choices: gamma i810 i915 mach64 mga r128 radeon r200 tdfx savage sis ffb
+   ati is not a valid DriDriver name. For new Radeon cards use r200 instead. */
+#define DriDrivers radeon r200
+"""]]
+If you have a 3dfx card and it's complaining about libglide3, or there are glide errors, you need to install the correct glide for your card as provided by your distribution. 
+
+If you are using a radeon and it complains about the module versions and maybe fails on an assertion, you need to update your DRM as in the instructions above. 
+
+If you've made it this far, glxinfo should be printing `direct rendering: Yes` and direct rendering for native GL programs should be working. Make sure that you are running at reasonable settings for your card, and maybe adjust your expectations of speed. 
+
+If you are experiencing trouble using GL with any program, maybe setting more [[environment variables|http://dri.sourceforge.net/doc/dri_driver_features.phtml]] may help you. 
+
+FreeBSD: 
+
+* Linux compatibility has its own set of issues. To debug Linux DRI compatibility (i.e. quake3/UT), use `/compat/linux/usr/X11R6/bin/glxinfo` with `LIBGL_DEBUG=verbose` set. You should be using -current as of April 25, 2003, or -stable as of May 2, 2003. Your linux_dri version should exactly match the X you have installed. If not you'll probably get segfaults. If your X.Org segfaults, make sure you don't have the linux_glx port installed. If you get coredumps on your system with SSE support (Pentium 3 and up, Athlon XP and up), you may need to set the environment variable MESA_FORCE_SSE to 1 due to what appears to be a bug with our linux compat's signal handling. 
+If you get message like this ([[original solution|http://wiki.archlinux.org/index.php/ATI_Radeon_&_Kernel_2.6]]): 
+
+
+[[!format txt """
+fglrx: libGL version undetermined - OpenGL module is using glapi fallback
+"""]]
+* This could be caused by having multiple versions of libGL.so on your system. Run: 
+
+[[!format txt """
+$ sudo updatedb
+$ locate libGL.so
+"""]]
+This should return the following output: 
+
+
+[[!format txt """
+$ locate libGL.so
+/usr/lib/libGL.so
+/usr/lib/libGL.so.1
+/usr/lib/libGL.so.1.2
+$
+"""]]
+These are the only three libGL.so files you should have on your system. If you have any more (eg. /usr/X11R6/lib/libGL.so.1.2), then remove them. This should fix your problem. Then using Gentoo linux, you should update and remerge `eselect-opengl` package: 
+
+
+[[!format txt """
+emerge --oneshot eselect-opengl
+"""]]
+
+
+---
+
+ 
+
+* [[CategoryTroubleshooting|CategoryTroubleshooting]] 
+\ No newline at end of file
diff --git a/DriTroubleshooting.moin b/DriTroubleshooting.moin
deleted file mode 100644
index be9e138..0000000
--- a/DriTroubleshooting.moin
+++ /dev/null
@@ -1,222 +0,0 @@
-This is a process for troubleshooting the DRI. It only works if you do it in order. OS names prefix OS-specific parts.
-
-This process assumes you have XFree86 4.3.0 or newer installed. If not, update to any version of X.Org, or XFree86 4.3.0 or newer, before starting.
-
-'''Contents''' <<TableOfContents>>
-
-== Kernel Setup ==
-=== AGP ===
-If you have a PCI card you may skip this section (DRM will load the AGP driver to resolve symbols, but otherwise doesn't need it).  If you have a non-Intel PCIE chipset you may also skip this step.
-
-Check that AGP has been set up properly.  If you have a PCI or PCIE card you may skip this step.  Otherwise, if {{{dmesg | grep agp}}} returns nothing, you need to fix it.
-
-FreeBSD:
-
- * If {{{dmesg | grep agp}}} doesn't show anything about agp, make sure you have device agp in your kernel (it's default in -stable and -current). AGP does not work when loaded as a module after boot until FreeBSD 7.0-current.
- * If your AGP module is loaded according to kldload but it didn't show up, probes fine, then you may have device agp in the kernel and loaded from loader.conf. This doesn't work, so remove it from loader.conf.
- * If you aren't using RELENG_6 (note: not RELENG_6_0), you may need to update to get support for your AGP chipset.
- * If you have device agp in the kernel but not in loader.conf, and are using RELENG_6 or newer, and it still doesn't probe, please file a PR containing the output of scanpci and your dmesg.
-Linux:
-
- * If there are no agpgart: lines, compile agpgart into your kernel or load it as a module.
- * If it complains about an unsupported chipset/bridge, make sure you included your chipset-specific AGP support when you configured the kernel.  This chipset support is for your motherboard, not for your video card, so if you have a Radeon on an Intel motherboard, you need intel-agp.ko, not ati-agp.ko.
-=== DRM ===
-Check that the DRM (Direct Rendering Module, the kernel module) is loaded and has found your card. Do {{{dmesg | grep drm}}}. You should have several lines of info, with samples below:
-
-FreeBSD:
-
-{{{
-drm0: <ATI Radeon QL R200 8500 LE> port 0x9000-0x90ff mem 0xed000000-0xed00ffff,0xe0000000-0xe7ffffff irq 10 at device 0.0 on pci1
-info: [drm] AGP at 0xe8000000 64MB
-info: [drm] Initialized radeon 1.9.0 20020828 on minor 0
-info: [drm] Loading R200 Microcode
-}}}
-Linux:
-
-{{{
-[drm] AGP 0.99 on Intel i815 @ 0xe8000000 64MB
-[drm] Initialized radeon 1.1.1 20010405 on minor 0
-}}}
-Note that 64MB is not the size of the card's memory; it's the size of the AGP aperture (how much system memory can be accessed by the card if X chooses to use that much).
-
-FreeBSD:
-
- * If kldload <card> (card being one of mga, r128, radeon, sis, tdfx) says {{{Exec format error}}}, check your dmesg for complaints about unresolved symbols. If the unresolved symbols are agp, look at the AGP instructions above.
- * If kldstat shows your card module is loaded but nothing shows up in {{{dmesg | grep drm}}}, you may not have a supported card, or it may not be getting probed due to the PCI ID being missing from the driver.
-Linux:
-
- * If you get DRM version output but not your card-specific DRM version output, you may not have a supported card, or it may not be getting probed due to the PCI ID being missing from the driver.
-If your card isn't getting probed, please make sure you are using current DRM CVS sources before submitting a report of missing support.  Instructions for building the DRM are at: Building.
-
-If you are using current DRM sources and your card should be supported by an existing driver but isn't, please submit a report to http://bugs.freedesktop.org/ with the output of {{{scanpci}}}
-
-== X server setup ==
-At this point DRM should be set up correctly.  Start the X server and {{{grep -i "Direct rendering" /var/log/Xorg.0.log}}}.  If that grep returns "Direct rendering enabled", skip ahead to the next section.
-
-If that grep returns nothing, make sure you have lines for `Load "dri"` and `Load "glx"` in the Modules section of xorg.conf.  If your changes to xorg.conf have no effect, make sure the xorg.conf you are editing matches the one being used according to {{{grep config\ file /var/log/Xorg.0.log}}}
-
-Next, make sure that X works with the DRM correctly. Look at the bottom of the X log where it has lines with [dri], [drm], [agp], etc. If there are any (EE) errors in there, look at those.
-
-If you get a message like this:
-
-{{{
-(EE) [dri] RADEONDRIScreenInit failed because of a version mismatch
-(EE) [dri] libdri version is 4.2.0 but version 5.0.0 is needed.
-(EE) [dri] Disabling DRI.
-}}}
-then your libdri module is too old.  If you installed from a snapshot, be sure to update the common module.  If the version numbers are the other way around (version is 5.0 but version 4.2 is needed) then you updated your server without updating your 2D driver as well.
-
-If it complains about the kernel module version, you have to update your kernel modules. For FreeBSD, this means either modules from -current or from -stable as described in the install section. For Linux, the kernel DRM is updated semi-regularly, and [[http://www.xfree86.org/~alanh/|Alan Hourihane's website]] also has kernel modules.
-
-Linux:
-
- * If you get this error message:
- {{{
-[agp] AGP not available
-}}}
- despite the fact that the agpgart module loaded and initialized without problems, ensure that agpgart loads '''before''' the driver module for your chipset (like the radeon module). If agpgart loads later, the driver module will not see the AGP bus. As well, make sure the kernel module for your AGP bridge loads before the driver module for your chipset. For example, if your AGP bridge is an AMD Irongate (this can be determined via {{{lspci -v}}} and looking for the line containing AGP), make sure that amd_k7_agp is loaded before the driver module (say radeon).
- * If you thought you had updated your kernel module and the updated version shows up after you modprobe the appropriate <card>.o, make sure your kernel doesn't have the DRM compiled in. If you {{{dmesg | grep drm}}}, it will show that multiple versions were loaded. Recompile your kernel without the DRM, and install the updated module again.
- * If it says:
- {{{
-[drm] drmSetBusid failed (7, PCI:1:0:0), Permission denied
-}}}
- people have said that it's because the modules were built with a different gcc version than the kernel. Make sure they are in sync. Also, {{{dmesg}}} output should show something about version magic mismatches if this is the case. Another possibility (for the i915/i810 chipsets) is that you have an old buggy version of the i810 driver. Be sure to upgrade to the latest and "greatest". '''NOTE: There is at least one known case with the radeon driver where the gcc-version cause theory is not true.'''
- * If at this point, dmesg says:
- {{{
-[drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
-}}}
- then you missed the part above about having the correct AGP modules loaded. 2.6 users need to make sure both the `agpgart` core module and the appropriate chipset-specific module are loaded. Run {{{lspci | grep "AGP bridge"}}} to find out what sort of AGP chipset you have. Intel needs `intel-agp`, VIA needs `via-agp`, etc.
-If you find a line saying:
-
-{{{
-(EE) RADEON(0): [dri] RADEONInitVisualConfigs failed (depth 8 not supported). Disabling DRI.
-}}}
-or something along those lines, this is because none of the DRI drivers support rendering in 8-bit mode. If you have a Voodoo3, it only works in 16-bit mode and will say something similar if you try 32-bit. Change your depth appropriately by adding:
-
-{{{
-   DefaultDepth 16
-}}}
-or
-
-{{{
-   DefaultDepth 24
-   DefaultFbBpp 32
-}}}
-as appropriate to your xorg.conf's Screen section.
-
-If there are no [dri] lines and it says Direct Rendering disabled, you may be trying to use too high a resolution. {{{grep Static\ buffer /var/log/Xorg.0.log}}} will find a line like:
-
-{{{
-(WW) ATI(0): DRI static buffer allocation failed -- need at least 4608 kB video memory
-}}}
-If so, reduce your resolution or color depth. The video ram necessary for a given resolution/depth is width*height*(depth/8)*3 kilobytes. (The 3 is for front, back, and depth buffers).
-
-If you are using Intel i8xx hardware and it says:
-
-{{{
-(WW) I810(0): xf86AllocateGARTMemory: allocation of 1024 pages failed
-   (Cannot allocate memory)
-}}}
-You need to have X.Org allocate more system memory to the integrated graphics. In the Device section of xorg.conf, set !VideoRam to something higher, for example:.
-
-{{{
-   VideoRam 32768
-}}}
-If you see messages about:
-
-{{{
-Symbol __glXActiveScreens from module /usr/X11R6/lib/modules/extensions/libdri.a is unresolved!
-}}}
-make sure you have Load "glx" in your xorg.conf's modules section. If you do have Load "glx", make sure you don't have any parts of the nvidia binary driver installed, particularly libglx.so*. Remove those, and reinstall X.Org if you continue to have problems.
-
-== Userspace setup ==
-Next, look at a GL program. Set the environment variable LIBGL_DEBUG to verbose, i.e. {{{setenv LIBGL_DEBUG verbose}}} for csh-based shells or {{{export LIBGL_DEBUG=verbose}}} for bash-based shells. Run glxinfo, which should be included with X.Org. At the top it should show libGL trying to load the driver-specific hardware rendering library, like:
-
-{{{
-libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/radeon_dri.so.
-}}}
-If it isn't doing that, you have replaced your X.Org-provided libGL with some other libGL, or it's finding an old libGL from somewhere.  Run {{{ldd /usr/X11R6/bin/glxinfo}}} and see which libGL it's finding. Make sure it's the one in {{{/usr/X11R6/lib/libGL}}}, or a link in {{{/usr/lib}}} to the one in {{{/usr/X11R6/lib}}}. You shouldn't have any libMesaGL* on your system.
-
-If the driver complains about unresolved symbols:
-
-{{{
-libGL error: dlopen /usr/X11R6/lib/modules/dri/radeon_dri.so failed
-   (/usr/X11R6/lib/modules/dri/radeon_dri.so: undefined symbol: _glapi_noop_enable_warnings)
-}}}
-then your libGL is out of sync with your DRI drivers.  Because APIs change, you typically need a libGL from the latest X.Org release to run DRI drivers, and sometimes you need a libGL from X.Org CVS for the latest drivers.  Reinstall both your drivers and your libGL from sources from the same date.
-
-If you get:
-
-{{{
-libGL error: failed to open DRM: Operation not permitted
-libGL error: reverting to (slow) indirect rendering
-}}}
-then you are trying to run as a user that doesn't have permission to use the DRI (root is the default allowed user). To let all users access the DRI, add the following section to your xorg.conf:
-
-{{{
-Section "DRI"
-    Mode 0666
-EndSection
-}}}
-If you get (the driver name may vary):
-
-{{{
-libGL error: dlopen /usr/X11R6/lib/modules/dri/r200_dri.so failed \
-(libexpat.so.1 : cannot open shared object file: No such file or directory)
-libGL error: unable to find driver: r200_dri.so
-}}}
-then make sure that you have libexpat.so.1 installed. Binary snapshots now come with a statically linked libexpat, so this should no longer be a problem.
-
-If you get (the driver name may vary):
-
-{{{
-libGL error: dlopen /usr/X11R6/lib/modules/dri/r200_dri.so failed \
-(r200_dri.so : cannot open shared object file: No such file or directory)
-}}}
-then make sure you have compiled the appropriate dri module for your card. It it could be either in a separate file (r200_dri.so in this case), or bundled in libGL.so. Edit {{{xc/config/cf/host.def}}} and make sure you list at least your driver (if not all available) in a line:\ \
-
-{{{
-#define BuildXF86DRI YES
-/* 2D accel drivers are: ati mga glint s3virge sis savage nv tga rendition tdfx vga i810 sunffb sunleo suncg6 suncg3 suncg14 suntcx */
-#define XF86CardDrivers ati
-/* the next line DriDrivers defines dri modules. Valid choices: gamma i810 i915 mach64 mga r128 radeon r200 tdfx savage sis ffb
-   ati is not a valid DriDriver name. For new Radeon cards use r200 instead. */
-#define DriDrivers radeon r200
-}}}
-If you have a 3dfx card and it's complaining about libglide3, or there are glide errors, you need to install the correct glide for your card as provided by your distribution.
-
-If you are using a radeon and it complains about the module versions and maybe fails on an assertion, you need to update your DRM as in the instructions above.
-
-If you've made it this far, glxinfo should be printing {{{direct rendering: Yes}}} and direct rendering for native GL programs should be working. Make sure that you are running at reasonable settings for your card, and maybe adjust your expectations of speed.
-
-If you are experiencing trouble using GL with any program, maybe setting more [[http://dri.sourceforge.net/doc/dri_driver_features.phtml|environment variables]] may help you.
-
-FreeBSD:
-
- * Linux compatibility has its own set of issues. To debug Linux DRI compatibility (i.e. quake3/UT), use {{{/compat/linux/usr/X11R6/bin/glxinfo}}} with {{{LIBGL_DEBUG=verbose}}} set. You should be using -current as of April 25, 2003, or -stable as of May 2, 2003. Your linux_dri version should exactly match the X you have installed. If not you'll probably get segfaults. If your X.Org segfaults, make sure you don't have the linux_glx port installed. If you get coredumps on your system with SSE support (Pentium 3 and up, Athlon XP and up), you may need to set the environment variable MESA_FORCE_SSE to 1 due to what appears to be a bug with our linux compat's signal handling.
-If you get message like this ([[http://wiki.archlinux.org/index.php/ATI_Radeon_&_Kernel_2.6|original solution]]):
-
-{{{
-fglrx: libGL version undetermined - OpenGL module is using glapi fallback
-}}}
- * This could be caused by having multiple versions of libGL.so on your system. Run:
-{{{
-$ sudo updatedb
-$ locate libGL.so
-}}}
-This should return the following output:
-
-{{{
-$ locate libGL.so
-/usr/lib/libGL.so
-/usr/lib/libGL.so.1
-/usr/lib/libGL.so.1.2
-$
-}}}
-These are the only three libGL.so files you should have on your system. If you have any more (eg. /usr/X11R6/lib/libGL.so.1.2), then remove them. This should fix your problem. Then using Gentoo linux, you should update and remerge {{{eselect-opengl}}} package:
-
-{{{
-emerge --oneshot eselect-opengl
-}}}
-----
- . CategoryTroubleshooting
diff --git a/DriWithoutX.mdwn b/DriWithoutX.mdwn
new file mode 100644
index 0000000..01720c6
--- /dev/null
+++ b/DriWithoutX.mdwn
@@ -0,0 +1,39 @@
+
+
+# DRI without X
+
+
+## Can DRI run without X?
+
+The first question you have to ask is whether you really should throw out X11. X11 does event handling, multiple windows, etc. It can also be made quite light weight -- it's running in 600k on an IPAQ. 
+
+If you decide you do need to throw out X, then you have to ask yourself if the DRI is the right solution for your problem. The DRI handles multiple 3D clients accessing hardware at the same time, sharing the same screen, in a robust and secure manner. If you don't need those properties then DRI isn't necessarily the right solution for you. 
+
+If you get to this point, then it would be theoretically possible to remove the DRI from X11 and have it run without X11. There's no code to support that at this point, so it would require some significant work to do that. 
+
+
+## What would be the advantages of a non-X version of DRI?
+[[!table header="no" class="mointable" data="""
+Pros | Cons
+Eliminate any performance bottlenecks the X server may be causing.  Since we are 3D only, any extraneous locking/unlocking, periodic refreshes of the (hidden) 2D portion of the display, etc., will cause unexpected slowdowns. | If the X server never does any drawing then the overhead is minimal. Locking is done around hardware operations. A lock check is a single CAS instruction. Assuming your 3D window covers the X root, then there are no 2D portions to redisplay.
+ Eliminate wasted system memory requirements.   |  Yes, there will be some resources from the X server, but I think not much. 
+ Eliminate on-card font/pixmap/surface/etc caches that just waste memory.   |  If you don't use them they aren't taking any resources. Right now, there is a small pixmap cache that's statically added to 2D. Removing that is a trivial code change. Making it dynamic (3D steals it away from 2D) is not too tough and a better solution than any static allocation.  
+ Eliminate the need for extra peripherals, such as mice.   |  Allowing operations without a mouse should be trivial if it isn't a configuration option already.  
+ Reduction in the amount of software necessary to install/maintain on a customer's system.  Certainly none of my customers would have been able to install XFree86 4.0 on their own.   |  XFree86 4.0 installs with appropriate packaging are trivial. What you're saying is that no one has done the packaging work for you, and that's correct. If you create your own stripped DRI version you'll be in for a lot more packaging work on your own.  The impact of the X server is on the 3D graphics pipeline is very little. Essentially none in the 3D pipeline. Some resources, but I think not much. Realize the CAS is in the driver, so you're looking at creating a custom version of that as well. I think effort spent avoiding the CAS, creating your own window system binding for GL, and moving the DRI functionality out of the X server would be much better spent optimizing Mesa and the driver instead. You have to focus resources where they provide the biggest payoff. 
+"""]]
+
+
+## I would like to make a X11 free access to 3D...
+
+See: 
+
+   * MiniGLX 
+   * DirectFB 
+   * [[FBDRI|FBDRI]] 
+Another option is to make the DRI work with TinyX. TinyX runs in 600k and gives you all of X. It should be a fairly straight forward project. As soon as you want more than one window, it makes a lot of sense to use the X framework that already exists. 
+
+
+
+---
+
+ [[CategoryFaq|CategoryFaq]] 
diff --git a/DriWithoutX.moin b/DriWithoutX.moin
deleted file mode 100644
index 419411c..0000000
--- a/DriWithoutX.moin
+++ /dev/null
@@ -1,33 +0,0 @@
-= DRI without X =
-
-== Can DRI run without X? ==
-
-The first question you have to ask is whether you really should throw out X11. X11 does event handling, multiple windows, etc. It can also be made quite light weight -- it's running in 600k on an IPAQ.
-
-If you decide you do need to throw out X, then you have to ask yourself if the DRI is the right solution for your problem. The DRI handles multiple 3D clients accessing hardware at the same time, sharing the same screen, in a robust and secure manner. If you don't need those properties then DRI isn't necessarily the right solution for you.
-
-If you get to this point, then it would be theoretically possible to remove the DRI from X11 and have it run without X11. There's no code to support that at this point, so it would require some significant work to do that.
-
-== What would be the advantages of a non-X version of DRI? ==
-
-||Pros||Cons||
-||Eliminate any performance bottlenecks the X server may be causing.  Since we are 3D only, any extraneous locking/unlocking, periodic refreshes of the (hidden) 2D portion of the display, etc., will cause unexpected slowdowns.||If the X server never does any drawing then the overhead is minimal. Locking is done around hardware operations. A lock check is a single CAS instruction. Assuming your 3D window covers the X root, then there are no 2D portions to redisplay.||
-|| Eliminate wasted system memory requirements.  || Yes, there will be some resources from the X server, but I think not much. ||
-|| Eliminate on-card font/pixmap/surface/etc caches that just waste memory.  || If you don't use them they aren't taking any resources. Right now, there is a small pixmap cache that's statically added to 2D. Removing that is a trivial code change. Making it dynamic (3D steals it away from 2D) is not too tough and a better solution than any static allocation.  ||
-|| Eliminate the need for extra peripherals, such as mice.  || Allowing operations without a mouse should be trivial if it isn't a configuration option already.  ||
-|| Reduction in the amount of software necessary to install/maintain on a customer's system.  Certainly none of my customers would have been able to install XFree86 4.0 on their own.  || XFree86 4.0 installs with appropriate packaging are trivial. What you're saying is that no one has done the packaging work for you, and that's correct. If you create your own stripped DRI version you'll be in for a lot more packaging work on your own.  The impact of the X server is on the 3D graphics pipeline is very little. Essentially none in the 3D pipeline. Some resources, but I think not much. Realize the CAS is in the driver, so you're looking at creating a custom version of that as well. I think effort spent avoiding the CAS, creating your own window system binding for GL, and moving the DRI functionality out of the X server would be much better spent optimizing Mesa and the driver instead. You have to focus resources where they provide the biggest payoff. ||
-
-== I would like to make a X11 free access to 3D... ==
-
-See:
-
-  * MiniGLX
-
-  * DirectFB
-
-  * [[FBDRI]]
-  
-Another option is to make the DRI work with TinyX. TinyX runs in 600k and gives you all of X. It should be a fairly straight forward project. As soon as you want more than one window, it makes a lot of sense to use the X framework that already exists.
-
-----
-CategoryFaq
diff --git a/DriverFiles.moin b/DriverFiles.mdwn
index 4133f29..bbc83b6 100644
--- a/DriverFiles.moin
+++ b/DriverFiles.mdwn
@@ -1,64 +1,66 @@
-== Driver Files ==
-This page is dedicated to describing what functions live where and how all the actual files fit together for the 2D driver, the 3D driver, and the DRM.  There is some variation between different drivers, but for the most part there is pattern of driver structure.  
-
-
-=== 2D Driver ===
-The 2D driver source is found here:
-xorg/drivers/xf86-video-*
-
-*_driver.c - This is the guts of the 2D driver.  It usually contains the mandatory functions (PreInit() ScreenInit(), VT switching, etc. - see the XFree86 [[http://www.xfree86.org/current/DESIGN.html|DESIGN]] document for more info on required functions) and the mode setting/switching code.
-
-*_regs.h - Contains the register defines and macros.
-
-*.h or *_driver.h - usually contains the driver specific info struct and other structs needed by the driver.  May also contain some macro defines and function definitions shared by the various files in the driver.
-
-*_video.c or *xv.c - Contains the code to set up and use the video overlay (Xv).
-
-*_hwmc.c - Contains the code to set up and use the iDCT or motion compensation features with the video overlay (XvMC).  The XvMC user libraries live in xorg/lib/libXvMC.
-
-*_accel.c - Contains the 2D acceleration code.
-
-*_shadow.c - Contains functions to support the shadow framebuffer if the driver supports it.
-
-*_i2c.c - Contains driver specific code for accessing the i2c bus on the card/chip.  It's usually used for DDC2.
-
-*_dga.c - Contains code to support DGA, an old feature that lets apps write driectly to the framebuffer.  It's rarely used nowadays.
-
-*_cursor.c - Contains code to enable the hardware cursor.
-
-*_dri.c - Contains server side code to set up the DRI.
-
-*_sarea.h - Contains defines needed for the SAREA (shared memory area).
-
-
-=== 3D driver ===
-The 3D driver source is found here:
-mesa/src/drv/
-
-*_3d_reg.h or *_reg.h - 3D register and macro defines.
-
-*_tex.[ch] - Contains texture code.
-
-*_xmesa.c or *_screen.[ch] and *_context.[ch] - These deal with screen and context management. The xmesa name is historical. There used to be a number of callbacks whose names started with XMesa. They were called directly by Mesa. The interface has changed in Mesa 4.0. Now there is an API record that specifies these driver entry points. In some drivers (radeon, r200, r128) these functions are in *_screen.[ch] and *_context.[ch].
-
-*_span.[ch] - Access to spans of the frame buffer, used for software rasterization fallbacks.
-
-*_tris.[ch] - It draws all primitives using some templates in mesa/tnl_dd. All primitives are mapped to the ones supported directly by the hardware. At the highest level whole Mesa vertex buffers are rendered.
-
-It is not the most efficient way of rendering because all strips and fans are decomposed into individual triangles. So lots of duplicate
-vertices are emitted to the hardware. At some point we may implement our own render stage that takes advantages of hardware strips and fans. r128 and mga used to have *_fastpath.[ch] files in Mesa 3 that did just that. So did the savage driver. These were not ported to Mesa 4 in any of these drivers. Maybe it's not such a big performance win in practice.
-
-*_state.[ch] - manage the 3D state in hardware.
-
-*_dd.[ch] - Some selection of device driver functions. I don't know why they are collected in this file. Maybe a historical leftover. The radeon drivers don't have it anymore. It's pretty short in other drivers.
-
-*_ioctl.[ch]  - ioctls for use with the DRM.
-
-*_vb.[ch] - Vertex setup. Determines which components are needed for the current state and generates appropriate hardware vertices from Mesa vertices.  For the D3D-like vertex formats there are templates in mesa/tnl_dd.
-
-
-=== DRM ===
-The linux DRM source is found here:
-mesa/drm
-
-ToDo
+
+
+## Driver Files
+
+This page is dedicated to describing what functions live where and how all the actual files fit together for the 2D driver, the 3D driver, and the DRM.  There is some variation between different drivers, but for the most part there is pattern of driver structure.   
+
+
+### 2D Driver
+
+The 2D driver source is found here: xorg/drivers/xf86-video-* 
+
+*_driver.c - This is the guts of the 2D driver.  It usually contains the mandatory functions ([[PreInit|PreInit]]() [[ScreenInit|ScreenInit]](), VT switching, etc. - see the XFree86 [[DESIGN|http://www.xfree86.org/current/DESIGN.html]] document for more info on required functions) and the mode setting/switching code. 
+
+*_regs.h - Contains the register defines and macros. 
+
+*.h or *_driver.h - usually contains the driver specific info struct and other structs needed by the driver.  May also contain some macro defines and function definitions shared by the various files in the driver. 
+
+*_video.c or *xv.c - Contains the code to set up and use the video overlay (Xv). 
+
+*_hwmc.c - Contains the code to set up and use the iDCT or motion compensation features with the video overlay (XvMC).  The XvMC user libraries live in xorg/lib/libXvMC. 
+
+*_accel.c - Contains the 2D acceleration code. 
+
+*_shadow.c - Contains functions to support the shadow framebuffer if the driver supports it. 
+
+*_i2c.c - Contains driver specific code for accessing the i2c bus on the card/chip.  It's usually used for DDC2. 
+
+*_dga.c - Contains code to support DGA, an old feature that lets apps write driectly to the framebuffer.  It's rarely used nowadays. 
+
+*_cursor.c - Contains code to enable the hardware cursor. 
+
+*_dri.c - Contains server side code to set up the DRI. 
+
+*_sarea.h - Contains defines needed for the SAREA (shared memory area). 
+
+
+### 3D driver
+
+The 3D driver source is found here: mesa/src/drv/ 
+
+*_3d_reg.h or *_reg.h - 3D register and macro defines. 
+
+*_tex.[ch] - Contains texture code. 
+
+*_xmesa.c or *_screen.[ch] and *_context.[ch] - These deal with screen and context management. The xmesa name is historical. There used to be a number of callbacks whose names started with XMesa. They were called directly by Mesa. The interface has changed in Mesa 4.0. Now there is an API record that specifies these driver entry points. In some drivers (radeon, r200, r128) these functions are in *_screen.[ch] and *_context.[ch]. 
+
+*_span.[ch] - Access to spans of the frame buffer, used for software rasterization fallbacks. 
+
+*_tris.[ch] - It draws all primitives using some templates in mesa/tnl_dd. All primitives are mapped to the ones supported directly by the hardware. At the highest level whole Mesa vertex buffers are rendered. 
+
+It is not the most efficient way of rendering because all strips and fans are decomposed into individual triangles. So lots of duplicate vertices are emitted to the hardware. At some point we may implement our own render stage that takes advantages of hardware strips and fans. r128 and mga used to have *_fastpath.[ch] files in Mesa 3 that did just that. So did the savage driver. These were not ported to Mesa 4 in any of these drivers. Maybe it's not such a big performance win in practice. 
+
+*_state.[ch] - manage the 3D state in hardware. 
+
+*_dd.[ch] - Some selection of device driver functions. I don't know why they are collected in this file. Maybe a historical leftover. The radeon drivers don't have it anymore. It's pretty short in other drivers. 
+
+*_ioctl.[ch]  - ioctls for use with the DRM. 
+
+*_vb.[ch] - Vertex setup. Determines which components are needed for the current state and generates appropriate hardware vertices from Mesa vertices.  For the D3D-like vertex formats there are templates in mesa/tnl_dd. 
+
+
+### DRM
+
+The linux DRM source is found here: mesa/drm 
+
+[[ToDo|ToDo]] 
diff --git a/DrmMapHandling.mdwn b/DrmMapHandling.mdwn
new file mode 100644
index 0000000..4c06ae9
--- /dev/null
+++ b/DrmMapHandling.mdwn
@@ -0,0 +1,77 @@
+
+This page should describe how "maps" and mmaping are handled in the DRM. 
+
+Maps were originally areas set up by the X Server for DRI clients to mmap into their space, using the DRM to provide the privelege to do so and handling of physical offsets.  Maps have grown since then, and are sometimes areas in the kernel not intended for userland consumption (_DRM_RESTRICTED maps), and ares sometimes set up by the kernel with out the X Server's awareness. 
+
+But originally, the X Server did an addmap of a certain offset, creating a map in its list, and returning the handle.  The handle identified the map for future use by userland, for example for removing the map or mmapping it.  The DRM internally maintained an offset, which was not necessarily equal to the handle, for its own use. 
+
+Here's a listing of what handles and offsets are for various mapping types: 
+[[!table header="no" class="mointable" data="""
+ **type**         |    **handle**             |    **offset**  |       **handle** passed to user space 
+ REGISTERS          |  kernel virtual address     |    bus address  |  `offset`
+ FRAMEBUFFER        |  0                          |    bus address  |  `offset`
+ SHM                |  kernel virtual address     |    kernel virtual address  |  `handle`
+ AGP                |  0                          |    bus address  |  `offset`
+ SCATTER_GATHER     |  kernel virtual address     |    kernel virtual address  |  `offset`
+ CONSISTENT         |  kernel virtual address     |    bus address  |  n/a
+"""]]
+
+Typically, the X Server communicates the handle returned from addmap to the client driver through its driver private record (XF86DRI protocol). 
+
+In all of the following cases, the handle value is used as an offset to mmap: 
+
+* The r128 client driver maps the register, gart texture handles. 
+* The radeon client driver maps the register, status, and gart texture handles. 
+* The sis client driver maps the register and agp handles. 
+Separate from maps, but also involved in the process, are bufs, which are used for DMA handling.  At least radeon and r128 use this.  These are set up with the drmAddBufs call in the server, and are either type AGP, SHM, or PCI (= consistent memory).  Client drivers call drmMapBufs on the file descriptor.  drmMapBufs calls into the kernel to get how many buffers there are, what their offsets are, and then actually map them. 
+
+So far map handles are of a machine dependent size. On 32-bit platform they are 32 bit wide while on 64-bit platforms their width is 64 bit. This creates problems on bi-arch architectures that can both run 32 and 64 bit binaries: 
+
+   1. The driver private rec that's passed between the Xserver and the DRI client has a machine dependent size making it impossible to pass data between different machine size binaries (64-bit Xserver and 32-bit DRI client for example). 
+   1. 64-bit handle that does not fit into 32-bit cannot be used as offset in a 32-bit binary (unless the code is compiled with -D_FILE_OFFSET_BITS=64). 
+From the table above we can see the following: `handle` contains either the kernel virtual address or 0 while `offset` contains either the kernel virtual address or the bus base. Furthermore the kernel virtual address is meaningless in user space. The `offset` value of the drm_handle_t structure is not read back to user space. Instead `handle` contains the value of `offset` which is used to identify the map from user space. We could therefore use `handle` to pass a 32-bit value back to user space. If we assume that bus base addresses always fit into 32-bit. This can be done by: 
+
+      1. finding a value range that is guranteed to never conflict with bus base addresses and storing the result in `offset` instead of the kernel virtual address or 
+      1. adding another element to the drm_map_t struct that uniquly identifies the map and passing this back to user space. We can pass the bus base to user space if feasable (ie. it fits in 32 bit and the value has not been used to identify another range). This would require creating a new struct for in kernel use, so that nothing changes for user space.   
+ This can be done by changing the name of every occurance of drm_map_t (except where copying from and to user space) or by using a different name for the drm_map_t in the kernel. The latter will produce a smaller patch, the former may be less confusing. 
+Inside of the DRM, the [[MapBufs|MapBufs]] ioctl does an mmap on behalf of the client, using the offset from the "agp_buffer_map," which is set by the driver to be the map that its buffers come from -- added as above as type AGP or SCATTER_GATHER or CONSISTENT. 
+
+Now, in the mmap handler, the map to mmap from is decided using the _offset_ of the map, not the handle.  This makes [[MapBufs|MapBufs]] work, and SHM, but I don't see how the register mmaping actually functions, since the kernel virtual address is going to be different from the bus address.  And, in the framebuffer case, passing 0 in for the handle seems like it's going to trigger the "drm_mmap_dma" case and fail.  So I'm clearly missing something. 
+
+Actually I don't see how the SHM case will work either: 
+
+In `drm_mmap()` `int drm_mmap(struct file *filp, struct vm_area_struct *vma)` does: 
+[[!format txt """
+                off = dev->driver->get_map_ofs(map);
+                if (off == VM_OFFSET(vma))
+                        break;
+"""]]
+to find the map region that should be mapped. 
+
+In the case of DRM_SHM `drm_addmap()` executes the following code: 
+[[!format txt """
+ #ifdef CONFIG_COMPAT
+        /* Assign a 32-bit handle for _DRM_SHM mappings */
+        /* We do it here so that dev->struct_sem protects the increment */
+        if (map->type == _DRM_SHM)
+                map->offset = map32_handle += PAGE_SIZE;
+#endif
+"""]]
+Therefore `map->offset` isn't a real virtual address any more but more or less a 'tag' identifying the map. 
+
+After identifying the correct map drm_mmap() goes on doing: 
+[[!format txt """
+                offset = dev->driver->get_reg_ofs(dev);
+#ifdef __sparc__
+                if (io_remap_page_range(DRM_RPR_ARG(vma) vma->vm_start,
+                                        VM_OFFSET(vma) + offset,
+                                        vma->vm_end - vma->vm_start,
+                                        vma->vm_page_prot, 0))
+#else
+                if (remap_pfn_range(vma, vma->vm_start,
+                                     (VM_OFFSET(vma) + offset) >> PAGE_SHIFT,
+                                     vma->vm_end - vma->vm_start,
+                                     vma->vm_page_prot))
+#endif
+"""]]
+This doesn't seem to work as `offset` is just a tag, not a virtual address. 
diff --git a/DrmMapHandling.moin b/DrmMapHandling.moin
deleted file mode 100644
index 76178d9..0000000
--- a/DrmMapHandling.moin
+++ /dev/null
@@ -1,77 +0,0 @@
-This page should describe how "maps" and mmaping are handled in the DRM.
-
-Maps were originally areas set up by the X Server for DRI clients to mmap into their space, using the DRM to provide the privelege to do so and handling of physical offsets.  Maps have grown since then, and are sometimes areas in the kernel not intended for userland consumption (_DRM_RESTRICTED maps), and ares sometimes set up by the kernel with out the X Server's awareness.
-
-But originally, the X Server did an addmap of a certain offset, creating a map in its list, and returning the handle.  The handle identified the map for future use by userland, for example for removing the map or mmapping it.  The DRM internally maintained an offset, which was not necessarily equal to the handle, for its own use.
-
-Here's a listing of what handles and offsets are for various mapping types:
-||<bgcolor='#E0E0FF'> '''type'''	||<bgcolor='#FFFFE0'>	'''handle'''		||<bgcolor='#E0E0FF'>	'''offset''' ||<bgcolor='#FFFFE0'>	'''handle''' passed to user space ||
-||<bgcolor='#E0E0FF'> REGISTERS		||<bgcolor='#FFFFE0'> kernel virtual address	||<bgcolor='#E0E0FF'> 	bus address ||<bgcolor='#FFFFE0'> {{{offset}}}||
-||<bgcolor='#E0E0FF'> FRAMEBUFFER	||<bgcolor='#FFFFE0'> 0				||<bgcolor='#E0E0FF'> 	bus address ||<bgcolor='#FFFFE0'> {{{offset}}}||
-||<bgcolor='#E0E0FF'> SHM		||<bgcolor='#FFFFE0'> kernel virtual address	||<bgcolor='#E0E0FF'> 	kernel virtual address ||<bgcolor='#FFFFE0'> {{{handle}}}||
-||<bgcolor='#E0E0FF'> AGP		||<bgcolor='#FFFFE0'> 0				||<bgcolor='#E0E0FF'> 	bus address ||<bgcolor='#FFFFE0'> {{{offset}}}||
-||<bgcolor='#E0E0FF'> SCATTER_GATHER	||<bgcolor='#FFFFE0'> kernel virtual address	||<bgcolor='#E0E0FF'> 	kernel virtual address ||<bgcolor='#FFFFE0'> {{{offset}}}||
-||<bgcolor='#E0E0FF'> CONSISTENT	||<bgcolor='#FFFFE0'> kernel virtual address	||<bgcolor='#E0E0FF'> 	bus address ||<bgcolor='#FFFFE0'> n/a||
-
-Typically, the X Server communicates the handle returned from addmap to the client driver through its driver private record (XF86DRI protocol).
-
-In all of the following cases, the handle value is used as an offset to mmap:
- * The r128 client driver maps the register, gart texture handles.
- * The radeon client driver maps the register, status, and gart texture handles.
- * The sis client driver maps the register and agp handles.
-
-Separate from maps, but also involved in the process, are bufs, which are used for DMA handling.  At least radeon and r128 use this.  These are set up with the drmAddBufs call in the server, and are either type AGP, SHM, or PCI (= consistent memory).  Client drivers call drmMapBufs on the file descriptor.  drmMapBufs calls into the kernel to get how many buffers there are, what their offsets are, and then actually map them.
-
-So far map handles are of a machine dependent size. On 32-bit platform they are 32 bit wide while on 64-bit platforms their width is 64 bit. This creates problems on bi-arch architectures that can both run 32 and 64 bit binaries:
-  1. The driver private rec that's passed between the Xserver and the DRI client has a machine dependent size making it impossible to pass data between different machine size binaries (64-bit Xserver and 32-bit DRI client for example).
-  1. 64-bit handle that does not fit into 32-bit cannot be used as offset in a 32-bit binary (unless the code is compiled with -D_FILE_OFFSET_BITS=64).
-
-From the table above we can see the following:
-{{{handle}}} contains either the kernel virtual address or 0 while {{{offset}}} contains either the kernel virtual address or the bus base.
-Furthermore the kernel virtual address is meaningless in user space. The {{{offset}}} value of the drm_handle_t structure is not read back to user space. Instead {{{handle}}} contains the value of {{{offset}}} which is used to identify the map from user space.
-We could therefore use {{{handle}}} to pass a 32-bit value back to user space.
-If we assume that bus base addresses always fit into 32-bit. This can be done by:
-   a. finding a value range that is guranteed to never conflict with bus base addresses and storing the result in {{{offset}}} instead of the kernel virtual address or
-   a. adding another element to the drm_map_t struct that uniquly identifies the map and passing this back to user space. We can pass the bus base to user space if feasable (ie. it fits in 32 bit and the value has not been used to identify another range). This would require creating a new struct for in kernel use, so that nothing changes for user space. <<BR>> This can be done by changing the name of every occurance of drm_map_t (except where copying from and to user space) or by using a different name for the drm_map_t in the kernel. The latter will produce a smaller patch, the former may be less confusing.
-
-Inside of the DRM, the MapBufs ioctl does an mmap on behalf of the client, using the offset from the "agp_buffer_map," which is set by the driver to be the map that its buffers come from -- added as above as type AGP or SCATTER_GATHER or CONSISTENT.
-
-Now, in the mmap handler, the map to mmap from is decided using the ''offset'' of the map, not the handle.  This makes MapBufs work, and SHM, but I don't see how the register mmaping actually functions, since the kernel virtual address is going to be different from the bus address.  And, in the framebuffer case, passing 0 in for the handle seems like it's going to trigger the "drm_mmap_dma" case and fail.  So I'm clearly missing something.
-
-Actually I don't see how the SHM case will work either:
-
-In {{{drm_mmap()}}} {{{int drm_mmap(struct file *filp, struct vm_area_struct *vma)}}} does:
-{{{
-                off = dev->driver->get_map_ofs(map);
-                if (off == VM_OFFSET(vma))
-                        break;
-}}}
-to find the map region that should be mapped.
-
-In the case of DRM_SHM {{{drm_addmap()}}} executes the following code:
-{{{
- #ifdef CONFIG_COMPAT
-        /* Assign a 32-bit handle for _DRM_SHM mappings */
-        /* We do it here so that dev->struct_sem protects the increment */
-        if (map->type == _DRM_SHM)
-                map->offset = map32_handle += PAGE_SIZE;
-#endif
-}}}
-Therefore {{{map->offset}}} isn't a real virtual address any more but more or less a 'tag' identifying the map.
-
-After identifying the correct map drm_mmap() goes on doing:
-{{{
-                offset = dev->driver->get_reg_ofs(dev);
-#ifdef __sparc__
-                if (io_remap_page_range(DRM_RPR_ARG(vma) vma->vm_start,
-                                        VM_OFFSET(vma) + offset,
-                                        vma->vm_end - vma->vm_start,
-                                        vma->vm_page_prot, 0))
-#else
-                if (remap_pfn_range(vma, vma->vm_start,
-                                     (VM_OFFSET(vma) + offset) >> PAGE_SHIFT,
-                                     vma->vm_end - vma->vm_start,
-                                     vma->vm_page_prot))
-#endif
-}}}
-This doesn't seem to work as {{{offset}}} is just a tag, not a virtual address.
diff --git a/DrmModesetting.mdwn b/DrmModesetting.mdwn
new file mode 100644
index 0000000..463d387
--- /dev/null
+++ b/DrmModesetting.mdwn
@@ -0,0 +1,116 @@
+
+
+# Enhancing kernel graphics
+
+
+## Overview
+
+Current Linux systems have several design problems in the area of graphics architecture.  In particular, several features are either missing or unnecessarily difficult in the current system: 
+
+   * suspend/resume of graphics state 
+   * output of oops/panic messages while graphical apps are running 
+   * use of graphics devices without X 
+   * overweight VT switch 
+Many of these problems are caused or exacerbated by the fact that several drivers compete for control of graphics devices in Linux systems:  the kernel VGA driver, kernel framebuffer drivers, kernel DRM drivers, userspace X drivers, userspace DRI drivers, and other userspace drivers (e.g. svgalib).  Each of them wants to exclusively "own" the graphics device they correspond to, due to the lack of proper interfaces between the different layers of functionality. 
+
+
+### Suspend and Resume Functionality
+
+Currently, suspend/resume of graphics devices in Linux is woefully incomplete, and doesn't work at all on many Linux systems.  If the system firmware fails to reinitialize graphics devices prior to handing control back to the kernel, your system is very likely to hang on resume, or in the best case, come back up but without graphics support. 
+
+Full suspend/resume logic for graphics devices belongs in the kernel for several reasons: 
+
+   * system graphics should come back as quickly as possible 
+   * platforms may or may not provide reinitialization support 
+   * users may not be running X, and therefore can't rely on their X driver to fully reinitialize their graphics device(s) 
+   * some support for reinitialization is necessary for featureful power management 
+Therefore, the proposed DRM enhancements include full suspend/resume logic at the DRM layer (though this could be moved to a GPU layer shared between FB and DRM drivers). 
+
+
+### Panic and Oops Messages
+
+On current systems, if a graphical application is running in KD_GRAPHICS mode (owning graphics for the selected VT), any kernel output, even if it's critical in nature, will be invisible to the user.  Generally, this means that panics are manifested as unexplained hangs in X sessions, with no easy way of seeing what happened short of rebooting and hoping the message was captured somewhere. 
+
+The enhancements outlined here include a new VT mode (KD_KERNEL_GRAPHICS or similar) that includes support for displaying emergency messages directly on the currently active framebuffer.  So, while still unfortunate, at least the user will know that a panic occurred and may be able to take action to prevent it from happening again. 
+
+
+### Freedom from X
+
+Since the X server comes with fairly featureful drivers for many graphics devices, and the difficulty of developing new drivers is fairly high, developers are faced with either developing their graphical applications for X, using minimally featured FB based applications, or writing their own driver stack. 
+
+Moving graphics device configuration and modesetting into the kernel, as these enhancements do, will allow fairly sophisticated applications to be developed independent of X, and should make it easier to port OpenGL stacks to standalone operation (à la EGL), making even complex 3D applications possible without using X. 
+
+
+### VT switch
+
+Currently, the kernel relies on an external program to restore the graphics state when a VT switch occurs.  This doesn't always work, with similar results to the suspend/resume case:  an apparently hung or unusable machine.  Of course, the kernel can't unconditionally preempt the graphics device to set a new mode, but having modesetting in the kernel will give it a much better chance of coordinating with the DRM command dispatch code to find a good time to set a new mode. 
+
+Need to describe lightweight DRM based VT switch mechanism here. 
+
+
+## Design
+
+There are several aspects to the new design: 
+
+   * DRM internal interface and initialization changes 
+   * External, userspace visible APIs for graphics device management 
+   * New userspace applications for detecting available modes and loading them into the kernel 
+
+### DRM internal changes
+
+Current DRM drivers are mostly initialized by DRM clients in userspace (like X).  In order to fully support the features outlined here, DRM drivers will need to perform full initialization at module load time (which would ideally be at kernel boot time) and include other features, including: 
+
+   * register mapping 
+   * irq registration 
+   * setup initial device state (e.g. setup ring buffers, enable device, etc.) 
+   * detect outputs 
+   * initial configuration setup (either storing current configuration into an "initial mode" structure, or setting an initial mode, depending on platform) 
+   * suspend/resume hooks 
+
+### External APIs
+
+The new system provides graphics device configuration and modesetting APIs: 
+
+   * Configuration and output management 
+   * Modesetting on a per-output basis 
+
+#### Configuration and Output Management
+
+The enhancements here include a new set of device nodes for graphics device management: 
+
+   * /dev/dri/0c - for listing outputs, crtcs, and binding them together 
+   * /dev/dri/0[x] - corresponding to each crtc configured with outputs, allows fine grained sharing and per-session control 
+
+#### Per-output Modesetting
+
+   * DRM_IOCTL_MODE_GETRESOURCES - get number of CRTCs, FBs 
+   * DRM_IOCTL_MODE_GETCRTC - get info about a given CRTC 
+   * DRM_IOCTL_MODE_GETOUTPUT - get info about a given output 
+   * DRM_IOCTL_MODE_SETCRTC - set CRTC parameters 
+   * DRM_IOCTL_MODE_ADDFB - add a new FB object 
+   * DRM_IOCTL_MODE_RMFB - remove an FB object 
+   * DRM_IOCTL_MODE_GETFB - get info about an FB object 
+These ioctls would typically be done against the /dev/drm node, which would create new /dev/drmN nodes for applications to attach to. 
+
+
+## Development
+
+Development is ongoing in the master branch of git://git.freedesktop.org/git/mesa/drm and various [[kernel git|http://git.kernel.org/]] trees. 
+
+Short Term TODO items: (things to do to replace current Intel DDX with a kernel one) 
+
+   * expose output properties (sysfs later on) 
+   * finish edid parsing and monitor support 
+   * implement DRM control/slave device node scheme 
+   * re-do ioctl commands against control/slave device node scheme 
+   * Finish intel driver hardware support 
+Long Term TODO items: 
+
+   * port other drivers (e.g. radeon, nouveau) to the tree 
+   * create mode verification and loading application (including CVT and GTF mode generation) for fixing up broken EDID data 
+   * add hotplug support (some devices can generate interrupts on monitor plug/unplug) 
+   * expose output controls (e.g. DPMS, display brightness) somehow, maybe via existing DRM param interface or new ioctl 
+   * add more advanced power management to drivers 
+   * add sysfs interface for interesting information (e.g. crtc->output configuration, available modes, etc.) 
+   * port existing apps to the new interfaces (starting with X drivers) 
+   * share more with FB layer (factor out common code into GPU layer) (?) 
+\ No newline at end of file
diff --git a/DrmModesetting.moin b/DrmModesetting.moin
deleted file mode 100644
index 4194844..0000000
--- a/DrmModesetting.moin
+++ /dev/null
@@ -1,101 +0,0 @@
-= Enhancing kernel graphics =
-
-== Overview ==
-
-Current Linux systems have several design problems in the area of graphics architecture.  In particular, several features are either missing or unnecessarily difficult in the current system:
-  * suspend/resume of graphics state
-  * output of oops/panic messages while graphical apps are running
-  * use of graphics devices without X
-  * overweight VT switch
-Many of these problems are caused or exacerbated by the fact that several drivers compete for control of graphics devices in Linux systems:  the kernel VGA driver, kernel framebuffer drivers, kernel DRM drivers, userspace X drivers, userspace DRI drivers, and other userspace drivers (e.g. svgalib).  Each of them wants to exclusively "own" the graphics device they correspond to, due to the lack of proper interfaces between the different layers of functionality.
-
-=== Suspend and Resume Functionality ===
-
-Currently, suspend/resume of graphics devices in Linux is woefully incomplete, and doesn't work at all on many Linux systems.  If the system firmware fails to reinitialize graphics devices prior to handing control back to the kernel, your system is very likely to hang on resume, or in the best case, come back up but without graphics support.
-
-Full suspend/resume logic for graphics devices belongs in the kernel for several reasons:
-  * system graphics should come back as quickly as possible
-  * platforms may or may not provide reinitialization support
-  * users may not be running X, and therefore can't rely on their X driver to fully reinitialize their graphics device(s)
-  * some support for reinitialization is necessary for featureful power management
-Therefore, the proposed DRM enhancements include full suspend/resume logic at the DRM layer (though this could be moved to a GPU layer shared between FB and DRM drivers).
-
-=== Panic and Oops Messages ===
-
-On current systems, if a graphical application is running in KD_GRAPHICS mode (owning graphics for the selected VT), any kernel output, even if it's critical in nature, will be invisible to the user.  Generally, this means that panics are manifested as unexplained hangs in X sessions, with no easy way of seeing what happened short of rebooting and hoping the message was captured somewhere.
-
-The enhancements outlined here include a new VT mode (KD_KERNEL_GRAPHICS or similar) that includes support for displaying emergency messages directly on the currently active framebuffer.  So, while still unfortunate, at least the user will know that a panic occurred and may be able to take action to prevent it from happening again.
-
-=== Freedom from X ===
-
-Since the X server comes with fairly featureful drivers for many graphics devices, and the difficulty of developing new drivers is fairly high, developers are faced with either developing their graphical applications for X, using minimally featured FB based applications, or writing their own driver stack.
-
-Moving graphics device configuration and modesetting into the kernel, as these enhancements do, will allow fairly sophisticated applications to be developed independent of X, and should make it easier to port OpenGL stacks to standalone operation (à la EGL), making even complex 3D applications possible without using X.
-
-=== VT switch ===
-
-Currently, the kernel relies on an external program to restore the graphics state when a VT switch occurs.  This doesn't always work, with similar results to the suspend/resume case:  an apparently hung or unusable machine.  Of course, the kernel can't unconditionally preempt the graphics device to set a new mode, but having modesetting in the kernel will give it a much better chance of coordinating with the DRM command dispatch code to find a good time to set a new mode.
-
-Need to describe lightweight DRM based VT switch mechanism here.
-
-== Design ==
-
-There are several aspects to the new design:
-  * DRM internal interface and initialization changes
-  * External, userspace visible APIs for graphics device management
-  * New userspace applications for detecting available modes and loading them into the kernel
-
-=== DRM internal changes ===
-
-Current DRM drivers are mostly initialized by DRM clients in userspace (like X).  In order to fully support the features outlined here, DRM drivers will need to perform full initialization at module load time (which would ideally be at kernel boot time) and include other features, including:
-  * register mapping
-  * irq registration
-  * setup initial device state (e.g. setup ring buffers, enable device, etc.)
-  * detect outputs
-  * initial configuration setup (either storing current configuration into an "initial mode" structure, or setting an initial mode, depending on platform)
-  * suspend/resume hooks
-
-=== External APIs ===
-
-The new system provides graphics device configuration and modesetting APIs:
-  * Configuration and output management
-  * Modesetting on a per-output basis
-
-==== Configuration and Output Management ====
-
-The enhancements here include a new set of device nodes for graphics device management:
-  * /dev/dri/0c - for listing outputs, crtcs, and binding them together
-  * /dev/dri/0[x] - corresponding to each crtc configured with outputs, allows fine grained sharing and per-session control
-
-==== Per-output Modesetting ====
-
-  * DRM_IOCTL_MODE_GETRESOURCES - get number of CRTCs, FBs
-  * DRM_IOCTL_MODE_GETCRTC - get info about a given CRTC
-  * DRM_IOCTL_MODE_GETOUTPUT - get info about a given output
-  * DRM_IOCTL_MODE_SETCRTC - set CRTC parameters
-  * DRM_IOCTL_MODE_ADDFB - add a new FB object
-  * DRM_IOCTL_MODE_RMFB - remove an FB object
-  * DRM_IOCTL_MODE_GETFB - get info about an FB object
-
-These ioctls would typically be done against the /dev/drm node, which would create new /dev/drmN nodes for applications to attach to.
-
-== Development ==
-
-Development is ongoing in the master branch of git://git.freedesktop.org/git/mesa/drm and various [[ http://git.kernel.org/| kernel git]] trees.
-
-Short Term TODO items: (things to do to replace current Intel DDX with a kernel one)
-  * expose output properties (sysfs later on)
-  * finish edid parsing and monitor support
-  * implement DRM control/slave device node scheme
-  * re-do ioctl commands against control/slave device node scheme
-  * Finish intel driver hardware support
-
-Long Term TODO items:
-  * port other drivers (e.g. radeon, nouveau) to the tree
-  * create mode verification and loading application (including CVT and GTF mode generation) for fixing up broken EDID data
-  * add hotplug support (some devices can generate interrupts on monitor plug/unplug)
-  * expose output controls (e.g. DPMS, display brightness) somehow, maybe via existing DRM param interface or new ioctl
-  * add more advanced power management to drivers
-  * add sysfs interface for interesting information (e.g. crtc->output configuration, available modes, etc.)
-  * port existing apps to the new interfaces (starting with X drivers)
-  * share more with FB layer (factor out common code into GPU layer) (?)
diff --git a/EditGroup.mdwn b/EditGroup.mdwn
new file mode 100644
index 0000000..19b9515
--- /dev/null
+++ b/EditGroup.mdwn
@@ -0,0 +1,18 @@
+
+List of people who can edit stuff on this wiki 
+
+* [[TollefFogHeen|TollefFogHeen]] 
+* [[EricAnholt|EricAnholt]] 
+* [[KennethGraunke|KennethGraunke]] 
+* [[PaulBerry|PaulBerry]] 
+* [[ChadVersace|ChadVersace]] 
+* [[IanRomanick|IanRomanick]] 
+* [[AdamRak|AdamRak]] 
+* danm 
+* [[AlexDeucher|AlexDeucher]] 
+* [[TomStellard|TomStellard]] 
+* [[MarekOlsak|MarekOlsak]] 
+* [[MichelDaenzer|MichelDaenzer]] 
+* [[AndreasBoll|AndreasBoll]] 
+* [[PaulWise|PaulWise]] 
+* [[JohannesObermayr|JohannesObermayr]] 
+\ No newline at end of file
diff --git a/EditGroup.moin b/EditGroup.moin
deleted file mode 100644
index ae224a9..0000000
--- a/EditGroup.moin
+++ /dev/null
@@ -1,19 +0,0 @@
-#format wiki
-
-List of people who can edit stuff on this wiki
-
- * TollefFogHeen
- * EricAnholt
- * KennethGraunke
- * PaulBerry
- * ChadVersace
- * IanRomanick
- * AdamRak
- * danm
- * AlexDeucher
- * TomStellard
- * MarekOlsak
- * MichelDaenzer
- * AndreasBoll
- * PaulWise
- * JohannesObermayr
diff --git a/EricAnholt.mdwn b/EricAnholt.mdwn
new file mode 100644
index 0000000..05351b4
--- /dev/null
+++ b/EricAnholt.mdwn
@@ -0,0 +1,27 @@
+
+
+## Eric Anholt
+Email
+: eta at lclark dot edu 
+
+Homepage
+: 
+[[http://people.freebsd.org/~anholt/dri/|http://people.freebsd.org/~anholt/dri/]] 
+
+
+Diary
+: 
+[[http://www.advogato.org/person/anholt/|http://www.advogato.org/person/anholt/]] 
+
+
+Interests
+: 
+      * FreeBSD 
+      * SiS driver 
+
+
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/EricAnholt.moin b/EricAnholt.moin
deleted file mode 100644
index 27a5f7a..0000000
--- a/EricAnholt.moin
+++ /dev/null
@@ -1,14 +0,0 @@
-== Eric Anholt ==
-
- Email:: eta at lclark dot edu
-
- Homepage:: http://people.freebsd.org/~anholt/dri/
-
- Diary:: http://www.advogato.org/person/anholt/
-
- Interests::
-   * FreeBSD
-   * SiS driver
-
-----
-CategoryHomepage
diff --git a/FBDRI.mdwn b/FBDRI.mdwn
new file mode 100644
index 0000000..d376a32
--- /dev/null
+++ b/FBDRI.mdwn
@@ -0,0 +1,21 @@
+
+
+## FBDRI
+
+FBDRI is an easy way to support 3D graphics in the Framebuffer console, yet it is not a new OpenGL implementation written from scratch. 
+
+Rather it reuses the GLX and XF86DRI code with significant modifications to run it independantly of a 2D windowing system. Despite the modifications, the reuse of XF86DRI makes it possible to support 3D in the framebuffer console shortly after any new X windows driver comes out. 
+
+
+### Resources
+
+   * [[FBDRI project homepage|http://fbdri.sourceforge.net/]] 
+
+### See also
+
+   * [[DriWithoutX|DriWithoutX]] 
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/FBDRI.moin b/FBDRI.moin
deleted file mode 100644
index 8c51e09..0000000
--- a/FBDRI.moin
+++ /dev/null
@@ -1,20 +0,0 @@
-== FBDRI ==
-
-FBDRI is an easy way to support 3D graphics in the Framebuffer console, yet it
-is not a new OpenGL implementation written from scratch.
-
-Rather it reuses the GLX and XF86DRI code with significant modifications to run
-it independantly of a 2D windowing system. Despite the modifications, the reuse
-of XF86DRI makes it possible to support 3D in the framebuffer console shortly
-after any new X windows driver comes out.
-
-=== Resources ===
-
-  * [[http://fbdri.sourceforge.net/|FBDRI project homepage]]
-
-=== See also ===
-
-  * [[DriWithoutX]]
-
-----
-CategoryGlossary
diff --git a/FIFO.mdwn b/FIFO.mdwn
new file mode 100644
index 0000000..979a895
--- /dev/null
+++ b/FIFO.mdwn
@@ -0,0 +1,11 @@
+
+
+## First-In, First-Out (FIFO)
+
+Is an approach to handling program work requests from queues so that the oldest request is handled next. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/FIFO.moin b/FIFO.moin
deleted file mode 100644
index a5f1f35..0000000
--- a/FIFO.moin
+++ /dev/null
@@ -1,7 +0,0 @@
-== First-In, First-Out (FIFO) ==
-
-Is an approach to handling program work requests
-from queues so that the oldest request is handled next.
-
-----
-CategoryGlossary
diff --git a/FSAA.mdwn b/FSAA.mdwn
new file mode 100644
index 0000000..ebdac28
--- /dev/null
+++ b/FSAA.mdwn
@@ -0,0 +1,11 @@
+
+
+## Full Screen Anti Aliasing (FSAA)
+
+A technique which oversamples each pixel to achieve a more realistic image. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/FSAA.moin b/FSAA.moin
deleted file mode 100644
index 2c4fb85..0000000
--- a/FSAA.moin
+++ /dev/null
@@ -1,7 +0,0 @@
-== Full Screen Anti Aliasing (FSAA) ==
-
-A technique which oversamples each pixel to
-achieve a more realistic image.
-
-----
-CategoryGlossary
diff --git a/FeatureMatrix.mdwn b/FeatureMatrix.mdwn
new file mode 100644
index 0000000..cc7987f
--- /dev/null
+++ b/FeatureMatrix.mdwn
@@ -0,0 +1,45 @@
+
+
+# Summary of DRI Driver Features
+[[!table header="no" class="mointable" data="""
+ Vendor  |  ATI |||| |  Intel ||| |  Matrox  |  3dfx || |  3DLabs  |  Sun  |  S3 ||| |  SiS || |  Trident  |  Via 
+ Chip    |  R200  |  R100  |  Rage128  |  Mach64 |  i810  |  i830  |  i915  |  G200/400/450/550  |  Voodoo3  |  Voodoo5  |  Gamma   |  FFB  |  Savage3D  |  Savage4  |  Virge  |  300/630/730  |  6326  |  Trident  |  Via 
+ Hardware Stencil  |  @32bpp  |  @32bpp  |  @32bpp  |  no  |  no  |  @32bpp  |  @32bpp  |  @32bpp  |  no  |  @32bpp  |  no  |  (bpp?)  |  @32bpp  |  @32bpp  |  X  |  (bpp?)  |  X  |  no  |  X 
+ Hardware Alpha Channel  |  @32bpp  |  @32bpp  |  no  |  no  |  no  |  @32bpp  |  X  |  @32bpp  |  no  |  @32bpp  |  @32bpp  |  @32bpp  |  X  |  X  |  X  |  @32bpp  |  X  |  no  |  X 
+ Hardware TCL  |  YES  |  YES  |  no  |  no  |  no  |  no  |  X  |  no  |  no  |  no  |  YES  |  no  |  no  |  no  |  no  |  no  |  no  |  no  |  X 
+ ARB_multitexture (units)  |  YES (2?)  |  YES (2?)  |  YES (2)  |  YES (2)  |  YES (2)  |  YES (2)  |  X  |  YES (G200:1, G400+:2)  |  YES (2)  |  YES (2)  |  no  |  no  |  no  |  YES (2)  |  no  |  no  |  no  |  no  |  X 
+ ARB/SGIS_texture_border_clamp  |  YES  |  YES  |  no  |  no  |  no  |  YES  |  X  |  no  |  no  |  no  |  no  |  no  |  X  |  X  |   no  |  no  |  X  |  no  |  X 
+ ARB_texture_cube_map  |  YES*  |  no  |  no  |  no  |  no  |  no  |  X  |  no  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ ARB/EXT_texture_env_add  |  YES  |  YES  |  YES  |  no  |  YES  |  YES  |  X  |  YES (G400+)  |  YES  |  YES  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ ARB/EXT_texture_env_dot3  |  YES  |  YES  |  no  |  no  |  no  |  YES  |  X  |  no  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ ARB/EXT_texture_env_combine  |  YES  |  YES  |  no  |  no  |  no  |  YES  |  X  |  no  |  no  |  YES  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ ARB_texture_mirrored_repeat  |  YES  |  YES  |  YES  |  no  |  YES  |  YES  |  X  |  no  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ ATI_texture_env_combine3  |  YES  |  YES  |  no  |  no  |  no  |  no  |  X  |  no  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ ATI_texture_mirror_once  |  YES  |  YES  |  no  |  no  |  no  |  no  |  X  |  no  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ EXT_blend_color  |  YES  |  YES (sw)  |  YES (sw)  |  YES (sw)  |  YES (sw)  |  YES  |  X  |  no  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ EXT_blend_func_separate  |  no  |  no  |  no  |  no  |  no  |  YES  |  X  |  no  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ EXT_blend_logic_op  |  YES  |  YES  |  no  |  no  |  no  |  no  |  X  |  no  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ EXT_blend_minmax  |  YES  |  YES (sw)  |  YES (sw)  |  YES (sw)  |  YES (sw)  |  YES  |  X  |  no  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ EXT_blend_subtract  |  YES  |  YES  |  YES (sw)  |  YES (sw)  |  YES (sw)  |  YES  |  X  |  no  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ EXT_fog_coord  |  no  |  no  |  no  |  no  |  no  |  YES  |  X  |  YES  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ EXT_paletted_texture  |  no  |  no  |  no  |  no  |  no  |  no  |  X  |  no  |  YES  |  YES  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ EXT_secondary_color  |  YES  |  YES  |  no  |  no  |  no  |  YES  |  X  |  YES  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ EXT_shared_texture_palette  |  no  |  no  |  no  |  no  |  no  |  no  |  X  |  no  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ EXT_stencil_wrap  |  YES  |  no  |  no  |  no  |  YES (sw)  |  YES  |  X  |  YES  |  no  |  YES  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ EXT/SGIS_texture_edge_clamp  |  YES  |  YES  |  YES  |  YES  |  YES  |  YES  |  X  |  YES (G400+)  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ EXT_texture_filter_anisotropic  |  YES  |  YES  |  no  |  no  |  no  |  YES  |  X  |  no  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ EXT_texture_lod_bias  |  YES  |  YES  |  no  |  no  |  YES  |  YES  |  X  |  no  |  YES  |  YES  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ MESA_pack_invert  |  YES  |  no  |  no  |  no  |  no  |  no  |  X  |  no  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ MESA_ycbcr_texture  |  YES  |  YES  |  YES  |  YES  |  YES  |  YES  |  X  |  YES  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ NV_blend_square  |  YES  |  YES  |  no  |  no  |  no  |  no  |  X  |  no  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ NV_texture_rectangle  |  YES  |  YES  |  no  |  no  |  YES  |  YES  |  X  |  no  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ SGIS_generate_mipmap  |  YES  |  YES  |  YES  |  YES  |  YES  |  YES  |  X  |  YES  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ GLX_MESA_swap_control  |  YES  |  YES  |  YES  |  YES  |  no  |  no  |  X  |  YES  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ GLX_MESA_swap_frame_usage  |  YES  |  YES  |  no  |  no  |  no  |  no  |  X  |  YES  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ GLX_NV_vertex_array_range  |  YES  |  no  |  no  |  no  |  no  |  no  |  X  |  no  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+ GLX_SGI_video_sync  |  YES  |  YES  |  YES  |  YES  |  no  |  no  |  X  |  YES  |  no  |  no  |  no  |  no  |  X  |  X  |  no  |  no  |  X  |  no  |  X 
+"""]]
+
+Legend: 
+
+X - Status unknown. 
diff --git a/FeatureMatrix.moin b/FeatureMatrix.moin
deleted file mode 100644
index fb282b1..0000000
--- a/FeatureMatrix.moin
+++ /dev/null
@@ -1,42 +0,0 @@
-= Summary of DRI Driver Features =
-
-|| Vendor ||<-4> ATI ||<-3> Intel || Matrox ||<-2> 3dfx || 3DLabs || Sun ||<-3> S3 ||<-2> SiS || Trident || Via ||
-|| Chip   || R200 || R100 || Rage128 || Mach64|| i810 || i830 || i915 || G200/400/450/550 || Voodoo3 || Voodoo5 || Gamma  || FFB || Savage3D || Savage4 || Virge || 300/630/730 || 6326 || Trident || Via ||
-|| Hardware Stencil || @32bpp || @32bpp || @32bpp || no || no || @32bpp || @32bpp || @32bpp || no || @32bpp || no || (bpp?) || @32bpp || @32bpp || X || (bpp?) || X || no || X ||
-|| Hardware Alpha Channel || @32bpp || @32bpp || no || no || no || @32bpp || X || @32bpp || no || @32bpp || @32bpp || @32bpp || X || X || X || @32bpp || X || no || X ||
-|| Hardware TCL || YES || YES || no || no || no || no || X || no || no || no || YES || no || no || no || no || no || no || no || X ||
-|| ARB_multitexture (units) || YES (2?) || YES (2?) || YES (2) || YES (2) || YES (2) || YES (2) || X || YES (G200:1, G400+:2) || YES (2) || YES (2) || no || no || no || YES (2) || no || no || no || no || X ||
-|| ARB/SGIS_texture_border_clamp || YES || YES || no || no || no || YES || X || no || no || no || no || no || X || X ||  no || no || X || no || X ||
-|| ARB_texture_cube_map || YES* || no || no || no || no || no || X || no || no || no || no || no || X || X || no || no || X || no || X ||
-|| ARB/EXT_texture_env_add || YES || YES || YES || no || YES || YES || X || YES (G400+) || YES || YES || no || no || X || X || no || no || X || no || X ||
-|| ARB/EXT_texture_env_dot3 || YES || YES || no || no || no || YES || X || no || no || no || no || no || X || X || no || no || X || no || X ||
-|| ARB/EXT_texture_env_combine || YES || YES || no || no || no || YES || X || no || no || YES || no || no || X || X || no || no || X || no || X ||
-|| ARB_texture_mirrored_repeat || YES || YES || YES || no || YES || YES || X || no || no || no || no || no || X || X || no || no || X || no || X ||
-|| ATI_texture_env_combine3 || YES || YES || no || no || no || no || X || no || no || no || no || no || X || X || no || no || X || no || X ||
-|| ATI_texture_mirror_once || YES || YES || no || no || no || no || X || no || no || no || no || no || X || X || no || no || X || no || X ||
-|| EXT_blend_color || YES || YES (sw) || YES (sw) || YES (sw) || YES (sw) || YES || X || no || no || no || no || no || X || X || no || no || X || no || X ||
-|| EXT_blend_func_separate || no || no || no || no || no || YES || X || no || no || no || no || no || X || X || no || no || X || no || X ||
-|| EXT_blend_logic_op || YES || YES || no || no || no || no || X || no || no || no || no || no || X || X || no || no || X || no || X ||
-|| EXT_blend_minmax || YES || YES (sw) || YES (sw) || YES (sw) || YES (sw) || YES || X || no || no || no || no || no || X || X || no || no || X || no || X ||
-|| EXT_blend_subtract || YES || YES || YES (sw) || YES (sw) || YES (sw) || YES || X || no || no || no || no || no || X || X || no || no || X || no || X ||
-|| EXT_fog_coord || no || no || no || no || no || YES || X || YES || no || no || no || no || X || X || no || no || X || no || X ||
-|| EXT_paletted_texture || no || no || no || no || no || no || X || no || YES || YES || no || no || X || X || no || no || X || no || X ||
-|| EXT_secondary_color || YES || YES || no || no || no || YES || X || YES || no || no || no || no || X || X || no || no || X || no || X ||
-|| EXT_shared_texture_palette || no || no || no || no || no || no || X || no || no || no || no || no || X || X || no || no || X || no || X ||
-|| EXT_stencil_wrap || YES || no || no || no || YES (sw) || YES || X || YES || no || YES || no || no || X || X || no || no || X || no || X ||
-|| EXT/SGIS_texture_edge_clamp || YES || YES || YES || YES || YES || YES || X || YES (G400+) || no || no || no || no || X || X || no || no || X || no || X ||
-|| EXT_texture_filter_anisotropic || YES || YES || no || no || no || YES || X || no || no || no || no || no || X || X || no || no || X || no || X ||
-|| EXT_texture_lod_bias || YES || YES || no || no || YES || YES || X || no || YES || YES || no || no || X || X || no || no || X || no || X ||
-|| MESA_pack_invert || YES || no || no || no || no || no || X || no || no || no || no || no || X || X || no || no || X || no || X ||
-|| MESA_ycbcr_texture || YES || YES || YES || YES || YES || YES || X || YES || no || no || no || no || X || X || no || no || X || no || X ||
-|| NV_blend_square || YES || YES || no || no || no || no || X || no || no || no || no || no || X || X || no || no || X || no || X ||
-|| NV_texture_rectangle || YES || YES || no || no || YES || YES || X || no || no || no || no || no || X || X || no || no || X || no || X ||
-|| SGIS_generate_mipmap || YES || YES || YES || YES || YES || YES || X || YES || no || no || no || no || X || X || no || no || X || no || X ||
-|| GLX_MESA_swap_control || YES || YES || YES || YES || no || no || X || YES || no || no || no || no || X || X || no || no || X || no || X ||
-|| GLX_MESA_swap_frame_usage || YES || YES || no || no || no || no || X || YES || no || no || no || no || X || X || no || no || X || no || X ||
-|| GLX_NV_vertex_array_range || YES || no || no || no || no || no || X || no || no || no || no || no || X || X || no || no || X || no || X ||
-|| GLX_SGI_video_sync || YES || YES || YES || YES || no || no || X || YES || no || no || no || no || X || X || no || no || X || no || X ||
-
-Legend:
-
-X - Status unknown.
diff --git a/FelixKuehling.mdwn b/FelixKuehling.mdwn
new file mode 100644
index 0000000..bad3bda
--- /dev/null
+++ b/FelixKuehling.mdwn
@@ -0,0 +1,25 @@
+
+
+## Felix Kühling
+
+[[!img http://user.cs.tu-berlin.de/~felixyz/images/portrait_85dpi.jpg] 
+Email
+: fxkuehl at gmx dot de 
+
+Homepage
+: 
+[[http://fxk.de.vu|http://fxk.de.vu]] 
+
+
+Interests
+: 
+      * [[ConfigurationInfrastructure|ConfigurationInfrastructure]] 
+      * ATIRadeon 
+      * [[S3Savage|S3Savage]] 
+
+
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/FelixKuehling.moin b/FelixKuehling.moin
deleted file mode 100644
index 36808dd..0000000
--- a/FelixKuehling.moin
+++ /dev/null
@@ -1,15 +0,0 @@
-== Felix Kühling ==
-
-{{http://user.cs.tu-berlin.de/~felixyz/images/portrait_85dpi.jpg}}
-
- Email:: fxkuehl at gmx dot de
-
- Homepage:: http://fxk.de.vu
-
- Interests::
-   * ConfigurationInfrastructure
-   * ATIRadeon
-   * S3Savage
-
-----
-CategoryHomepage
diff --git a/FindPage.moin b/FindPage.moin
deleted file mode 100644
index 3ed82b2..0000000
--- a/FindPage.moin
+++ /dev/null
@@ -1,23 +0,0 @@
-You can use this page to search all entries in this WikiWikiWeb.  Searches are not case sensitive.
-
-Good starting points to explore a wiki are:
- * RecentChanges: see where people are currently working
- * FindPage: search or browse the database in various ways
- * TitleIndex: a list of all pages in the wiki
- * WordIndex: a list of all words that are part of page title (thus, a list of the concepts in a wiki)
- * WikiSandBox: feel free to change this page and experiment with editing
-
-Here's a title search.  Try something like ''manager'':
-
- <<TitleSearch>>
-
-Here's a full-text search.
-
- <<FullSearch>>
-
-You can also use regular expressions, such as
-
-{{{    seriali[sz]e}}}
-
-Or go direct to a page, or create a new page by entering its name here:
- <<GoTo>>
diff --git a/FrankWorsley.mdwn b/FrankWorsley.mdwn
new file mode 100644
index 0000000..9b9d421
--- /dev/null
+++ b/FrankWorsley.mdwn
@@ -0,0 +1,22 @@
+
+
+## Frank Worsley
+Email
+: fworsley at neatstep dot com 
+
+Homepage
+: 
+[[http://frank.neatstep.com|http://frank.neatstep.com]] 
+
+
+Interests
+: 
+      * Linux in general 
+      * [[Gnome|http://www.gnome.org]] 
+
+
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/FrankWorsley.moin b/FrankWorsley.moin
deleted file mode 100644
index 265ed06..0000000
--- a/FrankWorsley.moin
+++ /dev/null
@@ -1,12 +0,0 @@
-== Frank Worsley ==
-
- Email:: fworsley at neatstep dot com
-
- Homepage:: http://frank.neatstep.com
- 
- Interests::
-   * Linux in general
-   * [[http://www.gnome.org|Gnome]]
-
-----
-CategoryHomepage
diff --git a/FreeBSD.mdwn b/FreeBSD.mdwn
new file mode 100644
index 0000000..f262699
--- /dev/null
+++ b/FreeBSD.mdwn
@@ -0,0 +1,21 @@
+
+
+# FreeBSD
+
+FreeBSD is an advanced operating system for x86 compatible, DEC Alpha, IA-64, AMD64, PC-98 and UltraSPARC® architectures. It is derived from BSD, the version of UNIX® developed at the University of California, Berkeley. It is developed and maintained by a large team of individuals. 
+
+
+## Status
+
+The mga, r128, r200, radeon, tdfx, and sis drivers are all supported on FreeBSD.  i810, i830, and gamma drivers aren't yet. 
+
+
+## Resources
+
+* [[The FreeBSD Project|http://www.freebsd.org/]] 
+* [[DRI on FreeBSD|http://people.freebsd.org/~anholt/dri/]] 
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]], [[CategoryOperatingSystem|CategoryOperatingSystem]] 
diff --git a/FreeBSD.moin b/FreeBSD.moin
deleted file mode 100644
index 9223232..0000000
--- a/FreeBSD.moin
+++ /dev/null
@@ -1,15 +0,0 @@
-= FreeBSD =
-
-FreeBSD is an advanced operating system for x86 compatible, DEC Alpha, IA-64, AMD64, PC-98 and UltraSPARC® architectures. It is derived from BSD, the version of UNIX® developed at the University of California, Berkeley. It is developed and maintained by a large team of individuals.
-
-== Status ==
-
-The mga, r128, r200, radeon, tdfx, and sis drivers are all supported on FreeBSD.  i810, i830, and gamma drivers aren't yet.
-
-== Resources ==
-
- * [[http://www.freebsd.org/|The FreeBSD Project]]
- * [[http://people.freebsd.org/~anholt/dri/|DRI on FreeBSD]]
-
-----
-CategoryGlossary, CategoryOperatingSystem
diff --git a/FrontPage.mdwn b/FrontPage.mdwn
new file mode 100644
index 0000000..9f43f32
--- /dev/null
+++ b/FrontPage.mdwn
@@ -0,0 +1,35 @@
+
+
+# Mesa 3D and Direct Rendering Infrastructure wiki
+
+[[Mesa|http://mesa3d.org/]] is an open-source OpenGL implementation, continually updated to support the latest OpenGL specification. 
+
+The Direct Rendering Infrastructure, also known as the DRI, is a framework for allowing direct access to graphics hardware under the X Window System in a safe and efficient manner. It includes changes to the X server, to several client libraries, and to the kernel (DRM, Direct Rendering Manager). The most important use for the DRI is to create fast OpenGL implementations providing hardware acceleration for Mesa. Several 3D accelerated drivers have been written to the DRI specification, including drivers for chipsets produced by 3DFX, AMD (formerly ATI), Intel and Matrox. 
+
+
+## Starting Points
+
+* [[Status|Status]] - status of various drivers 
+* [[Development|Development]] - contributing to development 
+* [[DevelopingForMesa|DevelopingForMesa]] - What to do to test your app on Mesa 
+* [[MailingLists|MailingLists]] - Mesa and DRI mailing lists 
+* [[Download|Download]] - download source code; ordinary users should get DRI with their BSD/Linux distribution 
+* [[Links|Links]] - collection of links related to DRI 
+
+## Documentation
+
+* [[Documentation|Documentation]] - documentation main page 
+* [[DriHistory|DriHistory]] - the DRI project history 
+* [[Mesa 3D|http://mesa3d.org/]] - introduction and technical documents about Mesa 
+* [[CategoryHardware|CategoryHardware]]: hardware specific information 
+* [[CategoryFaq|CategoryFaq]]: frequently asked questions 
+* [[TestingAndDebugging|TestingAndDebugging]]: tips for testing and debugging the drivers 
+* [[DriTroubleshooting|DriTroubleshooting]]: when things go wrong 
+* [[AuthorshipAndAcknowledgements|AuthorshipAndAcknowledgements]] 
+
+### Wiki maintenance
+
+* [[ToDo|ToDo]]: incomplete pages 
+* [[WantedPages|WantedPages]]: wanted/missing pages 
+* [[CategoryCategory|CategoryCategory]]: categories in this Wiki 
+The DRI website and the mailing lists are hosted by [[freedesktop.org|http://freedesktop.org/]]. 
diff --git a/FrontPage.moin b/FrontPage.moin
deleted file mode 100644
index 93c2e12..0000000
--- a/FrontPage.moin
+++ /dev/null
@@ -1,32 +0,0 @@
-#pragma section-numbers off
-= Mesa 3D and Direct Rendering Infrastructure wiki =
-
-[[http://mesa3d.org/|Mesa]] is an open-source OpenGL implementation, continually updated to support the latest OpenGL specification.
-
-The Direct Rendering Infrastructure, also known as the DRI, is a framework for allowing direct access to graphics hardware under the X Window System in a safe and efficient manner. It includes changes to the X server, to several client libraries, and to the kernel (DRM, Direct Rendering Manager). The most important use for the DRI is to create fast OpenGL implementations providing hardware acceleration for Mesa. Several 3D accelerated drivers have been written to the DRI specification, including drivers for chipsets produced by 3DFX, AMD (formerly ATI), Intel and Matrox.
-
-== Starting Points ==
- * [[Status]] - status of various drivers
- * [[Development]] - contributing to development
- * [[DevelopingForMesa]] - What to do to test your app on Mesa
- * [[MailingLists]] - Mesa and DRI mailing lists
- * [[Download]] - download source code; ordinary users should get DRI with their BSD/Linux distribution
- * [[Links]] - collection of links related to DRI
-
-== Documentation ==
-
- * [[Documentation]] - documentation main page
- * [[DriHistory]] - the DRI project history
- * [[http://mesa3d.org/|Mesa 3D]] - introduction and technical documents about Mesa
- * CategoryHardware: hardware specific information
- * CategoryFaq: frequently asked questions
- * TestingAndDebugging: tips for testing and debugging the drivers
- * DriTroubleshooting: when things go wrong
- * AuthorshipAndAcknowledgements
-
-=== Wiki maintenance ===
- * ToDo: incomplete pages
- * WantedPages: wanted/missing pages
- * CategoryCategory: categories in this Wiki
- 
-The DRI website and the mailing lists are hosted by [[http://freedesktop.org/|freedesktop.org]].
diff --git a/FullScreen.mdwn b/FullScreen.mdwn
new file mode 100644
index 0000000..299d39a
--- /dev/null
+++ b/FullScreen.mdwn
@@ -0,0 +1,15 @@
+
+
+### What's the deal with fullscreen and DGA?
+
+The difference between in a window and fullscreen is actually quite minor. When you're in fullscreen mode what you've done is zoomed in your desktop and moved the zoomed portion to cover just the window. (Just the same hitting Ctrl-Alt-plus and Ctrl-Alt-minus) The game still runs in a window in either case. So, the behavior shouldn't be any different. 
+
+DGA is turned off in the current configuration. I've just started adding those features back in. The latest code in the trunk has some support for DGA but is broken, the code in my tdfx-1-1 branch should be working. 
+
+
+
+---
+
+ 
+
+[[CategoryFaq|CategoryFaq]] 
diff --git a/FullScreen.moin b/FullScreen.moin
deleted file mode 100644
index 592def6..0000000
--- a/FullScreen.moin
+++ /dev/null
@@ -1,15 +0,0 @@
-=== What's the deal with fullscreen and DGA? ===
-
-The difference between in a window and fullscreen is actually quite minor. When
-you're in fullscreen mode what you've done is zoomed in your desktop and moved
-the zoomed portion to cover just the window. (Just the same hitting
-Ctrl-Alt-plus and Ctrl-Alt-minus) The game still runs in a window in either
-case. So, the behavior shouldn't be any different.
-
-DGA is turned off in the current configuration. I've just started adding those
-features back in. The latest code in the trunk has some support for DGA but is
-broken, the code in my tdfx-1-1 branch should be working.
-
-----
-
-CategoryFaq
diff --git a/GART.mdwn b/GART.mdwn
new file mode 100644
index 0000000..848c707
--- /dev/null
+++ b/GART.mdwn
@@ -0,0 +1,15 @@
+
+
+# Graphics Address Re-Mapping Table (GART)
+
+The AGP execute model interface specification requires a physical-to-physical address remapping mechanism which ensures that the graphics accelerator (an AGP master) will have a contiguous view of the graphics data structures dynamically allocated in system memory. 
+
+This address remapping is accomplished via a memory-based table called the Graphics Address Remapping Table (GART) -- also sometimes called the Graphics Translation Table (GTT). It is used (walked) by the corelogic to perform the remapping. In order to avoid compatibility issues and allow future implementation flexibility, this mechanism is specified at a software (API) level. In other words, the actual GART table format is not specified; rather it is abstracted to the API by a HAL or miniport driver that must be provided with the corelogic. 
+
+**Note:** This remapping function should not be confused in any way with the system address translation table mechanism. While some of the concepts are similar, these are completely separate mechanisms which operate independently, under control of the operating system. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/GART.moin b/GART.moin
deleted file mode 100644
index c2b7315..0000000
--- a/GART.moin
+++ /dev/null
@@ -1,22 +0,0 @@
-= Graphics Address Re-Mapping Table (GART) =
-
-The AGP execute model interface specification requires a physical-to-physical
-address remapping mechanism which ensures that the graphics accelerator (an AGP
-master) will have a contiguous view of the graphics data structures dynamically
-allocated in system memory.
-
-This address remapping is accomplished via a memory-based table called the
-Graphics Address Remapping Table (GART) -- also sometimes called the Graphics Translation Table (GTT). It is used (walked) by the corelogic to
-perform the remapping. In order to avoid compatibility issues and allow future
-implementation flexibility, this mechanism is specified at a software (API)
-level. In other words, the actual GART table format is not specified; rather it
-is abstracted to the API by a HAL or miniport driver that must be provided with
-the corelogic.
-
-'''Note:''' This remapping function should not be confused in any way with the
-system address translation table mechanism. While some of the concepts are
-similar, these are completely separate mechanisms which operate independently,
-under control of the operating system.
-
-----
-CategoryGlossary
diff --git a/GARTAddressingLimits.mdwn b/GARTAddressingLimits.mdwn
new file mode 100644
index 0000000..70a1a4c
--- /dev/null
+++ b/GARTAddressingLimits.mdwn
@@ -0,0 +1,33 @@
+
+Some GARTs may have addressing limits which can't cover all of the physical addresses which may be available to the CPU.  This is an attempt to categorize chipsets. 
+
+The maximum memory is how much you can slot in.  The memory controller address limit is how much address space the northbridge is decoding.  So, 4 GB of address space with 4 GB slotted in will result in less than 4 GB of RAM available to the OS because a chunk of address space gets reserved for the PCI and miscellaneous apertures.  The GART address limit is how much of the MC address space the GART can map to.  Status is whether we need to worry about GART addressing as a result. 
+[[!table header="no" class="mointable" data="""
+ manufacturer  |  chipset name  |  maximum memory  |  MC address limit  |  GART address limit  |  status 
+ AMD  |  751  |  768MB  |  ??  |  ??  |  good 
+ AMD  |  761  |  2GB  |  ??  |  4GB  |  good 
+ AMD  |  762  |  4GB  |  4GB  |  4GB  |  good 
+ AMD  |  amd64 processor  |  ??  |  ??  |  1024GB  |  good 
+ Intel  |  830M/MG/MP  |  1GB  |   |  4GB  |  good 
+ Intel  |  845G/GL  |  2GB  |   |  4GB  |  good 
+ Intel  |  855GM/GME  |  2GB  |   |  4GB  |  good 
+ Intel  |  865G/GV  |  4GB  |  4GB  |  4GB  |  good
+ Intel  |  915G/GV/GL/P/PL/GL  |  4GB  |  4GB  |  4GB  |  good 
+ Intel  |  915GM  |  2GB  |  4GB  |  4GB  |  good 
+ Intel  |  945GM  |  4GB  |  4GB  |  4GB  |  good 
+ Intel  |  G33  |  8GB  |  64GB  |  64GB  |  good 
+ Intel  |  G35  |  8GB  |  64GB  |  64GB  |  good 
+ Intel  |  G965  |  ??  |  64GB  |  64GB  |  good 
+ SiS  |  630/730  |  1.5GB  |  ??  |  4GB  |  good 
+ VIA  |  PLE133  |  1.5GB  |  ??  |  ??  |  good 
+ VIA  |  [[P4M400|P4M400]]  |  2GB  |  ??  |  ??  |  ?? 
+ VIA  |  KM266  |  4GB  |  ??  |  ??  |  ?? 
+"""]]
+
+Note: VIA's specs webpages don't agree with their product comparisons on maximum memory sizes around the PM800 series. 
+[[!table header="no" class="mointable" data="""
+ manufacturer  |  graphics chipset  |  GART address limit 
+ ATI  |  Rage 128  |  4GB 
+ ATI  |  R100  |  4GB 
+ ATI  |  R200  |  4GB 
+"""]]
diff --git a/GARTAddressingLimits.moin b/GARTAddressingLimits.moin
deleted file mode 100644
index 2507cc3..0000000
--- a/GARTAddressingLimits.moin
+++ /dev/null
@@ -1,30 +0,0 @@
-Some GARTs may have addressing limits which can't cover all of the physical addresses which may be available to the CPU.  This is an attempt to categorize chipsets.
-
-The maximum memory is how much you can slot in.  The memory controller address limit is how much address space the northbridge is decoding.  So, 4 GB of address space with 4 GB slotted in will result in less than 4 GB of RAM available to the OS because a chunk of address space gets reserved for the PCI and miscellaneous apertures.  The GART address limit is how much of the MC address space the GART can map to.  Status is whether we need to worry about GART addressing as a result.
-
-|| manufacturer || chipset name || maximum memory || MC address limit || GART address limit || status ||
-|| AMD || 751 || 768MB || ?? || ?? || good ||
-|| AMD || 761 || 2GB || ?? || 4GB || good ||
-|| AMD || 762 || 4GB || 4GB || 4GB || good ||
-|| AMD || amd64 processor || ?? || ?? || 1024GB || good ||
-|| Intel || 830M/MG/MP || 1GB || || 4GB || good ||
-|| Intel || 845G/GL || 2GB || || 4GB || good ||
-|| Intel || 855GM/GME || 2GB || || 4GB || good ||
-|| Intel || 865G/GV || 4GB || 4GB || 4GB || good||
-|| Intel || 915G/GV/GL/P/PL/GL || 4GB || 4GB || 4GB || good ||
-|| Intel || 915GM || 2GB || 4GB || 4GB || good ||
-|| Intel || 945GM || 4GB || 4GB || 4GB || good ||
-|| Intel || G33 || 8GB || 64GB || 64GB || good ||
-|| Intel || G35 || 8GB || 64GB || 64GB || good ||
-|| Intel || G965 || ?? || 64GB || 64GB || good ||
-|| SiS || 630/730 || 1.5GB || ?? || 4GB || good ||
-|| VIA || PLE133 || 1.5GB || ?? || ?? || good ||
-|| VIA || P4M400 || 2GB || ?? || ?? || ?? ||
-|| VIA || KM266 || 4GB || ?? || ?? || ?? ||
-
-Note: VIA's specs webpages don't agree with their product comparisons on maximum memory sizes around the PM800 series.
-
-|| manufacturer || graphics chipset || GART address limit ||
-|| ATI || Rage 128 || 4GB ||
-|| ATI || R100 || 4GB ||
-|| ATI || R200 || 4GB ||
diff --git a/GLU.mdwn b/GLU.mdwn
new file mode 100644
index 0000000..c5e6662
--- /dev/null
+++ b/GLU.mdwn
@@ -0,0 +1,11 @@
+
+
+## Graphics Library Utilities (GLU)
+
+OpenGL is good but doing some common operations is a regular pain in the proverbial. GLU is a platform independent library that can build spheres, perform collision detection, determine if a point is inside a 3D shape, etc. GLU works on top of OpenGL. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/GLU.moin b/GLU.moin
deleted file mode 100644
index de07127..0000000
--- a/GLU.moin
+++ /dev/null
@@ -1,9 +0,0 @@
-== Graphics Library Utilities (GLU) ==
-
-OpenGL is good but doing some common
-operations is a regular pain in the proverbial. GLU is a platform independent
-library that can build spheres, perform collision detection, determine if a
-point is inside a 3D shape, etc. GLU works on top of OpenGL.
-
-----
-CategoryGlossary
diff --git a/GLUT.mdwn b/GLUT.mdwn
new file mode 100644
index 0000000..9238ae6
--- /dev/null
+++ b/GLUT.mdwn
@@ -0,0 +1,11 @@
+
+
+## Graphics Library Utility Toolkit (GLUT)
+
+OpenGL is platform independent but certain operations (like creating windows, receiving mouse clicks, resizing windows) are done differently over the many platforms supported by OpenGL. GLUT lets you write a single application that will compile and work on Windows, X11, MacOS, etc. GLUT is fairly limited and so it's more useful for simple demonstration programs rather than full blown applications or games. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/GLUT.moin b/GLUT.moin
deleted file mode 100644
index ed8468b..0000000
--- a/GLUT.moin
+++ /dev/null
@@ -1,11 +0,0 @@
-== Graphics Library Utility Toolkit (GLUT) ==
-
-OpenGL is platform independent but
-certain operations (like creating windows, receiving mouse clicks, resizing
-windows) are done differently over the many platforms supported by OpenGL.
-GLUT lets you write a single application that will compile and work on
-Windows, X11, MacOS, etc. GLUT is fairly limited and so it's more useful for
-simple demonstration programs rather than full blown applications or games.
-
-----
-CategoryGlossary
diff --git a/GLX.mdwn b/GLX.mdwn
new file mode 100644
index 0000000..7099bfd
--- /dev/null
+++ b/GLX.mdwn
@@ -0,0 +1,11 @@
+
+
+### GLX
+
+X11 is a networked windowing system. Your client and your server might be on different machines. GLX packages up OpenGL commands into network packets, spits them across the X11 network pipe, then unpacks them at the other end. This lets you run accelerated 3D remotely: the client could be a simulation on a mainframe, the display could be your desktop machine in your office. GLX does a number of other X11 related things that couldn't be packaged into OpenGL. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/GLX.moin b/GLX.moin
deleted file mode 100644
index 8f28f57..0000000
--- a/GLX.moin
+++ /dev/null
@@ -1,12 +0,0 @@
-=== GLX ===
-
-X11 is a networked windowing system. Your client and your server might
-be on different machines. GLX packages up OpenGL commands into network
-packets, spits them across the X11 network pipe, then unpacks them at the
-other end. This lets you run accelerated 3D remotely: the client could be a
-simulation on a mainframe, the display could be your desktop machine in your
-office. GLX does a number of other X11 related things that couldn't be
-packaged into OpenGL.
-
-----
-CategoryGlossary
diff --git a/GLXExtension.mdwn b/GLXExtension.mdwn
new file mode 100644
index 0000000..7835ce9
--- /dev/null
+++ b/GLXExtension.mdwn
@@ -0,0 +1,17 @@
+
+
+### GLX Extension
+
+
+#### What does the XFree86 GLX extension?
+
+The GLX extension to the X server handles the server-side tasks of the GLX protocol. This involves setup of GLX-enhanced visuals, GLX context creation, context binding and context destruction. 
+
+When using indirect rendering, the GLX extension decodes GLX command packets and dispatches them to GLcoreExtension, the core rendering engine. 
+
+
+#### Where does the XFree86 GLX reside?
+
+The GLX extension module usually resides at _/usr/X``11R6/lib/modules/extensions/libglx.a_. 
+
+The GLX extension source code resides at [[xc/programs/Xserver/GL/glx/|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/GL/glx/]] . 
diff --git a/GLXExtension.moin b/GLXExtension.moin
deleted file mode 100644
index f1dfde7..0000000
--- a/GLXExtension.moin
+++ /dev/null
@@ -1,11 +0,0 @@
-=== GLX Extension ===
-==== What does the XFree86 GLX extension? ====
-The GLX extension to the X server handles the server-side tasks of the GLX protocol. This involves setup of GLX-enhanced visuals, GLX context creation, context binding and context destruction.
- 
-When using indirect rendering, the GLX extension decodes GLX command packets and dispatches them to GLcoreExtension, the core rendering engine.
- 
-==== Where does the XFree86 GLX reside? ====
- 
-The GLX extension module usually resides at ''/usr/X``11R6/lib/modules/extensions/libglx.a''.
- 
-The GLX extension source code resides at [[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/GL/glx/|xc/programs/Xserver/GL/glx/]] .
diff --git a/GLcore.moin b/GLcore.mdwn
index b6a1508..3b5f616 100644
--- a/GLcore.moin
+++ b/GLcore.mdwn
@@ -1,3 +1,4 @@
-GLcore is the name given to the part of the X server that renders OpenGL commands for the GLX protocol.  It is implemented as a software-only version of Mesa, and is used when the DDX driver does not support DRI.
-
-As of Xorg 7.2, the X server is also capable of loading DRI drivers to handle indirect GLX rendering.  This is what AIGLX means: accelerated indirect GLX.
+
+GLcore is the name given to the part of the X server that renders OpenGL commands for the GLX protocol.  It is implemented as a software-only version of Mesa, and is used when the DDX driver does not support DRI. 
+
+As of Xorg 7.2, the X server is also capable of loading DRI drivers to handle indirect GLX rendering.  This is what AIGLX means: accelerated indirect GLX. 
diff --git a/GLcoreExtension.moin b/GLcoreExtension.mdwn
index 8008008..7c938a6 100644
--- a/GLcoreExtension.moin
+++ b/GLcoreExtension.mdwn
@@ -1,43 +1,50 @@
-=== GLcore Extension ===
-
-==== What is the GLcore extension? ====
-
-The GLcore module takes care of rendering for indirect or non-local clients.
-
-Currently, Mesa is used as a software renderer. In the future, indirect rendering will also be hardware accelerated.
-
-==== Where does the GLcore extension reside? ====
-
-The GLcore extension module usually resides at ''/usr/X``11R6/lib/modules/extensions/libGLcore.a''.
-
-The GLcore extension source code resides at [[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/GL/mesa/src/|xc/programs/Xserver/GL/mesa/src/]] .
-
-==== If I run a GLX enabled OpenGL program on a remote system with the display set back to my machine, will the X server itself render the GLX requests through DRI? ====
-
-The X server will render the requests but not through the DRI. The rendering will be software only. There are two possible solutions to this; either the X server can spawn a DRI client to handle the GLX protocol stream, or the X server can be a DRI client itself.  Either method would effectively provide accelerated indirect rendering.
-
-==== What's the real difference between local clients and remote clients? ====
-
-There is no difference as far as the client is concerned. The only difference is speed.
-
-The difference between direct and indirect rendering is that the former can't take place over the network. The DRI currently concentrates on the direct rendering case.
-
-The application still gets a fully functional OpenGL implementation which is all that's required by the specification. The fact is that the implementation is entirely in software, but that's completely legal. In fact, all implementations fall back to software when they can't handle the request in hardware. It's just that in this case, the implementation can't handle anything in hardware.
-
-Most people don't run GLX applications remotely, and/because most applications run very poorly when run remotely. It's not really the applications fault, OpenGL pushes around a lot of data.
-
-Therefore there hasn't been a lot of interest in hardware accelerated remote rendering and there's plenty to do local rendering. It is on the TO``DO list but at a low priority.
-
-One solution is actually fairly straight forward. When the X server gets a remote client, it forks off a small application that just reads GLX packets and then remakes the same OpenGL calls. This new application is then just a standard direct rendering client and the problem reduces to one already solved.
-
-==== How would I go about adding support for hardware accelerated indirect rendering? ====
-
-"The goal would be to modify the interface between libglx.a (the part that handles the high-level GLX protocol stuff) and libGLcore.a (the part that does the drawing) to be the same as the interface between libGL and the client-side DRI driver.  Then a "client-side" DRI driver would be loaded instead of libGLcore.a."
-
-  -- IanRomanick
-
-==== Is there a difference between using indirect DRI rendering (e.g., with LIBGL_ALWAYS_INDIRECT) and just linking against the Mesa library? ====
-
-Yes. DRI  ''libGL'' used in in indirect mode sends GLX protocol messages to the X server which are executed by the GLcore renderer. Stand-alone Mesa's non-GLX. It effectively translates OpenGL calls into Xlib calls.
-
-The GLcore renderer is based on Mesa. The GLcore renderer can not take advantage of hardware acceleration.
+
+
+### GLcore Extension
+
+
+#### What is the GLcore extension?
+
+The GLcore module takes care of rendering for indirect or non-local clients. 
+
+Currently, Mesa is used as a software renderer. In the future, indirect rendering will also be hardware accelerated. 
+
+
+#### Where does the GLcore extension reside?
+
+The GLcore extension module usually resides at _/usr/X``11R6/lib/modules/extensions/libGLcore.a_. 
+
+The GLcore extension source code resides at [[xc/programs/Xserver/GL/mesa/src/|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/programs/Xserver/GL/mesa/src/]] . 
+
+
+#### If I run a GLX enabled OpenGL program on a remote system with the display set back to my machine, will the X server itself render the GLX requests through DRI?
+
+The X server will render the requests but not through the DRI. The rendering will be software only. There are two possible solutions to this; either the X server can spawn a DRI client to handle the GLX protocol stream, or the X server can be a DRI client itself.  Either method would effectively provide accelerated indirect rendering. 
+
+
+#### What's the real difference between local clients and remote clients?
+
+There is no difference as far as the client is concerned. The only difference is speed. 
+
+The difference between direct and indirect rendering is that the former can't take place over the network. The DRI currently concentrates on the direct rendering case. 
+
+The application still gets a fully functional OpenGL implementation which is all that's required by the specification. The fact is that the implementation is entirely in software, but that's completely legal. In fact, all implementations fall back to software when they can't handle the request in hardware. It's just that in this case, the implementation can't handle anything in hardware. 
+
+Most people don't run GLX applications remotely, and/because most applications run very poorly when run remotely. It's not really the applications fault, OpenGL pushes around a lot of data. 
+
+Therefore there hasn't been a lot of interest in hardware accelerated remote rendering and there's plenty to do local rendering. It is on the TO``DO list but at a low priority. 
+
+One solution is actually fairly straight forward. When the X server gets a remote client, it forks off a small application that just reads GLX packets and then remakes the same OpenGL calls. This new application is then just a standard direct rendering client and the problem reduces to one already solved. 
+
+
+#### How would I go about adding support for hardware accelerated indirect rendering?
+
+"The goal would be to modify the interface between libglx.a (the part that handles the high-level GLX protocol stuff) and libGLcore.a (the part that does the drawing) to be the same as the interface between libGL and the client-side DRI driver.  Then a "client-side" DRI driver would be loaded instead of libGLcore.a." 
+
+   * -- [[IanRomanick|IanRomanick]] 
+
+#### Is there a difference between using indirect DRI rendering (e.g., with LIBGL_ALWAYS_INDIRECT) and just linking against the Mesa library?
+
+Yes. DRI  _libGL_ used in in indirect mode sends GLX protocol messages to the X server which are executed by the GLcore renderer. Stand-alone Mesa's non-GLX. It effectively translates OpenGL calls into Xlib calls. 
+
+The GLcore renderer is based on Mesa. The GLcore renderer can not take advantage of hardware acceleration. 
diff --git a/GLdispatch.mdwn b/GLdispatch.mdwn
new file mode 100644
index 0000000..77e146f
--- /dev/null
+++ b/GLdispatch.mdwn
@@ -0,0 +1,134 @@
+
+[[!toc ]] 
+
+
+# Background of API dispatch in Mesa
+
+The operation of nearly every function in the OpenGL API depends on the state of the currently bound context.  Even if all state in two context's is identical, the operation can be different between the two contexts.  Consider a couple common examples: 
+
+* One context is created for direct rendering (requiring that function calls be directed into the local driver) and the other context is created for indirect rendering (requiring that function calls be convertex to GLX protocol and sent to the server). 
+* Both contexts are created for direct rendering, but one context is created on screen 0 of the display, which happens to be on a card by manufacturer Foo, and the other context is created on screen 1, which happens to be on a card by manufacturer Bar.  In this function calls are directed to a _different_ local driver for each context. 
+To implement this, Mesa uses something similar to the virtual function table for a C++ class.  Each context has an associated _dispatch table_.  This table contains a function pointer for every function in the API.  When a context is bound with `glXMakeCurrent` (or similar function), a pointer to its dispatch table is stored in a global variable.  When an application calls an API function, such as `glVertex3f`, it is actually calling a generic _dispatch stub_ in Mesa (dispatch stubs that are directly called are also referred to as _static dispatch stubs_).  This dispatch stub fetches a pointer to the currently context's dispatch table, looks up a pointer to the desired function in that table, and, finally, calls the function. 
+
+It is also important to note that, since the current context is set per-thread in a multithreaded application, the dispatch pointer is also stored per-thread. 
+
+The [[Linux OpenGL ABI|http://oss.sgi.com/projects/ogl-sample/ABI/index.html]] requires that certain functions be statically exported by the system libGL.  However, nearly any useful implementation will want to expose more functionality.  Since applications cannot depend on these functions being statically available, another method is needed to access them.  Initially implemented as an [[extension|http://oss.sgi.com/projects/ogl-sample/registry/ARB/get_proc_address.txt]] and later incorporated into [[GLX 1.4|http://www.opengl.org/documentation/spec.html]], `glXGetProcAddressARB` (or `glXGetProcAddress`) is used to get a pointer to a named API function.  GLX requires that pointers returned by `glXGetProcAddressARB` be _context independent_.  This means that calling `glXGetProcAddressARB((const GLubyte *) "glVertex3f")` will return the same value no matter what context is bound [^1]. 
+
+In addition, `glXGetProcAddressARB` can be called when _no_ context is bound.  Since Mesa is capable of loading drivers with unknown functionality, Mesa has no way to know a priori that a requested function, such as `glWillNeverExist`, doesn't exist.  For this reason Mesa's implementation of `glXGetProcAddressARB` will _never_ return `NULL` for a well formed API function name.  Other libGL implementations that only operate with a limited set of known drivers (e.g., Nvidia's closed-source libGL) can know which functions will never exist and may return `NULL`. 
+
+Mesa's implementation of `glXGetProcAddressARB` does two important steps when called with a function name that is currently unknown.  It first assigns an offset in the dispatch table to the new function.  Once the location of the function pointer in the dispatch table is known, Mesa generates a _dynamic dispatch stub_ for the function.  A pointer to this function is returned by `glXGetProcAddressARB`.  The name of the function, the assigned offset, and the dispatch stub pointer are all stored in a table used internally by Mesa. 
+
+
+# Threading models supported by Mesa
+
+In terms of API dispatch, Mesa currently supports four different threading models.  The compile-time choice of threading model dictates the implementation of the dispatch stubs.  The core difference lies in how the global dispatch pointer is stored and retrieved.  The threading mode is selected by defining one of `PTHREADS`, `SOLARIS_THREADS`, `WIN32_THREADS`, `USE_XTHREADS`, or `BEOS_THREADS`.  When `PTHREADS` is selected, `GLX_USE_TLS` can also be used.  If none of these values are defined, Mesa uses a single-threaded mode of operation. 
+
+
+## Single-threaded
+
+In single threaded mode as single, global variable is used to store the dispatch table pointer.  This results in the simplest possible dispatch stubs as well. 
+
+
+[[!format txt """
+void glVertex3fv( const GLfloat * v )
+{
+    (*_glapi_Dispatch->Vertex3fv)( v );
+}
+"""]]
+
+## Non-TLS threading models
+
+Mesa implements a generic wrapper function, called `_glapi_get_dispatch`, that is used to get the per-thread dispatch pointer.  The naive implementation of a dispatch stub is shown below. 
+
+
+[[!format txt """
+void glVertex3fv( const GLfloat * v )
+{
+    const struct _glapi_table * d = _glapi_get_dispatch();
+    (*d->Vertex3fv)( v );
+}
+"""]]
+This implementation is very simple, but it results in poor performance in the single-threaded case.  Single-threaded applications are by far more common that multi-threaded, so it make sense to do some optimization for that case.  The old variable `_glapi_Dispatch` continues to exist, but its semantic is slightly modified.  When the implementation of `glXMakeCurrent` detects that a new thread is setting a current context, `_glapi_Dispatch` is set to `NULL` and the true dispatch table pointer is stored in some piece of thread local storage.  This allows the dispatch function to use the state of `_glapi_Dispatch` to determine whether or not the application is single- or multi-threaded. 
+
+
+[[!format txt """
+void glVertex3fv( const GLfloat * v )
+{
+    const struct _glapi_table * d = (_glapi_Dispatch != NULL)
+        ? _glapi_Dispatch : _glapi_get_dispatch();
+    (*d->Vertex3fv)( v );
+}
+"""]]
+The result is vastly improved single-threaded performance with a small penalty to multi-threaded performance. 
+
+
+### Pthreads optimization
+
+Pthreads is by far the most common threading model used by Mesa.  Some of the overhead of `_glapi_get_dispatch` can be avoided by directly calling `pthread_getspecific` from the dispatch stub.  This helps the multi-threaded case slightly but has no impact on the single-threaded case. 
+
+
+[[!format txt """
+void glVertex3fv( const GLfloat * v )
+{
+    const struct _glapi_table * d = (_glapi_Dispatch != NULL)
+        ? _glapi_Dispatch : pthread_getspecific( & _gl_DispatchTSD );
+    (*d->Vertex3fv)( v );
+}
+"""]]
+
+## TLS
+
+Thread-local storage on Linux provides compiler supported, per-thread variables.  Once a variable is defined as being per-thread, it can be accessed with in C code like any global variable.  However, the compiler (and linker) will perform some magic behind the scenes to ensure that each thread has its own data.  On x86 this requires the use of a slightly more expensive addressing mode to access the TLS variables.  The performance penalty of this addressing mode in the single-threaded case has been measure to be comparable to the penalty of the `_glapi_Dispatch` test in the non-TLS case.  The performance advantage of the TLS access versus the call to either `_glapi_get_dispatch` or `pthreads_getspecific` is quite large. 
+
+The name of the dispatch table pointer is changed in the TLS case to prevent conflicts between a TLS libGL and a non-TLS DRI driver. 
+
+
+[[!format txt """
+void glVertex3fv( const GLfloat * v )
+{
+    (*_glapi_tls_Dispatch->Vertex3fv)( v );
+}
+"""]]
+
+# Implementation of static dispatch functions in Mesa
+
+In the Mesa source tree, the file gl_API.xml describes all of the known API functions.  In addition to describing the parameters to the function, each entry in gl_API.xml also declares a static offset in the dispatch table for that function. 
+
+
+## Python generator scripts
+
+A series of Python scripts are used to generate both platform independent API files and platform dependent API files.  For the API dispatch code, the most significant scripts that generate platform independent files are summarized in the following table. 
+[[!table header="no" class="mointable" data="""
+**Script Name** | **Generated File** | **Notes**
+gl_apitemp.py | glapitemp.h | C-code dispatch function templates
+gl_offsets.py | glapioffsets.h | List of defines of dispatch offsets
+gl_procs.py | glprocs.h | Tables used by `glXGetProcAddressARB`
+gl_table.py | glapitable.h | C structure definition of the dispatch table
+"""]]
+
+There are also several scripts that generate platform dependent files.  In all cases the generated files are assembly language versions of the dispatch stubs for a particular platform. 
+[[!table header="no" class="mointable" data="""
+**Script Name** | **Generated File** | **Notes**
+gl_ppc_asm.py | ppc/glapi_ppc.S | PowerPC dispatch stubs
+gl_SPARC_asm.py | sparc/glapi_sparc.S | SPARC (32-bit and 64-bit) dispatch stubs
+gl_x86_asm.py | x86/glapi_x86.S | x86 (32-bit) dispatch stubs
+gl_x86-64_asm.py | x86-64/glapi_x86-64.S | x86-64 dispatch stubs
+"""]]
+
+
+## Platform specifics
+
+
+### x86
+
+
+### x86-64
+
+
+### SPARC (32-bit and 64-bit)
+
+
+# Implementation of dynamic dispatch functions in Mesa
+
+
+[^1] This may not be the same as the address of the static dispatch stub.
diff --git a/GLdispatch.moin b/GLdispatch.moin
deleted file mode 100644
index 7595110..0000000
--- a/GLdispatch.moin
+++ /dev/null
@@ -1,120 +0,0 @@
-#pragma section-numbers on 
-
-<<TableOfContents>>
-
-= Background of API dispatch in Mesa =
-
-The operation of nearly every function in the OpenGL API depends on the state of the currently bound context.  Even if all state in two context's is identical, the operation can be different between the two contexts.  Consider a couple common examples:
-
- * One context is created for direct rendering (requiring that function calls be directed into the local driver) and the other context is created for indirect rendering (requiring that function calls be convertex to GLX protocol and sent to the server).
- * Both contexts are created for direct rendering, but one context is created on screen 0 of the display, which happens to be on a card by manufacturer Foo, and the other context is created on screen 1, which happens to be on a card by manufacturer Bar.  In this function calls are directed to a ''different'' local driver for each context.
-
-To implement this, Mesa uses something similar to the virtual function table for a C++ class.  Each context has an associated ''dispatch table''.  This table contains a function pointer for every function in the API.  When a context is bound with {{{glXMakeCurrent}}} (or similar function), a pointer to its dispatch table is stored in a global variable.  When an application calls an API function, such as {{{glVertex3f}}}, it is actually calling a generic ''dispatch stub'' in Mesa (dispatch stubs that are directly called are also referred to as ''static dispatch stubs'').  This dispatch stub fetches a pointer to the currently context's dispatch table, looks up a pointer to the desired function in that table, and, finally, calls the function.
-
-It is also important to note that, since the current context is set per-thread in a multithreaded application, the dispatch pointer is also stored per-thread.
-
-The [[http://oss.sgi.com/projects/ogl-sample/ABI/index.html|Linux OpenGL ABI]] requires that certain functions be statically exported by the system libGL.  However, nearly any useful implementation will want to expose more functionality.  Since applications cannot depend on these functions being statically available, another method is needed to access them.  Initially implemented as an [[http://oss.sgi.com/projects/ogl-sample/registry/ARB/get_proc_address.txt|extension]] and later incorporated into [[http://www.opengl.org/documentation/spec.html|GLX 1.4]], {{{glXGetProcAddressARB}}} (or {{{glXGetProcAddress}}}) is used to get a pointer to a named API function.  GLX requires that pointers returned by {{{glXGetProcAddressARB}}} be ''context independent''.  This means that calling {{{glXGetProcAddressARB((const GLubyte *) "glVertex3f")}}} will return the same value no matter what context is bound <<FootNote(This may not be the same as the address of the static dispatch stub.)>>.
-
-In addition, {{{glXGetProcAddressARB}}} can be called when ''no'' context is bound.  Since Mesa is capable of loading drivers with unknown functionality, Mesa has no way to know a priori that a requested function, such as {{{glWillNeverExist}}}, doesn't exist.  For this reason Mesa's implementation of {{{glXGetProcAddressARB}}} will ''never'' return {{{NULL}}} for a well formed API function name.  Other libGL implementations that only operate with a limited set of known drivers (e.g., Nvidia's closed-source libGL) can know which functions will never exist and may return {{{NULL}}}.
-
-Mesa's implementation of {{{glXGetProcAddressARB}}} does two important steps when called with a function name that is currently unknown.  It first assigns an offset in the dispatch table to the new function.  Once the location of the function pointer in the dispatch table is known, Mesa generates a ''dynamic dispatch stub'' for the function.  A pointer to this function is returned by {{{glXGetProcAddressARB}}}.  The name of the function, the assigned offset, and the dispatch stub pointer are all stored in a table used internally by Mesa.
-
-
-= Threading models supported by Mesa =
-
-In terms of API dispatch, Mesa currently supports four different threading models.  The compile-time choice of threading model dictates the implementation of the dispatch stubs.  The core difference lies in how the global dispatch pointer is stored and retrieved.  The threading mode is selected by defining one of {{{PTHREADS}}}, {{{SOLARIS_THREADS}}}, {{{WIN32_THREADS}}}, {{{USE_XTHREADS}}}, or {{{BEOS_THREADS}}}.  When {{{PTHREADS}}} is selected, {{{GLX_USE_TLS}}} can also be used.  If none of these values are defined, Mesa uses a single-threaded mode of operation.
-
-== Single-threaded ==
-
-In single threaded mode as single, global variable is used to store the dispatch table pointer.  This results in the simplest possible dispatch stubs as well.
-
-{{{
-void glVertex3fv( const GLfloat * v )
-{
-    (*_glapi_Dispatch->Vertex3fv)( v );
-}
-}}}
-
-== Non-TLS threading models ==
-
-Mesa implements a generic wrapper function, called {{{_glapi_get_dispatch}}}, that is used to get the per-thread dispatch pointer.  The naive implementation of a dispatch stub is shown below.
-
-{{{
-void glVertex3fv( const GLfloat * v )
-{
-    const struct _glapi_table * d = _glapi_get_dispatch();
-    (*d->Vertex3fv)( v );
-}
-}}}
-
-This implementation is very simple, but it results in poor performance in the single-threaded case.  Single-threaded applications are by far more common that multi-threaded, so it make sense to do some optimization for that case.  The old variable {{{_glapi_Dispatch}}} continues to exist, but its semantic is slightly modified.  When the implementation of {{{glXMakeCurrent}}} detects that a new thread is setting a current context, {{{_glapi_Dispatch}}} is set to {{{NULL}}} and the true dispatch table pointer is stored in some piece of thread local storage.  This allows the dispatch function to use the state of {{{_glapi_Dispatch}}} to determine whether or not the application is single- or multi-threaded.
-
-{{{
-void glVertex3fv( const GLfloat * v )
-{
-    const struct _glapi_table * d = (_glapi_Dispatch != NULL)
-        ? _glapi_Dispatch : _glapi_get_dispatch();
-    (*d->Vertex3fv)( v );
-}
-}}}
-
-The result is vastly improved single-threaded performance with a small penalty to multi-threaded performance.
-
-=== Pthreads optimization ===
-
-Pthreads is by far the most common threading model used by Mesa.  Some of the overhead of {{{_glapi_get_dispatch}}} can be avoided by directly calling {{{pthread_getspecific}}} from the dispatch stub.  This helps the multi-threaded case slightly but has no impact on the single-threaded case.
-
-{{{
-void glVertex3fv( const GLfloat * v )
-{
-    const struct _glapi_table * d = (_glapi_Dispatch != NULL)
-        ? _glapi_Dispatch : pthread_getspecific( & _gl_DispatchTSD );
-    (*d->Vertex3fv)( v );
-}
-}}}
-
-== TLS ==
-
-Thread-local storage on Linux provides compiler supported, per-thread variables.  Once a variable is defined as being per-thread, it can be accessed with in C code like any global variable.  However, the compiler (and linker) will perform some magic behind the scenes to ensure that each thread has its own data.  On x86 this requires the use of a slightly more expensive addressing mode to access the TLS variables.  The performance penalty of this addressing mode in the single-threaded case has been measure to be comparable to the penalty of the {{{_glapi_Dispatch}}} test in the non-TLS case.  The performance advantage of the TLS access versus the call to either {{{_glapi_get_dispatch}}} or {{{pthreads_getspecific}}} is quite large.
-
-The name of the dispatch table pointer is changed in the TLS case to prevent conflicts between a TLS libGL and a non-TLS DRI driver.
-
-{{{
-void glVertex3fv( const GLfloat * v )
-{
-    (*_glapi_tls_Dispatch->Vertex3fv)( v );
-}
-}}}
-
-= Implementation of static dispatch functions in Mesa =
-
-In the Mesa source tree, the file gl_API.xml describes all of the known API functions.  In addition to describing the parameters to the function, each entry in gl_API.xml also declares a static offset in the dispatch table for that function.
-
-== Python generator scripts ==
-
-A series of Python scripts are used to generate both platform independent API files and platform dependent API files.  For the API dispatch code, the most significant scripts that generate platform independent files are summarized in the following table.
-
-||<border="1">'''Script Name'''||'''Generated File'''||'''Notes'''||
-||gl_apitemp.py||glapitemp.h||C-code dispatch function templates||
-||gl_offsets.py||glapioffsets.h||List of defines of dispatch offsets||
-||gl_procs.py||glprocs.h||Tables used by {{{glXGetProcAddressARB}}}||
-||gl_table.py||glapitable.h||C structure definition of the dispatch table||
-
-There are also several scripts that generate platform dependent files.  In all cases the generated files are assembly language versions of the dispatch stubs for a particular platform.
-
-||<border="1">'''Script Name'''||'''Generated File'''||'''Notes'''||
-||gl_ppc_asm.py||ppc/glapi_ppc.S||PowerPC dispatch stubs||
-||gl_SPARC_asm.py||sparc/glapi_sparc.S||SPARC (32-bit and 64-bit) dispatch stubs||
-||gl_x86_asm.py||x86/glapi_x86.S||x86 (32-bit) dispatch stubs||
-||gl_x86-64_asm.py||x86-64/glapi_x86-64.S||x86-64 dispatch stubs||
-
-== Platform specifics ==
-
-=== x86 ===
-
-=== x86-64 ===
-
-=== SPARC (32-bit and 64-bit) ===
-
-
-= Implementation of dynamic dispatch functions in Mesa =
diff --git a/GSoC_2008.moin b/GSoC_2008.mdwn
index 3e49010..de4f166 100644
--- a/GSoC_2008.moin
+++ b/GSoC_2008.mdwn
@@ -1,39 +1,51 @@
-== Introduction ==
-
-Mesa / DRI was not accepted as a SoC organization, however we still accept projects through X.Org. This page is the current list of possible project ideas.  As always with GSoC, student suggested project ideas are always welcome.  Please join us for discussion in #dri-devel on Freenode.
-
-== Project List ==
-
-Below is the list of potential projects.  If there is a project not on the list that ''you would like to mentor'', please add it.  If there is a project not on the list that ''you would like to work on'', please contact us on #dri-devel on Freenode ''or'' on the Mesa developer's mailing list (https://lists.sourceforge.net/lists/listinfo/mesa3d-dev)
-
-=== Peep-hole Optimizer for Real-Time Code Generation ===
-More and more parts of the rendering pipeline are being dynamically generated.  For example, the Cell driver generates code, at run-time, to perform vertex fetch, depth testing, alpha blending, etc.  As time goes on, this will become more and more common.  Writing ''optimized'' C code to generate this assembly code is difficult.  One particular area of difficulty is preventing redundant calculations and redundant data loads.  Another area of difficulty is properly scheduling instructions for the target processor.
-
-Much of this complexity could be eliminated by the presence of a peep-hole optimizer.  This optimizer would analyze the code generated, for example, to perform alpha blending.  It would then reorder instructions, change register usage, eliminate redundant calculations, etc.  Peep-hole optimization is a fairly well known area in compiler development, however, stand-alone optimizers for use cases like this are less known.
-
-The goal of this project is to develop a peep-hole optimizer for the rtasm (real-time assembly) infrastructure in the gallium-0.1 branch of Mesa.  The optimizer should optimize code generated for one of the common Mesa target architectures (i.e., PowerPC, Cell SPE, x86-32 SSE, or x86-64).  Alternately, an optimizer could be written for one of the GPU architectures (r300, i965, etc.).  The optimizer should be considered a proof-of-concept implementation.  While being specific to one particular architecture, the optimizer will likely provide a model that would be used to create additional optimizers.  Eventually an optimizer will be need for each target processor and GPU.
-
-Mentor: IanRomanick
-
-
-=== Add a Nouveau gallium backend ===
-Nouveau currently implements 3D through gallium3D, which allows implementing a 3D driver core in very few lines of C (about 3000 for a basic driver). However, this support only exists (and in limited form) for nv40 cards. Preliminary support exists for nv10 and nv30.
-
-The goal of this project is to get a new 3D backend going. Obviously, this is a very ambitious goal, but intermediate goals can be set (for example: working single triangle, working glxgears, working textures...). Furthermore, nvidia cards have a fair amount of hardware in common from one generation to the other, and so code could be (and should be) leveraged from existing drivers (for example the nv20 vertex unit is identical to nv30's, whose code exists right now). The exact card to work on is to be determined by what hardware the student owns.
-
-Mentor: StephaneMarchesin
-
-=== Gallium3D frontend for video decoding ===
-Currently, real time video decoding of high definition streams can only be achieved thanks to hardware acceleration. The purpose of this project is to add a card-agnostic way of supporting hardware video decoding through the gallium3D framework. Gallium3D is a new framework allowing hardware accelerated OpenGL in free software drivers. However, it is not limited to OpenGL: when working on the frontend side, one can support additional APIs. The purpose of this project is to add a new frontend that supports hardware video decoding.
-
-Steps for this include choosing relevant APIs (XvMC and vaapi are among the possibilities) and implementing them in terms of the intermediate gallium3D format. The entropy decoding stage (which is the first step of most video decoding pipelines) should be taken particular care of, since it does not work well on a GPU (except when special hardware is available), so it will probably have to be done as optimized C or assembly. Special care should also be taken in ensuring that the decoding components are kept modular, since video codecs often use similar pipelines with slight changes.
-
-=== Implement render operations as a gallium3D frontend ===
-Currently drivers that want to implement render acceleration need to implement it separately in the DDX.  This code is is generally duplicated from the 3D driver, since texture operations are the most common method for doing blends and transforms in hardware.  The purpose of this project is to add a card-agnostic way of supporting hardware render operations through the gallium3D framework. Gallium3D is a new framework allowing hardware accelerated OpenGL in free software drivers. However, it is not limited to OpenGL: when working on the frontend side, one can support additional APIs that map to the card's pipeline. 
-
-Implementation would include support for 3D blits and fills with transformed coordinates and blends for the Porter/Duff compositing operations.
-
-=== Improve support for AMD/ATI cards ===
-While there are already drivers for most AMD/ATI hardware there are several features that are not yet taken advantage of.  Some possible ideas include: support for new extensions, support for private back/depth buffers, better use of GART space, etc.
-
-Mentor: AlexDeucher
+
+
+## Introduction
+
+Mesa / DRI was not accepted as a SoC organization, however we still accept projects through X.Org. This page is the current list of possible project ideas.  As always with GSoC, student suggested project ideas are always welcome.  Please join us for discussion in #dri-devel on Freenode. 
+
+
+## Project List
+
+Below is the list of potential projects.  If there is a project not on the list that _you would like to mentor_, please add it.  If there is a project not on the list that _you would like to work on_, please contact us on #dri-devel on Freenode _or_ on the Mesa developer's mailing list ([[https://lists.sourceforge.net/lists/listinfo/mesa3d-dev|https://lists.sourceforge.net/lists/listinfo/mesa3d-dev]]) 
+
+
+### Peep-hole Optimizer for Real-Time Code Generation
+
+More and more parts of the rendering pipeline are being dynamically generated.  For example, the Cell driver generates code, at run-time, to perform vertex fetch, depth testing, alpha blending, etc.  As time goes on, this will become more and more common.  Writing _optimized_ C code to generate this assembly code is difficult.  One particular area of difficulty is preventing redundant calculations and redundant data loads.  Another area of difficulty is properly scheduling instructions for the target processor. 
+
+Much of this complexity could be eliminated by the presence of a peep-hole optimizer.  This optimizer would analyze the code generated, for example, to perform alpha blending.  It would then reorder instructions, change register usage, eliminate redundant calculations, etc.  Peep-hole optimization is a fairly well known area in compiler development, however, stand-alone optimizers for use cases like this are less known. 
+
+The goal of this project is to develop a peep-hole optimizer for the rtasm (real-time assembly) infrastructure in the gallium-0.1 branch of Mesa.  The optimizer should optimize code generated for one of the common Mesa target architectures (i.e., PowerPC, Cell SPE, x86-32 SSE, or x86-64).  Alternately, an optimizer could be written for one of the GPU architectures (r300, i965, etc.).  The optimizer should be considered a proof-of-concept implementation.  While being specific to one particular architecture, the optimizer will likely provide a model that would be used to create additional optimizers.  Eventually an optimizer will be need for each target processor and GPU. 
+
+Mentor: [[IanRomanick|IanRomanick]] 
+
+
+### Add a Nouveau gallium backend
+
+Nouveau currently implements 3D through gallium3D, which allows implementing a 3D driver core in very few lines of C (about 3000 for a basic driver). However, this support only exists (and in limited form) for nv40 cards. Preliminary support exists for nv10 and nv30. 
+
+The goal of this project is to get a new 3D backend going. Obviously, this is a very ambitious goal, but intermediate goals can be set (for example: working single triangle, working glxgears, working textures...). Furthermore, nvidia cards have a fair amount of hardware in common from one generation to the other, and so code could be (and should be) leveraged from existing drivers (for example the nv20 vertex unit is identical to nv30's, whose code exists right now). The exact card to work on is to be determined by what hardware the student owns. 
+
+Mentor: [[StephaneMarchesin|StephaneMarchesin]] 
+
+
+### Gallium3D frontend for video decoding
+
+Currently, real time video decoding of high definition streams can only be achieved thanks to hardware acceleration. The purpose of this project is to add a card-agnostic way of supporting hardware video decoding through the gallium3D framework. Gallium3D is a new framework allowing hardware accelerated OpenGL in free software drivers. However, it is not limited to OpenGL: when working on the frontend side, one can support additional APIs. The purpose of this project is to add a new frontend that supports hardware video decoding. 
+
+Steps for this include choosing relevant APIs (XvMC and vaapi are among the possibilities) and implementing them in terms of the intermediate gallium3D format. The entropy decoding stage (which is the first step of most video decoding pipelines) should be taken particular care of, since it does not work well on a GPU (except when special hardware is available), so it will probably have to be done as optimized C or assembly. Special care should also be taken in ensuring that the decoding components are kept modular, since video codecs often use similar pipelines with slight changes. 
+
+
+### Implement render operations as a gallium3D frontend
+
+Currently drivers that want to implement render acceleration need to implement it separately in the DDX.  This code is is generally duplicated from the 3D driver, since texture operations are the most common method for doing blends and transforms in hardware.  The purpose of this project is to add a card-agnostic way of supporting hardware render operations through the gallium3D framework. Gallium3D is a new framework allowing hardware accelerated OpenGL in free software drivers. However, it is not limited to OpenGL: when working on the frontend side, one can support additional APIs that map to the card's pipeline.  
+
+Implementation would include support for 3D blits and fills with transformed coordinates and blends for the Porter/Duff compositing operations. 
+
+
+### Improve support for AMD/ATI cards
+
+While there are already drivers for most AMD/ATI hardware there are several features that are not yet taken advantage of.  Some possible ideas include: support for new extensions, support for private back/depth buffers, better use of GART space, etc. 
+
+Mentor: [[AlexDeucher|AlexDeucher]] 
diff --git a/Gallium3D.mdwn b/Gallium3D.mdwn
new file mode 100644
index 0000000..912cf20
--- /dev/null
+++ b/Gallium3D.mdwn
@@ -0,0 +1,11 @@
+
+
+### New driver infrastructure
+
+Initial announcement, under the name softpipe, 2007-05-24: [[humble beginnings...|http://thread.gmane.org/gmane.comp.video.mesa3d.devel/8719]] 
+
+Some docs/presentation, from November, 2009:  [[Gallium3D Online Developers Workshop|http://www.freedesktop.org/wiki/Software/gallium/GAOnlineWorkshop]] 
+
+Zack Rusin, working hard on various improvements to Gallium3D (2007-2010) : [[Blog|http://zrusin.blogspot.com/]] 
+
+[[Status|http://www.x.org/wiki/GalliumStatus]] , on X.org Wiki page.  
diff --git a/Gallium3D.moin b/Gallium3D.moin
deleted file mode 100644
index 79f212d..0000000
--- a/Gallium3D.moin
+++ /dev/null
@@ -1,9 +0,0 @@
-=== New driver infrastructure ===
-
-Initial announcement, under the name softpipe, 2007-05-24: [[ http://thread.gmane.org/gmane.comp.video.mesa3d.devel/8719 | humble beginnings... ]]
-
-Some docs/presentation, from November, 2009:  [[ http://www.freedesktop.org/wiki/Software/gallium/GAOnlineWorkshop | Gallium3D Online Developers Workshop ]]
-
-Zack Rusin, working hard on various improvements to Gallium3D (2007-2010) : [[ http://zrusin.blogspot.com/ | Blog ]]
-
-[[ http://www.x.org/wiki/GalliumStatus|Status]] , on X.org Wiki page. 
diff --git a/GalliumCompute.mdwn b/GalliumCompute.mdwn
new file mode 100644
index 0000000..453b7a2
--- /dev/null
+++ b/GalliumCompute.mdwn
@@ -0,0 +1,130 @@
+
+[[!toc ]] 
+
+
+## Current Status
+
+For supporting OpenCL, or hardware level GeneralPurposeGPU computing. We are at the planning stage, and redesigning the interfaces in gallium to support compute, like TGSI. It is expected that we will support AMD (ATI) Evergreen (r800 - HD5xxx), and hopefully Nvidia cards too. 
+[[!table header="no" class="mointable" data="""
+  | **cpu (llvmpipe)**  | **nv50**  | **nvc0**  | **r700**  | **r800**  | **r900** 
+non gallium test code<sup>1</sup>  | N/N  | TODO  | TODO  | DONE  | DONE  | WIP 
+gallium hw interface  | N/N  | MOSTLY  | MOSTLY  | 3D  | MOSTLY  | MOSTLY 
+execute binary<sup>2</sup> compute shader  | TODO  | TODO  | TODO  | N/A  | MOSTLY  | TODO 
+handling GPU buffers  | TODO  | TODO  | TODO  | TODO  | MOSTLY  | MOSTLY 
+execute TGSI compute shader  | TODO  | TODO  | TODO  | TODO  | N/A  | N/A 
+execute LLVM-IR compute shader  | TODO  | TODO  | TODO  | TODO  | DONE  | DONE 
+performance profiling  | TODO  | TODO  | TODO  | TODO  | TODO  | TODO 
+global address space  | TODO  | TODO  | TODO  | TODO  | DONE  | WIP 
+local address space  | TODO  | TODO  | TODO  | TODO  | TODO  | TODO 
+private address space  | TODO  | TODO  | TODO  | TODO  | WIP  | WIP 
+constant adress space  | TODO  | TODO  | TODO  | TODO  | WIP  | WIP 
+local sync  | TODO  | TODO  | TODO  | TODO  | TODO  | TODO 
+global sync  | TODO  | TODO  | TODO  | N/A  | TODO  | TODO 
+local atomics  | TODO  | TODO  | TODO  | N/A  | TODO  | TODO 
+global atomics  | TODO  | TODO  | TODO  | N/A  | TODO  | TODO 
+2D image read  | TODO  | TODO  | TODO  | TODO  | TODO  | TODO 
+3D image read  | TODO  | TODO  | TODO  | N/A  | TODO  | TODO 
+2D image write  | TODO  | TODO  | TODO  | TODO  | TODO  | TODO 
+3D image write  | TODO  | TODO  | TODO  | N/A  | TODO  | TODO 
+accurate<sup>4</sup> arithmetics  | TODO  | TODO  | TODO  | TODO  | MOSTLY<sup>7</sup>  | WIP 
+OpenCL<sup>5</sup> 1.0  | TODO  | TODO  | TODO  | N/A<sup>6</sup>  | WIP  | WIP 
+OpenCL 1.1  | TODO  | TODO  | TODO  | N/A  | WIP  | WIP 
+OpenGL interoperability  | TODO  | TODO  | TODO  | TODO  | TODO  | TODO 
+"""]]
+
+<sup>1</sup> Proof of concept test code for testing and experimenting with hardware compute support 
+
+<sup>2</sup> Hardware specific binary code 
+
+<sup>4</sup> OpenCL defines some level expected accuracy. Some hardware doesn't support it, so we need software emulation 
+
+<sup>5</sup> OpenCL front-end is a separate project, we aim to support all features needed by the front-end to implement the standard 
+
+<sup>6</sup> Only partial OpenCL support is possible, support through vertex shaders. 
+
+<sup>7</sup> Mostly reliable for float and integer types.  char, short, long, and double types need more testing. 
+
+
+### r600g
+
+
+#### Supported Hardware
+
+* All Evergreen and Northern Islands GPU familes are currently supported.  If you are unsure what family your GPU is, you can use this chart: [[http://www.x.o/wiki/RadeonFeature#Decoder_ring_for_engineering_vs_marketing_names|http://www.x.org/wiki/RadeonFeature#Decoder_ring_for_engineering_vs_marketing_names]] to figure it out. 
+* There are still a few bugs on Cayman GPUs, that may prevent some compute features from working as well as they do on pre-Cayman GPUS. 
+
+#### Supported Linux Kernel Versions
+
+* r600g compute is known to work with stable Linux Kernel versions >= 3.1. Versions older than 3.1 may work, but have not been tested. 
+
+#### How to Install
+
+
+##### Getting the source code
+
+* Current Development version: 
+   * LLVM / Clang: [[!format txt """
+git clone http://llvm.org/git/llvm.git
+cd llvm/tools
+git clone http://llvm.org/git/clang.git
+"""]]
+   * libclc: [[!format txt """
+git clone git://people.freedesktop.org/~tstellar/libclc
+"""]]
+   * Mesa: [[!format txt """
+git clone git://anongit.freedesktop.org/mesa/mesa
+"""]]
+* Stable Version (NOTE: Some distros provide packages for the stable versions of Mesa (9.1) and LLVM (3.2) that include compute support for r600g): 
+   * LLVM / Clang: [[!format txt """
+git clone git://people.freedesktop.org/~tstellar/llvm
+cd llvm/tools
+wget http://llvm.org/releases/3.2/clang-3.2.src.tar.gz
+tar -xzf clang-3.2.src.targ.gz
+mv clang-3.2-src clang
+"""]]
+   * libclc: [[!format txt """
+git clone git://people.freedesktop.org/~tstellar/libclc
+git checkout llvm-3.2
+"""]]
+   * Mesa: [[!format txt """
+wget ftp://ftp.freedesktop.org/pub/mesa/9.1.1/MesaLib-9.1.1.tar.gz
+tar -xzf MesaLib-9.1.1.tar.gz
+"""]]
+
+##### Building
+
+1. LLVM / Clang: [[!format txt """
+cd llvm/
+./configure --enable-experimental-targets=R600 --enable-targets=x86 --enable-shared
+make -j3 && make install
+"""]]
+   * LLVM builds all supported targets by default, so adding --enable-targets=x86 will speed up the build time.  NOTE: Mesa requires the X86 target to be built. 
+   * LLVM will try to use clang as its compiler by default.  This may not work for you in all cases (e.g. you have an old version of clang installed).  You can force llvm to use gcc by appending CC=gcc CXX=g++ to the configure arguments. 
+1. libclc: [[!format txt """
+git clone git://people.freedesktop.org/~tstellar/libclc
+cd libclc/
+./configure.py
+make
+make install
+"""]]
+   * When buiding libclc you may see this warning: " is not a recognized processor for this target (ignoring processor)" Don't worry, this warning is harmless. 
+1. Mesa: [[!format txt """
+cd mesa/
+./autogen.sh --with-dri-drivers="" --with-gallium-drivers=r600 --enable-opencl
+make -j3
+make install
+"""]]
+
+#### Testing
+
+* OpenCL examples that mostly work with clover and r600g can be found [[here|http://cgit.freedesktop.org/~tstellar/opencl-example/]]. 
+* [[Piglit|http://cgit.freedesktop.org/piglit]]: Use the all_cl.tests test profile. 
+
+#### Troubleshooting
+
+* If see this error message: radeon: Failed to get PCI ID, error number -13, make sure you have permissions to access the device (usually /dev/dri/card0), and get the latest version of mesa from git.  Prior to this commit: 044de40cb0c6af54d99252f55145972780362afa, you would have seen this error message when running compute programs and X at the same time. 
+* If you get the error message "cannot find stddef.h" when you try to run a compute program, this means that clang can't find its builtin include files.  The solution for this is to make sure that clang and llvm are both installed to the same $(LIBDIR). Clover expects the clang builtin includes to be in $(LLVM_LIBDIR)/clang/$(LLVM_VERSION)/ 
+
+#### Todo
+
+[[R600ToDo#Compute|R600ToDo]] 
diff --git a/GalliumCompute.moin b/GalliumCompute.moin
deleted file mode 100644
index c7265f6..0000000
--- a/GalliumCompute.moin
+++ /dev/null
@@ -1,128 +0,0 @@
-<<TableOfContents()>>
-
-== Current Status ==
-For supporting OpenCL, or hardware level GeneralPurposeGPU computing. We are at the planning stage, and redesigning the interfaces in gallium to support compute, like TGSI. It is expected that we will support AMD (ATI) Evergreen (r800 - HD5xxx), and hopefully Nvidia cards too.
-||<tablestyle="text-align:center;"> ||<#666666>'''cpu (llvmpipe)''' ||<#666666>'''nv50''' ||<#666666>'''nvc0''' ||<#666666>'''r700''' ||<#666666>'''r800''' ||<#666666>'''r900''' ||
-||non gallium test code^1^ ||<bgcolor="lightgray">N/N ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="lightgreen">DONE ||<bgcolor="lightgreen">DONE ||<bgcolor="orange">WIP ||
-||gallium hw interface ||<bgcolor="lightgray">N/N ||<bgcolor="yellow">MOSTLY ||<bgcolor="yellow">MOSTLY ||<bgcolor="yellow">3D ||<bgcolor="yellow">MOSTLY ||<bgcolor="yellow">MOSTLY ||
-||execute binary^2^ compute shader ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="lightgray">N/A ||<bgcolor="yellow">MOSTLY ||<bgcolor="red">TODO ||
-||handling GPU buffers ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="yellow">MOSTLY ||<bgcolor="yellow">MOSTLY ||
-||execute TGSI compute shader ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="lightgray">N/A ||<bgcolor="lightgray">N/A ||
-||execute LLVM-IR compute shader ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="lightgreen">DONE ||<bgcolor="lightgreen">DONE ||
-||performance profiling ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||
-||global address space ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="lightgreen">DONE ||<bgcolor="orange">WIP ||
-||local address space ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||
-||private address space ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="orange">WIP ||<bgcolor="orange">WIP ||
-||constant adress space ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="orange">WIP ||<bgcolor="orange">WIP ||
-||local sync ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||
-||global sync ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="lightgray">N/A ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||
-||local atomics ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="lightgray">N/A ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||
-||global atomics ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="lightgray">N/A ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||
-||2D image read ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||
-||3D image read ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="lightgray">N/A ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||
-||2D image write ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||
-||3D image write ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="lightgray">N/A ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||
-||accurate^4^ arithmetics ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="yellow">MOSTLY^7^ ||<bgcolor="orange">WIP ||
-||OpenCL^5^ 1.0 ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="lightgray">N/A^6^ ||<bgcolor="orange">WIP ||<bgcolor="orange">WIP ||
-||OpenCL 1.1 ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="lightgray">N/A ||<bgcolor="orange">WIP ||<bgcolor="orange">WIP ||
-||OpenGL interoperability ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||<bgcolor="red">TODO ||
-
-
-
-
-^1^ Proof of concept test code for testing and experimenting with hardware compute support
-
-^2^ Hardware specific binary code
-
-^4^ OpenCL defines some level expected accuracy. Some hardware doesn't support it, so we need software emulation
-
-^5^ OpenCL front-end is a separate project, we aim to support all features needed by the front-end to implement the standard
-
-^6^ Only partial OpenCL support is possible, support through vertex shaders.
-
-^7^ Mostly reliable for float and integer types.  char, short, long, and double types need more testing.
-
-=== r600g ===
-==== Supported Hardware ====
- * All Evergreen and Northern Islands GPU familes are currently supported.  If you are unsure what family your GPU is, you can use this chart: [[http://www.x.org/wiki/RadeonFeature#Decoder_ring_for_engineering_vs_marketing_names|http://www.x.o/wiki/RadeonFeature#Decoder_ring_for_engineering_vs_marketing_names]] to figure it out.
-
- * There are still a few bugs on Cayman GPUs, that may prevent some compute features from working as well as they do on pre-Cayman GPUS.
-
-==== Supported Linux Kernel Versions ====
- * r600g compute is known to work with stable Linux Kernel versions >= 3.1. Versions older than 3.1 may work, but have not been tested.
-
-==== How to Install ====
-===== Getting the source code =====
- * Current Development version:
-  * LLVM / Clang:
-  {{{
-git clone http://llvm.org/git/llvm.git
-cd llvm/tools
-git clone http://llvm.org/git/clang.git
-}}}
-  * libclc:
-  {{{
-git clone git://people.freedesktop.org/~tstellar/libclc
-}}}
-  * Mesa:
-  {{{
-git clone git://anongit.freedesktop.org/mesa/mesa
-}}}
- * Stable Version (NOTE: Some distros provide packages for the stable versions of Mesa (9.1) and LLVM (3.2) that include compute support for r600g):
-  * LLVM / Clang:
-  {{{
-git clone git://people.freedesktop.org/~tstellar/llvm
-cd llvm/tools
-wget http://llvm.org/releases/3.2/clang-3.2.src.tar.gz
-tar -xzf clang-3.2.src.targ.gz
-mv clang-3.2-src clang
-}}}
-  * libclc:
-  {{{
-git clone git://people.freedesktop.org/~tstellar/libclc
-git checkout llvm-3.2
-}}}
-  * Mesa:
-  {{{
-wget ftp://ftp.freedesktop.org/pub/mesa/9.1.1/MesaLib-9.1.1.tar.gz
-tar -xzf MesaLib-9.1.1.tar.gz
-}}}
-
-===== Building =====
- 1. LLVM / Clang:
- {{{
-cd llvm/
-./configure --enable-experimental-targets=R600 --enable-targets=x86 --enable-shared
-make -j3 && make install
-}}}
-
-  * LLVM builds all supported targets by default, so adding --enable-targets=x86 will speed up the build time.  NOTE: Mesa requires the X86 target to be built.
-
-  * LLVM will try to use clang as its compiler by default.  This may not work for you in all cases (e.g. you have an old version of clang installed).  You can force llvm to use gcc by appending CC=gcc CXX=g++ to the configure arguments.
- 1. libclc:
- {{{
-git clone git://people.freedesktop.org/~tstellar/libclc
-cd libclc/
-./configure.py
-make
-make install
-}}}
-  * When buiding libclc you may see this warning: " is not a recognized processor for this target (ignoring processor)" Don't worry, this warning is harmless.
- 1. Mesa:
- {{{
-cd mesa/
-./autogen.sh --with-dri-drivers="" --with-gallium-drivers=r600 --enable-opencl
-make -j3
-make install
-}}}
-
-==== Testing ====
- * OpenCL examples that mostly work with clover and r600g can be found [[http://cgit.freedesktop.org/~tstellar/opencl-example/|here]].
- * [[http://cgit.freedesktop.org/piglit|Piglit]]: Use the all_cl.tests test profile.
-
-==== Troubleshooting ====
- * If see this error message: radeon: Failed to get PCI ID, error number -13, make sure you have permissions to access the device (usually /dev/dri/card0), and get the latest version of mesa from git.  Prior to this commit: 044de40cb0c6af54d99252f55145972780362afa, you would have seen this error message when running compute programs and X at the same time.
- * If you get the error message "cannot find stddef.h" when you try to run a compute program, this means that clang can't find its builtin include files.  The solution for this is to make sure that clang and llvm are both installed to the same $(LIBDIR). Clover expects the clang builtin includes to be in $(LLVM_LIBDIR)/clang/$(LLVM_VERSION)/
-
-==== Todo ====
-R600ToDo#Compute
diff --git a/GeForce.moin b/GeForce.mdwn
index 82da02b..01b7332 100644
--- a/GeForce.moin
+++ b/GeForce.mdwn
@@ -1 +1,2 @@
-GeForce is the name of a family of graphics adapters from nVidia.
+
+GeForce is the name of a family of graphics adapters from nVidia. 
diff --git a/GettingStarted.mdwn b/GettingStarted.mdwn
new file mode 100644
index 0000000..4467986
--- /dev/null
+++ b/GettingStarted.mdwn
@@ -0,0 +1,58 @@
+
+
+# Getting started
+
+To join in development you must first understand the DRI and X11 architecture. Start by reading the developer documents in the documentation section of this website. 
+
+Check out the [[DRI git tree|http://cgit.freedesktop.org/mesa/mesa/?h=master]]. Poke around the driver source code to find out more about the inner workings of the DRI. There also are some text documents within the X11 source tree that contain useful information. The [[Building|Building]] page tells you how to check out, build and install into your local installation of X. If you would like to build and test as a normal user, try the [[NormalUserBuild|NormalUserBuild]] page. 
+
+Once you feel that you have sufficient understanding of the DRI to begin coding you can start by submitting a patch. You have to submit at least one patch to get write access to our git. Have a look in [[Bugzilla|https://bugs.freedesktop.org]] for open issues. That is a good place to find an issue that you can fix by submitting a patch. 
+
+After you have submitted your patch you can start working on a more concrete project. Have a look at the Status page or read the newsgroups for projects that need to be worked on. 
+
+Of course you don't have to submit a patch before you can work on a project. But since you wont be able to check in your work until you submit a patch it is very desirable to submit a patch first. You do want people to test your work, right? 
+
+Also, don't be shy about asking questions on the [[dri-devel newsgroup|http://lists.freedesktop.org/mailman/listinfo/dri-devel]]. The main purpose of the newsgroup is the discussion of development issues. So, feel free to ask questions. 
+
+
+## Submitting patches
+
+Submit a patch by posting it to the dri-devel mailing list as an attachment to a message. Make sure you explain clearly what your patch is for. 
+
+Once you become a regular contributor we'll give you git access. 
+
+
+## Suggested Reading
+
+The References page has a list of suggested reading material.  This section will give you a guide to how you should approach the reading of these resources. 
+
+
+### For beginners...
+
+There is a wide range of concepts involved in making a DRI driver. As a beginner you don't really need to fully understand them -- just a basic understanding which enables you to get the global picture. You should skim through all the documents referred below, giving more attention to the parts that your curiosity and/or ignorance point you to. 
+
+The first document you should read is this FAQ. Not because it's more important than the rest, but because is full of references and simple explanations that provide basic knowledge you need to guide yourself. 
+
+There are several topics you must address: 
+
+   * **3D cards workings:** Since a 3D driver and the OpenGL API are basically abstractions to 3D graphics cards abilities, knowing how a 3D card works will help you better understand the drivers. [[Barron01|References]] and [[Savator01|References]] give an excellent overview. 
+   * **OpenGL API:** DRI drivers typcially aim to be as conformant as possible to the OpenGL API. The best reading is indeed the OpenGL Specification. As [[BrianPaul|BrianPaul]] once said: "The [[RedBook|RedBook]] is for OpenGL users. The spec is more for the implementors." 
+* **Low-level programming:** Since you'll be dealing with the guts of the hardware and the OS you should read [[LDD|References]] which addresses all the details of writing a device driver, covering issues such as I/O, DMA, and memory organization from the Linux kernel perspective. [[TLK|References]] and [[LKMPG|References]] are also good references. 
+* [[background on ioremap, cacheing, cache coherency on x86|http://kerneltrap.org/mailarchive/linux-kernel/2008/4/29/1657814]] 
+* **DRI and X11 architecture:** This FAQ will give you a good overview of the DRI architecture.  It does not contain all the information of the [[DRI documentation|http://dri.sourceforge.net/documentation.phtml]], but you should give a quick look through it since you may need it for later reference. The X11 architecture is also important. 
+
+### For reference...
+
+Beyond reading the above documents more thoroughly, the source code can be the best reference available, especially when the documentation is out of date or non-existent. 
+
+Master the tools to quickly find information in a large source tree like DRI's. Use [[find and locate|http://www.gnu.org/software/findutils/findutils.html]] to quickly get to the files you search. Use [[grep|http://www.gnu.org/software/grep/doc/grep.html]] for searching a for a particular variable or piece of text.  You can also use specific tools for code navigation such as [[cscope|http://cscope.sourceforge.net]] and [[Source Navigator|http://sources.redhat.com/sourcenav/]]. 
+
+Another source of information is the source of the drivers other than the one you are interested in. Since the DRI drivers are largely in tune with each other you can learn much by comparing the sources. Use [[diff|http://www.gnu.org/software/diffutils/diffutils.html]] or [[xxdiff|http://xxdiff.sourceforge.net]] for that. 
+
+
+## Tools
+
+After you read enough about what to do and how to do so without damaging your hardware, you could look: 
+
+* [[ReverseEngineering|ReverseEngineering]] tools. 
+* [[Profiling|Profiling]] tools. 
+\ No newline at end of file
diff --git a/GettingStarted.moin b/GettingStarted.moin
deleted file mode 100644
index ddf0287..0000000
--- a/GettingStarted.moin
+++ /dev/null
@@ -1,54 +0,0 @@
-= Getting started =
-
-To join in development you must first understand the DRI and X11 architecture. Start by reading the developer documents in the documentation section of this website.
-
-Check out the [[http://cgit.freedesktop.org/mesa/mesa/?h=master|DRI git tree]]. Poke around the driver source code to find out more about the inner workings of the DRI. There also are some text documents within the X11 source tree that contain useful information. The [[Building]] page tells you how to check out, build and install into your local installation of X. If you would like to build and test as a normal user, try the NormalUserBuild page.
-
-Once you feel that you have sufficient understanding of the DRI to begin coding you can start by submitting a patch. You have to submit at least one patch to get write access to our git. Have a look in [[https://bugs.freedesktop.org|Bugzilla]] for open issues. That is a good place to find an issue that you can fix by submitting a patch.
-
-After you have submitted your patch you can start working on a more concrete project. Have a look at the Status page or read the newsgroups for projects that need to be worked on.
-
-Of course you don't have to submit a patch before you can work on a project. But since you wont be able to check in your work until you submit a patch it is very desirable to submit a patch first. You do want people to test your work, right?
-
-Also, don't be shy about asking questions on the [[http://lists.freedesktop.org/mailman/listinfo/dri-devel|dri-devel newsgroup]]. The main purpose of the newsgroup is the discussion of development issues. So, feel free to ask questions.
-
-== Submitting patches ==
-
-Submit a patch by posting it to the dri-devel mailing list as an attachment to a message.
-Make sure you explain clearly what your patch is for.
-
-Once you become a regular contributor we'll give you git access.
-
-== Suggested Reading ==
-
-The References page has a list of suggested reading material.  This section will give you a guide to how you should approach the reading of these resources.
-
-=== For beginners... ===
-
-There is a wide range of concepts involved in making a DRI driver. As a beginner you don't really need to fully understand them -- just a basic understanding which enables you to get the global picture. You should skim through all the documents referred below, giving more attention to the parts that your curiosity and/or ignorance point you to.
-
-The first document you should read is this FAQ. Not because it's more important than the rest, but because is full of references and simple explanations that provide basic knowledge you need to guide yourself.
-
-There are several topics you must address:
-
-  * '''3D cards workings:''' Since a 3D driver and the OpenGL API are basically abstractions to 3D graphics cards abilities, knowing how a 3D card works will help you better understand the drivers. [[References|Barron01]] and [[References|Savator01]] give an excellent overview.
-  * '''OpenGL API:''' DRI drivers typcially aim to be as conformant as possible to the OpenGL API. The best reading is indeed the OpenGL Specification. As BrianPaul once said: "The RedBook is for OpenGL users. The spec is more for the implementors."
- * '''Low-level programming:''' Since you'll be dealing with the guts of the hardware and the OS you should read [[References|LDD]] which addresses all the details of writing a device driver, covering issues such as I/O, DMA, and memory organization from the Linux kernel perspective. [[References|TLK]] and [[References|LKMPG]] are also good references.
- * [[http://kerneltrap.org/mailarchive/linux-kernel/2008/4/29/1657814 | background on ioremap, cacheing, cache coherency on x86]]
- * '''DRI and X11 architecture:''' This FAQ will give you a good overview of the DRI architecture.  It does not contain all the information of the [[http://dri.sourceforge.net/documentation.phtml|DRI documentation]], but you should give a quick look through it since you may need it for later reference. The X11 architecture is also important.
-
-=== For reference... ===
-
-Beyond reading the above documents more thoroughly, the source code can be the best reference available, especially when the documentation is out of date or non-existent.
-
-Master the tools to quickly find information in a large source tree like DRI's. Use [[http://www.gnu.org/software/findutils/findutils.html|find and locate]] to quickly get to the files you search. Use [[http://www.gnu.org/software/grep/doc/grep.html|grep]] for searching a for a particular variable or piece of text. 
-You can also use specific tools for code navigation such as [[http://cscope.sourceforge.net|cscope]] and [[http://sources.redhat.com/sourcenav/|Source Navigator]].
-
-Another source of information is the source of the drivers other than the one you are interested in. Since the DRI drivers are largely in tune with each other you can learn much by comparing the sources. Use [[http://www.gnu.org/software/diffutils/diffutils.html|diff]] or [[http://xxdiff.sourceforge.net|xxdiff]] for that.
-
-== Tools ==
-
-After you read enough about what to do and how to do so without damaging your hardware, you could look:
-
- * ReverseEngineering tools.
- * [[Profiling]] tools.
diff --git a/Glide.mdwn b/Glide.mdwn
new file mode 100644
index 0000000..9758577
--- /dev/null
+++ b/Glide.mdwn
@@ -0,0 +1,34 @@
+
+
+## Glide
+
+A 3D API developed by the 3dfx company. Glide only works with Voodoo based 3D cards and in many ways it is very similar to OpenGL. You can write an entire 3D application using Glide and it should (in theory) run on any Voodoo based 3D card. Glide is now open source. 
+
+
+### What's the relationship between Glide and DRI?
+
+Right now the picture looks like this: 
+
+   * [[!format txt """
+Client -> OpenGL / GLX -> Glide as HAL (DRI) -> hardware
+"""]]
+In this layout the Glide (DRI) is really a hardware abstraction layer. The only API exposed it OpenGL and Glide (DRI) only works with OpenGL. It isn't useful by itself. 
+
+There are a few Glide only games. 3dfx would like to see those work. So the current solution, shown above, doesn't work since the Glide API isn't available. Instead we need: 
+
+* [[!format txt """
+Client -> Glide as API (DRI) -> hw
+"""]]
+Right now Mesa does a bunch of the DRI work, and then hands that data down to Glide. Also Mesa does all the locking of the hardware. If we're going to remove Mesa, then Glide now has to do the DRI work, and we have to do something about the locking. 
+
+The solution is actually a bit more complicated. Glide wants to use all the memory as well. We don't want the X server to draw at all. Glide will turn off drawing in the X server and grab the lock and never let it go. That way no other 3D client can start up and the X server can still process keyboard events and such for you. When the Glide app goes away we just force a big refresh event for the whole screen. 
+
+I hope that explains it. We're really not trying to encourage people to use the Glide API, it is just to allow those existing games to run. We really want people to use OpenGL directly. 
+
+Another interesting project that a few people have discussed is removing Glide from the picture at all. Just let Mesa send the actual commands to the hardware. That's the way most of our drivers were written. It would simplify the install process (you don't need Glide separately) and it might improve performance a bit, and since we're only doing this for one type of hardware (Voodoo3+) Glide isn't doing that much as a hardware abstraction layer. It's some work. There's about 50 calls from Glide we use and those aren't simple, but it might be a good project for a few people to tackle. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]], [[CategoryFaq|CategoryFaq]] 
diff --git a/Glide.moin b/Glide.moin
deleted file mode 100644
index 8ba6f28..0000000
--- a/Glide.moin
+++ /dev/null
@@ -1,54 +0,0 @@
-== Glide ==
-
-A 3D API developed by the 3dfx company. Glide only works with Voodoo based 3D
-cards and in many ways it is very similar to OpenGL. You can write an entire 3D
-application using Glide and it should (in theory) run on any Voodoo based 3D
-card. Glide is now open source.
-
-=== What's the relationship between Glide and DRI? ===
-
-Right now the picture looks like this:
-
-  {{{
-Client -> OpenGL / GLX -> Glide as HAL (DRI) -> hardware
-}}}
-
-In this layout the Glide (DRI) is really a hardware abstraction layer. The only
-API exposed it OpenGL and Glide (DRI) only works with OpenGL. It isn't useful by
-itself.
-
-There are a few Glide only games. 3dfx would like to see those work. So the
-current solution, shown above, doesn't work since the Glide API isn't
-available. Instead we need:
-
- {{{
-Client -> Glide as API (DRI) -> hw
-}}}
-
-Right now Mesa does a bunch of the DRI work, and then hands that data down to
-Glide. Also Mesa does all the locking of the hardware. If we're going to remove
-Mesa, then Glide now has to do the DRI work, and we have to do something about
-the locking.
-
-The solution is actually a bit more complicated. Glide wants to use all the
-memory as well. We don't want the X server to draw at all. Glide will turn off
-drawing in the X server and grab the lock and never let it go. That way no
-other 3D client can start up and the X server can still process keyboard events
-and such for you. When the Glide app goes away we just force a big refresh
-event for the whole screen.
-
-I hope that explains it. We're really not trying to encourage people to use the
-Glide API, it is just to allow those existing games to run. We really want
-people to use OpenGL directly.
-
-Another interesting project that a few people have discussed is removing Glide
-from the picture at all. Just let Mesa send the actual commands to the
-hardware. That's the way most of our drivers were written. It would simplify
-the install process (you don't need Glide separately) and it might improve
-performance a bit, and since we're only doing this for one type of hardware
-(Voodoo3+) Glide isn't doing that much as a hardware abstraction layer. It's
-some work. There's about 50 calls from Glide we use and those aren't simple,
-but it might be a good project for a few people to tackle.
-
-----
-CategoryGlossary, CategoryFaq
diff --git a/GlossaryTemplate.mdwn b/GlossaryTemplate.mdwn
new file mode 100644
index 0000000..2b118f9
--- /dev/null
+++ b/GlossaryTemplate.mdwn
@@ -0,0 +1,15 @@
+
+
+## Term
+
+Definition. 
+
+
+### Resources
+
+   * [[A link|http://somewhere.com]] 
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/GlossaryTemplate.moin b/GlossaryTemplate.moin
deleted file mode 100644
index 2610843..0000000
--- a/GlossaryTemplate.moin
+++ /dev/null
@@ -1,10 +0,0 @@
-== Term ==
-
-Definition.
-
-=== Resources ===
-
-  * [[http://somewhere.com|A link]]
-
-----
-CategoryGlossary
diff --git a/HAL.mdwn b/HAL.mdwn
new file mode 100644
index 0000000..8876ad6
--- /dev/null
+++ b/HAL.mdwn
@@ -0,0 +1,19 @@
+
+
+## Hardware Abstraction Layer (HAL)
+
+Todo (Put here the generic, non-Matrox related, definition of a _hardware abstraction layer_ --[[JoseFonseca|JoseFonseca]]) 
+
+
+
+---
+
+ The HAL module is also a binary provided by Matrox to provide extra functionality with its XFree86 drivers for the G400/450/550 chips.  It provides support for dualhead and TV-out on G400 and DVI digital screen support on G450/550 cards.  It also allows you to use their MergedFB implementation for dualheaded cards and their powerdesk configuration utility. 
+
+You can download it [[here|http://www.matrox.com/mga/support/drivers/latest/home.cfm]].  It's included with their Linux drivers. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/HAL.moin b/HAL.moin
deleted file mode 100644
index e215b12..0000000
--- a/HAL.moin
+++ /dev/null
@@ -1,11 +0,0 @@
-== Hardware Abstraction Layer (HAL) ==
-
-Todo (Put here the generic, non-Matrox related, definition of a ''hardware abstraction layer'' --JoseFonseca)
-
-----
-The HAL module is also a binary provided by Matrox to provide extra functionality with its XFree86 drivers for the G400/450/550 chips.  It provides support for dualhead and TV-out on G400 and DVI digital screen support on G450/550 cards.  It also allows you to use their MergedFB implementation for dualheaded cards and their powerdesk configuration utility.
-
-You can download it [[http://www.matrox.com/mga/support/drivers/latest/home.cfm|here]].  It's included with their Linux drivers.
-
-----
-CategoryGlossary
diff --git a/HardwareChipsetTemplate.mdwn b/HardwareChipsetTemplate.mdwn
new file mode 100644
index 0000000..723074e
--- /dev/null
+++ b/HardwareChipsetTemplate.mdwn
@@ -0,0 +1,18 @@
+
+
+# Chipset Name
+
+
+## Status
+
+
+## Specifications
+
+
+## Resources
+
+
+
+---
+
+ [[CategoryHardwareChipset|CategoryHardwareChipset]] 
diff --git a/HardwareChipsetTemplate.moin b/HardwareChipsetTemplate.moin
deleted file mode 100644
index 77ccc09..0000000
--- a/HardwareChipsetTemplate.moin
+++ /dev/null
@@ -1,10 +0,0 @@
-= Chipset Name =
-
-== Status ==
-
-== Specifications ==
-
-== Resources ==
-
-----
-CategoryHardwareChipset
diff --git a/HardwareVendorTemplate.mdwn b/HardwareVendorTemplate.mdwn
new file mode 100644
index 0000000..c54b983
--- /dev/null
+++ b/HardwareVendorTemplate.mdwn
@@ -0,0 +1,20 @@
+
+
+# Vendor Name
+
+**Chipsets** [[!map pages="^Vendor.+"]] 
+
+
+## Status
+
+
+## Specifications
+
+
+## Resources
+
+
+
+---
+
+ [[CategoryHardwareVendor|CategoryHardwareVendor]] 
diff --git a/HardwareVendorTemplate.moin b/HardwareVendorTemplate.moin
deleted file mode 100644
index 8d09be5..0000000
--- a/HardwareVendorTemplate.moin
+++ /dev/null
@@ -1,13 +0,0 @@
-= Vendor Name =
-
-'''Chipsets'''
-<<PageList(^Vendor.+)>>
-
-== Status ==
-
-== Specifications ==
-
-== Resources ==
-
-----
-CategoryHardwareVendor
diff --git a/HardwareWithoutMipmaps.mdwn b/HardwareWithoutMipmaps.mdwn
new file mode 100644
index 0000000..42cccd7
--- /dev/null
+++ b/HardwareWithoutMipmaps.mdwn
@@ -0,0 +1,91 @@
+
+
+# Handling hardware that can't handle mipmaps
+
+To one degree or another, most older graphics chips do not support mipmaps.  Some new chips, such as the R100 family, don't support mipmaps on cubic or volume textures.  This document presents a couple different ways to deal with such hardware.  A description of each technique will be presented along with its pros and cons. 
+
+The following table summarizes the chips know to have mipmapping limitations. 
+[[!table header="no" class="mointable" data="""
+**Chip name** | **Supported by Mesa?** | **Rasterization Method** | **1D / 2D mipmaps** | **3D mipmaps** | **cubic mipmaps**
+ATI Rage IIc |  No |  Scanline |  No |  N/A |  N/A
+ATI [[RagePro|RagePro]] |  Yes |  Polygon setup |  No |  N/A |  N/A
+ATI Radeon R100 |  Yes |  TNL |  Yes |  No |  No
+ATI Radeon R200 |  Yes |  TNL |  Yes |  No |  Yes
+S3 Virge |  No* |  Scanline |  No |  N/A |  N/A
+3Dlabs 500TX |  No |  Polygon setup** |  No |  N/A |  N/A
+Matrox G100 |  No |  Scanline? |  No? |  N/A |  N/A
+"""]]
+
+* A driver exists, but it is not maintained and is know to have significant problems. 
+
+** Polygon setup is performed by a Glint Delta chip, and rasterization is performed by the 500TX.  Some (rare) cards may exist that omit the Delta, and it may be possible to circumvent the Delta and program the 500TX directly. 
+
+
+## Clamp to base LOD
+
+The easiest technique is to simply use the base LOD setting for the texture.  When selecting which mipmap to use, all of the usual variables (e.g., LOD bias, explicit baselevel setting, etc.) are considered.  Then, that single mipmap is used until either the current texture or the LOD settings are changed. 
+
+It should be noted that this technique will produce very incorrect results if the successive mipmaps are not scaled, filtered versions of the base map.  Other than programs that test the texture filtering quality of a driver, I don't know of any applications that do this, but they may exist. 
+
+Pros: 
+
+* Very easy to implement 
+* Fast 
+Cons: 
+
+* Non-conformant 
+* Low visual quality 
+
+## Fallback to software
+
+Another option is to fallback to software rasterization if a mipmapped texture filter is selected. 
+
+Pros: 
+
+* Very easy to implement 
+* Conformant 
+* High visual quality 
+Cons: 
+
+* **SLOW** 
+
+## Calculate per-polygon LOD
+
+After the points of a polygon have been transformed, clipped, lit, and transformed to screen space, the resulting data can be used to approximate the rho calculation defined by the OpenGL spec (see pages 171 and 172 of the [[OpenGL 2.0 spec|http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf]]).  For each edge in the polygon, the following calculation is performed. 
+
+   * rho = max( sqrt( sqr(du/dx) + sqr(dv/dx) + sqr(dw/dx) ), sqrt( sqr(du/dy) + sqr(dv/dy) + sqr(dw/dy) ) ) 
+Where dx and dy are the changes in screen space coordinates across the edge.  du, dv, and dw are the changes in texel addresses across the edge.  In this case, u = s * width, v = t * height, and w = r * depth.  For 1D textures, height and depth are zero.  For 2D textures, depth is zero. 
+
+On hardware that is scanline based (e.g., S3 Virge), this calculation could be done per-scaneline during rasterization.  However, other hardware limitations may make this impractical. 
+
+As an interesting side effect, this algorithm could be used to implement per-polygon anisotropic filtering.  The technique is [[described|http://www.opengl.org/resources/tutorials/advanced/advanced98/notes/node37.html]] in the SIGGRAPH '98 course [[Advanced Graphics Programming Techniques Using OpenGL|http://www.opengl.org/resources/tutorials/advanced/advanced98/notes/notes.html]]. 
+
+Marc Olano et. al. has a paper on a similar technique called [["Vertex-based Anisotropic Texturing"|http://www.csee.umbc.edu/~olano/papers/vbat/vbat.pdf]].  [[Slides|http://www.csee.umbc.edu/~olano/papers/vbat/]] are also available for the 2001 SIGGRAPH/Eurographics Workshop on Graphics Hardware presentation.  This algorithm may not be of much use here, but the paper is an interesting read either way. 
+
+Pros: 
+
+* Improved visual quality 
+* Allows "fake" anisotropic filtering 
+Cons: 
+
+* Non-conformant 
+* Difficult to implement in Mesa 
+* Sizable performance hit 
+
+## Calculate per-batch LOD
+
+This technique is just like calculating the per-polygon LOD, but the same mipmap level is used for all polygons in a batch (e.g., within a single glBegin / glEnd pair). 
+
+Pros: 
+
+* Improved visual quality 
+* Modest performance hit on non-TNL cards 
+Cons: 
+
+* Non-conformant 
+* Difficult to implement in Mesa 
+
+
+---
+
+ [[CategoryHardware|CategoryHardware]] 
diff --git a/HardwareWithoutMipmaps.moin b/HardwareWithoutMipmaps.moin
deleted file mode 100644
index 9e1effe..0000000
--- a/HardwareWithoutMipmaps.moin
+++ /dev/null
@@ -1,83 +0,0 @@
-= Handling hardware that can't handle mipmaps =
-
-To one degree or another, most older graphics chips do not support mipmaps.  Some new chips, such as the R100 family, don't support mipmaps on cubic or volume textures.  This document presents a couple different ways to deal with such hardware.  A description of each technique will be presented along with its pros and cons.
-
-The following table summarizes the chips know to have mipmapping limitations.
-
-||'''Chip name'''||'''Supported by Mesa?'''||'''Rasterization Method'''||'''1D / 2D mipmaps'''||'''3D mipmaps'''||'''cubic mipmaps'''||
-||ATI Rage IIc||<:> No||<:> Scanline||<:> No||<:> N/A||<:> N/A||
-||ATI RagePro||<:> Yes||<:> Polygon setup||<:> No||<:> N/A||<:> N/A||
-||ATI Radeon R100||<:> Yes||<:> TNL||<:> Yes||<:> No||<:> No||
-||ATI Radeon R200||<:> Yes||<:> TNL||<:> Yes||<:> No||<:> Yes||
-||S3 Virge||<:> No*||<:> Scanline||<:> No||<:> N/A||<:> N/A||
-||3Dlabs 500TX||<:> No||<:> Polygon setup**||<:> No||<:> N/A||<:> N/A||
-||Matrox G100||<:> No||<:> Scanline?||<:> No?||<:> N/A||<:> N/A||
-
-* A driver exists, but it is not maintained and is know to have significant problems.
-
-** Polygon setup is performed by a Glint Delta chip, and rasterization is performed by the 500TX.  Some (rare) cards may exist that omit the Delta, and it may be possible to circumvent the Delta and program the 500TX directly.
-
-== Clamp to base LOD ==
-
-The easiest technique is to simply use the base LOD setting for the texture.  When selecting which mipmap to use, all of the usual variables (e.g., LOD bias, explicit baselevel setting, etc.) are considered.  Then, that single mipmap is used until either the current texture or the LOD settings are changed.
-
-It should be noted that this technique will produce very incorrect results if the successive mipmaps are not scaled, filtered versions of the base map.  Other than programs that test the texture filtering quality of a driver, I don't know of any applications that do this, but they may exist.
-
-Pros:
- * Very easy to implement
- * Fast
-
-Cons:
- * Non-conformant
- * Low visual quality
-
-== Fallback to software ==
-
-Another option is to fallback to software rasterization if a mipmapped texture filter is selected.
-
-Pros:
- * Very easy to implement
- * Conformant
- * High visual quality
-
-Cons:
- * '''SLOW'''
-
-== Calculate per-polygon LOD ==
-
-After the points of a polygon have been transformed, clipped, lit, and transformed to screen space, the resulting data can be used to approximate the rho calculation defined by the OpenGL spec (see pages 171 and 172 of the [[http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf|OpenGL 2.0 spec]]).  For each edge in the polygon, the following calculation is performed.
-
-  rho = max( sqrt( sqr(du/dx) + sqr(dv/dx) + sqr(dw/dx) ), sqrt( sqr(du/dy) + sqr(dv/dy) + sqr(dw/dy) ) )
-
-Where dx and dy are the changes in screen space coordinates across the edge.  du, dv, and dw are the changes in texel addresses across the edge.  In this case, u = s * width, v = t * height, and w = r * depth.  For 1D textures, height and depth are zero.  For 2D textures, depth is zero.
-
-On hardware that is scanline based (e.g., S3 Virge), this calculation could be done per-scaneline during rasterization.  However, other hardware limitations may make this impractical.
-
-As an interesting side effect, this algorithm could be used to implement per-polygon anisotropic filtering.  The technique is [[http://www.opengl.org/resources/tutorials/advanced/advanced98/notes/node37.html|described]] in the SIGGRAPH '98 course [[http://www.opengl.org/resources/tutorials/advanced/advanced98/notes/notes.html|Advanced Graphics Programming Techniques Using OpenGL]].
-
-Marc Olano et. al. has a paper on a similar technique called [[http://www.csee.umbc.edu/~olano/papers/vbat/vbat.pdf|"Vertex-based Anisotropic Texturing"]].  [[http://www.csee.umbc.edu/~olano/papers/vbat/|Slides]] are also available for the 2001 SIGGRAPH/Eurographics Workshop on Graphics Hardware presentation.  This algorithm may not be of much use here, but the paper is an interesting read either way.
-
-Pros:
- * Improved visual quality
- * Allows "fake" anisotropic filtering
-
-Cons:
- * Non-conformant
- * Difficult to implement in Mesa
- * Sizable performance hit
-
-== Calculate per-batch LOD ==
-
-This technique is just like calculating the per-polygon LOD, but the same mipmap level is used for all polygons in a batch (e.g., within a single glBegin / glEnd pair).
-
-Pros:
- * Improved visual quality
- * Modest performance hit on non-TNL cards
-
-Cons:
- * Non-conformant
- * Difficult to implement in Mesa
-
-
-----
-CategoryHardware
diff --git a/HomepageTemplate.mdwn b/HomepageTemplate.mdwn
new file mode 100644
index 0000000..a3eccf7
--- /dev/null
+++ b/HomepageTemplate.mdwn
@@ -0,0 +1,20 @@
+
+
+## Your Name
+Email
+: ... 
+
+Homepage
+: ... 
+
+Interests
+: 
+      * ...  
+      * ... 
+
+
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/HomepageTemplate.moin b/HomepageTemplate.moin
deleted file mode 100644
index cd23433..0000000
--- a/HomepageTemplate.moin
+++ /dev/null
@@ -1,12 +0,0 @@
-== Your Name ==
-
- Email:: ...
-
- Homepage:: ...
-
- Interests::
-   * ... 
-   * ...
-
-----
-CategoryHomepage
diff --git a/IRC.mdwn b/IRC.mdwn
new file mode 100644
index 0000000..a9e0e5a
--- /dev/null
+++ b/IRC.mdwn
@@ -0,0 +1,10 @@
+
+
+# IRC
+
+
+## End-user Support
+
+The `#dri` channel on [[FreeNode|http://www.freenode.net/]] is for DRI-specific user problems.  If you have issues with downloading, building, or configuring the DRI (that aren't covered in Download, Building, or [[DriTroubleshooting|DriTroubleshooting]]), `#dri` is the place to ask.  Conversely, if you're good at fixing DRI compilation or configuration problems, you are encouraged to join `#dri` and answer questions. 
+
+[[!inline pages="IRCMeetings" quick="yes" raw="yes"]] 
diff --git a/IRC.moin b/IRC.moin
deleted file mode 100644
index 49b99ad..0000000
--- a/IRC.moin
+++ /dev/null
@@ -1,7 +0,0 @@
-= IRC =
-
-== End-user Support ==
-
-The `#dri` channel on [[http://www.freenode.net/|FreeNode]] is for DRI-specific user problems.  If you have issues with downloading, building, or configuring the DRI (that aren't covered in Download, Building, or DriTroubleshooting), `#dri` is the place to ask.  Conversely, if you're good at fixing DRI compilation or configuration problems, you are encouraged to join `#dri` and answer questions.
-
-<<Include(IRCMeetings)>>
diff --git a/IRCMeetings.moin b/IRCMeetings.mdwn
index ed1528d..7793306 100644
--- a/IRCMeetings.moin
+++ b/IRCMeetings.mdwn
@@ -1,13 +1,16 @@
-== IRC Meetings ==
-
-Weekly development meetings are held in #dri-devel on irc.freenode.net Mondays at 2100UTC (2:00PM PDT, 5:00PM EDT).  It is a general time for developers to get together and talk about current projects, make decisions faster than can occur through email, and answer each other's questions.
-
-All developers who are interested are welcome to join.
-
-Please note that the #dri-devel channel is not a technical support channel for end users, so XFree86 (Xserver/X.org) /DRI configuration and troubleshooting issues are off topic. The #xfree86 (#xorg ?), #dri, and possibly #nvidia or #ati channels are more suited to those types of discussions.
-
-=== Meeting Logs ===
-	
-Logs of all developer IRC meetings are available at http://dri.sourceforge.net/IRC-logs/ . <-- seems to be dead.
-
-IRC logs (#dri-devel/#nouveau/#radeon/#radeonhd, started from 2009-10-01) at freedesktop: [[http://people.freedesktop.org/~cbrill/dri-log/ | DRI logs]]
+
+
+## IRC Meetings
+
+Weekly development meetings are held in #dri-devel on irc.freenode.net Mondays at 2100UTC (2:00PM PDT, 5:00PM EDT).  It is a general time for developers to get together and talk about current projects, make decisions faster than can occur through email, and answer each other's questions. 
+
+All developers who are interested are welcome to join. 
+
+Please note that the #dri-devel channel is not a technical support channel for end users, so XFree86 (Xserver/X.org) /DRI configuration and troubleshooting issues are off topic. The #xfree86 (#xorg ?), #dri, and possibly #nvidia or #ati channels are more suited to those types of discussions. 
+
+
+### Meeting Logs
+
+Logs of all developer IRC meetings are available at [[http://dri.sourceforge.net/IRC-logs/|http://dri.sourceforge.net/IRC-logs/]] . <-- seems to be dead. 
+
+IRC logs (#dri-devel/#nouveau/#radeon/#radeonhd, started from 2009-10-01) at freedesktop: [[DRI logs|http://people.freedesktop.org/~cbrill/dri-log/]] 
diff --git a/IanRomanick.mdwn b/IanRomanick.mdwn
new file mode 100644
index 0000000..925a500
--- /dev/null
+++ b/IanRomanick.mdwn
@@ -0,0 +1,20 @@
+
+
+## Ian Romanick
+Email
+: idr at freedesktop dot org 
+
+Interests
+: 
+      * [[MissingFunctionality|MissingFunctionality]] 
+      * [[WorkQueue|WorkQueue]] Old interests (not that interesting): 
+      * [[PartiallyAliasedFunctions|PartiallyAliasedFunctions]] 
+      * [[DriMemoryManagerDesign|DriMemoryManagerDesign]] 
+      * [[IanRomanickToDo|IanRomanickToDo]] 
+
+
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/IanRomanick.moin b/IanRomanick.moin
deleted file mode 100644
index 6e4db4f..0000000
--- a/IanRomanick.moin
+++ /dev/null
@@ -1,15 +0,0 @@
-== Ian Romanick ==
-
- Email:: idr at freedesktop dot org
-
- Interests::
-   * MissingFunctionality
-   * WorkQueue
-
- Old interests (not that interesting):
-   * PartiallyAliasedFunctions
-   * DriMemoryManagerDesign
-   * IanRomanickToDo
-
-----
-CategoryHomepage
diff --git a/IanRomanickToDo.mdwn b/IanRomanickToDo.mdwn
new file mode 100644
index 0000000..63a71a5
--- /dev/null
+++ b/IanRomanickToDo.mdwn
@@ -0,0 +1,73 @@
+
+This is [[IanRomanick|IanRomanick]]'s rather lengthy todo list.  I basically add stuff to this list whenever I think of or find something that needs doing.  It is _not_ a list of things that I have a plan for actually doing. :) 
+
+
+
+---
+
+ 
+
+
+## General Optimization
+
+* Modify texmem interface so that mipmaps can be fragmented. The individual mipmaps don't need to be right next to each other in memory.  This could be helpful for some chips like Matrox (G200 and G400 family), SiS, and ATIRage128. 
+* Modify drivers to drop either the back-buffer or the depth-buffer if there is not enough on-card memory. The idea is that DDX driver will allocate as much memory as it can.  Hopefully there is enough for two full size buffers.  There obviously has to be enough for the front buffer.  The other buffer can be used for either the back-buffer or the depth-buffer.  It then exports visuals that use only one extra buffer normally.  Visuals that use both the back-buffer and the depth-buffer are exported as "slow."  These visuals end up being indirect only. 
+      * The radeon driver already supports a degenerate version of this, where the back buffer can be disabled.  Also, I don't see why you'd need to force the slow visuals indirect, you should be able to do them as software renderbuffers, at least for the case of no hardware back buffer.  -- [[AdamJackson|AdamJackson]] 
+* Add support for frustum culling of display lists. When a display list is compiled, generate a bounding box for it.  When the list is rendered, test the bounding box against the current view frustum.  If it's outside the view, don't render it.  This could help even HW TCL cards and should improve our [[ViewPerf|ViewPerf]] scores!  It might be possible to apply this optimization to some other cases as well (i.e., CVA and VBOs). 
+* Change the way [[GL_SGIS_generate_mipmap|http://oss.sgi.com/projects/ogl-sample/registry/SGIS/generate_mipmap.txt]] is implemented. Right now [[GL_SGIS_generate_mipmap|http://oss.sgi.com/projects/ogl-sample/registry/SGIS/generate_mipmap.txt]] is implemented by creating the mipmaps as soon as the base texture is modified.  This makes it impossible to implement support in hardware.  A better way to do it would be to keep a bit mask with one bit per level.  When the base level is modified, each of the lower levels are marked "dirty".  If the application provides a texture for a level, it gets marked "clean". At texture upload, the driver has to do something "smart" with the dirty levels. There are some tricky parts.  The app can enable mipmap generation, set the base level, disable mipmap generation, and modify the base level. In that case, the base level no longer holds the texture that should be used to generate the lower levels.  A number of solutions are available, including falling back to software generation, but I'm not sure which one is best.  It will take some experimentation. There is also the problem doing a [[CopyTexSubImage|CopyTexSubImage]] (or even [[TexSubImage|TexSubImage]]) to a hardware generated level.  This is another case where we could fallback to software. 
+
+## New / improved extension support
+
+* Add support for [[GL_SGIS_fog_function|http://oss.sgi.com/projects/ogl-sample/registry/SGIS/fog_func.txt]]. This is essentially table based fog.  For hardware that supports table based fog, we convert the app specified fog function into the fog table. 
+* Improve support for [[GL_APPLE_client_storage|http://oss.sgi.com/projects/ogl-sample/registry/APPLE/client_storage.txt]]. Right now this extension really only works as a hack in the R200 driver. However, Mesa should be able to detect if the driver format matches the source texture format.  If it is a match, Mesa should keep a pointer to the client's data instead of making a copy.  If this were done, we could get at least some benefit from the extension on all drivers. 
+* Look at adding support for [[GL_SGIX_resample|http://oss.sgi.com/projects/ogl-sample/registry/SGIX/resample.txt]], [[GL_OML_subsample|http://oss.sgi.com/projects/ogl-sample/registry/OML/subsample.txt]], [[GL_OML_resample|http://oss.sgi.com/projects/ogl-sample/registry/OML/resample.txt]], [[GL_SGIX_interlace|http://oss.sgi.com/projects/ogl-sample/registry/SGIX/interlace.txt]], [[GL_OML_interlace|http://oss.sgi.com/projects/ogl-sample/registry/OML/interlace.txt]], [[GL_INGR_interlace_read|http://oss.sgi.com/projects/ogl-sample/registry/INGR/interlace_read.txt]]. 
+* Add support for [[GL_SGIS_texture_color_mask|http://oss.sgi.com/projects/ogl-sample/registry/SGIS/texture_color_mask.txt]]. 
+* Add support for [[GL_ATI_envmap_bumpmap|http://oss.sgi.com/projects/ogl-sample/registry/ATI/envmap_bumpmap.txt]]. 
+      * **Done** in mesa [[mesa: add support for ATI_envmap_bumpmap|http://cgit.freedesktop.org/mesa/mesa/commit/?id=114152e068ec919feb0a57a1259c2ada970b9f02]] In terms of advancing OpenGL on Linux, there's no real point to implementing this extension.  However, by implementing this extension Wine can implement DirectX EMBM without having to use fragment programs. This is a good thing since the only open-source driver that supports fragment programs on the i915. 
+As another twist, it should be possible to add support to the texture_env_combine-to-fragment program conversion code for this extension.  Then any future card that supports [[GL_ARB_fragment_program|http://oss.sgi.com/projects/ogl-sample/registry/ARB/fragment_program.txt]] would automatically get support. 
+
+* Add support for [[GL_NV_texture_env_combine4|http://oss.sgi.com/projects/ogl-sample/registry/NV/texture_env_combine4.txt]]. 
+      * **Done** in mesa [[mesa: enable GL_NV_texture_env_combine4 for sw drivers|http://cgit.freedesktop.org/mesa/mesa/commit/?id=d4757cd02aeebe1a3072f35b5134ad5e278e3a6f]] I've been told that there are quite a few apps that support this extension.  That's not terribly surprising to me.  It has been supported by Nvidia hardware since the original TNT. 
+As another twist, it should be possible to add support to the texture_env_combine-to-fragment program conversion code for this extension.  Then any future card that supports [[GL_ARB_fragment_program|http://oss.sgi.com/projects/ogl-sample/registry/ARB/fragment_program.txt]] would automatically get support. 
+
+* Implement GLX_SUN_init_threads. Right now libGL dynamially determines if an application is multithreaded.  There is a small (very small) race condition in this code.  If an application were to tell libGL in advance that it was going to be multithreaded, we could completely avoid that race. What might be more interesting is to have an extension where applications could tell libGL that they were going to be exclusively single-threaded.  That way we could build specialized DRI drivers that don't do some of the locking that otherwise required.  That could help the performance of some single-threaded, CPU-bound applicattion.  At this point it may not be worth the effort.  With Hyperthreading and multicore CPUs becoming more common, more and more applications are going to be multithreaded. A [[manual page|http://www.mail-archive.com/oglbase-discuss@corp.sgi.com/msg00113.html]] for the SUN extension is available and [[Google|http://www.google.com/search?as_q=&num=50&hs=Gfx&hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&btnG=Google+Search&as_epq=&as_oq=GLX_SUN_init_threads+SUN_init_threads&as_eq=&lr=&as_ft=i&as_filetype=&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=&as_rights=&safe=images]] turns up many hits. 
+* Implement [[GL_EXT_texture_filter_anisotropic|http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_filter_anisotropic.txt]] using "rip maps" in software Mesa. [[Rip maps|http://www.sgi.com/products/software/performer/brew/anisotropic.html]] are a cheap way to implement anisotropic texture filtering.  Having some sort of anisotropic filtering in software Mesa would be nice.  As an added bonus, hardware that doesn't implement anisotropic filter could re-use most of the swrast infrastructure.  There would be some trickery involved, and the performance wouldn't be that great.  However, it _would_ be better than nothing. 
+
+## Hardware Specific
+
+* Add support to Matrox driver for storing depth-buffer in AGP memory. Starting with the G400, the depth and stencil buffers can be stored in AGP memory.  There are two things that are particularly interesting about this.  First, it can enable display modes for which there is not enough on-card memory to store the front, back, and depth buffers.  This means that 3D acceleration would be possible at 1600x1200x24-bit on a 16MB card. In addition, having the depth-buffer in AGP memory would free up on-card memory for textures.  It would be very interesting to me to see how this would impact performance of some applications. 
+* Add support for [[GL_EXT_texture_filter_anisotropic|http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_filter_anisotropic.txt]] to the Matrox driver. We already know how to enable it.  That's not the problem.  The problem is that not all G400-class hardware supports it quite right.  The G400 and G450 need to use both texture units to implement it.  The G550 does not.  The problem is that before MGA DRM 3.2 we could not tell the difference between a G4x0 and a G550.  Using the `MGA_PARAM_CARD_TYPE` parameter to `mga_getparam` we can now do this. I'd be willing to forego support for this extension on the G4x0 cards. We just need to detect the presence of a G550 and enable it there. 
+* Add support to SiS driver for storing depth-buffer in AGP memory. 
+* Add support for [[GL_ATI_envmap_bumpmap|http://oss.sgi.com/projects/ogl-sample/registry/ATI/envmap_bumpmap.txt]] to the Radeon driver. 
+* Add support for [[GL_ATI_envmap_bumpmap|http://oss.sgi.com/projects/ogl-sample/registry/ATI/envmap_bumpmap.txt]] to the R200 driver. I'm not 100% sure how this works on the R200.  I suspect that it may require a two-pass fragment shader. 
+* Add support for [[GL_ATI_envmap_bumpmap|http://oss.sgi.com/projects/ogl-sample/registry/ATI/envmap_bumpmap.txt]] to the R300 driver. The R300 can implement this via a fragment program. 
+* Add support for [[GL_ATI_envmap_bumpmap|http://oss.sgi.com/projects/ogl-sample/registry/ATI/envmap_bumpmap.txt]] to the Matrox driver. 
+* Add support for [[GL_ATI_envmap_bumpmap|http://oss.sgi.com/projects/ogl-sample/registry/ATI/envmap_bumpmap.txt]] to the SiS driver. 
+* Add support for [[GL_ATI_envmap_bumpmap|http://oss.sgi.com/projects/ogl-sample/registry/ATI/envmap_bumpmap.txt]] to the Intel (i915) driver. The i915 can implement this via a fragment program, and the i830 can implement this natively (I think). 
+* Add support for [[GL_ATI_envmap_bumpmap|http://oss.sgi.com/projects/ogl-sample/registry/ATI/envmap_bumpmap.txt]] to the [[Unichrome|CLE266]] driver. 
+* Add support for GL_MESA_ycbcr_texture to the 3dfx driver. 
+* Add support for GL_MESA_ycbcr_texture to the [[S3Virge|S3Virge]] driver (_ha-ha!_). 
+* Add support for more depth / stencil modes to the SiS driver. The file sis_reg.h leads me to believe that, in addition to the usual 16/0 and 24/8 modes, the SiS hardware can support 15/1, 32/0, 31/1, 30/2, and 28/4 modes.  Mesa can't support the 32/0 mode, but all the rest should be doable. The trick is that this would require changes to both the client-side driver and the server-side driver.  Care would be needed to prevent breaking the combination of an old client-side driver with a new server-side driver. 
+* Investigate adding support for [[GL_EXT_texture_filter_anisotropic|http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_filter_anisotropic.txt]] to the SiS driver. There are some bits in sis_reg.h (e.g., `MASK_TextureAnisotropyRatio`) that lead me to believe that the SiS hardware has some form of support for anisotropic texture filtering.  Just looking at the bits in the header file, it's not 100% clear how it might be implemented.  My guess is that the anisotropy value is converted to an integer (4.0? 3.1? 2.2?) and stored in the low 4-bits of `REG_3D_Texture[01]Mip`.  Then, `MASK_Texture0AnisotropicEnable` is set in `REG_3D_TEnable2`.  Is that it? 
+   * Using the patch at [[http://people.freedesktop.org/~anholt/sis-anisotropic.diff|http://people.freedesktop.org/~anholt/sis-anisotropic.diff]] and testing all 15 values of the aniso field using texfilt, no visual difference was seen. --[[EricAnholt|EricAnholt]] 
+* Add support for GL_EXT_texture_compression_s3tc to the SiS driver. There are bits in sis_reg.h for S3TC support. 
+* Add support for GL_ARB_texture_env_combine to the [[S3Savage|S3Savage]] driver. The [[Windows driver|http://www.delphi3d.net/hardware/viewreport.php?report=800]] supports GL_ARB_texture_env_combine, and it appears that there is enough information in savage_3d_reg.h to implement it.  The meaning of some of the bits in savageRegTexBlendCtrl will take some experimentation and guess work. 
+* Add support for mirrored texture wrap modes to the [[S3Savage|S3Savage]] driver. Savage4 has bits to support some for of mirrored texture wrapping. It's probably GL_ARB_texture_mirrored_repeat.  Investigate, implement, and test. 
+   * The wrapping field actually has only 3 documented values, all of which we use (we're cheating on clamping, as several drivers do, where we use a _CLAMP_TO_EDGE value for _CLAMP).  I tried sticking the fourth possible value of the field in in the GL_MIRRORED_REPEAT case (arbitrarily), and got the results at [[sis-badwrap.png|http://people.freedesktop.org/~anholt/savage-badwrap.png]] (top window is hardware, bottom is indirect).  Looks kinda like MIRROR_CLAMP_TO_EDGE but flipped.  Actually, the plain CLAMP wrapping shows issues on my Savage4, as you can see in the 2nd and 3rd boxes at the top. --[[EricAnholt|EricAnholt]] 
+* Add support for GL_EXT_fog_coord to the [[S3Savage|S3Savage]] driver. The [[Windows driver|http://www.delphi3d.net/hardware/viewreport.php?report=800]] supports GL_EXT_fog_coord, but I'm not quite sure that all the needed information is in savage_3d_reg.h and savage_bci.h.  It looks like savageRegFogCtrl (savage_3d_reg.h) and [[FogMode|FogMode]] (savage_bci.h) play roles, but I don't see exactly how.  There appears to be some code in the driver to support fog coordinates, but it doesn't look complete. 
+* Add support for GL_ARB_point_parameters to the [[S3Savage|S3Savage]] driver. The [[Windows driver|http://www.delphi3d.net/hardware/viewreport.php?report=800]] supports GL_EXT_point_parameters (and the ARB version is virtually identical).  It doesn't look like the Savage hardware can do points at all.  My guess is that large points will have to be converted to polygons of some sort. 
+* Add support for 1-bit stencil buffer to [[S3Savage|S3Savage]] driver (Savage3D) The only stencil configuration that the old Savage3D can support is a 15/1 depth/stencil mode.  There is currently no support for it, but there should be.  The Savage4 may also support this mode, but it's not entirely clear from looking at the code or headers. 
+* Enhance the set of used texture formats in the [[S3Savage|S3Savage]] driver. The Savage4 hardware (and a few others) can directly support `GL_LUMINANCE4_ALPHA4` (`TFT_A4L4`).  This may require some changes to core Mesa. Some Savage4 hardware can also directly support `GL_INTENSITY8` (`TFT_I8`).  Code will need to be added to detect hardware that is known to support it correctly, and only use that mode on that hardware. 
+* Investigate texture filter modes in the [[Unichrome|CLE266]] driver. The file via_3d_reg.h has some interesting bits in the `HC_HTXnFL*` group.  The most intersting are `HC_HTXnFLSe_Sharp` (could be related to SGIS_sharpen_texture), `HC_HTXnFLSe_Flat_Gaussian_Cubic`, and `HC_HTXnFLDs_Ani`.  In any case, it would be useful to figure out what all the various bits do (by way of experimentation) and document it in the header file. 
+* Add support for GL_EXT_blend_func_separate to the [[Unichrome|CLE266]] driver. 
+* Add support for GL_EXT_blend_color to the [[Unichrome|CLE266]] driver. It appears that the blend color could be supported the same way that `GL_ZERO` and `GL_ONE` are supported. 
+* Add support for GL_EXT_blend_minmax to the [[Unichrome|CLE266]] driver. It looks like setting the source blend factor to 1, the destination blend factor to 0, and using `HC_HABLCa_maxSrcDst` or `HC_HABLCa_minSrcDst` should do the trick. 
+* Add support for GL_EXT_blend_equation_separate to the [[Unichrome|CLE266]] driver. Once support for GL_EXT_blend_minmax is added, support for this extension can also be added. 
+* Add support for GL_EXT_blend_subtract to the [[Unichrome|CLE266]] driver. The [[Windows drivers|http://www.delphi3d.net/hardware/viewreport.php?report=962]] supports this on KM400 / KN400 (and later?) chips. It's not 100% clear to me how this might be done, but there are some posabilities that need to be explored.  On thing to try would be the `HC_HALBCbias_*` values.  Another thing to try would be `HC_XC_OPCp5` (or using a 3 for that value instead of 2). The last obvious thing to try is `HC_HABLCop_MASK`.  This could toggle add and subtract mode.  A separate "subtract reverse" mode isn't needed because the hardware is flexable enough to just switch the operands.  I actually think that this is the most likely candidate. 
+* Add support for [[GL_EXT_texture_filter_anisotropic|http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_filter_anisotropic.txt]] to the Intel (i810) driver. Looking at i810_3d_reg.h, it appears that the i810 can do the same sort of anisotropic filtering that the i830 can. 
+* Add support for GL_ATI_texture_env_combine3 to the Intel (i810) driver. This is a little tricky, but it should be mostly doable.  The i810 has two texture units, but 3 texture combine stages.  All of the extra operations can be split into two operations.  As long as a new op is only used in one of the texture units, it should be fine. 
+* Add support for GL_EXT_secondary_color to the Intel (i810) driver. 
+* Add support for GL_EXT_fog_coord to the Intel (i810) driver. 
+* Add support for GL_ATI_texture_env_combine3 to the Intel (i830) driver. The driver can natively do `GL_MODULATE_ADD_ATI`.  The other modes can be emulated by using multiple combine stages. 
+* Optimize generation of texture combine stages in the Intel (i830) driver. The i830 has several `MODULATE_AND_ADD` modes and a `BLEND_AND_ADD` mode. These can be used to use fewer combine stages.  By itself this isn't useful.  However, it can be used to free up instruction slots for texture environments that are expanded by GL_ATI_texture_env_combine3 support. 
+* Investigate the "missing" combine modes in the Intel (i830) driver. In the defines for the texture combine modes, there is a gap between `TEXBLENDOP_MODULATE` and `TEXBLENDOP_ADD`.  The odds are pretty good that these missing values do *something*.  The trick is to figure out what they do and if it's useful. 
+\ No newline at end of file
diff --git a/IanRomanickToDo.moin b/IanRomanickToDo.moin
deleted file mode 100644
index 976d087..0000000
--- a/IanRomanickToDo.moin
+++ /dev/null
@@ -1,196 +0,0 @@
-This is IanRomanick's rather lengthy todo list.  I basically add stuff to this list whenever I think of or find something that needs doing.  It is ''not'' a list of things that I have a plan for actually doing. :)
-
-----
-
-== General Optimization ==
-
- * Modify texmem interface so that mipmaps can be fragmented.
-
- The individual mipmaps don't need to be right next to each other in memory.  This could be helpful for some chips like Matrox (G200 and G400 family), SiS, and ATIRage128.
-
- * Modify drivers to drop either the back-buffer or the depth-buffer if there is not enough on-card memory.
-
- The idea is that DDX driver will allocate as much memory as it can.  Hopefully there is enough for two full size buffers.  There obviously has to be enough for the front buffer.  The other buffer can be used for either the back-buffer or the depth-buffer.  It then exports visuals that use only one extra buffer normally.  Visuals that use both the back-buffer and the depth-buffer are exported as "slow."  These visuals end up being indirect only.
-   * The radeon driver already supports a degenerate version of this, where the back buffer can be disabled.  Also, I don't see why you'd need to force the slow visuals indirect, you should be able to do them as software renderbuffers, at least for the case of no hardware back buffer.  -- AdamJackson
-
- * Add support for frustum culling of display lists.
-
- When a display list is compiled, generate a bounding box for it.  When the list is rendered, test the bounding box against the current view frustum.  If it's outside the view, don't render it.  This could help even HW TCL cards and should improve our ViewPerf scores!  It might be possible to apply this optimization to some other cases as well (i.e., CVA and VBOs).
-
- * Change the way [[http://oss.sgi.com/projects/ogl-sample/registry/SGIS/generate_mipmap.txt|GL_SGIS_generate_mipmap]] is implemented.
-
- Right now [[http://oss.sgi.com/projects/ogl-sample/registry/SGIS/generate_mipmap.txt|GL_SGIS_generate_mipmap]] is implemented by creating the mipmaps as soon as the base texture is modified.  This makes it impossible to implement support in hardware.  A better way to do it would be to keep a bit mask with one bit per level.  When the base level is modified, each of the lower levels are marked "dirty".  If the application provides a texture for a level, it gets marked "clean". At texture upload, the driver has to do something "smart" with the dirty levels.
-
- There are some tricky parts.  The app can enable mipmap generation, set the base level, disable mipmap generation, and modify the base level. In that case, the base level no longer holds the texture that should be used to generate the lower levels.  A number of solutions are available, including falling back to software generation, but I'm not sure which one is best.  It will take some experimentation.
-
- There is also the problem doing a CopyTexSubImage (or even TexSubImage) to a hardware generated level.  This is another case where we could fallback to software.
-
-== New / improved extension support ==
-
- * Add support for [[http://oss.sgi.com/projects/ogl-sample/registry/SGIS/fog_func.txt|GL_SGIS_fog_function]].
-
- This is essentially table based fog.  For hardware that supports table based fog, we convert the app specified fog function into the fog table.
-
- * Improve support for [[http://oss.sgi.com/projects/ogl-sample/registry/APPLE/client_storage.txt|GL_APPLE_client_storage]].
-
- Right now this extension really only works as a hack in the R200 driver. However, Mesa should be able to detect if the driver format matches the source texture format.  If it is a match, Mesa should keep a pointer to the client's data instead of making a copy.  If this were done, we could get at least some benefit from the extension on all drivers.
-
- * Look at adding support for [[http://oss.sgi.com/projects/ogl-sample/registry/SGIX/resample.txt|GL_SGIX_resample]], [[http://oss.sgi.com/projects/ogl-sample/registry/OML/subsample.txt|GL_OML_subsample]], [[http://oss.sgi.com/projects/ogl-sample/registry/OML/resample.txt|GL_OML_resample]], [[http://oss.sgi.com/projects/ogl-sample/registry/SGIX/interlace.txt|GL_SGIX_interlace]], [[http://oss.sgi.com/projects/ogl-sample/registry/OML/interlace.txt|GL_OML_interlace]], [[http://oss.sgi.com/projects/ogl-sample/registry/INGR/interlace_read.txt|GL_INGR_interlace_read]].
-
- * Add support for [[http://oss.sgi.com/projects/ogl-sample/registry/SGIS/texture_color_mask.txt|GL_SGIS_texture_color_mask]].
-
- * Add support for [[http://oss.sgi.com/projects/ogl-sample/registry/ATI/envmap_bumpmap.txt|GL_ATI_envmap_bumpmap]].
-   '''Done''' in mesa [[http://cgit.freedesktop.org/mesa/mesa/commit/?id=114152e068ec919feb0a57a1259c2ada970b9f02|mesa: add support for ATI_envmap_bumpmap]]
-
- In terms of advancing OpenGL on Linux, there's no real point to implementing this extension.  However, by implementing this extension Wine can implement DirectX EMBM without having to use fragment programs. This is a good thing since the only open-source driver that supports fragment programs on the i915.
-
- As another twist, it should be possible to add support to the texture_env_combine-to-fragment program conversion code for this extension.  Then any future card that supports [[http://oss.sgi.com/projects/ogl-sample/registry/ARB/fragment_program.txt|GL_ARB_fragment_program]] would automatically get support.
-
- * Add support for [[http://oss.sgi.com/projects/ogl-sample/registry/NV/texture_env_combine4.txt|GL_NV_texture_env_combine4]].
-   '''Done''' in mesa [[http://cgit.freedesktop.org/mesa/mesa/commit/?id=d4757cd02aeebe1a3072f35b5134ad5e278e3a6f|mesa: enable GL_NV_texture_env_combine4 for sw drivers]]
-
- I've been told that there are quite a few apps that support this extension.  That's not terribly surprising to me.  It has been supported by Nvidia hardware since the original TNT.
-
- As another twist, it should be possible to add support to the texture_env_combine-to-fragment program conversion code for this extension.  Then any future card that supports [[http://oss.sgi.com/projects/ogl-sample/registry/ARB/fragment_program.txt|GL_ARB_fragment_program]] would automatically get support.
-
- * Implement GLX_SUN_init_threads.
-
- Right now libGL dynamially determines if an application is multithreaded.  There is a small (very small) race condition in this code.  If an application were to tell libGL in advance that it was going to be multithreaded, we could completely avoid that race.
-
- What might be more interesting is to have an extension where applications could tell libGL that they were going to be exclusively single-threaded.  That way we could build specialized DRI drivers that don't do some of the locking that otherwise required.  That could help the performance of some single-threaded, CPU-bound applicattion.  At this point it may not be worth the effort.  With Hyperthreading and multicore CPUs becoming more common, more and more applications are going to be multithreaded.
-
- A [[http://www.mail-archive.com/oglbase-discuss@corp.sgi.com/msg00113.html|manual page]] for the SUN extension is available and [[http://www.google.com/search?as_q=&num=50&hs=Gfx&hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&btnG=Google+Search&as_epq=&as_oq=GLX_SUN_init_threads+SUN_init_threads&as_eq=&lr=&as_ft=i&as_filetype=&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=&as_rights=&safe=images|Google]] turns up many hits.
-
- * Implement [[http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_filter_anisotropic.txt|GL_EXT_texture_filter_anisotropic]] using "rip maps" in software Mesa.
-
- [[http://www.sgi.com/products/software/performer/brew/anisotropic.html|Rip maps]] are a cheap way to implement anisotropic texture filtering.  Having some sort of anisotropic filtering in software Mesa would be nice.  As an added bonus, hardware that doesn't implement anisotropic filter could re-use most of the swrast infrastructure.  There would be some trickery involved, and the performance wouldn't be that great.  However, it ''would'' be better than nothing.
-
-== Hardware Specific ==
-
- * Add support to Matrox driver for storing depth-buffer in AGP memory.
-
- Starting with the G400, the depth and stencil buffers can be stored in AGP memory.  There are two things that are particularly interesting about this.  First, it can enable display modes for which there is not enough on-card memory to store the front, back, and depth buffers.  This means that 3D acceleration would be possible at 1600x1200x24-bit on a 16MB card.
-
- In addition, having the depth-buffer in AGP memory would free up on-card memory for textures.  It would be very interesting to me to see how this would impact performance of some applications.
-
- * Add support for [[http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_filter_anisotropic.txt|GL_EXT_texture_filter_anisotropic]] to the Matrox driver.
-
- We already know how to enable it.  That's not the problem.  The problem is that not all G400-class hardware supports it quite right.  The G400 and G450 need to use both texture units to implement it.  The G550 does not.  The problem is that before MGA DRM 3.2 we could not tell the difference between a G4x0 and a G550.  Using the `MGA_PARAM_CARD_TYPE` parameter to `mga_getparam` we can now do this.
-
- I'd be willing to forego support for this extension on the G4x0 cards. We just need to detect the presence of a G550 and enable it there.
-
- * Add support to SiS driver for storing depth-buffer in AGP memory.
-
- * Add support for [[http://oss.sgi.com/projects/ogl-sample/registry/ATI/envmap_bumpmap.txt|GL_ATI_envmap_bumpmap]] to the Radeon driver.
-
- * Add support for [[http://oss.sgi.com/projects/ogl-sample/registry/ATI/envmap_bumpmap.txt|GL_ATI_envmap_bumpmap]] to the R200 driver.
-
- I'm not 100% sure how this works on the R200.  I suspect that it may require a two-pass fragment shader.
-
- * Add support for [[http://oss.sgi.com/projects/ogl-sample/registry/ATI/envmap_bumpmap.txt|GL_ATI_envmap_bumpmap]] to the R300 driver.
-
- The R300 can implement this via a fragment program.
-
- * Add support for [[http://oss.sgi.com/projects/ogl-sample/registry/ATI/envmap_bumpmap.txt|GL_ATI_envmap_bumpmap]] to the Matrox driver.
-
- * Add support for [[http://oss.sgi.com/projects/ogl-sample/registry/ATI/envmap_bumpmap.txt|GL_ATI_envmap_bumpmap]] to the SiS driver.
-
- * Add support for [[http://oss.sgi.com/projects/ogl-sample/registry/ATI/envmap_bumpmap.txt|GL_ATI_envmap_bumpmap]] to the Intel (i915) driver.
-
- The i915 can implement this via a fragment program, and the i830 can implement this natively (I think).
-
- * Add support for [[http://oss.sgi.com/projects/ogl-sample/registry/ATI/envmap_bumpmap.txt|GL_ATI_envmap_bumpmap]] to the [[CLE266|Unichrome]] driver.
-
- * Add support for GL_MESA_ycbcr_texture to the 3dfx driver.
-
- * Add support for GL_MESA_ycbcr_texture to the S3Virge driver (''ha-ha!'').
-
- * Add support for more depth / stencil modes to the SiS driver.
-
- The file sis_reg.h leads me to believe that, in addition to the usual 16/0 and 24/8 modes, the SiS hardware can support 15/1, 32/0, 31/1, 30/2, and 28/4 modes.  Mesa can't support the 32/0 mode, but all the rest should be doable.
-
- The trick is that this would require changes to both the client-side driver and the server-side driver.  Care would be needed to prevent breaking the combination of an old client-side driver with a new server-side driver.
-
- * Investigate adding support for [[http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_filter_anisotropic.txt|GL_EXT_texture_filter_anisotropic]] to the SiS driver.
-
- There are some bits in sis_reg.h (e.g., `MASK_TextureAnisotropyRatio`) that lead me to believe that the SiS hardware has some form of support for anisotropic texture filtering.  Just looking at the bits in the header file, it's not 100% clear how it might be implemented.  My guess is that the anisotropy value is converted to an integer (4.0? 3.1? 2.2?) and stored in the low 4-bits of `REG_3D_Texture[01]Mip`.  Then, `MASK_Texture0AnisotropicEnable` is set in `REG_3D_TEnable2`.  Is that it?
-  * Using the patch at [[http://people.freedesktop.org/~anholt/sis-anisotropic.diff]] and testing all 15 values of the aniso field using texfilt, no visual difference was seen. --EricAnholt
-
- * Add support for GL_EXT_texture_compression_s3tc to the SiS driver.
-
- There are bits in sis_reg.h for S3TC support.
-
- * Add support for GL_ARB_texture_env_combine to the S3Savage driver.
-
- The [[http://www.delphi3d.net/hardware/viewreport.php?report=800|Windows driver]] supports GL_ARB_texture_env_combine, and it appears that there is enough information in savage_3d_reg.h to implement it.  The meaning of some of the bits in savageRegTexBlendCtrl will take some experimentation and guess work.
-
- * Add support for mirrored texture wrap modes to the S3Savage driver.
-
- Savage4 has bits to support some for of mirrored texture wrapping. It's probably GL_ARB_texture_mirrored_repeat.  Investigate, implement, and test.
-  * The wrapping field actually has only 3 documented values, all of which we use (we're cheating on clamping, as several drivers do, where we use a _CLAMP_TO_EDGE value for _CLAMP).  I tried sticking the fourth possible value of the field in in the GL_MIRRORED_REPEAT case (arbitrarily), and got the results at [[http://people.freedesktop.org/~anholt/savage-badwrap.png|sis-badwrap.png]] (top window is hardware, bottom is indirect).  Looks kinda like MIRROR_CLAMP_TO_EDGE but flipped.  Actually, the plain CLAMP wrapping shows issues on my Savage4, as you can see in the 2nd and 3rd boxes at the top. --EricAnholt
-
- * Add support for GL_EXT_fog_coord to the S3Savage driver.
-
- The [[http://www.delphi3d.net/hardware/viewreport.php?report=800|Windows driver]] supports GL_EXT_fog_coord, but I'm not quite sure that all the needed information is in savage_3d_reg.h and savage_bci.h.  It looks like savageRegFogCtrl (savage_3d_reg.h) and FogMode (savage_bci.h) play roles, but I don't see exactly how.  There appears to be some code in the driver to support fog coordinates, but it doesn't look complete.
-
- * Add support for GL_ARB_point_parameters to the S3Savage driver.
-
- The [[http://www.delphi3d.net/hardware/viewreport.php?report=800|Windows driver]] supports GL_EXT_point_parameters (and the ARB version is virtually identical).  It doesn't look like the Savage hardware can do points at all.  My guess is that large points will have to be converted to polygons of some sort.
-
- * Add support for 1-bit stencil buffer to S3Savage driver (Savage3D)
-
- The only stencil configuration that the old Savage3D can support is a 15/1 depth/stencil mode.  There is currently no support for it, but there should be.  The Savage4 may also support this mode, but it's not entirely clear from looking at the code or headers.
-
- * Enhance the set of used texture formats in the S3Savage driver.
-
- The Savage4 hardware (and a few others) can directly support `GL_LUMINANCE4_ALPHA4` (`TFT_A4L4`).  This may require some changes to core Mesa.
-
- Some Savage4 hardware can also directly support `GL_INTENSITY8` (`TFT_I8`).  Code will need to be added to detect hardware that is known to support it correctly, and only use that mode on that hardware.
-
- * Investigate texture filter modes in the [[CLE266|Unichrome]] driver.
-
- The file via_3d_reg.h has some interesting bits in the `HC_HTXnFL*` group.  The most intersting are `HC_HTXnFLSe_Sharp` (could be related to SGIS_sharpen_texture), `HC_HTXnFLSe_Flat_Gaussian_Cubic`, and `HC_HTXnFLDs_Ani`.  In any case, it would be useful to figure out what all the various bits do (by way of experimentation) and document it in the header file.
-
- * Add support for GL_EXT_blend_func_separate to the [[CLE266|Unichrome]] driver.
-
- * Add support for GL_EXT_blend_color to the [[CLE266|Unichrome]] driver.
-
- It appears that the blend color could be supported the same way that `GL_ZERO` and `GL_ONE` are supported.
-
- * Add support for GL_EXT_blend_minmax to the [[CLE266|Unichrome]] driver.
-
- It looks like setting the source blend factor to 1, the destination blend factor to 0, and using `HC_HABLCa_maxSrcDst` or `HC_HABLCa_minSrcDst` should do the trick.
-
- * Add support for GL_EXT_blend_equation_separate to the [[CLE266|Unichrome]] driver.
-
- Once support for GL_EXT_blend_minmax is added, support for this extension can also be added.
-
- * Add support for GL_EXT_blend_subtract to the [[CLE266|Unichrome]] driver.
-
- The [[http://www.delphi3d.net/hardware/viewreport.php?report=962|Windows drivers]] supports this on KM400 / KN400 (and later?) chips. It's not 100% clear to me how this might be done, but there are some posabilities that need to be explored.  On thing to try would be the `HC_HALBCbias_*` values.  Another thing to try would be `HC_XC_OPCp5` (or using a 3 for that value instead of 2).
-
- The last obvious thing to try is `HC_HABLCop_MASK`.  This could toggle add and subtract mode.  A separate "subtract reverse" mode isn't needed because the hardware is flexable enough to just switch the operands.  I actually think that this is the most likely candidate.
-
- * Add support for [[http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_filter_anisotropic.txt|GL_EXT_texture_filter_anisotropic]] to the Intel (i810) driver.
-
- Looking at i810_3d_reg.h, it appears that the i810 can do the same sort of anisotropic filtering that the i830 can.
-
- * Add support for GL_ATI_texture_env_combine3 to the Intel (i810) driver.
-
- This is a little tricky, but it should be mostly doable.  The i810 has two texture units, but 3 texture combine stages.  All of the extra operations can be split into two operations.  As long as a new op is only used in one of the texture units, it should be fine.
-
- * Add support for GL_EXT_secondary_color to the Intel (i810) driver.
-
- * Add support for GL_EXT_fog_coord to the Intel (i810) driver.
-
- * Add support for GL_ATI_texture_env_combine3 to the Intel (i830) driver.
-
- The driver can natively do `GL_MODULATE_ADD_ATI`.  The other modes can be emulated by using multiple combine stages.
-
- * Optimize generation of texture combine stages in the Intel (i830) driver.
-
- The i830 has several `MODULATE_AND_ADD` modes and a `BLEND_AND_ADD` mode. These can be used to use fewer combine stages.  By itself this isn't useful.  However, it can be used to free up instruction slots for texture environments that are expanded by GL_ATI_texture_env_combine3 support.
-
- * Investigate the "missing" combine modes in the Intel (i830) driver.
-
- In the defines for the texture combine modes, there is a gap between `TEXBLENDOP_MODULATE` and `TEXBLENDOP_ADD`.  The odds are pretty good that these missing values do *something*.  The trick is to figure out what they do and if it's useful.
diff --git a/IndirectRendering.mdwn b/IndirectRendering.mdwn
new file mode 100644
index 0000000..fd934a2
--- /dev/null
+++ b/IndirectRendering.mdwn
@@ -0,0 +1,16 @@
+
+
+# Indirect Rendering
+
+When OpenGL commands are packaged up with the GLX library and transported across a network pipe (even if that network pipe is local) it is termed Indirect Rendering. 
+
+
+## Status
+
+Indirect rendering is accelerated via the DRI driver as of Xorg 7.1. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]], [[CategoryHelpWanted|CategoryHelpWanted]] 
diff --git a/IndirectRendering.moin b/IndirectRendering.moin
deleted file mode 100644
index c28d2f3..0000000
--- a/IndirectRendering.moin
+++ /dev/null
@@ -1,12 +0,0 @@
-= Indirect Rendering =
-
-When OpenGL commands are packaged up with the GLX library and transported
-across a network pipe (even if that network pipe is local) it is termed
-Indirect Rendering.
-
-== Status ==
-
-Indirect rendering is accelerated via the DRI driver as of Xorg 7.1.
-
-----
-CategoryGlossary, CategoryHelpWanted
diff --git a/Intel.mdwn b/Intel.mdwn
new file mode 100644
index 0000000..31ef2f1
--- /dev/null
+++ b/Intel.mdwn
@@ -0,0 +1,95 @@
+
+
+# Intel
+
+**Chipsets** [[!map pages="^Intel.+"]] 
+
+
+## Status
+
+Supported chipsets: 
+
+   * i810 
+   * i810-dc100 
+   * i810e 
+   * i810e2 
+   * i815 
+   * i815e 
+   * i830G 
+   * i845G 
+   * i852/855 
+   * i865G 
+   * i915G/i915GM/i915GMS 
+   * i945G/i945GM (includes GMA 950, GMA 3000, GMA 3100) 
+   * i965G, G3x, G4x (includes GMA X3000, GMA X3100, GMA X3500, GMA X4500) 
+Unsupported old chips: 
+
+   * i740.  Intel [[claimed|http://web.archive.org/web/20041031000647/http://www.intel.com/support/graphics/sb/cs-004535-prd39.htm]] to have a Software Developer's Manual (order number 290617) available for this chip, but it is not posted on the website anywhere.  The datasheet is available [[here|http://support.intel.com/support/graphics/intel740/]], but this is a feature list only and is not useful for programming a DRI driver.  The i740 appears to be the i810 minus multitexturing and anisotropic mipmap filtering, with slightly different register locations. 
+   * i752.  Brief-lived successor to the i740, and may in fact be identical to the i810. 
+
+## Specifications
+
+Specifications for a few Intel chipsets are publicly available on its developer site. 
+
+There are complete Programmer's Reference Manuals including register descriptions for the [[i810|http://www.intel.com/design/chipsets/manuals/298026.htm/]] and the [[i815|http://www.intel.com/design/chipsets/manuals/298237.htm/]]. 
+
+Programmer's Reference Manuals for both generations of the i965 family are available on the [[Intel driver development site|http://intellinuxgraphics.org/documentation.html]]. 
+
+For the other chips, have a look at the datasheets for various versions of the Graphics and Memory Controller Hub (eg. for the i830, look at  82830 GMCH-M, etc.). 
+
+Here is an attempt to collect information about some [[IntelRegisters|IntelRegisters]] for those chips. 
+
+
+## Chip Information
+
+The Intel chipsets can be split into 4 categories at this stage.  
+
+   1. i810/i815 family 
+   1. i8xx 
+   1. i915/945 family 
+   1. i965 family 
+Intel produces motherboard chipsets with and without integrated graphics functionality. The chipsets also commonly allow for an external graphics adapter to be used in-place of the integrated functionality (AGP or PCI-E). The chipsets containing integrated graphics always seem to be have a G in the name. (e.g. 865G, 915G and 945G). These are normally the desktop targeted graphics chips. Later a mobile targeted version is usually released tagged with a GM (i915GM and 945GM). Post the GM series things can be a bit murky, but normally a GMS version of the chip can be released which is also mobile targeted but with maybe less power or more features 
+
+
+## i8xx
+
+The i8xx chipset supported AGP graphics cards. The integrated graphics functionality is disabled when an external AGP card is detected. The i8xx used DVO (Digitial Video Out) ports to talk to external chips (TMDS, LVDS and TV-Out). The control interface used i2c. These DVO ports were multiplexed via the AGP connector and could be used by an ADD card. The external chips used on ADD cards were also used by other manufactures to provide functionality on their graphics systems (e.g VIA could use ADD cards, and some radeons had silicon image DVI chips). The i8xx had separate DDC i2c channels for external devices. 
+[[!table header="no" class="mointable" data="""
+ Chipset  |  Pipes  |  Analog  |  DVOs  |  LVDS  |  TV-OUT  |  TMDS (DVI) 
+ 830M/MG  |  2  |  Y  |  A/B/C  |  N  |  N  |  N 
+ 845G/GE  |  1  |  Y  |  B/C  |  N  |  N  |  N 
+ 852GM  |  2  |  Y  |  C  |  B  |  N  |  N 
+ 855GM/GME  |  2  |  Y  |  B/C  |  B  |  N  |  N 
+ 865G  |  1  |  Y  |  B/C  |  N  |  N  |  N 
+"""]]
+
+
+## i915/i945
+
+The i915/i945 chipsets support PCI-Express graphics cards. The integrated functionality is disabled when an external PCI-E card is detected. The i9xx use sDVO (Serial Digital Video Out) ports to talk to external chips (TMDS, LVDS and TV-Out). The control interface is the sDVO protocol, which runs on top of a standard i2c link. The sDVO ports are multiplexed with the PCI-Express and can be used via ADD2 or ADD2+ cards. The external chips are currently used with Intel hw only. The i9xx has a point to point connection over i2c to control the external chips, the external chips must switch the i2c bus to allow access to monitor DDC or ADD2 PROMs. 
+[[!table header="no" class="mointable" data="""
+ Chipset  |  Pipes  |  Analog  |  DVOs  |  LVDS  |  TV-OUT  |  TMDS (DVI) 
+ 915G  |  2  |  Y  |  B/C  |  N  |  N  |  N 
+ 915GM/GMS  |   2  |  Y  |  B/C  |  Y  |  Y  |  N 
+ 945G  |  2  |  Y  |  B/C  |  N  |  N  |  N 
+"""]]
+
+t Also GMA 3000 / 3100 (without "X") are in this family. 
+
+
+## i965
+
+i965 is a new graphics architecture, present in chipsets 965G, G31, G33, G35 and the new G4x series. It goes by the marketing names GMA X3000, GMA X3100, GMA X3500 and GMA X4500, ie. everything with an "X" in it. 
+
+They support OpenGL 2.0, ie. full GLSL shading language support etc. is available in Mesa 7.0.4 release and above. 
+
+
+## Resources
+
+   * [[Intel driver development site|http://intellinuxgraphics.org/]] 
+   * [[Intel's general developer site|http://developer.intel.com/]] 
+
+
+---
+
+ [[CategoryHardwareVendor|CategoryHardwareVendor]] [[CategoryHelpWanted|CategoryHelpWanted]] 
diff --git a/Intel.moin b/Intel.moin
deleted file mode 100644
index a39dda1..0000000
--- a/Intel.moin
+++ /dev/null
@@ -1,90 +0,0 @@
-= Intel =
-
-'''Chipsets'''
-<<PageList(^Intel.+)>>
-
-== Status ==
-
-Supported chipsets:
-  * i810
-  * i810-dc100
-  * i810e
-  * i810e2
-  * i815
-  * i815e
-  * i830G
-  * i845G
-  * i852/855
-  * i865G
-  * i915G/i915GM/i915GMS
-  * i945G/i945GM (includes GMA 950, GMA 3000, GMA 3100)
-  * i965G, G3x, G4x (includes GMA X3000, GMA X3100, GMA X3500, GMA X4500)
-
-Unsupported old chips:
-  * i740.  Intel [[http://web.archive.org/web/20041031000647/http://www.intel.com/support/graphics/sb/cs-004535-prd39.htm|claimed]] to have a Software Developer's Manual (order number 290617) available for this chip, but it is not posted on the website anywhere.  The datasheet is available [[http://support.intel.com/support/graphics/intel740/|here]], but this is a feature list only and is not useful for programming a DRI driver.  The i740 appears to be the i810 minus multitexturing and anisotropic mipmap filtering, with slightly different register locations.
-  * i752.  Brief-lived successor to the i740, and may in fact be identical to the i810.
-
-== Specifications ==
-
-Specifications for a few Intel chipsets are publicly available on its developer site.
-
-There are complete Programmer's Reference Manuals including register
-descriptions
-for the [[http://www.intel.com/design/chipsets/manuals/298026.htm/|i810]]
-and the [[http://www.intel.com/design/chipsets/manuals/298237.htm/|i815]].
-
-Programmer's Reference Manuals for both generations of the i965 family are available
-on the [[http://intellinuxgraphics.org/documentation.html|Intel driver development site]].
-
-For the other chips, have a look at the datasheets for various versions of
-the Graphics and Memory Controller Hub (eg. for the i830, look at 
-82830 GMCH-M, etc.).
-
-Here is an attempt to collect information about some [[IntelRegisters]] for those chips.
-
-== Chip Information ==
-
-The Intel chipsets can be split into 4 categories at this stage. 
-
-  1. i810/i815 family
-  2. i8xx
-  3. i915/945 family
-  4. i965 family
-
-Intel produces motherboard chipsets with and without integrated graphics functionality. The chipsets also commonly allow for an external graphics adapter to be used in-place of the integrated functionality (AGP or PCI-E). The chipsets containing integrated graphics always seem to be have a G in the name. (e.g. 865G, 915G and 945G). These are normally the desktop targeted graphics chips. Later a mobile targeted version is usually released tagged with a GM (i915GM and 945GM). Post the GM series things can be a bit murky, but normally a GMS version of the chip can be released which is also mobile targeted but with maybe less power or more features
-
-== i8xx ==
-
-The i8xx chipset supported AGP graphics cards. The integrated graphics functionality is disabled when an external AGP card is detected. The i8xx used DVO (Digitial Video Out) ports to talk to external chips (TMDS, LVDS and TV-Out). The control interface used i2c. These DVO ports were multiplexed via the AGP connector and could be used by an ADD card. The external chips used on ADD cards were also used by other manufactures to provide functionality on their graphics systems (e.g VIA could use ADD cards, and some radeons had silicon image DVI chips). The i8xx had separate DDC i2c channels for external devices.
-
-|| Chipset || Pipes || Analog || DVOs || LVDS || TV-OUT || TMDS (DVI) ||
-|| 830M/MG || 2 || Y || A/B/C || N || N || N ||
-|| 845G/GE || 1 || Y || B/C || N || N || N ||
-|| 852GM || 2 || Y || C || B || N || N ||
-|| 855GM/GME || 2 || Y || B/C || B || N || N ||
-|| 865G || 1 || Y || B/C || N || N || N ||
-
-== i915/i945 ==
-
-The i915/i945 chipsets support PCI-Express graphics cards. The integrated functionality is disabled when an external PCI-E card is detected. The i9xx use sDVO (Serial Digital Video Out) ports to talk to external chips (TMDS, LVDS and TV-Out). The control interface is the sDVO protocol, which runs on top of a standard i2c link. The sDVO ports are multiplexed with the PCI-Express and can be used via ADD2 or ADD2+ cards. The external chips are currently used with Intel hw only. The i9xx has a point to point connection over i2c to control the external chips, the external chips must switch the i2c bus to allow access to monitor DDC or ADD2 PROMs.
-
-|| Chipset || Pipes || Analog || DVOs || LVDS || TV-OUT || TMDS (DVI) ||
-|| 915G || 2 || Y || B/C || N || N || N ||
-|| 915GM/GMS ||  2 || Y || B/C || Y || Y || N ||
-|| 945G || 2 || Y || B/C || N || N || N ||
-t
-Also GMA 3000 / 3100 (without "X") are in this family.
-
-== i965 ==
-
-i965 is a new graphics architecture, present in chipsets 965G, G31, G33, G35 and the new G4x series. It goes by the marketing names GMA X3000, GMA X3100, GMA X3500 and GMA X4500, ie. everything with an "X" in it.
-
-They support OpenGL 2.0, ie. full GLSL shading language support etc. is available in Mesa 7.0.4 release and above.
-
-== Resources ==
-
-  * [[http://intellinuxgraphics.org/|Intel driver development site]]
-  * [[http://developer.intel.com/|Intel's general developer site]]
-
-----
-CategoryHardwareVendor CategoryHelpWanted
diff --git a/IntelGL.moin b/IntelGL.mdwn
index bfe7b80..9b4db0e 100644
--- a/IntelGL.moin
+++ b/IntelGL.mdwn
@@ -1,23 +1,27 @@
-The goal of this page is to document some of the surprises in the Intel open-source GL implementation.
-
-Generally things are categorized by the generation -- 830 meaning gen2 (830, 845, 855, 865), 915 meaning gen3 (915, 945, g33), and 965 meaning gen4+ (965, g45).
-
-=== 965: Dynamic branching unlikely to be a performance win. ===
-
-GLSL added support for if, for, while, and other dynamic branching.  This would encourage switching from the traditional way of doing it in the assembly shaders by running both sides of an if and using compares and multiplies to choose the result, to using a simple if statement.  However, due to the way the fragment shader is architected, if not all the pixels in a dispatch group (generally 8 or 16 at a time) take the same branch of the shader, you end up executing both paths anyway.  Additionally, due to limitations in the GLSL compiler, no optimization is performed on shaders with dynamic branching.  This can be a 30% performance hit.
-
-We hope to resolve this in the future.
- 
-=== 965: No support for indices other than ~0 in ARB_primitive_restart ===
-
-The hardware requires that 0xffffffff (or appropriately truncated for smaller size indices) be used to indicate a primitive restart.  If an index other than ~0 is used to indicate primitive restart, it will fall back to doing primitive restart handling in software -- reading the index buffer and doing draw calls between the restarts.
-
-=== 915: Support for GLSL ===
-
-The 915-class hardware doesn't support many of the features of GLSL, notably dynamic branching.  However, GLSL is quite useful from a programmer's perspective even if some features of the language aren't available.  So, we've added the "fragment_shader" driconf option that enables limited GLSL program execution support.
-
-Among the features that don't work are if statements, non-unrolled for loops, subroutines, dFdx(), dFdy(), fwidth(), backface color, and noise().
-
-Some of these should be fixed in the future, including flattening if statements to work, inlining more subroutines so they work, and backface color support.
-
-Additionally, the 915-class hardware has no support for occlusion queries, which are a requirement for GL 1.5.  There doesn't appear to be a way to emulate them that would be useful for application developers.  However, most applications using GLSL shaders require GL 2.0, as the GL 2.0 entrypoints are simpler and very nice to use.  To support running those applications, a debug driconf option called "stub_occlusion_query" is provided that enables nonconformant ARB_occlusion_query support, that in combination with the ARB_fragment_shader support results in the driver reporting GL 2.0 support.
+
+The goal of this page is to document some of the surprises in the Intel open-source GL implementation. 
+
+Generally things are categorized by the generation -- 830 meaning gen2 (830, 845, 855, 865), 915 meaning gen3 (915, 945, g33), and 965 meaning gen4+ (965, g45). 
+
+
+### 965: Dynamic branching unlikely to be a performance win.
+
+GLSL added support for if, for, while, and other dynamic branching.  This would encourage switching from the traditional way of doing it in the assembly shaders by running both sides of an if and using compares and multiplies to choose the result, to using a simple if statement.  However, due to the way the fragment shader is architected, if not all the pixels in a dispatch group (generally 8 or 16 at a time) take the same branch of the shader, you end up executing both paths anyway.  Additionally, due to limitations in the GLSL compiler, no optimization is performed on shaders with dynamic branching.  This can be a 30% performance hit. 
+
+We hope to resolve this in the future. 
+
+
+### 965: No support for indices other than ~0 in ARB_primitive_restart
+
+The hardware requires that 0xffffffff (or appropriately truncated for smaller size indices) be used to indicate a primitive restart.  If an index other than ~0 is used to indicate primitive restart, it will fall back to doing primitive restart handling in software -- reading the index buffer and doing draw calls between the restarts. 
+
+
+### 915: Support for GLSL
+
+The 915-class hardware doesn't support many of the features of GLSL, notably dynamic branching.  However, GLSL is quite useful from a programmer's perspective even if some features of the language aren't available.  So, we've added the "fragment_shader" driconf option that enables limited GLSL program execution support. 
+
+Among the features that don't work are if statements, non-unrolled for loops, subroutines, dFdx(), dFdy(), fwidth(), backface color, and noise(). 
+
+Some of these should be fixed in the future, including flattening if statements to work, inlining more subroutines so they work, and backface color support. 
+
+Additionally, the 915-class hardware has no support for occlusion queries, which are a requirement for GL 1.5.  There doesn't appear to be a way to emulate them that would be useful for application developers.  However, most applications using GLSL shaders require GL 2.0, as the GL 2.0 entrypoints are simpler and very nice to use.  To support running those applications, a debug driconf option called "stub_occlusion_query" is provided that enables nonconformant ARB_occlusion_query support, that in combination with the ARB_fragment_shader support results in the driver reporting GL 2.0 support. 
diff --git a/IntelGMA.mdwn b/IntelGMA.mdwn
new file mode 100644
index 0000000..0323849
--- /dev/null
+++ b/IntelGMA.mdwn
@@ -0,0 +1,8 @@
+
+
+
+---
+
+ 
+
+* [[CategoryHardwareChipset|CategoryHardwareChipset]] 
+\ No newline at end of file
diff --git a/IntelGMA.moin b/IntelGMA.moin
deleted file mode 100644
index 24be67f..0000000
--- a/IntelGMA.moin
+++ /dev/null
@@ -1,3 +0,0 @@
-#REDIRECT Intel
-----
- . CategoryHardwareChipset
diff --git a/IntelPerformance.mdwn b/IntelPerformance.mdwn
new file mode 100644
index 0000000..db6f944
--- /dev/null
+++ b/IntelPerformance.mdwn
@@ -0,0 +1,73 @@
+
+
+## Ideas for improving Intel 3D driver performance
+
+
+### 965: Profile URB allocation
+
+How often are we cutting down to minimal URB allocation size? 
+
+
+### G4x: Use transposed reads
+
+This would cut the URB size from sf->wm, allowing more concurrency.  g45-transposed-read branch of ~anholt/mesa 
+
+
+### 965: Cut down on state flagging in brw_new_batch
+
+We just need to re-emit everything (BRW_NEW_CONTEXT), not re-calculate all state.  Must make sure that BRW_NEW_CONTEXT is set where it needs to be.  Also, merge this and BRW_NEW_BATCH together. 
+
+
+### 965: Enable other-sized dispatch in wm
+
+Right now we only enable 16-pixel or 8-pixel dispatch, while creating program binaries with multiple entrypoints for differently-sized dispatch could save us many cycles. 
+
+
+### 965: Merge brw_wm_glsl.c into brw_wm_emit.c
+
+This would get us 16-wide dispatch in GLSL, which looks like a 10-20% performance win. 
+
+
+### 915: Avoid no-op updates of non-pipelined state
+
+Calling [[DrawBuffer|DrawBuffer]] to the same buffer is painful as it flags us for updating the draw buffer, which is non-pipelined state.  This brings the meta clear code from 200mb/s to 6mb/s.  Something like what 965 does would be better for state tracking in this driver. 
+
+
+### both: Save state instead of using push/pop in metaops
+
+push/pop are expensive, and if we just kept track of the state in static structures it would be a win. 
+
+
+### both: Use fps and vps in metaops
+
+This is partially done now, but using fps and vps for metaops lets us push/pop less state and reduces the cost for mesa and 965 to calculate the state updates that result. 
+
+
+### both: Avoiding CPU-dirty of BOs kicked out of the aperture
+
+Right now when an application exceeds the aperture size, it hits a performance cliff because BOs removed from the aperture have their pages unpinned so they can be swapped.  If we kept the BOs pinned but had a memory pressure handler, we could avoid cpu dirtying them, which would remove most of the unbind/rebind thrashing cost. 
+
+
+### both: Use PPGTT to have a larger aperture size
+
+Pulls us back from the performance cliff in the previous entry.  This would also let us successfully render larger FBOs and textures where we fail currently. 
+
+
+### i965: Avoid creating new VBO until we've sent the last one out in a batchbuffer
+
+Right now when vbo_exec_api.c flushes a set of primitives, it does [[BufferData|BufferData]](size, NULL) on the VBO, so that you don't block on mapping the old one due to existing rendering.  VBOs are relatively huge, so if you're doing tiny draws it's a lot of overhead, keeping us from using real VBOs for vbo_exec. 
+
+
+### i965: Implement the ranged mapping extension
+
+This would obsolete the previous entry, as the vbo module would start doing what we want for us. 
+
+
+### i965: Only upload the constant buffer when the contents or the fencing of it has changed.
+
+Right now we upload it if you change programs, fencing, pipelined state, or anything related to transforms or projection.  Would this help? 
+
+
+### i965: Use PIPE_CONTROL
+
+This is supposed to get us better pipelining behavior than MI_FLUSH. 
diff --git a/IntelPerformance.moin b/IntelPerformance.moin
deleted file mode 100644
index c063407..0000000
--- a/IntelPerformance.moin
+++ /dev/null
@@ -1,42 +0,0 @@
-== Ideas for improving Intel 3D driver performance ==
-=== 965: Profile URB allocation ===
-How often are we cutting down to minimal URB allocation size?
-
-=== G4x: Use transposed reads ===
-This would cut the URB size from sf->wm, allowing more concurrency.  g45-transposed-read branch of ~anholt/mesa
-
-=== 965: Cut down on state flagging in brw_new_batch ===
-We just need to re-emit everything (BRW_NEW_CONTEXT), not re-calculate all state.  Must make sure that BRW_NEW_CONTEXT is set where it needs to be.  Also, merge this and BRW_NEW_BATCH together.
-
-=== 965: Enable other-sized dispatch in wm ===
-Right now we only enable 16-pixel or 8-pixel dispatch, while creating program binaries with multiple entrypoints for differently-sized dispatch could save us many cycles.
-
-=== 965: Merge brw_wm_glsl.c into brw_wm_emit.c ===
-This would get us 16-wide dispatch in GLSL, which looks like a 10-20% performance win.
-
-=== 915: Avoid no-op updates of non-pipelined state ===
-Calling DrawBuffer to the same buffer is painful as it flags us for updating the draw buffer, which is non-pipelined state.  This brings the meta clear code from 200mb/s to 6mb/s.  Something like what 965 does would be better for state tracking in this driver.
-
-=== both: Save state instead of using push/pop in metaops ===
-push/pop are expensive, and if we just kept track of the state in static structures it would be a win.
-
-=== both: Use fps and vps in metaops ===
-This is partially done now, but using fps and vps for metaops lets us push/pop less state and reduces the cost for mesa and 965 to calculate the state updates that result.
-
-=== both: Avoiding CPU-dirty of BOs kicked out of the aperture ===
-Right now when an application exceeds the aperture size, it hits a performance cliff because BOs removed from the aperture have their pages unpinned so they can be swapped.  If we kept the BOs pinned but had a memory pressure handler, we could avoid cpu dirtying them, which would remove most of the unbind/rebind thrashing cost.
-
-=== both: Use PPGTT to have a larger aperture size ===
-Pulls us back from the performance cliff in the previous entry.  This would also let us successfully render larger FBOs and textures where we fail currently.
-
-=== i965: Avoid creating new VBO until we've sent the last one out in a batchbuffer ===
-Right now when vbo_exec_api.c flushes a set of primitives, it does BufferData(size, NULL) on the VBO, so that you don't block on mapping the old one due to existing rendering.  VBOs are relatively huge, so if you're doing tiny draws it's a lot of overhead, keeping us from using real VBOs for vbo_exec.
-
-=== i965: Implement the ranged mapping extension ===
-This would obsolete the previous entry, as the vbo module would start doing what we want for us.
-
-=== i965: Only upload the constant buffer when the contents or the fencing of it has changed. ===
-Right now we upload it if you change programs, fencing, pipelined state, or anything related to transforms or projection.  Would this help?
-
-=== i965: Use PIPE_CONTROL ===
-This is supposed to get us better pipelining behavior than MI_FLUSH.
diff --git a/IntelPerformanceTuning.mdwn b/IntelPerformanceTuning.mdwn
new file mode 100644
index 0000000..087901a
--- /dev/null
+++ b/IntelPerformanceTuning.mdwn
@@ -0,0 +1,118 @@
+
+
+### Performance tuning on the Intel graphics driver
+
+The Intel graphics driver has several tools available for it to help OpenGL developers and driver developers track down where performance bottlenecks are in the driver stack. 
+
+
+#### Step 1: Known issues
+
+The first tool to look at is running your application with the environment variable `INTEL_DEBUG=perf` set.  This will report debug information for many known causes of performance problems on the console.  Not all of them will cause visible performance improvements when fixed, but it's a good first step to see what might going wrong. 
+
+
+#### Step 2: CPU vs GPU
+
+The primary question is figuring out whether the CPU is busy in your application, the CPU is busy in the GL driver, the GPU is waiting for the CPU, or the CPU is waiting for the GPU.  Ideally, you get to the point where the CPU is waiting for the GPU infrequently but for a significant amount of time (however long it takes the GPU to draw a frame). 
+
+There are two initial tools: `top` and `intel_gpu_top`.  They have related readouts.  Pull up top while your application is running.  Is the CPU usage around 90%+?  If so, then our performance analysis will be with sysprof. 
+
+
+#### sysprof
+
+If the CPU is totally busy and the GPU isn't terribly busy, there is an excellent tool for debugging: sysprof.  Just install, run as root (so you can get system-wide profiling), hit play and later stop.  The top-left area shows the flat profile sorted by total time of that symbol plus its descendents.  The top few are generally uninteresting (`main()` and its descendents consuming a lot), but eventually you can get down to something interesting.  Click it, and to the right you get the callchains to descendents -- where all that time actually went.  On the other hand, the lower left shows callers -- double-clicking those selects that as the symbol to view, instead. 
+
+Note that you need debug symbols for the callgraphs sysprof to work, which is where most of its value is.  Most distributions offer debug symbol packages from their builds which can be installed separately, and sysprof will find them. 
+
+
+#### intel_gpu_top
+
+If the CPU is mostly idle, then run `intel_gpu_top` from the intel-gpu-tools package.  The important number is "ring busy".  An app that keeps the GPU busy will see this number fluctuate between 90-100%. 
+
+There is a bunch of other data on this screen as well.  Not much of it is of a lot of use -- the mysterious acronyms on the left are from the spec for the register we're getting that information from, and we don't even know what some of those acronyms mean (and much less what those units being busy implies for an application or driver developer). 
+
+
+#### Identifying expensive GPU tasks
+
+If `intel_gpu_top` says the GPU is busy, there are a few tools available for figuring out where all that GPU time is going. 
+
+One is, on gen7 (Ivybridge) and newer, the `INTEL_DEBUG=shader_time` environment variable.  This inserts timestamps at the start and end of every shader that get accumulated through atomic operations.  It has a significant runtime performance cost, and there are some inaccuracies (some instructions don't end up counted, and only time in the shaders is counted and not the fixed function hardware calling those shaders), but it can quickly and accurately point to which stage of which shader might be the bottleneck. 
+
+If you don't have Ivybridge or if `shader_time` is failing for some other reason, there is apitrace's -pgpu option.  Capture a trace of your application using `apitrace trace appname`.  This will produce `appname.trace` in the current directory.  You can then use the qapitrace GUI's Profile option on it (which produces a timeline of which shaders were used in which draw calls and for how long), or you summarize blame for shader programs at the console with `apitrace replay -pgpu appname.trace > appname.pgpu; profileshader.py < appname.pgpu` where profileshader.py comes from the apitrace tree's `scripts` directory.  This tool has some inaccuracies as well to shader_time: While it includes fixed function overheads, it doesn't necessarily profile all calls that might result in time being spent on the GPU, and it has no way to pinpoint where the time was spent (vertex shader, fragment shader, or other) in a call. 
+
+There is also the GL_ARB_timer_query extension.  This is the tool that apitrace's profiling is based off of, and you can instrument your application to track where GPU time is spent across large blocks of your application. 
+
+If you have identified a shader that is the bottleneck for your application, `INTEL_DEBUG=fs` in the environment will dump out the generated fragment shader assembly on the 965, and `INTEL_DEBUG=vs` in the environment will dump out the vertex shader assembly. 
+
+On the other hand, if intel_gpu_top doesn't show the GPU very busy, then you're probably stalling on it. 
+
+
+#### perf for GPU stalls
+
+Not all stalls on the GPU are recorded in `INTEL_DEBUG=perf`.  To see all cases where this happens, use the `perf` tool from the Linux kernel (note: unrelated to `INTEL_DEBUG=perf`). 
+
+
+[[!format txt """
+sudo perf record -f -g -e i915:i915_gem_request_wait_begin -c 1 openarena
+"""]]
+If you want to see the whole system's stalls for a period of time (very useful!), use the `-a` flag instead of a particular command name.  Just `^C` when you're done capturing data. 
+
+At exit, you'll have `perf.data` in the current directory.  You can print out the results with `perf report | less`: 
+
+
+[[!format txt """
+   100.00%  openarena  [vdso]                          [.] 0x000000ffffe424
+                |          
+                |--95.96%-- drm_intel_bo_subdata
+                |          0xace13d53
+                |          _mesa_BufferSubDataARB
+                |          _mesa_meta_clear
+                |          0xace14f86
+                |          _mesa_Clear
+                |          0x815d875
+                |          
+                 --4.04%-- drm_intel_gem_bo_wait_rendering
+                           drm_intel_bo_wait_rendering
+                           |          
+                           |--54.67%-- 0xace167e8
+                           |          _mesa_Flush
+                           |          glXSwapBuffers
+                           |          0xb774e115
+                           |          SDL_GL_SwapBuffers
+                           |          0x81a4afd
+                           |          
+
+"""]]
+This shows that all of the wait events occurred in openarena, and of those, 96% were in `drm_intel_bo_subdata` triggered by `_mesa_Clear` (many `_mesa_Whatever` functions are the implementation of `glWhatever` -- the actual `glWhatever` function is a runtime-generated stub so it doesn't get labeled in profiles).  This shows a driver bug -- the `_mesa_meta_clear()` function is calling `_mesa_BufferSubDataARB()` on a buffer currently in use by the GPU, so the CPU blocks waiting for the GPU to finish. 
+
+The stalls under `glXSwapBuffers` in that trace are desired and expected: you don't want your application to run ahead and request draw 1000 frames of the same time in the game, when it will take a minute to render them all, so the driver stalls you when a whole frame is already queued up for rendering and not started rendering yet. 
+
+If you want to see exactly where in the compiled code a wait occurred, you can use `perf annotate`: 
+
+
+[[!format txt """
+perf annotate _mesa_meta_clear
+"""]]
+
+## Some common problems to find
+
+
+#### A lot of CPU time spent in _mesa_ReadPixels() or _mesa_GetTexImage
+
+glReadPixels() and glGetTexImage() are slow.  Do almost anything you can to avoid them.  Before gen6 (Sandybridge), these reads occur at between 10MB/sec and 40MB/sec.  On LLC-coherent hardware like Sandybridge and later, we can get them up to about 1GB/sec, but they still imply synchronization with the GPU. 
+
+PBOs, in limited cases, may be a win if you can delay mapping the PBO until later.  Note that if you're memcopying out of the PBO, there's an extra copy that's happened compared to a non-PBO readpixels (since we have to blit to the PBO to snapshot the data and to untile it).  To get the blit path, the requested format has to match the framebuffer's format -- see `_mesa_format_matches_format_and_type()` for the actual test, and `GL_OES_read_format` for a way to request what the right format ought to be. 
+
+
+#### A lot of CPU time spent in brw_validate_state()
+
+This is the computation of GL state to hardware state on Gen4 hardware.  On previous generations, as each OpenGL call is made we would compute the updated hardware state and queue it to be emitted.  Now, we queue up all hardware updates and only calculate the updated hardware state when we do drawing.  This helps avoid extra computation for common OpenGL idioms like functions popping their state on exit.  However, the flagging of what hardware state needs to be recomputed is handled by a limited number of state flags -- the strips and fans unit says that it needs to be recomputed for any change of viewport, scissor, or drawbuffers state, for example.  Some stages may indicate that they need recalculation when another stage changes.  There are plenty of places here for innocuous GL or driver state changes to cascade recomputation.  There's a tool for looking into this: run your program with `INTEL_DEBUG=state` in the environment.  You'll get a dump of how many times each state flag was set when drawing occurred.  This can help narrow down why CPU was used in state validation.  Note that for every BRW_NEW_CONTEXT we re-flag all state, and BRW_NEW_BATCH triggers a significant subset of those as well.  So things triggering pipeline flushes (`glFlush`, `glFinish`, `glReadPixels`, or most anything reporting access of busy BOs under `INTEL_DEBUG=perf`) will cause a lot of recomputation to occur. 
+
+
+#### A lot of CPU time is spent in drm_clflush_pages()
+
+This usually means that buffers are getting evicted from the aperture -- it's found as a descendent of `evict_something()`, or being brought back into the aperture at `i915_gem_execbuffer()` time.  Try tuning the graphics memory usage of the application at this point.  Be sure to free unused GL objects -- freed textures and buffer objects get put back in the BO cache so that their memory never has to be evicted before being reused. 
+
+
+#### A lot of CPU time is spent in drm_intel_bo_exec()
+
+If the caller of `drm_intel_bo_exec` is `require_space`, then you've just accumulated enough state updates that it's time to flush the batchbuffer.  Generally for busy applications this can take up 10% or so of the time, as the kernel has to do a bunch of validation and preparation to get the batchbuffer ready for submission.  If it's taking more than that, a descendent is usually `drm_clflush_pages()` above. 
diff --git a/IntelPerformanceTuning.moin b/IntelPerformanceTuning.moin
deleted file mode 100644
index 3400546..0000000
--- a/IntelPerformanceTuning.moin
+++ /dev/null
@@ -1,95 +0,0 @@
-=== Performance tuning on the Intel graphics driver ===
-
-The Intel graphics driver has several tools available for it to help OpenGL developers and driver developers track down where performance bottlenecks are in the driver stack.
-
-==== Step 1: Known issues ====
-The first tool to look at is running your application with the environment variable {{{INTEL_DEBUG=perf}}} set.  This will report debug information for many known causes of performance problems on the console.  Not all of them will cause visible performance improvements when fixed, but it's a good first step to see what might going wrong.
-
-==== Step 2: CPU vs GPU ====
-The primary question is figuring out whether the CPU is busy in your application, the CPU is busy in the GL driver, the GPU is waiting for the CPU, or the CPU is waiting for the GPU.  Ideally, you get to the point where the CPU is waiting for the GPU infrequently but for a significant amount of time (however long it takes the GPU to draw a frame).
-
-There are two initial tools: {{{top}}} and {{{intel_gpu_top}}}.  They have related readouts.  Pull up top while your application is running.  Is the CPU usage around 90%+?  If so, then our performance analysis will be with sysprof.
-
-==== sysprof ====
-If the CPU is totally busy and the GPU isn't terribly busy, there is an excellent tool for debugging: sysprof.  Just install, run as root (so you can get system-wide profiling), hit play and later stop.  The top-left area shows the flat profile sorted by total time of that symbol plus its descendents.  The top few are generally uninteresting ({{{main()}}} and its descendents consuming a lot), but eventually you can get down to something interesting.  Click it, and to the right you get the callchains to descendents -- where all that time actually went.  On the other hand, the lower left shows callers -- double-clicking those selects that as the symbol to view, instead.
-
-Note that you need debug symbols for the callgraphs sysprof to work, which is where most of its value is.  Most distributions offer debug symbol packages from their builds which can be installed separately, and sysprof will find them.
-
-==== intel_gpu_top ====
-If the CPU is mostly idle, then run {{{intel_gpu_top}}} from the intel-gpu-tools package.  The important number is "ring busy".  An app that keeps the GPU busy will see this number fluctuate between 90-100%.
-
-There is a bunch of other data on this screen as well.  Not much of it is of a lot of use -- the mysterious acronyms on the left are from the spec for the register we're getting that information from, and we don't even know what some of those acronyms mean (and much less what those units being busy implies for an application or driver developer).
-
-==== Identifying expensive GPU tasks ====
-If {{{intel_gpu_top}}} says the GPU is busy, there are a few tools available for figuring out where all that GPU time is going.
-
-One is, on gen7 (Ivybridge) and newer, the {{{INTEL_DEBUG=shader_time}}} environment variable.  This inserts timestamps at the start and end of every shader that get accumulated through atomic operations.  It has a significant runtime performance cost, and there are some inaccuracies (some instructions don't end up counted, and only time in the shaders is counted and not the fixed function hardware calling those shaders), but it can quickly and accurately point to which stage of which shader might be the bottleneck.
-
-If you don't have Ivybridge or if {{{shader_time}}} is failing for some other reason, there is apitrace's -pgpu option.  Capture a trace of your application using {{{apitrace trace appname}}}.  This will produce {{{appname.trace}}} in the current directory.  You can then use the qapitrace GUI's Profile option on it (which produces a timeline of which shaders were used in which draw calls and for how long), or you summarize blame for shader programs at the console with {{{apitrace replay -pgpu appname.trace > appname.pgpu; profileshader.py < appname.pgpu}}} where profileshader.py comes from the apitrace tree's {{{scripts}}} directory.  This tool has some inaccuracies as well to shader_time: While it includes fixed function overheads, it doesn't necessarily profile all calls that might result in time being spent on the GPU, and it has no way to pinpoint where the time was spent (vertex shader, fragment shader, or other) in a call.
-
-There is also the GL_ARB_timer_query extension.  This is the tool that apitrace's profiling is based off of, and you can instrument your application to track where GPU time is spent across large blocks of your application.
-
-If you have identified a shader that is the bottleneck for your application, {{{INTEL_DEBUG=fs}}} in the environment will dump out the generated fragment shader assembly on the 965, and {{{INTEL_DEBUG=vs}}} in the environment will dump out the vertex shader assembly.
-
-On the other hand, if intel_gpu_top doesn't show the GPU very busy, then you're probably stalling on it.
-
-==== perf for GPU stalls ====
-Not all stalls on the GPU are recorded in {{{INTEL_DEBUG=perf}}}.  To see all cases where this happens, use the {{{perf}}} tool from the Linux kernel (note: unrelated to {{{INTEL_DEBUG=perf}}}).
-
-{{{
-sudo perf record -f -g -e i915:i915_gem_request_wait_begin -c 1 openarena
-}}}
-
-If you want to see the whole system's stalls for a period of time (very useful!), use the {{{-a}}} flag instead of a particular command name.  Just {{{^C}}} when you're done capturing data.
-
-At exit, you'll have {{{perf.data}}} in the current directory.  You can print out the results with {{{perf report | less}}}:
-
-{{{
-   100.00%  openarena  [vdso]                          [.] 0x000000ffffe424
-                |          
-                |--95.96%-- drm_intel_bo_subdata
-                |          0xace13d53
-                |          _mesa_BufferSubDataARB
-                |          _mesa_meta_clear
-                |          0xace14f86
-                |          _mesa_Clear
-                |          0x815d875
-                |          
-                 --4.04%-- drm_intel_gem_bo_wait_rendering
-                           drm_intel_bo_wait_rendering
-                           |          
-                           |--54.67%-- 0xace167e8
-                           |          _mesa_Flush
-                           |          glXSwapBuffers
-                           |          0xb774e115
-                           |          SDL_GL_SwapBuffers
-                           |          0x81a4afd
-                           |          
-
-}}}
-
-This shows that all of the wait events occurred in openarena, and of those, 96% were in {{{drm_intel_bo_subdata}}} triggered by {{{_mesa_Clear}}} (many {{{_mesa_Whatever}}} functions are the implementation of {{{glWhatever}}} -- the actual {{{glWhatever}}} function is a runtime-generated stub so it doesn't get labeled in profiles).  This shows a driver bug -- the {{{_mesa_meta_clear()}}} function is calling {{{_mesa_BufferSubDataARB()}}} on a buffer currently in use by the GPU, so the CPU blocks waiting for the GPU to finish.
-
-The stalls under {{{glXSwapBuffers}}} in that trace are desired and expected: you don't want your application to run ahead and request draw 1000 frames of the same time in the game, when it will take a minute to render them all, so the driver stalls you when a whole frame is already queued up for rendering and not started rendering yet.
-
-If you want to see exactly where in the compiled code a wait occurred, you can use {{{perf annotate}}}:
-
-{{{
-perf annotate _mesa_meta_clear
-}}}
-
-== Some common problems to find ==
-
-==== A lot of CPU time spent in _mesa_ReadPixels() or _mesa_GetTexImage ====
-glReadPixels() and glGetTexImage() are slow.  Do almost anything you can to avoid them.  Before gen6 (Sandybridge), these reads occur at between 10MB/sec and 40MB/sec.  On LLC-coherent hardware like Sandybridge and later, we can get them up to about 1GB/sec, but they still imply synchronization with the GPU.
-
-PBOs, in limited cases, may be a win if you can delay mapping the PBO until later.  Note that if you're memcopying out of the PBO, there's an extra copy that's happened compared to a non-PBO readpixels (since we have to blit to the PBO to snapshot the data and to untile it).  To get the blit path, the requested format has to match the framebuffer's format -- see {{{_mesa_format_matches_format_and_type()}}} for the actual test, and {{{GL_OES_read_format}}} for a way to request what the right format ought to be.
-
-==== A lot of CPU time spent in brw_validate_state() ====
-This is the computation of GL state to hardware state on Gen4 hardware.  On previous generations, as each OpenGL call is made we would compute the updated hardware state and queue it to be emitted.  Now, we queue up all hardware updates and only calculate the updated hardware state when we do drawing.  This helps avoid extra computation for common OpenGL idioms like functions popping their state on exit.  However, the flagging of what hardware state needs to be recomputed is handled by a limited number of state flags -- the strips and fans unit says that it needs to be recomputed for any change of viewport, scissor, or drawbuffers state, for example.  Some stages may indicate that they need recalculation when another stage changes.  There are plenty of places here for innocuous GL or driver state changes to cascade recomputation.  There's a tool for looking into this: run your program with {{{INTEL_DEBUG=state}}} in the environment.  You'll get a dump of how many times each state flag was set when drawing occurred.  This can help narrow down why CPU was used in state validation.  Note that for every BRW_NEW_CONTEXT we re-flag all state, and BRW_NEW_BATCH triggers a significant subset of those as well.  So things triggering pipeline flushes ({{{glFlush}}}, {{{glFinish}}}, {{{glReadPixels}}}, or most anything reporting access of busy BOs under {{{INTEL_DEBUG=perf}}}) will cause a lot of recomputation to occur.
-
-==== A lot of CPU time is spent in drm_clflush_pages() ====
-This usually means that buffers are getting evicted from the aperture -- it's found as a descendent of {{{evict_something()}}}, or being brought back into the aperture at {{{i915_gem_execbuffer()}}} time.  Try tuning the graphics memory usage of the application at this point.  Be sure to free unused GL objects -- freed textures and buffer objects get put back in the BO cache so that their memory never has to be evicted before being reused.
-
-==== A lot of CPU time is spent in drm_intel_bo_exec() ====
-If the caller of {{{drm_intel_bo_exec}}} is {{{require_space}}}, then you've just accumulated enough state updates that it's time to flush the batchbuffer.  Generally for busy applications this can take up 10% or so of the time, as the kernel has to do a bunch of validation and preparation to get the batchbuffer ready for submission.  If it's taking more than that, a descendent is usually {{{drm_clflush_pages()}}} above.
diff --git a/IntelRegisters.mdwn b/IntelRegisters.mdwn
new file mode 100644
index 0000000..79d6abf
--- /dev/null
+++ b/IntelRegisters.mdwn
@@ -0,0 +1,276 @@
+
+
+# IntelRegisters
+
+This is an attempt to explain the i8xx registers. It was started for the i830, and bits of information about the other models was unsystematically added. Please extend as appropriate, and mark the differences. 
+
+
+## Architecture overview
+
+The i830 emulates two PCI cards. The register of the PCI cards seem to shadow each other, and the X driver only uses the first card. 
+
+There are several parts used for graphic output: 
+
+Display planes A,B,C --> Pipes A,B --> Analog/Digital Ports   I2C control for TV encoder. 
+
+Some registers may be double buffered, and may need a write to another register to commit. 
+
+Here are some definitions from the i845G data sheet: 
+
+* A PLANE consists of a rectangular shaped image that has characteristics such as source, size, position, method, and format. These planes get attached to source surfaces that are rectangular memory surfaces with a similar set of characteristics.  They are also associated with a destination pipe. 
+
+* A PIPE consists of a set of combined planes and a timing generator.  
+
+
+## I2C control
+[[!table header="no" class="mointable" data="""
+ Chipset   |  I2C lines                        |  Known TV       
+ i810      |  DDC; LTV                         |  GPIOB = LTV    
+ i830      |  DDC1, I2C, DDC2; M_DDC, M_I2C    |  GPIOC = M_I2C  
+ i845      |  DDC_A; MI2C, MDVI, MDDC          |  GPIOE          
+ i865      |  DDC_A; MI2C, MDVI, MDDC          |  GPIOE = M_I2C  
+"""]]
+
+On the i830, DVO port A uses DDC2 or I2C, DVO ports B/C use M_I2C or M_DDC. The DDC ports are used for EDID display information transfer from the monitor (typically at address 0xA0) or flat panel. On the I2C port a device at 0x04 has been observed, possibly a flat panel controller.  
+[[!table header="no" class="mointable" data="""
+ 0x05010  |  GPIOA General purpose I/O A, one of the DDC ports. 
+ 0x05014  |  GPIOB General purpose I/O B, I2C port.             
+ 0x05018  |  GPIOC General purpose I/O C, M_I2C port.           
+ 0x05020  |  GPIOE General purpose I/O E (for i845)             
+ 0x05024  |  GPIOF General purpose I/O F (for i???)             
+31:13  |  reserved                                           
+   12  |  GPIO1 data in                                      
+   11  |  GPIO1 data value                                   
+   10  |  GPIO1 data mask (1=write data)                     
+    9  |  GPIO1 direction value (0=input, 1=output)          
+    8  |  GPIO1 direction mask (1=write direction)           
+ 7: 5  |  reserved                                           
+    4  |  GPIO0 data in                                      
+    3  |  GPIO0 data value                                   
+    2  |  GPIO0 data mask                                    
+    1  |  GPIO0 direction value                              
+    0  |  GPIO0 direction mask                               
+"""]]
+
+GPIO1 is the data pin, GPIO0 is the clock pin. Maybe there are even  more GPIO registers? 
+
+The i865 implements a hardware GMBus controller that can be used to control these signals.  This allows higher speed transactions (up to 400 kHz) on theses lines than was allowed with previous software centric `bit-bashing' techniques. 
+
+It is not completely clear how the GMBus controller registers work. 
+[[!table header="no" class="mointable" data="""
+ 0x05100  |  GMBUS CLK_PORT_SEL 
+ 0x05104  |  GMBUS CMD          
+ ?:16  |  DATA_COUNT         
+ ?: 8  |  SLAVE_REG          
+ 0x05108  |  GMBUS_STATUS       
+ 0x0510C  |  GMBUS_DATA         
+"""]]
+
+
+## Display planes
+
+There are (at least) 3 display planes: 
+
+* A: primary display plane 
+
+* B: 'sprite' plane (for specific laptop display information?) 
+
+* C: overlay plane (can also be directly sent in YUV format to DVO) 
+
+The datasheet diagram shows overlay, sprite, two cursor, and primary and secondary display units. Maybe those correspond to the planes. The datasheet also meantions a popup plane for mobile applications. The single overlay plane can only displayed on "single-pipe simultanious  displays" for multi-monitors. (For the i810, 0x70008 PIXCONF has some of the functions used here.) For the i865, these registers seem to be somewhere else. 
+[[!table header="no" class="mointable" data="""
+ 0x70180  |  DSPACTRL Display plane A control                            
+ 0x71180  |  DSPBCTRL Display plane B control                            
+   31  |  plane enable (1=enabled)                                    
+   30  |  gamma correction enable (0=bypass, 1=enabled)               
+29:26  |  pixformat (2=8BPP, 4=15_16BPP, 5=16BPP, 6=32BPP_NO_ALPHA, 7=32BPP) 
+   25  |  stereo enable (1=enabled)                                   
+   24  |  select pipe (0=A, 1=B)                                      
+   23  |  reserved                                                    
+   22  |  source key enable (1=enabled)                               
+21:20  |  pixel multiplicity (0=normal, 1=doubleline, 2=3=reserved)   
+   19  |  reserved                                                    
+   18  |  stereo polarity (0=first, 1=second)                         
+17-16  |  reserved                                                    
+   15  |  alpha transfer mode (1=enabled) ; B only                    
+14- 1  |  reserved                                                    
+    0  |  sprite_above (0=display A, 1=overlay) ; B only              
+"""]]
+
+Note: 8BPP is indexed, 15_16BPP is 5-5-5, 16BPP is 5-6-5,  32BPP_NO_ALPHA is X:8:8:8, and 32BPP is 8:8:8:8. 
+
+Note: Stereo requires two start (base) addresses, at least for plane B. 
+
+It is not clear why a display plane has to connect to a pipe, instead of the other way round, unless the plane block also contains the counters. 
+
+|| 0x70184 || DSPABASE Display plane A base address || 0x71184 || DSPBBASE Display plane B base address 
+
+|| 0x70188 || DSPASTRIDE Display plane A stride (= pitch) || 0x71188 || DSPBSTRIDE Display plane B stride (= pitch) ||<)>31-16 || UNKNOWN, 15CF/0001 ||<)> ?- 0 || stride 
+
+
+## Pipes
+
+There are two pipes, which control the timing.  
+[[!table header="no" class="mointable" data="""
+ 0x60000  |  HTOTAL_A                         
+ 0x60004  |  HBLANK_A                         
+ 0x60008  |  HSYNC_A                          
+ 0x6000c  |  VTOTAL_A                         
+ 0x60010  |  VBLANK_A                         
+ 0x60014  |  VSYNC_A                          
+ 0x6001c  |  PIPEASRC                         
+26:16  |  horizontal (= HTOTAL displayed)  
+10: 0  |  vertical   (= VTOTAL displayed)  
+ 0x60020  |  BCLRPAT border color pattern     
+"""]]
+
+Identical registers for pipe B are at 0x61000-0x61020. 
+
+On the i810, there also was the LCDTV_C register, which is probably not any longer supported. 
+[[!table header="no" class="mointable" data="""
+ 0x60018  |  LCDTV_C LCD/TV-Out control register 
+"""]]
+[[!table header="no" class="mointable" data="""
+ 0x70008  |  PIPEACONF (PIXCONF for i810) 
+   31  |  enable (1=enabled)           
+   30  |  width (1=double, 0=single)   
+29:27  |  reserved                     
+   25  |  lock (1=locked) ; unclear    
+   24  |  (0=palette, 1=gamma)         
+23: 0  |  reserved                     
+ 0x71008  |  PIPEBCONF                    
+   31  |  enable (1=enabled)           
+30:25  |  reserved                     
+   24  |  (0=palette, 1=gamma)         
+23: 0  |  reserved                     
+"""]]
+[[!table header="no" class="mointable" data="""
+ 0x71400  |  UNKNOWN (= 0020008e) 
+"""]]
+
+
+## Analog/Digital Ports
+
+There are three dedicated Digital Video Ports and one Analog Port. DVOB and C are multixplexed with the AGP pins. The local flat panel (LFP) is normally connected to DVOA. DVOB and DVOC may be combined into one 24bit wide port. DVO port signals are: 
+[[!table header="no" class="mointable" data="""
+ CLK/CLK#  |  differental clock output up to 165 MHz                        
+ D[11:0]   |  12bit data                                                    
+ HSYNC     |  outgoing HSync with programmable polarity                     
+ VSYNC     |  outgoing VSync with programmable polarity                     
+ BLANK#    |  outgoing blank period or border period signal                 
+ INTR      |  incoming interrupt (DVOA and DVOBC)                           
+ CLKINT    |  incoming clock or second interrupt (DVOA and DVOBC)           
+ FLD/STL   |  incoming TV field (to synchronize overlay) or FP stall signal 
+"""]]
+
+The DPLL registers control the phase locked loops that convert the incoming to the outgoing clock, or possibly some internal clock to the outgoing clock. They are associated to the corresponding pipe. 
+[[!table header="no" class="mointable" data="""
+ 0x06014  |  DPLL_A                                                 
+ 0x06018  |  DPLL_B                                                 
+   31  |  VCO enable (=1 for TFT, TV, mon)                       
+   30  |  2X clock enable (=1 for TFT, TV; =0 for mon)           
+   29  |  synclock enable (=0)                                   
+   28  |  VGA mode disable (=1 for TFT, TV, mon; =0 mon)         
+27:24  |  reserved                                               
+   24  |  [i???] PLL divisor select                              
+   23  |  P2 post divisor (loop divide flag?)                    
+   22  |  reserved                                               
+   21  |  P1 force DIV2                                          
+20:16  |  P1 post divisor                                        
+   15  |  reserved                                               
+14:13  |  reference select (=0 for LCD/mon, =2 for TV ?)         
+12: 0  |  reserved                                               
+    1  |  [i???] rate select mask (0=fp0, 1=fp1)                 
+"""]]
+
+There seems to be additional PLLs for the flat panel. (FIXME: Dave, please add a detailed explanation). 
+[[!table header="no" class="mointable" data="""
+ 0x06040  |  FPA0 flat panel PLL A0 
+ 0x06044  |  FPA1 flat panel PLL A1 
+ 0x06048  |  FPB0 flat panel PLL B0 
+ 0x0604C  |  FPB1 flat panel PLL B1 
+21:16  |  N                      
+13: 8  |  M1                     
+ 5: 0  |  M2                     
+"""]]
+
+where M = 5*(M1+2) + (M2+2), and Clk = RefCLK * M / (N+2) / P 
+
+The ADPA register controls the analog output (monitor). 
+[[!table header="no" class="mointable" data="""
+ 0x61100  |  ADPA                                                   
+   31  |  DAC enable (1=enabled) (=monitor enabled)              
+   30  |  Pipe select (0=A, 1=B) [maybe doesn't work]            
+29:16  |  reserved                                               
+   15  |  Use_VGA_HVPolarity (0=Sets HVPolarity)                 
+14:12  |  UNKNOWN                                                
+   11  |  VSync control disable (1=disabled)                     
+   10  |  HSync control disable (1=disabled)                     
+ 9: 5  |  reserved                                               
+    4  |  VSync active (0=low, 1=high)                           
+    3  |  HSync active (0=low, 1=high)                           
+ 2: 0  |  reserved                                               
+"""]]
+
+For the 3 DVO ports, only the enable bit is known. Other bits may include interrupt handling, polarity control for blank and sync signals, configuration of clock vs. second interrupt and field vs. stall. 
+[[!table header="no" class="mointable" data="""
+ 0x61120  |  DVOA                            
+ 0x61140  |  DVOB                            
+ 0x61160  |  DVOC                            
+   31  |  DVO enable (1=enabled)          
+   30  |  Pipe select (guess!) (0=A, 1=B) 
+   29  |  UNKNOWN                         
+15: 0  |  UNKNOWN                         
+   14  |  UNKNOWN                         
+    8  |  UNKNOWN                         
+    7  |  UNKNOWN                         
+    6  |  UNKNOWN                         
+    4  |  UNKNOWN                         
+    3  |  UNKNOWN                         
+    2  |  UNKNOWN                         
+"""]]
+
+This is used in i855 instead of DVO. 
+[[!table header="no" class="mointable" data="""
+ 0x61180  |  LVDS meaning unknown 
+"""]]
+[[!table header="no" class="mointable" data="""
+ 0x61124  |  DVOA_SRCDIM    
+ 0x61144  |  DVOB_SRCDIM    
+ 0x61164  |  DVOC_SRCDIM    
+23:12  |  (not needed ?) 
+11: 0  |  (not needed ?) 
+"""]]
+
+FIXME: What about 0x61104 ADPA_SRCDIM? and 0x61184 LVDS_SRCDIM? Maybe used for centering? 
+
+
+## Other registers
+[[!table header="no" class="mointable" data="""
+ 0x020cc  |  UNKNOWN = 000c000c / 0000004c 
+"""]]
+
+There are now two watermark registers, with a format different from the I810 FW_BLC register. 
+[[!table header="no" class="mointable" data="""
+ 0x020d8  |  Watermark/Burst = 01080108 
+ 0x020dc  |  Watermark/Burst = 00000108 
+   31:27  |  reserved                   
+   26:24  |  Burst B                    
+   23:21  |  reserved                   
+   20:16  |  Watermark B                
+   15:12  |  reserved                   
+   11: 8  |  Burst A                    
+    7: 6  |  reserved                   
+    5: 0  |  Watermark A                
+"""]]
+
+Software Flags (= scratch registers): 
+[[!table header="no" class="mointable" data="""
+ 0x71410  |  SWF0                                    
+ 0x71414  |  SWF1 (amount of video memory available) 
+ 0x71418  |  SWF2                                    
+ 0x7141c  |  SWF3                                    
+ 0x71420  |  SWF4                                    
+ 0x71424  |  SWF5                                    
+ 0x71428  |  SWF6                                    
+"""]]
diff --git a/IntelRegisters.moin b/IntelRegisters.moin
deleted file mode 100644
index d36b813..0000000
--- a/IntelRegisters.moin
+++ /dev/null
@@ -1,295 +0,0 @@
-= IntelRegisters =
-
-This is an attempt to explain the i8xx registers. It was started for
-the i830, and bits of information about the other models was
-unsystematically added. Please extend as appropriate, and mark the
-differences.
-
-== Architecture overview ==
-
-The i830 emulates two PCI cards. The register of the PCI cards seem
-to shadow each other, and the X driver only uses the first card.
-
-There are several parts used for graphic output:
-
-Display planes A,B,C --> Pipes A,B --> Analog/Digital Ports  
-I2C control for TV encoder.
-
-Some registers may be double buffered, and may need a write to another
-register to commit.
-
-Here are some definitions from the i845G data sheet:
-
-* A PLANE consists of a rectangular shaped image that has
-characteristics such as source, size, position, method, and
-format. These planes get attached to source surfaces that are
-rectangular memory surfaces with a similar set of characteristics. 
-They are also associated with a destination pipe.
-
-* A PIPE consists of a set of combined planes and a timing generator. 
-
-== I2C control ==
-
-|| Chipset  || I2C lines                       || Known TV       ||
-|| i810     || DDC; LTV                        || GPIOB = LTV    ||
-|| i830     || DDC1, I2C, DDC2; M_DDC, M_I2C   || GPIOC = M_I2C  ||
-|| i845     || DDC_A; MI2C, MDVI, MDDC         || GPIOE          ||
-|| i865     || DDC_A; MI2C, MDVI, MDDC         || GPIOE = M_I2C  ||
-
-On the i830, DVO port A uses DDC2 or I2C, DVO ports B/C use M_I2C
-or M_DDC. The DDC ports are used for EDID display information
-transfer from the monitor (typically at address 0xA0) or flat
-panel. On the I2C port a device at 0x04 has been observed, possibly
-a flat panel controller. 
-
-|| 0x05010 || GPIOA General purpose I/O A, one of the DDC ports. ||
-|| 0x05014 || GPIOB General purpose I/O B, I2C port.             ||
-|| 0x05018 || GPIOC General purpose I/O C, M_I2C port.           ||
-|| 0x05020 || GPIOE General purpose I/O E (for i845)             ||
-|| 0x05024 || GPIOF General purpose I/O F (for i???)             ||
-||<)>31:13 || reserved                                           ||
-||<)>   12 || GPIO1 data in                                      ||
-||<)>   11 || GPIO1 data value                                   ||
-||<)>   10 || GPIO1 data mask (1=write data)                     ||
-||<)>    9 || GPIO1 direction value (0=input, 1=output)          ||
-||<)>    8 || GPIO1 direction mask (1=write direction)           ||
-||<)> 7: 5 || reserved                                           ||
-||<)>    4 || GPIO0 data in                                      ||
-||<)>    3 || GPIO0 data value                                   ||
-||<)>    2 || GPIO0 data mask                                    ||
-||<)>    1 || GPIO0 direction value                              ||
-||<)>    0 || GPIO0 direction mask                               ||
-
-GPIO1 is the data pin, GPIO0 is the clock pin. Maybe there are even 
-more GPIO registers?
-
-The i865 implements a hardware GMBus controller that can be used
-to control these signals.  This allows higher speed transactions
-(up to 400 kHz) on theses lines than was allowed with previous
-software centric `bit-bashing' techniques.
-
-It is not completely clear how the GMBus controller registers work.
-
-|| 0x05100 || GMBUS CLK_PORT_SEL ||
-|| 0x05104 || GMBUS CMD          ||
-||<)> ?:16 || DATA_COUNT         ||
-||<)> ?: 8 || SLAVE_REG          ||
-|| 0x05108 || GMBUS_STATUS       ||
-|| 0x0510C || GMBUS_DATA         ||
-
-== Display planes ==
-
-There are (at least) 3 display planes:
-
-* A: primary display plane
-
-* B: 'sprite' plane (for specific laptop display information?)
-
-* C: overlay plane (can also be directly sent in YUV format to DVO)
-
-The datasheet diagram shows overlay, sprite, two cursor, and primary and
-secondary display units. Maybe those correspond to the planes. The
-datasheet also meantions a popup plane for mobile applications.
-The single overlay plane can only displayed on "single-pipe simultanious 
-displays" for multi-monitors. (For the i810, 0x70008 PIXCONF
-has some of the functions used here.) For the i865, these registers
-seem to be somewhere else.
-
-|| 0x70180 || DSPACTRL Display plane A control                            ||
-|| 0x71180 || DSPBCTRL Display plane B control                            ||
-||<)>   31 || plane enable (1=enabled)                                    ||
-||<)>   30 || gamma correction enable (0=bypass, 1=enabled)               ||
-||<)>29:26 || pixformat (2=8BPP, 4=15_16BPP, 5=16BPP, 6=32BPP_NO_ALPHA, 7=32BPP) ||
-||<)>   25 || stereo enable (1=enabled)                                   ||
-||<)>   24 || select pipe (0=A, 1=B)                                      ||
-||<)>   23 || reserved                                                    ||
-||<)>   22 || source key enable (1=enabled)                               ||
-||<)>21:20 || pixel multiplicity (0=normal, 1=doubleline, 2=3=reserved)   ||
-||<)>   19 || reserved                                                    ||
-||<)>   18 || stereo polarity (0=first, 1=second)                         ||
-||<)>17-16 || reserved                                                    ||
-||<)>   15 || alpha transfer mode (1=enabled) ; B only                    ||
-||<)>14- 1 || reserved                                                    ||
-||<)>    0 || sprite_above (0=display A, 1=overlay) ; B only              ||
- 
-Note: 8BPP is indexed, 15_16BPP is 5-5-5, 16BPP is 5-6-5, 
-32BPP_NO_ALPHA is X:8:8:8, and 32BPP is 8:8:8:8.
-
-Note: Stereo requires two start (base) addresses, at least for plane B.
-
-It is not clear why a display plane has to connect to a pipe, instead
-of the other way round, unless the plane block also contains the
-counters.
-
-|| 0x70184 || DSPABASE Display plane A base address
-|| 0x71184 || DSPBBASE Display plane B base address
-
-|| 0x70188 || DSPASTRIDE Display plane A stride (= pitch)
-|| 0x71188 || DSPBSTRIDE Display plane B stride (= pitch)
-||<)>31-16 || UNKNOWN, 15CF/0001
-||<)> ?- 0 || stride
-
-== Pipes ==
-
-There are two pipes, which control the timing. 
-
-|| 0x60000 || HTOTAL_A                         ||
-|| 0x60004 || HBLANK_A                         ||
-|| 0x60008 || HSYNC_A                          ||
-|| 0x6000c || VTOTAL_A                         ||
-|| 0x60010 || VBLANK_A                         ||
-|| 0x60014 || VSYNC_A                          ||
-|| 0x6001c || PIPEASRC                         ||
-||<)>26:16 || horizontal (= HTOTAL displayed)  ||
-||<)>10: 0 || vertical   (= VTOTAL displayed)  ||
-|| 0x60020 || BCLRPAT border color pattern     ||
-
-Identical registers for pipe B are at 0x61000-0x61020.
-
-On the i810, there also was the LCDTV_C register, which is probably
-not any longer supported.
-
-|| 0x60018 || LCDTV_C LCD/TV-Out control register ||
-
-|| 0x70008 || PIPEACONF (PIXCONF for i810) ||
-||<)>   31 || enable (1=enabled)           ||
-||<)>   30 || width (1=double, 0=single)   ||
-||<)>29:27 || reserved                     ||
-||<)>   25 || lock (1=locked) ; unclear    ||
-||<)>   24 || (0=palette, 1=gamma)         ||
-||<)>23: 0 || reserved                     ||
-|| 0x71008 || PIPEBCONF                    ||
-||<)>   31 || enable (1=enabled)           ||
-||<)>30:25 || reserved                     ||
-||<)>   24 || (0=palette, 1=gamma)         ||
-||<)>23: 0 || reserved                     ||
-
-|| 0x71400 || UNKNOWN (= 0020008e) ||
-
-== Analog/Digital Ports ==
-
-There are three dedicated Digital Video Ports and one Analog Port.
-DVOB and C are multixplexed with the AGP pins. The local flat panel
-(LFP) is normally connected to DVOA. DVOB and DVOC may be combined
-into one 24bit wide port. DVO port signals are:
-
-|| CLK/CLK# || differental clock output up to 165 MHz                        ||
-|| D[11:0]  || 12bit data                                                    ||
-|| HSYNC    || outgoing HSync with programmable polarity                     ||
-|| VSYNC    || outgoing VSync with programmable polarity                     ||
-|| BLANK#   || outgoing blank period or border period signal                 ||
-|| INTR     || incoming interrupt (DVOA and DVOBC)                           ||
-|| CLKINT   || incoming clock or second interrupt (DVOA and DVOBC)           ||
-|| FLD/STL  || incoming TV field (to synchronize overlay) or FP stall signal ||
-
-The DPLL registers control the phase locked loops that convert the
-incoming to the outgoing clock, or possibly some internal clock to
-the outgoing clock. They are associated to the corresponding pipe.
-
-|| 0x06014 || DPLL_A                                                 ||
-|| 0x06018 || DPLL_B                                                 ||
-||<)>   31 || VCO enable (=1 for TFT, TV, mon)                       ||
-||<)>   30 || 2X clock enable (=1 for TFT, TV; =0 for mon)           ||
-||<)>   29 || synclock enable (=0)                                   ||
-||<)>   28 || VGA mode disable (=1 for TFT, TV, mon; =0 mon)         ||
-||<)>27:24 || reserved                                               ||
-||<)>   24 || [i???] PLL divisor select                              ||
-||<)>   23 || P2 post divisor (loop divide flag?)                    ||
-||<)>   22 || reserved                                               ||
-||<)>   21 || P1 force DIV2                                          ||
-||<)>20:16 || P1 post divisor                                        ||
-||<)>   15 || reserved                                               ||
-||<)>14:13 || reference select (=0 for LCD/mon, =2 for TV ?)         ||
-||<)>12: 0 || reserved                                               ||
-||<)>    1 || [i???] rate select mask (0=fp0, 1=fp1)                 ||
-
-There seems to be additional PLLs for the flat panel. (FIXME: Dave,
-please add a detailed explanation).
-
-|| 0x06040 || FPA0 flat panel PLL A0 ||
-|| 0x06044 || FPA1 flat panel PLL A1 ||
-|| 0x06048 || FPB0 flat panel PLL B0 ||
-|| 0x0604C || FPB1 flat panel PLL B1 ||
-||<)>21:16 || N			     ||
-||<)>13: 8 || M1		     ||
-||<)> 5: 0 || M2                     ||
-
-where M = 5*(M1+2) + (M2+2), and Clk = RefCLK * M / (N+2) / P
-
-The ADPA register controls the analog output (monitor).
-
-|| 0x61100 || ADPA                                                   ||
-||<)>   31 || DAC enable (1=enabled) (=monitor enabled)              ||
-||<)>   30 || Pipe select (0=A, 1=B) [maybe doesn't work]            ||
-||<)>29:16 || reserved                                               ||
-||<)>   15 || Use_VGA_HVPolarity (0=Sets HVPolarity)                 ||
-||<)>14:12 || UNKNOWN                                                ||
-||<)>   11 || VSync control disable (1=disabled)                     ||
-||<)>   10 || HSync control disable (1=disabled)                     ||
-||<)> 9: 5 || reserved                                               ||
-||<)>    4 || VSync active (0=low, 1=high)                           ||
-||<)>    3 || HSync active (0=low, 1=high)                           ||
-||<)> 2: 0 || reserved                                               ||
-
-For the 3 DVO ports, only the enable bit is known. Other bits may
-include interrupt handling, polarity control for blank and sync signals,
-configuration of clock vs. second interrupt and field vs. stall.
-
-|| 0x61120 || DVOA                            ||
-|| 0x61140 || DVOB                            ||
-|| 0x61160 || DVOC                            ||
-||<)>   31 || DVO enable (1=enabled)          ||
-||<)>   30 || Pipe select (guess!) (0=A, 1=B) ||
-||<)>   29 || UNKNOWN			      ||
-||<)>15: 0 || UNKNOWN			      ||
-||<)>   14 || UNKNOWN			      ||
-||<)>    8 || UNKNOWN			      ||
-||<)>    7 || UNKNOWN			      ||
-||<)>    6 || UNKNOWN			      ||
-||<)>    4 || UNKNOWN			      ||
-||<)>    3 || UNKNOWN			      ||
-||<)>    2 || UNKNOWN			      ||
-
-This is used in i855 instead of DVO.
-
-|| 0x61180 || LVDS meaning unknown ||
-  
-|| 0x61124 || DVOA_SRCDIM    ||
-|| 0x61144 || DVOB_SRCDIM    ||
-|| 0x61164 || DVOC_SRCDIM    ||
-||<)>23:12 || (not needed ?) ||
-||<)>11: 0 || (not needed ?) ||
-
-FIXME: What about 0x61104 ADPA_SRCDIM? and 0x61184 LVDS_SRCDIM?
-Maybe used for centering?
-                                    
-== Other registers ==
-
-|| 0x020cc || UNKNOWN = 000c000c / 0000004c ||
-
-There are now two watermark registers, with a format different from
-the I810 FW_BLC register.
-
-|| 0x020d8 || Watermark/Burst = 01080108 ||
-|| 0x020dc || Watermark/Burst = 00000108 ||
-||   31:27 || reserved			 ||
-||   26:24 || Burst B			 ||
-||   23:21 || reserved			 ||
-||   20:16 || Watermark B		 ||
-||   15:12 || reserved			 ||
-||   11: 8 || Burst A			 ||
-||    7: 6 || reserved			 ||
-||    5: 0 || Watermark A                ||
-
-Software Flags (= scratch registers):
-
-|| 0x71410 || SWF0                                    ||
-|| 0x71414 || SWF1 (amount of video memory available) ||
-|| 0x71418 || SWF2 				      ||
-|| 0x7141c || SWF3 				      ||
-|| 0x71420 || SWF4 				      ||
-|| 0x71424 || SWF5 				      ||
-|| 0x71428 || SWF6                                    ||
-
-
-
diff --git a/JeanChristopheCardot.mdwn b/JeanChristopheCardot.mdwn
new file mode 100644
index 0000000..b5afc18
--- /dev/null
+++ b/JeanChristopheCardot.mdwn
@@ -0,0 +1,4 @@
+
+[[http://cardot.net|http://cardot.net]] 
+
+freedesktop at cardot dot net 
diff --git a/JeanChristopheCardot.moin b/JeanChristopheCardot.moin
deleted file mode 100644
index 7876843..0000000
--- a/JeanChristopheCardot.moin
+++ /dev/null
@@ -1,3 +0,0 @@
-http://cardot.net
-
-freedesktop at cardot dot net
diff --git a/JeffWaddell.mdwn b/JeffWaddell.mdwn
new file mode 100644
index 0000000..8d21fc2
--- /dev/null
+++ b/JeffWaddell.mdwn
@@ -0,0 +1,22 @@
+
+
+## Jeff Waddell
+Email
+: 
+[[jefferydouglaswaddell@gmail.com|mailto:jefferydouglaswaddell@gmail.com]] 
+
+
+Homepage
+: none currently 
+
+Interests
+: 
+      * mach64 dri 
+      * i810 dri 
+
+
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/JeffWaddell.moin b/JeffWaddell.moin
deleted file mode 100644
index 3b88e76..0000000
--- a/JeffWaddell.moin
+++ /dev/null
@@ -1,12 +0,0 @@
-== Jeff Waddell ==
-
- Email:: jefferydouglaswaddell@gmail.com
-
- Homepage:: none currently
-
- Interests::
-   * mach64 dri
-   * i810 dri
-
-----
-CategoryHomepage
diff --git a/JensOwen.mdwn b/JensOwen.mdwn
new file mode 100644
index 0000000..500086d
--- /dev/null
+++ b/JensOwen.mdwn
@@ -0,0 +1,19 @@
+
+
+## Jens Owen
+
+[[!img http://www.tungstengraphics.com/photos/jens.jpg] 
+Email
+: jens at tungstengraphics dot com 
+
+Interests
+: 
+   * DRI ([[DriHistory|DriHistory]]) 
+   * TG 
+
+
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/JensOwen.moin b/JensOwen.moin
deleted file mode 100644
index 629cc4f..0000000
--- a/JensOwen.moin
+++ /dev/null
@@ -1,12 +0,0 @@
-== Jens Owen ==
-
-{{http://www.tungstengraphics.com/photos/jens.jpg}}
-
- Email:: jens at tungstengraphics dot com
-
- Interests::
-  * DRI (DriHistory)
-  * TG
-
-----
-CategoryHomepage
diff --git a/JesseZhang.mdwn b/JesseZhang.mdwn
new file mode 100644
index 0000000..cb43245
--- /dev/null
+++ b/JesseZhang.mdwn
@@ -0,0 +1,4 @@
+
+Hi. 
+
+zh.jesse gmail com 
diff --git a/JesseZhang.moin b/JesseZhang.moin
deleted file mode 100644
index 974a317..0000000
--- a/JesseZhang.moin
+++ /dev/null
@@ -1,3 +0,0 @@
-Hi.
-
-zh.jesse gmail com
diff --git a/JonSmirl.mdwn b/JonSmirl.mdwn
new file mode 100644
index 0000000..116b3b6
--- /dev/null
+++ b/JonSmirl.mdwn
@@ -0,0 +1,13 @@
+
+
+## Jon Smirl
+
+* Email: [[jonsmirl@gmail.com]] Interests
+: 
+      * DRM 
+      * X on GL 
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/JonSmirl.moin b/JonSmirl.moin
deleted file mode 100644
index f6cfad1..0000000
--- a/JonSmirl.moin
+++ /dev/null
@@ -1,10 +0,0 @@
-== Jon Smirl ==
-
- Email: <<MailTo(jonsmirl@gmail.com)>>
-
- Interests::
-   * DRM
-   * X on GL
-
-----
-CategoryHomepage
diff --git a/JoseFonseca.mdwn b/JoseFonseca.mdwn
new file mode 100644
index 0000000..2fe9219
--- /dev/null
+++ b/JoseFonseca.mdwn
@@ -0,0 +1,21 @@
+
+
+## José Fonseca
+Email
+: jrfonseca at vmware dot com 
+
+Blog
+: 
+[[http://jrfonseca.blogspot.com/|http://jrfonseca.blogspot.com/]] 
+
+
+Interests
+: 
+      * [[Gallium3D|Gallium3D]] 
+
+
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/JoseFonseca.moin b/JoseFonseca.moin
deleted file mode 100644
index 40fd07e..0000000
--- a/JoseFonseca.moin
+++ /dev/null
@@ -1,11 +0,0 @@
-== José Fonseca ==
-
- Email:: jrfonseca at vmware dot com
-
- Blog:: http://jrfonseca.blogspot.com/
-
- Interests::
-   * [[Gallium3D]]
-
-----
-CategoryHomepage
diff --git a/KDrive.mdwn b/KDrive.mdwn
new file mode 100644
index 0000000..41031b9
--- /dev/null
+++ b/KDrive.mdwn
@@ -0,0 +1,15 @@
+
+
+## KDrive
+
+KDrive, formerly known as TinyX, is a trimmed down X server written by [[KeithPackard|KeithPackard]], and also used in some Linux distributions targeted to handhelds, internet appliances and similar. 
+
+
+### Resources
+
+   * [[Juliusz Chroboczek's notes about KDrive|http://www.pps.jussieu.fr/~jch/software/kdrive.html]] 
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/KDrive.moin b/KDrive.moin
deleted file mode 100644
index a794203..0000000
--- a/KDrive.moin
+++ /dev/null
@@ -1,12 +0,0 @@
-== KDrive ==
-
-KDrive, formerly known as TinyX, is a trimmed down X server written by
-KeithPackard, and also used in some Linux distributions targeted to handhelds,
-internet appliances and similar.
-
-=== Resources ===
-
-  * [[http://www.pps.jussieu.fr/~jch/software/kdrive.html|Juliusz Chroboczek's notes about KDrive]]
-  
-----
-CategoryGlossary
diff --git a/KMSFirstSteps.mdwn b/KMSFirstSteps.mdwn
new file mode 100644
index 0000000..300b745
--- /dev/null
+++ b/KMSFirstSteps.mdwn
@@ -0,0 +1,6 @@
+
+Not too much to see, but link to GSoC-2010 work by Matt Turner: 
+
+[[GLINT KMS driver and documentation|http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz&can=2&q=]] 
+
+Also, see [[single commit|http://git.kernel.org/?p=linux/kernel/git/csimpson/linux-2.6.git;a=shortlog;h=refs/heads/tdfx-kms]], adding very initial implementation of tdfx  KMS driver 
diff --git a/KMSFirstSteps.moin b/KMSFirstSteps.moin
deleted file mode 100644
index d755cc7..0000000
--- a/KMSFirstSteps.moin
+++ /dev/null
@@ -1,5 +0,0 @@
-Not too much to see, but link to GSoC-2010 work by Matt Turner:
-
-[[http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz&can=2&q= | GLINT KMS driver and documentation ]]
-
-Also, see [[ http://git.kernel.org/?p=linux/kernel/git/csimpson/linux-2.6.git;a=shortlog;h=refs/heads/tdfx-kms | single commit ]], adding very initial implementation of tdfx  KMS driver
diff --git a/KeithWhitwell.mdwn b/KeithWhitwell.mdwn
new file mode 100644
index 0000000..99763ac
--- /dev/null
+++ b/KeithWhitwell.mdwn
@@ -0,0 +1,20 @@
+
+
+## KeithWhitwell
+
+[[!img http://www.tungstengraphics.com/photos/keith.jpg] 
+Email
+: keithw at tungstengraphics dot com 
+
+Interests
+: 
+      * UtahGLX ([[DriHistory|DriHistory]]) 
+      * Mesa 
+      * ATIRadeon driver 
+
+
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/KeithWhitwell.moin b/KeithWhitwell.moin
deleted file mode 100644
index 427ec32..0000000
--- a/KeithWhitwell.moin
+++ /dev/null
@@ -1,13 +0,0 @@
-== KeithWhitwell ==
-
-{{http://www.tungstengraphics.com/photos/keith.jpg}}
-
- Email:: keithw at tungstengraphics dot com
-
- Interests::
-   * UtahGLX (DriHistory)
-   * Mesa
-   * ATIRadeon driver
-
-----
-CategoryHomepage
diff --git a/LeifDelgass.mdwn b/LeifDelgass.mdwn
new file mode 100644
index 0000000..295f155
--- /dev/null
+++ b/LeifDelgass.mdwn
@@ -0,0 +1,21 @@
+
+
+## Leif Delgass
+Email
+: ldelgass at retinalburn dot net 
+
+Homepage
+: 
+[[http://www.retinalburn.net/linux/|http://www.retinalburn.net/linux/]] 
+
+
+Interests
+: 
+      * ATIMach64 driver 
+
+
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/LeifDelgass.moin b/LeifDelgass.moin
deleted file mode 100644
index d379645..0000000
--- a/LeifDelgass.moin
+++ /dev/null
@@ -1,11 +0,0 @@
-== Leif Delgass ==
-
- Email:: ldelgass at retinalburn dot net
-
- Homepage:: http://www.retinalburn.net/linux/
-
- Interests::
-   * ATIMach64 driver
-
-----
-CategoryHomepage
diff --git a/Links.mdwn b/Links.mdwn
new file mode 100644
index 0000000..dd432b4
--- /dev/null
+++ b/Links.mdwn
@@ -0,0 +1,80 @@
+
+
+# DRI related Links
+
+[[Mesa3D|http://www.mesa3d.org]] Primary parent project .  
+
+[[XFree86(TM): Home Page|http://www.xfree86.org]] Primary parent project [windowing system]. 
+
+[[X.org home page|http://www.x.org/wiki/]] New primary parent project [windowing system, forked from Xfree86]. 
+
+[[Precision Insight, Inc.|http://www.precisioninsight.com]] The original company responsible for creating the DRI. 
+
+**Link dead**, [[archived link|http://web.archive.org/web/20001205052900/http://www.precisioninsight.com/]] 
+
+[[VA Software|http://www.valinux.com]] VA Software bought out Precision Insight, Inc. in April 2000. In August of 2001 the Precision Insight team was laid off. 
+
+**Link dead**, [[archived one|http://web.archive.org/web/20060612061311/www.vasoftware.com/]] 
+
+[[Tungsten Graphics, Inc.|http://www.tungstengraphics.com]] The new home for DRI development.  
+
+**Link wrong**, archived copy from early times (April, 2008): [[archive|http://web.archive.org/web/20080522090134/http://www.tungstengraphics.com/index.html]] 
+
+[[Utah-GLX|http://utah-glx.sourceforge.net]] Precursor to DRI project. 
+
+[[GATOS|http://gatos.sourceforge.net/]] General ATI TV and Overlay Software 
+
+[[v4l|http://www.exploits.org/v4l/]] Video for Linux 
+
+[[v4l2|http://www.thedirks.org/v4l2/]] Video for Linux Two 
+
+[[Chromium Project (The)|http://chromium.sourceforge.net]] Interactive rendering on clusters of workstations 
+
+[[FbDri|http://fbdri.sourceforge.net]] 3D graphics in the Framebuffer console 
+
+
+## Graphics Card Manufacturers:
+
+[[3DFX|http://www.3dfx.com]] Out of business, but provided Open Source DRI Drivers 
+
+[[3D Labs|http://www.3dlabs.com]] Open Source (DRI) and proprietary Drivers 
+
+[[ATI|http://www.ati.com]] Open Source (DRI) and proprietary Drivers 
+
+[[Intel|http://www.intel.com]] Open Source DRI Drivers 
+
+[[Matrox|http://www.matrox.com]] Open Source DRI Driver with proprietary modules for additional features 
+
+[[nVidia|http://www.nvidia.com]] Proprietary Drivers using a proprietary direct rendering infrastructure 
+
+[[PowerVR|http://www.powervr.com]] Proprietary DRI Drivers 
+
+[[SiS|http://www.sis.com]] Open Source DRI Drivers 
+
+
+## Operating Systems that support DRI:
+
+[[Linux|http://www.kernel.org]] 
+
+[[FreeBSD|http://www.freebsd.org]] 
+
+
+## Linux Distros that support DRI:
+
+[[Debian|http://www.debian.org]] 
+
+[[Mandrake|http://www.mandrake.com]] 
+
+[[Red Hat|http://www.redhat.com]] 
+
+[[SuSE|http://www.suse.com]] 
+
+[[Gentoo|http://www.gentoo.org]] 
+
+
+
+---
+
+ Contributors: [[FrankWorsley|FrankWorsley]] [[JensOwen|JensOwen]] 
+
+Compiler: [[LiamSmit|LiamSmit]] 
diff --git a/Links.moin b/Links.moin
deleted file mode 100644
index d5a953e..0000000
--- a/Links.moin
+++ /dev/null
@@ -1,73 +0,0 @@
-= DRI related Links =
-
-[[http://www.mesa3d.org|Mesa3D]] Primary parent project . 
-
-[[http://www.xfree86.org|XFree86(TM): Home Page]] Primary parent project [windowing system].
-
-[[http://www.x.org/wiki/| X.org home page]] New primary parent project [windowing system, forked from Xfree86].
-
-[[http://www.precisioninsight.com|Precision Insight, Inc.]] The original company responsible for creating the DRI.
-
-'''Link dead''', [[http://web.archive.org/web/20001205052900/http://www.precisioninsight.com/ | archived link]]
-
-[[http://www.valinux.com|VA Software]] VA Software bought out Precision Insight, Inc. in April 2000. In August of 2001 the Precision Insight team was laid off.
-
-'''Link dead''', [[ http://web.archive.org/web/20060612061311/www.vasoftware.com/| archived one]]
-
-
-[[http://www.tungstengraphics.com|Tungsten Graphics, Inc.]] The new home for DRI development. 
-
-'''Link wrong''', archived copy from early times (April, 2008): [[ http://web.archive.org/web/20080522090134/http://www.tungstengraphics.com/index.html| archive ]]
-
-[[http://utah-glx.sourceforge.net|Utah-GLX]] Precursor to DRI project.
-
-[[http://gatos.sourceforge.net/|GATOS]] General ATI TV and Overlay Software
-
-[[http://www.exploits.org/v4l/|v4l]] Video for Linux
-
-[[http://www.thedirks.org/v4l2/|v4l2]] Video for Linux Two
-
-[[http://chromium.sourceforge.net|Chromium Project (The)]] Interactive rendering on clusters of workstations
-
-[[http://fbdri.sourceforge.net|FbDri]] 3D graphics in the Framebuffer console
-
-== Graphics Card Manufacturers: ==
-
-[[http://www.3dfx.com|3DFX]] Out of business, but provided Open Source DRI Drivers
-
-[[http://www.3dlabs.com|3D Labs]] Open Source (DRI) and proprietary Drivers
-
-[[http://www.ati.com|ATI]] Open Source (DRI) and proprietary Drivers
-
-[[http://www.intel.com|Intel]] Open Source DRI Drivers
-
-[[http://www.matrox.com|Matrox]] Open Source DRI Driver with proprietary modules for additional features
-
-[[http://www.nvidia.com|nVidia]] Proprietary Drivers using a proprietary direct rendering infrastructure
-
-[[http://www.powervr.com|PowerVR]] Proprietary DRI Drivers
-
-[[http://www.sis.com|SiS]] Open Source DRI Drivers
-
-== Operating Systems that support DRI: ==
-
-[[http://www.kernel.org|Linux]]
-
-[[http://www.freebsd.org|FreeBSD]]
-
-== Linux Distros that support DRI: ==
-
-[[http://www.debian.org|Debian]]
-
-[[http://www.mandrake.com|Mandrake]]
-
-[[http://www.redhat.com|Red Hat]]
-
-[[http://www.suse.com|SuSE]]
-
-[[http://www.gentoo.org|Gentoo]]
-
-----
-Contributors: FrankWorsley JensOwen
-
-Compiler: LiamSmit
diff --git a/LinusTorvalds.moin b/LinusTorvalds.mdwn
index 39f8111..f523efc 100644
--- a/LinusTorvalds.moin
+++ b/LinusTorvalds.mdwn
@@ -1 +1,2 @@
-Perhaps there should be short writeup about Linus Here.  I don't know enough about him to write it myself.
+
+Perhaps there should be short writeup about Linus Here.  I don't know enough about him to write it myself. 
diff --git a/Linux.mdwn b/Linux.mdwn
new file mode 100644
index 0000000..f84653a
--- /dev/null
+++ b/Linux.mdwn
@@ -0,0 +1,24 @@
+
+
+# Linux
+
+Linux is a clone of the operating system Unix, written from scratch by Linus Torvalds with assistance from a loosely-knit team of hackers across the Net. It aims towards POSIX and Single UNIX Specification compliance. 
+
+
+## Status
+
+The Linux OS is fully supported by DRI. 
+
+
+## Resources
+
+   * [[The Linux Kernel Archives|http://www.kernel.org/]] 
+   * [[Linux Kernel Module Programming Guide|http://tldp.org/LDP/lkmpg/2.6/html/index.html]] 
+   * [[Linux Device Drivers|http://www.oreilly.com/catalog/linuxdrive2/]] 
+   * [[The Linux Kernel|http://tldp.org/LDP/tlk/tlk.html]] 
+   * [[KernelNewbies.org|http://www.kernelnewbies.org/]] 
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]], [[CategoryOperatingSystem|CategoryOperatingSystem]] 
diff --git a/Linux.moin b/Linux.moin
deleted file mode 100644
index 122844c..0000000
--- a/Linux.moin
+++ /dev/null
@@ -1,22 +0,0 @@
-= Linux =
-
-Linux is a clone of the operating system Unix, written from scratch by Linus Torvalds with assistance from a loosely-knit team of hackers across the Net. It aims towards POSIX and Single UNIX Specification compliance.
-
-== Status ==
-
-The Linux OS is fully supported by DRI.
-
-== Resources ==
-
-  * [[http://www.kernel.org/|The Linux Kernel Archives]]
-
-  * [[http://tldp.org/LDP/lkmpg/2.6/html/index.html|Linux Kernel Module Programming Guide]]
-
-  * [[http://www.oreilly.com/catalog/linuxdrive2/|Linux Device Drivers]]
-
-  * [[http://tldp.org/LDP/tlk/tlk.html|The Linux Kernel]]
-
-  * [[http://www.kernelnewbies.org/|KernelNewbies.org]]
-
-----
-CategoryGlossary, CategoryOperatingSystem
diff --git a/LinuxWorld.mdwn b/LinuxWorld.mdwn
new file mode 100644
index 0000000..f84be50
--- /dev/null
+++ b/LinuxWorld.mdwn
@@ -0,0 +1,2 @@
+
+LinuxWorld is a conference and expo for Linux OS centric companys and [[FreeSoftware|FreeSoftware]] people. It got held e.g. in Frankfurt/Main, Germany. 
diff --git a/LinuxWorld.moin b/LinuxWorld.moin
deleted file mode 100644
index 0de7cd8..0000000
--- a/LinuxWorld.moin
+++ /dev/null
@@ -1,2 +0,0 @@
-LinuxWorld is a conference and expo for Linux OS centric companys and FreeSoftware people.
-It got held e.g. in Frankfurt/Main, Germany.
diff --git a/LocalBadContent.mdwn b/LocalBadContent.mdwn
new file mode 100644
index 0000000..0abf199
--- /dev/null
+++ b/LocalBadContent.mdwn
@@ -0,0 +1,2 @@
+
+51dragon.com tjht.net xianliming.com pdxx.com junyuan.com.cn dotas.com jialicn.com furensteel.cn \.info 
diff --git a/LocalBadContent.moin b/LocalBadContent.moin
deleted file mode 100644
index 4243efa..0000000
--- a/LocalBadContent.moin
+++ /dev/null
@@ -1,14 +0,0 @@
-#format plain
-## Any line starting with a # will not be considered as regex,
-## but any other line will! So do not put other text or wiki markup on this page
-## or it will be considered as bad content, too - which might drive you crazy until
-## you notice what went wrong.
-51dragon.com
-tjht.net
-xianliming.com
-pdxx.com
-junyuan.com.cn
-dotas.com
-jialicn.com
-furensteel.cn
-\.info
diff --git a/LocalSpellingWords.moin b/LocalSpellingWords.mdwn
index d825c2f..dbb0acf 100644
--- a/LocalSpellingWords.moin
+++ b/LocalSpellingWords.mdwn
@@ -1,149 +1,144 @@
-1st 2nd Abend Checkbox Diffs Guten Haltet Hermann Homepage Info Jürgen
-Morgen Perl Platt Plattdeutsch Rechtschreibprüfung Spellchecker Zeitstempel
-automagically backtick blockquote browser calendaring distutils doesn email
-english folgendes foo german html http hyperlinks info internet lowercase
-markup may moin moinmoin morphed navigational preformatted renumbered shouldn
-spam uppercase wiki wikis www überschneidet übersetzen
-Administratoren Hauptkopie Hilfeseiten Standardverhalten auch auf benutzt bitte dann das dem der diese diesen durch ein eine einem einer erklärt erzeugt finden für gehen haben hinzufügen ist keine lesen mehr müssen neu nur oder wenn werden
-
-alle arbeiten bei beim beschreiben nicht noch sich sie sind sollen und vorhandene wichtig wie
-
-Benachrichtigung Seitenvorlagen automatisch dass neue personalisiert zusätzliche zwei über
-
-senden
-
-Architekturen Bluetooth Browsers Dateifreigaben Editierfeld Einzelwort Falschinformation Freiform Fußbereich Hilfeseite Intranet Klicken Konventionen Kopfbereich Lupen Rechtschreibkorrekturen Schablonen Seitenaufbau Seitentitel Unfug Wildcards alles ausbügeln einen erstellen
-
-Volltextsuche Zeile Zope alte andere angeboten anstatt da dadurch damit
-
-dort
-
-falsch fertig fragen funktioniert ganz ganze gar geben gegen generell generieren gerne hinzu jeder kommen machen meine meist mit notwendig schreiben sicher sobald soll sollte sollten
-
-ändern
-
-Codebasis Farmen Hilfethemen Konfigurationsvariable Präfixen Unterthemen besonders einsetzen folgende gemeinsame hierfür mehrere optimieren umzuleiten verwendet von weitere zeigt zu zum
-
-Intranets kann
-
-Erkundung Hochkommata Kleinbuchstabe Seitenname Seitentitels Standardseite Zeichenkodierungen Zeichensätzen aktuelle anderer asiatische aus befindet beliebt bilden bis daher daraus dargestellt darüber deren dieser editieren eines einfaches erzeugen es führt gemeinschaftliches genau geändert groß klicken leere lernen nach ohne sein speichern spezielle um unteren verschiedene westliche wird zurück üblicherweise
-
-einschließen fett im jede siehe vertraut vor weiter weiteres
-
-gefügte
-
-Beispielanwendung Druckversion Edititieren Metadaten Navigationshilfen Schnellsuche Seitentexten Seitentiteln Suchseite Teilworte anzuschalten benutzerspezifische bereits einige ermöglicht experimentell insbesondere invertierten klickt originalen rückwärts sowie zusätzlich zwischen übergeordneten
-
-Benutzerformat Benutzers Editierbereich Hyperlink Löschfunktion Seitenbereichen Systemformat Variablenersetzung Verarbeitungsanweisungen befolgen davon deshalb ersetzt folgenden ihre ihren lädt normalerweise sehr übliche
-
-Verlinken
-
-diff gif xml
-
-angeschaltet optionale
-
-Abschnittsüberschriften Genaueres Seitenamen Seitenformatierng Smileys Textformatierungen Textformatierungsregeln allgemeine dazu eingebettete eingerückte experimentieren externe gleichzeitg horizontale neuem sachverwandte unter zusammen
-
-Trennlinien Öffne
-
-Auflisten Benutzereinstellungen Druckansicht Formularfelder Hauptanwendung Lesezeichen Navigationselemente Seiteninhalt Seitennamen Sicherungskopie Suchergebnisse Umbenennen anfangen anzeigen aufrufen benutzerdefinierten gewissen gibt implementiert komplett letzte nachdem nichts physikalisch sende solange speziell später vom wieder zur zusammenhängen
-
-manuell setzt
-
-py txt url
-
-Editierbar Webseite erste größte jeglichem platzieren regulären standardmäßig steht stellen textuelle unüblich viel viele wiederherstellt zufällig zwar Übergeben ähnlich übernehmen
-
-Webservers dieses geklickt hübscher jedes kollaborativ löschen ob paar richtig schreibe schwieriger selbst treiben triviale tut unsere unterhalb verschiedenste vorhaben welche wichtige wiederherzustellen ziemlich
-
-allgemeinen definieren dessen einfache einzelne einzurücken er erstelle existiert folgen gelöschten gestellt hineinstelle hinzufüge händisch ich jedem kleine konsistente kursiv könnten mittels org würde
-
-Administrieren Diskussionsfaden Dokumentenformate Schablonenseite Speicherort Versionshistorie Webserver Wortänderungen Zugriffskontrolle administriere darauf eingeben kollaborative mitunter namens wir wo
-
-Regelmäßige Seitenlayout Zusatzdateien konfigurieren
-
-Entwicklungsversion Installationsprozeduren Installationsszenarien Installationsvorgang Konfigurationsoptionen Plattformen Wikiadministrator ab auswählen betreiben bevor dabei darin eigenes einrichten empfohlen ihr immer installieren konkrete nächste nächsten zunächst
-
-Win32 vorgehen
-
-abgeschlossen deutsche originale vollendet
-
-Editiere
-
-Kommandozeile Seitendatei Seitendateien
-
-Hostsystems
-
-Diagnosewerkzeug Grundinstallation Hauptgrund Idealerweise Konfigurationsdatei Kurznamen Mindestmenge Problembehandlung Setupverfahren Systemseiten Verfahrensweise Wikinamen Zugriffsrechte bestücken interaktive seitherige standardmäßige standardmäßigen umstellen ähnlichem übriggebliebene
-
-cgi funktionsfähig updaten upgraden
-
-Wortdatei Wortdateien Wortzahl
-
-Mailinglisten Softwareentwickler
-
-at client in Lcore lib open plans the Xserver access apply are at be build call client commands different don for fork given have in is it linked list locking low making manner mesa must name normal of on only order part priority protocol protocols renders safe software spawn that the this time to unable use version way working writing
-
-accesses always and as can directly hardware internal maybe or others parts rendering share side similar something target three used with
-
-Free86
-
-Rage cards driver drivers graphics support supported
-
-Inc technologies ATI
-
-category glossary array devices free implementation input open popular source Wikipedia
-
-X11 vast
-
-adding help how test their wanted what yes you added also announcement any archives available based branch bump but by cause changes chip chips cleaned closed code compiling console could current do documentation doubtful ever extensions get glance going has help index information kernel like looks mapping merged mode most needs new no nor not now older original out page people plans port ported problems project quick read recently reference registers released report restore results routines save screen see some status stock such supports switch text texture their there those twister up using we when will work works your
-
-savage Tim Utah com interim mailing savage
-
-once
-
-assisted
-
-Radeon
-
-3D 3DFX action box clone configuration debugging direct download DRI FAQ find forge general hat history if intel links Linux macro market Matrox nature points power precision Python recent red sand several since special stereo testing things troubleshooting web why writers about accelerated add all allowing an another asked been being bottom browse change chipsets common company configuration continue contribute create currently database debugging definition developed developers development direct easy edit editing efficient emphasis environment exist exit experiment explained expression fast feel first follow form formed framework frequently from funded go highlighted history hosted hypertext images includes including incomplete initial joined just known learn libraries link lists logo major management many mark merger missing modification more net pages partially please png PNG point points power pressing produced question questions run search searches server several slang SourceForge space specific specification starting testing things through tips title together topics various wanted was ways website what where which words written wrong XFree86 yet you
-
-authorship capitalized contributed contributing infrastructure insight inter interesting miscellaneous parser Tungsten categories collaborative consult cooperation focal implementations initially integral integrates maintained stereoscopic subsequent
-
-acknowledgement beginner Piki
-
-uses
-
-would
-
-Memory Oh So address anything bandwidth both chose complex counts describe does done each external fun here highest honest host its latency leads let level me memory my normally own perform performance processor programming quickly require right sacrifice slave structure systems tell they transfer types typical wish
-
-allow barring compromises data interaction limitations operation
-
-Note Table While abstracted accelerator accomplished actual allocated avoid called compatibility completely concepts confused control dynamically ensures execute flexibility format function future independently interface issues master mechanism mechanisms miniport model operate operating other physical provided rather requires separate should specified structures system table these translation under via view walked
-
-contiguous
-
-device
-
-freebsd
-
-dri Dri Faq freedesktop sourceforge
-
-Chipset conf cvs devel drm Roadmap uploads xfree86 xorg
-
-ati
-
-sis530 softpixel
-
-sis530
-
-Rv350 rv360
-
-macros
-
-mesa3d
-
-databooks en en2 ftp htm I731 M731 pdf products4d R3 siliconmotion tw
-
-gmail i810 Interests Jeff jefferydouglaswaddell mach64 none Waddell
-\ No newline at end of file
+
+1st 2nd Abend Checkbox Diffs Guten Haltet Hermann Homepage Info Jürgen Morgen Perl Platt Plattdeutsch Rechtschreibprüfung Spellchecker Zeitstempel automagically backtick blockquote browser calendaring distutils doesn email english folgendes foo german html http hyperlinks info internet lowercase markup may moin moinmoin morphed navigational preformatted renumbered shouldn spam uppercase wiki wikis www überschneidet übersetzen Administratoren Hauptkopie Hilfeseiten Standardverhalten auch auf benutzt bitte dann das dem der diese diesen durch ein eine einem einer erklärt erzeugt finden für gehen haben hinzufügen ist keine lesen mehr müssen neu nur oder wenn werden 
+
+alle arbeiten bei beim beschreiben nicht noch sich sie sind sollen und vorhandene wichtig wie 
+
+Benachrichtigung Seitenvorlagen automatisch dass neue personalisiert zusätzliche zwei über 
+
+senden 
+
+Architekturen Bluetooth Browsers Dateifreigaben Editierfeld Einzelwort Falschinformation Freiform Fußbereich Hilfeseite Intranet Klicken Konventionen Kopfbereich Lupen Rechtschreibkorrekturen Schablonen Seitenaufbau Seitentitel Unfug Wildcards alles ausbügeln einen erstellen 
+
+Volltextsuche Zeile Zope alte andere angeboten anstatt da dadurch damit 
+
+dort 
+
+falsch fertig fragen funktioniert ganz ganze gar geben gegen generell generieren gerne hinzu jeder kommen machen meine meist mit notwendig schreiben sicher sobald soll sollte sollten 
+
+ändern 
+
+Codebasis Farmen Hilfethemen Konfigurationsvariable Präfixen Unterthemen besonders einsetzen folgende gemeinsame hierfür mehrere optimieren umzuleiten verwendet von weitere zeigt zu zum 
+
+Intranets kann 
+
+Erkundung Hochkommata Kleinbuchstabe Seitenname Seitentitels Standardseite Zeichenkodierungen Zeichensätzen aktuelle anderer asiatische aus befindet beliebt bilden bis daher daraus dargestellt darüber deren dieser editieren eines einfaches erzeugen es führt gemeinschaftliches genau geändert groß klicken leere lernen nach ohne sein speichern spezielle um unteren verschiedene westliche wird zurück üblicherweise 
+
+einschließen fett im jede siehe vertraut vor weiter weiteres 
+
+gefügte 
+
+Beispielanwendung Druckversion Edititieren Metadaten Navigationshilfen Schnellsuche Seitentexten Seitentiteln Suchseite Teilworte anzuschalten benutzerspezifische bereits einige ermöglicht experimentell insbesondere invertierten klickt originalen rückwärts sowie zusätzlich zwischen übergeordneten 
+
+Benutzerformat Benutzers Editierbereich Hyperlink Löschfunktion Seitenbereichen Systemformat Variablenersetzung Verarbeitungsanweisungen befolgen davon deshalb ersetzt folgenden ihre ihren lädt normalerweise sehr übliche 
+
+Verlinken 
+
+diff gif xml 
+
+angeschaltet optionale 
+
+Abschnittsüberschriften Genaueres Seitenamen Seitenformatierng Smileys Textformatierungen Textformatierungsregeln allgemeine dazu eingebettete eingerückte experimentieren externe gleichzeitg horizontale neuem sachverwandte unter zusammen 
+
+Trennlinien Öffne 
+
+Auflisten Benutzereinstellungen Druckansicht Formularfelder Hauptanwendung Lesezeichen Navigationselemente Seiteninhalt Seitennamen Sicherungskopie Suchergebnisse Umbenennen anfangen anzeigen aufrufen benutzerdefinierten gewissen gibt implementiert komplett letzte nachdem nichts physikalisch sende solange speziell später vom wieder zur zusammenhängen 
+
+manuell setzt 
+
+py txt url 
+
+Editierbar Webseite erste größte jeglichem platzieren regulären standardmäßig steht stellen textuelle unüblich viel viele wiederherstellt zufällig zwar Übergeben ähnlich übernehmen 
+
+Webservers dieses geklickt hübscher jedes kollaborativ löschen ob paar richtig schreibe schwieriger selbst treiben triviale tut unsere unterhalb verschiedenste vorhaben welche wichtige wiederherzustellen ziemlich 
+
+allgemeinen definieren dessen einfache einzelne einzurücken er erstelle existiert folgen gelöschten gestellt hineinstelle hinzufüge händisch ich jedem kleine konsistente kursiv könnten mittels org würde 
+
+Administrieren Diskussionsfaden Dokumentenformate Schablonenseite Speicherort Versionshistorie Webserver Wortänderungen Zugriffskontrolle administriere darauf eingeben kollaborative mitunter namens wir wo 
+
+Regelmäßige Seitenlayout Zusatzdateien konfigurieren 
+
+Entwicklungsversion Installationsprozeduren Installationsszenarien Installationsvorgang Konfigurationsoptionen Plattformen Wikiadministrator ab auswählen betreiben bevor dabei darin eigenes einrichten empfohlen ihr immer installieren konkrete nächste nächsten zunächst 
+
+Win32 vorgehen 
+
+abgeschlossen deutsche originale vollendet 
+
+Editiere 
+
+Kommandozeile Seitendatei Seitendateien 
+
+Hostsystems 
+
+Diagnosewerkzeug Grundinstallation Hauptgrund Idealerweise Konfigurationsdatei Kurznamen Mindestmenge Problembehandlung Setupverfahren Systemseiten Verfahrensweise Wikinamen Zugriffsrechte bestücken interaktive seitherige standardmäßige standardmäßigen umstellen ähnlichem übriggebliebene 
+
+cgi funktionsfähig updaten upgraden 
+
+Wortdatei Wortdateien Wortzahl 
+
+Mailinglisten Softwareentwickler 
+
+at client in Lcore lib open plans the Xserver access apply are at be build call client commands different don for fork given have in is it linked list locking low making manner mesa must name normal of on only order part priority protocol protocols renders safe software spawn that the this time to unable use version way working writing 
+
+accesses always and as can directly hardware internal maybe or others parts rendering share side similar something target three used with 
+
+Free86 
+
+Rage cards driver drivers graphics support supported 
+
+Inc technologies ATI 
+
+category glossary array devices free implementation input open popular source Wikipedia 
+
+X11 vast 
+
+adding help how test their wanted what yes you added also announcement any archives available based branch bump but by cause changes chip chips cleaned closed code compiling console could current do documentation doubtful ever extensions get glance going has help index information kernel like looks mapping merged mode most needs new no nor not now older original out page people plans port ported problems project quick read recently reference registers released report restore results routines save screen see some status stock such supports switch text texture their there those twister up using we when will work works your 
+
+savage Tim Utah com interim mailing savage 
+
+once 
+
+assisted 
+
+Radeon 
+
+3D 3DFX action box clone configuration debugging direct download DRI FAQ find forge general hat history if intel links Linux macro market Matrox nature points power precision Python recent red sand several since special stereo testing things troubleshooting web why writers about accelerated add all allowing an another asked been being bottom browse change chipsets common company configuration continue contribute create currently database debugging definition developed developers development direct easy edit editing efficient emphasis environment exist exit experiment explained expression fast feel first follow form formed framework frequently from funded go highlighted history hosted hypertext images includes including incomplete initial joined just known learn libraries link lists logo major management many mark merger missing modification more net pages partially please png PNG point points power pressing produced question questions run search searches server several slang [[SourceForge|SourceForge]] space specific specification starting testing things through tips title together topics various wanted was ways website what where which words written wrong XFree86 yet you 
+
+authorship capitalized contributed contributing infrastructure insight inter interesting miscellaneous parser Tungsten categories collaborative consult cooperation focal implementations initially integral integrates maintained stereoscopic subsequent 
+
+acknowledgement beginner Piki 
+
+uses 
+
+would 
+
+Memory Oh So address anything bandwidth both chose complex counts describe does done each external fun here highest honest host its latency leads let level me memory my normally own perform performance processor programming quickly require right sacrifice slave structure systems tell they transfer types typical wish 
+
+allow barring compromises data interaction limitations operation 
+
+Note Table While abstracted accelerator accomplished actual allocated avoid called compatibility completely concepts confused control dynamically ensures execute flexibility format function future independently interface issues master mechanism mechanisms miniport model operate operating other physical provided rather requires separate should specified structures system table these translation under via view walked 
+
+contiguous 
+
+device 
+
+freebsd 
+
+dri Dri Faq freedesktop sourceforge 
+
+Chipset conf cvs devel drm Roadmap uploads xfree86 xorg 
+
+ati 
+
+sis530 softpixel 
+
+sis530 
+
+Rv350 rv360 
+
+macros 
+
+mesa3d 
+
+databooks en en2 ftp htm I731 M731 pdf products4d R3 siliconmotion tw 
+
+gmail i810 Interests Jeff jefferydouglaswaddell mach64 none Waddell 
diff --git a/MAOS.mdwn b/MAOS.mdwn
new file mode 100644
index 0000000..fae274e
--- /dev/null
+++ b/MAOS.mdwn
@@ -0,0 +1,15 @@
+
+
+## Term
+
+MAOS is an acronym for multiple arrays of structures 
+
+
+### Resources
+
+   * [[some notes about radeon/r200 driver|http://dri.sourceforge.net/IRC-logs/20020318.txt]] 
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/MAOS.moin b/MAOS.moin
deleted file mode 100644
index 4ca1343..0000000
--- a/MAOS.moin
+++ /dev/null
@@ -1,10 +0,0 @@
-== Term ==
-
-MAOS is an acronym for multiple arrays of structures
-
-=== Resources ===
-
-  * [[http://dri.sourceforge.net/IRC-logs/20020318.txt|some notes about radeon/r200 driver]]
-
-----
-CategoryGlossary
diff --git a/MESAX_array_element_base.mdwn b/MESAX_array_element_base.mdwn
new file mode 100644
index 0000000..a841276
--- /dev/null
+++ b/MESAX_array_element_base.mdwn
@@ -0,0 +1,107 @@
+
+Name 
+
+         * MESAX_array_element_base 
+Name Strings 
+
+         * GL_MESAX_array_element_base 
+Contributors 
+
+         * Various people in the Advanced Coding forum on OpenGL.org 
+Contact 
+
+         * Ian Romanick, IBM (idr 'at' us.ibm.com) 
+IP Status 
+
+         * No known IP issues. 
+Status 
+
+         * TBD 
+Version 
+
+         * $Date: 2004/07/28 08:45:00$ $Revision: 0.3$ 
+Number 
+
+         * TBD 
+Dependencies 
+
+         * OpenGL 1.1 is required. This extension is written against the OpenGL 1.5 specification. 
+Overview 
+
+         * In existing element based drawing APIs in OpenGL, changing the location of vertex data can be an expensive operation.  GL_ARB_vertex_buffer_objects potentially makes this operation even more expensive.  Since lots of vertex data can be packed into a single vertex array or vertex buffer object, meshes with the same topology can avoid this expense by reusing the same element data with a different base element for each draw call. The API in this extension provides the ability for applications to do that. This extension came from a discussion on the Advanced Coding forum on OpenGL.org. [[http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=012219|http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=012219]] 
+Issues 
+
+         1. Is MESAX_array_element_base the right name for this extension?  The name choice and the choice of enum and function names was based on the EXT_compiled_vertex_array extension. 
+                              * YES.  Nobody seems to have a better name, and nobody seems to object to the current name. 
+         1. Should !ArrayElementBaseMESAX calls be compiled into display lists? 
+                              * YES.  The functionality does not seem very useful, but it is consistent with the rest of the API. 
+         1. Should there be a separate element base for each vertex array target?  It may be useful to use a different set of position and normal data for each mesh, but keep the same texture coordinate data, for example. 
+                              * NO.  Having a per-array base isn't really any different than resetting the pointer for the array.  The two main optimizations possible with this extension are having a single API call and being able to use a hardware base-index "register".  Having a per-array base defeats both. 
+         1. Should this extension really be MESAX? 
+                              * YES.  This is experimental functionality.  The resolution of issue #3 in particular may change the API radically.  Not only that, ISVs may find this extension to not be useful, and it will just go away. 
+         1. What happens when base+i overflows the range of the datatype supplied to DrawElements or DrawRangeElements? 
+                              * UNRESOLVED.  The current thinking is that it won't matter due to the way the extension is defined.  It is defined as a modification to the behavior of ArrayElement.  The type passed to ArrayElement is a signed int.  Some words may need to be added to the fifth paragraph on page 25 stating that if (base+i) overflows a signed int, the behavior is undefined. 
+         1. What happens if base+i is outside the [start, end] range passed to DrawRangeElements? 
+                              * RESOLVED.  No special wording is needed.  The 1.5 spec is very clear, on page 27, that it is the values in the supplied array that are contrained to [start, end].  Since it specifically states that it is the values in the indices array, the base value is never taken into consideration for the range clamping. 
+         1. Should negative base values be allowed? 
+                              * NO.  While this is somewhat arbitrary, it's not known how hardware with a base-index register would handle a negative value.  It also seems like a negative base value would "encourage" cases where (i+base) < 0.  If this extension is every promoted to a higher status, this issue may be revisited. 
+New Procedures and Functions 
+
+         * `ArrayElementBaseMESAX( uint base );` 
+New Tokens 
+
+         * Accepted by the <pname> parameter of GetIntegerv, GetFloatv, GetDoublev, or GetBooleanv: 
+                     * `ARRAY_ELEMENT_BASE_MESAX                         0xXXXXX` 
+Additions to Chapter 2 of the OpenGL 1.5 Specification (OpenGL Operation) 
+
+         * - (2.8, p. 25) Third paragraph changed to: "The n<sup>th</sup> element of every enabled array is transferred to the GL by calling: 
+               * `void ArrayElement(int i);` For each enabled array, it is as though the corresponding command from section 2.7 or section 2.6.2 were called with a pointer to element n. n is the sum of i and the current value of ARRAY_ELEMENT_BASE_MESAX...." - (2.8, p. 25) Fifth paragraph changed to: 
+"Specifying i < 0, even if the sum of i and ARRAY_ELEMENT_BASE_MESAX is >= 0, results in undefined behavior.  Generating the error INVALID_VALUE is recommended in this case." 
+- (2.8, p. 25) After the fifth paragraph insert: "The base element of all vertex arrays is set by calling: 
+               * `void ArrayElementBase(int i);` 
+Specifying i < 0 generates the error INVALID_VALUE." 
+
+Additions to Chapter 3 of the OpenGL 1.5 Specification (Rasterization) 
+
+         * None 
+Additions to Chapter 4 of the OpenGL 1.5 Specification (Per-Fragment Operations) 
+
+         * None 
+Additions to Chapter 5 of the OpenGL 1.5 Specification (Special Functions) 
+
+         * None 
+Additions to Chapter 6 of the OpenGL 1.5 Specification (State and State Requests) 
+
+         * None 
+Additions to Appendix A of the OpenGL 1.5 Specification (Invariance) 
+
+         * None 
+Additions to the AGL/GLX/WGL Specifications 
+
+         * None 
+GLX Protocol 
+
+         * TBD 
+Interactions with EXT_draw_range_elements 
+
+         * All functions whose operation is defined in terms of ArrayElement calls are implicitly and automatically affected by this extension. This includes but is not limited to DrawArrays, DrawElements, DrawRangeElements, MultiDrawArrays, MultiDrawElements, !MultiModeDrawArraysIBM, and !MultiModeDrawElementsIBM. 
+Errors 
+
+         * None 
+New State 
+
+         * Modified State in Table 6.6 (p. 232): [[!table header="no" class="mointable" data="""
+Get Value | Get Command | Type | Initial Value | Description | Section | Attribute
+ARRAY_ELEMENT_BASE_MESAX | GetIntegerv | Z+ | 0 | Base array element index | 2.8 | vertex-array
+"""]]
+
+New Implementation Dependent State 
+
+         * None 
+Revision History 
+
+         * [[!table header="no" class="mointable" data="""
+2004/07/26 | 0.1 | idr | Initial draft version.
+2004/07/27 | 0.2 | idr | Added issues #5 and #6. Added initial contributors list.
+2004/07/28 | 0.3 | idr | Added issue #7.  Fixed the wording of issue #2. Resolved issues #1 and #3.
+"""]]
diff --git a/MESAX_array_element_base.moin b/MESAX_array_element_base.moin
deleted file mode 100644
index 59c8247..0000000
--- a/MESAX_array_element_base.moin
+++ /dev/null
@@ -1,200 +0,0 @@
-Name
-
-    MESAX_array_element_base
-
-Name Strings
-
-    GL_MESAX_array_element_base
-
-Contributors
-
-    Various people in the Advanced Coding forum on OpenGL.org
-
-Contact
-
-    Ian Romanick, IBM (idr 'at' us.ibm.com)
-
-IP Status
-
-    No known IP issues.
-
-Status
-
-    TBD
-
-Version
-
-    $Date: 2004/07/28 08:45:00$ $Revision: 0.3$
-
-Number
-
-    TBD
-
-Dependencies
-
-    OpenGL 1.1 is required.
-    This extension is written against the OpenGL 1.5 specification.
-
-Overview
-
-    In existing element based drawing APIs in OpenGL, changing the location of
-    vertex data can be an expensive operation.  GL_ARB_vertex_buffer_objects
-    potentially makes this operation even more expensive.  Since lots of
-    vertex data can be packed into a single vertex array or vertex buffer
-    object, meshes with the same topology can avoid this expense by reusing
-    the same element data with a different base element for each draw call.
-    The API in this extension provides the ability for applications to do
-    that.
-
-    This extension came from a discussion on the Advanced Coding forum on
-    OpenGL.org.
-
-    http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=012219
-
-Issues
-
-    1. Is MESAX_array_element_base the right name for this extension?  The name choice and the choice of enum and function names was based on the EXT_compiled_vertex_array extension.
-       
-           YES.  Nobody seems to have a better name, and nobody seems to
-           object to the current name.
-
-    2. Should !ArrayElementBaseMESAX calls be compiled into display lists?
-
-           YES.  The functionality does not seem very useful, but it is
-           consistent with the rest of the API.
-
-    3. Should there be a separate element base for each vertex array target?  It may be useful to use a different set of position and normal data for each mesh, but keep the same texture coordinate data, for example.
-       
-           NO.  Having a per-array base isn't really any different than
-           resetting the pointer for the array.  The two main optimizations
-           possible with this extension are having a single API call and
-           being able to use a hardware base-index "register".  Having a
-           per-array base defeats both.
-
-    4. Should this extension really be MESAX?
-    
-           YES.  This is experimental functionality.  The resolution of
-           issue #3 in particular may change the API radically.  Not only
-           that, ISVs may find this extension to not be useful, and it will
-           just go away.
-
-    5. What happens when base+i overflows the range of the datatype supplied to !DrawElements or !DrawRangeElements?
-       
-           UNRESOLVED.  The current thinking is that it won't matter due to
-           the way the extension is defined.  It is defined as a modification
-           to the behavior of !ArrayElement.  The type passed to !ArrayElement
-           is a signed int.  Some words may need to be added to the fifth
-           paragraph on page 25 stating that if (base+i) overflows a signed
-           int, the behavior is undefined.
-
-    6. What happens if base+i is outside the [start, end] range passed to !DrawRangeElements?
-       
-           RESOLVED.  No special wording is needed.  The 1.5 spec is
-           very clear, on page 27, that it is the values in the supplied
-           array that are contrained to [start, end].  Since it specifically
-           states that it is the values in the indices array, the base
-           value is never taken into consideration for the range
-           clamping.
-
-    7. Should negative base values be allowed?
-
-           NO.  While this is somewhat arbitrary, it's not known how
-           hardware with a base-index register would handle a negative
-           value.  It also seems like a negative base value would
-           "encourage" cases where (i+base) < 0.  If this extension is
-           every promoted to a higher status, this issue may be revisited.
-
-New Procedures and Functions
-
-    {{{ArrayElementBaseMESAX( uint base );}}}
-
-New Tokens
-
-    Accepted by the <pname> parameter of !GetIntegerv, !GetFloatv, !GetDoublev,
-    or !GetBooleanv:
-
-        {{{ARRAY_ELEMENT_BASE_MESAX                         0xXXXXX}}}
-
-Additions to Chapter 2 of the OpenGL 1.5 Specification (OpenGL Operation)
-
-    - (2.8, p. 25) Third paragraph changed to:
-    
-    "The n^th^ element of every enabled array is transferred to the GL by
-    calling:
-    
-      {{{void ArrayElement(int i);}}}
-      
-    For each enabled array, it is as though the corresponding command from
-    section 2.7 or section 2.6.2 were called with a pointer to element n.
-    n is the sum of i and the current value of ARRAY_ELEMENT_BASE_MESAX...."
-
-    - (2.8, p. 25) Fifth paragraph changed to:
-    
-    "Specifying i < 0, even if the sum of i and ARRAY_ELEMENT_BASE_MESAX
-    is >= 0, results in undefined behavior.  Generating the error
-    INVALID_VALUE is recommended in this case."
-
-    - (2.8, p. 25) After the fifth paragraph insert:
-    
-    "The base element of all vertex arrays is set by calling:
-    
-      {{{void ArrayElementBase(int i);}}}
-      
-    Specifying i < 0 generates the error INVALID_VALUE."
-
-Additions to Chapter 3 of the OpenGL 1.5 Specification (Rasterization)
-
-    None
-
-Additions to Chapter 4 of the OpenGL 1.5 Specification (Per-Fragment Operations)
-
-    None
-
-Additions to Chapter 5 of the OpenGL 1.5 Specification (Special Functions)
-
-    None
-
-Additions to Chapter 6 of the OpenGL 1.5 Specification (State and State Requests)
-
-    None
-
-Additions to Appendix A of the OpenGL 1.5 Specification (Invariance)
-
-    None
-
-Additions to the AGL/GLX/WGL Specifications
-
-    None
-
-GLX Protocol
-
-    TBD
-
-Interactions with EXT_draw_range_elements
-
-    All functions whose operation is defined in terms of !ArrayElement
-    calls are implicitly and automatically affected by this extension.
-    This includes but is not limited to !DrawArrays, !DrawElements,
-    !DrawRangeElements, !MultiDrawArrays, !MultiDrawElements,
-    !MultiModeDrawArraysIBM, and !MultiModeDrawElementsIBM.
-
-Errors
-
-    None
-
-New State
-
-    Modified State in Table 6.6 (p. 232):
-
-||Get Value||Get Command||Type||Initial Value||Description||Section||Attribute||
-||ARRAY_ELEMENT_BASE_MESAX||!GetIntegerv||Z+||0||Base array element index||2.8||vertex-array||
-
-New Implementation Dependent State
-
-    None
-
-Revision History
-
-    ||2004/07/26||0.1||idr||Initial draft version.||
-    ||2004/07/27||0.2||idr||Added issues #5 and #6. Added initial contributors list.||
-    ||2004/07/28||0.3||idr||Added issue #7.  Fixed the wording of issue #2. Resolved issues #1 and #3.||
diff --git a/MMIO.mdwn b/MMIO.mdwn
new file mode 100644
index 0000000..9e94b8b
--- /dev/null
+++ b/MMIO.mdwn
@@ -0,0 +1,11 @@
+
+
+## Memory-Mapped Input-Output (MMIO)
+
+Like PIO, but the FIFO is directly memory mapped. Again, this means more to x86 as it has the wierd I/O vs. memory distinction that 68k, etc. do not have. The FIFO is of fixed length and writes to successive locations are writes "further down" the FIFO. Also, MMIO allows a set of registers to be directly addressed by location where in the PIO system they would be addressed by "write to register # to address register, write/read data to/from data register, repeat" kind of system. MMIO is genearlly simpler to program for than PIO, but PIO is a lot easier to design hardware for. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/MMIO.moin b/MMIO.moin
deleted file mode 100644
index cbd1079..0000000
--- a/MMIO.moin
+++ /dev/null
@@ -1,14 +0,0 @@
-== Memory-Mapped Input-Output (MMIO) ==
-
-Like PIO, but the FIFO is directly memory
-mapped. Again, this means more to x86 as it has the wierd I/O vs. memory
-distinction that 68k, etc. do not have. The FIFO is of fixed length and writes
-to successive locations are writes "further down" the FIFO. Also, MMIO allows
-a set of registers to be directly addressed by location where in the PIO
-system they would be addressed by "write to register # to address register,
-write/read data to/from data register, repeat" kind of system. MMIO is
-genearlly simpler to program for than PIO, but PIO is a lot easier to design
-hardware for.
-
-----
-CategoryGlossary
diff --git a/MTRR.mdwn b/MTRR.mdwn
new file mode 100644
index 0000000..9f18e2a
--- /dev/null
+++ b/MTRR.mdwn
@@ -0,0 +1,11 @@
+
+
+## Memory Type Range Register (MTRR)
+
+On Intel P6 family processors (Pentium Pro, Pentium !II and later) the Memory Type Range Registers (MTRR's) may be used to control processor access to memory ranges. This is most useful when you have a video (VGA) card on a PCI or AGP bus. Enabling write-combining allows bus write transfers to be combined into a larger transfer before bursting over the PCI / AGP bus. This can increase performance of image write operations 2.5 times or more. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/MTRR.moin b/MTRR.moin
deleted file mode 100644
index d8a4d5d..0000000
--- a/MTRR.moin
+++ /dev/null
@@ -1,12 +0,0 @@
-== Memory Type Range Register (MTRR) ==
-
-On Intel P6 family processors (Pentium
-Pro, Pentium !II and later) the Memory Type Range Registers (MTRR's) may be used
-to control processor access to memory ranges. This is most useful when you
-have a video (VGA) card on a PCI or AGP bus. Enabling write-combining allows
-bus write transfers to be combined into a larger transfer before bursting over
-the PCI / AGP bus. This can increase performance of image write operations 2.5
-times or more.
-
-----
-CategoryGlossary
diff --git a/MailingLists.mdwn b/MailingLists.mdwn
new file mode 100644
index 0000000..05fde9c
--- /dev/null
+++ b/MailingLists.mdwn
@@ -0,0 +1,37 @@
+
+
+## Mailing Lists
+
+If you need more help getting DRI to work on your Linux system then your best bet is to check out [[BugZilla|BugZilla]] or the Mesa and DRI mailing lists:   
+  
+
+
+### Mesa 3D and DRI
+
+   * **mesa-announce**: [[Subscribe/Unsubscribe/Preferences|http://lists.freedesktop.org/mailman/listinfo/mesa-announce]] Archives at: [[Freedesktop|http://lists.freedesktop.org/archives/mesa-announce]], [[MARC|http://marc.theaimsgroup.com/?l=mesa3d-announce&r=1&w=2]], [[Gmane|http://news.gmane.org/gmane.comp.video.mesa3d.announce]] 
+      * Announcemenents about Mesa (and DRI) releases. 
+   * **mesa-users**: [[Subscribe/Unsubscribe/Preferences|http://lists.freedesktop.org/mailman/listinfo/mesa-users]] Archives at: [[Freedesktop|http://lists.freedesktop.org/archives/mesa-users]], [[MARC|http://marc.theaimsgroup.com/?l=mesa3d-users&r=1&w=2]], [[Gmane|http://news.gmane.org/gmane.comp.video.mesa3d.user]] 
+      * A list for general Mesa and DRI questions and support issues. See dri-users below for the Direct Rendering Module discussion. 
+   * **mesa-dev**: [[Subscribe/Unsubscribe/Preferences|http://lists.freedesktop.org/mailman/listinfo/mesa-dev]] Archives at: [[Freedesktop|http://lists.freedesktop.org/archives/mesa-dev]], [[MARC|http://marc.theaimsgroup.com/?l=mesa3d-dev&r=1&w=2]], [[Gmane|http://news.gmane.org/gmane.comp.video.mesa3d.devel]] 
+      * Now a focal point of _both_ Mesa 3D and Direct Rendering Infrastructure accelerated OpenGL development discussion, since they are so largely intertwined. For the kernel Direct Rendering Manager module discussions, see dri-devel below. 
+   * **mesa-commit**: [[Subscribe/Unsubscribe/Preferences|http://lists.freedesktop.org/mailman/listinfo/mesa-commit]] Archives at: [[Freedesktop|http://lists.freedesktop.org/archives/mesa-commit/]], [[Gmane|http://news.gmane.org/gmane.comp.video.mesa3d.scm]] 
+      * Any checkins to the Mesa source tree are recorded on the mesa-commit mailing list, and so this list can get a significant amount of volume when development is active. 
+
+
+
+
+
+
+
+
+### Direct Rendering Modules in Linux/BSD kernels
+
+The old DRI mailing lists have changed their focus to purely DRM, while actual DRI driver discussions has moved to the Mesa mailing lists above. 
+
+   * **dri-users** [[Subscribe/Unsubscribe/Preferences|http://lists.freedesktop.org/mailman/listinfo/dri-users]] Archives at: [[Freedesktop|http://lists.freedesktop.org/archives/dri-users]], [[MARC|http://marc.theaimsgroup.com/?l=dri-users&r=1&w=2]], [[Gmane|http://news.gmane.org/gmane.comp.video.dri.user]] 
+      * You should post to this list for all general questions and support issues. All non-development discussions should take place on this mailing list, rather than dri-devel. If you are having trouble getting the DRM up and running and want to ask questions, this is the list to post to. 
+   * **dri-devel** [[Subscribe/Unsubscribe/Preferences|http://lists.freedesktop.org/mailman/listinfo/dri-devel]]  Archives at: [[Freedesktop|http://lists.freedesktop.org/archives/dri-devel]], [[MARC|http://marc.theaimsgroup.com/?l=dri-devel&r=1&w=2]], [[Mail-archive.com|http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/]], [[Gmane|http://news.gmane.org/gmane.comp.video.dri.devel]] 
+      * This is the primary discussion list for work being done on the Direct Rendering Modules (DRM). You should post here if you have any questions for the developers or if you wish to participate in DRM development or if you have a bug to report. 
+   * **dri-patches** [[Subscribe/Unsubscribe/Preferences|http://lists.freedesktop.org/mailman/listinfo/dri-patches]] Archives at: [[Freedesktop|http://lists.freedesktop.org/archives/dri-patches]], [[MARC|http://marc.theaimsgroup.com/?l=dri-patches&r=1&w=2]], [[Gmane|http://news.gmane.org/gmane.comp.video.dri.patches]] 
+      * Any checkins to the DRM source tree are recorded on the dri-patches mailing list, and so this list can get a significant amount of volume when development is active. 
+Mailing lists **are archived**. So it might be easier to read them through HTML or search them as needed to find your answer instead of posting your question and waiting for a reply. 
diff --git a/MailingLists.moin b/MailingLists.moin
deleted file mode 100644
index c6b00e2..0000000
--- a/MailingLists.moin
+++ /dev/null
@@ -1,62 +0,0 @@
-== Mailing Lists ==
-
-If you need more help getting DRI to work on your Linux system then your best bet is to check out BugZilla or the Mesa and DRI mailing lists:
-<<BR>> 
-
-=== Mesa 3D and DRI ===
-  * '''mesa-announce''': [[http://lists.freedesktop.org/mailman/listinfo/mesa-announce|Subscribe/Unsubscribe/Preferences]]
-
-  Archives at: [[http://lists.freedesktop.org/archives/mesa-announce|Freedesktop]], [[http://marc.theaimsgroup.com/?l=mesa3d-announce&r=1&w=2|MARC]], [[http://news.gmane.org/gmane.comp.video.mesa3d.announce|Gmane]]
-
-   Announcemenents about Mesa (and DRI) releases.
-
-  * '''mesa-users''': [[http://lists.freedesktop.org/mailman/listinfo/mesa-users|Subscribe/Unsubscribe/Preferences]]
-
-  Archives at: [[http://lists.freedesktop.org/archives/mesa-users|Freedesktop]], [[http://marc.theaimsgroup.com/?l=mesa3d-users&r=1&w=2|MARC]], [[http://news.gmane.org/gmane.comp.video.mesa3d.user|Gmane]]
-
-   A list for general Mesa and DRI questions and support issues. See dri-users below for the Direct Rendering Module discussion.
-
-  * '''mesa-dev''': [[http://lists.freedesktop.org/mailman/listinfo/mesa-dev|Subscribe/Unsubscribe/Preferences]]
-
-  Archives at: [[http://lists.freedesktop.org/archives/mesa-dev|Freedesktop]], [[http://marc.theaimsgroup.com/?l=mesa3d-dev&r=1&w=2|MARC]], [[http://news.gmane.org/gmane.comp.video.mesa3d.devel|Gmane]]
-
-   Now a focal point of _both_ Mesa 3D and Direct Rendering Infrastructure accelerated OpenGL development discussion, since they are so largely intertwined. For the kernel Direct Rendering Manager module discussions, see dri-devel below.
-
-  * '''mesa-commit''': [[http://lists.freedesktop.org/mailman/listinfo/mesa-commit|Subscribe/Unsubscribe/Preferences]]
-
-  Archives at: [[http://lists.freedesktop.org/archives/mesa-commit/|Freedesktop]], [[http://news.gmane.org/gmane.comp.video.mesa3d.scm|Gmane]]
-
-   Any checkins to the Mesa source tree are recorded on the mesa-commit mailing list, and so this list can get a significant amount of volume when development is active.
-
-##  * '''dri-announce''' [[http://lists.sourceforge.net/mailman/listinfo/dri-announce|Subscribe/Unsubscribe/Preferences]]
-##
-##  Archives at: [[http://sourceforge.net/mailarchive/forum.php?forum_name=dri-announce|Sourceforge]], [[http://marc.theaimsgroup.com/?l=dri-announce&r=1&w=2|MARC]]
-##
-##  This list is used for major announcements about the DRI. This will
-##  mostly be when new chunks of code are checked into the stable trunk
-##  of the CVS repository. This should be a very low volume list.
-
-=== Direct Rendering Modules in Linux/BSD kernels ===
-
-The old DRI mailing lists have changed their focus to purely DRM, while actual DRI driver discussions has moved to the Mesa mailing lists above.
-
-  * '''dri-users''' [[http://lists.freedesktop.org/mailman/listinfo/dri-users|Subscribe/Unsubscribe/Preferences]]
-
-  Archives at: [[http://lists.freedesktop.org/archives/dri-users|Freedesktop]], [[http://marc.theaimsgroup.com/?l=dri-users&r=1&w=2|MARC]], [[http://news.gmane.org/gmane.comp.video.dri.user|Gmane]]
-
-   You should post to this list for all general questions and support issues. All non-development discussions should take place on this mailing list, rather than dri-devel. If you are having trouble getting the DRM up and running and want to ask questions, this is the list to post to.
-
-  * '''dri-devel''' [[http://lists.freedesktop.org/mailman/listinfo/dri-devel|Subscribe/Unsubscribe/Preferences]] 
-
-  Archives at: [[http://lists.freedesktop.org/archives/dri-devel|Freedesktop]], [[http://marc.theaimsgroup.com/?l=dri-devel&r=1&w=2|MARC]], [[http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/|Mail-archive.com]], [[http://news.gmane.org/gmane.comp.video.dri.devel|Gmane]]
-
-   This is the primary discussion list for work being done on the Direct Rendering Modules (DRM). You should post here if you have any questions for the developers or if you wish to participate in DRM development or if you have a bug to report.
-
-  * '''dri-patches''' [[http://lists.freedesktop.org/mailman/listinfo/dri-patches|Subscribe/Unsubscribe/Preferences]]
-
-  Archives at: [[http://lists.freedesktop.org/archives/dri-patches|Freedesktop]], [[http://marc.theaimsgroup.com/?l=dri-patches&r=1&w=2|MARC]], [[http://news.gmane.org/gmane.comp.video.dri.patches|Gmane]]
-
-   Any checkins to the DRM source tree are recorded on the dri-patches mailing list, and so this list can get a significant amount of volume when development is active.
-
-Mailing lists '''are archived'''. So it might be easier to read them through HTML or search them as needed to find your answer instead
-of posting your question and waiting for a reply.
diff --git a/Mali.mdwn b/Mali.mdwn
new file mode 100644
index 0000000..fff74ed
--- /dev/null
+++ b/Mali.mdwn
@@ -0,0 +1,32 @@
+
+
+# Mali
+
+ARM IP licensed 3d integrated circuit for ARM SoC. 
+
+Models : 
+
+* Mali200 * Mali400 
+
+
+## Status
+
+Source code of Mali GPUs Linux X11 Display Drivers including EXA/DRI2 Module Under MIT License 
+
+Source code of Mali GPUs Linux/Android Gralloc Module Under Apache License. 
+
+Both made by ARM 
+
+
+## Specifications
+
+
+## Resources
+
+* [[Drivers page|http://www.malideveloper.com/developer-resources/drivers/index.php]] * [[Official ARM EXA/DRI2 MALI drivers|http://www.malideveloper.com/open-source-mali-gpus-linux-exadri2-and-x11-display-drivers.php]] 
+
+
+
+---
+
+ [[CategoryHardwareChipset|CategoryHardwareChipset]] 
diff --git a/Mali.moin b/Mali.moin
deleted file mode 100644
index 754ade1..0000000
--- a/Mali.moin
+++ /dev/null
@@ -1,25 +0,0 @@
-= Mali =
-
-ARM IP licensed 3d integrated circuit for ARM SoC.
-
-Models :
-
-* Mali200
-* Mali400
-
-== Status ==
-
-Source code of Mali GPUs Linux X11 Display Drivers including EXA/DRI2 Module Under MIT License
-
-Source code of Mali GPUs Linux/Android Gralloc Module Under Apache License.
-
-Both made by ARM
-
-== Specifications ==
-
-== Resources ==
-* [[http://www.malideveloper.com/developer-resources/drivers/index.php|Drivers page]]
-* [[http://www.malideveloper.com/open-source-mali-gpus-linux-exadri2-and-x11-display-drivers.php|Official ARM EXA/DRI2 MALI drivers]]
-
-----
-CategoryHardwareChipset
diff --git a/Matrox.mdwn b/Matrox.mdwn
new file mode 100644
index 0000000..ef5a01b
--- /dev/null
+++ b/Matrox.mdwn
@@ -0,0 +1,55 @@
+
+
+# Matrox
+
+**Chipsets** [[!map pages="^Matrox.+"]] 
+
+
+## Status
+
+Supported chipsets: 
+
+   * G200 
+   * G400 
+   * G450 
+   * G550 
+Unsupported chipsets (early): 
+
+   * Mystique (1064 and 2064) 
+   * Millenium II (2164) 
+   * Productiva G100 
+While Xorg has 2D support for these early chips, there is no 3D support yet. 
+
+Unsupported chipsets (modern): 
+
+   * QID 
+   * P650 
+   * P750 
+   * Parhelia 
+P-series and Parhelia cards are supported by a binary driver provided by Matrox.  The QID card is not supported under Linux at all, despite being apparently based on the Parhelia core. 
+
+Important notes: 
+
+   * [[IanRomanick|IanRomanick]] recently added support for PCI mga G4/5xx cards. 
+Example graphics cards: 
+
+   * Millennium G550 
+   * Millennium G450 
+   * Millennium G400 
+   * Millennium G200 
+   * Mystique G200 
+
+## Specifications
+
+Databooks for the G200 and G400 used to be available through Matrox' developer program, however the program seems to no longer exist. 
+
+
+## Resources
+
+Probably earliest Matrox (Millenium I and Mystique) hw 3D driver, from ~1997,  no texturing, just Z-buffered, Gouraud-shaded tris: [[Page|http://web.archive.org/web/20000831085135/www.jura.uni-tuebingen.de/~goetz/indexeng.html]], [[Download src|http://web.archive.org/web/20000831085135/http://www.jura.uni-tuebingen.de/~goetz/download/sources.tar.gz]] 
+
+
+
+---
+
+ [[CategoryHardwareVendor|CategoryHardwareVendor]] 
diff --git a/Matrox.moin b/Matrox.moin
deleted file mode 100644
index 7d971a8..0000000
--- a/Matrox.moin
+++ /dev/null
@@ -1,48 +0,0 @@
-= Matrox =
-
-'''Chipsets'''
-<<PageList(^Matrox.+)>>
-
-== Status ==
-
-Supported chipsets:
-  * G200
-  * G400
-  * G450
-  * G550
-
-Unsupported chipsets (early):
-  * Mystique (1064 and 2064)
-  * Millenium II (2164)
-  * Productiva G100
-
-While Xorg has 2D support for these early chips, there is no 3D support yet.
-
-Unsupported chipsets (modern):
-  * QID
-  * P650
-  * P750
-  * Parhelia
-
-P-series and Parhelia cards are supported by a binary driver provided by Matrox.  The QID card is not supported under Linux at all, despite being apparently based on the Parhelia core.
-
-Important notes:
-  IanRomanick recently added support for PCI mga G4/5xx cards.
-
-Example graphics cards:
-  * Millennium G550
-  * Millennium G450
-  * Millennium G400
-  * Millennium G200
-  * Mystique G200
-
-== Specifications ==
-
-Databooks for the G200 and G400 used to be available through Matrox' developer program, however the program seems to no longer exist.
-
-== Resources ==
-
-Probably earliest Matrox (Millenium I and Mystique) hw 3D driver, from ~1997,  no texturing, just Z-buffered, Gouraud-shaded tris: [[ http://web.archive.org/web/20000831085135/www.jura.uni-tuebingen.de/~goetz/indexeng.html | Page ]], [[ http://web.archive.org/web/20000831085135/http://www.jura.uni-tuebingen.de/~goetz/download/sources.tar.gz | Download src]]
-
-----
-CategoryHardwareVendor
diff --git a/MergedFB.moin b/MergedFB.mdwn
index 2a011fe..a643d4d 100644
--- a/MergedFB.moin
+++ b/MergedFB.mdwn
@@ -1,59 +1,70 @@
-== MergedFB ==
-
-Merged Framebuffer mode allows you to use 3D acceleration on both heads of a dualheaded Radeon card.  This is accomplished by creating a single large framebuffer with two viewports (CRTCs) looking into it.  The current Radeon dualhead code creates two separate screens with separate framebuffers.  they can be combined into a single logical screen using xinerama or used separately as separate X servers (host:0.0 and host:0.1).  Merged Framebuffer mode can only be used to create a single logical screen.  This is because a single framebuffer is shared between the two CRTCs.  This is also the reason that HW accelerated 3D works on both heads.
-
-(See http://bugs.xfree86.org/show_bug.cgi?id=276)
-
-=== MergedFB Driver Options ===
-
-These are the Radeon MergedFB options from the Radeon [[http://www.botchco.com/alex/radeon/mergedfb/cvs/DRI/final/radeon.4.html|man page]].
-
-
-=== Notes ===
-
-Pageflipping does not work reliably in all MergedFB modes.  If you have problems with MergedFB, please disable it.
-
-If you have any 3D contexts greater than 2048, you will get an empty window. The 3D engine is limited to 2048x2048.  I'd like to get around this at some point, and there is a potential solution out there, I just have not had time to mess with it.  For more information, see the "2048 limit" thread in dri-devel.
-
-Thomas Winischhofer's SiS [[http://www.winischhofer.net/linuxsisvga.shtml#mergedfbmode|site]] has some good information on MergedFB, and since the Radeon MergedFB driver is based on Thomas' work it is relevant to Radeon as well.
-
-the No2048Limit option has been deprecated.
-
-== Some usage notes ==
-
-When enabling MergedFB in your xorg.conf, here are some things to keep in mind.
-
-Under the Device section you should have this line:
-          Option "MergedFB" "true"
-
-Also, one thing that was causing me headache, in your Screen section you must have a subsection that sets up the virtual display, and it must also contain a subsection that gives the display modes. Like this:
-
-SubSection "Display"<<BR>>
-         Depth 24<<BR>>
-         Virtual 1560 1024<<BR>>
-EndSubSection<<BR>>
-
-SubSection "Display"<<BR>>
-         Depth 24<<BR>>
-         Modes "1400x1050 1280x1024 1024x768"<<BR>>
-EndSubSection<<BR>>
-
-
-This information is correct for my radeon mobility 9000 using recognized as r250 chipset.<<BR>>
-After much searching I was not able to find a similiar xorg.conf example in my google searches.<<BR>>
-
---- Also of note:
-
-Because the radeon driver defaults to "MergedFB" mode X -configure run against my RV370 generated a /root/xorg.conf.new that was correct in most respects except misleadingly "CRT2Position" defaulted to "Clone" -- uncommented and changed it to "RightOf" and suddenly its dualheadedness was more evident.
-
-
-
-=== Other MergedFB drivers ===
-
-nVidia has a similar feature in their binary drivers called "twinview."
-
-ATI has a similar feature in their binary drivers.
-
-Matrox has MergedFB support when using its binary HAL module.
-
-Thomas Winischhofer's SiS [[http://www.winischhofer.net/linuxsisvga.shtml|driver]] has MergedFB support.
+
+
+## MergedFB
+
+Merged Framebuffer mode allows you to use 3D acceleration on both heads of a dualheaded Radeon card.  This is accomplished by creating a single large framebuffer with two viewports (CRTCs) looking into it.  The current Radeon dualhead code creates two separate screens with separate framebuffers.  they can be combined into a single logical screen using xinerama or used separately as separate X servers (host:0.0 and host:0.1).  Merged Framebuffer mode can only be used to create a single logical screen.  This is because a single framebuffer is shared between the two CRTCs.  This is also the reason that HW accelerated 3D works on both heads. 
+
+(See [[http://bugs.xfree86.org/show_bug.cgi?id=276|http://bugs.xfree86.org/show_bug.cgi?id=276]]) 
+
+
+### MergedFB Driver Options
+
+These are the Radeon MergedFB options from the Radeon [[man page|http://www.botchco.com/alex/radeon/mergedfb/cvs/DRI/final/radeon.4.html]]. 
+
+
+### Notes
+
+Pageflipping does not work reliably in all MergedFB modes.  If you have problems with MergedFB, please disable it. 
+
+If you have any 3D contexts greater than 2048, you will get an empty window. The 3D engine is limited to 2048x2048.  I'd like to get around this at some point, and there is a potential solution out there, I just have not had time to mess with it.  For more information, see the "2048 limit" thread in dri-devel. 
+
+Thomas Winischhofer's SiS [[site|http://www.winischhofer.net/linuxsisvga.shtml#mergedfbmode]] has some good information on MergedFB, and since the Radeon MergedFB driver is based on Thomas' work it is relevant to Radeon as well. 
+
+the [[No2048Limit|No2048Limit]] option has been deprecated. 
+
+
+## Some usage notes
+
+When enabling MergedFB in your xorg.conf, here are some things to keep in mind. 
+
+Under the Device section you should have this line: 
+
+                           * Option "MergedFB" "true" 
+Also, one thing that was causing me headache, in your Screen section you must have a subsection that sets up the virtual display, and it must also contain a subsection that gives the display modes. Like this: 
+
+[[SubSection|SubSection]] "Display"  
+ 
+
+                        * Depth 24  
+ Virtual 1560 1024  
+ 
+[[EndSubSection|EndSubSection]]  
+ 
+
+[[SubSection|SubSection]] "Display"  
+ 
+
+                        * Depth 24  
+ Modes "1400x1050 1280x1024 1024x768"  
+ 
+[[EndSubSection|EndSubSection]]  
+ 
+
+This information is correct for my radeon mobility 9000 using recognized as r250 chipset.  
+ After much searching I was not able to find a similiar xorg.conf example in my google searches.  
+ 
+
+--- Also of note: 
+
+Because the radeon driver defaults to "MergedFB" mode X -configure run against my RV370 generated a /root/xorg.conf.new that was correct in most respects except misleadingly "CRT2Position" defaulted to "Clone" -- uncommented and changed it to "[[RightOf|RightOf]]" and suddenly its dualheadedness was more evident. 
+
+
+### Other MergedFB drivers
+
+nVidia has a similar feature in their binary drivers called "twinview." 
+
+ATI has a similar feature in their binary drivers. 
+
+Matrox has MergedFB support when using its binary HAL module. 
+
+Thomas Winischhofer's SiS [[driver|http://www.winischhofer.net/linuxsisvga.shtml]] has MergedFB support. 
diff --git a/Mesa.mdwn b/Mesa.mdwn
new file mode 100644
index 0000000..d1b2b96
--- /dev/null
+++ b/Mesa.mdwn
@@ -0,0 +1,13 @@
+
+
+## Mesa
+
+Brian Paul wrote a free open-source implementation of OpenGL called Mesa. The name has no hidden meaning, it just sounds nice. The original versions of Mesa only did software rendering. Recent versions of Mesa have had accelerated backends for Glide, DRI, etc. 
+
+The Mesa website is at [[http://www.mesa3d.org/|http://www.mesa3d.org/]]. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/Mesa.moin b/Mesa.moin
deleted file mode 100644
index 58c9216..0000000
--- a/Mesa.moin
+++ /dev/null
@@ -1,11 +0,0 @@
-== Mesa ==
-
-Brian Paul wrote a free open-source implementation of OpenGL called
-Mesa. The name has no hidden meaning, it just sounds nice. The original
-versions of Mesa only did software rendering. Recent versions of Mesa have had
-accelerated backends for Glide, DRI, etc.
-
-The Mesa website is at [[http://www.mesa3d.org/]].
-
-----
-CategoryGlossary
diff --git a/MesaDriver.mdwn b/MesaDriver.mdwn
new file mode 100644
index 0000000..070deaa
--- /dev/null
+++ b/MesaDriver.mdwn
@@ -0,0 +1,201 @@
+
+
+## Mesa internals
+
+
+### How does one write a new Mesa driver?
+
+There are two basic aspects to writing a new driver. 
+
+First, define the public OpenGL / window system API. In the case of GLX, these are the glx*() functions. For OSMesa these are the OSMesa*() functions seen in `include/GL/osmesa.h`. You'll basically need functions for specifying frame buffer formats (bits per rgb, bits for Z, bits for stencil, etc.), functions for creating/destroying contexts, binding contexts to windows. etc. 
+
+Second, implement the internal functions needed by the "DD" interface. Look at the `osmesa.c` file and grep for "ctx->Driver. = ". This is where the driver hooks itself into the core of Mesa. In many cases we hook in fall-back functions (like _swrast_[[DrawPixels|DrawPixels]]). 
+
+This isn't simple (or even as straight-forward as it used to be) but the system's designed for efficiency, flexibility and modularity. If the device driver interface were made for simplicity above all else there would probably only be two driver functions: dd_function_table::[[ReadPixels|ReadPixels]]() and dd_function_table::[[DrawPixels|DrawPixels]](). 
+
+The OSMesa driver is pretty simple. The only complexity comes from supporting all the different frame buffer formats like !RGB, !RGBA, !BGRA, !ABGR, etc. I think the Windows driver is in pretty good shape too. The XMesa driver (upon which Mesa's GLX is layered) is rather large because of lots of frame buffer formats and optimized point/line/triangle rendering functions. 
+
+
+### Mesa 4.x Implementation Notes
+
+The big changes in Mesa were made between Mesa 3.4.x and Mesa 3.5. That's when [[KeithWhitwell|KeithWhitwell]] re-modularized the source code into separate modules for T&L, s/w rasterization, etc.  
+
+This document is an overview of the internal structure of Mesa and is meant for those who are interested in modifying or enhancing Mesa, or just curious. 
+
+**Note:** Based on the original [[Mesa Implementation Notes|http://www.mesa3d.org/docs/Implementation.html]] and corrections by Brian Paul. 
+
+
+#### Library State and Contexts
+
+OpenGL uses the notion of a state machine. Almost all OpenGL state is contained in one large structure: <ins>GLcontextRec (typedef'd to GLcontext), as seen in mtypes.h. This is the central context data structure for Mesa. 
+
+The </ins>GLcontextRec structure actually contains a number of sub structures which exactly correspond to OpenGL's attribute groups. This organization made glPushAttrib and glPopAttrib trivial to implement and proved to be a good way of organizing the state variables. 
+
+
+#### Vertex buffer
+
+The immediate represents everything that can take place between glBegin and glEnd being able to represent multiple glBegin/glEnd pairs. It can be used to losslessly encode this information in display lists. See t_context.h and t_imm_api.c. 
+
+When either the vertex buffer becomes filled or a state change outside the glBegin/glEnd is made, we must flush the buffer. That is, we apply the vertex transformations, compute lighting, fog, texture coordinates etc. The various vertex transformations are implemented as software pipeline stages by the t_pipeline.c and `tnl/t_vb_*.c` files. 
+
+When we're outside of a glBegin/glEnd pair the information in this structure is retained pending either of the flushing events described above. 
+
+**Note:** Originally, Mesa didn't accumulate vertices in this way. Instead, glVertex transformed and lit then buffered each vertex as it was received. When enough vertices to draw the primitive (1 for points, 2 for lines, >2 for polygons) were accumulated the primitive was drawn and the buffer cleared. 
+
+The new approach of buffering many vertices and then transforming, lighting and clip testing is faster because it's done in a "vectorized" manner. See gl_transform_points in m_xform.c for an example. 
+
+For best performance Mesa clients should try to maximize the number of vertices between glBegin/glEnd pairs and use connected primitives when possible. 
+
+
+#### Rasterization
+
+The point, line and polygon rasterizers are called via the Point, Line, and Triangle function pointers in the SWcontext structure in s_context.h. Whenever the library state is changed in a significant way, the [[NewState|NewState]] context flag is raised. When glBegin is called [[NewState|NewState]] is checked. If the flag is set we re-evaluate the state to determine what rasterizers to use. Special purpose rasterizers are selected according to the status of certain state variables such as flat vs smooth shading, depth-buffered vs. non-depth- buffered, etc. The _swrast_choose_* functions do this analysis. It's up to the device driver to choose optimized or accelerated rasterization functions to replace those in the general software rasterizer. 
+
+In general, typical states (depth-buffered & smooth-shading) result in optimized rasterizers being selected. Non-typical states (stenciling, blending, stippling) result in slower, general purpose rasterizers being selected. 
+
+
+#### Pixel spans
+
+* Point, Line, Triangle, glDrawPixel, glCopyPixels and glBitmap all use the sw_span structure and functions in s_span.c generate horizontal runs of pixels called spans. Processing includes window clipping, depth testing, stenciling, texturing, etc. After processing the span is written to the frame buffer by calling a device driver function. The goal is to maximize the number of pixels processed inside loops and to minimize the number of function calls. 
+**Note:** Pixel buffers are no longer present in the latest Mesa code (4.1). All fragment (pixels plus color, depth, texture coordinates) processing is done via the span functions in s_span.c. 
+
+
+#### Device Driver
+
+There are three Mesa data types which are meant to be used by device drivers: 
+
+   * GLcontext: this contains the Mesa rendering state 
+   * GLvisual: this describes the color buffer (RGB vs. CI), whether or not there's a depth buffer, stencil buffer, etc. 
+   * GLframebuffer: contains pointers to the depth buffer, stencil buffer, accum buffer and alpha buffers. 
+These types should be encapsulated by corresponding device driver data types. See xmesa.h and xmesaP.h for an example. 
+
+In OOP terms, GLcontext, GLvisual, and GLframebuffer are base classes which the device driver must derive from. 
+
+The structure dd_function_table seen in dd.h, defines the device driver functions [^1]. By using a table of pointers, the device driver can be changed dynamically at runtime. For example, the X/Mesa and OS/Mesa (Off-Screen rendering) device drivers can co-exist in one library and be selected at runtime. 
+
+In addition to the device driver table functions, each Mesa driver has its own set of unique interface functions. For example, the X/Mesa driver has the XMesaCreateContext, XMesaBindWindow, and XMesaSwapBuffers functions while the Windows/Mesa interface has WMesaCreateContext, WMesaPaletteChange and WMesaSwapBuffers. New Mesa drivers need to both implement the dd_function_table functions and define a set of unique window system or operating system-specific interface functions. 
+
+The device driver functions can roughly be divided into three groups: 
+
+   1. pixel span functions which read or write horizontal runs of RGB or color-index pixels. Each function takes an array of mask flags which indicate whether or not to plot each pixel in the span. 
+   1. miscellaneous functions for window clearing, setting the current drawing color, enabling/disabling dithering, returning the current frame buffer size, specifying the window clear color, synchronization, etc. Most of these functions directly correspond to higher level OpenGL functions. 
+   1. if your graphics hardware or operating system provides accelerated point, line and polygon rendering operations, they can be utilized through the [[PointsFunc|PointsFunc]], [[LineFunc|LineFunc]], and [[TriangleFunc|TriangleFunc]] functions. Mesa will call these functions to "ask" the device driver for accelerated functions through the [[UpdateState|UpdateState]]. If the device driver can provide an appropriate renderer, given the current Mesa state, then a pointer to that function can be returned. Otherwise the [[PointsFunc|PointsFunc]], [[LineFunc|LineFunc]], and [[TriangleFunc|TriangleFunc]] functions pointers can just be set to NULL. 
+Even if hardware accelerated renderers aren't available, the device driver may implement tuned, special purpose code for common kinds of points, lines or polygons. The X/Mesa device driver does this for a number of lines and polygons. See the xm_line.c and xm_tri.c and files. 
+
+
+#### Overall Organization
+
+The overall relation of the core Mesa library, X device driver/interface, toolkits and application programs is shown in this diagram: 
+
+
+[[!format txt """
++-----------------------------------------------------------+
+|                                                           |
+|                   Application Programs                    |
+|                                                           |
+|          +- glu.h -+------ glut.h -------+                |
+|          |         |                     |                |
+|          |   GLU   |        GLUT         |                |
+|          |         |      toolkits       |                |
+|          |         |                     |                |
++---------- gl.h ------------+-------- glx.h ----+          |
+|                            |                   |          |
+|         Mesa core          |   GLX functions   |          |
+|                            |                   |          |
++---------- dd.h ------------+------------- xmesa.h --------+
+|                                                           |
+|              XMesa* and device driver functions           |
+|                                                           |
++-----------------------------------------------------------+
+|                 Hardware/OS/Window System                 |
++-----------------------------------------------------------+
+"""]]
+
+### Mesa's pipeline
+
+The work starts on t_pipeline.c where a driver configurable pipeline is run in response to either the vertex buffer filling up, or a statechange. 
+
+The pipeline stages operate on context variables (suchs as vertices coord, colors, normals, textures coords, etc), applying the necessary operations in a OpenGL pipeline (such as coord transformation, lighting, etc.). 
+
+The last stage - rendering -, calls *[[BuildVertices|BuildVertices]] in `*_vb.c` which applies the viewport transformation, perpective divide, data type convertion and packs the vertex data in the context (in the arrays tnl->vb->*Ptr->data) into a driver dependent buffer with just the information relevent for the current OpenGL state (e.g., with/without texture, fog, etc). The template `t_dd_vbtmp.h` does this into a Direct3D alike vertex structure format. 
+
+For instance, if we needed to premultiply the textures coordinates, as it is done in the tdfx and mach64 driver, we will need to make a customized version of `t_dd_vbtmp.h` for that effect, or change it and supply a configuration parameter to control that behavior. 
+
+This buffer is then used to render the primitives in `*_tris.c`. This vertex data is intended to be copied almost verbatim into DMA buffers, with a header command, in most chips with DMA. 
+
+But in the case of Mach64, where the commands are interleaved with each of the vertex data elements, it will be necessary to use a different structure of *Vertex to do the same, and probably to come up with a rather different implementation of t_dd_vbtmp.h as well. 
+
+Indeed, if the chip expects something quite different to the d3d vertices, one will certainly want to look at this. In the meantime, it may be simplest to go with a "normal-looking"  `*_vb.c` and do some extra stuff in the triangle/line/point functions. The ffb and glint drivers are a bit like this, I think. 
+
+All this mechanism is controlled with function pointers in the context which are rechosen whenever the OpenGL state changes enough. These functions pointers can also be overwritten with those in the `sw_*` modules to fallback to software rendering. 
+
+
+## How about the main X drawing surface? Are 2 extra "window sized" buffers allocated for primary and secondary buffers in a page-flipping configuration?
+
+Right now, we don't do page flipping at all. Everything is a blit from back to front. The biggest problem with page flipping is detecting when you're in full screen mode, since OpenGL doesn't really have a concept of full screen mode. We want a solution that works for existing games. So we've been designing a solution for it. It should get implemented fairly soon since we need it for antialiasing on the V5. 
+
+In the current implementation the X front buffer is the 3D front buffer. When we do page flipping we'll continue to do the same thing. Since you have an X window that covers the screen it is safe for us to use the X surface's memory. Then we'll do page flipping. The only issue will be falling back to blitting if the window is ever moved from covering the whole screen. 
+
+
+## Clipping
+
+This section gives some notions about the several concepts associated to clipping. 
+
+   * -- [[LeifDelgass|LeifDelgass]] 
+
+### Scissors
+
+The scissors are register settings that determine a hardware clipping rect in window coords. Any part of a primitive or other drawing operation that extends beyond the scissors is not drawn. The scissors can be set through GL commands. This has nothing to do with perspective clipping in the pipeline, just the final window coordinates. 
+
+
+### Cliprects
+
+Cliprects are used to determine what parts of the context/window should be redrawn to handle overlapping windows. The more overlapping windows, the more cliprects you have. These need to be passed to the drm. It does a clear or swap for each cliprect. Again these are for 2D clipping after rasterization and not part of the pipeline. Things get a bit complicated by the fact that there can be separate clip rects for the front and back buffers. 
+
+The cliprects are stored in device-independent structures, hence the code is abstracted out of the individual drivers. 
+
+
+### Viewport
+
+The viewport array holds values to determine how to translate transformed, clipped, and projected vertex coordinates into window coordinates. This is the last stage of the pipeline. The values are based on the size and position of the "drawable", also known as the drawing area of the window for the context. 
+
+
+## Texture management
+
+What follows is a description of the texture management system in the DRI. This is all based on the Radeon driver in the 11-Feb-2002 CVS of the mesa-4-0-branch. While it is based on the Radeon code, all drivers except gamma and tdfx seem to use the same scheme (and virtually identical code). 
+
+   * Excluding the texture backing store, which is managed by Mesa, texture data is tracked in two places. The per-screen (card) SAREA divides each type of texturable memory (on-card, AGP, etc.) into an array of fixed sized chunks (RADEONSAREAPriv.texList in `programs/Xserver/hw/xfree86/drivers/ati/radeon_sarea.h`). The number of these chunks is a compile-time constant, and it cannot be changed without destroying the universe. That is, any changes here will present major compatibility issues. Currently, this constant is 64. So, for the new 128MB Radeon 8500 cards, each block of memory will likely be 1MB or more. This is not as bad as it may first seem, see below. The usage of each type of memory is also tracked per-context. 
+   * The per-context memory tracking is done using a memHeap_t. Allocations from the memHeap_t (see lib/GL/mesa/src/drv/common/mm.c) are done at byte granularity. When a context needs a block of texture memory, it is allocated from the memHeap_t. This results in very little memory fragmentation (within a context). After the allocation is made, the map of allocated memory in the SAREA is updated (radeonUpdateTexLRU in `lib/GL/mesa/src/drv/radeon/radeon_texmem.c`). Basically, each block of memory in texList that corresponds to an allocated region (in the per-context memHeap_t) is marked as allocated. 
+   * The texList isn't just an array of blocks. It's also a priority queue (linked list). As each texture is accessed, the blocks that it occupies are moved to the head of the queue. In the Radeon code, each time a texture is uploaded or bound to a texture unit, the blocks of memory (in AGP space or on-card) are moved to the head of the texList queue. 
+   * If an allocation (via the memHeap_t) fails when texture space is allocated (radeonUploadTexImages in `lib/GL/mesa/src/drv/radeon/radeon_texmem.c`), blocks at the end of the texList queue are freed until the allocation can succeed.This may be an area where the algorithm could be improved. For example, it might be better to find the largest free block (in the memHeap_t) and release memory around that block in LRU or least-often-used fashion until the allocation can succeed. This may be too difficult to get right or too slow when done right. Someone would have to try it and see. 
+   * Each time a direct-client detects that another client has held the per-screen lock, radeonGetLock is called. This synchronizes the per-context vision of the hardware state. Part of this synchronization is synchronizing the view of texture memory. In addition to the texList, the SAREA holds a texAge array. This array stores the generation number of each of the texture heaps. If a client detects that the generation number of a heap has changed in radeonGetLock, it calls radeonAgeTextures for that heap. radeonAgeTextures runs through the texList looking for blocks with a more recent generation number. Each block that has a newer generation is passed to radeonTexturesGone. 
+   * radeonTexturesGone searches the per-context memHeap_t for an allocated region matching the block with the updated generation. When a matching region is found, it is freed, and if the region was for a texture in the local context, the local state of that texture is updated. If the updated block (from the global context) is "in-use" (i.e., some other context has stolen that block from the current context), the block is re-allocated and marked as in-use by another context. 
+   * It seems that about 2 years ago a few people (from the CVS log) had taken a stab at factoring the common code out and put it in `shared_texture_lru.[ch]` in `lib/GL/mesa/src/drv/common` but it isn't used and hasn't been touched (at least not in CVS) since 4-April-2000. 
+**Note:** Just FYI: the tdfx texture memory management code is different because: 
+
+   1. It was originally developed before the scheme [[KeithWhitwell|KeithWhitwell]] implemented for the i810 and mga drivers (and later used for the R128 and radeon). 
+   1. There are some idiosynchracies with the Voodoo3 such as two separate banks of TRAM and needing to store alternate mipmap levels in alternate banks. 
+   1. We did everything through the Glide interface, rather than working directly with the hardware. -- [[IanRomanick|IanRomanick]] 
+
+## How often are checks done to see if things need clipped/redrawn/redisplayed?
+
+The locking system is designed to be highly efficient. It is based on a two tiered lock. Basically it works like this: 
+
+The client wants the lock. The use the CAS (I was corrected that the instruction is compare and swap, I knew that was the functionality, but I got the name wrong) If the client was the last application to hold the lock, you're done you move on. 
+
+If it wasn't the last one, then we use an IOCTL to the kernel to arbitrate the lock. 
+
+In this case some or all of the state on the card may have changed. The shared memory carries a stamp number for the X server. When the X server does a window operation it increments the stamp. If the client sees that the stamp has changed, it uses a DRI X protocol request to get new window location and clip rects. This only happens on a window move. Assuming your clip rects/window position hasn't changed, the redisplay happens entirely in the client. 
+
+The client may have other state to restore as well. In the case of the tdfx driver we have three more flags for command fifo invalid, 3D state invalid, textures invalid. If those are set the corresponding state is restored. 
+
+So, if the X server wakes up to process input, it currently grabs the lock but doesn't invalidate any state. I'm actually fixing this now so that it doesn't grab the lock for input processing. 
+
+If the X server draws, it grabs the lock and invalidates the command FIFO. 
+
+If the X server moves a window, it grabs the lock, updates the stamp, and invalidates the command FIFO. 
+
+If another 3D app runs, it grabs the lock, invalidates the command FIFO, invalidates the 3D state and possibly invalidates the texture state. 
+
+
+[^1] Many of the functions which used to be in the dd_function_table are now moved into the tnl or swrast modules. 
diff --git a/MesaDriver.moin b/MesaDriver.moin
deleted file mode 100644
index 4dfa7f4..0000000
--- a/MesaDriver.moin
+++ /dev/null
@@ -1,192 +0,0 @@
-== Mesa internals ==
-
-=== How does one write a new Mesa driver? ===
-
-There are two basic aspects to writing a new driver.
-
-First, define the public OpenGL / window system API. In the case of GLX, these are the glx*() functions. For OSMesa these are the OSMesa*() functions seen in `include/GL/osmesa.h`. You'll basically need functions for specifying frame buffer formats (bits per rgb, bits for Z, bits for stencil, etc.), functions for creating/destroying contexts, binding contexts to windows. etc.
-
-Second, implement the internal functions needed by the "DD" interface. Look at the `osmesa.c` file and grep for "ctx->Driver. = ". This is where the driver hooks itself into the core of Mesa. In many cases we hook in fall-back functions (like _swrast_DrawPixels).
-
-This isn't simple (or even as straight-forward as it used to be) but the system's designed for efficiency, flexibility and modularity. If the device driver interface were made for simplicity above all else there would probably only be two driver functions: dd_function_table::ReadPixels() and dd_function_table::DrawPixels().
-
-The OSMesa driver is pretty simple. The only complexity comes from supporting all the different frame buffer formats like !RGB, !RGBA, !BGRA, !ABGR, etc. I think the Windows driver is in pretty good shape too. The XMesa driver (upon which Mesa's GLX is layered) is rather large because of lots of frame buffer formats and optimized point/line/triangle rendering functions.
-
-=== Mesa 4.x Implementation Notes ===
-
-The big changes in Mesa were made between Mesa 3.4.x and Mesa 3.5. That's when KeithWhitwell re-modularized the source code into separate modules for T&L, s/w rasterization, etc. 
-
-This document is an overview of the internal structure of Mesa and is meant for those who are interested in modifying or enhancing Mesa, or just curious.
-
-'''Note:''' Based on the original [[http://www.mesa3d.org/docs/Implementation.html|Mesa Implementation Notes]] and corrections by Brian Paul.
-
-==== Library State and Contexts ====
-
-OpenGL uses the notion of a state machine. Almost all OpenGL state is contained in one large structure: __GLcontextRec (typedef'd to GLcontext), as seen in mtypes.h. This is the central context data structure for Mesa.
-
-The __GLcontextRec structure actually contains a number of sub structures which exactly correspond to OpenGL's attribute groups. This organization made glPushAttrib and glPopAttrib trivial to implement and proved to be a good way of organizing the state variables.
-
-==== Vertex buffer ====
-
-The immediate represents everything that can take place between glBegin and glEnd being able to represent multiple glBegin/glEnd pairs. It can be used to losslessly encode this information in display lists. See t_context.h and t_imm_api.c.
-
-When either the vertex buffer becomes filled or a state change outside the glBegin/glEnd is made, we must flush the buffer. That is, we apply the vertex transformations, compute lighting, fog, texture coordinates etc. The various vertex transformations are implemented as software pipeline stages by the t_pipeline.c and `tnl/t_vb_*.c` files.
-
-When we're outside of a glBegin/glEnd pair the information in this structure is retained pending either of the flushing events described above.
-
-'''Note:''' Originally, Mesa didn't accumulate vertices in this way. Instead, glVertex transformed and lit then buffered each vertex as it was received. When enough vertices to draw the primitive (1 for points, 2 for lines, >2 for polygons) were accumulated the primitive was drawn and the buffer cleared.
-
-The new approach of buffering many vertices and then transforming, lighting and clip testing is faster because it's done in a "vectorized" manner. See gl_transform_points in m_xform.c for an example.
-
-
-For best performance Mesa clients should try to maximize the number of vertices between glBegin/glEnd pairs and use connected primitives when possible.
-
-==== Rasterization ====
-
-The point, line and polygon rasterizers are called via the Point, Line, and Triangle function pointers in the SWcontext structure in s_context.h. Whenever the library state is changed in a significant way, the NewState context flag is raised. When glBegin is called NewState is checked. If the flag is set we re-evaluate the state to determine what rasterizers to use. Special purpose rasterizers are selected according to the status of certain state variables such as flat vs smooth shading, depth-buffered vs. non-depth- buffered, etc. The _swrast_choose_* functions do this analysis. It's up to the device driver to choose optimized or accelerated rasterization functions to replace those in the general software rasterizer.
-
-In general, typical states (depth-buffered & smooth-shading) result in optimized rasterizers being selected. Non-typical states (stenciling, blending, stippling) result in slower, general purpose rasterizers being selected.
-
-==== Pixel spans ====
-
- Point, Line, Triangle, glDrawPixel, glCopyPixels and glBitmap all use the sw_span structure and functions in s_span.c generate horizontal runs of pixels called spans. Processing includes window clipping, depth testing, stenciling, texturing, etc. After processing the span is written to the frame buffer by calling a device driver function. The goal is to maximize the number of pixels processed inside loops and to minimize the number of function calls.
-
-'''Note:''' Pixel buffers are no longer present in the latest Mesa code (4.1). All fragment (pixels plus color, depth, texture coordinates) processing is done via the span functions in s_span.c.
-
-
-==== Device Driver ====
-
-There are three Mesa data types which are meant to be used by device drivers:
-
-  * GLcontext: this contains the Mesa rendering state
-
-  * GLvisual: this describes the color buffer (RGB vs. CI), whether or not there's a depth buffer, stencil buffer, etc.
-
-  * GLframebuffer: contains pointers to the depth buffer, stencil buffer, accum buffer and alpha buffers.
-
-These types should be encapsulated by corresponding device driver data types. See xmesa.h and xmesaP.h for an example.
-
-In OOP terms, GLcontext, GLvisual, and GLframebuffer are base classes which the device driver must derive from.
-
-The structure dd_function_table seen in dd.h, defines the device driver functions <<FootNote(Many of the functions which used to be in the dd_function_table are now moved into the tnl or swrast modules. )>>. By using a table of pointers, the device driver can be changed dynamically at runtime. For example, the X/Mesa and OS/Mesa (Off-Screen rendering) device drivers can co-exist in one library and be selected at runtime.
-
-In addition to the device driver table functions, each Mesa driver has its own set of unique interface functions. For example, the X/Mesa driver has the XMesaCreateContext, XMesaBindWindow, and XMesaSwapBuffers functions while the Windows/Mesa interface has WMesaCreateContext, WMesaPaletteChange and WMesaSwapBuffers. New Mesa drivers need to both implement the dd_function_table functions and define a set of unique window system or operating system-specific interface functions.
-
-The device driver functions can roughly be divided into three groups:
-
-  1. pixel span functions which read or write horizontal runs of RGB or color-index pixels. Each function takes an array of mask flags which indicate whether or not to plot each pixel in the span.
-  1. miscellaneous functions for window clearing, setting the current drawing color, enabling/disabling dithering, returning the current frame buffer size, specifying the window clear color, synchronization, etc. Most of these functions directly correspond to higher level OpenGL functions.
-  1. if your graphics hardware or operating system provides accelerated point, line and polygon rendering operations, they can be utilized through the PointsFunc, LineFunc, and TriangleFunc functions. Mesa will call these functions to "ask" the device driver for accelerated functions through the UpdateState. If the device driver can provide an appropriate renderer, given the current Mesa state, then a pointer to that function can be returned. Otherwise the PointsFunc, LineFunc, and TriangleFunc functions pointers can just be set to NULL.
-
-Even if hardware accelerated renderers aren't available, the device driver may implement tuned, special purpose code for common kinds of points, lines or polygons. The X/Mesa device driver does this for a number of lines and polygons. See the xm_line.c and xm_tri.c and files.
-
-==== Overall Organization ====
-
-The overall relation of the core Mesa library, X device driver/interface, toolkits and application programs is shown in this diagram:
-
-{{{
-+-----------------------------------------------------------+
-|                                                           |
-|                   Application Programs                    |
-|                                                           |
-|          +- glu.h -+------ glut.h -------+                |
-|          |         |                     |                |
-|          |   GLU   |        GLUT         |                |
-|          |         |      toolkits       |                |
-|          |         |                     |                |
-+---------- gl.h ------------+-------- glx.h ----+          |
-|                            |                   |          |
-|         Mesa core          |   GLX functions   |          |
-|                            |                   |          |
-+---------- dd.h ------------+------------- xmesa.h --------+
-|                                                           |
-|              XMesa* and device driver functions           |
-|                                                           |
-+-----------------------------------------------------------+
-|                 Hardware/OS/Window System                 |
-+-----------------------------------------------------------+
-}}}
-
-=== Mesa's pipeline ===
-
-The work starts on t_pipeline.c where a driver configurable pipeline is run in response to either the vertex buffer filling up, or a statechange.
-
-The pipeline stages operate on context variables (suchs as vertices coord, colors, normals, textures coords, etc), applying the necessary operations in a OpenGL pipeline (such as coord transformation, lighting, etc.).
-
-The last stage - rendering -, calls *BuildVertices in `*_vb.c` which applies the viewport transformation, perpective divide, data type convertion and packs the vertex data in the context (in the arrays tnl->vb->*Ptr->data) into a driver dependent buffer with just the information relevent for the current OpenGL state (e.g., with/without texture, fog, etc). The template `t_dd_vbtmp.h` does this into a Direct3D alike vertex structure format.
-
-For instance, if we needed to premultiply the textures coordinates, as it is done in the tdfx and mach64 driver, we will need to make a customized version of `t_dd_vbtmp.h` for that effect, or change it and supply a configuration parameter to control that behavior.
-
-This buffer is then used to render the primitives in `*_tris.c`. This vertex data is intended to be copied almost verbatim into DMA buffers, with a header command, in most chips with DMA.
-
-But in the case of Mach64, where the commands are interleaved with each of the vertex data elements, it will be necessary to use a different structure of *Vertex to do the same, and probably to come up with a rather different implementation of t_dd_vbtmp.h as well.
-
-Indeed, if the chip expects something quite different to the d3d vertices, one will certainly want to look at this. In the meantime, it may be simplest to go with a "normal-looking"  `*_vb.c` and do some extra stuff in the triangle/line/point functions. The ffb and glint drivers are a bit like this, I think.
-
-All this mechanism is controlled with function pointers in the context which are rechosen whenever the OpenGL state changes enough. These functions pointers can also be overwritten with those in the `sw_*` modules to fallback to software rendering.
-
-== How about the main X drawing surface? Are 2 extra "window sized" buffers allocated for primary and secondary buffers in a page-flipping configuration? ==
-
-Right now, we don't do page flipping at all. Everything is a blit from back to front. The biggest problem with page flipping is detecting when you're in full screen mode, since OpenGL doesn't really have a concept of full screen mode. We want a solution that works for existing games. So we've been designing a solution for it. It should get implemented fairly soon since we need it for antialiasing on the V5.
-
-In the current implementation the X front buffer is the 3D front buffer. When we do page flipping we'll continue to do the same thing. Since you have an X window that covers the screen it is safe for us to use the X surface's memory. Then we'll do page flipping. The only issue will be falling back to blitting if the window is ever moved from covering the whole screen.
-
-== Clipping ==
-
-This section gives some notions about the several concepts associated to clipping.
-
-  -- LeifDelgass
-  
-=== Scissors ===
-
-The scissors are register settings that determine a hardware clipping rect in window coords. Any part of a primitive or other drawing operation that extends beyond the scissors is not drawn. The scissors can be set through GL commands. This has nothing to do with perspective clipping in the pipeline, just the final window coordinates.
-
-=== Cliprects ===
-
-Cliprects are used to determine what parts of the context/window should be redrawn to handle overlapping windows. The more overlapping windows, the more cliprects you have. These need to be passed to the drm. It does a clear or swap for each cliprect. Again these are for 2D clipping after rasterization and not part of the pipeline. Things get a bit complicated by the fact that there can be separate clip rects for the front and back buffers.
-
-The cliprects are stored in device-independent structures, hence the code is abstracted out of the individual drivers.
-
-=== Viewport ===
-
-The viewport array holds values to determine how to translate transformed, clipped, and projected vertex coordinates into window coordinates. This is the last stage of the pipeline. The values are based on the size and position of the "drawable", also known as the drawing area of the window for the context.
-
-== Texture management ==
-
-What follows is a description of the texture management system in the DRI. This is all based on the Radeon driver in the 11-Feb-2002 CVS of the mesa-4-0-branch. While it is based on the Radeon code, all drivers except gamma and tdfx seem to use the same scheme (and virtually identical code).
-
-  * Excluding the texture backing store, which is managed by Mesa, texture data is tracked in two places. The per-screen (card) SAREA divides each type of texturable memory (on-card, AGP, etc.) into an array of fixed sized chunks (RADEONSAREAPriv.texList in `programs/Xserver/hw/xfree86/drivers/ati/radeon_sarea.h`). The number of these chunks is a compile-time constant, and it cannot be changed without destroying the universe. That is, any changes here will present major compatibility issues. Currently, this constant is 64. So, for the new 128MB Radeon 8500 cards, each block of memory will likely be 1MB or more. This is not as bad as it may first seem, see below. The usage of each type of memory is also tracked per-context.
-  * The per-context memory tracking is done using a memHeap_t. Allocations from the memHeap_t (see lib/GL/mesa/src/drv/common/mm.c) are done at byte granularity. When a context needs a block of texture memory, it is allocated from the memHeap_t. This results in very little memory fragmentation (within a context). After the allocation is made, the map of allocated memory in the SAREA is updated (radeonUpdateTexLRU in `lib/GL/mesa/src/drv/radeon/radeon_texmem.c`). Basically, each block of memory in texList that corresponds to an allocated region (in the per-context memHeap_t) is marked as allocated.
-  * The texList isn't just an array of blocks. It's also a priority queue (linked list). As each texture is accessed, the blocks that it occupies are moved to the head of the queue. In the Radeon code, each time a texture is uploaded or bound to a texture unit, the blocks of memory (in AGP space or on-card) are moved to the head of the texList queue.
-  * If an allocation (via the memHeap_t) fails when texture space is allocated (radeonUploadTexImages in `lib/GL/mesa/src/drv/radeon/radeon_texmem.c`), blocks at the end of the texList queue are freed until the allocation can succeed.This may be an area where the algorithm could be improved. For example, it might be better to find the largest free block (in the memHeap_t) and release memory around that block in LRU or least-often-used fashion until the allocation can succeed. This may be too difficult to get right or too slow when done right. Someone would have to try it and see.
-  * Each time a direct-client detects that another client has held the per-screen lock, radeonGetLock is called. This synchronizes the per-context vision of the hardware state. Part of this synchronization is synchronizing the view of texture memory. In addition to the texList, the SAREA holds a texAge array. This array stores the generation number of each of the texture heaps. If a client detects that the generation number of a heap has changed in radeonGetLock, it calls radeonAgeTextures for that heap. radeonAgeTextures runs through the texList looking for blocks with a more recent generation number. Each block that has a newer generation is passed to radeonTexturesGone.
-  * radeonTexturesGone searches the per-context memHeap_t for an allocated region matching the block with the updated generation. When a matching region is found, it is freed, and if the region was for a texture in the local context, the local state of that texture is updated. If the updated block (from the global context) is "in-use" (i.e., some other context has stolen that block from the current context), the block is re-allocated and marked as in-use by another context.
-  * It seems that about 2 years ago a few people (from the CVS log) had taken a stab at factoring the common code out and put it in `shared_texture_lru.[ch]` in `lib/GL/mesa/src/drv/common` but it isn't used and hasn't been touched (at least not in CVS) since 4-April-2000.
-
-'''Note:''' Just FYI: the tdfx texture memory management code is different because:
-
-  1. It was originally developed before the scheme KeithWhitwell implemented for the i810 and mga drivers (and later used for the R128 and radeon).
-  1. There are some idiosynchracies with the Voodoo3 such as two separate banks of TRAM and needing to store alternate mipmap levels in alternate banks.
-  1. We did everything through the Glide interface, rather than working directly with the hardware.
-
-  -- IanRomanick
-
-== How often are checks done to see if things need clipped/redrawn/redisplayed? ==
-
-The locking system is designed to be highly efficient. It is based on a two tiered lock. Basically it works like this:
-
-The client wants the lock. The use the CAS (I was corrected that the instruction is compare and swap, I knew that was the functionality, but I got the name wrong) If the client was the last application to hold the lock, you're done you move on.
-
-If it wasn't the last one, then we use an IOCTL to the kernel to arbitrate the lock.
-
-In this case some or all of the state on the card may have changed. The shared memory carries a stamp number for the X server. When the X server does a window operation it increments the stamp. If the client sees that the stamp has changed, it uses a DRI X protocol request to get new window location and clip rects. This only happens on a window move. Assuming your clip rects/window position hasn't changed, the redisplay happens entirely in the client.
-
-The client may have other state to restore as well. In the case of the tdfx driver we have three more flags for command fifo invalid, 3D state invalid, textures invalid. If those are set the corresponding state is restored.
-
-So, if the X server wakes up to process input, it currently grabs the lock but doesn't invalidate any state. I'm actually fixing this now so that it doesn't grab the lock for input processing.
-
-If the X server draws, it grabs the lock and invalidates the command FIFO.
-
-If the X server moves a window, it grabs the lock, updates the stamp, and invalidates the command FIFO.
-
-If another 3D app runs, it grabs the lock, invalidates the command FIFO, invalidates the 3D state and possibly invalidates the texture state.
diff --git a/MesaImplementationNotesOld.mdwn b/MesaImplementationNotesOld.mdwn
new file mode 100644
index 0000000..937d1dc
--- /dev/null
+++ b/MesaImplementationNotesOld.mdwn
@@ -0,0 +1,105 @@
+
+
+### Old Mesa 3.4.x Implementation Notes
+
+This document is an overview of the internal structure of Mesa and is meant for those who are interested in modifying or enhancing Mesa, or just curious. 
+
+**Note:** Based on the original [[Mesa Implementation Notes|http://www.mesa3d.org/docs/Implementation.html]] by Brian Paul. 
+
+
+#### Library State and Contexts
+
+OpenGL uses the notion of a state machine. Mesa encapsulates the state in one large structure: gl_context, as seen in types.h. 
+
+The gl_context structure actually contains a number of sub structures which exactly correspond to OpenGL's attribute groups. This organization made glPushAttrib and glPopAttrib trivial to implement and proved to be a good way of organizing the state variables. 
+
+
+#### Vertex buffer
+
+The vertices between glBegin and glEnd are accumulated in the vertex buffer (see [[vb.h|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/vb.h?rev=HEAD&content-type=text/vnd.viewcvs-markup]] and [[vb.c|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/vb.c?rev=HEAD&content-type=text/vnd.viewcvs-markup]] ). When either the vertex buffer becomes filled or a state change outside the glBegin/glEnd is made, we must flush the buffer. That is, we apply the vertex transformations, compute lighting, fog, texture coordinates etc. Then, we can render the vertices as points, lines or polygons by calling the gl_render_vb() function in [[render.c|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/render.c?rev=HEAD&content-type=text/vnd.viewcvs-markup]]. 
+
+When we're outside of a glBegin/glEnd pair the information in this structure is retained pending either of the flushing events described above. 
+
+**Note:** Originally, Mesa didn't accumulate vertices in this way. Instead, glVertex transformed and lit then buffered each vertex as it was received. When enough vertices to draw the primitive (1 for points, 2 for lines, >2 for polygons) were accumulated the primitive was drawn and the buffer cleared. 
+
+The new approach of buffering many vertices and then transforming, lighting and clip testing is faster because it's done in a "vectorized" manner. See gl_transform_points in [[xform.c|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/xform.c?rev=HEAD&content-type=text/vnd.viewcvs-markup]] for an example. Also, vertices shared between primitives (i.e. `GL_LINE_STRIP`) are only transformed once. 
+
+The only complication is clipping. If no vertices in the vertex buffer have their clip flag set, the rasterization functions can be applied directly to the vertex buffer. Otherwise, a clipping function is called before rasterizing each primitive. If clipping introduces new vertices they will be stored at the end of the vertex buffer. 
+
+For best performance Mesa clients should try to maximize the number of vertices between glBegin/glEnd pairs and used connected primitives when possible. 
+
+
+#### Rasterization
+
+The point, line and polygon rasterizers are called via the [[PointsFunc|PointsFunc]], [[LineFunc|LineFunc]], and [[TriangleFunc|TriangleFunc]] function pointers in the dd_function_table driver function pointer table. Whenever the library state is changed in a significant way, the [[NewState|NewState]] context flag is raised. When glBegin is called [[NewState|NewState]] is checked. If the flag is set we re-evaluate the state to determine what rasterizers to use. Special purpose rasterizers are selected according to the status of certain state variables such as flat vs smooth shading, depth-buffered vs. non-depth- buffered, etc. The gl_set_point|line|polygon_function functions do this analysis. They in turn query the device driver for "accelerated" rasterizers. More on that later. 
+
+In general, typical states (depth-buffered & smooth-shading) result in optimized rasterizers being selected. Non-typical states (stenciling, blending, stippling) result in slower, general purpose rasterizers being selected. 
+
+
+#### Pixel (fragment) buffer
+
+The general purpose point, line and bitmap rasterizers accumulate fragments (pixels plus color, depth, texture coordinates) in the PB (Pixel Buffer) structure seen in . [[pb.h|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/pb.h?rev=HEAD&content-type=text/vnd.viewcvs-markup]] and [[pb.c|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/pb.c?rev=HEAD&content-type=text/vnd.viewcvs-markup]]. When the pixel buffer is full or glEnd is called the pixel buffer is flushed. This includes clipping the fragments against the window, depth testing, stenciling, blending, stippling, etc. Finally, the pixel buffer's pixels are drawn to the display buffer by calling one of device driver functions. The goal is to maximize the number of pixels processed inside loops and to minimize the number of function calls. 
+
+
+#### Pixel spans
+
+The polygon, glDrawPixels, and glCopyPixels functions generate horizontal runs of pixels called spans. Spans are processed in [[span.c|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/span.c?rev=HEAD&content-type=text/vnd.viewcvs-markup]]. Processing includes window clipping, depth testing, stenciling, texturing, etc. After processing the span is written to the frame buffer by calling a device driver function. 
+
+
+#### Device Driver
+
+There are three Mesa data types which are meant to be used by device drivers: 
+GLcontext
+: this contains the Mesa rendering state 
+
+GLvisual
+: this describes the color buffer (RGB vs. CI), whether or not there's a depth buffer, stencil buffer, etc. 
+
+GLframebuffer
+: contains pointers to the depth buffer, stencil buffer, accum buffer and alpha buffers. 
+
+
+These types should be encapsulated by corresponding device driver data types. See [[xmesa.h|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/xmesa.h?rev=HEAD&content-type=text/vnd.viewcvs-markup]] and [[xmesaP.h|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/xmesaP.h?rev=HEAD&content-type=text/vnd.viewcvs-markup]] for an example. 
+
+In OOP terms, GLcontext, GLvisual, and GLframebuffer are base classes which the device driver must derive from. 
+
+The structure dd_function_table seen in [[dd.h|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/dd.h?rev=HEAD&content-type=text/vnd.viewcvs-markup]], defines the device driver functions. By using a table of pointers, the device driver can be changed dynamically at runtime. For example, the X/Mesa and OS/Mesa (Off-Screen rendering) device drivers can co-exist in one library and be selected at runtime. 
+
+In addition to the device driver table functions, each Mesa driver has its own set of unique interface functions. For example, the X/Mesa driver has the XMesaCreateContext, XMesaBindWindow, and XMesaSwapBuffers functions while the Windows/Mesa interface has WMesaCreateContext, WMesaPaletteChange and WMesaSwapBuffers. New Mesa drivers need to both implement the dd_function_table functions and define a set of unique window system or operating system-specific interface functions. 
+
+The device driver functions can roughly be divided into four groups: 
+
+   1. pixel span functions which read or write horizontal runs of RGB or color-index pixels. Each function takes an array of mask flags which indicate whether or not to plot each pixel in the span. 
+   1. pixel array functions which are very similar to the pixel span functions except that they're used to read or write arrays of pixels at random locations rather than horizontal runs. 
+   1. miscellaneous functions for window clearing, setting the current drawing color, enabling/disabling dithering, returning the current frame buffer size, specifying the window clear color, synchronization, etc. Most of these functions directly correspond to higher level OpenGL functions. 
+   1. if your graphics hardware or operating system provides accelerated point, line and polygon rendering operations, they can be utilized through the [[PointsFunc|PointsFunc]], [[LineFunc|LineFunc]], and [[TriangleFunc|TriangleFunc]] functions. Mesa will call these functions to "ask" the device driver for accelerated functions through the [[UpdateState|UpdateState]]. If the device driver can provide an appropriate renderer, given the current Mesa state, then a pointer to that function can be returned. Otherwise the [[PointsFunc|PointsFunc]], [[LineFunc|LineFunc]], and [[TriangleFunc|TriangleFunc]] functions pointers can just be set to NULL. 
+Even if hardware accelerated renderers aren't available, the device driver may implement tuned, special purpose code for common kinds of points, lines or polygons. The X/Mesa device driver does this for a number of lines and polygons. See the [[xmesa3.c|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/xmesa3.c?rev=HEAD&content-type=text/vnd.viewcvs-markup]] file. 
+
+
+#### Overall Organization
+
+The overall relation of the core Mesa library, X device driver/interface, toolkits and application programs is shown in this diagram: 
+
+
+[[!format txt """
++-----------------------------------------------------------+
+|                                                           |
+|                   Application Programs                    |
+|                                                           |
+|          +- glu.h -+------ glut.h -------+                |
+|          |         |                     |                |
+|          |   GLU   |        GLUT         |                |
+|          |         |      toolkits       |                |
+|          |         |                     |                |
++---------- gl.h ------------+-------- glx.h ----+          |
+|                            |                   |          |
+|         Mesa core          |   GLX functions   |          |
+|                            |                   |          |
++---------- dd.h ------------+------------- xmesa.h --------+
+|                                                           |
+|              XMesa* and device driver functions           |
+|                                                           |
++-----------------------------------------------------------+
+|                 Hardware/OS/Window System                 |
++-----------------------------------------------------------+
+"""]]
+\ No newline at end of file
diff --git a/MesaImplementationNotesOld.moin b/MesaImplementationNotesOld.moin
deleted file mode 100644
index ab7c364..0000000
--- a/MesaImplementationNotesOld.moin
+++ /dev/null
@@ -1,95 +0,0 @@
-=== Old Mesa 3.4.x Implementation Notes ===
-
-This document is an overview of the internal structure of Mesa and is meant for those who are interested in modifying or enhancing Mesa, or just curious.
-
-'''Note:''' Based on the original [[http://www.mesa3d.org/docs/Implementation.html|Mesa Implementation Notes]] by Brian Paul.
-
-
-==== Library State and Contexts ====
-
-OpenGL uses the notion of a state machine. Mesa encapsulates the state in one large structure: gl_context, as seen in types.h.
-
-The gl_context structure actually contains a number of sub structures which exactly correspond to OpenGL's attribute groups. This organization made glPushAttrib and glPopAttrib trivial to implement and proved to be a good way of organizing the state variables.
-
-==== Vertex buffer ====
-
-The vertices between glBegin and glEnd are accumulated in the vertex buffer (see [[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/vb.h?rev=HEAD&content-type=text/vnd.viewcvs-markup|vb.h]] and [[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/vb.c?rev=HEAD&content-type=text/vnd.viewcvs-markup|vb.c]] ). When either the vertex buffer becomes filled or a state change outside the glBegin/glEnd is made, we must flush the buffer. That is, we apply the vertex transformations, compute lighting, fog, texture coordinates etc. Then, we can render the vertices as points, lines or polygons by calling the gl_render_vb() function in [[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/render.c?rev=HEAD&content-type=text/vnd.viewcvs-markup|render.c]].
-
-When we're outside of a glBegin/glEnd pair the information in this structure is retained pending either of the flushing events described above.
-
-'''Note:''' Originally, Mesa didn't accumulate vertices in this way. Instead, glVertex transformed and lit then buffered each vertex as it was received. When enough vertices to draw the primitive (1 for points, 2 for lines, >2 for polygons) were accumulated the primitive was drawn and the buffer cleared.
-
-The new approach of buffering many vertices and then transforming, lighting and clip testing is faster because it's done in a "vectorized" manner. See gl_transform_points in [[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/xform.c?rev=HEAD&content-type=text/vnd.viewcvs-markup|xform.c]] for an example. Also, vertices shared between primitives (i.e. `GL_LINE_STRIP`) are only transformed once.
-
-
-The only complication is clipping. If no vertices in the vertex buffer have their clip flag set, the rasterization functions can be applied directly to the vertex buffer. Otherwise, a clipping function is called before rasterizing each primitive. If clipping introduces new vertices they will be stored at the end of the vertex buffer.
-
-For best performance Mesa clients should try to maximize the number of vertices between glBegin/glEnd pairs and used connected primitives when possible.
-
-==== Rasterization ====
-
-The point, line and polygon rasterizers are called via the PointsFunc, LineFunc, and TriangleFunc function pointers in the dd_function_table driver function pointer table. Whenever the library state is changed in a significant way, the NewState context flag is raised. When glBegin is called NewState is checked. If the flag is set we re-evaluate the state to determine what rasterizers to use. Special purpose rasterizers are selected according to the status of certain state variables such as flat vs smooth shading, depth-buffered vs. non-depth- buffered, etc. The gl_set_point|line|polygon_function functions do this analysis. They in turn query the device driver for "accelerated" rasterizers. More on that later.
-
-In general, typical states (depth-buffered & smooth-shading) result in optimized rasterizers being selected. Non-typical states (stenciling, blending, stippling) result in slower, general purpose rasterizers being selected.
-
-==== Pixel (fragment) buffer ====
-
-The general purpose point, line and bitmap rasterizers accumulate fragments (pixels plus color, depth, texture coordinates) in the PB (Pixel Buffer) structure seen in . [[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/pb.h?rev=HEAD&content-type=text/vnd.viewcvs-markup|pb.h]] and [[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/pb.c?rev=HEAD&content-type=text/vnd.viewcvs-markup|pb.c]]. When the pixel buffer is full or glEnd is called the pixel buffer is flushed. This includes clipping the fragments against the window, depth testing, stenciling, blending, stippling, etc. Finally, the pixel buffer's pixels are drawn to the display buffer by calling one of device driver functions. The goal is to maximize the number of pixels processed inside loops and to minimize the number of function calls.
-
-==== Pixel spans ====
-
-The polygon, glDrawPixels, and glCopyPixels functions generate horizontal runs of pixels called spans. Spans are processed in [[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/span.c?rev=HEAD&content-type=text/vnd.viewcvs-markup|span.c]]. Processing includes window clipping, depth testing, stenciling, texturing, etc. After processing the span is written to the frame buffer by calling a device driver function.
-
-==== Device Driver ====
-
-There are three Mesa data types which are meant to be used by device drivers:
-
- GLcontext:: this contains the Mesa rendering state
-
- GLvisual:: this describes the color buffer (RGB vs. CI), whether or not there's a depth buffer, stencil buffer, etc.
-
- GLframebuffer:: contains pointers to the depth buffer, stencil buffer, accum buffer and alpha buffers.
-
-These types should be encapsulated by corresponding device driver data types. See [[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/xmesa.h?rev=HEAD&content-type=text/vnd.viewcvs-markup|xmesa.h]] and [[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/xmesaP.h?rev=HEAD&content-type=text/vnd.viewcvs-markup|xmesaP.h]] for an example.
-
-In OOP terms, GLcontext, GLvisual, and GLframebuffer are base classes which the device driver must derive from.
-
-The structure dd_function_table seen in [[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/dd.h?rev=HEAD&content-type=text/vnd.viewcvs-markup|dd.h]], defines the device driver functions. By using a table of pointers, the device driver can be changed dynamically at runtime. For example, the X/Mesa and OS/Mesa (Off-Screen rendering) device drivers can co-exist in one library and be selected at runtime.
-
-In addition to the device driver table functions, each Mesa driver has its own set of unique interface functions. For example, the X/Mesa driver has the XMesaCreateContext, XMesaBindWindow, and XMesaSwapBuffers functions while the Windows/Mesa interface has WMesaCreateContext, WMesaPaletteChange and WMesaSwapBuffers. New Mesa drivers need to both implement the dd_function_table functions and define a set of unique window system or operating system-specific interface functions.
-
-The device driver functions can roughly be divided into four groups:
-
-  1. pixel span functions which read or write horizontal runs of RGB or color-index pixels. Each function takes an array of mask flags which indicate whether or not to plot each pixel in the span.
-  1. pixel array functions which are very similar to the pixel span functions except that they're used to read or write arrays of pixels at random locations rather than horizontal runs.
-  1. miscellaneous functions for window clearing, setting the current drawing color, enabling/disabling dithering, returning the current frame buffer size, specifying the window clear color, synchronization, etc. Most of these functions directly correspond to higher level OpenGL functions.
-  1. if your graphics hardware or operating system provides accelerated point, line and polygon rendering operations, they can be utilized through the PointsFunc, LineFunc, and TriangleFunc functions. Mesa will call these functions to "ask" the device driver for accelerated functions through the UpdateState. If the device driver can provide an appropriate renderer, given the current Mesa state, then a pointer to that function can be returned. Otherwise the PointsFunc, LineFunc, and TriangleFunc functions pointers can just be set to NULL.
-
-Even if hardware accelerated renderers aren't available, the device driver may implement tuned, special purpose code for common kinds of points, lines or polygons. The X/Mesa device driver does this for a number of lines and polygons. See the [[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/extras/Mesa/src/xmesa3.c?rev=HEAD&content-type=text/vnd.viewcvs-markup|xmesa3.c]] file.
-
-==== Overall Organization ====
-
-The overall relation of the core Mesa library, X device driver/interface, toolkits and application programs is shown in this diagram:
-
-{{{
-+-----------------------------------------------------------+
-|                                                           |
-|                   Application Programs                    |
-|                                                           |
-|          +- glu.h -+------ glut.h -------+                |
-|          |         |                     |                |
-|          |   GLU   |        GLUT         |                |
-|          |         |      toolkits       |                |
-|          |         |                     |                |
-+---------- gl.h ------------+-------- glx.h ----+          |
-|                            |                   |          |
-|         Mesa core          |   GLX functions   |          |
-|                            |                   |          |
-+---------- dd.h ------------+------------- xmesa.h --------+
-|                                                           |
-|              XMesa* and device driver functions           |
-|                                                           |
-+-----------------------------------------------------------+
-|                 Hardware/OS/Window System                 |
-+-----------------------------------------------------------+
-}}}
diff --git a/MesaWishList.mdwn b/MesaWishList.mdwn
new file mode 100644
index 0000000..25365a2
--- /dev/null
+++ b/MesaWishList.mdwn
@@ -0,0 +1,41 @@
+
+
+# Mesa Wish List
+
+This page is the list of projects and enhancements that people would _like_ to see in the next development release of Mesa.  An item being on this list does not guarantee its inclusion, nor does it necessarily mean that anyone is working on it. 
+
+Please add driver-specific items to a per-driver wish list wiki entry. 
+
+* Continued enhancements to libGL and loader / driver interface. 
+      * Enhancements for [[PartiallyAliasedFunctions|PartiallyAliasedFunctions]] (see also [[bug #4681|https://bugs.freedesktop.org/show_bug.cgi?id=4681]]). **Done.** 
+      * Misc. clean ups in the loader / driver interfaces (see [[bug #5714|https://bugs.freedesktop.org/show_bug.cgi?id=5714]]). 
+      * Move vsync interfaces out into the loader, at least the parts that wait for events. This will e.g. allow AIGLX to suspend clients instead of blocking the X server. 
+      * Fix MSC interfaces to reference the drawable, so the corresponding head can be determined in multihead environments. 
+      * Support for pbuffers within the loader / driver interface.  Even if a DRI driver does not support any pbuffer capable fbconfigs, this will allow us to advertise GLX 1.4.  That is a _good_ thing. 
+            * Entries in `__DRIdrawableRec` for `GetDrawableAttributes` and `ChangeDrawableAttribute`. 
+            * Modify libGL to handle pbuffers correctly for direct rendering contexts.  It currently treats all pbuffer commands as indirect rendering. 
+      * Run-time dispatch function generation.  See the thread [[Dispatch generation for x86-64|http://marc.theaimsgroup.com/?l=mesa3d-dev&m=115197849909114&w=2]]. 
+            * Support for "secure" dispatch generation. 
+            * Dispatch generation for x86-64 (see [[bug #3379|https://bugs.freedesktop.org/show_bug.cgi?id=3379]]). 
+      * Provide generic optimization for indirect rendering of [[CompiledVertexArray|CompiledVertexArray]]. 
+* Shading Language / Programmable Pipeline Enhancements 
+      * Migrate the "assembly" programming interface to use the Yacc based front-end developed by [[IanRomanick|IanRomanick]] for the [[PSU vertex program compiler project|https://projects.cecs.pdx.edu/svn/arb_vertex/glasm]].  The advantage of this front-end is that it supports a _lot_ more of the assembly programming extensions than the existing front-end. 
+      * Migrate the "assembly" programming interface to use the back-end used by the GLSL compiler.  This implies that the existing drivers that support the assembly interfaces will also need to migrate to that interface.  The good news is that those drivers will, with fallbacks, automatically get support for GLSL. 
+      * Implement a GLSL back-end for x86-64. 
+      * Implement a GLSL back-end for PowerPC. 
+* Add missing functionality from GL 2.0.  I believe that all the functionality is supported.  It seems that we're just missing the updated interfaces (e.g., the GLSL interfaces changed from the ARB extension to core GL 2.0) to this functionality. 
+      * GLSL (already supported?) 
+      * MRT (supported) 
+      * Non-power-of-two textures (supported) 
+      * Point sprites (supported) 
+      * Two-sided stencil (supported with old interface) 
+* Add missing functionality from GL 2.1. 
+      * GLSL changes. 
+      * Non-square matrices (e.g., glUniformMatrix2x3). 
+      * Pixel-buffer objects (already supported?). 
+      * sRGB textures. 
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/MesaWishList.moin b/MesaWishList.moin
deleted file mode 100644
index ba80fb7..0000000
--- a/MesaWishList.moin
+++ /dev/null
@@ -1,36 +0,0 @@
-= Mesa Wish List =
-
-This page is the list of projects and enhancements that people would ''like'' to see in the next development release of Mesa.  An item being on this list does not guarantee its inclusion, nor does it necessarily mean that anyone is working on it.
-
-Please add driver-specific items to a per-driver wish list wiki entry.
-
- * Continued enhancements to libGL and loader / driver interface.
-   * Enhancements for PartiallyAliasedFunctions (see also [[https://bugs.freedesktop.org/show_bug.cgi?id=4681|bug #4681]]). '''Done.'''
-   * Misc. clean ups in the loader / driver interfaces (see [[https://bugs.freedesktop.org/show_bug.cgi?id=5714|bug #5714]]).
-   * Move vsync interfaces out into the loader, at least the parts that wait for events. This will e.g. allow AIGLX to suspend clients instead of blocking the X server.
-   * Fix MSC interfaces to reference the drawable, so the corresponding head can be determined in multihead environments.
-   * Support for pbuffers within the loader / driver interface.  Even if a DRI driver does not support any pbuffer capable fbconfigs, this will allow us to advertise GLX 1.4.  That is a ''good'' thing.
-     * Entries in {{{__DRIdrawableRec}}} for {{{GetDrawableAttributes}}} and {{{ChangeDrawableAttribute}}}.
-     * Modify libGL to handle pbuffers correctly for direct rendering contexts.  It currently treats all pbuffer commands as indirect rendering.
-   * Run-time dispatch function generation.  See the thread [[http://marc.theaimsgroup.com/?l=mesa3d-dev&m=115197849909114&w=2|Dispatch generation for x86-64]].
-     * Support for "secure" dispatch generation.
-     * Dispatch generation for x86-64 (see [[https://bugs.freedesktop.org/show_bug.cgi?id=3379|bug #3379]]).
-   * Provide generic optimization for indirect rendering of CompiledVertexArray.
- * Shading Language / Programmable Pipeline Enhancements
-   * Migrate the "assembly" programming interface to use the Yacc based front-end developed by IanRomanick for the [[https://projects.cecs.pdx.edu/svn/arb_vertex/glasm|PSU vertex program compiler project]].  The advantage of this front-end is that it supports a ''lot'' more of the assembly programming extensions than the existing front-end.
-   * Migrate the "assembly" programming interface to use the back-end used by the GLSL compiler.  This implies that the existing drivers that support the assembly interfaces will also need to migrate to that interface.  The good news is that those drivers will, with fallbacks, automatically get support for GLSL.
-   * Implement a GLSL back-end for x86-64.
-   * Implement a GLSL back-end for PowerPC.
- * Add missing functionality from GL 2.0.  I believe that all the functionality is supported.  It seems that we're just missing the updated interfaces (e.g., the GLSL interfaces changed from the ARB extension to core GL 2.0) to this functionality.
-   * GLSL (already supported?)
-   * MRT (supported)
-   * Non-power-of-two textures (supported)
-   * Point sprites (supported)
-   * Two-sided stencil (supported with old interface)
- * Add missing functionality from GL 2.1.
-   * GLSL changes.
-   * Non-square matrices (e.g., glUniformMatrix2x3).
-   * Pixel-buffer objects (already supported?).
-   * sRGB textures.
-----
-CategoryHomepage
diff --git a/MichelDaenzer.mdwn b/MichelDaenzer.mdwn
new file mode 100644
index 0000000..0c09a3b
--- /dev/null
+++ b/MichelDaenzer.mdwn
@@ -0,0 +1,11 @@
+
+
+## Michel Dänzer
+Email
+: michel at daenzer dot net 
+
+Interests
+: 
+      * AMD/ATI Radeon drivers 
+      * Debian 
+      * PowerPC 
+\ No newline at end of file
diff --git a/MichelDaenzer.moin b/MichelDaenzer.moin
deleted file mode 100644
index 84d31cb..0000000
--- a/MichelDaenzer.moin
+++ /dev/null
@@ -1,8 +0,0 @@
-== Michel Dänzer ==
-
- Email:: michel at daenzer dot net
-
- Interests::
-   * AMD/ATI Radeon drivers
-   * Debian
-   * PowerPC
diff --git a/MikeHarris.mdwn b/MikeHarris.mdwn
new file mode 100644
index 0000000..17e2088
--- /dev/null
+++ b/MikeHarris.mdwn
@@ -0,0 +1,2 @@
+
+Mike A. Harris is doing grafics codings for [[RedHat|RedHat]]. 
diff --git a/MikeHarris.moin b/MikeHarris.moin
deleted file mode 100644
index 8704eaa..0000000
--- a/MikeHarris.moin
+++ /dev/null
@@ -1 +0,0 @@
-Mike A. Harris is doing grafics codings for RedHat.
diff --git a/MiniGLX.mdwn b/MiniGLX.mdwn
new file mode 100644
index 0000000..785a98a
--- /dev/null
+++ b/MiniGLX.mdwn
@@ -0,0 +1,20 @@
+
+
+## Mini-GLX
+
+[[ToDo|ToDo]] (It's an project to get the DRI running directly on a console with the Radeon.) 
+
+
+### Resources
+
+Take a look to the embedded-1-branch in [[Mesa CVS repository|http://sourceforge.net/cvs/?group_id=3]].  
+
+
+### See also
+
+   * DriWithoutX 
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/MiniGLX.moin b/MiniGLX.moin
deleted file mode 100644
index 2a4866e..0000000
--- a/MiniGLX.moin
+++ /dev/null
@@ -1,14 +0,0 @@
-== Mini-GLX ==
-
-ToDo (It's an project to get the DRI running directly on a console with the Radeon.)
-
-=== Resources ===
-
-Take a look to the embedded-1-branch in [[http://sourceforge.net/cvs/?group_id=3|Mesa CVS repository]]. 
-
-=== See also ===
-
-  * DriWithoutX
-
-----
-CategoryGlossary
diff --git a/MissingFunctionality.mdwn b/MissingFunctionality.mdwn
new file mode 100644
index 0000000..aa29dd7
--- /dev/null
+++ b/MissingFunctionality.mdwn
@@ -0,0 +1,48 @@
+[[!table header="no" class="mointable" data="""
+**Texture Format Related Features** | GL Version | Mesa Version | i965 | r600g | Difficulty | Notes
+GL_ARB_texture_rg    | 3.0       | 7.10 | 7.10 | 7.10 |   |  
+GL_ARB_texture_float | 3.0       | 7.11 | 7.11 | 7.11 |   |  
+GL_EXT_texture_array | 3.0       | 7.8  | 8.0  | 8.0  |   |  Test implicit interactions with S3TC 
+GL_EXT_texture_integer (texture formats) | 3.0 | 8.0   | 8.0  | 8.0  |   |  
+GL_EXT_packed_float       | 3.0   | 7.11 | 8.0  | 7.11 |   |  
+GL_EXT_texture_shared_exponent | 3.0 | 7.11 | 8.0  | 7.11 |  
+GL_ARB_half_float_pixel   | 3.0   | 6.5  | 7.11 | 7.9  |   |  
+GL_EXT_texture_compression_rgtc | 3.0 | 7.11 | 7.11 | 7.11 |   |  
+GL_EXT_texture_snorm      | 3.1   | 7.11 | 7.11 | 7.11 |   |  
+GL_ARB_texture_multisample |  3.2  | No  | Doable | Doable | Weeks? |  
+GL_ARB_texture_rgb10_a2ui | 3.3   | 8.0  | 9.0  | 8.0  |   |  
+**Draw-call Related Features** | GL Version | Mesa Version | i965 | r600g | Difficulty | Notes
+GL_EXT_transform_feedback | 3.0   | 8.0  | 8.0  | 8.0  |   |   
+GL_NV_conditional_render  | 3.0   | 7.8  | 7.11 | 7.11 |   | Supported using waiting for OQ results so far on Intel.
+GL_ARB_draw_instanced     | 3.1   | 7.11 | 9.0  | 7.11? | Days |  
+GL_NV_primitive_restart   | 3.1   | 7.10 | 9.0  | 8.0  |   |  
+GL_ARB_instanced_arrays   | 3.3   | Yes  | 9.0 | 7.11 | Weeks | Even adding trivial software emulation would save the validation required for N-1 draw calls. 
+GL_ARB_occlusion_query2   | 3.3   | 7.11 | 7.11 | 7.11 |   |  
+GL_ARB_vertex_type_2_10_10_10_rev | 3.3 | 8.0 | Doable | 8.0  | Weeks |   
+**Render-target Related Features** | GL Version | Mesa Version | i965 | r600g | Difficulty | Notes
+GL_ARB_color_buffer_float | 3.0   | 7.11 | 7.11   | 7.11 |   |  
+GL_ARB_depth_buffer_float | 3.0   | 8.0  | 8.0  | 8.0  |   | 
+GL_EXT_texture_integer (render formats) | 3.0 | 8.0  | 8.0  | 8.0  |   |  
+GL_EXT_draw_buffers2      | 3.0   | 7.8 | 7.9 | 7.10 |   | 
+GL_ARB_blend_func_extended | 3.3  | 9.0 | 9.0 | 9.0 |   |  
+GL_EXT_framebuffer_sRGB    | 3.0  | 7.11 | 7.11 | 7.11 |   |  
+**Shading Language Features** | GL Version | Mesa Version | i965 | r600g | Difficulty | Notes
+GLSL 1.30                 | 3.0   | 8.0  | 8.0  | 8.0  |   |  
+GL_EXT_gpu_shader4        | 3.1   | No | Doable | Doable | Weeks |  
+GLSL 1.40                 | 3.1   | 9.0 | 9.0  | 9.0  |   |  
+GL_ARB_texture_buffer_object | 3.1 | 9.0 | 9.0  | 9.0  |   |  
+GL_ARB_uniform_buffer_object | 3.1 | 9.0 | 9.0  | 9.0  | Months |  
+16 vertex textures        | 3.0   | Yes | 8.0    | 7.11     |   |  
+GLSL 1.50                 | 3.2   | No | Doable | Doable | Months | Piles and piles of work.
+GL_ARB_geometry_shader4   | 3.2   | Partial? | Doable | Doable | Months |  Plombo is working on it: [[https://github.com/Plombo/mesa/tree/geometry-shaders-rebase|https://github.com/Plombo/mesa/tree/geometry-shaders-rebase]] 
+GL_ARB_fragment_coord_conventions | 3.2 | 7.8  | 7.10 | 7.8  |   | 
+GL_ARB_shader_bit_encoding | 3.3  | 9.0 | 9.0 | 9.0 |   |  
+GL_ARB_explicit_attrib_location | 3.3 | 7.10 | 7.10 | 7.10 |   |  
+**Misc. Features** | GL Version | Mesa Version | i965 | r600g | Difficulty | Notes
+GL_ARB_sampler_objects    | 3.3   | 7.11      | 7.11      | 7.11 |      |  
+GL_ARB_texture_swizzle    | 3.3   | 7.9 (7.5) | 7.9 (7.5) | 7.9  |      | Originally GL_EXT_texture_swizzle in Mesa 7.5.
+GL_ARB_timer_query        | 3.3   | 7.9       | 9.0  | 9.0  |   |  
+**GLX / EGL Features** | GL Version | Mesa Version | i965 | r600g | Difficulty | Notes
+GLX_ARB_create_context         | 3.0   | 8.0  | 8.0  | 8.0  |   |  
+GLX_ARB_create_context_profile | 3.2   | 8.0  | 8.0  | 8.0  | Weeks | Mesa drivers don't actually support profiles yet, and Xserver support for this extension has not be implemented.  There is still work to do here.
+"""]]
diff --git a/MissingFunctionality.moin b/MissingFunctionality.moin
deleted file mode 100644
index 5bac0a2..0000000
--- a/MissingFunctionality.moin
+++ /dev/null
@@ -1,46 +0,0 @@
-||<style="background-color: #666666">'''Texture Format Related Features'''||<style="background-color: #666666">GL Version||<style="background-color: #666666">Mesa Version||<style="background-color: #666666">i965||<style="background-color: #666666">r600g||<style="background-color: #666666">Difficulty||<style="background-color: #666666">Notes||
-||GL_ARB_texture_rg   ||3.0      ||7.10||7.10||7.10|| || ||
-||GL_ARB_texture_float||3.0      ||7.11||7.11||7.11|| || ||
-||GL_EXT_texture_array||3.0      ||7.8 ||8.0 ||8.0 || || Test implicit interactions with S3TC ||
-||GL_EXT_texture_integer (texture formats)||3.0||8.0  ||8.0 ||8.0 || || ||
-||GL_EXT_packed_float      ||3.0  ||7.11||8.0 ||7.11|| || ||
-||GL_EXT_texture_shared_exponent||3.0||7.11||8.0 ||7.11|| ||
-||GL_ARB_half_float_pixel  ||3.0  ||6.5 ||7.11||7.9 || || ||
-||GL_EXT_texture_compression_rgtc||3.0||7.11||7.11||7.11|| || ||
-||GL_EXT_texture_snorm     ||3.1  ||7.11||7.11||7.11|| || ||
-||GL_ARB_texture_multisample|| 3.2 ||No ||Doable||Doable||Weeks?|| ||
-||GL_ARB_texture_rgb10_a2ui||3.3  ||8.0 ||9.0 ||8.0 || || ||
-||<style="background-color: #666666">'''Draw-call Related Features'''||<style="background-color: #666666">GL Version||<style="background-color: #666666">Mesa Version||<style="background-color: #666666">i965||<style="background-color: #666666">r600g||<style="background-color: #666666">Difficulty||<style="background-color: #666666">Notes||
-||GL_EXT_transform_feedback||3.0  ||8.0 ||8.0 ||8.0 || ||  ||
-||GL_NV_conditional_render ||3.0  ||7.8 ||7.11||7.11|| ||Supported using waiting for OQ results so far on Intel.||
-||GL_ARB_draw_instanced    ||3.1  ||7.11||9.0 ||7.11?||Days|| ||
-||GL_NV_primitive_restart  ||3.1  ||7.10||9.0 ||8.0 || || ||
-||GL_ARB_instanced_arrays  ||3.3  ||Yes ||9.0||7.11||Weeks||Even adding trivial software emulation would save the validation required for N-1 draw calls. ||
-||GL_ARB_occlusion_query2  ||3.3  ||7.11||7.11||7.11|| || ||
-||GL_ARB_vertex_type_2_10_10_10_rev||3.3||8.0||Doable||8.0 ||Weeks||  ||
-||<style="background-color: #666666">'''Render-target Related Features'''||<style="background-color: #666666">GL Version||<style="background-color: #666666">Mesa Version||<style="background-color: #666666">i965||<style="background-color: #666666">r600g||<style="background-color: #666666">Difficulty||<style="background-color: #666666">Notes||
-||GL_ARB_color_buffer_float||3.0  ||7.11||7.11  ||7.11|| || ||
-||GL_ARB_depth_buffer_float||3.0  ||8.0 ||8.0 ||8.0 || ||||
-||GL_EXT_texture_integer (render formats)||3.0||8.0 ||8.0 ||8.0 || || ||
-||GL_EXT_draw_buffers2     ||3.0  ||7.8||7.9||7.10|| ||||
-||GL_ARB_blend_func_extended||3.3 ||9.0||9.0||9.0|| || ||
-||GL_EXT_framebuffer_sRGB   ||3.0 ||7.11||7.11||7.11|| || ||
-||<style="background-color: #666666">'''Shading Language Features'''||<style="background-color: #666666">GL Version||<style="background-color: #666666">Mesa Version||<style="background-color: #666666">i965||<style="background-color: #666666">r600g||<style="background-color: #666666">Difficulty||<style="background-color: #666666">Notes||
-||GLSL 1.30                ||3.0  ||8.0 ||8.0 ||8.0 || || ||
-||GL_EXT_gpu_shader4       ||3.1  ||No||Doable||Doable||Weeks|| ||
-||GLSL 1.40                ||3.1  ||9.0||9.0 ||9.0 || || ||
-||GL_ARB_texture_buffer_object||3.1||9.0||9.0 ||9.0 || || ||
-||GL_ARB_uniform_buffer_object||3.1||9.0||9.0 ||9.0 ||Months|| ||
-||16 vertex textures       ||3.0  ||Yes||8.0   ||7.11    || || ||
-||GLSL 1.50                ||3.2  ||No||Doable||Doable||Months||Piles and piles of work.||
-||GL_ARB_geometry_shader4  ||3.2  ||Partial?||Doable||Doable||Months|| Plombo is working on it: https://github.com/Plombo/mesa/tree/geometry-shaders-rebase ||
-||GL_ARB_fragment_coord_conventions||3.2||7.8 ||7.10||7.8 || ||||
-||GL_ARB_shader_bit_encoding||3.3 ||9.0||9.0||9.0|| || ||
-||GL_ARB_explicit_attrib_location||3.3||7.10||7.10||7.10|| || ||
-||<style="background-color: #666666">'''Misc. Features'''||<style="background-color: #666666">GL Version||<style="background-color: #666666">Mesa Version||<style="background-color: #666666">i965||<style="background-color: #666666">r600g||<style="background-color: #666666">Difficulty||<style="background-color: #666666">Notes||
-||GL_ARB_sampler_objects   ||3.3  ||7.11     ||7.11     ||7.11||    || ||
-||GL_ARB_texture_swizzle   ||3.3  ||7.9 (7.5)||7.9 (7.5)||7.9 ||    ||Originally GL_EXT_texture_swizzle in Mesa 7.5.||
-||GL_ARB_timer_query       ||3.3  ||7.9      ||9.0 ||9.0 || || ||
-||<style="background-color: #666666">'''GLX / EGL Features'''||<style="background-color: #666666">GL Version||<style="background-color: #666666">Mesa Version||<style="background-color: #666666">i965||<style="background-color: #666666">r600g||<style="background-color: #666666">Difficulty||<style="background-color: #666666">Notes||
-||GLX_ARB_create_context        ||3.0  ||8.0 ||8.0 ||8.0 || || ||
-||GLX_ARB_create_context_profile||3.2  ||8.0 ||8.0 ||8.0 ||Weeks||Mesa drivers don't actually support profiles yet, and Xserver support for this extension has not be implemented.  There is still work to do here.||
diff --git a/MultiHead.moin b/MultiHead.mdwn
index ca7a8ef..6b5d424 100644
--- a/MultiHead.moin
+++ b/MultiHead.mdwn
@@ -1,23 +1,26 @@
-= MultiHead =
-
-== Status ==
-
-Support for MultiHead configurations of XFree86 has been designed into the DRI. However, full implementations of multihead support have not be done. There are many variations on how multihead can be supported on XFree86. This section describes what's possible, and where more work is needed.
-
-Many of the challenges with supporting basic multiple adapter multihead reside in getting basic 2D initialization for *all* heads. Some XFree86 drivers work better than others in this area. The focus from a DRI perspective, is to make sure 3D works if 2D does. This has not been done for many of the DRI drivers, but is something that can be addressed at the driver level. When attempting to support basic multihead functionality within a driver, there are multiple levels of increasing complexity that should be addressed:
-
-  * 2D working on all heads, 3D on none
-
-  * 2D working on all heads, 3D working on a single head
-
-  * 2D working on all heads, 3D working on all heads
-
-For many configurations, the biggest development challenge for the last step may be getting AGPGART support going with multiple heads. It's possible to defer this by working with drivers that don't require this support (PCI-only).
-
-== See also ==
-
- * Xinerama
- * MergedFB
-
-----
-CategoryHelpWanted
+
+
+# MultiHead
+
+
+## Status
+
+Support for MultiHead configurations of XFree86 has been designed into the DRI. However, full implementations of multihead support have not be done. There are many variations on how multihead can be supported on XFree86. This section describes what's possible, and where more work is needed. 
+
+Many of the challenges with supporting basic multiple adapter multihead reside in getting basic 2D initialization for *all* heads. Some XFree86 drivers work better than others in this area. The focus from a DRI perspective, is to make sure 3D works if 2D does. This has not been done for many of the DRI drivers, but is something that can be addressed at the driver level. When attempting to support basic multihead functionality within a driver, there are multiple levels of increasing complexity that should be addressed: 
+
+   * 2D working on all heads, 3D on none 
+   * 2D working on all heads, 3D working on a single head 
+   * 2D working on all heads, 3D working on all heads 
+For many configurations, the biggest development challenge for the last step may be getting AGPGART support going with multiple heads. It's possible to defer this by working with drivers that don't require this support (PCI-only). 
+
+
+## See also
+
+* Xinerama 
+* MergedFB 
+
+
+---
+
+ [[CategoryHelpWanted|CategoryHelpWanted]] 
diff --git a/NDA.mdwn b/NDA.mdwn
new file mode 100644
index 0000000..fc4ae96
--- /dev/null
+++ b/NDA.mdwn
@@ -0,0 +1,66 @@
+
+
+## Access to NDA documentation
+
+**Contents** [[!toc ]] 
+
+
+### What does NDA stands for?
+
+NDA stands for Non Disclosure Agreement. This means, when you agree to an NDA, you are agreeing to not disclose the information you are receiving, to parties other than whom are listed in the agreement you are signing or agreeing to. 
+
+
+### Doesn't XFree86.org have NDA documentation?
+
+XFree86.org had documentation for some pieces of video hardware that was obtained under NDA.  They were not able to distribute that documentation to other people freely, only to others who had signed a blanket NDA with XFree86.org. That NDA was the primary feature of the XFree86.org member program. 
+
+XFree86.org has since ended its member program and the documentation they previously offered is no longer available. 
+
+
+### What are the steps that one should take to get NDA documentation?
+
+Please read Frank La``Monica's doc, [[Managing Graphics Hardware Vendor Relationships in the Linux Developer Community|http://dri.sourceforge.net/doc/vendor_relationships_paper.html]] 
+
+
+### What're the reasons behind NDA?
+
+I'd just like to comment a bit about the mechanisms involved here, at least as I myself see them. It is not limited to any particular vendor nor to any particular individual seeking information. Also, my comments are solely my own, and do not in any way reflect any opinions of my employer, or of any hardware vendors, etc. 
+
+In a perfect world, all vendors would just allow access to their documentation outright and freely. However, we aren't in that utopia yet, and they do indeed control access to their documentation, whether or not individuals like that or not. So, to get to that documentation, we very much need to play by their rules. Again, I speak of no particular company here, or individuals. 
+
+If they want to restrict access to information, then IMHO, there needs to be some mechanism in place to determine who gets documentation, and who does not get it. If it were as simple as: Joe Blow signs up, is automatically accepted without any question, clicks on NDA agreement, and then gets the docs, they might as well just publish the docs on their website freely for anyone to download anyways, as they wouldn't be restricting information at all. 
+
+Who should they give their docs to? Do they want just anyone having the docs? Or do they want competent developers that are most likely to really use the information to produce real results? 
+
+What metric gauges the decision? Does Joe programmer have a CS degree in 3D work, thus more likely to successfully use the information to complete some open source work? Is he a video game programmer? What has he done? Or is he just someone who is wanting to help, and is good intentioned, but might not actually have the skills and/or time to truly contribute? How do they know? For all they know, someone could say they are working on fixing a bug in XFree86, however actually they are working for a competitor for example. Who knows what the logic behind it all, or cares. Either way, some metric is needed to decide how to divulge information. 
+
+If the purpose of using an NDA is to restrict access to information, yet let capable individuals access that information to yield working results, and thus improve support for and promote a hardware vendor's product well, there needs to be some metric with which to gauge someone, and whether they are truly capable, or whether they are just "good intentioned". 
+
+If someone is working for a graphics company for example, is affiliated with some past work such as DRI, XFree86, perhaps has their name in the kernel credits for graphics work, or has some credential showing their capabilities, then it would stand to reason the chances are much higher that they could use the information and produce results. Probability-wise that is. 
+
+If someone is not working for a company who does graphics, or is writing video drivers, or affiliated with XFree86 and/or DRI, or some other similar thing, they could (not would, just could) potentially be a higher risk of information leakage IMHO. It stands to reason then, that a company may want to see some credentials before allowing access to information. By having people become XFree86 members first, I think it is a very good metric to see who is serious on working on code. XFree86 does not have difficult membership requirements, and any programmer who is capable of taking register level documentation from a hardware manufacturer, and producing useful results from it, is also very capable of quickly becoming an XFree86 member. 
+
+To do so, one need only fix a bug in XFree86, or perhaps add a feature, even something small. It is a small measure of one's capabilities to do the job. Once someone has passed the test of writing some small patch, that fixes something in X, they have shown some level of troubleshooting skill, some level of proficiency, and are much more likely to also continue to contribute to the project in the future. By passing that test, one can elect to join XFree86 as a member, which involves reading a web page, firing off an email, and then bouncing a few emails, agreeing to the XFree86 NDA. 
+
+Once one is an XFree86 member, they open up a lot of doors, including access to information that XFree86 has under NDA, and other private stuff. One can then come to a hardware vendor, asking for technical specifications under NDA with something more than "I know how to program C, and have good intentions", they can say, "I am an XFree86 member wanting to add support for foo, and/or fix bar in driver baz on your fooblaster card." I don't know of any XFree86 developer who has been refused information by vendors who support open source after having adequately went through the right channels, and proved that they are truly serious about the work they'd like to do, by passing a few litmus tests. 
+
+In all honesty, I think if someone thinks fixing a bug in XFree86 and becoming a member is too much of a hassle, then they are most likely not going to come through on any serious code at all anyways, and are thus more likely to be a information leak to a particular hardware vendor than an asset. 
+
+People certainly don't need to jump into the lake completely, it makes at least some sense to me that they should commit to dipping their leg in up to their knee, rather than just putting their toe in, and wanting full scuba gear. Scuba equipment given to them, may end up sitting on a shelf, rather than being used for whatever it is scuba divers use their equipment for. 
+
+OK.. that was an oddball analogy, but it does the job. ;) 
+
+My above thoughts on the logic involved behind these processes, may be way off mark, but that is what I've come up with, while watching the processes at work, and trying to look at the situation from the various different sides involved. 
+
+I guess it could be stated more like this: 
+
+   * You can get much further with a smile and a few bugfixes accepted into the code base, than you can get with a smile alone. 
+You can quote me on that. ;) 
+
+-- [[MikeHarris|MikeHarris]] 
+
+
+
+---
+
+ [[CategoryFaq|CategoryFaq]] 
diff --git a/NDA.moin b/NDA.moin
deleted file mode 100644
index b5cf58d..0000000
--- a/NDA.moin
+++ /dev/null
@@ -1,130 +0,0 @@
-== Access to NDA documentation ==
-
-'''Contents'''
-<<TableOfContents>>
-
-=== What does NDA stands for? ===
-
-NDA stands for Non Disclosure Agreement. This means, when you agree to an NDA,
-you are agreeing to not disclose the information you are receiving, to parties
-other than whom are listed in the agreement you are signing or agreeing to.
-
-=== Doesn't XFree86.org have NDA documentation? ===
-
-XFree86.org had documentation for some pieces of video hardware that was
-obtained under NDA.  They were not able to distribute that documentation to
-other people freely, only to others who had signed a blanket NDA with XFree86.org.
-That NDA was the primary feature of the XFree86.org member program.
-
-XFree86.org has since ended its member program and the documentation they
-previously offered is no longer available.
-
-=== What are the steps that one should take to get NDA documentation? ===
-
-Please read Frank La``Monica's doc, [[http://dri.sourceforge.net/doc/vendor_relationships_paper.html|Managing Graphics Hardware Vendor Relationships in the Linux Developer Community]]
-
-=== What're the reasons behind NDA? ===
-
-I'd just like to comment a bit about the mechanisms involved here, at least as
-I myself see them. It is not limited to any particular vendor nor to any
-particular individual seeking information. Also, my comments are solely my own,
-and do not in any way reflect any opinions of my employer, or of any hardware
-vendors, etc.
-
-In a perfect world, all vendors would just allow access to their documentation
-outright and freely. However, we aren't in that utopia yet, and they do indeed
-control access to their documentation, whether or not individuals like that or
-not. So, to get to that documentation, we very much need to play by their
-rules. Again, I speak of no particular company here, or individuals.
-
-If they want to restrict access to information, then IMHO, there needs to be
-some mechanism in place to determine who gets documentation, and who does not
-get it. If it were as simple as: Joe Blow signs up, is automatically accepted
-without any question, clicks on NDA agreement, and then gets the docs, they
-might as well just publish the docs on their website freely for anyone to
-download anyways, as they wouldn't be restricting information at all.
-
-Who should they give their docs to? Do they want just anyone having the docs?
-Or do they want competent developers that are most likely to really use the
-information to produce real results?
-
-What metric gauges the decision? Does Joe programmer have a CS degree in 3D
-work, thus more likely to successfully use the information to complete some
-open source work? Is he a video game programmer? What has he done? Or is he
-just someone who is wanting to help, and is good intentioned, but might not
-actually have the skills and/or time to truly contribute? How do they know? For
-all they know, someone could say they are working on fixing a bug in XFree86,
-however actually they are working for a competitor for example. Who knows what
-the logic behind it all, or cares. Either way, some metric is needed to decide
-how to divulge information.
-
-If the purpose of using an NDA is to restrict access to information, yet let
-capable individuals access that information to yield working results, and thus
-improve support for and promote a hardware vendor's product well, there needs
-to be some metric with which to gauge someone, and whether they are truly
-capable, or whether they are just "good intentioned".
-
-If someone is working for a graphics company for example, is affiliated with
-some past work such as DRI, XFree86, perhaps has their name in the kernel
-credits for graphics work, or has some credential showing their capabilities,
-then it would stand to reason the chances are much higher that they could use
-the information and produce results. Probability-wise that is.
-
-If someone is not working for a company who does graphics, or is writing
-video drivers, or affiliated with XFree86 and/or DRI, or some other similar
-thing, they could (not would, just could) potentially be a higher risk of
-information leakage IMHO. It stands to reason then, that a company may want
-to see some credentials before allowing access to information. By having
-people become XFree86 members first, I think it is a very good metric to see
-who is serious on working on code. XFree86 does not have difficult membership
-requirements, and any programmer who is capable of taking register level
-documentation from a hardware manufacturer, and producing useful results from
-it, is also very capable of quickly becoming an XFree86 member.
-
-To do so, one need only fix a bug in XFree86, or perhaps add a feature, even
-something small. It is a small measure of one's capabilities to do the job.
-Once someone has passed the test of writing some small patch, that fixes
-something in X, they have shown some level of troubleshooting skill, some level
-of proficiency, and are much more likely to also continue to contribute to the
-project in the future. By passing that test, one can elect to join XFree86 as a
-member, which involves reading a web page, firing off an email, and then
-bouncing a few emails, agreeing to the XFree86 NDA.
-
-Once one is an XFree86 member, they open up a lot of doors, including access to
-information that XFree86 has under NDA, and other private stuff. One can then
-come to a hardware vendor, asking for technical specifications under NDA with
-something more than "I know how to program C, and have good intentions", they
-can say, "I am an XFree86 member wanting to add support for foo, and/or fix bar
-in driver baz on your fooblaster card." I don't know of any XFree86 developer
-who has been refused information by vendors who support open source after
-having adequately went through the right channels, and proved that they are
-truly serious about the work they'd like to do, by passing a few litmus tests.
-
-In all honesty, I think if someone thinks fixing a bug in XFree86 and becoming
-a member is too much of a hassle, then they are most likely not going to come
-through on any serious code at all anyways, and are thus more likely to be a
-information leak to a particular hardware vendor than an asset.
-
-People certainly don't need to jump into the lake completely, it makes at least
-some sense to me that they should commit to dipping their leg in up to their
-knee, rather than just putting their toe in, and wanting full scuba gear. Scuba
-equipment given to them, may end up sitting on a shelf, rather than being used
-for whatever it is scuba divers use their equipment for.
-
-OK.. that was an oddball analogy, but it does the job. ;)
-
-My above thoughts on the logic involved behind these processes, may be way off
-mark, but that is what I've come up with, while watching the processes at work,
-and trying to look at the situation from the various different sides involved.
-
-I guess it could be stated more like this:
-
-  You can get much further with a smile and a few bugfixes accepted into the
-  code base, than you can get with a smile alone.
-
-You can quote me on that. ;)
-
--- MikeHarris
-
-----
-CategoryFaq
diff --git a/NV1.moin b/NV1.mdwn
index b5849b8..1e858d9 100644
--- a/NV1.moin
+++ b/NV1.mdwn
@@ -1,20 +1,28 @@
-= NV1 =
-
-nVidia's first attempt at a 3D accelerator.  Reportedly an extremely weird design, not at all triangle-based.  Legend has it that its design was fundamentally incompatible with DirectX, forcing a redesign that later became the nv3 Riva chip.  Inspection of the 2D register headers from the nv1 and nv3 drivers in XFree86 3.x shows some design similarities though.
-
-These do still pop up on eBay from time to time.  It may be possible to support them in the DRI, but they might not be capable of GL in the usual sense.
-
-== Status ==
-
-A 2D driver was available in XFree86 3.3, but was never ported forward to 4.0.
-
-Some 3D support was available in Windows, but it's not clear if that was an early form of DirectX, or GL, or what.
-
-== Specifications ==
-
-Yeah, right.
-
-== Resources ==
-
-----
-CategoryHardwareChipset
+
+
+# NV1
+
+nVidia's first attempt at a 3D accelerator.  Reportedly an extremely weird design, not at all triangle-based.  Legend has it that its design was fundamentally incompatible with DirectX, forcing a redesign that later became the nv3 Riva chip.  Inspection of the 2D register headers from the nv1 and nv3 drivers in XFree86 3.x shows some design similarities though. 
+
+These do still pop up on eBay from time to time.  It may be possible to support them in the DRI, but they might not be capable of GL in the usual sense. 
+
+
+## Status
+
+A 2D driver was available in XFree86 3.3, but was never ported forward to 4.0. 
+
+Some 3D support was available in Windows, but it's not clear if that was an early form of DirectX, or GL, or what. 
+
+
+## Specifications
+
+Yeah, right. 
+
+
+## Resources
+
+
+
+---
+
+ [[CategoryHardwareChipset|CategoryHardwareChipset]] 
diff --git a/NVIDIA.moin b/NVIDIA.mdwn
index 861b0f3..af2c926 100644
--- a/NVIDIA.moin
+++ b/NVIDIA.mdwn
@@ -1,33 +1,42 @@
-= NVIDIA =
-
-== Status ==
-
-2D support for the nv3 and up (everything from the Riva to now, basically) is available in Xorg in the `nv` driver.
-
-Currently NVIDIA 3D DRI development is being done in the [[http://nouveau.freedesktop.org/wiki/|Nouveau]] project, which is rewriting the DDX driver (`nv` is provided by NVIDIA and is obfuscated, new `nouveau` will replace it), co-operating with other teams to improve DRM architecture to support NVIDIA cards and writing 3D/DRI support on top of those.
-
-=== History ===
-
-nVidia provides their own closed-source binary drivers, which are not based on the DRI.  DRI developers can not help you with issues with the closed drivers. A DRM module for nVidia hardware was developed as part of the EXA work for that chip.  This is currently available in DRM CVS, but not in any mainline kernel.  Full DRI support would require adding DRI awareness to the 2D driver, and porting the 3D driver from UtahGLX.
-
-No support exists for the original nv1 chip anymore.  For details, see [[NV1]].
-
-== Specifications ==
-
-Hardware specs are not available. Some reverse engineering has been done and can be found at RivaTV
-[[http://rivatv.sourceforge.net/stuff/riva128.txt|Riva128]]. More reverse engineering in Nouveau.
-
-The hardware appears to be slightly more complex than your typical queue-up-the-vertices-and-fire card.  There seems to be extensive state tracking in the hardware itself, which is probably used to optimize performance when multiple GL contexts are active.
-
-== nVidia nForce AGPGART driver ==
-
-See http://www.codemonkey.org.uk/projects/agp/nvidia.shtml .
-
-== Resources ==
-
-UtahGLX also has an old, basic support for nVidia Riva / TNT / GeForce for XFree86 3.3 and 4.0.  Someone could port this to DRI.
-
-[[http://nouveau.freedesktop.org/wiki/|Nouveau]] project aims at producing Open Source 3D drivers for NVIDIA cards.
-
-----
-CategoryHardwareVendor CategoryHelpWanted
+
+
+# NVIDIA
+
+
+## Status
+
+2D support for the nv3 and up (everything from the Riva to now, basically) is available in Xorg in the `nv` driver. 
+
+Currently NVIDIA 3D DRI development is being done in the [[Nouveau|http://nouveau.freedesktop.org/wiki/]] project, which is rewriting the DDX driver (`nv` is provided by NVIDIA and is obfuscated, new `nouveau` will replace it), co-operating with other teams to improve DRM architecture to support NVIDIA cards and writing 3D/DRI support on top of those. 
+
+
+### History
+
+nVidia provides their own closed-source binary drivers, which are not based on the DRI.  DRI developers can not help you with issues with the closed drivers. A DRM module for nVidia hardware was developed as part of the EXA work for that chip.  This is currently available in DRM CVS, but not in any mainline kernel.  Full DRI support would require adding DRI awareness to the 2D driver, and porting the 3D driver from UtahGLX. 
+
+No support exists for the original nv1 chip anymore.  For details, see [[NV1|NV1]]. 
+
+
+## Specifications
+
+Hardware specs are not available. Some reverse engineering has been done and can be found at RivaTV [[Riva128|http://rivatv.sourceforge.net/stuff/riva128.txt]]. More reverse engineering in Nouveau. 
+
+The hardware appears to be slightly more complex than your typical queue-up-the-vertices-and-fire card.  There seems to be extensive state tracking in the hardware itself, which is probably used to optimize performance when multiple GL contexts are active. 
+
+
+## nVidia nForce AGPGART driver
+
+See [[http://www.codemonkey.org.uk/projects/agp/nvidia.shtml|http://www.codemonkey.org.uk/projects/agp/nvidia.shtml]] . 
+
+
+## Resources
+
+UtahGLX also has an old, basic support for nVidia Riva / TNT / [[GeForce|GeForce]] for XFree86 3.3 and 4.0.  Someone could port this to DRI. 
+
+[[Nouveau|http://nouveau.freedesktop.org/wiki/]] project aims at producing Open Source 3D drivers for NVIDIA cards. 
+
+
+
+---
+
+ [[CategoryHardwareVendor|CategoryHardwareVendor]] [[CategoryHelpWanted|CategoryHelpWanted]] 
diff --git a/NVIDIAGeForce.mdwn b/NVIDIAGeForce.mdwn
new file mode 100644
index 0000000..f8677ac
--- /dev/null
+++ b/NVIDIAGeForce.mdwn
@@ -0,0 +1,6 @@
+
+
+
+---
+
+ [[CategoryHardwareChipset|CategoryHardwareChipset]] 
diff --git a/NVIDIAGeForce.moin b/NVIDIAGeForce.moin
deleted file mode 100644
index 7b0d45b..0000000
--- a/NVIDIAGeForce.moin
+++ /dev/null
@@ -1,4 +0,0 @@
-#REDIRECT NVIDIA
-
-----
-CategoryHardwareChipset
diff --git a/NeverWinterNights.mdwn b/NeverWinterNights.mdwn
new file mode 100644
index 0000000..31824f3
--- /dev/null
+++ b/NeverWinterNights.mdwn
@@ -0,0 +1,31 @@
+
+
+# Neverwinter Nights (NWN)
+
+
+## Well known 'error' message
+
+**Problem**: 
+
+   * I was still having a problem running Neverwinter Nights: when I ran the program I would simply get the useless 'Error' message, which should be well known to those in the NWN Linux community.  Why? 
+**Solution** 
+
+   * NWN did not work because it requests (since the beta4 client or so) a  32bit buffer size (though for no good reason, since it doesn't request  an alpha size, so 24bit would be enough, which would avoid all the  trouble...). However, up until very recently (last week in the cvs) the  X Server wrongly reported all true-color visuals with the root-depth  (which is only 24bit). This change is somewhere in the server side glx  code, and ends up afaik in libglx.a (btw if the snapshots don't contain  libglx.a then that will probably continue to be a problem - never tried  the snapshots myself, always using CVS). (You can easily check if you  have the fixed version with glxinfo - the "bf sz" is the value in  question.) The reason it works with older XFree86 versions is in old releases the client side code (I believe this all ends up in libGL.so?) (also errornously) simply ignores minimal buffer sizes asked by an application - thus the app could ask for a minimum buffer size of 32bit and just get back a 24bit buffer instead if no buffers with 32bit were available.  This was fixed some month ago and the client now gets back the error it should receive, which broke NWN. So, if you happen to have a libGL version with the glx visual matching code changes but not an X server which reports the buffer size correctly you have a problem. If this is still a problem today with the snapshots, then probably libglx.a (at least I think that's the correct file) is not included in the snapshots. -- [[RolandScheidegger|RolandScheidegger]] on dri-users. 
+
+## Bad lightening
+
+(maybe this is not the correct place for such a hint, but as there already was a NeverWinterNights section...) 
+
+**Problem:** 
+
+Some part of the scene is not lightened correctly (it is flickering).  
+
+**Solution:** 
+
+Seems that this is a problem with TCL. Just set R200_NO_TCL=1 (or use the [[ConfigurationOptions|ConfigurationOptions]] to disable TCL in newer version)  then it should work fine (but with no TCL of course). This problem is fixed in current CVS and snapshots, so disabling TCL should no longer be necessary. 
+
+See this  [[NeverWinter Nights for linux FAQ|http://pgshopping.com/mdkxp/en/artcls/nwnfaq.php#path]] 
+
+---
+
+ [[CategoryTroubleshooting|CategoryTroubleshooting]] 
diff --git a/NeverWinterNights.moin b/NeverWinterNights.moin
deleted file mode 100644
index 99e4ab5..0000000
--- a/NeverWinterNights.moin
+++ /dev/null
@@ -1,57 +0,0 @@
-= Neverwinter Nights (NWN) =
-
-== Well known 'error' message ==
-
-'''Problem''':
-
-  I was still having a problem running Neverwinter Nights: when I ran the
-  program I would simply get the useless 'Error' message, which should be well
-  known to those in the NWN Linux community.  Why?
-
-'''Solution'''
-
-
-  NWN did not work because it requests (since the beta4 client or so) a 
-  32bit buffer size (though for no good reason, since it doesn't request 
-  an alpha size, so 24bit would be enough, which would avoid all the 
-  trouble...). However, up until very recently (last week in the cvs) the 
-  X Server wrongly reported all true-color visuals with the root-depth 
-  (which is only 24bit). This change is somewhere in the server side glx 
-  code, and ends up afaik in libglx.a (btw if the snapshots don't contain 
-  libglx.a then that will probably continue to be a problem - never tried 
-  the snapshots myself, always using CVS). (You can easily check if you 
-  have the fixed version with glxinfo - the "bf sz" is the value in 
-  question.)
-
-  The reason it works with older XFree86 versions is in old releases the client
-  side code (I believe this all ends up in libGL.so?) (also errornously) simply
-  ignores minimal buffer sizes asked by an application - thus the app could ask
-  for a minimum buffer size of 32bit and just get back a 24bit buffer instead
-  if no buffers with 32bit were available.  This was fixed some month ago and
-  the client now gets back the error it should receive, which broke NWN.
-
-  So, if you happen to have a libGL version with the glx visual matching code
-  changes but not an X server which reports the buffer size correctly you have
-  a problem. If this is still a problem today with the snapshots, then probably
-  libglx.a (at least I think that's the correct file) is not included in the
-  snapshots.
-
-  -- RolandScheidegger on dri-users.
-
-
-== Bad lightening ==
-(maybe this is not the correct place for such a hint, but as there already was a NeverWinterNights section...)
-
-'''Problem:'''
-
-Some part of the scene is not lightened correctly (it is flickering). 
-
-'''Solution:'''
-
-Seems that this is a problem with TCL.
-Just set R200_NO_TCL=1 (or use the ConfigurationOptions to disable TCL in newer version)  then it should work fine (but with no TCL of course).
-This problem is fixed in current CVS and snapshots, so disabling TCL should no longer be necessary.
-
-See this  [[http://pgshopping.com/mdkxp/en/artcls/nwnfaq.php#path|NeverWinter Nights for linux FAQ]]
-----
-CategoryTroubleshooting
diff --git a/NewDeveloperAccount.moin b/NewDeveloperAccount.mdwn
index fb22e4e..c5fef84 100644
--- a/NewDeveloperAccount.moin
+++ b/NewDeveloperAccount.mdwn
@@ -1,12 +1,15 @@
-=== Instructions for new developers ===
-Developers can get write access to the CVS repository after having contributed patches to the DRI and being proposed by another committer.  Write access to the CVS repository is provided by having an account at freedesktop.org.  This is managed by the fd.o 'sitewranglers'.
-
-To get a new account, follow the procedure at [[http://www.freedesktop.org/wiki/AccountRequests|AccountRequests @ fd.o]].
-
-Your ssh public key should be dsa if possible, though people with existing rsa keys have been allowed to use them.  If you don't have an ssh key yet, use "ssh-keygen -t dsa".  You should use a passphrase to keep your key safe.  If you don't like typing in your passphrase every time you access freedesktop.org, check out ssh-agent and ssh-add.
-
-Access to the repository is explained on the CVS wiki page.  If you use cvsup to maintain a local mirror, you can commit from a local checkout by explicitly specifying the freedesktop.org cvs root in your "cvs commit" command (i.e. env CVS_RSH=ssh cvs -d:ext:username@dri.freedesktop.org:/cvs/dri commit).
-
-Should you experience troubles committing and feel things should be fixed in the repository, send an email to dri-devel@lists.sourceforge.net to get it resolved, rather than jumping in to fix it on freedesktop.org yourself.
-
-Remember to add the user's WikiName to the CurrentDevelopers page.
+
+
+### Instructions for new developers
+
+Developers can get write access to the CVS repository after having contributed patches to the DRI and being proposed by another committer.  Write access to the CVS repository is provided by having an account at freedesktop.org.  This is managed by the fd.o 'sitewranglers'. 
+
+To get a new account, follow the procedure at [[AccountRequests @ fd.o|http://www.freedesktop.org/wiki/AccountRequests]]. 
+
+Your ssh public key should be dsa if possible, though people with existing rsa keys have been allowed to use them.  If you don't have an ssh key yet, use "ssh-keygen -t dsa".  You should use a passphrase to keep your key safe.  If you don't like typing in your passphrase every time you access freedesktop.org, check out ssh-agent and ssh-add. 
+
+Access to the repository is explained on the CVS wiki page.  If you use cvsup to maintain a local mirror, you can commit from a local checkout by explicitly specifying the freedesktop.org cvs root in your "cvs commit" command (i.e. env CVS_RSH=ssh cvs -d:ext:[[username@dri.freedesktop.org|mailto:username@dri.freedesktop.org]]:/cvs/dri commit). 
+
+Should you experience troubles committing and feel things should be fixed in the repository, send an email to [[dri-devel@lists.sourceforge.net|mailto:dri-devel@lists.sourceforge.net]] to get it resolved, rather than jumping in to fix it on freedesktop.org yourself. 
+
+Remember to add the user's [[WikiName|WikiName]] to the [[CurrentDevelopers|CurrentDevelopers]] page. 
diff --git a/NextDRMVersion.mdwn b/NextDRMVersion.mdwn
new file mode 100644
index 0000000..f7d98a8
--- /dev/null
+++ b/NextDRMVersion.mdwn
@@ -0,0 +1,12 @@
+
+This is a page to put ideas about future changes to the DRM should a major version number bump occur.  I've put some things I've come across while doing FreeBSD DRM work. 
+
+* We should attach a DRM to a specific card, and not use the getunique/setunique mess that's currently used to attach DRMs to cards.  This is mostly doable for the single-DRI-head case while retaining backwards compatibility. (in progress --[[EricAnholt|EricAnholt]]) 
+* DRM_IOCTL_IRQ_BUSID gets an irq for a pci device based on a busid.  This was useful when it was a generic DRM module function, and could service several different devices.  It should probably be changed to something that only returns the irq number of the device that that drm_device_t is attached to.  It might not be necessary at all and could be part of DRM_IOCTL_CONTROL. (in progress --[[EricAnholt|EricAnholt]]) 
+* Actually, why not have DRM_IOCTL_CONTROL's contents just be moved into device setup/teardown (first open/last close)?  Is there any situation where ioctls would be enabled at a significantly different time than setup/teardown of the dri in the server?  Well, since the irq handlers require the device private to be initialized, it can't be moved easily (without changing how devices get initialized). 
+* We should convert the gamma driver to a similar DMA infrastructure as the other devices if possible, greatly simplifying much of the general DRM code.  FreeBSD has axed much of the gamma DMA infrastructure from its DRM, but some parts can't be removed (such as SIGIO handler management) because the X Server still expects it. 
+Miscellaneous cleanups: 
+
+* Card drivers should use family information based on the pci device id in the kernel rather than taking in information from userland.  Quirks for hardware may require pci device id checks anyway. 
+* It should work. 
+There is a proposed new interface design up at DRMRedesign. 
diff --git a/NextDRMVersion.moin b/NextDRMVersion.moin
deleted file mode 100644
index 21d3c69..0000000
--- a/NextDRMVersion.moin
+++ /dev/null
@@ -1,14 +0,0 @@
-This is a page to put ideas about future changes to the DRM should a major
-version number bump occur.  I've put some things I've come across while doing
-FreeBSD DRM work.
-
- * We should attach a DRM to a specific card, and not use the getunique/setunique mess that's currently used to attach DRMs to cards.  This is mostly doable for the single-DRI-head case while retaining backwards compatibility. (in progress --EricAnholt)
- * DRM_IOCTL_IRQ_BUSID gets an irq for a pci device based on a busid.  This was useful when it was a generic DRM module function, and could service several different devices.  It should probably be changed to something that only returns the irq number of the device that that drm_device_t is attached to.  It might not be necessary at all and could be part of DRM_IOCTL_CONTROL. (in progress --EricAnholt)
- * Actually, why not have DRM_IOCTL_CONTROL's contents just be moved into device setup/teardown (first open/last close)?  Is there any situation where ioctls would be enabled at a significantly different time than setup/teardown of the dri in the server?  Well, since the irq handlers require the device private to be initialized, it can't be moved easily (without changing how devices get initialized).
- * We should convert the gamma driver to a similar DMA infrastructure as the other devices if possible, greatly simplifying much of the general DRM code.  FreeBSD has axed much of the gamma DMA infrastructure from its DRM, but some parts can't be removed (such as SIGIO handler management) because the X Server still expects it.
-
-Miscellaneous cleanups:
- * Card drivers should use family information based on the pci device id in the kernel rather than taking in information from userland.  Quirks for hardware may require pci device id checks anyway.
- * It should work.
-
-There is a proposed new interface design up at DRMRedesign.
diff --git a/No2048Limit.mdwn b/No2048Limit.mdwn
new file mode 100644
index 0000000..dcfcd5e
--- /dev/null
+++ b/No2048Limit.mdwn
@@ -0,0 +1,9 @@
+
+
+## No2048Limit
+
+Device option in DRI CVS as of 10/24/2003 which allows you to bypass the builtin DRI screen limit of 2048x2048 pixels. 
+
+A more in-depth discussion of this can be found here: 
+
+[[http://bugs.xfree86.org/show_bug.cgi?id=276#c99|http://bugs.xfree86.org/show_bug.cgi?id=276#c99]] 
diff --git a/No2048Limit.moin b/No2048Limit.moin
deleted file mode 100644
index 74221e3..0000000
--- a/No2048Limit.moin
+++ /dev/null
@@ -1,7 +0,0 @@
-== No2048Limit ==
-
-Device option in DRI CVS as of 10/24/2003 which allows you to bypass the builtin DRI screen limit of 2048x2048 pixels.
-
-A more in-depth discussion of this can be found here:
-
-http://bugs.xfree86.org/show_bug.cgi?id=276#c99
diff --git a/NoAccel.mdwn b/NoAccel.mdwn
new file mode 100644
index 0000000..d1383ca
--- /dev/null
+++ b/NoAccel.mdwn
@@ -0,0 +1,14 @@
+
+
+## NoAccel
+
+An option understood by most video drivers to disable 2D acceleration. Normally used for debugging or in problem situations. Enabled by specifying   Option "NoAccel" in the Driver section of the configuration file. 
+
+
+### Resources
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/NoAccel.moin b/NoAccel.moin
deleted file mode 100644
index 91b188f..0000000
--- a/NoAccel.moin
+++ /dev/null
@@ -1,9 +0,0 @@
-== NoAccel ==
-
-An option understood by most video drivers to disable 2D acceleration. Normally used for debugging or in problem situations. Enabled by
-specifying   Option "NoAccel" in the Driver section of the configuration file.
-
-=== Resources ===
-
-----
-CategoryGlossary
diff --git a/NormalUserBuild.moin b/NormalUserBuild.mdwn
index f7baf1e..9e8d399 100644
--- a/NormalUserBuild.moin
+++ b/NormalUserBuild.mdwn
@@ -1,134 +1,148 @@
-'''Contents'''
-<<TableOfContents>>
-
-== Building the DRI with Mesa as a normal user ==
-
-This is a basic guide to building DRI from source. It currently only focuses on building and testing the 3D drivers, but it will allow you to try out the latest drivers from CVS and your own modifications to them without having to modify your current X installation. It is an alternative to the procedure described on the Building page and as such refers to that page for some steps.
-
-The 3D drivers now live in the Mesa tree, so you will have to check out both the DRI CVS tree (for 2D driver and X bits) and the Mesa CVS tree (for 3D driver and GL stuff).  You should also get the DRM tree for the updated kernel modules.
-
-=== Howto ===
-==== Getting the CVS trees ====
-
-There are three trees to check out: the DRI tree, the DRM tree and the Mesa tree.
-
-Get the CVS trees using the `cvs` command.  There is no password for anonymous CVS so just hit enter when prompted.  You should run all of these commands from the same directory.  Once they've all run, you will have three new subdirectories: `xc`, `Mesa`, and `drm`.
-
-===== Getting DRI (optional) =====
-
-The source for libGL.so is in this tree. If you want to have debug symbols in libGL.so, you need this tree. If you are going to do some development on the 3D drivers and you plan on using the libGL.so of your current installation, you don't really need this tree. Steps for building libGL.so will be marked as optional throughout this document.
-
-{{{
-
-cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/dri login 
-
-cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/dri co xc 
-
-}}}
-
-===== Getting DRM =====
-
-This contains the kernel driver source.
-
-{{{
-
-cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/dri login
-
-cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/dri co drm
-
-}}}
-
-===== Getting Mesa =====
-
-The mesa tree is where the sources of the 3D drivers live. This is the place where most developers will do their work. As the Building page explains, you can also build the drivers from the DRI tree, but that is not the preferred way for developers. The rest of this page will assume you do your development in the Mesa tree.
-
-{{{
-
-cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/mesa login 
-
-cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/mesa co Mesa
-
-}}}
-
-==== Editing configurations ====
-
-===== xc/xc/config/cf/host.def (optional) =====
-
-Search for the definitions of XF86CardDrivers and DriDrivers for your architecture and remove any driver names from both of these definitions. For i386 it should look like this:
-
-{{{
-#elif defined(i386Architecture)
-
-#define XF86CardDrivers
-#define DriDrivers
-}}}
-
-This will exclude the drivers from the build in the DRI tree and save you some time, because you are going to build the drivers in the Mesa tree anyway.
-
-===== Mesa/configs/default =====
-
-If necessary, edit the following line to point to the DRM tree you downloaded. If the Mesa tree and the DRM tree are both in the same directory, the default value for DRM_SOURCE_PATH will do. Note that if you for example were in the directory `/foo/drm` when you downloaded DRM, the DRM source tree would be in `/foo/drm/drm`, since the cvs process creates a subfolder containing the source.
-
-{{{
-DRM_SOURCE_PATH=/path/to/drm
-}}}
-
-==== Compiling ====
-
-===== libGL.so (optional) =====
-
-Change to the xc/xc/ directory in the DRI tree and run:
-
-{{{
-make World >& world.log
-}}}
-
-===== drivers =====
-
-To build the drivers for the first time, change to the root of the Mesa tree and run:
-
-{{{
-make
-}}}
-
-This will show you all configurations you can build. For example, if you would like to build only the 3D drivers for linux, you could do:
-
-{{{
-make linux-dri
-}}}
-
-If you would like to build those drivers using x86 or x86-64 assembly where possible, use linux-dri-x86 or linux-dri-x86-64 respectively.
-After you have built a configuration once, it has become the default configuration. Future builds can be done by a simple `make`.
-
-
-
-
-==== Running ====
-
-There are a couple of things you need to set up in your environment.
-
-===== LD_LIBRARY_PATH (optional) =====
-If you want to use the libGL.so that you built in the DRI tree, you need to add the correct path to `LD_LIBRARY_PATH`:
-
-{{{
-export LD_LIBRARY_PATH=/path/to/xc/xc/exports/lib:$LD_LIBRARY_PATH
-}}}
-
-===== LIBGL_DRIVERS_DIR =====
-To have libGL.so look for the 3D driver in your development tree, you also have to set the `LIBGL_DRIVERS_DIR`:
-
-{{{
-export LIBGL_DRIVERS_DIR=/path/to/Mesa/lib
-}}}
-
-==== Building the DRM ====
-
-Please refer to the Building page for instructions on how to build the DRM kernel module.
-
-==== Finishing up ====
-
-The Building page has some additional instructions on finishing up.
-
-=== Troubleshooting ===
-
-Some build-time troubleshooting hints can also be found on the Building page. However, the issue that is mentioned with Gentoo's OpenGL package switch is not applicable for the approach on this page.
+
+**Contents** [[!toc ]] 
+
+
+## Building the DRI with Mesa as a normal user
+
+This is a basic guide to building DRI from source. It currently only focuses on building and testing the 3D drivers, but it will allow you to try out the latest drivers from CVS and your own modifications to them without having to modify your current X installation. It is an alternative to the procedure described on the Building page and as such refers to that page for some steps. 
+
+The 3D drivers now live in the Mesa tree, so you will have to check out both the DRI CVS tree (for 2D driver and X bits) and the Mesa CVS tree (for 3D driver and GL stuff).  You should also get the DRM tree for the updated kernel modules. 
+
+
+### Howto
+
+
+#### Getting the CVS trees
+
+There are three trees to check out: the DRI tree, the DRM tree and the Mesa tree. 
+
+Get the CVS trees using the `cvs` command.  There is no password for anonymous CVS so just hit enter when prompted.  You should run all of these commands from the same directory.  Once they've all run, you will have three new subdirectories: `xc`, `Mesa`, and `drm`. 
+
+
+##### Getting DRI (optional)
+
+The source for libGL.so is in this tree. If you want to have debug symbols in libGL.so, you need this tree. If you are going to do some development on the 3D drivers and you plan on using the libGL.so of your current installation, you don't really need this tree. Steps for building libGL.so will be marked as optional throughout this document. 
+
+
+[[!format txt """
+cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/dri login 
+
+cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/dri co xc 
+
+"""]]
+
+##### Getting DRM
+
+This contains the kernel driver source. 
+
+
+[[!format txt """
+cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/dri login
+
+cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/dri co drm
+
+"""]]
+
+##### Getting Mesa
+
+The mesa tree is where the sources of the 3D drivers live. This is the place where most developers will do their work. As the Building page explains, you can also build the drivers from the DRI tree, but that is not the preferred way for developers. The rest of this page will assume you do your development in the Mesa tree. 
+
+
+[[!format txt """
+cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/mesa login 
+
+cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/mesa co Mesa
+
+"""]]
+
+#### Editing configurations
+
+
+##### xc/xc/config/cf/host.def (optional)
+
+Search for the definitions of XF86CardDrivers and [[DriDrivers|DriDrivers]] for your architecture and remove any driver names from both of these definitions. For i386 it should look like this: 
+
+
+[[!format txt """
+#elif defined(i386Architecture)
+
+#define XF86CardDrivers
+#define DriDrivers
+"""]]
+This will exclude the drivers from the build in the DRI tree and save you some time, because you are going to build the drivers in the Mesa tree anyway. 
+
+
+##### Mesa/configs/default
+
+If necessary, edit the following line to point to the DRM tree you downloaded. If the Mesa tree and the DRM tree are both in the same directory, the default value for DRM_SOURCE_PATH will do. Note that if you for example were in the directory `/foo/drm` when you downloaded DRM, the DRM source tree would be in `/foo/drm/drm`, since the cvs process creates a subfolder containing the source. 
+
+
+[[!format txt """
+DRM_SOURCE_PATH=/path/to/drm
+"""]]
+
+#### Compiling
+
+
+##### libGL.so (optional)
+
+Change to the xc/xc/ directory in the DRI tree and run: 
+
+
+[[!format txt """
+make World >& world.log
+"""]]
+
+##### drivers
+
+To build the drivers for the first time, change to the root of the Mesa tree and run: 
+
+
+[[!format txt """
+make
+"""]]
+This will show you all configurations you can build. For example, if you would like to build only the 3D drivers for linux, you could do: 
+
+
+[[!format txt """
+make linux-dri
+"""]]
+If you would like to build those drivers using x86 or x86-64 assembly where possible, use linux-dri-x86 or linux-dri-x86-64 respectively. After you have built a configuration once, it has become the default configuration. Future builds can be done by a simple `make`. 
+
+
+#### Running
+
+There are a couple of things you need to set up in your environment. 
+
+
+##### LD_LIBRARY_PATH (optional)
+
+If you want to use the libGL.so that you built in the DRI tree, you need to add the correct path to `LD_LIBRARY_PATH`: 
+
+
+[[!format txt """
+export LD_LIBRARY_PATH=/path/to/xc/xc/exports/lib:$LD_LIBRARY_PATH
+"""]]
+
+##### LIBGL_DRIVERS_DIR
+
+To have libGL.so look for the 3D driver in your development tree, you also have to set the `LIBGL_DRIVERS_DIR`: 
+
+
+[[!format txt """
+export LIBGL_DRIVERS_DIR=/path/to/Mesa/lib
+"""]]
+
+#### Building the DRM
+
+Please refer to the Building page for instructions on how to build the DRM kernel module. 
+
+
+#### Finishing up
+
+The Building page has some additional instructions on finishing up. 
+
+
+### Troubleshooting
+
+Some build-time troubleshooting hints can also be found on the Building page. However, the issue that is mentioned with Gentoo's OpenGL package switch is not applicable for the approach on this page. 
diff --git a/NumberNine.moin b/NumberNine.mdwn
index ce43b9b..fa5d022 100644
--- a/NumberNine.moin
+++ b/NumberNine.mdwn
@@ -1,28 +1,33 @@
-= Number Nine =
-
-An early vendor of 3d graphics cards.  In addition to a number of S3-based boards, they also developed their own line of chips:
-
- * Imagine 128
- * Imagine 128 II
- * Ticket 2 Ride
- * Ticket 2 Ride IV
-
-There is also a rumor of a Ticket to Ride V card in some embedded military applications.
-
-The Ticket 2 Ride and above are basic single-TMU cards capable of OpenGL 1.2 and probably a few extensions.  They only have simple triangles in hardware, but there is a display list processor that can be fed via DMA.  The DMA engine only works over AGP, but there's a memory window engine that can operate over PCI with some double-buffering.  The hardware supports an impressive range of texture formats, including a few YUV formats if you abuse the memory window engine.
-
-I know much less about the Imagine cards, because I don't have the docs.  I suspect they can't texture.
-
-== Status ==
-
- * DRM driver in DRM CVS
- * initial work on DRI driver (not checked in or useful yet)
-
-See also the [[http://xorg.freedesktop.org/wiki/i128|i128 page on the Xorg wiki]].
-
-== Contact ==
-
-AdamJackson is the only one working on #9 support at the moment.
-
-----
-CategoryHardwareVendor
+
+
+# Number Nine
+
+An early vendor of 3d graphics cards.  In addition to a number of S3-based boards, they also developed their own line of chips: 
+
+* Imagine 128 
+* Imagine 128 II 
+* Ticket 2 Ride 
+* Ticket 2 Ride IV 
+There is also a rumor of a Ticket to Ride V card in some embedded military applications. 
+
+The Ticket 2 Ride and above are basic single-TMU cards capable of OpenGL 1.2 and probably a few extensions.  They only have simple triangles in hardware, but there is a display list processor that can be fed via DMA.  The DMA engine only works over AGP, but there's a memory window engine that can operate over PCI with some double-buffering.  The hardware supports an impressive range of texture formats, including a few YUV formats if you abuse the memory window engine. 
+
+I know much less about the Imagine cards, because I don't have the docs.  I suspect they can't texture. 
+
+
+## Status
+
+* DRM driver in DRM CVS 
+* initial work on DRI driver (not checked in or useful yet) 
+See also the [[i128 page on the Xorg wiki|http://xorg.freedesktop.org/wiki/i128]]. 
+
+
+## Contact
+
+[[AdamJackson|AdamJackson]] is the only one working on #9 support at the moment. 
+
+
+
+---
+
+ [[CategoryHardwareVendor|CategoryHardwareVendor]] 
diff --git a/OpenGL.mdwn b/OpenGL.mdwn
new file mode 100644
index 0000000..278915f
--- /dev/null
+++ b/OpenGL.mdwn
@@ -0,0 +1,18 @@
+
+
+## Open Graphics Library (OpenGL)
+
+SGI originally developed a graphics library called IrisGL for their high-end 3D hardware. They made some clever changes to make it work on any platform and renamed it OpenGL. Very recently SGI relaxed their restrictions for licensing and also released conformance tests for OpenGL. OpenGL abstracts 3D operations such as projections, lighting, rendering, texturing, matrix operations, etc, making it very easy for developers to produce high quality 3D applications. 
+
+
+### Resources
+
+   * [[OpenGL Forum|http://www.opengl.org/]] 
+   * [[OpenGL Specifications|http://www.opengl.org/documentation/spec.html]] 
+   * [[OpenGL Developer FAQ and TroubleShooting Guide|http://www.opengl.org/resources/faq/technical/index.html]] 
+   * [[OpenGL Programming Guide|http://www.opengl.org/resources/tutorials/]] 
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/OpenGL.moin b/OpenGL.moin
deleted file mode 100644
index 8b40872..0000000
--- a/OpenGL.moin
+++ /dev/null
@@ -1,21 +0,0 @@
-== Open Graphics Library (OpenGL) ==
-
-SGI originally developed a graphics library called IrisGL for their high-end
-3D hardware. They made some clever changes to make it work on any platform and
-renamed it OpenGL. Very recently SGI relaxed their restrictions for licensing
-and also released conformance tests for OpenGL. OpenGL abstracts 3D operations
-such as projections, lighting, rendering, texturing, matrix operations, etc,
-making it very easy for developers to produce high quality 3D applications.
-
-=== Resources ===
-
-  * [[http://www.opengl.org/|OpenGL Forum]]
-
-  * [[http://www.opengl.org/documentation/spec.html|OpenGL Specifications]]
-
-  * [[http://www.opengl.org/resources/faq/technical/index.html|OpenGL Developer FAQ and TroubleShooting Guide]]
-
-  * [[http://www.opengl.org/resources/tutorials/|OpenGL Programming Guide]]
-
-----
-CategoryGlossary
diff --git a/OpenGLFeatures.mdwn b/OpenGLFeatures.mdwn
new file mode 100644
index 0000000..c5975bd
--- /dev/null
+++ b/OpenGLFeatures.mdwn
@@ -0,0 +1,54 @@
+
+
+# Summary of DRI Driver Features
+
+* "YES" means that the feature is present in HW and supported by the driver. 
+* "no" means that the feature is not present in the HW or driver. 
+* "SW" means that the feature is not present in the HW, but is emulated by the driver anyway. 
+* "HW" means that the feature is theoretically supported by the HW, but nobody's written the support into the driver. Yet. 
+* "x" means "unknown." Nobody's bothered to fill in the blanks yet. 
+Todo: 
+
+* Nouveau guys, please add nVidia chipsets; I'm not familiar with your status. 
+* Add the r300 driver. [[!table header="no" class="mointable" data="""
+ Vendor  |  ATI |||| |  Intel ||| |  Matrox  |  3dfx || |  3DLabs  |  Sun  |  S3 ||| |  SiS || |  Trident  |  Via 
+ Chip  |  Mach64  |  Rage128  |  R100  |  R200  |  i810  |  i830  |  i915  |  G200/400/450/550  |  Voodoo3  |  Voodoo5  |  Gamma  |  FFB  |  Savage3D  |  Savage4  |  Virge  |  300/630/730  |  6326  |  Trident  |  Via 
+ Hardware Stencil<sup>1</sup>  |  no  |  YES  |  YES  |  YES  |  no  |  YES  |  YES  |  YES  |  no  |  YES  |  no  |  YES  |  YES  |  YES  |  x  |  x  |  x  |  no  |  x 
+ Hardware Alpha Channel<sup>1</sup>  |  no  |  no  |  YES  |  YES  |  no  |  YES  |  x  |  YES  |  no  |  YES  |  YES  |  YES  |  x  |  x  |  x  |  YES  |  x  |  no  |  x 
+ Hardware TCL  |  no  |  no  |  YES  |  YES  |  no  |  no  |  x  |  no  |  no  |  no  |  YES  |  no  |  no  |  no  |  no  |  no  |  no  |  no  |  x 
+ ARB_multitexture (units)  |  YES (2)  |  YES (2)  |  YES (2)  |  YES (2)  |  YES (2)  |  YES (2)  |  x  |  YES (G200:1, G400+:2)  |  YES (2)  |  YES (2)  |  no  |  no  |  no  |  YES (2)  |  no  |  no  |  no  |  no  |  x 
+ ARB/SGIS_texture_border_clamp  |  no  |  no  |  YES  |  YES  |  no  |  YES  |  x  |  no  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ ARB_texture_cube_map  |  no  |  no  |  no  |  YES  |  no  |  no  |  x  |  no  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ ARB/EXT_texture_env_add  |  no  |  YES  |  YES  |  YES  |  YES  |  YES  |  x  |  YES (G400+)  |  YES  |  YES  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ ARB/EXT_texture_env_dot3  |  no  |  no  |  YES  |  YES  |  no  |  YES  |  x  |  no  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ ARB/EXT_texture_env_combine  |  no  |  no  |  YES  |  YES  |  no  |  YES  |  x  |  no  |  no  |  YES  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ ARB_texture_mirrored_repeat  |  no  |  YES  |  YES  |  YES  |  YES  |  YES  |  x  |  no  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ ATI_texture_env_combine3  |  no  |  no  |  YES  |  YES  |  no  |  no  |  x  |  no  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ ATI_texture_mirror_once  |  no  |  no  |  YES  |  YES  |  no  |  no  |  x  |  no  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ EXT_blend_color  |  SW  |  SW  |  SW  |  YES  |  SW  |  YES  |  x  |  no  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ EXT_blend_func_separate  |  no  |  no  |  no  |  no  |  no  |  YES  |  x  |  no  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ EXT_blend_logic_op  |  no  |  no  |  YES  |  YES  |  no  |  no  |  x  |  no  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ EXT_blend_minmax  |  SW  |  SW  |  SW  |  YES  |  SW  |  YES  |  x  |  no  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ EXT_blend_subtract  |  SW  |  SW  |  YES  |  YES  |  SW  |  YES  |  x  |  no  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ EXT_fog_coord  |  no  |  no  |  no  |  no  |  no  |  YES  |  x  |  YES  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ EXT_paletted_texture  |  no  |  no  |  no  |  no  |  no  |  no  |  x  |  no  |  YES  |  YES  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ EXT_secondary_color  |  no  |  no  |  YES  |  YES  |  no  |  YES  |  x  |  YES  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ EXT_shared_texture_palette  |  no  |  no  |  no  |  no  |  no  |  no  |  x  |  no  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ EXT_stencil_wrap  |  no  |  no  |  no  |  YES  |  SW  |  YES  |  x  |  YES  |  no  |  YES  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ EXT/SGIS_texture_edge_clamp  |  YES  |  YES  |  YES  |  YES  |  YES  |  YES  |  x  |  YES (G400+)  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ EXT_texture_filter_anisotropic  |  no  |  no  |  YES  |  YES  |  no  |  YES  |  x  |  no  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ EXT_texture_lod_bias  |  no  |  no  |  YES  |  YES  |  YES  |  YES  |  x  |  no  |  YES  |  YES  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ MESA_pack_invert  |  no  |  no  |  no  |  YES  |  no  |  no  |  x  |  no  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ MESA_ycbcr_texture  |  YES  |  YES  |  YES  |  YES  |  YES  |  YES  |  x  |  YES  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ NV_blend_square  |  no  |  no  |  YES  |  YES  |  no  |  no  |  x  |  no  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ NV_texture_rectangle  |  no  |  no  |  YES  |  YES  |  YES  |  YES  |  x  |  no  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ SGIS_generate_mipmap  |  YES  |  YES  |  YES  |  YES  |  YES  |  YES  |  x  |  YES  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ GLX_MESA_swap_control  |  YES  |  YES  |  YES  |  YES  |  no  |  no  |  x  |  YES  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ GLX_MESA_swap_frame_usage  |  no  |  no  |  YES  |  YES  |  no  |  no  |  x  |  YES  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ GLX_NV_vertex_array_range  |  no  |  no  |  no  |  YES  |  no  |  no  |  x  |  no  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+ GLX_SGI_video_sync  |  YES  |  YES  |  YES  |  YES  |  no  |  no  |  x  |  YES  |  no  |  no  |  no  |  no  |  x  |  x  |  no  |  no  |  x  |  no  |  x 
+"""]]
+
+Notes: 
+
+1. Hardware stencilling and hardware alpha channels are usually only available with 32bpp contexts. 
+\ No newline at end of file
diff --git a/OpenGLFeatures.moin b/OpenGLFeatures.moin
deleted file mode 100644
index 88012b3..0000000
--- a/OpenGLFeatures.moin
+++ /dev/null
@@ -1,53 +0,0 @@
-## page was copied from FeatureMatrix
-= Summary of DRI Driver Features =
-
- * "YES" means that the feature is present in HW and supported by the driver.
- * "no" means that the feature is not present in the HW or driver.
- * "SW" means that the feature is not present in the HW, but is emulated by the driver anyway.
- * "HW" means that the feature is theoretically supported by the HW, but nobody's written the support into the driver. Yet.
- * "x" means "unknown." Nobody's bothered to fill in the blanks yet.
-
-Todo:
- * Nouveau guys, please add nVidia chipsets; I'm not familiar with your status.
- * Add the r300 driver.
-
-|| Vendor ||<-4> ATI ||<-3> Intel || Matrox ||<-2> 3dfx || 3DLabs || Sun ||<-3> S3 ||<-2> SiS || Trident || Via ||
-|| Chip || Mach64 || Rage128 || R100 || R200 || i810 || i830 || i915 || G200/400/450/550 || Voodoo3 || Voodoo5 || Gamma || FFB || Savage3D || Savage4 || Virge || 300/630/730 || 6326 || Trident || Via ||
-|| Hardware Stencil^1^ ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| Hardware Alpha Channel^1^ ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| Hardware TCL ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| ARB_multitexture (units) ||<style="background-color:lightgreen;"> YES (2) ||<style="background-color:lightgreen;"> YES (2) ||<style="background-color:lightgreen;"> YES (2) ||<style="background-color:lightgreen;"> YES (2) ||<style="background-color:lightgreen;"> YES (2) ||<style="background-color:lightgreen;"> YES (2) ||<style="background-color:lightgray;"> x ||<style="background-color:lightgreen;"> YES (G200:1, G400+:2) ||<style="background-color:lightgreen;"> YES (2) ||<style="background-color:lightgreen;"> YES (2) ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES (2) ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| ARB/SGIS_texture_border_clamp ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| ARB_texture_cube_map ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| ARB/EXT_texture_env_add ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:lightgreen;"> YES (G400+) ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| ARB/EXT_texture_env_dot3 ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| ARB/EXT_texture_env_combine ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| ARB_texture_mirrored_repeat ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| ATI_texture_env_combine3 ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| ATI_texture_mirror_once ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| EXT_blend_color ||<style="background-color:lightblue;"> SW ||<style="background-color:lightblue;"> SW ||<style="background-color:lightblue;"> SW ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightblue;"> SW ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| EXT_blend_func_separate ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| EXT_blend_logic_op ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| EXT_blend_minmax ||<style="background-color:lightblue;"> SW ||<style="background-color:lightblue;"> SW ||<style="background-color:lightblue;"> SW ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightblue;"> SW ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| EXT_blend_subtract ||<style="background-color:lightblue;"> SW ||<style="background-color:lightblue;"> SW ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightblue;"> SW ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| EXT_fog_coord ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| EXT_paletted_texture ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| EXT_secondary_color ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| EXT_shared_texture_palette ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| EXT_stencil_wrap ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightblue;"> SW ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| EXT/SGIS_texture_edge_clamp ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:lightgreen;"> YES (G400+) ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| EXT_texture_filter_anisotropic ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| EXT_texture_lod_bias ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| MESA_pack_invert ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| MESA_ycbcr_texture ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| NV_blend_square ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| NV_texture_rectangle ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| SGIS_generate_mipmap ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgray;"> x ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| GLX_MESA_swap_control ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| GLX_MESA_swap_frame_usage ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| GLX_NV_vertex_array_range ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-|| GLX_SGI_video_sync ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgreen;"> YES ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||<style="background-color:red;"> no ||<style="background-color:lightgray;"> x ||
-
-Notes:
-
- 1. Hardware stencilling and hardware alpha channels are usually only available with 32bpp contexts.
diff --git a/PCI.mdwn b/PCI.mdwn
new file mode 100644
index 0000000..7b1d89c
--- /dev/null
+++ b/PCI.mdwn
@@ -0,0 +1,11 @@
+
+
+## Peripheral Component Interconnect (PCI) bus
+
+[[ToDo|ToDo]] 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/PCI.moin b/PCI.moin
deleted file mode 100644
index f2ef2cf..0000000
--- a/PCI.moin
+++ /dev/null
@@ -1,6 +0,0 @@
-== Peripheral Component Interconnect (PCI) bus ==
-
-ToDo
-
-----
-CategoryGlossary
diff --git a/PIO.mdwn b/PIO.mdwn
new file mode 100644
index 0000000..54d7a95
--- /dev/null
+++ b/PIO.mdwn
@@ -0,0 +1,11 @@
+
+
+## Programmed Input/Output (PIO)
+
+Basically, PIO means that the processor is responsible to write a byte/word at a time to one I/O address at a time to communicate a block of data. Note that for x86, I/O space means something different than most other arch's as x86 has seperate I/O and memory spaces -- addressed by different instructions out/in vs store/load (okay, it's **mov** in x86 parlance, but if you know that, you already should know what I'm talking about). Think of PIO as writing to or reading from one end of a FIFO while the target reads/writes to the other end. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/PIO.moin b/PIO.moin
deleted file mode 100644
index 4561982..0000000
--- a/PIO.moin
+++ /dev/null
@@ -1,13 +0,0 @@
-== Programmed Input/Output (PIO) ==
-
-Basically, PIO means that the processor is
-responsible to write a byte/word at a time to one I/O address at a time to
-communicate a block of data. Note that for x86, I/O space means something
-different than most other arch's as x86 has seperate I/O and memory spaces --
-addressed by different instructions out/in vs store/load (okay, it's '''mov'''
-in x86 parlance, but if you know that, you already should know what I'm
-talking about). Think of PIO as writing to or reading from one end of a FIFO
-while the target reads/writes to the other end.
-
-----
-CategoryGlossary
diff --git a/PageflipBenchmarks.moin b/PageflipBenchmarks.mdwn
index d1cf2f0..0a0532b 100644
--- a/PageflipBenchmarks.moin
+++ b/PageflipBenchmarks.mdwn
@@ -1,94 +1,90 @@
-Some time ago, we implemented page flipping for several of the DRI drivers.  Page flipping is an optimization where, on glXSwapBuffers, rather than blitting the contents of the GL window's back buffer to the front buffer, the driver simply updates the monitor's scanout registers to display the "back" buffer instead of the front; the back and front buffer essentially switch roles on every buffer swap.  Note that one buffer swap is one frame of animation.
-
-It seemed like a good idea at the time, but I (EricAnholt) have been arguing that it was a mistake, due to the added complexity, increased overhead for 2d, and X-versus-OpenGL nonconformance issues due to the shadow buffer used to maintain 2d contents between front and back.
-
-So, how about some benchmarks?  I ran quake3 with pageflipping enabled and disabled on a Radeon 64M VIVO, and got:
-{{{
-x /home/anholt/pf-q3-disable
-+ /home/anholt/pf-q3-enable
-+--------------------------------------------------------------------------+
-|   x                                                                    + |
-|   x                                                                    + |
-|   x                                                                    + |
-|x  x                                                              +     + |
-| |AM                                                                |__AM||
-+--------------------------------------------------------------------------+
-    N           Min           Max        Median           Avg        Stddev
-x   5          70.7          70.8          70.8         70.78    0.04472136
-+   5          73.1          73.3          73.3         73.26   0.089442719
-Difference at 95.0% confidence
-        2.48 +/- 0.103127
-        3.50381% +/- 0.145701%
-        (Student's t, pooled s = 0.0707107)
-}}}
-
-With a Radeon 8500:
-{{{
-x /home/anholt/pf-q3-disable
-+ /home/anholt/pf-q3-enable
-+--------------------------------------------------------------------------+
-|                                                          +               |
-|                             x                            +               |
-|                             x                            +               |
-|x              x             x                            +              +|
-|       |____________A________M___|                     |__M__A______|     |
-+--------------------------------------------------------------------------+
-    N           Min           Max        Median           Avg        Stddev
-x   5          71.6          71.8          71.8         71.74   0.089442719
-+   5            72          72.1            72         72.02    0.04472136
-Difference at 95.0% confidence
-        0.28 +/- 0.103127
-        0.390298% +/- 0.143752%
-        (Student's t, pooled s = 0.0707107)
-}}}
-
-And with a Radeon 7000:
-{{{
-x /home/anholt/pf-q3-disable
-+ /home/anholt/pf-q3-enable
-+--------------------------------------------------------------------------+
-|x                                                                        +|
-|x                                                                        +|
-|x                                                                        +|
-|A                                                                        A|
-+--------------------------------------------------------------------------+
-    N           Min           Max        Median           Avg        Stddev
-x   5          31.2          31.2          31.2          31.2             0
-+   3          32.9          32.9          32.9          32.9 4.7683716e-07
-Difference at 95.0% confidence
-        1.7 +/- 4.91975e-07
-        5.44872% +/- 1.57684e-06%
-        (Student's t, pooled s = 2.75302e-07)
-}}}
-
-
-So, with quake3 at 1024x768 we see an improvement between .4 and 5.4% in framerate.  But I suppose that's not really fair for the rv100, since nobody would actually run it at that resolution on that card.  So how about 640x480?
-{{{
-x /home/anholt/pf-q3-disable
-+ /home/anholt/pf-q3-enable
-+--------------------------------------------------------------------------+
-|  x                                                                    +  |
-|  x          x                                              +          +  |
-|  x          x                                              +          +  |
-||_M___A______|                                              |______A___M_||
-+--------------------------------------------------------------------------+
-    N           Min           Max        Median           Avg        Stddev
-x   5          59.5          59.6          59.5         59.54   0.054772256
-+   5            60          60.1          60.1         60.06   0.054772256
-Difference at 95.0% confidence
-        0.52 +/- 0.0798822
-        0.873362% +/- 0.134166%
-        (Student's t, pooled s = 0.0547723)
-}}}
-
-Now, we see that if we crank down the resolution to a playable framerate, page flipping again becomes unimportant, even on the Radeon 7000.
-
-From a theoretical perspective, let's assume that pageflipping turns glXSwapBuffers into a basically free operation, and that the back-to-front blit execution time is dominated by the video card's VRAM bandwidth.  The peak performance win of pageflipping is therefore
-
-{{{
-            2 * width * height * depth (in bytes)
-framerate * --------------------------
-                     bandwidth
-}}}
-
-Where `framerate` is the FPS count without pageflipping, and the constant 2 factor comes from the fact that every pixel in the blit is read once and written once.  In the example above of a Radeon 7000 at 640x480x32, you have 2.6GB/s of card bandwidth to work with, and about 2.33M of bandwidth used per blit.  So each blit takes about 0.88ms to complete.  By making swapping a "free" operation and starting at 59.6fps, you'd gain at most an additional 52.5ms per second, or about 5% less rendering time per buffer swap.  Likewise in the 1024x768 example you'd end up with at most an additional 70.3ms or 7% higher framerate.
+
+Some time ago, we implemented page flipping for several of the DRI drivers.  Page flipping is an optimization where, on glXSwapBuffers, rather than blitting the contents of the GL window's back buffer to the front buffer, the driver simply updates the monitor's scanout registers to display the "back" buffer instead of the front; the back and front buffer essentially switch roles on every buffer swap.  Note that one buffer swap is one frame of animation. 
+
+It seemed like a good idea at the time, but I ([[EricAnholt|EricAnholt]]) have been arguing that it was a mistake, due to the added complexity, increased overhead for 2d, and X-versus-OpenGL nonconformance issues due to the shadow buffer used to maintain 2d contents between front and back. 
+
+So, how about some benchmarks?  I ran quake3 with pageflipping enabled and disabled on a Radeon 64M VIVO, and got: 
+[[!format txt """
+x /home/anholt/pf-q3-disable
++ /home/anholt/pf-q3-enable
++--------------------------------------------------------------------------+
+|   x                                                                    + |
+|   x                                                                    + |
+|   x                                                                    + |
+|x  x                                                              +     + |
+| |AM                                                                |__AM||
++--------------------------------------------------------------------------+
+    N           Min           Max        Median           Avg        Stddev
+x   5          70.7          70.8          70.8         70.78    0.04472136
++   5          73.1          73.3          73.3         73.26   0.089442719
+Difference at 95.0% confidence
+        2.48 +/- 0.103127
+        3.50381% +/- 0.145701%
+        (Student's t, pooled s = 0.0707107)
+"""]]
+With a Radeon 8500: 
+[[!format txt """
+x /home/anholt/pf-q3-disable
++ /home/anholt/pf-q3-enable
++--------------------------------------------------------------------------+
+|                                                          +               |
+|                             x                            +               |
+|                             x                            +               |
+|x              x             x                            +              +|
+|       |____________A________M___|                     |__M__A______|     |
++--------------------------------------------------------------------------+
+    N           Min           Max        Median           Avg        Stddev
+x   5          71.6          71.8          71.8         71.74   0.089442719
++   5            72          72.1            72         72.02    0.04472136
+Difference at 95.0% confidence
+        0.28 +/- 0.103127
+        0.390298% +/- 0.143752%
+        (Student's t, pooled s = 0.0707107)
+"""]]
+And with a Radeon 7000: 
+[[!format txt """
+x /home/anholt/pf-q3-disable
++ /home/anholt/pf-q3-enable
++--------------------------------------------------------------------------+
+|x                                                                        +|
+|x                                                                        +|
+|x                                                                        +|
+|A                                                                        A|
++--------------------------------------------------------------------------+
+    N           Min           Max        Median           Avg        Stddev
+x   5          31.2          31.2          31.2          31.2             0
++   3          32.9          32.9          32.9          32.9 4.7683716e-07
+Difference at 95.0% confidence
+        1.7 +/- 4.91975e-07
+        5.44872% +/- 1.57684e-06%
+        (Student's t, pooled s = 2.75302e-07)
+"""]]
+So, with quake3 at 1024x768 we see an improvement between .4 and 5.4% in framerate.  But I suppose that's not really fair for the rv100, since nobody would actually run it at that resolution on that card.  So how about 640x480? 
+[[!format txt """
+x /home/anholt/pf-q3-disable
++ /home/anholt/pf-q3-enable
++--------------------------------------------------------------------------+
+|  x                                                                    +  |
+|  x          x                                              +          +  |
+|  x          x                                              +          +  |
+||_M___A______|                                              |______A___M_||
++--------------------------------------------------------------------------+
+    N           Min           Max        Median           Avg        Stddev
+x   5          59.5          59.6          59.5         59.54   0.054772256
++   5            60          60.1          60.1         60.06   0.054772256
+Difference at 95.0% confidence
+        0.52 +/- 0.0798822
+        0.873362% +/- 0.134166%
+        (Student's t, pooled s = 0.0547723)
+"""]]
+Now, we see that if we crank down the resolution to a playable framerate, page flipping again becomes unimportant, even on the Radeon 7000. 
+
+From a theoretical perspective, let's assume that pageflipping turns glXSwapBuffers into a basically free operation, and that the back-to-front blit execution time is dominated by the video card's VRAM bandwidth.  The peak performance win of pageflipping is therefore 
+
+
+[[!format txt """
+            2 * width * height * depth (in bytes)
+framerate * --------------------------
+                     bandwidth
+"""]]
+Where `framerate` is the FPS count without pageflipping, and the constant 2 factor comes from the fact that every pixel in the blit is read once and written once.  In the example above of a Radeon 7000 at 640x480x32, you have 2.6GB/s of card bandwidth to work with, and about 2.33M of bandwidth used per blit.  So each blit takes about 0.88ms to complete.  By making swapping a "free" operation and starting at 59.6fps, you'd gain at most an additional 52.5ms per second, or about 5% less rendering time per buffer swap.  Likewise in the 1024x768 example you'd end up with at most an additional 70.3ms or 7% higher framerate. 
diff --git a/PartiallyAliasedFunctions.mdwn b/PartiallyAliasedFunctions.mdwn
new file mode 100644
index 0000000..d9508d7
--- /dev/null
+++ b/PartiallyAliasedFunctions.mdwn
@@ -0,0 +1,47 @@
+
+
+## Problem Statement
+
+There are a few functions in OpenGL that are functional aliases of each other but do not share GLX protocol.  glGenTexturesEXT and glGenTextures are an example.  From the point of view of an application or a direct rendering driver, these two functions are identical.  From the point of view of an indirect rendering library, these two functions are as different from each other as glGenBuffers and glGenQueries. 
+
+There are a total of 17 pairs of functions that have this mismatch.  They are: 
+
+* [[GL_EXT_convolution|http://www.opengl.org/registry/specs/EXT/convolution.txt]]: 
+   * glGetConvolutionFilterEXT / glGetConvolutionFilter 
+   * glGetConvolutionParameterfvEXT / glGetConvolutionParameterfv 
+   * glGetConvolutionParameterivEXT / glGetConvolutionParameteriv 
+   * glGetSeparableFilterEXT / glGetSeparableFilter 
+* [[GL_EXT_histogram|http://www.opengl.org/registry/specs/EXT/histogram.txt]]: 
+   * glGetHistogramEXT / glGetHistogram 
+   * glGetHistogramParameterfvEXT / glGetHistogramParameterfv 
+   * glGetHistogramParameterivEXT / glGetHistogramParameteriv 
+   * glGetMinmaxEXT / glGetMinmax 
+   * glGetMinmaxParameterfvEXT / glGetMinmaxParameterfv 
+   * glGetMinmaxParameterivEXT / glGetMinmaxParameteriv 
+* [[GL_EXT_texture_object|http://www.opengl.org/registry/specs/EXT/texture_object.txt]]: 
+   * glAreTexturesResidentEXT / glAreTexturesResident 
+   * glDeleteTexturesEXT / glDeleteTextures 
+   * glGenTexturesEXT / glGenTextures 
+   * glIsTextureEXT / glIsTexture 
+* [[GL_SGI_color_table|http://www.opengl.org/registry/specs/SGI/color_table.txt]]: 
+   * glGetColorTableSGI / glGetColorTable 
+   * glGetColorTableParameterfvSGI / glGetColorTableParameterfv 
+   * glGetColorTableParameterivSGI / glGetColorTableParameteriv 
+Since these functions are different for the indirect rendering case, each function has its own slot in the dispatch table.  This factor must be correctly handled by drivers exposing both versions of the function.  Due to the way that Mesa implements GL 1.2 and [[GL_ARB_imaging|http://www.opengl.org/registry/specs/ARB/imaging.txt]], nearly all of the drivers expose both functions in all 17 pairs.  This results in extra, unnecessary code. 
+
+
+## Solution
+
+The solution has two parts.  For direct rendering drivers and software-only Mesa, the EXT version of the function is treated as an alias of the core version.  The indirect rendering library will generate a special stub for the EXT version.  The existing dispatch stubs simply look up a function pointer in the dispatch table and jump to the function.  For these EXT functions, the dispatch stub will first determine whether or not the current context is a direct rendering context.  If the current context is direct rendering, the stub will look up the aliased function in the dispatch table and jump to it.  if the current context is indirect rendering, the stub will emit GLX protocol for the EXT version. 
+
+Since all of these functions involve a round-trip to the server, the performance impact of the added tests should be unmeasurably small. 
+
+
+## Implementation
+
+At a minimum, the following code generator scripts would need to be changed: 
+
+* gl_procs.py (Generates the table used by glXGetProcAddress) - Would need some fairly significant change.  On systems where the dispatch functions are fixed-size (e.g., x86, x86-64 with TLS), a pointer to the dispatch stub is not stored in the table. 
+* glX_proto_send.py (Generates code to send GLX protocol) - Needs to generate dispatch stubs for the EXT versions of the functions.  These special stubs are described above. 
+* glX_proto_recv.py (Generates code to receive GLX protocol) - Generate special code for the matched pairs.  Since the relies are the same for both functions in the pair, the initial stub for each function would decode the inputs then call a secondary function that does the real work. 
+* glX_server_table.py (Generates the server's GLX protocol decode tables) - Needs to be smart enough to treat aliased functions with different opcodes as different functions. 
+\ No newline at end of file
diff --git a/PartiallyAliasedFunctions.moin b/PartiallyAliasedFunctions.moin
deleted file mode 100644
index 0c431dc..0000000
--- a/PartiallyAliasedFunctions.moin
+++ /dev/null
@@ -1,65 +0,0 @@
-== Problem Statement ==
-
-There are a few functions in OpenGL that are functional aliases of each
-other but do not share GLX protocol.  glGenTexturesEXT and glGenTextures are
-an example.  From the point of view of an application or a direct rendering
-driver, these two functions are identical.  From the point of view of an
-indirect rendering library, these two functions are as different from each
-other as glGenBuffers and glGenQueries.
-
-There are a total of 17 pairs of functions that have this mismatch.  They
-are:
-
- * [[http://www.opengl.org/registry/specs/EXT/convolution.txt|GL_EXT_convolution]]:
-  * glGetConvolutionFilterEXT / glGetConvolutionFilter
-  * glGetConvolutionParameterfvEXT / glGetConvolutionParameterfv
-  * glGetConvolutionParameterivEXT / glGetConvolutionParameteriv
-  * glGetSeparableFilterEXT / glGetSeparableFilter
- * [[http://www.opengl.org/registry/specs/EXT/histogram.txt|GL_EXT_histogram]]:
-  * glGetHistogramEXT / glGetHistogram
-  * glGetHistogramParameterfvEXT / glGetHistogramParameterfv
-  * glGetHistogramParameterivEXT / glGetHistogramParameteriv
-  * glGetMinmaxEXT / glGetMinmax
-  * glGetMinmaxParameterfvEXT / glGetMinmaxParameterfv
-  * glGetMinmaxParameterivEXT / glGetMinmaxParameteriv
- * [[http://www.opengl.org/registry/specs/EXT/texture_object.txt|GL_EXT_texture_object]]:
-  * glAreTexturesResidentEXT / glAreTexturesResident
-  * glDeleteTexturesEXT / glDeleteTextures
-  * glGenTexturesEXT / glGenTextures
-  * glIsTextureEXT / glIsTexture
- * [[http://www.opengl.org/registry/specs/SGI/color_table.txt|GL_SGI_color_table]]:
-  * glGetColorTableSGI / glGetColorTable
-  * glGetColorTableParameterfvSGI / glGetColorTableParameterfv
-  * glGetColorTableParameterivSGI / glGetColorTableParameteriv
-
-Since these functions are different for the indirect rendering case, each
-function has its own slot in the dispatch table.  This factor must be
-correctly handled by drivers exposing both versions of the function.  Due to
-the way that Mesa implements GL 1.2 and [[http://www.opengl.org/registry/specs/ARB/imaging.txt|GL_ARB_imaging]], nearly all of the
-drivers expose both functions in all 17 pairs.  This results in extra,
-unnecessary code.
-
-== Solution ==
-
-The solution has two parts.  For direct rendering drivers and software-only
-Mesa, the EXT version of the function is treated as an alias of the core
-version.  The indirect rendering library will generate a special stub for
-the EXT version.  The existing dispatch stubs simply look up a function
-pointer in the dispatch table and jump to the function.  For these EXT
-functions, the dispatch stub will first determine whether or not the current
-context is a direct rendering context.  If the current context is direct
-rendering, the stub will look up the aliased function in the dispatch table
-and jump to it.  if the current context is indirect rendering, the stub will
-emit GLX protocol for the EXT version.
-
-Since all of these functions involve a round-trip to the server, the
-performance impact of the added tests should be unmeasurably small.
-
-== Implementation ==
-
-At a minimum, the following code generator scripts would need to be changed:
-
- * gl_procs.py (Generates the table used by glXGetProcAddress) - Would need some fairly significant change.  On systems where the dispatch functions are fixed-size (e.g., x86, x86-64 with TLS), a pointer to the dispatch stub is not stored in the table.
- * glX_proto_send.py (Generates code to send GLX protocol) - Needs to generate dispatch stubs for the EXT versions of the functions.  These special stubs are described above.
- * glX_proto_recv.py (Generates code to receive GLX protocol) - Generate special code for the matched pairs.  Since the relies are the same for both functions in the pair, the initial stub for each function would decode the inputs then call a secondary function that does the real work.
- * glX_server_table.py (Generates the server's GLX protocol decode tables) - Needs to be smart enough to treat aliased functions with different opcodes as different functions.
diff --git a/PowerManagement.mdwn b/PowerManagement.mdwn
new file mode 100644
index 0000000..a2d5acc
--- /dev/null
+++ b/PowerManagement.mdwn
@@ -0,0 +1,7 @@
+
+
+# Power Management Support
+
+See Charl Botha's patches on [[http://cpbotha.net/dri_resume.html|http://cpbotha.net/dri_resume.html]] and [[http://cpbotha.net/dri_reinit.html|http://cpbotha.net/dri_reinit.html]] . 
+
+See [[AlexDeucher|AlexDeucher]]'s Radeon XFree86 [[power management patch|http://bugs.xfree86.org/show_bug.cgi?id=96]] based on Benjamin Herrenschmidt and ATI's radeonfb power management code. 
diff --git a/PowerManagement.moin b/PowerManagement.moin
deleted file mode 100644
index f6a8ee9..0000000
--- a/PowerManagement.moin
+++ /dev/null
@@ -1,5 +0,0 @@
-= Power Management Support =
-
-See Charl Botha's patches on http://cpbotha.net/dri_resume.html and http://cpbotha.net/dri_reinit.html .
-
-See AlexDeucher's Radeon XFree86 [[http://bugs.xfree86.org/show_bug.cgi?id=96|power management patch]] based on Benjamin Herrenschmidt and ATI's radeonfb power management code.
diff --git a/PowerVR.moin b/PowerVR.mdwn
index 5ebef8e..23c9395 100644
--- a/PowerVR.moin
+++ b/PowerVR.mdwn
@@ -1,24 +1,32 @@
-= PowerVR =
-
-At least three PowerVR chip generations exist.  The first was the version used on the Matrox m3D card, which was a pure-3D accelerator card that plugged into the PCI bus but had no monitor connector.  Presumably one would render the 3D scene on the PowerVR card and blit it across the bus to the existing 2D card.  This is a very strange device and would present interesting challenges to support in the DRI.  A second PowerVR chip was used in the Sega Dreamcast video game console.  There were also several PC-class PCI and AGP cards made under the Kyro brand containing PowerVR chips.
-
-There are probably further PowerVR chips being used in embedded devices.
-
-The PowerVR chips appear to lack an explicit depth buffer, with the scene instead being subdivided into tiles and the depth buffer constructed on the fly for each frame.  This would save significant memory on embedded platforms, but might make full GL conformance a challenge.
-
-== Status ==
-
-No 2D or 3D driver for PowerVR chips exists in Xorg.  The Linux kernel includes an fbdev driver which is probably good enough to bootstrap an Xorg driver with.
-
-Some 3D information can probably be gleaned from [[http://www.dchomebrew.org/freedev/kgl.pdf|KallistiGL]], a GL subset in the Dreamcast homebrew operating system KallistiOS.  It's unknown how much of this information would be relevant to earlier or later generations of PowerVR hardware.
-
-There exists a closed-source PowerVR binary driver for Linux 2.4 kernels, including DRI support.  It does not appear to be based on Mesa, and the manufacturer has expressed no interest in supporting later kernels.
-
-== Specifications ==
-
-Potentially available under NDA.
-
-== Resources ==
-
-----
-CategoryHardwareChipset
+
+
+# PowerVR
+
+At least three PowerVR chip generations exist.  The first was the version used on the Matrox m3D card, which was a pure-3D accelerator card that plugged into the PCI bus but had no monitor connector.  Presumably one would render the 3D scene on the PowerVR card and blit it across the bus to the existing 2D card.  This is a very strange device and would present interesting challenges to support in the DRI.  A second PowerVR chip was used in the Sega Dreamcast video game console.  There were also several PC-class PCI and AGP cards made under the Kyro brand containing PowerVR chips. 
+
+There are probably further PowerVR chips being used in embedded devices. 
+
+The PowerVR chips appear to lack an explicit depth buffer, with the scene instead being subdivided into tiles and the depth buffer constructed on the fly for each frame.  This would save significant memory on embedded platforms, but might make full GL conformance a challenge. 
+
+
+## Status
+
+No 2D or 3D driver for PowerVR chips exists in Xorg.  The Linux kernel includes an fbdev driver which is probably good enough to bootstrap an Xorg driver with. 
+
+Some 3D information can probably be gleaned from [[KallistiGL|http://www.dchomebrew.org/freedev/kgl.pdf]], a GL subset in the Dreamcast homebrew operating system KallistiOS.  It's unknown how much of this information would be relevant to earlier or later generations of PowerVR hardware. 
+
+There exists a closed-source PowerVR binary driver for Linux 2.4 kernels, including DRI support.  It does not appear to be based on Mesa, and the manufacturer has expressed no interest in supporting later kernels. 
+
+
+## Specifications
+
+Potentially available under NDA. 
+
+
+## Resources
+
+
+
+---
+
+ [[CategoryHardwareChipset|CategoryHardwareChipset]] 
diff --git a/Profiling.mdwn b/Profiling.mdwn
new file mode 100644
index 0000000..39d920c
--- /dev/null
+++ b/Profiling.mdwn
@@ -0,0 +1,92 @@
+
+
+# Profiling DRI drivers
+
+
+## Using oprofile
+
+[[Oprofile|http://oprofile.sourceforge.net/]] is not difficult to setup, it doesn't require special compilation flags other than debugging info, and it allows to know where time is spent globally (including time spent inside the kernel and X server). 
+
+Here is a simple script that automates the invocation of oprofile to profile glxgears:  
+[[!format txt """
+#!/bin/sh
+VMLINUX=/boot/vmlinux-`uname -r`
+if [ -f $VMLINUX ]
+then
+        opcontrol --vmlinux=$VMLINUX
+else
+        opcontrol --no-vmlinux
+fi
+opcontrol --separate=kernel
+opcontrol --callgraph=16
+opcontrol --init
+opcontrol --reset
+glxgears &
+PID=$!
+sleep 5s
+opcontrol --start 
+sleep 60s
+kill $PID
+opcontrol --stop
+opcontrol --dump
+"""]]
+NOTE: Oprofile requires kernel support, and an uncompressed vmlinux to profile inside the kernel. For Debian-based distro users, oprofile already comes with stock kernel, but uncompressed vmlinux images dot not. Check the instructions in /usr/share/doc/oprofile/README.Debian.gz for more details on how to proceed. For Redhat enable the core-debuginfo repos in /etc/yum.repos.d/, and yum install kernel-debuginfo. See [[here|http://www.redhat.com/magazine/012oct05/features/oprofile/]] for more detail on oprofile and [[RedHat|RedHat]]. 
+
+WARNING: I used the above script on a Celeron processor, for which oprofile can produce timer based information only. Time is usually more interesting than other CPU events. Therefore, on non-Celeron processors you will likely need to pass an --event=XXX option to request specifically timer based events. The actual option depends on your kernel version and processor. See the [[oprofile manual|http://oprofile.sourceforge.net/doc/]] for more information. 
+
+You can then view the output by: 
+[[!format txt """
+opreport -l | less
+"""]]
+You can also generate a colored call graph using [[gprof2dot.py|http://code.google.com/p/jrfonseca/wiki/Gprof2Dot]]: 
+[[!format txt """
+opreport -cgf > glxgears.oprofile
+/path/to/gprof2dot.py -f oprofile -o glxgears.dot glxgears.oprofile
+dot -Tpng -o glxgears.png glxgears.dot
+"""]]
+You'll hopefully get an image similar to [[this one|http://people.freedesktop.org/~jrfonseca/profiling/oprofile-gallium.png]]. 
+
+See the [[xdot.py|http://jrfonseca.googlecode.com/svn/trunk/gprof2dot/xdot.py]] script for interactive viewing of *.dot files. 
+
+NOTE: The gprof2dot.py and xdot.py are work in progress. Please contact-me if you have any problems with them. -- [[JoseFonseca|JoseFonseca]] 
+
+You can also use [[KCacheGrind|http://kcachegrind.sourceforge.net/]] together with the included op2calltree script to visualize it. However, op2calltree doesn't support call graph information. You'll only get a linear profile. 
+
+
+## Valgrind + Callgrind
+
+Using [[valgrind|http://valgrind.org/]] is very simple: 
+
+
+[[!format txt """
+valgrind --tool=callgrind glxgears
+"""]]
+And you can use [[KCacheGrind|http://kcachegrind.sourceforge.net/]] to visualize the output it generates. 
+
+However, callgrind only measures CPU instructions, not time. So the time that driver is spending waiting for buffers from DRM, or the card is not accounted.  Enhancing callgrind to measure time would be an interesting project. 
+
+
+## Using gprof
+
+Gprof requires the code to be recompiled and libraries statically linked, which is not convenient for profiling DRI drivers. 
+
+However, Gallium 3D has the option to be compiled statically with profiling generation: 
+
+
+[[!format txt """
+make linux-debug
+cd progs/xdemos
+make
+./glxgears
+gprof glxgears
+"""]]
+You can also generate a graph from gprof output using [[http://code.google.com/p/jrfonseca/wiki/Gprof2Dot|http://code.google.com/p/jrfonseca/wiki/Gprof2Dot]] . 
+
+
+## Others
+
+Here are some other profilers which might also be useful: 
+
+* [[Sysprof|http://www.daimi.au.dk/~sandmann/sysprof/]] -- similar to oprofile, comes with a gui 
+* [[qprof|http://www.hpl.hp.com/research/linux/qprof/]] -- process-wide profiling without need for kernel support 
+* simple benchmarking of [[screensaver|https://wiki.ubuntu.com/X/Screensavers]] hacks 
+\ No newline at end of file
diff --git a/Profiling.moin b/Profiling.moin
deleted file mode 100644
index 5ff8978..0000000
--- a/Profiling.moin
+++ /dev/null
@@ -1,92 +0,0 @@
-= Profiling DRI drivers =
-
-== Using oprofile ==
-
-[[http://oprofile.sourceforge.net/|Oprofile]] is not difficult to setup, it doesn't require special compilation flags other than debugging info, and it allows to know where time is spent globally (including time spent inside the kernel and X server).
-
-Here is a simple script that automates the invocation of oprofile to profile glxgears: 
-{{{
-#!/bin/sh
-VMLINUX=/boot/vmlinux-`uname -r`
-if [ -f $VMLINUX ]
-then
-        opcontrol --vmlinux=$VMLINUX
-else
-        opcontrol --no-vmlinux
-fi
-opcontrol --separate=kernel
-opcontrol --callgraph=16
-opcontrol --init
-opcontrol --reset
-glxgears &
-PID=$!
-sleep 5s
-opcontrol --start 
-sleep 60s
-kill $PID
-opcontrol --stop
-opcontrol --dump
-}}}
-
-NOTE: Oprofile requires kernel support, and an uncompressed vmlinux to profile inside the kernel. For Debian-based distro users, oprofile already comes with stock kernel, but uncompressed vmlinux images dot not. Check the instructions in /usr/share/doc/oprofile/README.Debian.gz for more details on how to proceed. For Redhat enable the core-debuginfo repos in /etc/yum.repos.d/, and yum install kernel-debuginfo. See [[http://www.redhat.com/magazine/012oct05/features/oprofile/|here]] for more detail on oprofile and RedHat.
-
-WARNING: I used the above script on a Celeron processor, for which oprofile can produce timer based information only. Time is usually more interesting than other CPU events. Therefore, on non-Celeron processors you will likely need to pass an --event=XXX option to request specifically timer based events. The actual option depends on your kernel version and processor. See the [[http://oprofile.sourceforge.net/doc/|oprofile manual]] for more information.
-
-You can then view the output by:
-{{{
-opreport -l | less
-}}}
-
-You can also generate a colored call graph using [[http://code.google.com/p/jrfonseca/wiki/Gprof2Dot|gprof2dot.py]]:
-{{{
-opreport -cgf > glxgears.oprofile
-/path/to/gprof2dot.py -f oprofile -o glxgears.dot glxgears.oprofile
-dot -Tpng -o glxgears.png glxgears.dot
-}}}
-
-You'll hopefully get an image similar to [[http://people.freedesktop.org/~jrfonseca/profiling/oprofile-gallium.png|this one]].
-
-See the [[http://jrfonseca.googlecode.com/svn/trunk/gprof2dot/xdot.py|xdot.py]] script for interactive viewing of *.dot files.
-
-NOTE: The gprof2dot.py and xdot.py are work in progress. Please contact-me if you have any problems with them. -- JoseFonseca
-
-You can also use [[http://kcachegrind.sourceforge.net/|KCacheGrind]] together with the included op2calltree script to visualize it. However, op2calltree doesn't support call graph information. You'll only get a linear profile.
-
-
-== Valgrind + Callgrind ==
-
-Using [[http://valgrind.org/|valgrind]] is very simple:
-
-{{{
-valgrind --tool=callgrind glxgears
-}}}
-
-And you can use [[http://kcachegrind.sourceforge.net/|KCacheGrind]] to visualize the output it generates.
-
-However, callgrind only measures CPU instructions, not time. So the time that driver is spending waiting for buffers from DRM, or the card is not accounted. 
-Enhancing callgrind to measure time would be an interesting project.
-
-
-== Using gprof ==
-
-Gprof requires the code to be recompiled and libraries statically linked, which is not convenient for profiling DRI drivers.
-
-However, Gallium 3D has the option to be compiled statically with profiling generation:
-
-{{{
-make linux-debug
-cd progs/xdemos
-make
-./glxgears
-gprof glxgears
-}}}
-
-You can also generate a graph from gprof output using http://code.google.com/p/jrfonseca/wiki/Gprof2Dot .
-
-
-== Others ==
-
-Here are some other profilers which might also be useful:
- * [[http://www.daimi.au.dk/~sandmann/sysprof/|Sysprof]] -- similar to oprofile, comes with a gui
- * [[http://www.hpl.hp.com/research/linux/qprof/|qprof]] -- process-wide profiling without need for kernel support
- * simple benchmarking of [[https://wiki.ubuntu.com/X/Screensavers|screensaver]] hacks
diff --git a/QuickDraw3D.moin b/QuickDraw3D.mdwn
index 2248796..6cea7c3 100644
--- a/QuickDraw3D.moin
+++ b/QuickDraw3D.mdwn
@@ -1,3 +1,5 @@
-== QuickDraw3D ==
-
-A 3D graphics API used on Apple Macintosh systems through MacOS 9.x.  In 1999 Apple decided to not support QuickDraw3D in the Carbon toolkit (which provides the classic MacOS API to OSX applications).  The QuickDraw3D API lives on in [[http://www.quesa.org/|Quesa]], an LGPL'd clean-room implementation that is both source- and binary-compatible with Apple's library and runs on MacOS 8-X, Windows, Linux, and BeOS.
+
+
+## QuickDraw3D
+
+A 3D graphics API used on Apple Macintosh systems through MacOS 9.x.  In 1999 Apple decided to not support QuickDraw3D in the Carbon toolkit (which provides the classic MacOS API to OSX applications).  The QuickDraw3D API lives on in [[Quesa|http://www.quesa.org/]], an LGPL'd clean-room implementation that is both source- and binary-compatible with Apple's library and runs on MacOS 8-X, Windows, Linux, and BeOS. 
diff --git a/R200ToDo.mdwn b/R200ToDo.mdwn
new file mode 100644
index 0000000..d2505b0
--- /dev/null
+++ b/R200ToDo.mdwn
@@ -0,0 +1,10 @@
+
+
+# R200 ToDo
+
+1. Figure out various tiling on r200 (colorbuffer already done, texture tiling need some work) 
+1. Abjust r200_blit.c to work between tiled/untiled surfaces 
+1. Figure out how to upload and use hardware vertex buffer objects on r200 (and r100?) 
+1. Add support for [[pixel_buffer_object|http://www.opengl.org/registry/specs/ARB/pixel_buffer_object.txt]] 
+1. Use some "meta" code in mesa for more acceleration (glbitmaps .... ) 
+... 
diff --git a/R200ToDo.moin b/R200ToDo.moin
deleted file mode 100644
index 8c7902a..0000000
--- a/R200ToDo.moin
+++ /dev/null
@@ -1,10 +0,0 @@
-= R200 ToDo =
-
- 1. Figure out various tiling on r200 (colorbuffer already done, texture tiling need some work)
- 2. Abjust r200_blit.c to work between tiled/untiled surfaces
- 4. Figure out how to upload and use hardware vertex buffer objects on r200 (and r100?)
- 5. Add support for [[http://www.opengl.org/registry/specs/ARB/pixel_buffer_object.txt | pixel_buffer_object ]]
- 6. Use some "meta" code in mesa for more acceleration (glbitmaps .... )
-
-
-...
diff --git a/R300.mdwn b/R300.mdwn
new file mode 100644
index 0000000..ecff6eb
--- /dev/null
+++ b/R300.mdwn
@@ -0,0 +1,59 @@
+
+
+# Deprecation Warning
+
+This page is deprecated and exists only for historical reason; it should be removed/archived entirely at some point. 
+
+Go to [[Radeon|Radeon]] instead. 
+
+
+# R300
+
+Homepage of AMD/ATI R300 chipset. You will find here all you want to know about DRI R300 support, at least i hope so. :) 
+
+We always need help, take a look at the [[R300ToDo|R300ToDo]] list and see if there is anything you could do! Read the documentation, the code, and if you want to ask something or to start getting involved join us in #dri-devel on freenode. 
+
+
+## News
+
+_**30.04.2007 posted by [[ChristophBrill|ChristophBrill]]**_  
+ We switched our news section to a [[blog|http://tirdc.livejournal.com]] that is aggregated on [[Planet Freedesktop|http://planet.freedesktop.org]]. There won't be any further news entries here. 
+
+_**25.04.2007 posted by [[ChristophBrill|ChristophBrill]]**_  
+ Time is passing way to fast, but here it is: [[TiRDC #4|Radeon_Companion_4]]. 
+
+_**01.04.2007 posted by [[ChristophBrill|ChristophBrill]]**_  
+ Since we got so much great news on Radeon development we proudly present you a short but informative [[TiRDC #3|Radeon_Companion_3]]. 
+
+_**20.03.2007 posted by [[ChristophBrill|ChristophBrill]]**_  
+ There has been such a great response on TiRDC #1 and so much activity lately, we wanted to inform you about. So here is [[TiRDC #2|Radeon_Companion_2]] for you to read. 
+
+_**10.03.2007 posted by [[ChristophBrill|ChristophBrill]]**_  
+ Welcome to the new _News_ section in this wiki. We have written a small summary of current events for you. Take a look at [[TiRDC #1|Radeon%Companion%1]] for you. 
+
+
+## DRI/DRM
+
+   * Documentation: The DRI documentation page 
+   * [[DRI, DDX, DRM, GLX... how it works together|http://people.freedesktop.org/~ajax/dri-explanation.txt]] 
+   * [[MesaDriver|MesaDriver]]: How to write a Mesa driver 
+   * [[A locking mechanism for the DRI|http://dri.sourceforge.net/doc/hardware_locking_low_level.html]] 
+
+## Reverse engineering
+
+   * [[ReverseEngineering|ReverseEngineering]]: Reverse engineering tools 
+
+## R300 related page
+
+   * [[R300Benchmark|R300Benchmark]]: Benchmark of R300 driver 
+   * [[R300Application|R300Application]]: Meant as a list of applications and their general behaviour with the r300 driver. 
+   * [[http://megahurts.dk/rune/r300_status.html|http://megahurts.dk/rune/r300_status.html]] (Another status page) 
+
+## TODO
+
+   * [[R300ToDo|R300ToDo]]: The R300 to do list 
+   * [[ToDo|ToDo]]: General to do list 
+
+## Links
+
+   * [[R300_Portal|R300_Portal]]: Get some links to other resources there 
+\ No newline at end of file
diff --git a/R300.moin b/R300.moin
deleted file mode 100644
index c18b9ef..0000000
--- a/R300.moin
+++ /dev/null
@@ -1,62 +0,0 @@
-= Deprecation Warning =
-
-This page is deprecated and exists only for historical reason; it should be removed/archived entirely at some point.
-
-Go to [[Radeon]] instead.
-
-
-= R300 =
-
-Homepage of AMD/ATI R300 chipset. You will find here all you want to know about DRI R300 support, at least i hope so. :)
-
-We always need help, take a look at the R300ToDo list and see if there is anything you could do! Read the documentation, the code, and if you want to ask something or to start getting involved join us in #dri-devel on freenode.
-
-== News ==
-
-'''''30.04.2007 posted by ChristophBrill'''''<<BR>>
-We switched our news section to a [[http://tirdc.livejournal.com|blog]] that is aggregated on [[http://planet.freedesktop.org|Planet Freedesktop]]. There won't be any further news entries here.
-
-'''''25.04.2007 posted by ChristophBrill'''''<<BR>>
-Time is passing way to fast, but here it is: [[Radeon_Companion_4|TiRDC #4]].
-
-'''''01.04.2007 posted by ChristophBrill'''''<<BR>>
-Since we got so much great news on Radeon development we proudly present you a short but informative [[Radeon_Companion_3|TiRDC #3]].
-
-'''''20.03.2007 posted by ChristophBrill'''''<<BR>>
-There has been such a great response on TiRDC #1 and so much activity lately, we wanted to inform you about. So here is [[Radeon_Companion_2|TiRDC #2]] for you to read.
-
-'''''10.03.2007 posted by ChristophBrill'''''<<BR>>
-Welcome to the new ''News'' section in this wiki. We have written a small summary of current events for you. Take a look at [[Radeon%Companion%1|TiRDC #1]] for you.
-
-== DRI/DRM ==
-
-  * Documentation: The DRI documentation page
-
-  * [[http://people.freedesktop.org/~ajax/dri-explanation.txt|DRI, DDX, DRM, GLX... how it works together]]
-
-  * MesaDriver: How to write a Mesa driver
-
-  * [[http://dri.sourceforge.net/doc/hardware_locking_low_level.html|A locking mechanism for the DRI]]
-
-
-== Reverse engineering ==
-
-  * ReverseEngineering: Reverse engineering tools
-
-== R300 related page ==
-
-  * R300Benchmark: Benchmark of R300 driver
-
-  * R300Application: Meant as a list of applications and their general behaviour with the r300 driver.
-
-  * [[http://megahurts.dk/rune/r300_status.html]] (Another status page)
-
-== TODO ==
-
-  * R300ToDo: The R300 to do list
-
-  * ToDo: General to do list
-
-== Links ==
-
-  * [[R300_Portal]]: Get some links to other resources there
diff --git a/R300Application.mdwn b/R300Application.mdwn
new file mode 100644
index 0000000..e411643
--- /dev/null
+++ b/R300Application.mdwn
@@ -0,0 +1,223 @@
+
+
+# Deprecation warning
+
+This page is deprecated / obsolete and exists only for historical reasons. It should be removed entirely eventually. 
+
+Go to [[Radeon|Radeon]] or [[RadeonProgram|http://xorg.freedesktop.org/wiki/RadeonProgram]] at X.org wiki instead. 
+
+
+
+---
+
+ **Tips:** 
+
+* If you experience crashes see [[radeon config|http://dri.freedesktop.org/wiki/ATIRadeon#head-8851142da56fd885ce668a165b33fee7003e858d]]. 
+* To reboot in a safer manner with lockups, try **Magic Sys Rq** in linux. (Ctrl + alt + Sys Rq   S  U  B ). 
+
+
+---
+
+ [[!toc ]] 
+
+---
+
+ 
+# B
+
+
+## Battalion
+[[!table header="no" class="mointable" data="""
+ **2004c**  |  Stable, but toooo fast 
+"""]]
+
+
+## Blender
+[[!table header="no" class="mointable" data="""
+ **2.42**  |  Stable, but corrupted black menus 
+ **2.41** and **2.42a**  |  Stable, but problems in some vertex select mode 
+"""]]
+
+
+## Briquolo
+[[!table header="no" class="mointable" data="""
+ **0.5.4**  |  Stable 
+"""]]
+
+
+## BZflag
+[[!table header="no" class="mointable" data="""
+ **2.0.8**  |  Stable 
+"""]]
+
+
+# C
+
+
+## Celestia
+[[!table header="no" class="mointable" data="""
+ **1.4.0**  |  Stable 
+ **1.4.1**  |  Crash in some circonstances 
+"""]]
+
+
+# E
+
+
+## Enemy Territory
+[[!table header="no" class="mointable" data="""
+ **2.60**  |  Stable 
+"""]]
+
+
+# F
+
+
+## Flight Gear Flight Simulator
+[[!table header="no" class="mointable" data="""
+ **0.9.10**  |  Stable, have to disable fallback for quality to be usable 
+"""]]
+
+
+# N
+
+
+## Neverball
+[[!table header="no" class="mointable" data="""
+ **1.4.0**  |  Stable 
+"""]]
+
+
+## Nexuiz
+[[!table header="no" class="mointable" data="""
+ **2.1**  |  Varying from stable - segfaults, depending on driver versions and driver settings.  
+"""]]
+
+
+# Q
+
+
+## Quake
+[[!table header="no" class="mointable" data="""
+ **equake (fuhquake-gl.glx)**  |  Stable 
+"""]]
+
+
+## Quake 2
+[[!table header="no" class="mointable" data="""
+ **icculus.org svn (ref_sdlgl.so)**  |  Stable 
+ **icculus.org svn (ref_glx.so)**  |  Stable, mouse issue 
+"""]]
+
+
+## Quake 3 Arena
+[[!table header="no" class="mointable" data="""
+ **1.32b**  |  Stable 
+ **demo**  |  Stable 
+ **1.32b, mod true combat 1.3** |  Lockups in XAA mode, use EXA
+"""]]
+
+
+## Quake 4
+[[!table header="no" class="mointable" data="""
+ **demo**  |  Segfaults on startup 
+"""]]
+
+
+# S
+
+
+## Second Life
+[[!table header="no" class="mointable" data="""
+ **Alpha Linux Client**  |  Stable 
+"""]]
+
+
+## Search and Rescue
+[[!table header="no" class="mointable" data="""
+ **0.8.2**  |  works fine, sometimes crash at end of mission 
+"""]]
+
+
+## SuperTux
+[[!table header="no" class="mointable" data="""
+ **0.1.3**  |  Stable but big bugs in screen blits 
+"""]]
+
+
+## Supertuxkart
+[[!table header="no" class="mointable" data="""
+ **0.2rc1**  |  Stable but slow 
+"""]]
+
+
+# T
+
+
+## TASpring
+[[!table header="no" class="mointable" data="""
+ **svn + taspring-linux-data-0.72b1**  |  Stable 
+"""]]
+
+
+## Trackballs
+[[!table header="no" class="mointable" data="""
+ **1.1.1**  |  Stable, sometime a little bit slow 
+"""]]
+
+
+## Toycars
+[[!table header="no" class="mointable" data="""
+ **0.2.3**  |  Stable 
+"""]]
+
+
+# U
+
+
+## ultimatestunts
+[[!table header="no" class="mointable" data="""
+ **0561**  |  stable but really slow 
+"""]]
+
+
+## Unreal Tournament 1999
+[[!table header="no" class="mointable" data="""
+ **GOTY, 436**  |  Stable 
+ **demo**  |  Stable 
+"""]]
+
+
+## Unreal Tournament 2004
+[[!table header="no" class="mointable" data="""
+ **MEGAPACK 1.0, 3369.2**   |  Stable. But renders with texture corruption due to S3TC version. 
+ **demo**  |  Stable. But renders with texture corruption due to S3TC version. 
+"""]]
+
+
+# V
+
+
+## Vegastrike
+[[!table header="no" class="mointable" data="""
+ **svn**  |  Stable 
+"""]]
+
+
+# W
+
+
+## Warzone 2100
+[[!table header="no" class="mointable" data="""
+ **svn**  |  Stable 
+"""]]
+
+
+# X
+
+
+## X moto
+[[!table header="no" class="mointable" data="""
+ **0.1.12**  |  Stable 
+ **0.1.16**  |  Generally stable, crash at quit 
+"""]]
diff --git a/R300Application.moin b/R300Application.moin
deleted file mode 100644
index 4229dc6..0000000
--- a/R300Application.moin
+++ /dev/null
@@ -1,109 +0,0 @@
-= Deprecation warning =
-
-This page is deprecated / obsolete and exists only for historical reasons. It should be removed entirely eventually.
-
-Go to [[Radeon]] or [[http://xorg.freedesktop.org/wiki/RadeonProgram|RadeonProgram]] at X.org wiki instead.
-
-----
-'''Tips:'''
- * If you experience crashes see [[http://dri.freedesktop.org/wiki/ATIRadeon#head-8851142da56fd885ce668a165b33fee7003e858d|radeon config]].
- * To reboot in a safer manner with lockups, try '''Magic Sys Rq''' in linux. (Ctrl + alt + Sys Rq   S  U  B ).
-----
-<<TableOfContents>>
-----
-= B =
-
-== Battalion ==
-|| '''2004c''' || Stable, but toooo fast ||
-
-== Blender ==
-|| '''2.42''' || Stable, but corrupted black menus ||
-|| '''2.41''' and '''2.42a''' || Stable, but problems in some vertex select mode ||
-
-== Briquolo ==
-|| '''0.5.4''' || Stable ||
-
-== BZflag ==
-|| '''2.0.8''' || Stable ||
-
-= C =
-== Celestia ==
-|| '''1.4.0''' || Stable ||
-|| '''1.4.1''' || Crash in some circonstances ||
- 
-= E =
-== Enemy Territory ==
-|| '''2.60''' || Stable ||
-
-= F =
-== Flight Gear Flight Simulator ==
-|| '''0.9.10''' || Stable, have to disable fallback for quality to be usable ||
-
-
-= N =
-== Neverball ==
-|| '''1.4.0''' || Stable ||
-== Nexuiz ==
-|| '''2.1''' || Varying from stable - segfaults, depending on driver versions and driver settings.  ||
-
-= Q =
-== Quake ==
-|| '''equake (fuhquake-gl.glx)''' || Stable ||
-== Quake 2 ==
-|| '''icculus.org svn (ref_sdlgl.so)''' || Stable ||
-|| '''icculus.org svn (ref_glx.so)''' || Stable, mouse issue ||
-== Quake 3 Arena ==
-|| '''1.32b''' || Stable ||
-|| '''demo''' || Stable ||
-|| '''1.32b, mod true combat 1.3'''|| Lockups in XAA mode, use EXA||
-== Quake 4 ==
-|| '''demo''' || Segfaults on startup ||
-
-= S =
-== Second Life ==
-|| '''Alpha Linux Client''' || Stable ||
-
-== Search and Rescue ==
-|| '''0.8.2''' || works fine, sometimes crash at end of mission ||
-
-== SuperTux ==
-|| '''0.1.3''' || Stable but big bugs in screen blits ||
-
-== Supertuxkart ==
-|| '''0.2rc1''' || Stable but slow ||
-
-= T =
-== TASpring ==
-|| '''svn + taspring-linux-data-0.72b1''' || Stable ||
-
-== Trackballs ==
-|| '''1.1.1''' || Stable, sometime a little bit slow ||
-
-== Toycars ==
-|| '''0.2.3''' || Stable ||
-
-= U =
-
-== ultimatestunts ==
-|| '''0561''' || stable but really slow ||
-
-== Unreal Tournament 1999 ==
-|| '''GOTY, 436''' || Stable ||
-|| '''demo''' || Stable ||
-
-== Unreal Tournament 2004 ==
-|| '''MEGAPACK 1.0, 3369.2'''  || Stable. But renders with texture corruption due to S3TC version. ||
-|| '''demo''' || Stable. But renders with texture corruption due to S3TC version. ||
-
-= V =
-== Vegastrike ==
-|| '''svn''' || Stable ||
-
-= W =
-== Warzone 2100 ==
-|| '''svn''' || Stable ||
-
-= X =
-== X moto ==
-|| '''0.1.12''' || Stable ||
-|| '''0.1.16''' || Generally stable, crash at quit ||
diff --git a/R300Benchmark.moin b/R300Benchmark.mdwn
index 5b8bde8..78fadf2 100644
--- a/R300Benchmark.moin
+++ b/R300Benchmark.mdwn
@@ -1,52 +1,66 @@
-= Instructions =
-To keep this meaningful:
- * Short test descriptions with full closure on circumstance.
- * Preferably use existing example tests. 
- * Only submit games that '''render as intended''' and that do '''not crash'''.
-<<BR>>
-= Benchmarks =
- * Quake 3 Arena
-{{{
-    game: Quake 3 Arena 
- version: 1.32b
-
-settings: untouched default settings, fullscreen, varying resolutions. 
-    test: in the ingame console (~ key) type:
-          timedemo 1; demo four
-
-  system: P4 2.8GHZ 533MHZ 1GB
-     GPU: PCIE X700LE 128MB 64bit      
-
-  driver: (II) ATI: ATI driver (version 6.6.1) for chipsets: ati, ativga
-          (II) RADEON(0): [dri] Found DRI library version 
-          (II) RADEON(0): [drm] DRM interface version 1.2
-          OpenGL renderer string: Mesa DRI R300 20040924 x86/MMX/SSE2 TCL
-          OpenGL version string: 1.3 Mesa 6.5.1
- 
- results: Section "Device"
-             Identifier "ATI X300"
-             Driver "radeon"
-             #Option "AGPFastWrite" "1"        # NO EFFECT, PCIE
-             #Option "AGPMode"      "8"        # NO EFFECT, PCIE              
-             #Option "DisplayPriority" "HIGH"  # NO EFFECT
-             ...
-          EndSection
-            
-                          ***   +++   ---   ---   ---
-Option "AccelMethod"    | EXA | XAA | EXA | XAA | EXA | XAA | EXA | XAA |
-Option "EnablePageFlip" |  1  |  1  |  0  |  0  |  1  |  1  |  0  |  0  |
-Option "ColorTiling"    |  1  |  1  |  0  |  0  |  0  |  0  |  1  |  1  |
-         FPS  640x480   | 140 | 150 |  81 |  81 |  82 |  86 | 139 | 139 |  
-         FPS  800x600   |  95 | 108 |  53 |  53 |  53 |  57 |  96 |  95 |  
-         FPS 1024x768   |  59 |  68 |  32 |  32 |  32 |  34 |  59 |  59 |   
-
-*** stablest                                 
-+++ fastest
---- slowest
-
-by Paul Heldens, Thu Aug 10 00:55:28 CEST 2006
-}}}
-----
- 
-----
-CategoryTroubleshooting
+
+
+# Instructions
+
+To keep this meaningful: 
+
+* Short test descriptions with full closure on circumstance. 
+* Preferably use existing example tests.  
+* Only submit games that **render as intended** and that do **not crash**. 
+  
+ 
+# Benchmarks
+
+* Quake 3 Arena 
+
+[[!format txt """
+    game: Quake 3 Arena 
+ version: 1.32b
+
+settings: untouched default settings, fullscreen, varying resolutions. 
+    test: in the ingame console (~ key) type:
+          timedemo 1; demo four
+
+  system: P4 2.8GHZ 533MHZ 1GB
+     GPU: PCIE X700LE 128MB 64bit      
+
+  driver: (II) ATI: ATI driver (version 6.6.1) for chipsets: ati, ativga
+          (II) RADEON(0): [dri] Found DRI library version 
+          (II) RADEON(0): [drm] DRM interface version 1.2
+          OpenGL renderer string: Mesa DRI R300 20040924 x86/MMX/SSE2 TCL
+          OpenGL version string: 1.3 Mesa 6.5.1
+ 
+ results: Section "Device"
+             Identifier "ATI X300"
+             Driver "radeon"
+             #Option "AGPFastWrite" "1"        # NO EFFECT, PCIE
+             #Option "AGPMode"      "8"        # NO EFFECT, PCIE              
+             #Option "DisplayPriority" "HIGH"  # NO EFFECT
+             ...
+          EndSection
+            
+                          ***   +++   ---   ---   ---
+Option "AccelMethod"    | EXA | XAA | EXA | XAA | EXA | XAA | EXA | XAA |
+Option "EnablePageFlip" |  1  |  1  |  0  |  0  |  1  |  1  |  0  |  0  |
+Option "ColorTiling"    |  1  |  1  |  0  |  0  |  0  |  0  |  1  |  1  |
+         FPS  640x480   | 140 | 150 |  81 |  81 |  82 |  86 | 139 | 139 |  
+         FPS  800x600   |  95 | 108 |  53 |  53 |  53 |  57 |  96 |  95 |  
+         FPS 1024x768   |  59 |  68 |  32 |  32 |  32 |  34 |  59 |  59 |   
+
+*** stablest                                 
++++ fastest
+--- slowest
+
+by Paul Heldens, Thu Aug 10 00:55:28 CEST 2006
+"""]]
+
+
+---
+
+ 
+
+
+
+---
+
+ [[CategoryTroubleshooting|CategoryTroubleshooting]] 
diff --git a/R300Compiler.moin b/R300Compiler.mdwn
index 1d62bc2..dd12a68 100644
--- a/R300Compiler.moin
+++ b/R300Compiler.mdwn
@@ -1,61 +1,64 @@
-== The R300-R500 shader compiler ==
-
-This document provides some information about the hardware-specific shader compiler for the R300-R500 family of chips. It is used in both the classic Mesa driver and the `r300g` [[Gallium3D]] driver. The source code is located in [[http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/r300/compiler|src/mesa/drivers/dri/r300/compiler]] in the Mesa repository.
-
-The compiler is for R300-R500 only. At some point we might want to investigate if it makes sense to extend it to R600+. Note that the instruction format of R600+ is quite different, so this may or may not make sense.
-
-<<TableOfContents>>
-
-
-=== Building and dependency situation ===
-
-Despite the fact that the source resides inside the `r300` driver directory, the compiler is automatically built for both the classic and the `r300g` driver. For this reason, no code in the compiler may depend on any headers that are part of Mesa or of Gallium3D. All data structures are specific to the compiler. This causes some unfortunate minor code duplication, but it also allows us to be more flexible in changing our data structures.
-
-The compiler is written in plain C99; it uses no additional external libraries (it might use some GNU C extensions; not sure about that).
-
-
-=== High-level role of the shader compiler ===
-
-One core thing to understand about the compiler is that it doesn't actually know about GLSL, or any of the ARB program extensions. There are many different flows of shader program code, and the following list contains only some examples, where (data formats) are in parentheses and [program modules] are in brackets:
- * If you use fixed function OpenGL with the classic Mesa driver: `(OpenGL state) -> [`[[http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/texenvprogram.c|src/mesa/main/texenvprogram.c]]`] -> (gl_program) -> [`[[http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/r300/radeon_mesa_to_rc.c|radeon_mesa_to_rc.c]]`] -> (rc_program) -> [r300/compiler] -> (binary opcodes and register settings)`
- * If you use ARB program extensions with the classic Mesa driver: `(ARB program text) -> [parser] -> (gl_program) -> [radeon_mesa_to_rc.c] -> (rc_program) -> [r300/compiler] -> (binary opcodes and register settings)`
- * If you use GLSL with `r300g`: `(GLSL shader text) -> [slang compiler] -> (gl_program) -> [`[[http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/state_tracker/st_mesa_to_tgsi.c|src/mesa/state_tracker/st_mesa_to_tgsi.c]]`] -> (`[[http://www.freedesktop.org/wiki/Software/gallium?action=AttachFile&do=view&target=tgsi-specification.pdf|TGSI]]`) -> [`[[http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/r300/r300_tgsi_to_rc.c|src/gallium/drivers/r300/r300_tgsi_to_rc.c]]`] -> (rc_program) -> [r300/compiler] -> (binary opcodes and register settings)`
- * If you use some other state tracker with `r300g`, such as `st/xorg`: `[state tracker] -> (TGSI) -> [r300_tgsi_to_rc.c] -> (rc_program) -> [r300/compiler] -> (binary opcodes and register settings)`
-There are some small simplifications here, but this should give you the big picture about what happens to the shader code. Note that the ARB program parser and the GLSL compiler are actually hardware independent; they both reside below the [[http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/shader|src/mesa/shader]] directory in the Mesa repository.
-
-As you can see, shaders are always eventually translated into the `rc_program` format, which is the only format that is ever seen by our shader compiler. The compiler then translates this into a hardware-executable program. Some of the paths shown above may seem a bit convoluted (and they are!), but keep in mind that they are only executed when the shader is first compiled and linked, which usually happens only during application startup. Once your application is running and all shaders are compiled into their binary, hardware-understandable representation, they only need to be loaded into the hardware registers for rendering, and all these long paths disappear entirely.
-
-You should also understand the role of the compiler-produced binary opcodes in relation to the hardware. Rather simplified, the hardware pipeline contains the following steps:
-
-`Vertex Fetch (VF) -> Programmable Vertex Shader (PVS) -> Primitive Assembly (GA) -> Rasterizer (RS) -> Pixel Shader (US) -> Graphics Backend (GB)`
-
-Vertex Fetch loads vertex information and writes into the PVS' Input Vertex Memory (IVM). The PVS runs the vertex shader itself and writes result values into its Output Vertex Memory (OVM). Primitive Assembly pulls vertex data out of the OVM to assemble primitives, clip them, and send appropriate information to the Rasterizer. The Rasterizer determines which pixels (fragments) are covered by primitives. The Rasterizer invokes the Pixel Shader and initializes the Pixel Shader's temporary registers using interpolated `varying` values. The Pixel Shader runs the fragment shader itself and outputs result values to the Graphics Backend, which is responsible for alpha blending, testing, Z buffer, etc.
-
-The binary code which is produced by the compiler configures '''only''' the PVS and US stages. In particular, the compiler does ''not'' decide how input registers and output registers should be laid out, or how the RS should be programmed, etc. This is the job of the rest of the driver, and there may be subtle differences between classic Mesa and `r300g` in that respect.
-
-The compiler provides interfaces with which drivers can communicate how input and output registers should be laid out. Consult [[http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/r300/r300_vs.c|r300_vs.c]] and [[http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/r300/r300_fs.c|r300_fs.c]] for examples of how these interfaces are used.
-
-
-=== How to learn about and hack the compiler ===
-
-One useful tool for learning about the compiler is to set the `RADEON_DEBUG` environment variable to print out intermediate stages of the vertex and fragment programs as they are being compiled. The debug flags for `r300g` are `vp` and `fp` (e.g. set `RADEON_DEBUG=vp`), for classic Mesa they are `verts` and `pixels`. Also, you should obviously learn about how the hardware actually works, referring to [[http://www.x.org/docs/AMD/|AMD's documentation]].
-
-Hacking on the compiler is a rather subtle undertaking, because it's easy to forget about a certain special case or quirk in the hardware, or to miss some subtle invariant about what the intermediate states of programs look like. This can make hacking the compiler seem daunting at first. Unfortunately, the best piece advice that I can give you is: be daring, and use [[http://people.freedesktop.org/~nh/piglit/|piglit]]. That is, after you wrote your first compiler patch and think it's looking good, test it using `piglit`. If your patch does not cause regressions there, there's a pretty good chance that it's correct, and does not break anybody's applications.
-
-
-=== Program representation in the compiler ===
-
-The structures representing programs in the compiler are mostly defined in [[http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/r300/compiler/radeon_program.h|radeon_program.h]], with additional definitions in other headers that you can just browse through in the source. Most important are [[http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/r300/compiler/radeon_program_pair.h|radeon_program_pair.h]] (only relevant for late stage fragment programs) and [[http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/r300/compiler/radeon_opcodes.h|radeon_opcodes.h]].
-
-Programs are represented by an `rc_program` structure, which at the time of this writing consists essentially of a doubly linked list of `rc_instruction`s, and that's really almost all there is to it. You can remove, insert, and modify instructions in a relatively care-free way. Some helper functions are provided, which you should make use of instead of rolling your own (they are not going to be documented here; for these details, the source code is the documentation).
-
-Note that there are some subtle and ill-defined invariants at different stages of the compilation. For example, after the initial stages, programs should be free of opcodes that cannot be implemented directly in the hardware. Use common sense.
-
-Also note that this very free-form program representation makes some operations rather time-consuming. For example, looking for all accesses to a temporary register requires scanning all instructions in the program (there are helper functions for this, too!). The only way to avoid this would be to create additional support structures with corresponding invariants that must be preserved at every modification of the program. Maintaining such invariants creates code that is more difficult to follow, which is why it isn't done yet. However, once we really know which kinds of support structures would be useful to speed up the compiler, it is possible that such structures and corresponding invariants will be introduced in the future.
-
-
-=== Compiler passes ===
-
-In order to make the compiler easier to understand and more maintainable, compilation is broken up into many passes that each do one specific thing. As a general rule of thumb, each pass should go into its own source file, to make the compiler source code more readable and maintainable.
-
-The purpose of each pass ''should'' be described in the source code, and additional high-level information may be put here.
+
+
+## The R300-R500 shader compiler
+
+This document provides some information about the hardware-specific shader compiler for the R300-R500 family of chips. It is used in both the classic Mesa driver and the `r300g` [[Gallium3D|Gallium3D]] driver. The source code is located in [[src/mesa/drivers/dri/r300/compiler|http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/r300/compiler]] in the Mesa repository. 
+
+The compiler is for R300-R500 only. At some point we might want to investigate if it makes sense to extend it to R600+. Note that the instruction format of R600+ is quite different, so this may or may not make sense. 
+
+[[!toc ]] 
+
+
+### Building and dependency situation
+
+Despite the fact that the source resides inside the `r300` driver directory, the compiler is automatically built for both the classic and the `r300g` driver. For this reason, no code in the compiler may depend on any headers that are part of Mesa or of Gallium3D. All data structures are specific to the compiler. This causes some unfortunate minor code duplication, but it also allows us to be more flexible in changing our data structures. 
+
+The compiler is written in plain C99; it uses no additional external libraries (it might use some GNU C extensions; not sure about that). 
+
+
+### High-level role of the shader compiler
+
+One core thing to understand about the compiler is that it doesn't actually know about GLSL, or any of the ARB program extensions. There are many different flows of shader program code, and the following list contains only some examples, where (data formats) are in parentheses and [program modules] are in brackets: 
+
+* If you use fixed function OpenGL with the classic Mesa driver: `(OpenGL state) -> [`[[src/mesa/main/texenvprogram.c|http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/main/texenvprogram.c]]`] -> (gl_program) -> [`[[radeon_mesa_to_rc.c|http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/r300/radeon_mesa_to_rc.c]]`] -> (rc_program) -> [r300/compiler] -> (binary opcodes and register settings)` 
+* If you use ARB program extensions with the classic Mesa driver: `(ARB program text) -> [parser] -> (gl_program) -> [radeon_mesa_to_rc.c] -> (rc_program) -> [r300/compiler] -> (binary opcodes and register settings)` 
+* If you use GLSL with `r300g`: `(GLSL shader text) -> [slang compiler] -> (gl_program) -> [`[[src/mesa/state_tracker/st_mesa_to_tgsi.c|http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/state_tracker/st_mesa_to_tgsi.c]]`] -> (`[[TGSI|http://www.freedesktop.org/wiki/Software/gallium?action=AttachFile&do=view&target=tgsi-specification.pdf]]`) -> [`[[src/gallium/drivers/r300/r300_tgsi_to_rc.c|http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/r300/r300_tgsi_to_rc.c]]`] -> (rc_program) -> [r300/compiler] -> (binary opcodes and register settings)` 
+* If you use some other state tracker with `r300g`, such as `st/xorg`: `[state tracker] -> (TGSI) -> [r300_tgsi_to_rc.c] -> (rc_program) -> [r300/compiler] -> (binary opcodes and register settings)` 
+There are some small simplifications here, but this should give you the big picture about what happens to the shader code. Note that the ARB program parser and the GLSL compiler are actually hardware independent; they both reside below the [[src/mesa/shader|http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/shader]] directory in the Mesa repository. 
+
+As you can see, shaders are always eventually translated into the `rc_program` format, which is the only format that is ever seen by our shader compiler. The compiler then translates this into a hardware-executable program. Some of the paths shown above may seem a bit convoluted (and they are!), but keep in mind that they are only executed when the shader is first compiled and linked, which usually happens only during application startup. Once your application is running and all shaders are compiled into their binary, hardware-understandable representation, they only need to be loaded into the hardware registers for rendering, and all these long paths disappear entirely. 
+
+You should also understand the role of the compiler-produced binary opcodes in relation to the hardware. Rather simplified, the hardware pipeline contains the following steps: 
+
+`Vertex Fetch (VF) -> Programmable Vertex Shader (PVS) -> Primitive Assembly (GA) -> Rasterizer (RS) -> Pixel Shader (US) -> Graphics Backend (GB)` 
+
+Vertex Fetch loads vertex information and writes into the PVS' Input Vertex Memory (IVM). The PVS runs the vertex shader itself and writes result values into its Output Vertex Memory (OVM). Primitive Assembly pulls vertex data out of the OVM to assemble primitives, clip them, and send appropriate information to the Rasterizer. The Rasterizer determines which pixels (fragments) are covered by primitives. The Rasterizer invokes the Pixel Shader and initializes the Pixel Shader's temporary registers using interpolated `varying` values. The Pixel Shader runs the fragment shader itself and outputs result values to the Graphics Backend, which is responsible for alpha blending, testing, Z buffer, etc. 
+
+The binary code which is produced by the compiler configures **only** the PVS and US stages. In particular, the compiler does _not_ decide how input registers and output registers should be laid out, or how the RS should be programmed, etc. This is the job of the rest of the driver, and there may be subtle differences between classic Mesa and `r300g` in that respect. 
+
+The compiler provides interfaces with which drivers can communicate how input and output registers should be laid out. Consult [[r300_vs.c|http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/r300/r300_vs.c]] and [[r300_fs.c|http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/r300/r300_fs.c]] for examples of how these interfaces are used. 
+
+
+### How to learn about and hack the compiler
+
+One useful tool for learning about the compiler is to set the `RADEON_DEBUG` environment variable to print out intermediate stages of the vertex and fragment programs as they are being compiled. The debug flags for `r300g` are `vp` and `fp` (e.g. set `RADEON_DEBUG=vp`), for classic Mesa they are `verts` and `pixels`. Also, you should obviously learn about how the hardware actually works, referring to [[AMD's documentation|http://www.x.org/docs/AMD/]]. 
+
+Hacking on the compiler is a rather subtle undertaking, because it's easy to forget about a certain special case or quirk in the hardware, or to miss some subtle invariant about what the intermediate states of programs look like. This can make hacking the compiler seem daunting at first. Unfortunately, the best piece advice that I can give you is: be daring, and use [[piglit|http://people.freedesktop.org/~nh/piglit/]]. That is, after you wrote your first compiler patch and think it's looking good, test it using `piglit`. If your patch does not cause regressions there, there's a pretty good chance that it's correct, and does not break anybody's applications. 
+
+
+### Program representation in the compiler
+
+The structures representing programs in the compiler are mostly defined in [[radeon_program.h|http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/r300/compiler/radeon_program.h]], with additional definitions in other headers that you can just browse through in the source. Most important are [[radeon_program_pair.h|http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/r300/compiler/radeon_program_pair.h]] (only relevant for late stage fragment programs) and [[radeon_opcodes.h|http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/r300/compiler/radeon_opcodes.h]]. 
+
+Programs are represented by an `rc_program` structure, which at the time of this writing consists essentially of a doubly linked list of `rc_instruction`s, and that's really almost all there is to it. You can remove, insert, and modify instructions in a relatively care-free way. Some helper functions are provided, which you should make use of instead of rolling your own (they are not going to be documented here; for these details, the source code is the documentation). 
+
+Note that there are some subtle and ill-defined invariants at different stages of the compilation. For example, after the initial stages, programs should be free of opcodes that cannot be implemented directly in the hardware. Use common sense. 
+
+Also note that this very free-form program representation makes some operations rather time-consuming. For example, looking for all accesses to a temporary register requires scanning all instructions in the program (there are helper functions for this, too!). The only way to avoid this would be to create additional support structures with corresponding invariants that must be preserved at every modification of the program. Maintaining such invariants creates code that is more difficult to follow, which is why it isn't done yet. However, once we really know which kinds of support structures would be useful to speed up the compiler, it is possible that such structures and corresponding invariants will be introduced in the future. 
+
+
+### Compiler passes
+
+In order to make the compiler easier to understand and more maintainable, compilation is broken up into many passes that each do one specific thing. As a general rule of thumb, each pass should go into its own source file, to make the compiler source code more readable and maintainable. 
+
+The purpose of each pass _should_ be described in the source code, and additional high-level information may be put here. 
diff --git a/R300FragmentProgramOptimization.moin b/R300FragmentProgramOptimization.mdwn
index f2d24d3..192e283 100644
--- a/R300FragmentProgramOptimization.moin
+++ b/R300FragmentProgramOptimization.mdwn
@@ -1,62 +1,68 @@
-= Optimization for  r300/r400 fragment shader program =
-We want few things, this stuff should be done in gallium. This could be done using the software rendering pipe so debugging is easier and there is no r300/r400 gallium driver yet. For shake of simplicity we will use the ARB fragment & vertex shader extension as we expect the higher level like glsl will be optimized in a first pass by things like llvm. We are focusing on optimizing a bit more the "ASM" we got as output of such stage. Also we don't want that one pass of optimization destroy the work done by another. To solve this i think that trying each permutation of optimization stage and selecting the one producing the slower number of instruction and fitting hardware is the best solution to keep things clean and simple.
-== Reshuffle texture instruction ==
-To work around the 4 textures indirection limit we need to reshuffle texture instructions. For instance the following program can be rewritten.
-
-Original which don't pass texture indirection limits (here 5 indirections):
-
-{{{
-TEMP a, b, c, d;
-// node 0 - 0 indirection
-TEX a, fragment.color, texture[0], 2D;
-// node 1 - 1 indirection
-TEX b, a, texture[1], 2D;
-ADD c, b, 1;
-MUL b, c, b;
-// node 2 - 2 indirection because c have been written in previous node
-TEX c, fragment.color, texture[2], 2D;
-// node 3 - 3 indirection c have been written in previous node
-TEX d, c, texture[3], 2D;
-ADD a, b, d;
-// node 4 (out of limit !) - a have been written in previous node
-TEX result.color, a, texture[4], 2D;
-}}}
-
-Reshuffled program which pass texture indirection limits (here 3 indirections):
-{{{
-TEMP a, b, c, d;
-TEMP _ts_0;
-// node 0 - 0 indirection
-TEX a, fragment.color, texture[0], 2D;
-TEX c, fragment.color, texture[2], 2D;
-// node 1 - 1 indirection
-TEX b, a, texture[1], 2D;
-TEX d, c, texture[3], 2D;
-ADD _ts_0, b, 1;
-MUL b, _ts_0, b;
-ADD a, b, d;
-// node 2 - 2 indirection a have been written in previous node
-TEX result.color, a, texture[4], 2D;
-}}}
-== Use native swizzle ==
-Please refer to doc to find native swizzle for r300/r400 hw. We want to rewritte asm to take advantage of native swizzle. This stage could be mixed with the scalar/vector optimization pass.
-
-Following program can be optimize (assuming xyzw & wzyx & wyxz are native but xzwy isn't):
-{{{
-TEMP a, b;
-PARAM coef = {0.5f, 0.6f, 0.7f, 0.8f};
-ADD a, fragment.color.xzwy, coef.wyxz;
-}}}
-
-To:
-{{{
-TEMP a, b;
-PARAM coef = {0.5f, 0.6f, 0.7f, 0.8f};
-ADD a, fragment.color.wzyx, coef.xyzw;
-}}}
-
-Well optimization here can be more complexe if we add negation on individual component in the equation.
-== Reshuffle instruction ==
-By reshuffling instruction you could take advantage of this scalar/vector split in unit to parallelize computation a bit more.
-== References ==
-http://www.opengl.org/registry/specs/ARB/fragment_program.txt
+
+
+# Optimization for  r300/r400 fragment shader program
+
+We want few things, this stuff should be done in gallium. This could be done using the software rendering pipe so debugging is easier and there is no r300/r400 gallium driver yet. For shake of simplicity we will use the ARB fragment & vertex shader extension as we expect the higher level like glsl will be optimized in a first pass by things like llvm. We are focusing on optimizing a bit more the "ASM" we got as output of such stage. Also we don't want that one pass of optimization destroy the work done by another. To solve this i think that trying each permutation of optimization stage and selecting the one producing the slower number of instruction and fitting hardware is the best solution to keep things clean and simple. 
+## Reshuffle texture instruction
+
+To work around the 4 textures indirection limit we need to reshuffle texture instructions. For instance the following program can be rewritten. 
+
+Original which don't pass texture indirection limits (here 5 indirections): 
+
+
+[[!format txt """
+TEMP a, b, c, d;
+// node 0 - 0 indirection
+TEX a, fragment.color, texture[0], 2D;
+// node 1 - 1 indirection
+TEX b, a, texture[1], 2D;
+ADD c, b, 1;
+MUL b, c, b;
+// node 2 - 2 indirection because c have been written in previous node
+TEX c, fragment.color, texture[2], 2D;
+// node 3 - 3 indirection c have been written in previous node
+TEX d, c, texture[3], 2D;
+ADD a, b, d;
+// node 4 (out of limit !) - a have been written in previous node
+TEX result.color, a, texture[4], 2D;
+"""]]
+Reshuffled program which pass texture indirection limits (here 3 indirections): 
+[[!format txt """
+TEMP a, b, c, d;
+TEMP _ts_0;
+// node 0 - 0 indirection
+TEX a, fragment.color, texture[0], 2D;
+TEX c, fragment.color, texture[2], 2D;
+// node 1 - 1 indirection
+TEX b, a, texture[1], 2D;
+TEX d, c, texture[3], 2D;
+ADD _ts_0, b, 1;
+MUL b, _ts_0, b;
+ADD a, b, d;
+// node 2 - 2 indirection a have been written in previous node
+TEX result.color, a, texture[4], 2D;
+"""]]
+
+## Use native swizzle
+
+Please refer to doc to find native swizzle for r300/r400 hw. We want to rewritte asm to take advantage of native swizzle. This stage could be mixed with the scalar/vector optimization pass. 
+
+Following program can be optimize (assuming xyzw & wzyx & wyxz are native but xzwy isn't): 
+[[!format txt """
+TEMP a, b;
+PARAM coef = {0.5f, 0.6f, 0.7f, 0.8f};
+ADD a, fragment.color.xzwy, coef.wyxz;
+"""]]
+To: 
+[[!format txt """
+TEMP a, b;
+PARAM coef = {0.5f, 0.6f, 0.7f, 0.8f};
+ADD a, fragment.color.wzyx, coef.xyzw;
+"""]]
+Well optimization here can be more complexe if we add negation on individual component in the equation. 
+## Reshuffle instruction
+
+By reshuffling instruction you could take advantage of this scalar/vector split in unit to parallelize computation a bit more. 
+## References
+
+[[http://www.opengl.org/registry/specs/ARB/fragment_program.txt|http://www.opengl.org/registry/specs/ARB/fragment_program.txt]] 
diff --git a/R300Textures.moin b/R300Textures.mdwn
index 7aa8d19..abacb25 100644
--- a/R300Textures.moin
+++ b/R300Textures.mdwn
@@ -1,57 +1,71 @@
-So, here's the information about Radeon r300-r500 texture layouts. Note that pitch is in texels, and stride is in bytes.
-
-== Colorbuffers ==
-
-=== Alignment ===
-
-Base offsets are 32-byte (256-bit) aligned. Pitch is at least 2 pixels.
-
-=== Limits ===
-
-Colorbuffers can be up to 4021x4021 pixels in 1/12 subpixel mode on r3xx/r4xx chips and 4096x4096 pixels on r5xx chips.
-
-== Textures ==
-
-=== Alignment ===
-
-Base offsets are 4-byte (32-bit) aligned. Strides are always at least 32 bytes. For RS690, things are slightly different; strides are always at least 64 bytes.
-
-=== Limits ===
-
-Textures can be up to 2048x2048x2048 texels in size. On R500 chipsets, textures can be up to 4096x4096x4096 texels in size.
-
-=== Additional levels ===
-
-Additional levels are packed directly after the first level, largest to smallest.
-
-Levels are always minified (reduced to the next smallest POT) in all dimensions as they get smaller.
-
-Level base offsets are 32-byte aligned and are not adjustable (that is, the hardware computes them automatically on the fly, and there is no way to configure level base offsets).
-
-=== 1D textures ===
-
-Nothing special.
-
-=== 2D textures ===
-
-Nothing special.
-
-=== 3D textures ===
-
-No idea.
-
-=== Cubemaps ===
-
-Within each mip level, the images corresponding to the faces are stored in the order of the corresponding OpenGL #defines, i.e. in the order (+X, -X, +Y, -Y, +Z, -Z).
-
-Images are stored consecutively, the only padding is for alignment. Alignment is as for all texture images (that is, 32 bytes).
-
-=== Width vs. Pitch ===
-
-Always use pitch instead of width for addressing. It's the only way to do rectangular and NPOT textures.
-
-Width still needs to be set, of course.
-
-=== Tiling ===
-
-Documenting this is a big TODO
+
+So, here's the information about Radeon r300-r500 texture layouts. Note that pitch is in texels, and stride is in bytes. 
+
+
+## Colorbuffers
+
+
+### Alignment
+
+Base offsets are 32-byte (256-bit) aligned. Pitch is at least 2 pixels. 
+
+
+### Limits
+
+Colorbuffers can be up to 4021x4021 pixels in 1/12 subpixel mode on r3xx/r4xx chips and 4096x4096 pixels on r5xx chips. 
+
+
+## Textures
+
+
+### Alignment
+
+Base offsets are 4-byte (32-bit) aligned. Strides are always at least 32 bytes. For RS690, things are slightly different; strides are always at least 64 bytes. 
+
+
+### Limits
+
+Textures can be up to 2048x2048x2048 texels in size. On R500 chipsets, textures can be up to 4096x4096x4096 texels in size. 
+
+
+### Additional levels
+
+Additional levels are packed directly after the first level, largest to smallest. 
+
+Levels are always minified (reduced to the next smallest POT) in all dimensions as they get smaller. 
+
+Level base offsets are 32-byte aligned and are not adjustable (that is, the hardware computes them automatically on the fly, and there is no way to configure level base offsets). 
+
+
+### 1D textures
+
+Nothing special. 
+
+
+### 2D textures
+
+Nothing special. 
+
+
+### 3D textures
+
+No idea. 
+
+
+### Cubemaps
+
+Within each mip level, the images corresponding to the faces are stored in the order of the corresponding OpenGL #defines, i.e. in the order (+X, -X, +Y, -Y, +Z, -Z). 
+
+Images are stored consecutively, the only padding is for alignment. Alignment is as for all texture images (that is, 32 bytes). 
+
+
+### Width vs. Pitch
+
+Always use pitch instead of width for addressing. It's the only way to do rectangular and NPOT textures. 
+
+Width still needs to be set, of course. 
+
+
+### Tiling
+
+Documenting this is a big TODO 
diff --git a/R300ToDo.mdwn b/R300ToDo.mdwn
new file mode 100644
index 0000000..7029e35
--- /dev/null
+++ b/R300ToDo.mdwn
@@ -0,0 +1,115 @@
+
+
+# R300 To Do list
+
+And here is the R300 to do list (at the end of this page); if you feel something is missing please add it. If you have done something and it no longer needs to be investigated, happily erase it from here :). 
+
+
+## Hardware limitations
+
+Should this be its own page? Probably not. 
+
+Some of these are errata, some aren't. You can't work around them in hardware, though. 
+
+   * Vertex shader limits [[!table header="no" class="mointable" data="""
+              | **<small>ALU</small>** | **<small>Const</small>** | **<small>Temp</small>** | **<small>Alt.Temp</small>**
+**<small>R300</small>** |  256      |  256        |  32        |  20 
+**<small>R400</small>** |  256      |  256        |  32        |  20 
+**<small>R500</small>** |  1024     |  256        |  32        |  20 
+"""]]
+
+   * Fragment shader limits [[!table header="no" class="mointable" data="""
+              | **<small>ALU</small>** | **<small>TEX</small>** | **<small>Const</small>** | **<small>Temp</small>** | **<small>Samplers</small>** | **<small>TEX Indirections</small>**
+**<small>R300</small>** |  64       |  32       |  32         |  32        |  16            |  4 
+**<small>R400</small>** |  512      |  512      |  32         |  64        |  16            |  4 
+**<small>R500</small>** |  512      |  512      |  256        |  128       |  16            |  Unlimited 
+"""]]
+
+   * Shader opcodes (unlisted opcodes are not supported) [[!table header="no" class="mointable" data="""
+      | **<small>R300 VS</small>** | **<small>R500 VS</small>** | **<small>R300 FS</small>** | **<small>R500 FS</small>**
+**<small>ABS </small>** |           |  (./)  |  (./)  |  (./)  |  Source operand modifier 
+**<small>ADD </small>** |  (./)  |  (./)  |           |          
+**<small>ARL </small>** |  (./)  |  (./)  |           |          
+**<small>ARR </small>** |  (./)  |  (./)  |           |          
+**<small>CND </small>** |           |           |  (./)  |  (./)  |  src0 > 0.5 ? src1 : src2  |  can be used for e.g. src0 ? src1 : src2 
+**<small>CMP </small>** |           |           |  (./)  |  (./)  |  src0 < 0.0 ? src1 : src2 
+**<small>COS </small>** |           |  (./)  |           |  (./) 
+**<small>DDX </small>** |           |           |           |  (./) 
+**<small>DDY </small>** |           |           |           |  (./) 
+**<small>DP2A</small>** |           |           |  (./)  |  (./) 
+**<small>DP3 </small>** |           |           |  (./)  |  (./) 
+**<small>DP4 </small>** |  (./)  |  (./)  |  (./)  |  (./) 
+**<small>DST </small>** |  (./)  |  (./)  |           |          
+**<small>EX2 </small>** |  (./)  |  (./)  |  (./)  |  (./) 
+**<small>EXP </small>** |  (./)  |  (./)  |           |          
+**<small>FRC </small>** |  (./)  |  (./)  |  (./)  |  (./) 
+**<small>KIL </small>** |           |           |  (./)  |  (./) 
+**<small>LG2 </small>** |  (./)  |  (./)  |  (./)  |  (./) 
+**<small>LIT </small>** |  (./)  |  (./)  |           |          
+**<small>LOG </small>** |  (./)  |  (./)  |           |          
+**<small>MAD </small>** |  (./)  |  (./)  |  (./)  |  (./) 
+**<small>MAX </small>** |  (./)  |  (./)  |  (./)  |  (./) 
+**<small>MIN </small>** |  (./)  |  (./)  |  (./)  |  (./) 
+**<small>MUL </small>** |  (./)  |  (./)  |           |          
+**<small>POW </small>** |  (./)  |  (./)  |           |          
+**<small>RCP </small>** |  (./)  |  (./)  |  (./)  |  (./) 
+**<small>RSQ </small>** |  (./)  |  (./)  |  (./)  |  (./) 
+**<small>SEQ </small>** |           |  (./)  |           |          
+**<small>SGE </small>** |  (./)  |  (./)  |           |          
+**<small>SGT </small>** |           |  (./)  |           |          
+**<small>SIN </small>** |           |  (./)  |           |  (./) 
+**<small>SLT </small>** |  (./)  |  (./)  |           |          
+**<small>SNE </small>** |           |  (./)  |           |          
+**<small>*_SAT</small>** |           |  (./)  |  (./)  |  (./)  |  Instruction modififer 
+**<small>TEX </small>** |           |           |  (./)  |  (./) 
+**<small>TXB </small>** |           |           |  (./)  |  (./) 
+**<small>TXD </small>** |           |           |           |  (./) 
+**<small>TXL </small>** |           |           |           |  (./) 
+**<small>TXP </small>** |           |           |  (./)  |  (./) 
+**<small>IF  </small>** |           |  (./)  |           |  (./) 
+**<small>ELSE </small>** |           |  (./)  |           |  (./) 
+**<small>ENDIF</small>** |           |  (./)  |           |  (./) 
+**<small>BGNLOOP</small>** |  (./)  |  (./)  |           |  (./)  |  There are a lot of restrictions on loops. 
+**<small>BRK </small>** |           |  (./)  |           |  (./) 
+**<small>CONT </small>** |           |           |           |  (./) 
+**<small>ENDLOOP</small>** |  (./)  |  (./)  |           |  (./) 
+"""]]
+
+   * Geometry 
+      * Vertex formats GL_*INT and GL_DOUBLE are not supported. GL_*SHORT is supported only for 2- and 4-component vertex attributes, and GL_*BYTE only for 4-component attributes. All individual vertex attribute fetches must be DWORD-aligned. 
+      * Quads and quadstrips cannot have the first vertex be the provoking vertex. 
+   * Rasterizer 
+      * The interpolated colors have a range of [0, 1] and are limited to 12 bits of precision. Unlike texture coordinates, when multisampling is enabled, the colors are sampled at the centroid of the covered portion of the fragment. With PS3 mode enabled (GUESS), the interpolated colors have 32 bits of precision. 
+   * Textures 
+      * Floating-point mipmap LOD clamping is not supported. Min LOD is floor'd and max LOD is ceil'd. 
+      * NPOT textures are not available, just rectangle textures (with possibility of normalized texture coordinates and bilinear filtering). 
+      * Floating-point textures cannot be filtered, the only allowed filter modes are GL_NEAREST and GL_NEAREST_MIPMAP_NEAREST. 
+      * Floating-point textures cannot be used with the wrap modes GL_CLAMP and GL_CLAMP_TO_BORDER, except for R500, which does support these modes. 
+      * 16-bits-per-channel textures cannot be used with the wrap modes GL_CLAMP and GL_CLAMP_TO_BORDER. 
+   * Vertex shader 
+      * Vertex shaders evaluate 0^0 as NaN. 
+   * Fragment shader 
+      * Fragment derivatives are calculated at half resolution. 
+      * R300 fragment shaders evaluate 0^0 as NaN. 
+   * Color buffers 
+      * R300 maximum color buffer size is 2560x2560. R400 maximum color buffer size is 4021x4021. R500 maximum color buffer size is 4096x4096 
+      * R300-R400 cannot do blending, alpha-testing, and multisampling with floating-point colorbuffers. R500 can do these only for GL_RGBA16F. 
+
+## Gallium3D Driver
+
+This is a TODO list for r300g. 
+
+* Driver enhancements 
+   * Add support for the centroid GLSL varying modifier (undocumented in the hw docs). 
+   * Add texture-stuffing-based things: smoothed points + lines + polygons, and stippled lines + polygons. This needs changes in the rasterizer, the RS block, and the fragment shading. 
+   * Enable Hyper-Z by default on r3xx/r4xx (needs additional testing). 
+   * Enable MSAA by default on r3xx/r4xx (needs additional testing). 
+* Compiler enhancements 
+   * Improve the VS register allocator to be more useful with ifs and loops (We should be able to reuse most of the FS register allocator for this). 
+   * VS: Implement Dual-Op Vector/Math (4D+1D) instruction pair scheduling. Performance++. 
+* State tracker enhancements 
+   * Implement accelerated pixel buffer objects (we can do the aligned copies at least). 
+   * Implement accelerated [[CopyBufferSubData|CopyBufferSubData]]. 
+* Bugs 
+   * [[Open bugs for Mesa:Drivers/Gallium/r300|https://bugs.freedesktop.org/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=Drivers%2FGallium%2Fr300&product=Mesa&order=bug_id%20DESC]] 
+   * Fix piglit tests. 
+\ No newline at end of file
diff --git a/R300ToDo.moin b/R300ToDo.moin
deleted file mode 100644
index 2d1eaa8..0000000
--- a/R300ToDo.moin
+++ /dev/null
@@ -1,109 +0,0 @@
-= R300 To Do list =
-
-And here is the R300 to do list (at the end of this page); if you feel something is missing please add it.
-If you have done something and it no longer needs to be investigated, happily erase it from here :).
-
-== Hardware limitations ==
-
-Should this be its own page? Probably not.
-
-Some of these are errata, some aren't. You can't work around them in hardware, though.
-
-  * Vertex shader limits
-  ||             ||<:>'''~-ALU-~'''||<:>'''~-Const-~'''||<:>'''~-Temp-~'''||<:>'''~-Alt.Temp-~'''||
-  ||<:>'''~-R300-~'''||<)> 256     ||<)> 256       ||<)> 32       ||<)> 20 ||
-  ||<:>'''~-R400-~'''||<)> 256     ||<)> 256       ||<)> 32       ||<)> 20 ||
-  ||<:>'''~-R500-~'''||<)> 1024    ||<)> 256       ||<)> 32       ||<)> 20 ||
-  * Fragment shader limits
-  ||             ||<:>'''~-ALU-~'''||<:>'''~-TEX-~'''||<:>'''~-Const-~'''||<:>'''~-Temp-~'''||<:>'''~-Samplers-~'''||<:>'''~-TEX Indirections-~'''||
-  ||<:>'''~-R300-~'''||<)> 64      ||<)> 32      ||<)> 32        ||<)> 32       ||<)> 16           ||<)> 4 ||
-  ||<:>'''~-R400-~'''||<)> 512     ||<)> 512     ||<)> 32        ||<)> 64       ||<)> 16           ||<)> 4 ||
-  ||<:>'''~-R500-~'''||<)> 512     ||<)> 512     ||<)> 256       ||<)> 128      ||<)> 16           ||<)> Unlimited ||
-  * Shader opcodes (unlisted opcodes are not supported)
-  ||     ||<:>'''~-R300 VS-~'''||<:>'''~-R500 VS-~'''||<:>'''~-R300 FS-~'''||<:>'''~-R500 FS-~'''||
-  ||<:>'''~- ABS -~'''||         ||<:> (./) ||<:> (./) ||<:> (./) || Source operand modifier ||
-  ||<:>'''~- ADD -~'''||<:> (./) ||<:> (./) ||         ||         ||
-  ||<:>'''~- ARL -~'''||<:> (./) ||<:> (./) ||         ||         ||
-  ||<:>'''~- ARR -~'''||<:> (./) ||<:> (./) ||         ||         ||
-  ||<:>'''~- CND -~'''||         ||         ||<:> (./) ||<:> (./) || src0 > 0.5 ? src1 : src2 || can be used for e.g. src0 ? src1 : src2 ||
-  ||<:>'''~- CMP -~'''||         ||         ||<:> (./) ||<:> (./) || src0 < 0.0 ? src1 : src2 ||
-  ||<:>'''~- COS -~'''||         ||<:> (./) ||         ||<:> (./) ||
-  ||<:>'''~- DDX -~'''||         ||         ||         ||<:> (./) ||
-  ||<:>'''~- DDY -~'''||         ||         ||         ||<:> (./) ||
-  ||<:>'''~- DP2A-~'''||         ||         ||<:> (./) ||<:> (./) ||
-  ||<:>'''~- DP3 -~'''||         ||         ||<:> (./) ||<:> (./) ||
-  ||<:>'''~- DP4 -~'''||<:> (./) ||<:> (./) ||<:> (./) ||<:> (./) ||
-  ||<:>'''~- DST -~'''||<:> (./) ||<:> (./) ||         ||         ||
-  ||<:>'''~- EX2 -~'''||<:> (./) ||<:> (./) ||<:> (./) ||<:> (./) ||
-  ||<:>'''~- EXP -~'''||<:> (./) ||<:> (./) ||         ||         ||
-  ||<:>'''~- FRC -~'''||<:> (./) ||<:> (./) ||<:> (./) ||<:> (./) ||
-  ||<:>'''~- KIL -~'''||         ||         ||<:> (./) ||<:> (./) ||
-  ||<:>'''~- LG2 -~'''||<:> (./) ||<:> (./) ||<:> (./) ||<:> (./) ||
-  ||<:>'''~- LIT -~'''||<:> (./) ||<:> (./) ||         ||         ||
-  ||<:>'''~- LOG -~'''||<:> (./) ||<:> (./) ||         ||         ||
-  ||<:>'''~- MAD -~'''||<:> (./) ||<:> (./) ||<:> (./) ||<:> (./) ||
-  ||<:>'''~- MAX -~'''||<:> (./) ||<:> (./) ||<:> (./) ||<:> (./) ||
-  ||<:>'''~- MIN -~'''||<:> (./) ||<:> (./) ||<:> (./) ||<:> (./) ||
-  ||<:>'''~- MUL -~'''||<:> (./) ||<:> (./) ||         ||         ||
-  ||<:>'''~- POW -~'''||<:> (./) ||<:> (./) ||         ||         ||
-  ||<:>'''~- RCP -~'''||<:> (./) ||<:> (./) ||<:> (./) ||<:> (./) ||
-  ||<:>'''~- RSQ -~'''||<:> (./) ||<:> (./) ||<:> (./) ||<:> (./) ||
-  ||<:>'''~- SEQ -~'''||         ||<:> (./) ||         ||         ||
-  ||<:>'''~- SGE -~'''||<:> (./) ||<:> (./) ||         ||         ||
-  ||<:>'''~- SGT -~'''||         ||<:> (./) ||         ||         ||
-  ||<:>'''~- SIN -~'''||         ||<:> (./) ||         ||<:> (./) ||
-  ||<:>'''~- SLT -~'''||<:> (./) ||<:> (./) ||         ||         ||
-  ||<:>'''~- SNE -~'''||         ||<:> (./) ||         ||         ||
-  ||<:>'''~-*_SAT-~'''||         ||<:> (./) ||<:> (./) ||<:> (./) || Instruction modififer ||
-  ||<:>'''~- TEX -~'''||         ||         ||<:> (./) ||<:> (./) ||
-  ||<:>'''~- TXB -~'''||         ||         ||<:> (./) ||<:> (./) ||
-  ||<:>'''~- TXD -~'''||         ||         ||         ||<:> (./) ||
-  ||<:>'''~- TXL -~'''||         ||         ||         ||<:> (./) ||
-  ||<:>'''~- TXP -~'''||         ||         ||<:> (./) ||<:> (./) ||
-  ||<:>'''~- IF  -~'''||         ||<:> (./) ||         ||<:> (./) ||
-  ||<:>'''~-ELSE -~'''||         ||<:> (./) ||         ||<:> (./) ||
-  ||<:>'''~-ENDIF-~'''||         ||<:> (./) ||         ||<:> (./) ||
-  ||<:>'''~-BGNLOOP-~'''||<:> (./) ||<:> (./) ||         ||<:> (./) || There are a lot of restrictions on loops. ||
-  ||<:>'''~- BRK -~'''||         ||<:> (./) ||         ||<:> (./) ||
-  ||<:>'''~-CONT -~'''||         ||         ||         ||<:> (./) ||
-  ||<:>'''~-ENDLOOP-~'''||<:> (./) ||<:> (./) ||         ||<:> (./) ||
-
-  * Geometry
-   * Vertex formats GL_*INT and GL_DOUBLE are not supported. GL_*SHORT is supported only for 2- and 4-component vertex attributes, and GL_*BYTE only for 4-component attributes. All individual vertex attribute fetches must be DWORD-aligned.
-   * Quads and quadstrips cannot have the first vertex be the provoking vertex.
-  * Rasterizer
-   * The interpolated colors have a range of [0, 1] and are limited to 12 bits of precision. Unlike texture coordinates, when multisampling is enabled, the colors are sampled at the centroid of the covered portion of the fragment. With PS3 mode enabled (GUESS), the interpolated colors have 32 bits of precision.
-  * Textures
-   * Floating-point mipmap LOD clamping is not supported. Min LOD is floor'd and max LOD is ceil'd.
-   * NPOT textures are not available, just rectangle textures (with possibility of normalized texture coordinates and bilinear filtering).
-   * Floating-point textures cannot be filtered, the only allowed filter modes are GL_NEAREST and GL_NEAREST_MIPMAP_NEAREST.
-   * Floating-point textures cannot be used with the wrap modes GL_CLAMP and GL_CLAMP_TO_BORDER, except for R500, which does support these modes.
-   * 16-bits-per-channel textures cannot be used with the wrap modes GL_CLAMP and GL_CLAMP_TO_BORDER.
-  * Vertex shader
-   * Vertex shaders evaluate 0^0 as NaN.
-  * Fragment shader
-   * Fragment derivatives are calculated at half resolution.
-   * R300 fragment shaders evaluate 0^0 as NaN.
-  * Color buffers
-   * R300 maximum color buffer size is 2560x2560. R400 maximum color buffer size is 4021x4021. R500 maximum color buffer size is 4096x4096
-   * R300-R400 cannot do blending, alpha-testing, and multisampling with floating-point colorbuffers. R500 can do these only for GL_RGBA16F.
-
-
-== Gallium3D Driver ==
-
-This is a TODO list for r300g.
-
- * Driver enhancements
-  * Add support for the centroid GLSL varying modifier (undocumented in the hw docs).
-  * Add texture-stuffing-based things: smoothed points + lines + polygons, and stippled lines + polygons. This needs changes in the rasterizer, the RS block, and the fragment shading.
-  * Enable Hyper-Z by default on r3xx/r4xx (needs additional testing).
-  * Enable MSAA by default on r3xx/r4xx (needs additional testing).
- * Compiler enhancements
-  * Improve the VS register allocator to be more useful with ifs and loops (We should be able to reuse most of the FS register allocator for this).
-  * VS: Implement Dual-Op Vector/Math (4D+1D) instruction pair scheduling. Performance++.
- * State tracker enhancements
-  * Implement accelerated pixel buffer objects (we can do the aligned copies at least).
-  * Implement accelerated CopyBufferSubData.
- * Bugs
-  * [[https://bugs.freedesktop.org/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=Drivers%2FGallium%2Fr300&product=Mesa&order=bug_id%20DESC|Open bugs for Mesa:Drivers/Gallium/r300]]
-  * Fix piglit tests.
diff --git a/R300_Portal.mdwn b/R300_Portal.mdwn
new file mode 100644
index 0000000..0575f82
--- /dev/null
+++ b/R300_Portal.mdwn
@@ -0,0 +1,21 @@
+
+
+# Deprecation warning
+
+This page is deprecated / obsolete and exists only for historical reasons. It should be removed entirely eventually. 
+
+Go to [[Radeon|Radeon]] instead.  
+
+
+# local
+
+* [[Supported chips|ATIRadeon]] 
+* [[Obtaining and building snapshots of the drivers|Building]] 
+* [[Runtime Configuration|ATIRadeon]] (Driver settings) 
+* [[Application List|R300Application]] (List of application or games behaviour) 
+* [[Benchmark Results|R300Benchmark]] (Performance tests) 
+
+# external
+
+* [[http://megahurts.dk/rune/r300_status.html|http://megahurts.dk/rune/r300_status.html]] 
+* [[RadeonProgram @ Xorg wiki|http://xorg.freedesktop.org/wiki/RadeonProgram]] 
+\ No newline at end of file
diff --git a/R300_Portal.moin b/R300_Portal.moin
deleted file mode 100644
index 34bfbfe..0000000
--- a/R300_Portal.moin
+++ /dev/null
@@ -1,18 +0,0 @@
-= Deprecation warning =
-
-This page is deprecated / obsolete and exists only for historical reasons. It should be removed entirely eventually.
-
-Go to [[Radeon]] instead. 
-
-
-= local =
- * [[ATIRadeon|Supported chips]]
- * [[Building|Obtaining and building snapshots of the drivers]]
- * [[ATIRadeon#head-8851142da56fd885ce668a165b33fee7003e858d|Runtime Configuration]] (Driver settings)
- * [[R300Application|Application List]] (List of application or games behaviour)
- * [[R300Benchmark|Benchmark Results]] (Performance tests)
-
-= external =
-
- * http://megahurts.dk/rune/r300_status.html
- * [[http://xorg.freedesktop.org/wiki/RadeonProgram|RadeonProgram @ Xorg wiki]]
diff --git a/R600ToDo.mdwn b/R600ToDo.mdwn
new file mode 100644
index 0000000..8a575c5
--- /dev/null
+++ b/R600ToDo.mdwn
@@ -0,0 +1,132 @@
+
+[[!toc ]] 
+
+
+## R600 To Do list
+
+And here is the R600g to do list; if you feel something is missing please add it. If you have done something and it no longer needs to be investigated, happily erase it from here :). 
+
+
+### LLVM
+
+* **Testing on R600, R700 and Cayman GPUs** 
+   * _Difficulty:_ Easy 
+   * _Who's working on it:_ 
+   * _Date Started:_ 
+   * _Status:_ 
+   * _Description:_ 
+   * Most of the LLVM backend testing has been with Evergreen or Northern Islands GPUs.  R600, R700, and Cayman GPUs are slightly different, so there may be bugs on these GPUs that aren't present on Evergeen/Northern Islands.  The best method for testing is to compare piglit results with and without the LLVM backend and report the regressions.  For easy switching between the two compilers, compile mesa with --enable-r600-llvm-compiler.  This will make the LLVM backend the default compiler, and you can switch back to the old compiler by using the R600_LLVM=0 environment variable. 
+   * It would also be interesting to see if there are any performance gains from using the LLVM backend, so a related task would be to compare the performance of your favorite programs with and without the LLVM backend and then report any discrepancies. 
+* **Remove target specific intrinsics** 
+   * _Difficulty:_ Easy 
+   * _Who's working on it:_ N/A 
+   * _Date Started:_ N/A 
+   * _Status:_ N/A 
+   * _Description:_ 
+   * The code in gallium/drivers/radeon/radeon_setup_tgsi.c uses a lot of target specific intrinsics for translating from TGSI to LLVM.  Most of these are unnecessary and should be replaced with LLVM IR or LLVM intrinsics. 
+* **Add support for 4 x i8 stores** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_ N/A 
+   * _Date Started:_ N/A 
+   * _Status:_ N/A 
+   * _Description:_ 
+   * We may be able to implement this by using a 32-bit store instructions and having the vector packed into a single 32-bit register.  I think LLVM may be able to do this for us, but we need to tell it that that some i8 operations are illegal. 
+* **Use LLVM analysis passes to clear the Barrier bit on Control Flow instructions** 
+   * _Difficulty:_ Hard 
+   * _Who's working on it:_ N/A 
+   * _Date Started: _N/A 
+   * _Status:_ N/A 
+   * _Description:_ 
+   * Clearing the Barrier bit on Control Flow instructions allows them to execute in parallel, which can improve performance.  We can use the LLVM analysis passes to determine when it is safe to clear this bit.  This task will also require some changes to the way code is generated by the backend, because we don't currently have much control over Control Flow instructions from inside the backend. 
+
+### Compute
+
+* **Store Kernel Parameters in Constant Registers ** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_ N/A 
+   * _Date Started: _N/A 
+   * _Status:_ N/A 
+   * _Description:_ 
+   * Kernel parameters are currently being stored in vertex buffers, which are slower to access than the constant registers.  To complete this task a developer would need to: 
+      1. Modify evergreen_compute_upload_input() in evergreen_compute.c to upload inputs to constant registers. 
+      1. Change the custom lowering for implicit parameters in R600ISelLowering to use constant registers instead of VTX_READS 
+      1. Have [[R600KernelParameters|R600KernelParameters]].cpp load parameters from the constant address space. 
+      1. Lower loads from the constant address space to constant register reads. 
+   * For this task, it might be good to start by doing step 1 for only the implicit parameters, and then completing step 2. 
+* **Enable constant address space ** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_ N/A 
+   * _Date Started: _N/A 
+   * _Status:_ N/A 
+   * _Description:_ 
+   * Clover currently uses the global address space for all memory even constant memory, which is not optimal from a performance perspective.  To complete this task a developer would need to: 
+      1. Modify clover to create a module::argument::constant for pointers in the constant address space (See the XXX comment in build_module_llvm() @ llvm/invocation.cpp 
+      1. Add support to r600g for creating constant buffers for compute.  (We should be able to resue evergreen_emit_constant_buffer() for this and we should create a separate constbuf_state atom for compute). 
+      1. Update the LLVM backend to handle loads from the constant address space. 
+* **Enable local address space ** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_ N/A 
+   * _Date Started: _N/A 
+   * _Status:_ N/A 
+   * _Description:_ 
+   * To complete this task a developer would need to: 
+      1. Modify clover to create a module::argument::local for data in the local address space (See the XXX comment in build_module_llvm() @ llvm/invocation.cpp 
+      1. Have r600g initialize the LDS with the correct size (see evergreen_set_lds() in evergreen_compute_internal.c) 
+      1. Add instructions to the LLVM backend for reading and writing from LDS. 
+* **Handle #include directive in OpenCL C source code ** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_ N/A 
+   * _Date Started: _N/A 
+   * _Status:_ I think this works.  It just needs to be tested and verified. 
+   * _Description:_ 
+   * The Clang frontend supports the #include directive, but Clover is not taking advantage of this.  gallium/state_trackers/clover/llvm/invocation.cpp is the place to start investigating how to complete this task. 
+
+### General Optimization
+
+* [MEDIUM] Convert the remaining pipe_state into atoms 
+
+### 3D Features
+
+* **Fast color clear on Evergreen-Cayman** 
+   * _Difficulty:_ Easy 
+   * _Who's working on it:_ N/A 
+   * _Note:_ CMASK is enabled already, but not being fast-cleared yet. 
+* **MSAA texturing on Cayman** 
+   * _Difficulty:_ Unknown 
+   * _Who was working on it:_ Marek Olšák 
+   * _Note:_ It's implemeneted, but it doesn't work. The ldfptr instruction (which reads a resolved FMASK) returns wrong values. 
+* **Polygon stippling** 
+   * _Difficulty:_ Easy 
+   * _Who's working on it:_ N/A 
+   * _Note:_ Take advantage of util/u_pstipple. It contains the shader transformation code and can create a stipple texture. 
+* **Polygon/line/point smoothing** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_ N/A 
+* **Texture buffer objects (read-only buffer resources in shaders)** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_ Dave Airlie 
+   * _Note:_ Core Mesa/Gallium support might need some work too. 
+* **Uniform buffer objects (constant buffers)** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_ Dave Airlie 
+   * _Note:_ Core Mesa/Gallium support might need some work too. 
+* **HyperZ support** 
+   * _Difficulty:_ Hard 
+   * _Who's working on it:_ Jerome Glisse 
+   * _Note:_ Patches available on the mailing list, but they currently cause hangs in a lot of cases. 
+* **Geometry shaders** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_ N/A 
+   * _Note:_ Core Mesa/Gallium support might need some work too. 
+
+### Bugs
+
+* **Virtual address space locks up on Cayman** 
+   * _Difficulty:_ Hard 
+   * _Who's working on it:_ Jerome, Christian 
+   * _Note:_ Patches posted. 
+* All open bugs assigned to [[Drivers/Gallium/r600|https://bugs.freedesktop.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=Drivers%2FGallium%2Fr600&product=Mesa&list_id=95681]] 
+
+## Notes
+
+* R600 trig functions input must be normalized from radians by dividing by 2*PI.  Valid input domain is [-256, 256] which corresponds to an unnormalized input domain of [-512*PI, 512*PI].  For SIN, an out of range input results in 0.0f, for COS, 1.0f. 
+\ No newline at end of file
diff --git a/R600ToDo.moin b/R600ToDo.moin
deleted file mode 100644
index e7298ad..0000000
--- a/R600ToDo.moin
+++ /dev/null
@@ -1,152 +0,0 @@
-<<TableOfContents()>>
-
-== R600 To Do list ==
-And here is the R600g to do list; if you feel something is missing please add it. If you have done something and it no longer needs to be investigated, happily erase it from here :).
-
-=== LLVM ===
- * '''Testing on R600, R700 and Cayman GPUs'''
-  * ''Difficulty:'' Easy
-  * ''Who's working on it:''
-  * ''Date Started:''
-  * ''Status:''
-  * ''Description:''
-
-  . Most of the LLVM backend testing has been with Evergreen or Northern Islands GPUs.  R600, R700, and Cayman GPUs are slightly different, so there may be bugs on these GPUs that aren't present on Evergeen/Northern Islands.  The best method for testing is to compare piglit results with and without the LLVM backend and report the regressions.  For easy switching between the two compilers, compile mesa with --enable-r600-llvm-compiler.  This will make the LLVM backend the default compiler, and you can switch back to the old compiler by using the R600_LLVM=0 environment variable.
-
-  . It would also be interesting to see if there are any performance gains from using the LLVM backend, so a related task would be to compare the performance of your favorite programs with and without the LLVM backend and then report any discrepancies.
-
- * '''Remove target specific intrinsics'''
-  * ''Difficulty:'' Easy
-  * ''Who's working on it:'' N/A
-  * ''Date Started:'' N/A
-  * ''Status:'' N/A
-  * ''Description:''
-
-  . The code in gallium/drivers/radeon/radeon_setup_tgsi.c uses a lot of target specific intrinsics for translating from TGSI to LLVM.  Most of these are unnecessary and should be replaced with LLVM IR or LLVM intrinsics.
-
- * '''Add support for 4 x i8 stores'''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:'' N/A
-  * ''Date Started:'' N/A
-  * ''Status:'' N/A
-  * ''Description:''
-
-  . We may be able to implement this by using a 32-bit store instructions and having the vector packed into a single 32-bit register.  I think LLVM may be able to do this for us, but we need to tell it that that some i8 operations are illegal.
-
- * '''Use LLVM analysis passes to clear the Barrier bit on Control Flow instructions'''
-  * ''Difficulty:'' Hard
-  * ''Who's working on it:'' N/A
-  * ''Date Started: ''N/A
-  * ''Status:'' N/A
-  * ''Description:''
-
-  . Clearing the Barrier bit on Control Flow instructions allows them to execute in parallel, which can improve performance.  We can use the LLVM analysis passes to determine when it is safe to clear this bit.  This task will also require some changes to the way code is generated by the backend, because we don't currently have much control over Control Flow instructions from inside the backend.
-=== Compute ===
-
- * '''Store Kernel Parameters in Constant Registers '''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:'' N/A
-  * ''Date Started: ''N/A
-  * ''Status:'' N/A
-  * ''Description:''
-
-  . Kernel parameters are currently being stored in vertex buffers, which are slower to access than the constant registers.  To complete this task a developer would need to:
-
-   1. Modify evergreen_compute_upload_input() in evergreen_compute.c to upload inputs to constant registers.
-   1. Change the custom lowering for implicit parameters in R600ISelLowering to use constant registers instead of VTX_READS
-   1. Have R600KernelParameters.cpp load parameters from the constant address space.
-   1. Lower loads from the constant address space to constant register reads.
-   
-  . For this task, it might be good to start by doing step 1 for only the implicit parameters, and then completing step 2.
-
- * '''Enable constant address space '''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:'' N/A
-  * ''Date Started: ''N/A
-  * ''Status:'' N/A
-  * ''Description:''
-
-  . Clover currently uses the global address space for all memory even constant memory, which is not optimal from a performance perspective.  To complete this task a developer would need to:
-
-   1. Modify clover to create a module::argument::constant for pointers in the constant address space (See the XXX comment in build_module_llvm() @ llvm/invocation.cpp
-   1. Add support to r600g for creating constant buffers for compute.  (We should be able to resue evergreen_emit_constant_buffer() for this and we should create a separate constbuf_state atom for compute).
-   1. Update the LLVM backend to handle loads from the constant address space.
-
-
- * '''Enable local address space '''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:'' N/A
-  * ''Date Started: ''N/A
-  * ''Status:'' N/A
-  * ''Description:''
-
-  . To complete this task a developer would need to:
-
-   1. Modify clover to create a module::argument::local for data in the local address space (See the XXX comment in build_module_llvm() @ llvm/invocation.cpp
-   1. Have r600g initialize the LDS with the correct size (see evergreen_set_lds() in evergreen_compute_internal.c)
-   1. Add instructions to the LLVM backend for reading and writing from LDS.
-
- * '''Handle #include directive in OpenCL C source code '''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:'' N/A
-  * ''Date Started: ''N/A
-  * ''Status:'' I think this works.  It just needs to be tested and verified.
-  * ''Description:''
-
-  . The Clang frontend supports the #include directive, but Clover is not taking advantage of this.  gallium/state_trackers/clover/llvm/invocation.cpp is the place to start investigating how to complete this task.
-
-=== General Optimization ===
- * [MEDIUM] Convert the remaining pipe_state into atoms
-
-=== 3D Features ===
-
- * '''Fast color clear on Evergreen-Cayman'''
-  * ''Difficulty:'' Easy
-  * ''Who's working on it:'' N/A
-  * ''Note:'' CMASK is enabled already, but not being fast-cleared yet.
-
- * '''MSAA texturing on Cayman'''
-  * ''Difficulty:'' Unknown
-  * ''Who was working on it:'' Marek Olšák
-  * ''Note:'' It's implemeneted, but it doesn't work. The ldfptr instruction (which reads a resolved FMASK) returns wrong values.
-
- * '''Polygon stippling'''
-  * ''Difficulty:'' Easy
-  * ''Who's working on it:'' N/A
-  * ''Note:'' Take advantage of util/u_pstipple. It contains the shader transformation code and can create a stipple texture.
-
- * '''Polygon/line/point smoothing'''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:'' N/A
-
- * '''Texture buffer objects (read-only buffer resources in shaders)'''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:'' Dave Airlie
-  * ''Note:'' Core Mesa/Gallium support might need some work too.
-
- * '''Uniform buffer objects (constant buffers)'''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:'' Dave Airlie
-  * ''Note:'' Core Mesa/Gallium support might need some work too.
-
- * '''HyperZ support'''
-  * ''Difficulty:'' Hard
-  * ''Who's working on it:'' Jerome Glisse
-  * ''Note:'' Patches available on the mailing list, but they currently cause hangs in a lot of cases.
-
- * '''Geometry shaders'''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:'' N/A
-  * ''Note:'' Core Mesa/Gallium support might need some work too.
-
-=== Bugs ===
-
- * '''Virtual address space locks up on Cayman'''
-  * ''Difficulty:'' Hard
-  * ''Who's working on it:'' Jerome, Christian
-  * ''Note:'' Patches posted.
-
- * All open bugs assigned to [[https://bugs.freedesktop.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=Drivers%2FGallium%2Fr600&product=Mesa&list_id=95681|Drivers/Gallium/r600]]
-
-== Notes ==
- * R600 trig functions input must be normalized from radians by dividing by 2*PI.  Valid input domain is [-256, 256] which corresponds to an unnormalized input domain of [-512*PI, 512*PI].  For SIN, an out of range input results in 0.0f, for COS, 1.0f.
diff --git a/Radeon%Architecture.moin b/Radeon%Architecture.mdwn
index 95b8a06..df75bba 100644
--- a/Radeon%Architecture.moin
+++ b/Radeon%Architecture.mdwn
@@ -1,96 +1,116 @@
-= Intro =
-This is as attempt to document the Radeon architecture and make things things a little bit easier for those new/would by DRM hackers.   It will describe some of the higher level hardware concepts and point to the DRM/X server code which manipulates that part of the hardware.  Many of these concepts are similar on other graphics architectures, but this document will only make an attempt to document the Radeon architecture. 
-
-= Registers & Framebuffer =
-Let's begin at the beginning.   The radeon card typically exposes two regions of memory which all of the software on the system can manipulate.   One region is the framebuffer, and the other (much smaller) region is the register region.   We can view these resources by using lspci to display information about the devices on the PCI bus.  My laptop has an ATI Radeon mobility, and here is its device information: 
-
-{{{
- /sbin/lspci  -v 
- ...
- 01:00.0 VGA compatible controller: ATI Technologies Inc M22 [Radeon Mobility M300] (prog-if 00 [VGA])
-        Subsystem: IBM Unknown device 056e
-        Flags: bus master, fast devsel, latency 0, IRQ 16
-        Memory at c0000000 (32-bit, prefetchable) [size=128M]
-        I/O ports at 3000 [size=256]
-        Memory at a8100000 (32-bit, non-prefetchable) [size=64K]
-        [virtual] Expansion ROM at a8120000 [disabled] [size=128K]
-        Capabilities: <access denied>
- ...
-}}}
-In this case, the frame buffer is mapped into 0xc0000000 and the registers are mapped into 0xa8100000.  These addresses are those viewed from the CPU.  If you opened up /dev/mem, and wrote to offset 0xc0000000, you would be writing to the first entry of the framebuffer.
-
-If you wanted to manipulate register 0x100, you would have to open up /dev/mem and write to 0xa8100100.  There are other ways to map things, but basically you are always writing to the same memory location. 
-
-The Xserver and/or DRM kernel module will do the mapping of these registers and framebuffer so that it can manipulate the card. 
-
-== The Register Region ==
-The register region contains all the registers that are used to control the card.  The registers are manipulated by the DRM kernel module, the X server, and sometimes even the kernel. (in the case of the Framebuffer driver.)  
-
-The function of some registers are well-know, and others have been reverse engineered and their functions are a little sketchy. 
-
-The registers and some of their values are defined all over the place.  The X server has some definitions: 
-http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=blob;f=src/radeon_reg.h
-
-There are some definitions which are only for the R300: 
-http://gitweb.freedesktop.org/?p=mesa/drm.git;a=blob;f=shared-core/r300_reg.h
-
-The kernel has some, too:  
-http://www.gelato.unsw.edu.au/lxr/source/include/video/radeon.h
-
-Why are things spread out?  Mainly because each piece/definition grew up to support the area which is using it.  For example, the mesa/dri version has information about the registers which control the 3-d portions of the hardware, which the kernel/X server mainly have the 2-d and modesetting stuff. (Although there is some overlap.) 
-
-With the radeon, the entire card can be controlled by manipulating registers.  
-
-If you want to color the screen green (for example), you can make a series of register writes and the card will turn the screen green.   
-
-It is important to note that EVERYTHING you are doing to radeon card ultimately boils down to a series of register writes.  The X server basically takes the high level functions and translates them into a series of register writes.  Mesa takes the OpenGL commands and (working with DRI) translates them into a series of register writes. 
-
-There are ways to make this more efficient (using the CP with the RING buffer and indirect writes), but it all basically boils down to a series of register writes. 
-
-== The Framebuffer ==
-The other region of memory contains the framebuffer (or area where the final pixels on the screen will end up.)  
-However, sometimes, other things such as the GART table and textures are also put into this memory. 
-
-This memory is typically (but not always in the case of some embedded/laptop chipsets) on-board dedicated video memory for the graphics card. 
-
-= Command Processor (CP) =
-As stated above, with the radeon the entire card can be controlled by manipulating registers.  
-
-However, if the CPU had to sit and wait for each and every register write to the Radeon to complete, the CPU would not be able to do anything else.   This is where the Radeon's command processor (CP) comes in handy.  It can read register/ value pairs from a ring buffer, and execute those commands while the CPU is off doing other things. 
-
-The radeon has a ring buffer which you can stuff full with a bunch of register/values which you want to write, tell the Radeon about it, and check back later to see if things have been completed.   The command processor will work through the ring buffer until it has completed everything.   One of the nice features is that the CPU can still add new work to the end of the ring buffer while the CP is processing things at the front of the ring buffer. 
-
-The CP is initialized in the kernel DRM module, in this file: 
-[[http://gitweb.freedesktop.org/?p=mesa/drm.git;a=blob;f=shared-core/radeon_cp.c|radeon_cp.c]]
-
-If DRM is directly writing all of the commands to ring buffer (called direct access), the application would need to  make a system call for every register that they want to write.  Another alternative is indirect access, where the application (or Mesa acting on its behalf) will create a list of commands in an indirect buffer, and hand that buffer to DRM.  Then the DRM kernel module will issue a command to the CP which says "execute the commands in this piece of memory", (or in CP speak, "execute the commands in this indirect buffer".)  That way, not only can the CPU be doing other things when the CP is running, but the creation of the list of commands for the CP can be done in user space. 
-
-== Initialization ==
-TODO
-
-== Use of the CP ==
-TODO (Head pointer, tail pointer, etc.) 
-
-== Format of Messages ==
-TODO
-
-= Memory Mapping =
-
-Memory mapping on the Radeon can make your head spin.   A single location in memory can have as many as 4 different 
-address based on where it is being accessed from:
-  * GART Table  (physical address)
-  * DRM module  (kernel virtual address)
-  * Radeon Card (bus address)
-  * User space app (user virtual address)
-
-This is similar to many hardware devices, and once you understand why and how it is done, things become much easier. 
-
-(TODO)
-
-== GART ==
-
-= Display Setup =
-
-== i2c stuff ==
-----
-CategoryHardware
+
+
+# Intro
+
+This is as attempt to document the Radeon architecture and make things things a little bit easier for those new/would by DRM hackers.   It will describe some of the higher level hardware concepts and point to the DRM/X server code which manipulates that part of the hardware.  Many of these concepts are similar on other graphics architectures, but this document will only make an attempt to document the Radeon architecture.  
+
+
+# Registers & Framebuffer
+
+Let's begin at the beginning.   The radeon card typically exposes two regions of memory which all of the software on the system can manipulate.   One region is the framebuffer, and the other (much smaller) region is the register region.   We can view these resources by using lspci to display information about the devices on the PCI bus.  My laptop has an ATI Radeon mobility, and here is its device information:  
+
+
+[[!format txt """
+ /sbin/lspci  -v 
+ ...
+ 01:00.0 VGA compatible controller: ATI Technologies Inc M22 [Radeon Mobility M300] (prog-if 00 [VGA])
+        Subsystem: IBM Unknown device 056e
+        Flags: bus master, fast devsel, latency 0, IRQ 16
+        Memory at c0000000 (32-bit, prefetchable) [size=128M]
+        I/O ports at 3000 [size=256]
+        Memory at a8100000 (32-bit, non-prefetchable) [size=64K]
+        [virtual] Expansion ROM at a8120000 [disabled] [size=128K]
+        Capabilities: <access denied>
+ ...
+"""]]
+In this case, the frame buffer is mapped into 0xc0000000 and the registers are mapped into 0xa8100000.  These addresses are those viewed from the CPU.  If you opened up /dev/mem, and wrote to offset 0xc0000000, you would be writing to the first entry of the framebuffer. 
+
+If you wanted to manipulate register 0x100, you would have to open up /dev/mem and write to 0xa8100100.  There are other ways to map things, but basically you are always writing to the same memory location.  
+
+The Xserver and/or DRM kernel module will do the mapping of these registers and framebuffer so that it can manipulate the card.  
+
+
+## The Register Region
+
+The register region contains all the registers that are used to control the card.  The registers are manipulated by the DRM kernel module, the X server, and sometimes even the kernel. (in the case of the Framebuffer driver.)   
+
+The function of some registers are well-know, and others have been reverse engineered and their functions are a little sketchy.  
+
+The registers and some of their values are defined all over the place.  The X server has some definitions:  [[http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=blob;f=src/radeon_reg.h|http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=blob;f=src/radeon_reg.h]] 
+
+There are some definitions which are only for the R300:  [[http://gitweb.freedesktop.org/?p=mesa/drm.git;a=blob;f=shared-core/r300_reg.h|http://gitweb.freedesktop.org/?p=mesa/drm.git;a=blob;f=shared-core/r300_reg.h]] 
+
+The kernel has some, too:   [[http://www.gelato.unsw.edu.au/lxr/source/include/video/radeon.h|http://www.gelato.unsw.edu.au/lxr/source/include/video/radeon.h]] 
+
+Why are things spread out?  Mainly because each piece/definition grew up to support the area which is using it.  For example, the mesa/dri version has information about the registers which control the 3-d portions of the hardware, which the kernel/X server mainly have the 2-d and modesetting stuff. (Although there is some overlap.)  
+
+With the radeon, the entire card can be controlled by manipulating registers.   
+
+If you want to color the screen green (for example), you can make a series of register writes and the card will turn the screen green.    
+
+It is important to note that EVERYTHING you are doing to radeon card ultimately boils down to a series of register writes.  The X server basically takes the high level functions and translates them into a series of register writes.  Mesa takes the OpenGL commands and (working with DRI) translates them into a series of register writes.  
+
+There are ways to make this more efficient (using the CP with the RING buffer and indirect writes), but it all basically boils down to a series of register writes.  
+
+
+## The Framebuffer
+
+The other region of memory contains the framebuffer (or area where the final pixels on the screen will end up.)   However, sometimes, other things such as the GART table and textures are also put into this memory.  
+
+This memory is typically (but not always in the case of some embedded/laptop chipsets) on-board dedicated video memory for the graphics card.  
+
+
+# Command Processor (CP)
+
+As stated above, with the radeon the entire card can be controlled by manipulating registers.   
+
+However, if the CPU had to sit and wait for each and every register write to the Radeon to complete, the CPU would not be able to do anything else.   This is where the Radeon's command processor (CP) comes in handy.  It can read register/ value pairs from a ring buffer, and execute those commands while the CPU is off doing other things.  
+
+The radeon has a ring buffer which you can stuff full with a bunch of register/values which you want to write, tell the Radeon about it, and check back later to see if things have been completed.   The command processor will work through the ring buffer until it has completed everything.   One of the nice features is that the CPU can still add new work to the end of the ring buffer while the CP is processing things at the front of the ring buffer.  
+
+The CP is initialized in the kernel DRM module, in this file:  [[radeon_cp.c|http://gitweb.freedesktop.org/?p=mesa/drm.git;a=blob;f=shared-core/radeon_cp.c]] 
+
+If DRM is directly writing all of the commands to ring buffer (called direct access), the application would need to  make a system call for every register that they want to write.  Another alternative is indirect access, where the application (or Mesa acting on its behalf) will create a list of commands in an indirect buffer, and hand that buffer to DRM.  Then the DRM kernel module will issue a command to the CP which says "execute the commands in this piece of memory", (or in CP speak, "execute the commands in this indirect buffer".)  That way, not only can the CPU be doing other things when the CP is running, but the creation of the list of commands for the CP can be done in user space.  
+
+
+## Initialization
+
+TODO 
+
+
+## Use of the CP
+
+TODO (Head pointer, tail pointer, etc.)  
+
+
+## Format of Messages
+
+TODO 
+
+
+# Memory Mapping
+
+Memory mapping on the Radeon can make your head spin.   A single location in memory can have as many as 4 different  address based on where it is being accessed from: 
+
+   * GART Table  (physical address) 
+   * DRM module  (kernel virtual address) 
+   * Radeon Card (bus address) 
+   * User space app (user virtual address) 
+This is similar to many hardware devices, and once you understand why and how it is done, things become much easier.  
+
+(TODO) 
+
+
+## GART
+
+
+# Display Setup
+
+
+## i2c stuff
+
+
+
+---
+
+ [[CategoryHardware|CategoryHardware]] 
diff --git a/Radeon%Companion%1.mdwn b/Radeon%Companion%1.mdwn
new file mode 100644
index 0000000..9aeb414
--- /dev/null
+++ b/Radeon%Companion%1.mdwn
@@ -0,0 +1,31 @@
+
+
+# The irregular Radeon-Development companion
+
+
+## Issue for 2007-03-10
+
+
+## Intro
+
+This page is an accumulation of the events happening in Radeon development. The concept has been shamelessly copied from [[nouveau|http://nouveau.freedesktop.org]] and will hopefully be kept up. 
+
+
+## Ongoing work
+
+* There is currently ongoing work on the **FireMV 2400** card by Erwin Rol. This card is basically a couple of 2 Radeon M9 that can drive 4 monitors. But sadly it needs some trick to initialize it correctly. This setup works fine without DRI but enabling it causes the computer to hang. Erwin has traced the hang to _RADEONRestorePLLRegisters_ but isn't sure if that is correct. He is currently waiting for input from other developers. [[Source|http://lists.freedesktop.org/archives/xorg/2007-March/022462.html]], [[Source|http://lists.freedesktop.org/archives/xorg/2007-March/022340.html]] 
+* A bug was entered by Oliver [[McFadden|McFadden]] to bugzilla to **clean up the naming in of the R300 context**. This work is based on earlier patches by Christoph Brill that were committed and supported by Jerome Glisse. It basically tries to rename all unkXXXX from r300_hw_state to a human readable value. There might be further patches in that area since Jermone Glisse mentioned that some of these might be merged with each other. [[Source|https://bugs.freedesktop.org/show_bug.cgi?id=10234]] 
+* Phillip Ezolt is still working on debugging the **200M command processor**. At the current point he is looking at the GART before, during and after a 3D application is run. He is also waiting for input from other developers. At the current state he found out where the location of the ring buffer is, the virtual address of the ring buffer in X.org and he assumes that the first page of the ring buffer will be the first entry in the GART table. [[Source|http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg30016.html]] 
+* During this week Papadakos Panagiotis came up with **invalid reads from intersect_rect in radeon_state.c of r300 driver** and reported that in a bug. Quickly he responded to himself with a patch to fix up cliprect in R300. That patch hit the git tree and Papadakos noted that other (Radeon) drivers might be also effected by this bug. [[Source|http://bugs.freedesktop.org/show_bug.cgi?id=10109]] 
+* Christoph Brill did his first patches against git guided by Jerome Glisse to add some defines to **r300_reg.h cleanup**. Jerome reviewed these patches and committed them shortly after they hit the mailing list. [[Source|http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg29880.html]] 
+* A short discussion about the **logic behind enabling Early Z** on R300 was taken by Roland Scheidegger, Keith Withwell and Jerome Glisse. They spotted a piece of code that implements this logic and discussed why it looks like this. They came to the conclusion that this logic is currently necessary to work around missing support for depth writing in the driver. [[Source|http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg29870.html]] 
+* On IRC a discussion came up about porting **nouveau tools to Radeon**. Oliver [[McFadden|McFadden]] and marcheu discussed the working methods of Renouveau and why it could also work in R300. Renouveau basically looks at the hardware state of a card, sends OpenGL commands to it and again looks at the state. Using this technique it's "relatively" simple to spot what has changed and why. Renouveau is one of the most useful tools in nouveau development. R300 development is a bit more chaotic so porting it would be a good idea. Another interesting tool from nouveau is rules-ng.xml. It is used to completely describe a graphics card and it might be of interest to use it for R300, too. No further discussion was made on these topics. 
+* Oliver [[McFadden|McFadden]], marcheu, Wallbraker and Dave Airlie discussed methods about **how to trace commands on R300**. Until a recent change, the fglrx driver was doing many work in userspace using indirect buffer access. Tools like [[iba-2 and libsegfault|ReverseEngineering]] could be used to trace the access and make a sense of it. Now most of the stuff is done in kernel space using MMIO. They agreed that [[KMMIO|http://nouveau.freedesktop.org/wiki/MmioTrace]] should do the trick. Dave also explained that fglrx is using a similar system to DRM (Direct Rendering Manager) just like the open source driver does. 
+* Lately Oliver [[McFadden|McFadden]] is looking on hard lockups of his card when he is running an application that make use of features like stencil shadows. He and Wallbraker are discussing if it is related to this or to synchronisation issues. Until now the are both unsure what the cause is. 
+* Wallbraker is also looking into how to implement modesetting in DRM. Discussion between him and Dave Airlie about naming conventions for methods were lead but until now there is no progress you can see. 
+
+## Help needed
+
+Currently Radeon development is going slowly forward. We are **looking for developers** and users that are able to understand hardware development. So if you got free time and maybe even knowledge of hardware development, feel free to join #dri-devel on irc.freenode.net and look at the source. We are also interessted in **porting Renouveau over to R300** (or even to make it vendor independent, so it could be used for Intel and whatever else). This work would be highly appreciated by every developer. It would also be important to check why **KMMIO does not work flawless on R300**. 
+
+_Written by Christoph Brill_ 
diff --git a/Radeon%Companion%1.moin b/Radeon%Companion%1.moin
deleted file mode 100644
index 91a5e0f..0000000
--- a/Radeon%Companion%1.moin
+++ /dev/null
@@ -1,35 +0,0 @@
-= The irregular Radeon-Development companion =
-
-== Issue for 2007-03-10 ==
-
-== Intro ==
-
-This page is an accumulation of the events happening in Radeon development. The concept has been shamelessly copied from [[http://nouveau.freedesktop.org|nouveau]] and will hopefully be kept up.
-
-== Ongoing work ==
-
- * There is currently ongoing work on the '''FireMV 2400''' card by Erwin Rol. This card is basically a couple of 2 Radeon M9 that can drive 4 monitors. But sadly it needs some trick to initialize it correctly. This setup works fine without DRI but enabling it causes the computer to hang. Erwin has traced the hang to ''RADEONRestorePLLRegisters'' but isn't sure if that is correct. He is currently waiting for input from other developers. [[http://lists.freedesktop.org/archives/xorg/2007-March/022462.html|Source]], [[http://lists.freedesktop.org/archives/xorg/2007-March/022340.html|Source]]
-
- * A bug was entered by Oliver McFadden to bugzilla to '''clean up the naming in of the R300 context'''. This work is based on earlier patches by Christoph Brill that were committed and supported by Jerome Glisse. It basically tries to rename all unkXXXX from r300_hw_state to a human readable value. There might be further patches in that area since Jermone Glisse mentioned that some of these might be merged with each other. [[https://bugs.freedesktop.org/show_bug.cgi?id=10234|Source]]
-
- * Phillip Ezolt is still working on debugging the '''200M command processor'''. At the current point he is looking at the GART before, during and after a 3D application is run. He is also waiting for input from other developers. At the current state he found out where the location of the ring buffer is, the virtual address of the ring buffer in X.org and he assumes that the first page of the ring buffer will be the first entry in the GART table. [[http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg30016.html|Source]]
-
- * During this week Papadakos Panagiotis came up with '''invalid reads from intersect_rect in radeon_state.c of r300 driver''' and reported that in a bug. Quickly he responded to himself with a patch to fix up cliprect in R300. That patch hit the git tree and Papadakos noted that other (Radeon) drivers might be also effected by this bug. [[http://bugs.freedesktop.org/show_bug.cgi?id=10109|Source]]
-
- * Christoph Brill did his first patches against git guided by Jerome Glisse to add some defines to '''r300_reg.h cleanup'''. Jerome reviewed these patches and committed them shortly after they hit the mailing list. [[http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg29880.html|Source]]
-
- * A short discussion about the '''logic behind enabling Early Z''' on R300 was taken by Roland Scheidegger, Keith Withwell and Jerome Glisse. They spotted a piece of code that implements this logic and discussed why it looks like this. They came to the conclusion that this logic is currently necessary to work around missing support for depth writing in the driver. [[http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg29870.html|Source]]
-
- * On IRC a discussion came up about porting '''nouveau tools to Radeon'''. Oliver McFadden and marcheu discussed the working methods of Renouveau and why it could also work in R300. Renouveau basically looks at the hardware state of a card, sends OpenGL commands to it and again looks at the state. Using this technique it's "relatively" simple to spot what has changed and why. Renouveau is one of the most useful tools in nouveau development. R300 development is a bit more chaotic so porting it would be a good idea. Another interesting tool from nouveau is rules-ng.xml. It is used to completely describe a graphics card and it might be of interest to use it for R300, too. No further discussion was made on these topics.
-
- * Oliver McFadden, marcheu, Wallbraker and Dave Airlie discussed methods about '''how to trace commands on R300'''. Until a recent change, the fglrx driver was doing many work in userspace using indirect buffer access. Tools like [[ReverseEngineering|iba-2 and libsegfault]] could be used to trace the access and make a sense of it. Now most of the stuff is done in kernel space using MMIO. They agreed that [[http://nouveau.freedesktop.org/wiki/MmioTrace|KMMIO]] should do the trick. Dave also explained that fglrx is using a similar system to DRM (Direct Rendering Manager) just like the open source driver does.
-
- * Lately Oliver McFadden is looking on hard lockups of his card when he is running an application that make use of features like stencil shadows. He and Wallbraker are discussing if it is related to this or to synchronisation issues. Until now the are both unsure what the cause is.
-
- * Wallbraker is also looking into how to implement modesetting in DRM. Discussion between him and Dave Airlie about naming conventions for methods were lead but until now there is no progress you can see.
-
-== Help needed ==
-
-Currently Radeon development is going slowly forward. We are '''looking for developers''' and users that are able to understand hardware development. So if you got free time and maybe even knowledge of hardware development, feel free to join #dri-devel on irc.freenode.net and look at the source. We are also interessted in '''porting Renouveau over to R300''' (or even to make it vendor independent, so it could be used for Intel and whatever else). This work would be highly appreciated by every developer. It would also be important to check why '''KMMIO does not work flawless on R300'''.
-
-''Written by Christoph Brill''
diff --git a/Radeon.mdwn b/Radeon.mdwn
new file mode 100644
index 0000000..d9e4450
--- /dev/null
+++ b/Radeon.mdwn
@@ -0,0 +1,125 @@
+
+
+## Radeon 3D acceleration Portal
+
+This page is the entry portal for everything related to _open source_ 3D hardware acceleration support on AMD (formerly ATI) Radeon cards, from the old Radeon 7000 up to the latest Radeon HD cards. More information about general Radeon issues (2D acceleration etc.) can be found over at the [[X.org Wiki|http://xorg.freedesktop.org/wiki/radeon]]. 
+
+[[!toc ]] 
+
+
+### How well does it work?
+
+As of October 2009, all Radeon cards are well supported in 2D using the Radeon [[DDX|DDX]] 6.12.4. Using Mesa 7.6, the 3D support is as follows: 
+
+* Radeon 7000 - X1950: Well supported by the free drivers `radeon`, `r200` and `r300`. Experimental work on a [[Gallium3D|Gallium3D]] driver for Radeon 9500 - X1950 is in progress under the codename `r300g`. 
+* Radeon X2000 - X4870: Initial experimental 3D support is available by the free driver `r600`, and is rapidly improving in the Mesa master branch. 
+For more detail, see a [[list of supported features|http://xorg.freedesktop.org/wiki/RadeonFeature]] and the [[program and games test matrix|http://xorg.freedesktop.org/wiki/RadeonProgram]]. 
+
+
+### How to get bleeding-edge 3D drivers?
+
+Your distribution should install a nice choice of default drivers. This section applies only if you want to experience the bleeding edge, if a developer has suggested that you try some patch, or if you want to become a developer yourself. 
+
+**Be careful, for this section may lead you into a world of pain and crashes.** 
+
+As a first step, maybe your distribution offers more bleeding edge packages already: 
+
+* Ubuntu has an [[xorg-edgers|https://launchpad.net/~xorg-edgers]] team and PPA 
+* Rawhide tends to provide a very recent and up-to-day graphics environment 
+* **TODO:** Add information for other distributions 
+If you want to go to the source, you should follow the instructions on the [[Building|Building]] site. 
+
+
+### Where can I get help?
+
+If you have a concrete problem for which you need help, perhaps the problem is already known. Check out the [[RadeonTroubleshooting|RadeonTroubleshooting]] page. 
+
+Your distribution may have documentation and/or an active community that is willing to help you out: 
+
+* Ubuntu has a [[How to get help|https://help.ubuntu.com/community/Signpost/Questions#help]] 
+* **TODO:** Add information for other distributions 
+You can also visit the [[forums at Phoronix|http://www.phoronix.com/forums/forumdisplay.php?f=43]] or the IRC channel `#radeon` on `irc.freenode.net`. 
+
+
+### How to report bugs
+
+First of all, make sure your problem isn't already known, by perusing the "Where can I get help?" section. 
+
+We use the [[FreeDesktop Bugzilla|http://bugs.freedesktop.org/]] for bug tracking, and this should be your first stop to check for already existing bugs. There are separate components for the different 3D drivers: 
+
+* [[radeon|https://bugs.freedesktop.org/buglist.cgi?component=Drivers%2FDRI%2Fradeon&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED]]: Radeon 7000 
+* [[r200|https://bugs.freedesktop.org/buglist.cgi?component=Drivers%2FDRI%2Fr200&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED]]: Radeon 8500 - 9200 
+* [[r300|https://bugs.freedesktop.org/buglist.cgi?component=Drivers%2FDRI%2Fr300&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED]]: Radeon 9500 - X1950 
+* [[r600|https://bugs.freedesktop.org/buglist.cgi?component=Drivers%2FDRI%2FR600&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED]]: all Radeon HD cards 
+There is currently no bug tracker for the experimental `r300g` driver. We'll create one as soon as we are interested in receiving bug reports for that driver. 
+
+Make sure you use good bug hygiene: 
+
+* Check whether the bug has already been reported. 
+* Provide steps to reproduce the bug. 
+   * If the bug affects uncommon programs (in particular, if it affects games), provide a link where developers can obtain the program. 
+* State clearly what is going wrong, i.e. what do you expect to happen, and where do things fail. In the case of incorrect rendering (i.e. graphics artefacts), it is most useful if you can provide screenshots of both incorrect **and** correct rendering. 
+* Provide full information about your system. Many distributions have tools to help with that. In particular, you should provide: 
+   * the version of all involved software, in particular the kernel, the [[DDX|DDX]], [[libdrm|libdrm]], Mesa 
+   * the version of the program that is affected by the bug 
+   * whether you are using [[Kernel Mode Setting|Kernel Mode Setting]] (KMS) or not 
+   * information about your hardware: state the model of your graphics card, whether it's AGP or PCIE; output of `lspci` can't hurt either 
+   * output of `dmesg`, and your `Xorg.0.log` 
+   * output of the affected program, if any 
+* _Do not paste log files and the like into bug comments._ Instead, add those files as attachments to the bug report. 
+* Be responsive if a developer asks for more information or asks you to test some workaround or patch. 
+If at all possible, use [[git bisect|http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#using-bisect]] to pin-point the cause of the bug if it is a regression. 
+
+
+### How can I help?
+
+There are many ways you can help, whether you are a programmer or not. Here are some suggestions for non-programmers: 
+
+* Help us keep the [[program support matrix|http://xorg.freedesktop.org/wiki/RadeonProgram]] up to date. 
+* Contribute to this documentation (for example, you may come across [[troubleshooting advice|RadeonTroubleshooting]] from developers that they haven't been able to add; don't hesitate to add it yourself!); be helpful to people who are running into issues in the various Linux and FreeBSD communities. 
+* Run bleeding-edge drivers on your own system, and report any regressions you run into. We try to keep Mesa master as stable as possible, but regressions do creep in occasionally, and the sooner we know about them, the better. 
+If you want to get your hands dirty with the code itself, welcome! Here are some of things that should help you to get started: 
+
+* [[Build|Building]] Mesa and related packages from source. 
+* Get yourself acquainted with the development community places (see section below). 
+* Browse the source code and familiarize yourself with how it works, perhaps via the other development resources. 
+* Learn to program small OpenGL programs and learn to read the [[OpenGL and extension specifications|http://www.opengl.org/registry/]]. 
+Finally, you should find yourself some small project to work on. This could be: 
+
+* Fix one of the many open bugs in the bug tracker. 
+* Check out the [[piglit|http://cgit.freedesktop.org/piglit]] test suite. There are still failing tests, maybe you can fix one of them. 
+* There may be a bug affecting your favourite 3D game. 
+* Perhaps you want to improve the performance of your favourite 3D game. 
+There are also semi-up-to-date Todo lists that you may peruse for inspiration: 
+
+* r300: [[R300ToDo|R300ToDo]]; note that work on new feature is more appreciated for `r300g` these days 
+* r600: [[R600ToDo|R600ToDo]]; 
+Once you have a working patch (even if the patch merely adds or clarifies some comments in the source code!), you should send your patch to the developers. The most accepted way to do this is to send your patch in an email to the `mesa3d-dev` (for Mesa patches) or `dri-devel` (for libdrm or kernel patches) mailing list. The `git format-patch` command can help you with that. If your patch is small enough and you feel comfortable with IRC, you can also ask for feedback on `#radeon`, having uploaded your patch to a pastebin site (e.g. [[here|http://radeon.pastebin.com/]]) or to a public Git repository of your own. 
+
+
+### Development Community Places
+
+The development centers around the source code, which is available in the [[Mesa Git repository|http://cgit.freedesktop.org/mesa/mesa]]. Most of the development discussion actually takes place on IRC, in `#radeon` on `irc.freenode.net`. Some discussions, particularly about [[Gallium3D|Gallium3D]], also take place in the channel `#dri-devel`. [[IRC logs|http://people.freedesktop.org/~cbrill/dri-log/]] of past discussions are available. The second most important place are the [[relevant mailing lists|MailingLists]]. Furthermore, many developers visit the [[Phoronix forums|http://www.phoronix.com/forums/forumdisplay.php?f=43]], where they will often provide useful information; however, development discussions usually do not take place there. 
+
+There are also several developers' blogs which are aggregated on [[Planet Freedesktop|http://planet.freedesktop.org/]], and an (also aggregated) extremely irregular [[blog specifically about Radeon development|http://tirdc.livejournal.com/]]. 
+
+
+### Development Resources
+
+* [[R300Compiler|R300Compiler]] provides some information about the shader compiler for R300-R500 
+* Hardware Information 
+   * [[Hardware documentation from AMD|http://www.x.org/docs/AMD/]] 
+   * [[ATIRadeon|ATIRadeon]]: Chipset naming, and various information that maybe should be integrated in a nicer way 
+   * [[Radeon Architecture|Radeon%Architecture]] - mostly superseded by the documentation from AMD 
+   * R300-R500 
+      * [[R300ToDo|R300ToDo]] 
+      * [[R300Textures|R300Textures]] 
+      * [[Radeon200M|Radeon200M]] 
+   * R000-R700 
+      * [[R600ToDo|R600ToDo]] 
+* [[General Todo list|ToDo]] 
+* Various collected links (may benefit from updating): 
+   * [[MesaDriver|MesaDriver]]: How to write a Mesa driver (only applies to classic drivers and the Mesa state tracker, but not to [[Gallium3D|Gallium3D]] drivers) 
+   * [[A locking mechanism for the DRI|http://dri.sourceforge.net/doc/hardware_locking_low_level.html]] (no longer applies to DRI2) 
+   * [[ReverseEngineering|ReverseEngineering]]: Reverse engineering tools 
+* Old TiRDCs: [[Radeon%Companion%1|Radeon%Companion%1]], [[Radeon_Companion_2|Radeon_Companion_2]], [[Radeon_Companion_3|Radeon_Companion_3]], [[Radeon_Companion_4|Radeon_Companion_4]] 
+\ No newline at end of file
diff --git a/Radeon.moin b/Radeon.moin
deleted file mode 100644
index 51fbe75..0000000
--- a/Radeon.moin
+++ /dev/null
@@ -1,113 +0,0 @@
-== Radeon 3D acceleration Portal ==
-
-This page is the entry portal for everything related to ''open source'' 3D hardware acceleration support on AMD (formerly ATI) Radeon cards, from the old Radeon 7000 up to the latest Radeon HD cards. More information about general Radeon issues (2D acceleration etc.) can be found over at the [[http://xorg.freedesktop.org/wiki/radeon|X.org Wiki]].
-
-<<TableOfContents>>
-
-
-=== How well does it work? ===
-
-As of October 2009, all Radeon cards are well supported in 2D using the Radeon [[DDX]] 6.12.4. Using Mesa 7.6, the 3D support is as follows:
- * Radeon 7000 - X1950: Well supported by the free drivers `radeon`, `r200` and `r300`. Experimental work on a [[Gallium3D]] driver for Radeon 9500 - X1950 is in progress under the codename `r300g`.
- * Radeon X2000 - X4870: Initial experimental 3D support is available by the free driver `r600`, and is rapidly improving in the Mesa master branch.
-For more detail, see a [[http://xorg.freedesktop.org/wiki/RadeonFeature|list of supported features]] and the [[http://xorg.freedesktop.org/wiki/RadeonProgram|program and games test matrix]].
-
-=== How to get bleeding-edge 3D drivers? ===
-
-Your distribution should install a nice choice of default drivers. This section applies only if you want to experience the bleeding edge, if a developer has suggested that you try some patch, or if you want to become a developer yourself.
-
-'''Be careful, for this section may lead you into a world of pain and crashes.'''
-
-As a first step, maybe your distribution offers more bleeding edge packages already:
- * Ubuntu has an [[https://launchpad.net/~xorg-edgers|xorg-edgers]] team and PPA
- * Rawhide tends to provide a very recent and up-to-day graphics environment
- * '''TODO:''' Add information for other distributions
-
-If you want to go to the source, you should follow the instructions on the [[Building]] site.
-
-=== Where can I get help? ===
-
-If you have a concrete problem for which you need help, perhaps the problem is already known. Check out the [[RadeonTroubleshooting]] page.
-
-Your distribution may have documentation and/or an active community that is willing to help you out:
- * Ubuntu has a [[https://help.ubuntu.com/community/Signpost/Questions#help|How to get help]]
- * '''TODO:''' Add information for other distributions
-
-You can also visit the [[http://www.phoronix.com/forums/forumdisplay.php?f=43|forums at Phoronix]] or the IRC channel `#radeon` on `irc.freenode.net`.
-
-=== How to report bugs ===
-
-First of all, make sure your problem isn't already known, by perusing the "Where can I get help?" section.
-
-We use the [[http://bugs.freedesktop.org/|FreeDesktop Bugzilla]] for bug tracking, and this should be your first stop to check for already existing bugs. There are separate components for the different 3D drivers:
- * [[https://bugs.freedesktop.org/buglist.cgi?component=Drivers%2FDRI%2Fradeon&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED|radeon]]: Radeon 7000
- * [[https://bugs.freedesktop.org/buglist.cgi?component=Drivers%2FDRI%2Fr200&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED|r200]]: Radeon 8500 - 9200
- * [[https://bugs.freedesktop.org/buglist.cgi?component=Drivers%2FDRI%2Fr300&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED|r300]]: Radeon 9500 - X1950
- * [[https://bugs.freedesktop.org/buglist.cgi?component=Drivers%2FDRI%2FR600&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED|r600]]: all Radeon HD cards
-There is currently no bug tracker for the experimental `r300g` driver. We'll create one as soon as we are interested in receiving bug reports for that driver.
-
-Make sure you use good bug hygiene:
- * Check whether the bug has already been reported.
- * Provide steps to reproduce the bug.
-  * If the bug affects uncommon programs (in particular, if it affects games), provide a link where developers can obtain the program.
- * State clearly what is going wrong, i.e. what do you expect to happen, and where do things fail. In the case of incorrect rendering (i.e. graphics artefacts), it is most useful if you can provide screenshots of both incorrect '''and''' correct rendering.
- * Provide full information about your system. Many distributions have tools to help with that. In particular, you should provide:
-  * the version of all involved software, in particular the kernel, the [[DDX]], [[libdrm]], Mesa
-  * the version of the program that is affected by the bug
-  * whether you are using [[Kernel Mode Setting]] (KMS) or not
-  * information about your hardware: state the model of your graphics card, whether it's AGP or PCIE; output of `lspci` can't hurt either
-  * output of `dmesg`, and your `Xorg.0.log`
-  * output of the affected program, if any
- * ''Do not paste log files and the like into bug comments.'' Instead, add those files as attachments to the bug report.
- * Be responsive if a developer asks for more information or asks you to test some workaround or patch.
-
-If at all possible, use [[http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#using-bisect|git bisect]] to pin-point the cause of the bug if it is a regression.
-
-=== How can I help? ===
-
-There are many ways you can help, whether you are a programmer or not. Here are some suggestions for non-programmers:
- * Help us keep the [[http://xorg.freedesktop.org/wiki/RadeonProgram|program support matrix]] up to date.
- * Contribute to this documentation (for example, you may come across [[RadeonTroubleshooting|troubleshooting advice]] from developers that they haven't been able to add; don't hesitate to add it yourself!); be helpful to people who are running into issues in the various Linux and FreeBSD communities.
- * Run bleeding-edge drivers on your own system, and report any regressions you run into. We try to keep Mesa master as stable as possible, but regressions do creep in occasionally, and the sooner we know about them, the better.
-
-If you want to get your hands dirty with the code itself, welcome! Here are some of things that should help you to get started:
- * [[Building|Build]] Mesa and related packages from source.
- * Get yourself acquainted with the development community places (see section below).
- * Browse the source code and familiarize yourself with how it works, perhaps via the other development resources.
- * Learn to program small OpenGL programs and learn to read the [[http://www.opengl.org/registry/|OpenGL and extension specifications]].
-Finally, you should find yourself some small project to work on. This could be:
- * Fix one of the many open bugs in the bug tracker.
- * Check out the [[http://cgit.freedesktop.org/piglit|piglit]] test suite. There are still failing tests, maybe you can fix one of them.
- * There may be a bug affecting your favourite 3D game.
- * Perhaps you want to improve the performance of your favourite 3D game.
-There are also semi-up-to-date Todo lists that you may peruse for inspiration:
- * r300: [[R300ToDo]]; note that work on new feature is more appreciated for `r300g` these days
- * r600: [[R600ToDo]];
-
-Once you have a working patch (even if the patch merely adds or clarifies some comments in the source code!), you should send your patch to the developers. The most accepted way to do this is to send your patch in an email to the `mesa3d-dev` (for Mesa patches) or `dri-devel` (for libdrm or kernel patches) mailing list. The `git format-patch` command can help you with that. If your patch is small enough and you feel comfortable with IRC, you can also ask for feedback on `#radeon`, having uploaded your patch to a pastebin site (e.g. [[http://radeon.pastebin.com/|here]]) or to a public Git repository of your own.
-
-=== Development Community Places ===
-
-The development centers around the source code, which is available in the [[http://cgit.freedesktop.org/mesa/mesa|Mesa Git repository]]. Most of the development discussion actually takes place on IRC, in `#radeon` on `irc.freenode.net`. Some discussions, particularly about [[Gallium3D]], also take place in the channel `#dri-devel`. [[http://people.freedesktop.org/~cbrill/dri-log/|IRC logs]] of past discussions are available. The second most important place are the [[MailingLists|relevant mailing lists]]. Furthermore, many developers visit the [[http://www.phoronix.com/forums/forumdisplay.php?f=43|Phoronix forums]], where they will often provide useful information; however, development discussions usually do not take place there.
-
-There are also several developers' blogs which are aggregated on [[http://planet.freedesktop.org/|Planet Freedesktop]], and an (also aggregated) extremely irregular [[http://tirdc.livejournal.com/|blog specifically about Radeon development]].
-
-=== Development Resources ===
-
- * [[R300Compiler]] provides some information about the shader compiler for R300-R500
- * Hardware Information
-  * [[http://www.x.org/docs/AMD/|Hardware documentation from AMD]]
-  * [[ATIRadeon]]: Chipset naming, and various information that maybe should be integrated in a nicer way
-  * [[Radeon%Architecture|Radeon Architecture]] - mostly superseded by the documentation from AMD
-  * R300-R500
-   * [[R300ToDo]]
-   * [[R300Textures]]
-   * [[Radeon200M]]
-  * R000-R700
-   * [[R600ToDo]]
- * [[ToDo|General Todo list]]
- * Various collected links (may benefit from updating):
-  * [[MesaDriver]]: How to write a Mesa driver (only applies to classic drivers and the Mesa state tracker, but not to [[Gallium3D]] drivers)
-  * [[http://dri.sourceforge.net/doc/hardware_locking_low_level.html|A locking mechanism for the DRI]] (no longer applies to DRI2)
-  * [[ReverseEngineering]]: Reverse engineering tools
- * Old TiRDCs: [[Radeon%Companion%1]], [[Radeon_Companion_2]], [[Radeon_Companion_3]], [[Radeon_Companion_4]]
diff --git a/Radeon200M.mdwn b/Radeon200M.mdwn
new file mode 100644
index 0000000..e4a1058
--- /dev/null
+++ b/Radeon200M.mdwn
@@ -0,0 +1,257 @@
+
+
+# Chipset Name
+
+Radeon 200M (RS480) 
+
+PCI Express card, using 128M of sideport memory. (No) 
+
+
+## Status
+
+I've gotten the IGPGART programmed and working using the info from the mmio-traces I took, code in my drm tree. However the 3D driver causes that card to lockup on initial access which isn't too good, but we can get CP acceleration now at least.. - airlied 
+
+The card appears to have a PCI GART but attempts to use this have failed on my system - airlied. I've attempted to move the CP into the last 8MBs of the pre-allocated framebuffer and move all the buffer mappings in there as well. This seemed to work for getting CP acceleration for the 2D driver. However attempts to make the 3D driver run failed miserably, it may be a simple problem with the buffer mappings for the r300 memory manager code, but I think it is probably a bit deeper, accessing the framebuffer while the CP is running has sometimes been known to be flaky on other radeons. I'm trying to access it via main RAM so it should work, but doesn't... - airlied 
+
+I've ran mmio-trace on the fglrx kernel module and gotten a bunch of indirect register access at 0x168, 0x16c, the 0x2c write looked like an address, and there looks to be a GART table at that address, so perhaps with AGP_BASE + MC_AGP_LOCATION programmed, it will use this GART table. It writes some other registers in this indirect area as well... so that needs some work... I've annotated some of the cpu parsed log at [[http://www.skynet.ie/~airlied/radeon/r200m/cpu-parsed|http://www.skynet.ie/~airlied/radeon/r200m/cpu-parsed]] - airlied 19/02/07 
+
+In the current git tree, if DRM is enabled, the X server will hang upon startup.  This is because it is waiting for the CP to initialize.  The driver submits some commands, and the X server loops infinitely waiting for the CP to become idle.  This is probably a bug.. the Xserver should probably wait some reasonable amount of time and then exit (rather than infinitely consuming a whole bunch of CPU.)  
+
+In my local tree, if I set MC_AGP_LOCATION to match that of fglrx driver & force PCIE express mode, the X server at least comes up. There is no stipple and the xserver hangs after moving the cursor around. 
+
+
+### Open Issues
+
+
+#### The memory map is different between the 8.23.5 fglrx driver and the Xorg driver.
+
+I don't know if this is a problem.  
+
+fgrlx: 
+[[!format txt """
+[34] 0  0       0xc01203b0 - 0xc01203bb (0xc) IS[B]
+[35] 0  0       0xc01203c0 - 0xc01203df (0x20) IS[B]
+"""]]
+Opensource driver: 
+
+
+[[!format txt """
+[33] 0  0       0x000003b0 - 0x000003bb (0xc) IS[B]
+[34] 0  0       0x000003c0 - 0x000003df (0x20) IS[B]
+"""]]
+Look how the addresses are different.  
+
+This should provide me more info about what these mean:  [[http://www.xfree86.org/current/DESIGN9.html|http://www.xfree86.org/current/DESIGN9.html]] 
+
+
+#### The stipple pattern never appears on the screen.
+
+When DRI is enabled, the CP does not appear to be working.  The indirect buffer is never executed.. Infact, I don't even think that the ring buffer is working properly. (Because the CP_IB_BASE is set to 0x00000000) 
+
+The CP configuration for the fglrx 8.32.5 driver is as follows:  
+
+
+[[!format txt """
+memory_aperture=0xc8000000
+register_aperture=0xc0100000
+MEM_BASE=0xc8000008
+MC_FB_LOCATION=0x57ff5000
+MC_AGP_LOCATION=0x5fff5800
+DISPLAY_BASE_ADDR=0x50000000
+OVERLAY_BASE_ADDR=0x50000000
+AGP_BASE=0x58000000
+----------------- CP registers ------------------
+RADEON_CP_RB_BASE=0x58000000
+RADEON_CP_RB_CNTL=0x08040f11
+RADEON_CP_RB_RPTR_ADDR=0x00000000
+RADEON_CP_RB_RPTR=0x0001b150
+RADEON_CP_RB_WPTR=0x0001b150
+RADEON_CP_RB_WPTR_DELAY=0x00000000
+RADEON_CP_IB_BASE=0x58710000
+RADEON_CP_CSQ_CNTL=0x80000000
+"""]]
+and the values for my current hacked radeon drivers are:  
+[[!format txt """
+memory_aperture=0xc8000000
+register_aperture=0xc0100000
+MEM_BASE=0xc8000008
+MC_FB_LOCATION=0x57ff5000
+MC_AGP_LOCATION=0x5fff5800
+DISPLAY_BASE_ADDR=0x50000000
+OVERLAY_BASE_ADDR=0x50000000
+AGP_BASE=0x00000000
+----------------- CP registers ------------------
+RADEON_CP_RB_BASE=0x58000000
+RADEON_CP_RB_CNTL=0x00000011
+RADEON_CP_RB_RPTR_ADDR=0x3471e000
+RADEON_CP_RB_RPTR=0x0000001e
+RADEON_CP_RB_WPTR=0x0000001e
+RADEON_CP_RB_WPTR_DELAY=0x00000000
+RADEON_CP_IB_BASE=0x00000000
+RADEON_CP_CSQ_CNTL=0x40000000
+"""]]
+Here are some interesting differences: 
+
+      * The AGP_BASE for the fglrx is set to 0x58000000 (same as the CP_RB_BASE). For the radeon driver, the AGP_BASE is set to 0x00000000.  
+      * The CP_RB_RPTR_ADDR is set to 0x00000000 for fglrx, and to 0x3471e000 for the radeon driver.  Maybe the 0x00000 indicates some magic offset where the ring buffer should be stored.  
+      * The CP read and write pointers have advanced for the fglrx, so the CP is working for the fglrx.   
+      * For the radeon driver, look at how the RADEON_CP_IB_BASE is 0, so the CP (I think) never received the command to execute an indirect buffer.  
+
+#### After a few second of mouse movement, the box hangs.
+
+      * I suspect that this is related to the improper command processor setup.  
+
+#### PCIE GART
+
+I don't know how the GART is setup for this card.  None of the RADEON_PCIE registers are called in the trace of 8.32.5.  
+
+All attemps to dump this areas when fglrx is running return 0. 
+
+Something funny is going on..  
+
+UPDATE: I looks like Dave got a step further in understanding this.  Using kmmio to trap the different accesses going on in kernel space, it appears that the 0x168 and 0x16C registers are indirect registers for configuring the memory controller.  
+
+Also, the accesses to 0x168/0x16C seem to have the following pattern: 
+
+      * Write to 0x168 (setup the index)  (Where 0x100 indicates a write..) 
+      * Read/Write to/from 0x16C 
+      * Write 7f to 0x168 (Maybe a commit or something?)  
+I turned on PC recording in kmmio. It reveals some interesting things about what those indirect memory accesses are doing.  First, all of the calls to the 168/16C registers are in: MCIL_Modify``Register (So it looks like this is the Memory Controller that it is accessing.) 
+
+Next, I recorded the address of the function which called MCIL_Modify``Register: 
+[[!format txt """
+  read[18] -> 0x00001000 _ZN9GartRS48023InitializeGartRegistersEv
+write[118] <- 0x00001000 _ZN9GartRS48023InitializeGartRegistersEv
+write[138] <- 0x00000005 _ZN9GartRS48023InitializeGartRegistersEv
+  read[2b] -> 0x00000000 _ZN9GartRS48023InitializeGartRegistersEv
+write[12b] <- 0x42040800 _ZN9GartRS48023InitializeGartRegistersEv
+write[12c] <- 0x33b00000 _ZN9GartRS48023InitializeGartRegistersEv
+  read[39] -> 0x01400000 _ZN9GartRS48023InitializeGartRegistersEv
+write[139] <- 0x01400000 _ZN9GartRS48023InitializeGartRegistersEv
+
+  read[38] -> 0x00000005 _ZN9GartRS48010EnableGartEv
+write[138] <- 0x00000005 _ZN9GartRS48010EnableGartEv
+
+  read[2e] -> 0x00000000 _ZN9GartRS48012flushGartTLBEv
+write[12e] <- 0x00000001 _ZN9GartRS48012flushGartTLBEv
+  read[2e] -> 0x00000000 _ZN9GartRS48012flushGartTLBEv
+write[12e] <- 0x00000000 _ZN9GartRS48012flushGartTLBEv
+
+  read[2e] -> 0x00000000 _ZN9GartRS48012flushGartTLBEv
+write[12e] <- 0x00000001 _ZN9GartRS48012flushGartTLBEv
+  read[2e] -> 0x00000000 _ZN9GartRS48012flushGartTLBEv
+write[12e] <- 0x00000000 _ZN9GartRS48012flushGartTLBEv
+"""]]
+So, some interesting things come out of this: I think that: 
+
+      * 38/138 turns on the GART.  (Write 0x5) 
+      * 2e/12e flushs the Gart TLB (Write 0x1 and then 0x0) 
+      * 2c/12c The address of the GART table (Write the physical address of the GART table) 
+      * 2b/12b (?)  (Write 0x42040800) 
+      * 18/118 (?)  (Read and then write 0x00001000) 
+      * 39/139 (?)  (Read and then write 0x01400000) 
+Comment by Slice: "Chips R200-RV280 use reg 1d8 for address of PCI Gart table Chips R300-RV420 use res ab0 - Lo 32 bits, ab4 - Hi 32 bits of Gart table address reg 1d0 has bit 0 for PCI_GART_ENABLE in both cases" 
+
+
+## HW Config
+
+Radeon 200M (RS480) PCI Express 128 M sideport memory (UMA/system memory usage disabled.) 
+
+
+[[!format txt """
+01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS 200M 5955 (PCIE) (prog-if 00 [VGA])
+        Subsystem: Hewlett-Packard Company Unknown device 30a4
+        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
+        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
+        Latency: 66 (2000ns min), Cache Line Size 08
+        Interrupt: pin A routed to IRQ 7
+        Region 0: Memory at c0000000 (32-bit, prefetchable) [size=256M]
+        Region 1: I/O ports at 9000 [size=256]
+        Region 2: Memory at b0100000 (32-bit, non-prefetchable) [size=64K]
+        [virtual] Expansion ROM at b0120000 [disabled] [size=128K]
+        Capabilities: [50] Power Management version 2
+                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
+                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
+"""]]
+NOTE: The firegl 8.32.5 driver works with this card ONLY if I use 128M of sideport. (No UMA) NOTE2: The 8.24.5 fglrx driver works if I have 128M UMA + 128M of sideport.  
+
+
+## Specifications
+
+
+### Architecture
+
+(Coming soon)  
+
+
+### Reviews
+
+Some of these are of the Radeon200, but they basically apply:  
+
+[[http://www.techreport.com/reviews/2004q4/radeon-xpress200/index.x?pg=1|http://www.techreport.com/reviews/2004q4/radeon-xpress200/index.x?pg=1]] [[http://3dgpu.com/archives/2004/11/08/ati-radeon-xpress-200g-review/|http://3dgpu.com/archives/2004/11/08/ati-radeon-xpress-200g-review/]] [[http://www.driverheaven.net/reviews/RadeonXpress/|http://www.driverheaven.net/reviews/RadeonXpress/]] [[http://www.hothardware.com/viewarticle.cfm?articleid=597&cid=3|http://www.hothardware.com/viewarticle.cfm?articleid=597&cid=3]] [[http://www.pcper.com/article.php?aid=88|http://www.pcper.com/article.php?aid=88]] [[http://techreport.com/reviews/2004q4/radeon-xpress200/index.x?pg=1|http://techreport.com/reviews/2004q4/radeon-xpress200/index.x?pg=1]] 
+
+
+## Resources
+
+ATI's 200M page:  [[http://ati.amd.com/products/Radeonxpress200m/index.html|http://ati.amd.com/products/Radeonxpress200m/index.html]] 
+
+White paper about hypermemory:  [[http://www.ati.com/technology/HyperMemory_Whitepaper.pdf|http://www.ati.com/technology/HyperMemory_Whitepaper.pdf]] 
+
+Another man's OpenGL problems with the 200M under windows: [[http://fixthe200m.wordpress.com/|http://fixthe200m.wordpress.com/]] 
+
+
+## Handy Facts for Radeon Reverse engineers
+
+   * It seems that the commands issued to the CP are just register,value pairs... You could issue these directly using MMIOs, but when you hand it to the CP, it will do the work for you. (If someone know better, please tell me..)  
+   * The Radeon Xserver uses DRI to draw the stipple pattern, so if you see it on the screen, the CP is at least partially working.. 
+   * Here's a pretty good explanation about how the radeon deals with memory (bus view vs. card view):  
+         * [[http://lists.freedesktop.org/archives/xorg/2005-May/007673.html|http://lists.freedesktop.org/archives/xorg/2005-May/007673.html]] 
+
+### Tracing MMIOs
+
+One way to figure out how the driver interacts with the card is either to:  
+#### Dump the registers
+
+This contains a link to a generic MMIO register dumper:  [[http://gatos.sourceforge.net/apps.php|http://gatos.sourceforge.net/apps.php]] (In particular, an (untried) windows version is at: [[http://gatos.sourceforge.net/hws_win.zip|http://gatos.sourceforge.net/hws_win.zip]]) 
+
+Radeon Dump: [[http://www.botchco.com/alex/radeon/mergedfb/cvs/DRI/hy0/radeon_dump.tgz|http://www.botchco.com/alex/radeon/mergedfb/cvs/DRI/hy0/radeon_dump.tgz]] 
+
+RADEON tool: [[http://gitweb.freedesktop.org/?p=users/airlied/radeontool.git;a=summary|http://gitweb.freedesktop.org/?p=users/airlied/radeontool.git;a=summary]] 
+
+
+#### Trace the register accesses
+
+Trace userspace MMIOs: [[http://people.freedesktop.org/~glisse/libsegfault.tar.bz2|http://people.freedesktop.org/~glisse/libsegfault.tar.bz2]] 
+
+Trace kernelspace MMIOs: git://people.freedesktop.org/~jrmuizel/mmio-trace 
+
+
+### Decoding accesses
+
+Here's some code to convert register names/values to human readable text: [[http://ozlabs.org/~jk/code/bitfield/|http://ozlabs.org/~jk/code/bitfield/]] 
+
+I'm currently working on a config file for the radeon_RS480, but I imagine much of the R300 family is similar.  
+
+
+#### Radeon Registers
+
+NOTE: It is unclear what all of the registers do, so there seems to be a smattering of different places which define this.  
+
+DRM: (FIXME) 
+
+Radeon Xorg Driver: (FIXME) 
+
+Mplayer's list:  
+
+   * [[http://svn.mplayerhq.hu/mplayer/trunk/drivers/radeon.h?view=markup|http://svn.mplayerhq.hu/mplayer/trunk/drivers/radeon.h?view=markup]] 
+The Kernel's list:  
+
+   * [[http://www.gelato.unsw.edu.au/lxr/source/include/video/radeon.h|http://www.gelato.unsw.edu.au/lxr/source/include/video/radeon.h]] 
+Possibly related: 
+
+   * [[http://www.handhelds.org/moin/moin.cgi/w100MMRegisters|http://www.handhelds.org/moin/moin.cgi/w100MMRegisters]] 
+
+
+---
+
+ [[CategoryHardwareChipset|CategoryHardwareChipset]] 
diff --git a/Radeon200M.moin b/Radeon200M.moin
deleted file mode 100644
index 6fafb7f..0000000
--- a/Radeon200M.moin
+++ /dev/null
@@ -1,260 +0,0 @@
-= Chipset Name =
-Radeon 200M (RS480)
-
-PCI Express card, using 128M of sideport memory. (No)
-
-== Status ==
-
-I've gotten the IGPGART programmed and working using the info from the mmio-traces I took, code in my drm tree. However the 3D driver causes that card to lockup on initial access which isn't too good, but
-we can get CP acceleration now at least.. - airlied
-
-The card appears to have a PCI GART but attempts to use this have failed on my system - airlied.
-I've attempted to move the CP into the last 8MBs of the pre-allocated framebuffer and move all the buffer mappings in there as well. This seemed to work for getting CP acceleration for the 2D driver. However attempts to make the 3D driver run failed miserably, it may be a simple problem with the buffer mappings for the r300 memory manager code, but I think it is probably a bit deeper, accessing the framebuffer while the CP is running has sometimes been known to be flaky on other radeons. I'm trying to access it via main RAM so it should work, but doesn't... - airlied
-
-I've ran mmio-trace on the fglrx kernel module and gotten a bunch of indirect register access at 0x168, 0x16c, the 0x2c write looked like an address, and there looks to be a GART table at that address, so perhaps with AGP_BASE + MC_AGP_LOCATION programmed, it will use this GART table. It writes some other registers in this indirect area as well... so that needs some work...
-I've annotated some of the cpu parsed log at http://www.skynet.ie/~airlied/radeon/r200m/cpu-parsed - airlied 19/02/07
- 
-In the current git tree, if DRM is enabled, the X server will hang upon startup.  This is because it is waiting for the CP to initialize.  The driver submits some commands, and the X server loops infinitely waiting for the CP to become idle.  This is probably a bug.. the Xserver should probably wait some reasonable amount of time and then exit (rather than infinitely consuming a whole bunch of CPU.) 
-
-In my local tree, if I set MC_AGP_LOCATION to match that of fglrx driver & force PCIE express mode, the X server at least comes up. There is no stipple and the xserver hangs after moving the cursor around.
-
-=== Open Issues ===
-==== The memory map is different between the 8.23.5 fglrx driver and the Xorg driver. ====
-
-I don't know if this is a problem. 
-
-fgrlx:
-{{{
-[34] 0  0       0xc01203b0 - 0xc01203bb (0xc) IS[B]
-[35] 0  0       0xc01203c0 - 0xc01203df (0x20) IS[B]
-}}}
-Opensource driver:
-
-{{{
-[33] 0  0       0x000003b0 - 0x000003bb (0xc) IS[B]
-[34] 0  0       0x000003c0 - 0x000003df (0x20) IS[B]
-}}}
-
-Look how the addresses are different. 
-
-This should provide me more info about what these mean:  http://www.xfree86.org/current/DESIGN9.html
-
-==== The stipple pattern never appears on the screen. ====
-
-When DRI is enabled, the CP does not appear to be working.  The indirect buffer is never executed.. Infact, I don't even think that the ring buffer is working properly. (Because the CP_IB_BASE is set to 0x00000000)
-
-The CP configuration for the fglrx 8.32.5 driver is as follows: 
-  
-{{{
-memory_aperture=0xc8000000
-register_aperture=0xc0100000
-MEM_BASE=0xc8000008
-MC_FB_LOCATION=0x57ff5000
-MC_AGP_LOCATION=0x5fff5800
-DISPLAY_BASE_ADDR=0x50000000
-OVERLAY_BASE_ADDR=0x50000000
-AGP_BASE=0x58000000
------------------ CP registers ------------------
-RADEON_CP_RB_BASE=0x58000000
-RADEON_CP_RB_CNTL=0x08040f11
-RADEON_CP_RB_RPTR_ADDR=0x00000000
-RADEON_CP_RB_RPTR=0x0001b150
-RADEON_CP_RB_WPTR=0x0001b150
-RADEON_CP_RB_WPTR_DELAY=0x00000000
-RADEON_CP_IB_BASE=0x58710000
-RADEON_CP_CSQ_CNTL=0x80000000
-}}}
-
-and the values for my current hacked radeon drivers are: 
-{{{
-memory_aperture=0xc8000000
-register_aperture=0xc0100000
-MEM_BASE=0xc8000008
-MC_FB_LOCATION=0x57ff5000
-MC_AGP_LOCATION=0x5fff5800
-DISPLAY_BASE_ADDR=0x50000000
-OVERLAY_BASE_ADDR=0x50000000
-AGP_BASE=0x00000000
------------------ CP registers ------------------
-RADEON_CP_RB_BASE=0x58000000
-RADEON_CP_RB_CNTL=0x00000011
-RADEON_CP_RB_RPTR_ADDR=0x3471e000
-RADEON_CP_RB_RPTR=0x0000001e
-RADEON_CP_RB_WPTR=0x0000001e
-RADEON_CP_RB_WPTR_DELAY=0x00000000
-RADEON_CP_IB_BASE=0x00000000
-RADEON_CP_CSQ_CNTL=0x40000000
-}}}
-
-Here are some interesting differences:
-   * The AGP_BASE for the fglrx is set to 0x58000000 (same as the CP_RB_BASE). For the radeon driver, the AGP_BASE is set to 0x00000000. 
-
-   * The CP_RB_RPTR_ADDR is set to 0x00000000 for fglrx, and to 0x3471e000 for the radeon driver.  Maybe the 0x00000 indicates some magic offset where the ring buffer should be stored. 
- 
-   * The CP read and write pointers have advanced for the fglrx, so the CP is working for the fglrx.  
-
-   * For the radeon driver, look at how the RADEON_CP_IB_BASE is 0, so the CP (I think) never received the command to execute an indirect buffer. 
-
-
-==== After a few second of mouse movement, the box hangs.   ====
-   I suspect that this is related to the improper command processor setup. 
-
-==== PCIE GART ====
-
-I don't know how the GART is setup for this card.  None of the RADEON_PCIE registers are called in the trace of 8.32.5. 
-
-All attemps to dump this areas when fglrx is running return 0.
-
-Something funny is going on.. 
-
-UPDATE:
-I looks like Dave got a step further in understanding this.  Using kmmio to trap the different accesses going on in kernel space, it appears that the 0x168 and 0x16C registers are indirect registers for configuring the memory controller. 
-
-Also, the accesses to 0x168/0x16C seem to have the following pattern:
-   * Write to 0x168 (setup the index)  (Where 0x100 indicates a write..)
-   * Read/Write to/from 0x16C
-   * Write 7f to 0x168 (Maybe a commit or something?) 
-
-I turned on PC recording in kmmio. It reveals some interesting things about what those indirect memory accesses are doing.  First, all of the calls to the 168/16C registers are in: MCIL_Modify``Register (So it looks like this is the Memory Controller that it is accessing.)
-
-Next, I recorded the address of the function which called MCIL_Modify``Register:
-{{{
-  read[18] -> 0x00001000 _ZN9GartRS48023InitializeGartRegistersEv
-write[118] <- 0x00001000 _ZN9GartRS48023InitializeGartRegistersEv
-write[138] <- 0x00000005 _ZN9GartRS48023InitializeGartRegistersEv
-  read[2b] -> 0x00000000 _ZN9GartRS48023InitializeGartRegistersEv
-write[12b] <- 0x42040800 _ZN9GartRS48023InitializeGartRegistersEv
-write[12c] <- 0x33b00000 _ZN9GartRS48023InitializeGartRegistersEv
-  read[39] -> 0x01400000 _ZN9GartRS48023InitializeGartRegistersEv
-write[139] <- 0x01400000 _ZN9GartRS48023InitializeGartRegistersEv
-
-  read[38] -> 0x00000005 _ZN9GartRS48010EnableGartEv
-write[138] <- 0x00000005 _ZN9GartRS48010EnableGartEv
-
-  read[2e] -> 0x00000000 _ZN9GartRS48012flushGartTLBEv
-write[12e] <- 0x00000001 _ZN9GartRS48012flushGartTLBEv
-  read[2e] -> 0x00000000 _ZN9GartRS48012flushGartTLBEv
-write[12e] <- 0x00000000 _ZN9GartRS48012flushGartTLBEv
-
-  read[2e] -> 0x00000000 _ZN9GartRS48012flushGartTLBEv
-write[12e] <- 0x00000001 _ZN9GartRS48012flushGartTLBEv
-  read[2e] -> 0x00000000 _ZN9GartRS48012flushGartTLBEv
-write[12e] <- 0x00000000 _ZN9GartRS48012flushGartTLBEv
-}}}
-
-So, some interesting things come out of this:
-I think that:
-   * 38/138 turns on the GART.  (Write 0x5)
-   * 2e/12e flushs the Gart TLB (Write 0x1 and then 0x0)
-   * 2c/12c The address of the GART table (Write the physical address of the GART table)
-   * 2b/12b (?)  (Write 0x42040800)
-   * 18/118 (?)  (Read and then write 0x00001000)
-   * 39/139 (?)  (Read and then write 0x01400000)
-
-Comment by Slice:
-"Chips R200-RV280 use reg 1d8 for address of PCI Gart table
-Chips R300-RV420 use res ab0 - Lo 32 bits, ab4 - Hi 32 bits of Gart table address
-reg 1d0 has bit 0 for PCI_GART_ENABLE in both cases"
-
-== HW Config ==
-Radeon 200M (RS480)
-PCI Express
-128 M sideport memory (UMA/system memory usage disabled.)
-
-{{{
-01:05.0 VGA compatible controller: ATI Technologies Inc ATI Radeon XPRESS 200M 5955 (PCIE) (prog-if 00 [VGA])
-        Subsystem: Hewlett-Packard Company Unknown device 30a4
-        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
-        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
-        Latency: 66 (2000ns min), Cache Line Size 08
-        Interrupt: pin A routed to IRQ 7
-        Region 0: Memory at c0000000 (32-bit, prefetchable) [size=256M]
-        Region 1: I/O ports at 9000 [size=256]
-        Region 2: Memory at b0100000 (32-bit, non-prefetchable) [size=64K]
-        [virtual] Expansion ROM at b0120000 [disabled] [size=128K]
-        Capabilities: [50] Power Management version 2
-                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
-                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
-}}}
-
-NOTE: The firegl 8.32.5 driver works with this card ONLY if I use 128M of sideport. (No UMA)
-NOTE2: The 8.24.5 fglrx driver works if I have 128M UMA + 128M of sideport. 
-
-== Specifications ==
-
-=== Architecture ===
-(Coming soon) 
-
-=== Reviews ===
-
-Some of these are of the Radeon200, but they basically apply: 
-
-http://www.techreport.com/reviews/2004q4/radeon-xpress200/index.x?pg=1
-http://3dgpu.com/archives/2004/11/08/ati-radeon-xpress-200g-review/
-http://www.driverheaven.net/reviews/RadeonXpress/
-http://www.hothardware.com/viewarticle.cfm?articleid=597&cid=3
-http://www.pcper.com/article.php?aid=88
-http://techreport.com/reviews/2004q4/radeon-xpress200/index.x?pg=1
-
-== Resources ==
-ATI's 200M page: 
-http://ati.amd.com/products/Radeonxpress200m/index.html
-
-White paper about hypermemory: 
-http://www.ati.com/technology/HyperMemory_Whitepaper.pdf
-
-Another man's OpenGL problems with the 200M under windows:
-http://fixthe200m.wordpress.com/
-
-== Handy Facts for Radeon Reverse engineers ==
-  * It seems that the commands issued to the CP are just register,value pairs... You could issue these directly using MMIOs, but when you hand it to the CP, it will do the work for you. (If someone know better, please tell me..) 
-
-  * The Radeon Xserver uses DRI to draw the stipple pattern, so if you see it on the screen, the CP is at least partially working..
-
-  * Here's a pretty good explanation about how the radeon deals with memory (bus view vs. card view): 
-    http://lists.freedesktop.org/archives/xorg/2005-May/007673.html
-
-=== Tracing MMIOs ===
-One way to figure out how the driver interacts with the card is either to: 
-==== Dump the registers ====
-This contains a link to a generic MMIO register dumper: 
-http://gatos.sourceforge.net/apps.php
-(In particular, an (untried) windows version is at: http://gatos.sourceforge.net/hws_win.zip)
-
-Radeon Dump:
-http://www.botchco.com/alex/radeon/mergedfb/cvs/DRI/hy0/radeon_dump.tgz
-
-RADEON tool:
-http://gitweb.freedesktop.org/?p=users/airlied/radeontool.git;a=summary
-
-==== Trace the register accesses ====
-Trace userspace MMIOs:
-http://people.freedesktop.org/~glisse/libsegfault.tar.bz2
-
-Trace kernelspace MMIOs:
-git://people.freedesktop.org/~jrmuizel/mmio-trace
-
-=== Decoding accesses ===
-
-Here's some code to convert register names/values to human readable text: http://ozlabs.org/~jk/code/bitfield/
-
-I'm currently working on a config file for the radeon_RS480, but I imagine much of the R300 family is similar. 
-
-==== Radeon Registers ====
-NOTE: It is unclear what all of the registers do, so there seems to be a smattering of different places which define this. 
-
-DRM: (FIXME)
-
-Radeon Xorg Driver: (FIXME)
-
-Mplayer's list: 
-  http://svn.mplayerhq.hu/mplayer/trunk/drivers/radeon.h?view=markup
-
-The Kernel's list: 
-  http://www.gelato.unsw.edu.au/lxr/source/include/video/radeon.h
-
-Possibly related:
-  http://www.handhelds.org/moin/moin.cgi/w100MMRegisters
-
-----
-CategoryHardwareChipset
diff --git a/RadeonTroubleshooting.mdwn b/RadeonTroubleshooting.mdwn
new file mode 100644
index 0000000..0a45873
--- /dev/null
+++ b/RadeonTroubleshooting.mdwn
@@ -0,0 +1,36 @@
+
+
+# Radeon Troubleshooting
+
+This page contains known problems and their solutions, as well as techniques for troubleshooting issues related to 3D acceleration using the _open source_ drivers. See also the [[portal page|Radeon]]. 
+
+This page is clearly not very useful in its current form. If you are a user and you have just solved a problem that you ran into, please help us make this page better by adding or improving the information contained in here! 
+
+[[!toc ]] 
+
+
+## Troubleshooting Techniques
+
+This section should contain information about typical techniques that are useful in troubleshooting. 
+
+* Check the output of [[glxinfo|glxinfo]] for hints as to what goes wrong. 
+* To reboot in a safer manner when your system locks up completely, try **Magic Sys Rq** in linux. (Ctrl + alt + Sys Rq   S  U  B ). 
+Random pieces of information that could be integrated: 
+
+* [[DriConf|DriConf]] 
+* LIBGL_DRIVERS_DIR, LIBGL_ALWAYS_SOFTWARE, LIBGL_ALWAYS_INDIRECT, LIBGL_DEBUG 
+
+## Symptoms
+
+
+### glxgears is very slow
+
+**Note that `glxgears` is not a benchmark**. It doesn't matter if it renders at 3000, 5000 or 15000 fps - the only thing it can do, is show whether 3d acceleration is working: if `glxgears` renders at fewer than 500-1000 frames per second, there is a good chance that your DRI driver is not installed or is not working correctly. 
+
+If you ever come across this situation, you'll probably wish to find out the cause - and solve it. Here's how: 
+
+First of all, you need to confirm that you are indeed falling back to software rendering. Check the output of [[glxinfo|glxinfo]] according to the information on the [[glxinfo|glxinfo]] page. 
+
+The next step is to find out _why_ you are falling back to software rendering. Check `/var/log/Xorg.0.log` for errors (`'cat /var/log/Xorg.0.log | grep EE'` will return all errors from that file). 
+
+Todo: add more information on potential errors and their causes. Todo: what happens if `glxgears` is very slow, but we are not falling back to software rendering? 
diff --git a/RadeonTroubleshooting.moin b/RadeonTroubleshooting.moin
deleted file mode 100644
index 13eac9d..0000000
--- a/RadeonTroubleshooting.moin
+++ /dev/null
@@ -1,33 +0,0 @@
-= Radeon Troubleshooting =
-
-This page contains known problems and their solutions, as well as techniques for troubleshooting issues related to 3D acceleration using the ''open source'' drivers. See also the [[Radeon|portal page]].
-
-This page is clearly not very useful in its current form. If you are a user and you have just solved a problem that you ran into, please help us make this page better by adding or improving the information contained in here!
-
-<<TableOfContents>>
-
-== Troubleshooting Techniques ==
-
-This section should contain information about typical techniques that are useful in troubleshooting.
- * Check the output of [[glxinfo]] for hints as to what goes wrong.
- * To reboot in a safer manner when your system locks up completely, try '''Magic Sys Rq''' in linux. (Ctrl + alt + Sys Rq   S  U  B ).
-
-Random pieces of information that could be integrated:
- * [[DriConf]]
- * LIBGL_DRIVERS_DIR, LIBGL_ALWAYS_SOFTWARE, LIBGL_ALWAYS_INDIRECT, LIBGL_DEBUG
-
-
-== Symptoms ==
-
-=== glxgears is very slow ===
-
-'''Note that `glxgears` is not a benchmark'''. It doesn't matter if it renders at 3000, 5000 or 15000 fps - the only thing it can do, is show whether 3d acceleration is working: if `glxgears` renders at fewer than 500-1000 frames per second, there is a good chance that your DRI driver is not installed or is not working correctly.
-
-If you ever come across this situation, you'll probably wish to find out the cause - and solve it. Here's how:
-
-First of all, you need to confirm that you are indeed falling back to software rendering. Check the output of [[glxinfo]] according to the information on the [[glxinfo]] page.
-
-The next step is to find out ''why'' you are falling back to software rendering. Check `/var/log/Xorg.0.log` for errors (`'cat /var/log/Xorg.0.log | grep EE'` will return all errors from that file).
-
-Todo: add more information on potential errors and their causes.
-Todo: what happens if `glxgears` is very slow, but we are not falling back to software rendering?
diff --git a/Radeon_Companion_2.mdwn b/Radeon_Companion_2.mdwn
new file mode 100644
index 0000000..265bb1b
--- /dev/null
+++ b/Radeon_Companion_2.mdwn
@@ -0,0 +1,45 @@
+
+
+# The irregular Radeon-Development companion
+
+
+## Issue for 2007-03-20
+
+
+## Intro
+
+This page is an accumulation of the events happening in Radeon development, mainly on IRC or on dri-devel. The concept has been shamelessly copied from [[nouveau|http://nouveau.freedesktop.org]] and will hopefully be kept up. At least this is the second issue. So didn't immediately stop. 
+
+We got a lot of positive responses to the first TiRDC. Many people wondered who was writing it up. Many people felt honored for being named as supporter in this project. And we also got technical responses. So it's time for the next issue! 
+
+
+## Ongoing work
+
+* Since some people don't hang around on the IRC channel #dri-devel, _Christoph Brill (egore)_ decided to set up some **IRC logs**. Currently the logging is uploaded every midnight at GMT+1 to [[http://people.freedesktop.org/~cbrill/dri-log/|http://people.freedesktop.org/~cbrill/dri-log/]] . They can be used as a reference for discussions and will be referenced in this issue. 
+* Oliver [[McFadden|McFadden]] (z3ro) got an account as R300 developer and **continued the cleanup**. He did some synchronisation between drm and mesa source files ([[Source|http://gitweb.freedesktop.org/?p=mesa/drm.git;a=commit;h=130c39be3cf9a5fd742aa6b00d0383e96bbbd7b7]]), started renaming some unkXXXX registers ([[Source|http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commit;h=e64166703a27c5b1127373b1dff3b93e617bcaea]]) and created some discussion with his work. He added some defines for hardcoded values without knowing their exact purpose. On IRC it was agreed to add an "UNKOWN" to the defines and all was fine. 
+* Also Nicolai Haehnle (nh) got his account approved. He immediately started commiting some major work on the **R300 fragment program** that were tested by Oliver [[McFadden|McFadden]] (z3ro). As of git from 2007-03-10 the fragment program should pretty much work. ([[Source|http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commit;h=61821a41c07b6b383a275acf31ade56af2ecfb3c]]) 
+* There is a new toy around named **Piglit**, written up as a automated testing and regression suite using glean. It is written Nicolai Haehnle (nh) and nicely shows [[regressions or improvements|http://people.freedesktop.org/~nh/piglit/sample/index.html]] in the R300 code. It can used to test any 3D driver, but main focus relies on R300 for now. Try downloading [[Piglit|http://people.freedesktop.org/~nh/piglit/]] and run it on your hardware. It revealed an ironic statement about stability: R300 sometimes is suspected to be unstable, but ran all the test without crashing, while fglrx hard locked the system of Christoph Brill (egore) at the first test. 
+* Oliver [[McFadden|McFadden]] (z3ro) took the suggestion by Christoph Brill (egore) and renamed his reverse engineering tool r300reveng to **revenge** ([[Source|http://people.freedesktop.org/~cbrill/dri-log/dri-devel-2007-03-13.log]]). Currently Oliver [[McFadden|McFadden]] (z3ro) is working on it and looking at renouveau, iba and glxtest to get ideas on how to trace everything correctly. There were some discussions with Michael Daenzer ([[MrCooper|MrCooper]]) about the need of MMIO in that tool and about reading from IOCTLS. Most of the basic work is currently in progress but coming along nicely. Airlied pointed out that accessing memory using /dev/mem and dumping indirect buffers (like iba) is only necessary for access to an external process, but some dumping from /proc/self/maps would give the same information. Olvier [[McFadden|McFadden]] (z3ro) also tries to better document the driver and the reverse engineering methods while writing this tool. 
+* The **kernel based modesetting** currently in progress by Wallbraker was reviewed by Jerome Glisse (glisse). Most of his immediate comments were of cosmetic nature (indention, "/* */" instead of "// "). The code was also reviewed by jbarnes. Until now noone sad anything bad about the code or the idea, which is a very good sign. 
+* Lately some **discussion came about about the DRM layer** in general. Dave Airlie (airlied) and Wallbraker had a lengthy conversation about it ([[Source|http://people.freedesktop.org/~cbrill/dri-log/dri-devel-2007-03-16.log]]). Dave Airlie (airlied) explained a lot of basic concepts of how framebuffer drivers get access to the hardware and what the drm does. Both agreed that putting modesetting into the DRM layer is a good idea. They also thought about framebuffer drivers that would sit on top of the DRM layer and what the gain would be if DRM would dropping support for other OS than Linux. These ideas didn't go into details and won't happen soon (or ever). Anyone intersted in framebuffer drivers init, DRM init, where modesetting should happen and about DRM in general should take a look at the upper half of [[the log|http://people.freedesktop.org/~cbrill/dri-log/dri-devel-2007-03-16.log]]. 
+* The R300 now is **officially maintained by "The DRI Project"**. Not that someone else maintained it, but the GL_VENDOR stated "Tungsten Graphics". In the discussion at [[Bug #10303|http://bugs.freedesktop.org/show_bug.cgi?id=10303]] it was agreed to change that to "The DRI Project" to avoid confusion among users. 
+* Giacomo Perale reported in a bug some glitches in rendering on his R300. These glitches seem to come from [[ColorTiling|ColorTiling]] and [[PageFlipping|PageFlipping]] enabled. Until now noone came up with good ideas or solutions yet. ([[Source|http://bugs.freedesktop.org/show_bug.cgi?id=10245]]) 
+* The **issues about fragment.position** continued again. Oliver [[McFadden|McFadden]] (z3ro) tested a patch by Rune Petersen which moves the calculation of fragment.position from the vertex program into the fragment program. Oliver [[McFadden|McFadden]] (z3ro) also found out that the simple program 
+
+[[!format txt """
+mov result.color.xy, fragment.position;
+"""]]
+works on fglrx, but not on R300. It needs 
+[[!format txt """
+mov result.color.xyz, fragment.position;
+"""]]
+to work properly. Discussion about what fglrx uses for **z** ended without solution. Jerome Glisse (glisse) suggested to spy the fragment program of fglrx. 
+
+* Last but not least Simon80 came in the IRC channel and asked about a **Google Summer of Code project to add EXA render support** to R300. Dave Airlie (airlied) and marcheu discussed about the sense and if it would possible to do so in a SoC project. They also came up with the issues someone might run into. jbarnes also noted that there might me some 64 bit issues related with that task. 
+* Really the last entry in this issue is **2D support for R500** chips. Dave Airlie (airlied) wrote some time ago a small enhancement to the xf86-video-ati code to support this chipset. The issue is that he wrote it under NDA and is not allowed to publish the source without permission of ATI (or is it AMD today?). He asked politely but the request was ignored. Now he is waiting if anyone else to get ATI/AMD to respond and to tell if he is allowed to publish the source or if he is not. If you feel like asking ATI/AMDs support for that, please be polite but direct. Maybe someone will listen to you? Also [[Michael Larabel|http://www.michaellarabel.com/index.php?k=blog&i=121]] suggests a method to get ATI/AMD to improve their binary driver. 
+
+## Help needed
+
+Currently we are making really good progress. We don't have any special needs right now but it would be great if someone could help on R500 support. There seems to be some work going on, but slowly. It would also be very helpfull to see how people succeed in running KMMIO with R300 (against latest fglrx and against an older version). 
+
+_Written by Christoph Brill (egore)_ 
diff --git a/Radeon_Companion_2.moin b/Radeon_Companion_2.moin
deleted file mode 100644
index 9fe8e15..0000000
--- a/Radeon_Companion_2.moin
+++ /dev/null
@@ -1,49 +0,0 @@
-= The irregular Radeon-Development companion =
-
-== Issue for 2007-03-20 ==
-
-== Intro ==
-
-This page is an accumulation of the events happening in Radeon development, mainly on IRC or on dri-devel. The concept has been shamelessly copied from [[http://nouveau.freedesktop.org|nouveau]] and will hopefully be kept up. At least this is the second issue. So didn't immediately stop.
-
-We got a lot of positive responses to the first TiRDC. Many people wondered who was writing it up. Many people felt honored for being named as supporter in this project. And we also got technical responses. So it's time for the next issue!
-
-== Ongoing work ==
-
- * Since some people don't hang around on the IRC channel #dri-devel, ''Christoph Brill (egore)'' decided to set up some '''IRC logs'''. Currently the logging is uploaded every midnight at GMT+1 to http://people.freedesktop.org/~cbrill/dri-log/ . They can be used as a reference for discussions and will be referenced in this issue.
-
- * Oliver McFadden (z3ro) got an account as R300 developer and '''continued the cleanup'''. He did some synchronisation between drm and mesa source files ([[http://gitweb.freedesktop.org/?p=mesa/drm.git;a=commit;h=130c39be3cf9a5fd742aa6b00d0383e96bbbd7b7|Source]]), started renaming some unkXXXX registers ([[http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commit;h=e64166703a27c5b1127373b1dff3b93e617bcaea|Source]]) and created some discussion with his work. He added some defines for hardcoded values without knowing their exact purpose. On IRC it was agreed to add an "UNKOWN" to the defines and all was fine.
-
- * Also Nicolai Haehnle (nh) got his account approved. He immediately started commiting some major work on the '''R300 fragment program''' that were tested by Oliver McFadden (z3ro). As of git from 2007-03-10 the fragment program should pretty much work. ([[http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commit;h=61821a41c07b6b383a275acf31ade56af2ecfb3c|Source]])
-
- * There is a new toy around named '''Piglit''', written up as a automated testing and regression suite using glean. It is written Nicolai Haehnle (nh) and nicely shows [[http://people.freedesktop.org/~nh/piglit/sample/index.html|regressions or improvements]] in the R300 code. It can used to test any 3D driver, but main focus relies on R300 for now. Try downloading [[http://people.freedesktop.org/~nh/piglit/|Piglit]] and run it on your hardware. It revealed an ironic statement about stability: R300 sometimes is suspected to be unstable, but ran all the test without crashing, while fglrx hard locked the system of Christoph Brill (egore) at the first test.
-
- * Oliver McFadden (z3ro) took the suggestion by Christoph Brill (egore) and renamed his reverse engineering tool r300reveng to '''revenge''' ([[http://people.freedesktop.org/~cbrill/dri-log/dri-devel-2007-03-13.log|Source]]). Currently Oliver McFadden (z3ro) is working on it and looking at renouveau, iba and glxtest to get ideas on how to trace everything correctly. There were some discussions with Michael Daenzer (MrCooper) about the need of MMIO in that tool and about reading from IOCTLS. Most of the basic work is currently in progress but coming along nicely. Airlied pointed out that accessing memory using /dev/mem and dumping indirect buffers (like iba) is only necessary for access to an external process, but some dumping from /proc/self/maps would give the same information. Olvier McFadden (z3ro) also tries to better document the driver and the reverse engineering methods while writing this tool.
-
- * The '''kernel based modesetting''' currently in progress by Wallbraker was reviewed by Jerome Glisse (glisse). Most of his immediate comments were of cosmetic nature (indention, "/* */" instead of "// "). The code was also reviewed by jbarnes. Until now noone sad anything bad about the code or the idea, which is a very good sign.
-
- * Lately some '''discussion came about about the DRM layer''' in general. Dave Airlie (airlied) and Wallbraker had a lengthy conversation about it ([[http://people.freedesktop.org/~cbrill/dri-log/dri-devel-2007-03-16.log|Source]]). Dave Airlie (airlied) explained a lot of basic concepts of how framebuffer drivers get access to the hardware and what the drm does. Both agreed that putting modesetting into the DRM layer is a good idea. They also thought about framebuffer drivers that would sit on top of the DRM layer and what the gain would be if DRM would dropping support for other OS than Linux. These ideas didn't go into details and won't happen soon (or ever). Anyone intersted in framebuffer drivers init, DRM init, where modesetting should happen and about DRM in general should take a look at the upper half of [[http://people.freedesktop.org/~cbrill/dri-log/dri-devel-2007-03-16.log|the log]].
-
- * The R300 now is '''officially maintained by "The DRI Project"'''. Not that someone else maintained it, but the GL_VENDOR stated "Tungsten Graphics". In the discussion at [[http://bugs.freedesktop.org/show_bug.cgi?id=10303|Bug #10303]] it was agreed to change that to "The DRI Project" to avoid confusion among users.
-
- * Giacomo Perale reported in a bug some glitches in rendering on his R300. These glitches seem to come from ColorTiling and PageFlipping enabled. Until now noone came up with good ideas or solutions yet. ([[http://bugs.freedesktop.org/show_bug.cgi?id=10245|Source]])
-
- * The '''issues about fragment.position''' continued again. Oliver McFadden (z3ro) tested a patch by Rune Petersen which moves the calculation of fragment.position from the vertex program into the fragment program. Oliver McFadden (z3ro) also found out that the simple program
-{{{
-mov result.color.xy, fragment.position;
-}}}
-works on fglrx, but not on R300. It needs
-{{{
-mov result.color.xyz, fragment.position;
-}}}
-to work properly. Discussion about what fglrx uses for '''z''' ended without solution. Jerome Glisse (glisse) suggested to spy the fragment program of fglrx.
-
- * Last but not least Simon80 came in the IRC channel and asked about a '''Google Summer of Code project to add EXA render support''' to R300. Dave Airlie (airlied) and marcheu discussed about the sense and if it would possible to do so in a SoC project. They also came up with the issues someone might run into. jbarnes also noted that there might me some 64 bit issues related with that task.
-
- * Really the last entry in this issue is '''2D support for R500''' chips. Dave Airlie (airlied) wrote some time ago a small enhancement to the xf86-video-ati code to support this chipset. The issue is that he wrote it under NDA and is not allowed to publish the source without permission of ATI (or is it AMD today?). He asked politely but the request was ignored. Now he is waiting if anyone else to get ATI/AMD to respond and to tell if he is allowed to publish the source or if he is not. If you feel like asking ATI/AMDs support for that, please be polite but direct. Maybe someone will listen to you? Also [[http://www.michaellarabel.com/index.php?k=blog&i=121|Michael Larabel]] suggests a method to get ATI/AMD to improve their binary driver.
-
-== Help needed ==
-Currently we are making really good progress. We don't have any special needs right now but it would be great if someone could help on R500 support. There seems to be some work going on, but slowly. It would also be very helpfull to see how people succeed in running KMMIO with R300 (against latest fglrx and against an older version).
-
-
-''Written by Christoph Brill (egore)''
diff --git a/Radeon_Companion_3.moin b/Radeon_Companion_3.mdwn
index 0ef0b30..c5c1546 100644
--- a/Radeon_Companion_3.moin
+++ b/Radeon_Companion_3.mdwn
@@ -1,29 +1,32 @@
-= The irregular Radeon-Development companion =
-
-== Issue for 2007-04-01 ==
-
-== Intro ==
-
-This page is an accumulation of the events happening in Radeon development, mainly on IRC or on dri-devel. The concept has been shamelessly copied from [[http://nouveau.freedesktop.org|nouveau]] and will hopefully be kept up. At least this is the second issue. So didn't immediately stop.
-
-The TiRDC gained a lot of responses lately. So we try to keep our readers up to date with this issue. This issue will be a bit shorter because the author lacks time. But the most important events will be noted.
-
-* After Nicolai Haehnle (nh) started working on '''piglit''', he detected some bugs and some regressions. Luckyly after he found them he started fixing them. [[http://people.freedesktop.org/~nh/piglit/sample/index.html|Source]]
-
-* Mesa got the GLSL-1 branch merged. That means you can use mesa with GLSL shading programs. Thanks Brian Paul for doing the work of merging and thanks to anyone for writing that code. [[http://sourceforge.net/mailarchive/forum.php?thread_name=46082759.7050503%40tungstengraphics.com&forum_name=mesa3d-dev|Source]]
-
-* As a sidenote the X.org ATI driver xf86-video-ati got a release candidate. It contains a major re-write of the output mappings from what was known as "Alex's superpatch". Please log all regressions into bugzilla so they can be fixed before the 6.7 release of the driver.
-
-* Thomas Hellström came up with a patch to allow single-device-mutli-screen DRI. Neat idea. [[http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg30241.html|Source]]
-
-* Dave Airlie came up with the idea that TTM (the new and way better memory manager in mesa) should be used in wide areas. With his knownlege of TTM (aquried from Thomas Hellström, one of the guys behind TTM) and his great knowledge of the Radeon-Drivers, he ported the work from i915 over to R300. Note: The TTM support is not complete or offical yet. It only supports fencing and buffer management, which is the absolute basic of TTM. [[http://airlied.livejournal.com/41732.html|Source]]
-
-* Jakob Bornecrantz (Wallbraker) and Jesse Barnes (jbarnes) continue working on DRM modesetting. They don't have a public git repository or something yet, but that start a big discussion. Former developers of KGI (the kernel graphics interface) joined #dri-devel and disscussed about the modesetting in DRM. Dave Airlie took part in the discussion and added information about framebuffer drivers. All in all the idea of having a central entity for managing modesetting for framebuffer and X.org drivers was agreed to be a good idea, even if some though it might not be placed right in the DRM. [[http://www.egore911.de/vype/dri-log/dri-devel-2007-03-26.log|Source]]
-
-== Help wanted and needed ==
-We could really need help in finding regressions that might come from the GLSL-1 branch merge. It would be great if you could run piglit against
-* latest fglrx
-* dri drivers from before the GLSL-1 merge (maybe mesa 6.5.2 or better git from about 2 weeks ago)
-* latest dri drivers from git
-
-It would also be great if you could test Dave Airlie's TTM branch of R300 against latest git of mesa.
+
+
+# The irregular Radeon-Development companion
+
+
+## Issue for 2007-04-01
+
+
+## Intro
+
+This page is an accumulation of the events happening in Radeon development, mainly on IRC or on dri-devel. The concept has been shamelessly copied from [[nouveau|http://nouveau.freedesktop.org]] and will hopefully be kept up. At least this is the second issue. So didn't immediately stop. 
+
+The TiRDC gained a lot of responses lately. So we try to keep our readers up to date with this issue. This issue will be a bit shorter because the author lacks time. But the most important events will be noted. 
+
+* After Nicolai Haehnle (nh) started working on **piglit**, he detected some bugs and some regressions. Luckyly after he found them he started fixing them. [[Source|http://people.freedesktop.org/~nh/piglit/sample/index.html]] 
+
+* Mesa got the GLSL-1 branch merged. That means you can use mesa with GLSL shading programs. Thanks Brian Paul for doing the work of merging and thanks to anyone for writing that code. [[Source|http://sourceforge.net/mailarchive/forum.php?thread_name=46082759.7050503%40tungstengraphics.com&forum_name=mesa3d-dev]] 
+
+* As a sidenote the X.org ATI driver xf86-video-ati got a release candidate. It contains a major re-write of the output mappings from what was known as "Alex's superpatch". Please log all regressions into bugzilla so they can be fixed before the 6.7 release of the driver. 
+
+* Thomas Hellström came up with a patch to allow single-device-mutli-screen DRI. Neat idea. [[Source|http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg30241.html]] 
+
+* Dave Airlie came up with the idea that TTM (the new and way better memory manager in mesa) should be used in wide areas. With his knownlege of TTM (aquried from Thomas Hellström, one of the guys behind TTM) and his great knowledge of the Radeon-Drivers, he ported the work from i915 over to R300. Note: The TTM support is not complete or offical yet. It only supports fencing and buffer management, which is the absolute basic of TTM. [[Source|http://airlied.livejournal.com/41732.html]] 
+
+* Jakob Bornecrantz (Wallbraker) and Jesse Barnes (jbarnes) continue working on DRM modesetting. They don't have a public git repository or something yet, but that start a big discussion. Former developers of KGI (the kernel graphics interface) joined #dri-devel and disscussed about the modesetting in DRM. Dave Airlie took part in the discussion and added information about framebuffer drivers. All in all the idea of having a central entity for managing modesetting for framebuffer and X.org drivers was agreed to be a good idea, even if some though it might not be placed right in the DRM. [[Source|http://www.egore911.de/vype/dri-log/dri-devel-2007-03-26.log]] 
+
+
+## Help wanted and needed
+
+We could really need help in finding regressions that might come from the GLSL-1 branch merge. It would be great if you could run piglit against * latest fglrx * dri drivers from before the GLSL-1 merge (maybe mesa 6.5.2 or better git from about 2 weeks ago) * latest dri drivers from git 
+
+It would also be great if you could test Dave Airlie's TTM branch of R300 against latest git of mesa. 
diff --git a/Radeon_Companion_4.moin b/Radeon_Companion_4.mdwn
index 084c6ea..0c32dc8 100644
--- a/Radeon_Companion_4.moin
+++ b/Radeon_Companion_4.mdwn
@@ -1,28 +1,35 @@
-= The irregular Radeon-Development companion =
-
-== Issue for 2007-04-25 ==
-
-== Intro ==
-
-This page is an accumulation of the events happening in Radeon development, mainly on IRC or on dri-devel. The concept has been shamelessly copied from [[http://nouveau.freedesktop.org|nouveau]] and will hopefully be kept up at a frequent rate. But that (as everything in open source depends on time).
-
-== Status ==
-
-* Olliver McFadden did some work on his [[http://gitweb.freedesktop.org/?p=users/z3ro/revenge.git;a=summary|tool]] for reverse engineering lately. He is focussing on comparing the logs of fglrx with the ones from r300. He already found some minor differences and brought up questions about the major differences about the driver internals. While fglrx mainly uses indirect buffers to put data into to the card, r300 uses so called type one packets to transfer the data. Dave Airlie (airlied) explained that there is no big difference (performancewise) in any of these approaches. It's just a different way. Olliver McFadden pointed out that this at least creates a very different output between fglrx and r300. It was agreed that we cannot and won't change the driver to mimik fglrx for no real benefit.
-
-* Dave Airlie (airlied) started working on RS480. This chipset is R300 based but is some kind of "stripped down". The PCIGart has to be set up differently and it lacks some TnL hardware. He got the modesetting more or less working and got an unaccellerated DDX (2D driver) up and running. He started looking on how to get 3D running. Take a look at the picture to see how glxgears currently look on RS480.
-
-{{http://www.skynet.ie/~airlied/dri/gears_rs480.png}} 
-
-You should known what it ormally it should look like... The main issue seems to be that fact that RS480 does not have any vertex shaders which will require a lot of work to get RS480 to run with the r300 driver. Dave Airlie (airlied) did not go any further yet.
-
-* On the modesetting front we got some exciting news lately. Shortly after Jakob Bornecrantz (Wallbraker) and Jesse Barnes (jbarnes) created a [[http://gitweb.freedesktop.org/?p=mesa/drm.git;a=shortlog;h=modesetting-101|drm branch]] for modesetting, Dave Airlie (airlied) dropped in since he needed it for an X-less GLX setup (called MiniGLX). He got it to work on Intel APG with Intel Graphics. Others (like Kristian Høgsberg or Alan Hourihane) partly reviewed the code and fixed some minor issues. This branch requires the AGP backend to support TTM (the new memory manager). Currently using drm modesetting is only possible on intel hardware. Thomas Hellstrom has a patch for via AGP to add support for TTM. Some people are trying to get Dave Airlie (airlied) to do the R300 work, but they did not have success with it (yet?).
-
-* The logging of the #dri-devel channel on irc.freenode.net can now be reached at a [[http://dri.freedesktop.org|new location]]. Christoph Brill (egore) setup up the logs and thought a simple URL would be usefull.
-
-* Currently people are thinking about R300 "marketing". The nouveau driver gained a lot of interest lately. People with ATI cards don't want to see R300 development fall behind and so recently a discussion started about what can be done to get the driver development going faster, better and greater. Trevinho came around on IRC and talked to Jerome Glisse (glisse) about what could be done to increase popularity. A good suggestion by Jerome Glisse was to setup a blog that is aggregated on planet.freedesktop.org that outlines the news like we do here in this TiRDC. Dave Airlie (airlied) is already blogging the "great news" in driver development on [[http://airlied.livejournal.com/|his blog]], but others don't do it. There was no decision made on how to progress. We will discuss this in a later issue.
-
-* The status of GLSL was one of the topics lately. Intel got GLSL done and it seems to work pretty flawless. Arc dropped in on IRC and asked what would be necessary to get R300 to work with GLSL. Dave Airlie (airlied) pointed out that we don't have any specs on how to do that on R300. Olliver McFadden also pointed out that GLSL code is converted to vertex- and fragment-programs so we might need to fix them first. He also pointed out that R300 hardware does not support loops, so it would be necessary to unwrap the loops first. Arc was pointed to the Intel sources which are a good source for free 3D development.
-
-== Help wanted and needed ==
-R300 does not have any real "marketing". If you can think of anything that will get the driver further, feel free to discuss this on #dri-devel or the mailing lists. It would be also really helpful if people would link to this site and increase the publicity of TiRDC. Jerome Glisse will try to inform some bigger Linux related sites about it. If you got contact to someone who might write something about R300 or DRI development, please inform them about this little site.
+
+
+# The irregular Radeon-Development companion
+
+
+## Issue for 2007-04-25
+
+
+## Intro
+
+This page is an accumulation of the events happening in Radeon development, mainly on IRC or on dri-devel. The concept has been shamelessly copied from [[nouveau|http://nouveau.freedesktop.org]] and will hopefully be kept up at a frequent rate. But that (as everything in open source depends on time). 
+
+
+## Status
+
+* Olliver [[McFadden|McFadden]] did some work on his [[tool|http://gitweb.freedesktop.org/?p=users/z3ro/revenge.git;a=summary]] for reverse engineering lately. He is focussing on comparing the logs of fglrx with the ones from r300. He already found some minor differences and brought up questions about the major differences about the driver internals. While fglrx mainly uses indirect buffers to put data into to the card, r300 uses so called type one packets to transfer the data. Dave Airlie (airlied) explained that there is no big difference (performancewise) in any of these approaches. It's just a different way. Olliver [[McFadden|McFadden]] pointed out that this at least creates a very different output between fglrx and r300. It was agreed that we cannot and won't change the driver to mimik fglrx for no real benefit. 
+
+* Dave Airlie (airlied) started working on RS480. This chipset is R300 based but is some kind of "stripped down". The PCIGart has to be set up differently and it lacks some TnL hardware. He got the modesetting more or less working and got an unaccellerated DDX (2D driver) up and running. He started looking on how to get 3D running. Take a look at the picture to see how glxgears currently look on RS480. 
+
+[[!img http://www.skynet.ie/~airlied/dri/gears_rs480.png]  
+
+You should known what it ormally it should look like... The main issue seems to be that fact that RS480 does not have any vertex shaders which will require a lot of work to get RS480 to run with the r300 driver. Dave Airlie (airlied) did not go any further yet. 
+
+* On the modesetting front we got some exciting news lately. Shortly after Jakob Bornecrantz (Wallbraker) and Jesse Barnes (jbarnes) created a [[drm branch|http://gitweb.freedesktop.org/?p=mesa/drm.git;a=shortlog;h=modesetting-101]] for modesetting, Dave Airlie (airlied) dropped in since he needed it for an X-less GLX setup (called MiniGLX). He got it to work on Intel APG with Intel Graphics. Others (like Kristian Høgsberg or Alan Hourihane) partly reviewed the code and fixed some minor issues. This branch requires the AGP backend to support TTM (the new memory manager). Currently using drm modesetting is only possible on intel hardware. Thomas Hellstrom has a patch for via AGP to add support for TTM. Some people are trying to get Dave Airlie (airlied) to do the R300 work, but they did not have success with it (yet?). 
+
+* The logging of the #dri-devel channel on irc.freenode.net can now be reached at a [[new location|http://dri.freedesktop.org]]. Christoph Brill (egore) setup up the logs and thought a simple URL would be usefull. 
+
+* Currently people are thinking about R300 "marketing". The nouveau driver gained a lot of interest lately. People with ATI cards don't want to see R300 development fall behind and so recently a discussion started about what can be done to get the driver development going faster, better and greater. Trevinho came around on IRC and talked to Jerome Glisse (glisse) about what could be done to increase popularity. A good suggestion by Jerome Glisse was to setup a blog that is aggregated on planet.freedesktop.org that outlines the news like we do here in this TiRDC. Dave Airlie (airlied) is already blogging the "great news" in driver development on [[his blog|http://airlied.livejournal.com/]], but others don't do it. There was no decision made on how to progress. We will discuss this in a later issue. 
+
+* The status of GLSL was one of the topics lately. Intel got GLSL done and it seems to work pretty flawless. Arc dropped in on IRC and asked what would be necessary to get R300 to work with GLSL. Dave Airlie (airlied) pointed out that we don't have any specs on how to do that on R300. Olliver [[McFadden|McFadden]] also pointed out that GLSL code is converted to vertex- and fragment-programs so we might need to fix them first. He also pointed out that R300 hardware does not support loops, so it would be necessary to unwrap the loops first. Arc was pointed to the Intel sources which are a good source for free 3D development. 
+
+
+## Help wanted and needed
+
+R300 does not have any real "marketing". If you can think of anything that will get the driver further, feel free to discuss this on #dri-devel or the mailing lists. It would be also really helpful if people would link to this site and increase the publicity of TiRDC. Jerome Glisse will try to inform some bigger Linux related sites about it. If you got contact to someone who might write something about R300 or DRI development, please inform them about this little site. 
diff --git a/RadeonsiToDo.mdwn b/RadeonsiToDo.mdwn
new file mode 100644
index 0000000..6b4200c
--- /dev/null
+++ b/RadeonsiToDo.mdwn
@@ -0,0 +1,95 @@
+
+[[!toc ]] 
+
+
+## Radeonsi To Do list
+
+And here is the radeonsi to do list; if you feel something is missing please add it. If you have done something and it no longer needs to be investigated, happily erase it from here :). 
+
+
+### LLVM
+
+* **Turn on basic block vectorizer pass** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_ 
+   * _Status:_  N/A 
+   * _Description:_ 
+   * We might be able to use this pass to merge single dwords loads from constant memory into multiple dword loads. 
+
+### Compute
+
+* **Add support for compute interface** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_ 
+   * _Date Started: _ 
+   * _Status:_  WIP - Initial patch for non-compiler parts is [[here|http://people.freedesktop.org/~tstellar/0001-radeonsi-WIP-compute-patch.patch]] 
+   * _Description:_ 
+   * Add support for emitting dispatch packets and related compute state 
+* **Use asynchronous compute rings for compute ** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_ N/A 
+   * _Date Started: _N/A 
+   * _Status:_ N/A 
+   * _Description:_ 
+   * SI supports two asynchronous compute rings.  Use them for compute to avoid contention with gfx on the main gfx ring. 
+
+### 3D Features
+
+* **TGSI opcodes DDX/DDY** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_  Michel Dänzer 
+   * _Status:_  WIP 
+   * _Note:_   
+* **MSAA support on SI** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_ 
+   * _Status:_  N/A 
+   * _Note:_  Works very similarly to cayman.  Code from r600g can be ported over. 
+* **MSAA with colorbuffer compression on SI** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_ 
+   * _Status:_  N/A 
+   * _Note:_  Works very similarly to cayman.  Code from r600g can be ported over. 
+* **Fast color clear for MSAA buffers on SI** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_ N/A 
+   * _Note:_  Works very similarly to cayman.  Code from r600g can be ported over. 
+* **MSAA on the window system framebuffer** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_ N/A 
+   * _Note:_ AFAIK, nothing has been done for it in st/dri. I think we should allocate private MSAA color/depth/stencil surfaces in Gallium and ask the DDX to only allocate the single-sampled front where we will resolve the MSAA colorbuffer on [[SwapBuffers|SwapBuffers]]. 
+* **transform feedback support** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_ N/A 
+   * _Note:_  Works very similarly to cayman.  Code from r600g can be ported over. 
+* **timer query support** 
+   * _Difficulty:_ Easy 
+   * _Who's working on it:_ N/A 
+   * _Note:_  Works very similarly to r6xx-cayman.  Code from r600g can be ported over. 
+* **Polygon stippling** 
+   * _Difficulty:_ Easy 
+   * _Who's working on it:_ N/A 
+   * _Note:_ Take advantage of util/u_pstipple. It contains the shader transformation code and can create a stipple texture. 
+* **Polygon/line/point smoothing** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_ N/A 
+* **Texture buffer objects (read-only buffer resources in shaders)** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_ N/A 
+   * _Note:_: Core Mesa/Gallium support might need some work too. 
+* **Uniform buffer objects (constant buffers)** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_ N/A 
+   * _Note:_: Core Mesa/Gallium support might need some work too. 
+* **HyperZ support** 
+   * _Difficulty:_ Hard 
+   * _Who's working on it:_ N/A 
+   * _Note:_: Works very similarly to cayman.  Code for r600g can be ported over. 
+* **Geometry shaders** 
+   * _Difficulty:_ Medium 
+   * _Who's working on it:_ N/A 
+   * _Note:_: Core Mesa/Gallium support might need some work too. 
+
+### Bugs
+
+* All open bugs assigned to [[Drivers/Gallium/radeonsi|https://bugs.freedesktop.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=Drivers%2FGallium%2Fradeonsi&product=Mesa]] 
+\ No newline at end of file
diff --git a/RadeonsiToDo.moin b/RadeonsiToDo.moin
deleted file mode 100644
index 6bf264f..0000000
--- a/RadeonsiToDo.moin
+++ /dev/null
@@ -1,109 +0,0 @@
-<<TableOfContents()>>
-
-== Radeonsi To Do list ==
-And here is the radeonsi to do list; if you feel something is missing please add it. If you have done something and it no longer needs to be investigated, happily erase it from here :).
-
-=== LLVM ===
-
- * '''Turn on basic block vectorizer pass'''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:''
-  * ''Status:''  N/A
-  * ''Description:''
-
-  . We might be able to use this pass to merge single dwords loads from constant memory into multiple dword loads.
-
-
-=== Compute ===
-
- * '''Add support for compute interface'''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:''
-  * ''Date Started: ''
-  * ''Status:''  WIP - Initial patch for non-compiler parts is [[http://people.freedesktop.org/~tstellar/0001-radeonsi-WIP-compute-patch.patch|here]]
-  * ''Description:''
-
-  . Add support for emitting dispatch packets and related compute state
-
- * '''Use asynchronous compute rings for compute '''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:'' N/A
-  * ''Date Started: ''N/A
-  * ''Status:'' N/A
-  * ''Description:''
-
-  . SI supports two asynchronous compute rings.  Use them for compute to avoid contention with gfx on the main gfx ring.
-
-
-=== 3D Features ===
-
- * '''TGSI opcodes DDX/DDY'''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:''  Michel Dänzer
-  * ''Status:''  WIP
-  * ''Note:''  
-
- * '''MSAA support on SI'''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:''
-  * ''Status:''  N/A
-  * ''Note:''  Works very similarly to cayman.  Code from r600g can be ported over.
-
- * '''MSAA with colorbuffer compression on SI'''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:''
-  * ''Status:''  N/A
-  * ''Note:''  Works very similarly to cayman.  Code from r600g can be ported over.
-
- * '''Fast color clear for MSAA buffers on SI'''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:'' N/A
-  * ''Note:''  Works very similarly to cayman.  Code from r600g can be ported over.
-
- * '''MSAA on the window system framebuffer'''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:'' N/A
-  * ''Note:'' AFAIK, nothing has been done for it in st/dri. I think we should allocate private MSAA color/depth/stencil surfaces in Gallium and ask the DDX to only allocate the single-sampled front where we will resolve the MSAA colorbuffer on SwapBuffers.
-
- * '''transform feedback support'''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:'' N/A
-  * ''Note:''  Works very similarly to cayman.  Code from r600g can be ported over.
-
- * '''timer query support'''
-  * ''Difficulty:'' Easy
-  * ''Who's working on it:'' N/A
-  * ''Note:''  Works very similarly to r6xx-cayman.  Code from r600g can be ported over.
-
- * '''Polygon stippling'''
-  * ''Difficulty:'' Easy
-  * ''Who's working on it:'' N/A
-  * ''Note:'' Take advantage of util/u_pstipple. It contains the shader transformation code and can create a stipple texture.
-
- * '''Polygon/line/point smoothing'''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:'' N/A
-
- * '''Texture buffer objects (read-only buffer resources in shaders)'''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:'' N/A
-  * ''Note:'': Core Mesa/Gallium support might need some work too.
-
- * '''Uniform buffer objects (constant buffers)'''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:'' N/A
-  * ''Note:'': Core Mesa/Gallium support might need some work too.
-
- * '''HyperZ support'''
-  * ''Difficulty:'' Hard
-  * ''Who's working on it:'' N/A
-  * ''Note:'': Works very similarly to cayman.  Code for r600g can be ported over.
-
- * '''Geometry shaders'''
-  * ''Difficulty:'' Medium
-  * ''Who's working on it:'' N/A
-  * ''Note:'': Core Mesa/Gallium support might need some work too.
-
-=== Bugs ===
-
- * All open bugs assigned to [[https://bugs.freedesktop.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=Drivers%2FGallium%2Fradeonsi&product=Mesa|Drivers/Gallium/radeonsi]]
diff --git a/RedBook.mdwn b/RedBook.mdwn
new file mode 100644
index 0000000..9732d76
--- /dev/null
+++ b/RedBook.mdwn
@@ -0,0 +1,5 @@
+
+
+## Red Book
+
+The RedBook is the [[OpenGL Programming Guide|http://www.opengl.org/documentation/red_book_1.0/]].  It covers the use of the OpenGL API and the GLUT toolkit.  The book is currently up to version 1.4, but version 1.1 is available online in [[PDF|http://web.archive.org/web/20070314032548/http://www.gamedev.net/download/redbook.pdf]] and [[HTML|http://fly.cc.fer.hr/~unreal/theredbook/]] formats. 
diff --git a/RedBook.moin b/RedBook.moin
deleted file mode 100644
index aeca3bf..0000000
--- a/RedBook.moin
+++ /dev/null
@@ -1,2 +0,0 @@
-== Red Book ==
-The RedBook is the [[http://www.opengl.org/documentation/red_book_1.0/|OpenGL Programming Guide]].  It covers the use of the OpenGL API and the GLUT toolkit.  The book is currently up to version 1.4, but version 1.1 is available online in [[http://web.archive.org/web/20070314032548/http://www.gamedev.net/download/redbook.pdf|PDF]] and [[http://fly.cc.fer.hr/~unreal/theredbook/|HTML]] formats.
diff --git a/References.mdwn b/References.mdwn
new file mode 100644
index 0000000..2bc0cb3
--- /dev/null
+++ b/References.mdwn
@@ -0,0 +1,76 @@
+
+
+# References
+[Barron01]
+: 
+Dave Barron, [[ExtremeTech 3D Card Guided Tour|http://www.extremetech.com/article/0,3396,s%253D1019%2526a%253D1618,00.asp]] 
+
+
+[Salvator01]
+: 
+Dave Salvator, [[ExtremeTech 3D Pipeline Tutorial|http://www.extremetech.com/article/0,3396,s%253D1017%2526a%253D2674,00.asp]] 
+
+
+[Faith99]
+: 
+Rickard Faith, [[The Direct Rendering Manager: Kernel Support for the Direct Rendering Infrastructure|http://dri.sourceforge.net/doc/drm_low_level.html]], Precision Insight, Inc., 1999 
+
+
+[FOM99]
+: 
+Rickard Faith, Jens Owen, and Kevin Martin, [[Hardware Locking for the Direct Rendering Infrastructure|http://dri.sourceforge.net/doc/hardware_locking_low_level.html]], Precision Insight, Inc., 1999. 
+
+_NOTE: This document is in decent shape.  However, we don't use hardware locking very much for DMA based drivers; and it's really a infrastructure design justification.  Not recommended for 1st time driver writers; better for developer wanting to extend the infrastructure and needing a low overhead lock._ 
+
+
+[LKMPG]
+: 
+Ori Pomerantz, [[Linux Kernel Module Programming Guide|http://en.tldp.org/LDP/lkmpg/index.html]] 
+
+
+[LDD]
+: 
+Alessandro Rubini, Jonathan Corbet, and Greg Kroah-Hartman, [[Linux Device Drivers|http://www.oreilly.com/catalog/linuxdrive3/]] [[Available online|http://lwn.net/Kernel/LDD3/]] 
+
+
+[OpenGL-1.3-Spec]
+: 
+Mark Segal and Kurt Akeley, [[The OpenGL Graphics System: A Specification (Version 1.3)|http://www.opengl.org/documentation/specs/version1.3/glspec13.pdf]]. 
+
+   * _Complete specs for all parts of OpenGL are available from [[the opengl.org website|http://www.opengl.org/documentation/specs/]]._ 
+
+[OpenGL-design]
+: 
+Mark Segal and Kurt Akeley, [[The Design of the OpenGL Graphics Interface|http://wwws.sun.com/software/graphics/opengl/OpenGLdesign.pdf]]. 
+
+
+[OpenGL-FAQ]
+: 
+Paul Martz, [[OpenGL Technical FAQ and TroubleShooting Guide|http://www.opengl.org/resources/faq/technical/]] 
+
+
+[OpenGL-PG]
+: 
+[[OpenGL Programming Guide|http://ask.ii.uib.no/ebt-bin/nph-dweb/dynaweb/SGI_Developer/OpenGL_PG/]] 
+
+
+[Ref-Design-High-Level]
+: 
+Jens Owen and Kevin Martin, [[A Multipipe Direct Rendering Architecture for 3D|http://dri.sourceforge.net/doc/design_high_level.html]], Precision Insight, Inc., 1998 
+
+
+[Ref-DRI-Intro]
+: 
+Brian Paul, [[Introduction to the Direct Rendering Infrastructure|http://dri.sourceforge.net/doc/DRIintro.html]], 2000 
+
+
+[TLK]
+: 
+David Rusling, [[The Linux Kernel|http://en.tldp.org/LDP/tlk/tlk.html]] 
+
+
+[XFree86-Design]
+: 
+[[XFree86 X server "New Design"|http://www.xfree86.org/4.3.0/DESIGN.html]] 
+
+
diff --git a/References.moin b/References.moin
deleted file mode 100644
index 1edae12..0000000
--- a/References.moin
+++ /dev/null
@@ -1,33 +0,0 @@
-= References =
-
- [Barron01]:: Dave Barron, [[http://www.extremetech.com/article/0,3396,s%253D1019%2526a%253D1618,00.asp|ExtremeTech 3D Card Guided Tour]]
-
- [Salvator01]:: Dave Salvator, [[http://www.extremetech.com/article/0,3396,s%253D1017%2526a%253D2674,00.asp|ExtremeTech 3D Pipeline Tutorial]]
-
- [Faith99]:: Rickard Faith, [[http://dri.sourceforge.net/doc/drm_low_level.html|The Direct Rendering Manager: Kernel Support for the Direct Rendering Infrastructure]], Precision Insight, Inc., 1999
-
- [FOM99]:: Rickard Faith, Jens Owen, and Kevin Martin, [[http://dri.sourceforge.net/doc/hardware_locking_low_level.html|Hardware Locking for the Direct Rendering Infrastructure]], Precision Insight, Inc., 1999.
-
- ''NOTE: This document is in decent shape.  However, we don't use hardware locking very much for DMA based drivers; and it's really a infrastructure design justification.  Not recommended for 1st time driver writers; better for developer wanting to extend the infrastructure and needing a low overhead lock.''
-
- [LKMPG]:: Ori Pomerantz, [[http://en.tldp.org/LDP/lkmpg/index.html|Linux Kernel Module Programming Guide]]
-
- [LDD]:: Alessandro Rubini, Jonathan Corbet, and Greg Kroah-Hartman, [[http://www.oreilly.com/catalog/linuxdrive3/|Linux Device Drivers]] [[http://lwn.net/Kernel/LDD3/|Available online]]
-
- [OpenGL-1.3-Spec]:: Mark Segal and Kurt Akeley, [[http://www.opengl.org/documentation/specs/version1.3/glspec13.pdf|The OpenGL Graphics System: A Specification (Version 1.3)]].
-  ''Complete specs for all parts of OpenGL are available from [[http://www.opengl.org/documentation/specs/|the opengl.org website]].''
-
- [OpenGL-design]:: Mark Segal and Kurt Akeley, [[http://wwws.sun.com/software/graphics/opengl/OpenGLdesign.pdf|The Design of the OpenGL Graphics Interface]].
-
- [OpenGL-FAQ]:: Paul Martz, [[http://www.opengl.org/resources/faq/technical/|OpenGL Technical FAQ and TroubleShooting Guide]]
-
- [OpenGL-PG]:: [[http://ask.ii.uib.no/ebt-bin/nph-dweb/dynaweb/SGI_Developer/OpenGL_PG/|OpenGL Programming Guide]]
-
- [Ref-Design-High-Level]:: Jens Owen and Kevin Martin, [[http://dri.sourceforge.net/doc/design_high_level.html|A Multipipe Direct Rendering Architecture for 3D]], Precision Insight, Inc., 1998
-
- [Ref-DRI-Intro]:: Brian Paul, [[http://dri.sourceforge.net/doc/DRIintro.html|Introduction to the Direct Rendering Infrastructure]], 2000
-
- [TLK]:: David Rusling, [[http://en.tldp.org/LDP/tlk/tlk.html|The Linux Kernel]]
-
- [XFree86-Design]:: [[http://www.xfree86.org/4.3.0/DESIGN.html|XFree86 X server "New Design"]]
-
diff --git a/Rendition.moin b/Rendition.mdwn
index 952d006..0e041db 100644
--- a/Rendition.moin
+++ b/Rendition.mdwn
@@ -1,20 +1,25 @@
-= Rendition =
-
-The Rendition Verite was an early competitor of the 3dfx Voodoo line.  The design was quite ahead of its time, being based on a general-purpose RISC core with additional instructions for 3d primitives.  Three models saw production:
-
- * Verite V1000
- * Verite V2100
- * Verite V2200
-
-The major difference between the V1000 and later chips is that the V1000 lacks a 'tri' instruction for hardware triangle setup.  The V2x00s appear to mostly differ by clock speed.
-
-Rendition was bought up by Micron.
-
-== Status ==
-
-There is no DRI or DRM support for the Rendition chips.  Adding this support would involve figuring out how to load an acceptable microcode onto the chip.  This seems to be quite problematic, the 2D driver in Xorg doesn't use the accelerated 2D microcode at all.
-
-Since the hardware is very programmable, it would be a fascinating - if perhaps not very practical - experiment to implement vertex and fragment shaders in the Verite microcode.
-
-----
-CategoryHardwareChipset
+
+
+# Rendition
+
+The Rendition Verite was an early competitor of the 3dfx Voodoo line.  The design was quite ahead of its time, being based on a general-purpose RISC core with additional instructions for 3d primitives.  Three models saw production: 
+
+* Verite V1000 
+* Verite V2100 
+* Verite V2200 
+The major difference between the V1000 and later chips is that the V1000 lacks a 'tri' instruction for hardware triangle setup.  The V2x00s appear to mostly differ by clock speed. 
+
+Rendition was bought up by Micron. 
+
+
+## Status
+
+There is no DRI or DRM support for the Rendition chips.  Adding this support would involve figuring out how to load an acceptable microcode onto the chip.  This seems to be quite problematic, the 2D driver in Xorg doesn't use the accelerated 2D microcode at all. 
+
+Since the hardware is very programmable, it would be a fascinating - if perhaps not very practical - experiment to implement vertex and fragment shaders in the Verite microcode. 
+
+
+
+---
+
+ [[CategoryHardwareChipset|CategoryHardwareChipset]] 
diff --git a/Resources.mdwn b/Resources.mdwn
new file mode 100644
index 0000000..8ca147b
--- /dev/null
+++ b/Resources.mdwn
@@ -0,0 +1,2 @@
+
+Describe Resources here. 
diff --git a/Resources.moin b/Resources.moin
deleted file mode 100644
index 58d05af..0000000
--- a/Resources.moin
+++ /dev/null
@@ -1 +0,0 @@
-Describe Resources here.
diff --git a/ReverseEngineering.mdwn b/ReverseEngineering.mdwn
new file mode 100644
index 0000000..76aa786
--- /dev/null
+++ b/ReverseEngineering.mdwn
@@ -0,0 +1,99 @@
+
+In some cases there is no other way to create a device driver than to reverse engineer it from a binary "blob" (a closed-source driver). For some open-source drivers (like the driver for ATi R300+ based cards) some of these techniques were used to produce a working driver. Getting information from memory dumps or binary streams is difficult to master and in many cases takes lots of work. To make the necessary work a little easier, here is a list of several tools that could be used to gather information. 
+
+**Warning**: _only use the tools below when you know what you are doing!_ 
+
+   * **libsegfault** - blob memory access tracer 
+Get it at: [[http://people.freedesktop.org/~glisse/|http://people.freedesktop.org/~glisse/]] 
+
+The idea here is to set the environment variable SF_ADDR to your MMIO address. You find this address by using `lspci`.  For example, if `lspci -v` gives you: 
+
+
+[[!format txt """
+01:00.0 VGA compatible controller: ATI Technologies Inc RV380 [Radeon
+X600 (PCIE)] (prog-if 00 [VGA])
+        Subsystem: ATI Technologies Inc Unknown device 0f02
+        Flags: bus master, fast devsel, latency 0, IRQ 169
+        Memory at f0000000 (64-bit, prefetchable) [size=128M]
+        Memory at ''fe9e0000'' (64-bit, non-prefetchable) [size=64K]
+        I/O ports at dc00 [size=256]
+        Expansion ROM at fea00000 [disabled] [size=128K]
+        Capabilities: <access denied>
+"""]]
+Then you do 
+
+
+[[!format txt """
+export SF_ADDR='0xfe9e0000'
+$LD_PRELOAD=/pathto/libsegfault.so Xorg >dump 2>&1
+"""]]
+while xorg.conf is configured to use the fglrx driver. Note that this has a high impact on performance when running the X-server. 
+
+   * **iba** - a tool to spy indirect buffers used during R300 development 
+Get it at: [[http://rasterburn.org/~aet/iba.tar.bz2|http://rasterburn.org/~aet/iba.tar.bz2]] 
+
+   * **iba2** - successor of iba 
+Get it at: [[http://rasterburn.org/~aet/iba-2.tar.bz2|http://rasterburn.org/~aet/iba-2.tar.bz2]] 
+
+   * **iba4** - successor of iba-2 for usability features 
+Get it at: [[http://people.freedesktop.org/~cbrill/iba-4.tar.bz2|http://people.freedesktop.org/~cbrill/iba-4.tar.bz2]] 
+
+Currently this version is exactly the same as iba-2, execpt that you get some better error messages to see what is going on without looking into the source. Also this version features logging and analyzing without recompilation. It also features automatic detection of the correct address of the graphics card. 
+
+_Note: None of the iba's works with current fglrx anymore, because fglrx no longer uses user space to do mmio writes. You need "kmmio tracer" (see below)_ 
+
+_Note: Also consider Revenge (described below) as a possible replacement for iba. Revenge supports superiour auto-detection and works with the latest fglrx blob. 
+
+   * **libsegfault-iba** - a fork of libsegfault coupled with iba 
+Get it at: [[http://www.rasterburn.org/~aet/libsegfault-iba.tar.bz2|http://www.rasterburn.org/~aet/libsegfault-iba.tar.bz2]] 
+
+   * **vbetest hack** - video BIOS spying tools 
+Get it at: [[http://people.freedesktop.org/~airlied/xresprobe-mjg59-0.4.21.tar.gz|http://people.freedesktop.org/~airlied/xresprobe-mjg59-0.4.21.tar.gz]] 
+
+      * **vbetool** - run code from the video BIOS 
+Get it at: [[http://www.srcf.ucam.org/~mjg59/vbetool/|http://www.srcf.ucam.org/~mjg59/vbetool/]] 
+
+   * **valgrind-mmt** - tracks MMIO register writes 
+Get it at: [[http://www.skynet.ie/~airlied/patches/valgrind/|http://www.skynet.ie/~airlied/patches/valgrind/]] 
+
+   * **valgrind-mmt-extend** - extended version of valgrind-mmt for WR-only registers 
+Get it at: [[http://code-monkey.de/articles/2007/01/08/hacking-up-valgrind-mmt|http://code-monkey.de/articles/2007/01/08/hacking-up-valgrind-mmt]] 
+
+   * **valgrind-mmt-extend-extend** - extended version of valgrind-mmt-extend 
+Handles I/O port accesses on amd64, and takes a hex offset instead of decimal, e.g.:  
+ sudo valgrind --tool=mmt --offset=c1000000 /usr/bin/Xorg :0 -ac > x.log 2>&1 
+
+Get it at: [[http://gitweb.freedesktop.org/?p=users/daniels/valgrind.git;a=summary|http://gitweb.freedesktop.org/?p=users/daniels/valgrind.git;a=summary]] 
+
+   * **Oliver's Valgrind-MMT** 
+Extended version of Daniels' Valgrind-MMT (described above) supporting libc 2.5. 
+
+_Note: This version of Valgrind-MMT is based on the Valgrind SVN repository as of r7063, or 2007-10-31. 
+
+Get it at: [[http://cgit.freedesktop.org/~z3ro/valgrind-mmt/|http://cgit.freedesktop.org/~z3ro/valgrind-mmt/]]    (Unfortunately this was lost due to people.freedesktop.org home directory failure.) 
+
+   * **kmmio tracer** 
+Get it at: [[http://nouveau.freedesktop.org/wiki/MmioTrace|http://nouveau.freedesktop.org/wiki/MmioTrace]]  
+
+This traces all of the MMIO operations of a kernel module.  This is useful for tracing the MMIO of a binary kernel blob.  (As a side note: the fgrlx driver does most of its work in user space, so libsegfault should work just fine.) 
+
+   * ** bitfield ** 
+Get it at: [[http://ozlabs.org/~jk/code/bitfield/|http://ozlabs.org/~jk/code/bitfield/]] 
+
+This can translate registers/bitfields into their numeric values.  However, we need to generate config files appropriate for each card type/family.  
+
+   * ** glxtest ** 
+Get it at: [[http://r300.cvs.sourceforge.net/r300/glxtest/|http://r300.cvs.sourceforge.net/r300/glxtest/]] 
+
+These tools have been used to dump the command line that is sent to the CP (command processor) during R300 development. 
+
+   * ** Revenge ** 
+Read about it at: [[http://omcfadde.blogspot.com/2011/02/new-home-for-revenge-radeon-reverse.html|http://omcfadde.blogspot.com/2011/02/new-home-for-revenge-radeon-reverse.html]] 
+
+Get it by: _**git clone git://gitorious.org/omcfadde/revenge.git**_ 
+
+Revenge is a reverse engineering tool developed for reverse engineering and debugging the 3D commands sent to ATI GPU's. Revenge supports AGP, PCI, and PCI-E interfaces, as well as the IGP and RS690 chipsets. Currently you must specify the interface type as an option. 
+
+Revenge runs a series of simple OpenGL tests and dumps the results into several files, which may be examined by pretty_print_command_stream.tcl from the [[glxtest|http://r300.cvs.sourceforge.net/r300/glxtest/]] package, alternatively you could write your own analysis tools. Adding tests for new OpenGL features is a very simple task. 
+
+See the included README for more details. 
diff --git a/ReverseEngineering.moin b/ReverseEngineering.moin
deleted file mode 100644
index 43f969e..0000000
--- a/ReverseEngineering.moin
+++ /dev/null
@@ -1,124 +0,0 @@
-In some cases there is no other way to create a device driver than to reverse engineer it from a binary "blob" (a closed-source driver). For some open-source drivers (like the driver for ATi R300+ based cards) some of these techniques were used to produce a working driver. Getting information from memory dumps or binary streams is difficult to master and in many cases takes lots of work. To make the necessary work a little easier, here is a list of several tools that could be used to gather information.
-
-'''Warning''': ''only use the tools below when you know what you are doing!''
-
-
-  * '''libsegfault''' - blob memory access tracer
-Get it at: http://people.freedesktop.org/~glisse/
-
-The idea here is to set the environment variable SF_ADDR to your MMIO address. You find this address by using `lspci`.  For example, if `lspci -v` gives you:
-
-{{{
-01:00.0 VGA compatible controller: ATI Technologies Inc RV380 [Radeon
-X600 (PCIE)] (prog-if 00 [VGA])
-        Subsystem: ATI Technologies Inc Unknown device 0f02
-        Flags: bus master, fast devsel, latency 0, IRQ 169
-        Memory at f0000000 (64-bit, prefetchable) [size=128M]
-        Memory at ''fe9e0000'' (64-bit, non-prefetchable) [size=64K]
-        I/O ports at dc00 [size=256]
-        Expansion ROM at fea00000 [disabled] [size=128K]
-        Capabilities: <access denied>
-}}}
-Then you do
-
-{{{
-export SF_ADDR='0xfe9e0000'
-$LD_PRELOAD=/pathto/libsegfault.so Xorg >dump 2>&1
-}}}
-
-while xorg.conf is configured to use the fglrx driver. Note that this has a high impact on performance when running the X-server.
-
-  * '''iba''' - a tool to spy indirect buffers used during R300 development
-
-Get it at: http://rasterburn.org/~aet/iba.tar.bz2
-
-  * '''iba2''' - successor of iba
-
-Get it at: http://rasterburn.org/~aet/iba-2.tar.bz2
-
-  * '''iba4''' - successor of iba-2 for usability features
-
-Get it at: http://people.freedesktop.org/~cbrill/iba-4.tar.bz2
-
-Currently this version is exactly the same as iba-2, execpt that you get some better error messages to see what is going on without looking into the source. Also this version features logging and analyzing without recompilation. It also features automatic detection of the correct address of the graphics card.
-
-''Note: None of the iba's works with current fglrx anymore, because fglrx no longer uses user space to do mmio writes. You need "kmmio tracer" (see below)''
-
-''Note: Also consider Revenge (described below) as a possible replacement for
-iba. Revenge supports superiour auto-detection and works with the latest fglrx
-blob.
-
-  * '''libsegfault-iba''' - a fork of libsegfault coupled with iba
-
-Get it at: http://www.rasterburn.org/~aet/libsegfault-iba.tar.bz2
-
-  * '''vbetest hack''' - video BIOS spying tools
-
-Get it at: http://people.freedesktop.org/~airlied/xresprobe-mjg59-0.4.21.tar.gz
-
-   * '''vbetool''' - run code from the video BIOS
-
-Get it at: http://www.srcf.ucam.org/~mjg59/vbetool/
-
-  * '''valgrind-mmt''' - tracks MMIO register writes
-
-Get it at: http://www.skynet.ie/~airlied/patches/valgrind/
-
-  * '''valgrind-mmt-extend''' - extended version of valgrind-mmt for WR-only registers
-
-Get it at: http://code-monkey.de/articles/2007/01/08/hacking-up-valgrind-mmt
-
-  * '''valgrind-mmt-extend-extend''' - extended version of valgrind-mmt-extend
-
-Handles I/O port accesses on amd64, and takes a hex offset instead of decimal, e.g.:<<BR>>
-sudo valgrind --tool=mmt --offset=c1000000 /usr/bin/Xorg :0 -ac > x.log 2>&1
-
-Get it at: http://gitweb.freedesktop.org/?p=users/daniels/valgrind.git;a=summary
-
-  * '''Oliver's Valgrind-MMT'''
-
-Extended version of Daniels' Valgrind-MMT (described above) supporting libc
-2.5.
-
-''Note: This version of Valgrind-MMT is based on the Valgrind SVN repository as
-of r7063, or 2007-10-31.
-
-Get it at: http://cgit.freedesktop.org/~z3ro/valgrind-mmt/    (Unfortunately this was lost due to people.freedesktop.org home directory failure.)
-
-  * '''kmmio tracer'''
-
-Get it at: http://nouveau.freedesktop.org/wiki/MmioTrace 
-
-This traces all of the MMIO operations of a kernel module.  This is useful for tracing the MMIO of a binary kernel blob.  (As a side note: the fgrlx driver does most of its work in user space, so libsegfault should work just fine.)
-
-  * ''' bitfield '''
-
-Get it at: http://ozlabs.org/~jk/code/bitfield/
-
-This can translate registers/bitfields into their numeric values.  However, we need to generate config files appropriate for each card type/family. 
-
-  * ''' glxtest '''
-
-Get it at: http://r300.cvs.sourceforge.net/r300/glxtest/
-
-These tools have been used to dump the command line that is sent to the CP (command processor) during R300 development.
-
-
-  * ''' Revenge '''
-
-Read about it at: http://omcfadde.blogspot.com/2011/02/new-home-for-revenge-radeon-reverse.html
-
-Get it by: '''''git clone git://gitorious.org/omcfadde/revenge.git'''''
-
-Revenge is a reverse engineering tool developed for reverse engineering and
-debugging the 3D commands sent to ATI GPU's. Revenge supports AGP, PCI, and
-PCI-E interfaces, as well as the IGP and RS690 chipsets. Currently you must
-specify the interface type as an option.
-
-Revenge runs a series of simple OpenGL tests and dumps the results into
-several files, which may be examined by pretty_print_command_stream.tcl from
-the [[http://r300.cvs.sourceforge.net/r300/glxtest/|glxtest]] package,
-alternatively you could write your own analysis tools. Adding tests for new
-OpenGL features is a very simple task.
-
-See the included README for more details.
diff --git a/S3.mdwn b/S3.mdwn
new file mode 100644
index 0000000..ecf50b4
--- /dev/null
+++ b/S3.mdwn
@@ -0,0 +1,15 @@
+
+
+## S3
+
+See the following chipset articles: 
+
+* [[S3Savage|S3Savage]] 
+* [[S3Virge|S3Virge]] 
+[[!map pages="^S3.+"]] 
+
+
+
+---
+
+ [[CategoryHardwareVendor|CategoryHardwareVendor]] 
diff --git a/S3.moin b/S3.moin
deleted file mode 100644
index cb32907..0000000
--- a/S3.moin
+++ /dev/null
@@ -1,11 +0,0 @@
-== S3 ==
-
-See the following chipset articles:
-
- * [[S3Savage]]
- * [[S3Virge]]
-
-<<PageList(^S3.+)>>
-
-----
-CategoryHardwareVendor
diff --git a/S3Savage.mdwn b/S3Savage.mdwn
new file mode 100644
index 0000000..361850a
--- /dev/null
+++ b/S3Savage.mdwn
@@ -0,0 +1,59 @@
+
+
+### Savage
+
+Supported chips: 
+
+* Savage3D 
+* SavageMX/IX 
+* Savage4 
+* Supersavage 
+* Prosavage/Twister/DDR 
+PCI versions should be supported since 20050111. Shadow status problems with PCI cards were fixed in drm.ko on 20050112. 
+
+Unsupported chips: 
+
+* Savage2000 - Why not? I need it! /Michal P.  
+
+#### History
+
+S3/VIA released the source code to their savage DRI driver for xfree86 4.2.0. The UtahGLX project has support for savage 3D/MX/IX for XFree86 3.3.x and 4.x. [[FelixKuehling|FelixKuehling]] combined the S3/VIA and UtahGLX drivers and ported them to Mesa cvs.  [[AlexDeucher|AlexDeucher]] is working on the 2D driver and merged S3/VIA's changes with the xorg savage driver.  Their work is available in DRM, X.Org and Mesa cvs.  The code works for Savage4-based (savage4/prosavage/twister/DDR/supersavage) chips and the older Savage3D-based chips (3D/MX/IX).  3D is not supported on savage2000 at the moment. 
+
+In December 2004 configuration support was added. 
+
+As of 1st January 2005 the driver uses a new DRM driver with some cool new features: 
+
+* Secure DRM and DDX drivers that do not allow unprivileged 3D applications direct access to the hardware. 
+* Should be stable on a larger variety of hardware by using shadow status in the DRM if it is enabled in xorg.conf. 
+* Better performance by using vertex DMA when possible. 
+The Savage DRM and DDX versions were bumped to 2.0.0 indicating binary incompatible changes to the previous versions. If you upgrade (and you should ;-)) you need to update all three components (X.Org, Mesa and DRM) at the same time or DRI will not work. 
+
+Since Savage DRM version 2.2.0 and Mesa driver date 20050120 there is a fast path which yields another small performance improvement. There are now also options to disable vertex DMA and the fast path, so you can experiment which effect these features have with a specific application on your hardware. 
+
+Since Savage DRM version 2.4.0 and Mesa driver date 20050305 the driver supports command DMA on Savage4-based hardware. This improves performance slightly. It is also my hope that this works on Super``Savages, on which vertex DMA caused immediate lockups. 
+
+
+#### TODO
+
+* Use DMA for texture uploads. 
+* IRQ support for lower CPU usage. 
+* Implement/enable OpenGL extensions that the hardware can cope with. 
+
+#### How can I help?
+
+Test out the current driver on your savage chip and report the results to the dri-devel mailing list. 
+
+Adding extensions: Once we get the 3D driver cleaned up there are some extensions that could be added. For example, it looks like savage supports hardware assisted bump mapping. 
+
+See Felix' [[Savage Driver Roadmap|http://marc.theaimsgroup.com/?l=dri-devel&m=107722651207506&w=2]]. 
+
+
+#### Documentation
+
+Alex's [[Savage Guide|http://www.botchco.com/alex/savage/Savage_Guide.txt]]. 
+
+
+
+---
+
+ [[CategoryHardwareChipset|CategoryHardwareChipset]], [[CategoryHelpWanted|CategoryHelpWanted]] 
diff --git a/S3Savage.moin b/S3Savage.moin
deleted file mode 100644
index 76ca4fe..0000000
--- a/S3Savage.moin
+++ /dev/null
@@ -1,57 +0,0 @@
-=== Savage ===
-
-Supported chips:
-
- * Savage3D
- * SavageMX/IX
- * Savage4
- * Supersavage
- * Prosavage/Twister/DDR
-
-PCI versions should be supported since 20050111. Shadow status problems with PCI cards were fixed in drm.ko on 20050112.
-
-Unsupported chips:
-
-
- * Savage2000 - Why not? I need it! /Michal P. 
-
-
-==== History ====
-
-S3/VIA released the source code to their savage DRI driver for xfree86 4.2.0. The UtahGLX project has support for savage 3D/MX/IX for XFree86 3.3.x and 4.x. FelixKuehling combined the S3/VIA and UtahGLX drivers and ported them to Mesa cvs.  AlexDeucher is working on the 2D driver and merged S3/VIA's changes with the xorg savage driver.  Their work is available in DRM, X.Org and Mesa cvs.  The code works for Savage4-based (savage4/prosavage/twister/DDR/supersavage) chips and the older Savage3D-based chips (3D/MX/IX).  3D is not supported on savage2000 at the moment.
-
-In December 2004 configuration support was added.
-
-As of 1st January 2005 the driver uses a new DRM driver with some cool new features:
-
- * Secure DRM and DDX drivers that do not allow unprivileged 3D applications direct access to the hardware.
- * Should be stable on a larger variety of hardware by using shadow status in the DRM if it is enabled in xorg.conf.
- * Better performance by using vertex DMA when possible.
-
-The Savage DRM and DDX versions were bumped to 2.0.0 indicating binary incompatible changes to the previous versions. If you upgrade (and you should ;-)) you need to update all three components (X.Org, Mesa and DRM) at the same time or DRI will not work.
-
-Since Savage DRM version 2.2.0 and Mesa driver date 20050120 there is a fast path which yields another small performance improvement. There are now also options to disable vertex DMA and the fast path, so you can experiment which effect these features have with a specific application on your hardware.
-
-Since Savage DRM version 2.4.0 and Mesa driver date 20050305 the driver supports command DMA on Savage4-based hardware. This improves performance slightly. It is also my hope that this works on Super``Savages, on which vertex DMA caused immediate lockups.
-
-==== TODO ====
-
- * Use DMA for texture uploads.
- * IRQ support for lower CPU usage.
- * Implement/enable OpenGL extensions that the hardware can cope with.
-
-==== How can I help? ====
-
-Test out the current driver on your savage chip and report the results to the dri-devel mailing list.
-
-Adding extensions: Once we get the 3D driver cleaned up there are some extensions that could be added. For example, it looks like savage supports hardware assisted bump mapping.
-
-
-See Felix' [[http://marc.theaimsgroup.com/?l=dri-devel&m=107722651207506&w=2|Savage Driver Roadmap]].
-
-==== Documentation ====
-
-Alex's [[http://www.botchco.com/alex/savage/Savage_Guide.txt|Savage Guide]].
-
-----
-CategoryHardwareChipset, CategoryHelpWanted
diff --git a/S3TC.mdwn b/S3TC.mdwn
new file mode 100644
index 0000000..45b3d67
--- /dev/null
+++ b/S3TC.mdwn
@@ -0,0 +1,9 @@
+
+
+## S3TC
+
+S3TC support has been partially implemented in Mesa.  We cannot integrate and enable S3TC code by default due to the patents on the algorithm.  Because of this, to be cautious, code was integrated to only attempt to open an external library, libtxc_dxtn.so, and use a small number of functions from that to implement S3TC if available.  There is also an option in the S3TC-supporting DRI drivers called force_s3tc_enable.  If the library is unavailable, setting this option to true will expose the extension even though it cannot be fully implemented.  This may be of use for some games which require S3TC or don't use the ARB_texture_compression extension correctly. 
+
+The Mesa code is only enabled when USE_EXTERNAL_DXTN_LIB=1 is set in the build.  This is currently only set in the linux-dri and linux-dri-x86 Mesa configurations.  If you are having issues with S3TC, setting MESA_DEBUG=1 in the environment should print a warning from the S3TC code as to whether it succeeded in initializing or not, if it was built. 
+
+Source for the libtxc_dxtn.so is at [[http://cgit.freedesktop.org/~mareko/libtxc_dxtn/|http://cgit.freedesktop.org/~mareko/libtxc_dxtn/]]. Please be aware of the patent law in your own country with respect to using this code, as it is illegal in many places without a proper license from the patent holder. 
diff --git a/S3TC.moin b/S3TC.moin
deleted file mode 100644
index 0ae50da..0000000
--- a/S3TC.moin
+++ /dev/null
@@ -1,19 +0,0 @@
-== S3TC ==
-
-S3TC support has been partially implemented in Mesa.  We cannot integrate and enable
-S3TC code by default due to the patents on the algorithm.  Because of this, to be
-cautious, code was integrated to only attempt to open an external library, libtxc_dxtn.so,
-and use a small number of functions from that to implement S3TC if available.  There is also
-an option in the S3TC-supporting DRI drivers called force_s3tc_enable.  If the library is
-unavailable, setting this option to true will expose the extension even though it cannot
-be fully implemented.  This may be of use for some games which require S3TC or don't use the
-ARB_texture_compression extension correctly.
-
-The Mesa code is only enabled when USE_EXTERNAL_DXTN_LIB=1 is set in the build.  This is
-currently only set in the linux-dri and linux-dri-x86 Mesa configurations.  If you are
-having issues with S3TC, setting MESA_DEBUG=1 in the environment should print a warning from
-the S3TC code as to whether it succeeded in initializing or not, if it was built.
-
-Source for the libtxc_dxtn.so is at http://cgit.freedesktop.org/~mareko/libtxc_dxtn/.
-Please be aware of the patent law in your own country with respect to using this code,
-as it is illegal in many places without a proper license from the patent holder.
diff --git a/S3Virge.mdwn b/S3Virge.mdwn
new file mode 100644
index 0000000..9075d31
--- /dev/null
+++ b/S3Virge.mdwn
@@ -0,0 +1,54 @@
+
+
+# S3 Virge
+
+[[!map pages="^S3.+"]] 
+
+
+## Status
+
+There was a 3D driver in development for Xfree86 4.2.0/mesa 4.x by [[MaxLingua|MaxLingua]].  Adam Jackson imported the DRI part into Mesa CVS and fixed it up to compile under Mesa 6.x.  The DRM and DDX components are still languishing on the s3virge-0-0-1 branch of the old DRI CVS. 
+
+To be included in a future XFree86 release it will have to be fixed and finished.  Currently 2D must be disabled to use the 3D support.  There is support for 2D locking in the driver (so 2D and 3D can co-exist), but at the moment it locks up sometimes. 
+
+Alan Cox started [[porting|http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg18003.html]] it to xorg/mesa CVS.  
+
+See Max' readme for more info: [[http://dri.sourceforge.net/snapshots/bleeding-edge/README.s3virge|http://dri.sourceforge.net/snapshots/bleeding-edge/README.s3virge]] 
+
+from Max' readme: 
+
+"So here is what we have (hw accelerated, of course) 
+
+a) 3d primitives (flat/gouraud triangles and lines) 
+
+b) z-buffering 
+
+c) alpha-blending (for all the modes supported by virge) 
+
+d) texturing (for all the format and filter modes supported by virge) 
+
+Still not implemented are: 
+
+e) fog (hw fog is not compatible with hw alpha, so I chose the latter. It could still be implemented in sw, though) 
+
+f) lighting (I don't honestly understand how to implement it ; ) 
+
+g) hw clipping (it will give us some speed boost, but I don't know how to handle it in Mesa/DRI. Any info about it is welcome)" 
+
+It should support all Virge chips. 
+
+3D support is also available for XFree86 3.3.x in the [[Utah-GLX project|http://utah-glx.sf.net]]. 
+
+
+## Specifications
+
+
+## Resources
+
+Some resources from the dri-devel ML: [[http://marc.theaimsgroup.com/?t=102501705400003&r=1&w=2|http://marc.theaimsgroup.com/?t=102501705400003&r=1&w=2]] [[http://marc.theaimsgroup.com/?t=101623151900002&r=1&w=2|http://marc.theaimsgroup.com/?t=101623151900002&r=1&w=2]] [[http://marc.theaimsgroup.com/?t=102500392100001&r=1&w=2|http://marc.theaimsgroup.com/?t=102500392100001&r=1&w=2]] [[http://marc.theaimsgroup.com/?t=102509925800001&r=1&w=2|http://marc.theaimsgroup.com/?t=102509925800001&r=1&w=2]] 
+
+
+
+---
+
+ [[CategoryHardwareChipset|CategoryHardwareChipset]], [[CategoryHelpWanted|CategoryHelpWanted]] [[http://dri.sourceforge.net/cgi-bin/moin.cgi/RecentChanges|http://dri.sourceforge.net/cgi-bin/moin.cgi/RecentChanges]] 
diff --git a/S3Virge.moin b/S3Virge.moin
deleted file mode 100644
index 9134a30..0000000
--- a/S3Virge.moin
+++ /dev/null
@@ -1,57 +0,0 @@
-= S3 Virge =
-
-<<PageList(^S3.+)>>
-
-== Status ==
-
-There was a 3D driver in development for Xfree86 4.2.0/mesa 4.x by MaxLingua.  Adam Jackson imported the DRI part into Mesa CVS and fixed it up to compile under Mesa 6.x.  The DRM and DDX components are still languishing on the s3virge-0-0-1 branch of the old DRI CVS.
-
-To be included in a future XFree86 release it will have to be fixed and finished.  Currently 2D must be disabled to use the 3D support.  There is support for 2D locking in the driver (so 2D and 3D can co-exist), but at the moment it locks up sometimes.
-
-Alan Cox started [[http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg18003.html|porting]] it to xorg/mesa CVS. 
-
-See Max' readme for more info:
-[[http://dri.sourceforge.net/snapshots/bleeding-edge/README.s3virge]]
-
-from Max' readme:
-
-"So here is what we have (hw accelerated, of course)
-
-a) 3d primitives (flat/gouraud triangles and lines)
-
-b) z-buffering
-
-c) alpha-blending (for all the modes supported by virge)
-
-d) texturing (for all the format and filter modes supported by virge)
-
-Still not implemented are:
-
-e) fog (hw fog is not compatible with hw alpha, so I chose the latter. It could
-still be implemented in sw, though)
-
-f) lighting (I don't honestly understand how to implement it ; )
-
-g) hw clipping (it will give us some speed boost, but I don't know how to handle
-it in Mesa/DRI. Any info about it is welcome)"
-
-
-It should support all Virge chips.
-
-3D support is also available for XFree86 3.3.x in the
-[[http://utah-glx.sf.net|Utah-GLX project]].
-
-== Specifications ==
-
-== Resources ==
-
-Some resources from the dri-devel ML:
-[[http://marc.theaimsgroup.com/?t=102501705400003&r=1&w=2]]
-[[http://marc.theaimsgroup.com/?t=101623151900002&r=1&w=2]]
-[[http://marc.theaimsgroup.com/?t=102500392100001&r=1&w=2]]
-[[http://marc.theaimsgroup.com/?t=102509925800001&r=1&w=2]]
-
-
-----
-CategoryHardwareChipset, CategoryHelpWanted
-http://dri.sourceforge.net/cgi-bin/moin.cgi/RecentChanges
diff --git a/SAREA.mdwn b/SAREA.mdwn
new file mode 100644
index 0000000..d2aab6c
--- /dev/null
+++ b/SAREA.mdwn
@@ -0,0 +1,15 @@
+
+
+## SAREA
+
+The SAREA is a block of shared memory that is used to store internal device specific state but there's no simple answer to what, since it is used differently by each driver. It is shared among the X server and all the 3D clients. One piece that is common to all drivers is the upper layer of the lock. Reading the lock value out of the SAREA allows for fast locking. If there's contention the clients make an ioctl call to resolve the lock. 
+
+Beyond that it depends on the driver. The TDFX driver only uses a few flags in the SAREA, one to indicate that the FIFO has been modified, one to indicate that the 3D state has been modified, and one to indicate texture state has been modified. That way the clients know how much state they need to update when a context switch occurs. 
+
+Other drivers store more state in the SAREA. You can also store that state in the kernel driver. It's a design decision. So what values you put where will vary. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/SAREA.moin b/SAREA.moin
deleted file mode 100644
index 3cdf6ec..0000000
--- a/SAREA.moin
+++ /dev/null
@@ -1,21 +0,0 @@
-== SAREA ==
-
-The SAREA is a block of shared memory that is used to store internal device
-specific state but there's no simple answer to what, since it is used
-differently by each driver. It is shared among the X server and all the 3D
-clients. One piece that is common to all drivers is the upper layer of the
-lock. Reading the lock value out of the SAREA allows for fast locking. If
-there's contention the clients make an ioctl call to resolve the lock.
-
-Beyond that it depends on the driver. The TDFX driver only uses a few flags
-in the SAREA, one to indicate that the FIFO has been modified, one to indicate
-that the 3D state has been modified, and one to indicate texture state has been
-modified. That way the clients know how much state they need to update when a
-context switch occurs.
-
-Other drivers store more state in the SAREA. You can also store that state in
-the kernel driver. It's a design decision. So what values you put where will
-vary.
-
-----
-CategoryGlossary
diff --git a/SDL.mdwn b/SDL.mdwn
new file mode 100644
index 0000000..61d9ffb
--- /dev/null
+++ b/SDL.mdwn
@@ -0,0 +1,11 @@
+
+
+## Simple Direct-Media Layer (SDL)
+
+OpenGL only handles graphics (2D and 3D). Sam Lantinga (who now works at Loki Software Inc) wanted to handle !CD-!ROMs, audio, mixers, joysticks, keyboards, MPEG playback, and anything else related to multimedia and games. He also wanted to do all this in a platform independent way so he could compile and use the same source code on Windows, MacOS, Linux, etc. The SDL library achieves this. SDL relies heavily on other libraries like Mesa to do the grunt work. You can think of SDL as a more powerful version of GLUT. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/SDL.moin b/SDL.moin
deleted file mode 100644
index 1302c1b..0000000
--- a/SDL.moin
+++ /dev/null
@@ -1,13 +0,0 @@
-== Simple Direct-Media Layer (SDL) ==
-
-OpenGL only handles graphics (2D and 3D).
-Sam Lantinga (who now works at Loki Software Inc) wanted to handle !CD-!ROMs,
-audio, mixers, joysticks, keyboards, MPEG playback, and anything else related
-to multimedia and games. He also wanted to do all this in a platform
-independent way so he could compile and use the same source code on Windows,
-MacOS, Linux, etc. The SDL library achieves this. SDL relies heavily on other
-libraries like Mesa to do the grunt work. You can think of SDL as a more
-powerful version of GLUT.
-
-----
-CategoryGlossary
diff --git a/SGI.mdwn b/SGI.mdwn
new file mode 100644
index 0000000..50c5778
--- /dev/null
+++ b/SGI.mdwn
@@ -0,0 +1,17 @@
+
+
+## Silicon Graphics, Inc. (SGI)
+
+[[ToDo|ToDo]] 
+
+
+### Resources
+
+   * [[SGI homepage|http://www.sgi.com/]] 
+   * [[SGI's OpenGL sample implementation|http://oss.sgi.com/projects/ogl-sample/]] 
+   * [[SGI's GLX implementation|http://www.sgi.com/software/opensource/glx/]] 
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/SGI.moin b/SGI.moin
deleted file mode 100644
index eb10307..0000000
--- a/SGI.moin
+++ /dev/null
@@ -1,12 +0,0 @@
-== Silicon Graphics, Inc. (SGI) ==
-
-ToDo
-
-=== Resources ===
-
-  * [[http://www.sgi.com/|SGI homepage]]
-  * [[http://oss.sgi.com/projects/ogl-sample/|SGI's OpenGL sample implementation]]
-  * [[http://www.sgi.com/software/opensource/glx/|SGI's GLX implementation]]
-
-----
-CategoryGlossary
diff --git a/SIS650.mdwn b/SIS650.mdwn
new file mode 100644
index 0000000..76b1add
--- /dev/null
+++ b/SIS650.mdwn
@@ -0,0 +1,18 @@
+
+
+# Chipset Name
+
+sis 650 
+## Status
+
+without direct rendering 
+## Specifications
+
+
+## Resources
+
+
+
+---
+
+ [[CategoryHardwareChipset|CategoryHardwareChipset]] 
diff --git a/SIS650.moin b/SIS650.moin
deleted file mode 100644
index cd5eee7..0000000
--- a/SIS650.moin
+++ /dev/null
@@ -1,10 +0,0 @@
-= Chipset Name =
-sis 650
-== Status ==
-without direct rendering
-== Specifications ==
-
-== Resources ==
-
-----
-CategoryHardwareChipset
diff --git a/SLI.mdwn b/SLI.mdwn
new file mode 100644
index 0000000..e233022
--- /dev/null
+++ b/SLI.mdwn
@@ -0,0 +1,11 @@
+
+
+## Scan Line Interleaving (SLI)
+
+A technique where 2 or more 3D processors are used in parallel. Each processor renders only a fraction of the scanlines in the final image. This lets you achieve much higher framerates in games. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/SLI.moin b/SLI.moin
deleted file mode 100644
index c7c4f00..0000000
--- a/SLI.moin
+++ /dev/null
@@ -1,8 +0,0 @@
-== Scan Line Interleaving (SLI) ==
-
-A technique where 2 or more 3D processors are
-used in parallel. Each processor renders only a fraction of the scanlines in
-the final image. This lets you achieve much higher framerates in games.
-
-----
-CategoryGlossary
diff --git a/SMedia.mdwn b/SMedia.mdwn
new file mode 100644
index 0000000..078e249
--- /dev/null
+++ b/SMedia.mdwn
@@ -0,0 +1,21 @@
+
+
+## SMedia
+
+SMedia Glamo 3362 is used in eg. Openmoko's [[Neo FreeRunner|http://wiki.openmoko.org/wiki/Neo_FreeRunner_Hardware]]. 
+
+* Homepage: [[http://www.smediatech.com/product3362.htm|http://www.smediatech.com/product3362.htm]] 
+* 2D kernel driver: [[http://git.openmoko.org/?p=kernel.git;a=commit;h=911c6fab17f81ea2fdc6ad5e6173ce72bfe01ec4|http://git.openmoko.org/?p=kernel.git;a=commit;h=911c6fab17f81ea2fdc6ad5e6173ce72bfe01ec4]] 
+* 2D accelerated X driver: [[http://git.openmoko.org/?p=xglamo.git;a=summary|http://git.openmoko.org/?p=xglamo.git;a=summary]] 
+* Data sheet: [[http://people.openmoko.org/sean/datasheets/glamo3362/|http://people.openmoko.org/sean/datasheets/glamo3362/]] 
+Note that choosing Glamo has been accepted as a bit of a design mistake, both from performance point of view and openness point of view (3D part). So future Openmoko products will not feature the chip, but the currently (2008) selling Neo Free``Runner (GTA02) does have it and could be usable for 3D acceleration and other accelerations. Known limitations include (?) maximum framebuffer size of 512x512, which effectively excludes Free``Runner's default 480x640 out - so eg. the alternate resolution available, 240x320 (QVGA). is fine. 
+
+DRI2/KMS enabled stack (including attempts at 3D) work-in-progress [[here|http://www.bitwiz.org.uk/s/dri-for-the-freerunner.html]] 
+
+[[Some accelerated video decoding|http://unadventure.wordpress.com/2008/06/08/accelerating-in-my-pocket/]]. 
+
+
+
+---
+
+ [[CategoryHardwareVendor|CategoryHardwareVendor]] 
diff --git a/SMedia.moin b/SMedia.moin
deleted file mode 100644
index d464cee..0000000
--- a/SMedia.moin
+++ /dev/null
@@ -1,17 +0,0 @@
-== SMedia ==
-
-SMedia Glamo 3362 is used in eg. Openmoko's [[http://wiki.openmoko.org/wiki/Neo_FreeRunner_Hardware|Neo FreeRunner]].
-
- * Homepage: http://www.smediatech.com/product3362.htm
- * 2D kernel driver: http://git.openmoko.org/?p=kernel.git;a=commit;h=911c6fab17f81ea2fdc6ad5e6173ce72bfe01ec4
- * 2D accelerated X driver: http://git.openmoko.org/?p=xglamo.git;a=summary
- * Data sheet: http://people.openmoko.org/sean/datasheets/glamo3362/
-
-Note that choosing Glamo has been accepted as a bit of a design mistake, both from performance point of view and openness point of view (3D part). So future Openmoko products will not feature the chip, but the currently (2008) selling Neo Free``Runner (GTA02) does have it and could be usable for 3D acceleration and other accelerations. Known limitations include (?) maximum framebuffer size of 512x512, which effectively excludes Free``Runner's default 480x640 out - so eg. the alternate resolution available, 240x320 (QVGA). is fine.
-
-DRI2/KMS enabled stack (including attempts at 3D) work-in-progress [[http://www.bitwiz.org.uk/s/dri-for-the-freerunner.html |here]]
-
-[[http://unadventure.wordpress.com/2008/06/08/accelerating-in-my-pocket/|Some accelerated video decoding]].
-
-----
-CategoryHardwareVendor
diff --git a/SharedMemoryTransport.moin b/SharedMemoryTransport.mdwn
index 970875a..a788c59 100644
--- a/SharedMemoryTransport.moin
+++ b/SharedMemoryTransport.mdwn
@@ -1,439 +1,478 @@
-= Shared Memory Transport for XFree86 =
-Rickard E. Faith, Precision Insight, Inc.
-
-$Date: 2000/03/01 21:09:09 $, $Revision: 1.9 $
-
-Shared Memory Transport (SMT) is a mechanism for using shared memory to communicate X protocol information between the client application and the X server. This paper reviews existing SMT implementations, defines design criteria for SMT in XFree86, outlines a staged implementation of SMT for XFree86, and analyzes the performance of this implementation. On workstations, SMT has historically provided a significant improvement in performance. However, on modern workstations and on modern PC-class hardware, SMT improves overall performance by less than 10%. On modern hardware, the performance of the host CPU (including the X server and operating system implementations) is well-matched to the performance of the graphics hardware. Because of this, the performance of the typical X operation is almost completely limited by the performance of the graphics hardware, and the improvement in transport speed provided by SMT cannot provide large gains in rendering performance. Because of these observations, I do not recommend devoting more engineering time to the active improvement of the current SMT implementation for XFree86.
-
-<<TableOfContents>>
-
-== Preamble ==
-=== Copyright ===
-
-Copyright © 2000 by Precision Insight, Inc., Cedar Park, Texas.
-
-Permission is granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies.
-
-=== Trademarks ===
-
-Unix is a registered trademark of The Open Group. The 'X' device and X Windows System are trademarks of The Open Group. XFree86 is a trademark of The XFree86 Project. Linux is a registered trademark of Linus Torvalds. Intel is a trademark of Intel Corporation. SGI and Indigo2 High Impact are trademarks of Silicon Graphics, Inc. HP is a registered trademark of Hewlett-Packard Company. All other trademarks mentioned are the property of their respective owners.
-
-== Introduction ==
-=== X11 Transport ===
-
-X11 supports various methods for transporting information between the client application and the X server. For example, if the client and server are on different Unix machines, INET Domain Socket transport (i.e., via a common TCP/IP socket) might be used for the connection. Machines that support DECnet might use an alternative DECnet-based transport.
-
-If the client and server are on the same machine, however, Unix Domain Socket (UDS) transport (i.e., via a named pipe) may have lower overhead than a socket-based transport (because of lower operating-system implementation overhead). If it is more efficient, an X server will use UDS transport when the client and server are on the same machine. Some vendors may have special kernel-level interfaces which are even more efficient that UDS.
-
-=== Shared-Memory Transport ===
-
-Shared memory is memory that can be accessed by more than one process. For Unix-like operating systems, shared memory is usually managed via the System V shm system calls. Although early BSD systems did not have these calls, most modern Unix-like operating systems have implemented them in a portable fashion.
-
-Shared-memory transport (SMT) is an enhancement (or alternative) to pipe-based transport that uses shared memory in lieu of the pipe for the transport of X11 protocol between the client and the X server. XFree86 does not currently have a shared memory transport implementation because one was never included in the X11 sample server upon which XFree86 is based, and no one has subsequently donated an implementation. However, some vendors (e.g., DEC, HP, SGI, Sun) have implemented proprietary shared-memory transports that use shared-memory segments to communicate some or all of the X11 protocol data between the client and the server.
-
-The next section discusses key design issues regarding SMT. This discussion is followed by a review of current shared-memory transports.
-
-=== Design Issues ===
-
-Pipes (and local sockets) are implemented in the operating system kernel as FIFO buffers. The writer makes a call that causes the kernel to copy data from a user-space buffer into a kernel-space buffer. The reader makes another call that causes the kernel to copy the data from the kernel-space buffer into another user-space buffer. Therefore, two memory-to-memory copies are involved. When using shared memory, the client's user-space buffer and the server's user-space buffer can be the same memory region. Hence, one of the potential performance gains obtained by using SMT is the elimination of two memory-to-memory copies. Other issues that complicate the design will be discussed below.
-
-==== Synchronization ====
-
-The most basic complicating issue is that of synchronization: when a process writes to a pipe that is full, the kernel puts the process asleep until the reader has read part of the kernel-side buffer. Similarly, when a reader reads from an empty pipe, the reader is put to sleep until the writer writes more data. The X server and client both put the pipes in non-blocking mode so that they can perform other processing (e.g., reading from one pipe while waiting to write another pipe) while using `select(2)` or `poll(2)` to determine when the pipe is ready.
-
-In marked contrast, a shared memory segment is written and read from user-space and does not provide any sort of kernel-mediated synchronization. So, any SMT design must solve the synchronization problem. As we will see later in this paper, this problem is substantial.
-
-==== Size of X Requests ====
-
-When using pipes, the client assembles 1-3 different buffers into requests that are written to the pipe. The server then reads the pipe into a contiguous buffer. Since an X request (with the big requests extension [BIGREQ]) can be 4MB in length, an SMT implementation must either use a very large buffer (to assemble contiguous requests for use on the server side) or must provide fall-back involving memory-to-memory copies for large requests (thereby losing some fraction of the speedup provided by eliminating the copy).
-
-If an X request cannot fit contiguously in the shared memory buffer, other synchronization problems must be solved:
-
- 1. If the request does not fit in the space remaining in the buffer, but would fit if the buffer was empty, then the client may request notification from the server when the buffer is empty.
- 2. If the request does not fit in the buffer at all, the client must write pieces into the buffer and wait for notification from the server that another piece can be written.
-
-==== Security and Resource Management ====
-
-Since shared memory is a finite system resource, sharing a pool of shared-memory segments among several clients may be a reasonable resource management approach. However, if this means that one client can write into the shared-memory segment of another client, there is a potential security risk.
-
-Since X lacks any notion of privileges and all clients are treated equally [EP91], a rogue client cannot use access to the SMT buffer of another client to do anything that could not already be done via the rogue client's own pipe. In this sense, the use of a shared pool of shared-memory segments is acceptable. From a practical debugging standpoint, however, poorly written application-level code in one application should not be able to crash another application by writing into the wrong shared memory segment.
-
-From a resource management standpoint, using a shared pool of memory requires careful implementation so that the X server can always tell when a client is no longer using a segment.
-
-=== Related Work ===
-==== The MIT-SHM Extension ====
-
-The MIT-SHM extension [MIT-SHM] can provide some of the benefits of SMT. The MIT-SHM extension improves client performance by allowing for the creation of pixmaps in shared memory. In contrast to SMT, which is transparent to the client and has the potential to impact all protocol requests, MIT-SHM:
-
-
- 1. requires special code in the application, and
- 2. only improves code which uses XPutImage and XGetImage (and then only when certain restrictions apply to the pixmap format -- see [MITSHM] for details).
-
-The MIT-SHM extension is compatible with SMT, although its use will increase overall shared-memory resource utilization. In implementations of SMT which do not optimize GetImage, the MIT-SHM extension may still be an important tool for implementation of efficient clients.
-
-==== Other Shared-Memory Transport Implementations ====
-
-There is no example implementation of SMT available in the freely-available X11 source tree, and all vendor-specific SMT implementations are proprietary. Hence, implementation details are not readily available.
-
-Information on the web [DEC, HP] and in man pages (e.g., for SGI and Sun) can provide some insight into implementation details, as discussed below. Note, however, that this information may be out of date, and our inferences may be incorrect regarding the details of a specific vendor's implementation. This discussion, however, will outline some of the major design decisions faced by any implementation of shared-memory transport.
-
-===== Use of the Unix Domain Socket =====
-
-Vendor implementations of SMT [DEC, HP] use the usual UDS transport to provide:
-
- * SMT Flow control: UDS transport is used to notify the server when a request (or set of requests) is available for processing. This implies that a special X protocol extension must be used.
- * Responses: Minimally, all events and errors are sent from the server to the client using UDS transport. Many vendors also send all replies via the UDS transport, reserving SMT for requests.
-
-===== Use of the Shared Memory Segment =====
-
-Vendors [DEC, HP] generally use the shared-memory segment only for protocol requests, although GetImage has the potential to be dramtically improved by using shared-memory for replies. For some implementations, synchronization overhead can be dramatic (e.g., XNoOp may take significantly longer with SMT than with UDS [DEC]).
-
-===== Activation of SMT =====
-
-Most vendors key off the `DISPLAY` environment variable to determine if SMT should be used. For example, if `DISPLAY=local:0` [DEC] or `DISPLAY=shmlink:0` [HP], then SMT will be used. If `DISPLAY=unix:0`, then UDS transport will be used. And, if `DISPLAY=:0`, then the best possible transport will be used (e.g., SMT until the limit of SMT connections is reached, and UDS transport thereafter).
-
-Other vendors use the presence of an environment variable to alert the client that shared-memory transport should be requested.
-
-===== Tuning SMT =====
-
-SGI/IRIX man pages note that the number of SMT clients allowed by a particular server invocation is a tunable X server command-line parameter.
-
-Sun/Solaris man pages note that the size of the shared-memory segment can be tuned with an environment variable. This allows for per-client adjustment of the shared-memory segment.
-
-==== Profile of an HP X Server ====
-
-`x11perf` data was collected for HP's SMT-aware X server running under under HP-UX 10.20 on an HP 9000/735. Highlights of the output of `x11perfcomp` are presented here. (The means were computed from the raw rate (operations per second) data.)
-
-{{{
-   No SMT         SMT    Ratio   Operation
-2390000.0   3320000.0     1.39   Dot 
-1260000.0   1640000.0     1.30   1x1 rectangle 
- 280000.0    293000.0     1.05   10x10 rectangle 
-   9150.0      9150.0     1.00   100x100 rectangle 
-    437.0       437.0     1.00   500x500 rectangle
-1860000.0   2300000.0     1.24   1-pixel line 
- 936000.0   1020000.0     1.09   10-pixel line 
- 123000.0    124000.0     1.01   100-pixel line 
-  25300.0     25300.0     1.00   500-pixel line 
-  16900.0     20900.0     1.24   PutImage 10x10 square 
-    988.0      1620.0     1.64   PutImage 100x100 square 
-     40.0        33.9     0.85   PutImage 500x500 square 
-  20100.0     23300.0     1.16   ShmPutImage 10x10 square 
-   3390.0      3540.0     1.04   ShmPutImage 100x100 square 
-    131.0       131.0     1.00   ShmPutImage 500x500 square 
- 247000.0    252000.0     1.02   X protocol NoOperation
-
-Geometric mean for all operations:  1.06
-Maximum ratio:                      1.79 (1-pixel solid circle)
-Minimum ratio:                      0.80 (GetProperty)
-}}}         
-
-Note the trend over the rectangle and line operations: each of these operations requires the same amount of protocol to be transmitted, but the operations that can be rendered faster are accelerated more by SMT. Here, rendering time is the limiting factor on SMT performance improvement. Other operations with small protocol footprints showed a similar profile.
-
-For the PutImage operations, images that will fit in the shared-memory area are accelerated by SMT, with larger images being accelerated more, presumably because of the copy elimination. When the image no longer fits in the shared-memory area, the synchronization overhead of SMT slows the operation.
-
-==== Profile of an SGI X Server ====
-
-`x11perf` data was collected for SGI's SMT-aware X server running under IRIX 6.5 on an SGI Indigo2 High Impact. Highlights of the output of `x11perfcomp` are presented here. (The means were computed from the raw rate (operations per second) data. The SMT run did not complete, so all operations are not represented in the aggregate results.)
-
-{{{
-   No SMT         SMT    Ratio   Operation
-1940000.0   5270000.0    2.72    Dot 
-1400000.0   2370000.0    1.69    1x1 rectangle 
-1070000.0   1510000.0    1.41    10x10 rectangle 
-  18900.0     18900.0    1.00    100x100 rectangle 
-   1110.0      1110.0    1.00    500x500 rectangle 
-1450000.0   3180000.0    2.19    1-pixel line 
-1450000.0   3110000.0    2.14    10-pixel line 
- 409000.0    446000.0    1.09    100-pixel line 
-  92000.0     91900.0    1.00    500-pixel line 
-  34900.0     53100.0    1.52    PutImage 10x10 square 
-    601.0      1530.0    2.55    PutImage 100x100 square 
-     41.5        75.1    1.81    PutImage 500x500 square 
-  30400.0     40600.0    1.34    ShmPutImage 10x10 square 
-   1990.0      1940.0    0.97    ShmPutImage 100x100 square 
-    303.0       298.0    0.98    ShmPutImage 500x500 square 
- 529000.0    771000.0    1.46    X protocol NoOperation
-
-[See comment above: these aggregate values based on incomplete data.]
-Geometric mean for executed operations:  1.08
-Maximum ratio:                           2.72 (Dot)
-Minimum ratio:                           0.62 (10-pixel wide partial circle)
-}}}         
-
-Again, there is a trend over the rectangle and line operations: operations that take less time to render have a great improvement when SMT is used.
-
-== Design Criteria ==
-
-The previous section outlines some of the possible trade-offs involved in the design of an SMT system. This section outlines the design choices that were made for the XFree86 SMT implementation:
-
-=== Performance Goals ===
-
-The SMT implementation must have the following performance characteristics (performance will be measured using x11perf):
-
- * When SMT is not in use, the SMT-aware X server should have performance that is identical with a non-SMT-aware X server. This will ensure that when the SMT patches are enabled, they do not impact the performance of any non-SMT clients.
- * The performance of an SMT client should, on average, be better than that of a non-SMT client.
- * The performance of every `x11perf` tests should not be significantly worse when using SMT as compared to not using SMT (e.g., 50% performance from XNoOp is not acceptatble).
- * The addition of support for SMT should not impact the performance of other performance-related extensions, such as MIT-SHM [MITSHM] and the big requests extension [BIGREQ]. Indeed, big requests should transparently use the capabilities of the SMT implementation.
-
-=== Security and Stability ===
-==== Authenticated Connection ====
-
-A client can only initiate SMT after another local transport (e.g., UDS) has been connected. Any client authentication (i.e., via xauth) will be performed using the other transport, so the SMT implementation does not have to do any additional authentication.
-
-==== No Segment Sharing ====
-
-Some SMT implementations have used a shared pool of shared-memory segments to which all clients have access. This style of implementation is difficult because of the complexity of resource sharing issues, and should be avoided for an initial implementation. Therefore, the initial implementation of SMT for XFree86 will use a separate shared-memory segment for each client.
-
-If additional segments are required, they will either be private (per-client) read-write segments, as described in this section; or they will be public segments that allow read-only access by all of the clients and read-write access only by the X server.
-
-==== Server Creates and Destroys ====
-
-The X server will create all shared-memory segments. At the request of the client, the X server will create a segment, change the owner of the segment to the user ID of the client, and provide segment identifier to the client. This will ensure that a rogue client cannot attach to arbitrary shared memory segments. A rogue client could attach to the segment of other clients that shared its user id, but there is no advantage to this type of attack: without any SMT, the rogue could still open a standard connection to the X server and issue commands that impact the other clients [EP91].
-
-After the client attaches to the segment, the client will request that the X server start using the segment for transport. At this point, the X server can mark the segment as destroyed. This will prevent any other clients from attaching to the segment, and will ensure that the segment is returned to the system when the client and the X server detach. The server will also destroy and detach the segment if the client closes the non-SMT X protocol connection.
-
-=== Resource Management ===
-
-Shared memory is a precious system-wide resource. The `XF86Config` file should specify:
-
- * minimum and maximum values for the amount of shared memory that may be used by each client, and
- * a maximum value for the amount of shared memory that may be used by all clients.
-
-When the shared memory limits are exceeded, a request for SMT should fall-back to a non-SMT connection.
-
-A client will request SMT if the `XF86SMT` environment variable is set to a non-zero value that specifies the number of bytes requested for the shared memory segment. The shared memory segment actually used will be the lesser of the requested size and the minimum specified in the config file. SMT will not be activated if there is no more shared memory available.
-
-== Staged Implementation ==
-
-This section discusses a staged development process for adding SMT to XFree86. Early stages will lead to the rapid implementation of a usable shared-memory transport for XFree86. Later stages will require more implementation work, but will increase the performance improvement provided by SMT.
-
-=== Stage 1: Simple Two-Copy Implementation ===
-
-The first stage of SMT implementation will implement:
-
- * New Shared-Memory Transport: The X transport interface [XTRANS] has been encapsulated to simplify the addition of new transports. The SMT transport is a special case, however, since it relies on another transport being available for synchronization and, possibly, events, errors, and replies.
- * New X Protocol Extension: A protocol extension is required to establish the SMT connection.
-
-Stage 1 will demonstrate the feasibility of a simple, straight-forward SMT implementation that touches a minimum amount of code in the X11R6 source tree. This stage of implementation will send all X protocol commands through the shared-memory segment, using two user-space memory-to-memory copies (one on the client-side, and one on the server-side). The shared-memory segment is divided into two parts. The first part contains read and write pointers into the second part. The second part is treated as a large circular buffer.
-
-This implementation stage avoids moving data through the kernel, but still uses two copies to move the data between the client and the server. Since these two copies approximate the amount of work performed by a UDS-based implementation, this stage is not expected to be faster than pure UDS transport. Indeed, because of the simplistic synchronization used for this stage of implementation, performance will suffer.
-
-==== Performance Evaluation ====
-
-The initial implementation used the UDS (pipe) transport to send the size of the SMT data to the server after each write, and polled when the pipe was full. Because of this polling, this stage had extremely poor performance:
-
-{{{
-   No SMT         SMT    Ratio   Operation
-5720000.0   1320000.0    0.23    Dot 
-2060000.0    497000.0    0.24    1x1 rectangle 
- 808000.0    311000.0    0.38    10x10 rectangle 
-  24300.0     24200.0    1.00    100x100 rectangle 
-   1070.0      1070.0    1.00    500x500 rectangle 
-  57100.0      8020.0    0.14    PutImage 10x10 square 
-   1110.0       488.0    0.44    PutImage 100x100 square 
-     32.0        22.6    0.71    PutImage 500x500 square 
-2150000.0   2180000.0    1.01    X protocol NoOperation 
-}}}
-
-After the polling was eliminated, the performance improved:
-
-{{{
-   No SMT         SMT    Ratio   Operation
-5720000.0   4240000.0    0.74    Dot 
-2060000.0   1810000.0    0.88    1x1 rectangle 
- 808000.0    768000.0    0.95    10x10 rectangle 
-  24300.0     24200.0    1.00    100x100 rectangle 
-   1070.0      1070.0    1.00    500x500 rectangle 
-  57100.0     52400.0    0.92    PutImage 10x10 square 
-   1110.0       818.0    0.74    PutImage 100x100 square 
-     32.0        28.4    0.89    PutImage 500x500 square 
-2150000.0   2160000.0    1.00    X protocol NoOperation 
-}}}
-
-Without polling, operations that take longer to render perform at a speed similar to pipes. Operations that render quickly are slower because the overhead of copying and synchronization is starving the rendering engine. The Stage 2 implementation will concentrate on removing this overhead.
-
-=== Stage 2: Copy and Synchronization Elimination ===
-
-One of the well-known ways that SMT improves X performance is via copy-elimination: without SMT, the client does a copy from its buffer into the kernel-side pipe, and the server makes a copy of the pipe contents into its own buffer. However, use of the pipe has some constant overhead. Experiments that I've done suggest that pipe overhead can dominate copy time (especially when each buffer is already in the L2 cache, which may be a significant amount of the time). Hence, elimination of synchronization via the pipe is an extremely important part of SMT implementation.
-
-Stage 2 contains several sub-stages which are relatively independent:
-
- * Stage 2a: Elimination of server-side copy
- * Stage 2b: Partial elimination of synchronization
- * Stage 2c: Elimination of client-side copy
- * Stage 2d: Further elimination of synchronization
-
-Note that the elimination of client-side copies (Stage 2c) requires the introduction of additional synchronization. For the current implementation, Stage 2d is a replacement for Stage 2c. In this implementation, both the Stage 2c and the Stage 2d implementations sit on top of Stages 2a and 2b.
-
-=== Stage 2a: Elimination of Server-Side Copy ===
-
-Elimination of server-side copies requires solving two problems:
-
- * handling requests that are too big to fit in the shared-memory segment, or that are non-contiguous in the segment, and
- * notifying the client when the request is finished so that that part of the segment can be reused.
-
-Any request that falls off the end of the shared-memory segment causes the server to revert to a copy-based buffer. This same method also handles the case of a request that is too big for the buffer.
-
-Whenever the server asks for a new request, it is guaranteed that the server has finished processing all previous requests. At this time, the read pointer for the circular buffer in the shared-memory segment can be advanced. Currently, the pointer is advanced only after a complete subsequent request is received (or immediately, if reversion to a copy-based buffer has taken place).
-
-=== Stage 2b: Partial Elimination of Synchronization ===
-
-In the Stage 2a implementation, the pipe was used to notify the server whenever a copy into the shared-memory area was performed. This use of the pipe approximates the frequency at which the pipe would be used by a non-SMT implementation. In order to reduce use of the pipe in these situations, the following changes had to be made:
-
- * The client should use the pipe only when the server is sleeping.
- * Before doing a `select(2)`, the server should check all shared-memory areas to determine if there is pending input.
-
-The first problem was solved by creating another shared-memory segment that was writable by the server and readable by all of the clients. This segment contains a flag that the server sets before going to sleep (i.e., before calling `select(2)`). After copying information to the shared-memory segment, the client examines this flag and uses the pipe only if the server is asleep. Also, before the client goes to sleep (i.e., before calling `select(2)` or `poll(2)`), it makes sure the server is awake.
-
-Obviously, this scheme could introduce a race condition that would create deadlock with both the client and server sleeping. This race condition is avoided using strict client-side and server-side ordering. The client will:
-
- 1. Update the write pointer for the shared-memory segment.
- 2. Check the flag and write to the pipe if the server is sleeping.
- 3. Go to sleep if the client must wait on the server.
-
-The server will:
-
- 1. Set the flag.
- 2. Check all shared-memory areas for data (this can be optimized using a bitmap). If data is available, reset the flag and process the data, skipping the next step.
- 3. Go to sleep.
-
-==== Performance Evaluation ====
-
-{{{
-   No SMT         SMT    Ratio   Operation
-5720000.0   5650000.0    0.99    Dot 
-2060000.0   2270000.0    1.10    1x1 rectangle 
- 808000.0    838000.0    1.04    10x10 rectangle 
-  24300.0     24300.0    1.00    100x100 rectangle 
-   1070.0      1070.0    1.00    500x500 rectangle 
-  57100.0     63900.0    1.12    PutImage 10x10 square 
-   1110.0      1200.0    1.08    PutImage 100x100 square 
-     32.0        28.4    0.89    PutImage 500x500 square 
-2150000.0   2460000.0    1.14    X protocol NoOperation 
-}}}
-
-=== Stage 2c: Elimination of Client-Side Copy ===
-
-The client-side library uses several buffers for protocol requests to the server. The primary buffer is used for protocol headers and for many complete protocol requests. Elimination of the copy is easy for this buffer, since it can be directly replaced with the shared-memory segment. The only difficult problem is dealing with protocol requests that would wrap off the end of the buffer. These are handled by detecting when a wrap would have occurred, writing a special protocol request to the buffer that tells the server to wrap the pointers, and either writing into the first part of the buffer (if it is available) or waiting for the server to free up space in the buffer.
-
-The client also mallocs auxiliary buffers on-the-fly to handle the data portion of larger requests. Copies involving these buffers were not eliminated in this implementation, but would be a potential area for future improvement.
-
-==== Performance Evaluation ====
-
-{{{
-5720000.0   5940000.0    1.04    Dot 
-2060000.0   2260000.0    1.10    1x1 rectangle 
- 808000.0    837000.0    1.04    10x10 rectangle 
-  24300.0     24300.0    1.00    100x100 rectangle 
-   1070.0      1070.0    1.00    500x500 rectangle 
-  57100.0     77700.0    1.36    PutImage 10x10 square 
-   1110.0      1430.0    1.29    PutImage 100x100 square 
-     32.0        28.5    0.89    PutImage 500x500 square 
-2150000.0   2410000.0    1.12    X protocol NoOperation 
-}}}
-
-=== Stage 2d: Further Elimination of Synchronization ===
-
-Since Stage 2c added additional synchronization points, and since the use of the pipe appears to dominate any potential performance gain obtained from copy-elimination, Stage 2d will focus on elimination of synchronization without the elimination of client-side copies:
-
- * Optimize server-side reversion to copy-based buffer: only copy the current request, not all available bytes in the shared-memory segment. This should allow a rapid return to the copy-free state.
- * Clean up code to avoid unnecessary function calls (e.g., to test if the client is using SMT).
-
-==== Performance Evaluation ====
-
-{{{
-   No SMT         SMT    Ratio   Operation
-5720000.0   6590000.0 (  1.15)   Dot 
-2060000.0   2290000.0 (  1.11)   1x1 rectangle 
- 808000.0    842000.0 (  1.04)   10x10 rectangle 
-  24300.0     24300.0 (  1.00)   100x100 rectangle 
-   1070.0      1070.0 (  1.00)   500x500 rectangle 
-  57100.0     79900.0 (  1.40)   PutImage 10x10 square 
-   1110.0      1260.0 (  1.14)   PutImage 100x100 square 
-     32.0        28.4 (  0.89)   PutImage 500x500 square 
-2150000.0   2480000.0 (  1.15)   X protocol NoOperation 
-}}}
-
-These results are as good as or better then the Stage 2c results for most operations, without the additional complexity required for reduction of client-side copies.
-
-== Evaluation ==
-
-The data above were collected during the implementation phase using versions of XFree86 prior to 3.9.18. The following data were collected using XFree86 3.9.18 after a reboot on a 350MHz Pentium II with an ATI Rage 128 Pro card and 64MB of PC-100 SDRAM running Linux 2.3.42.
-
-The following table shows the means of `x11perf` output with the SMT patches, for clients that do or do not use SMT as the transport mechanism, compared with `x11perf` output for an X server built from a pristine XFree86 3.9.18 tree. Comparisons are made for 8 bit (8 bits per pixel) and 24 bit (32 bits per pixel) color depths.
-
-{{{
-                        No SMT      SMT
-8bit geometric mean:      1.01     1.03
-24bit geometric mean:     1.01     1.03
-}}}
-
-While some operations are more than 40% faster with SMT enabled, enabling SMT makes other operations up to 20% slower. The overall gain provided by the current SMT implementation is less than 5%.
-
-Clearly, SMT cannot improve operations that are render-bound, so the amount of overall improvement will depend on the speed of the graphics card compared with the speed of the host CPU: as the mismatch in relative speed increases, the improvement provided by SMT will also increase.
-
-Data from a small sample of mature proprietary SMT implementations support this conclusion, showing an overall 6-8% performance improvement when using SMT, with some operations up to 80-170% faster and other operations 20-40% slower. Workstation graphics subsystems often cost more, relative to the rest of the machine, than do PC-class graphics solutions. Since the relative mismatch in speed is greater, the relative improvement in SMT is also greater. This was demonstrated by gathering test data using a slower graphics card: the results, as expected, showed that the performance gain from SMT was under 3%.
-
-A fairer evaluation of SMT would examine only those operations which are not render bound. To illustrate, the following data was computed from `x11perf` operations that contain less than 101 pixels or less than 5 kids:
-
-{{{
-8bit geometric mean:      1.06
-24bit geometric mean:     1.05
-}}}
-
-These data suggest that applications that use small rendering operations frequently (e.g., window managers) would have a larger performance improvement that other applications. However because the improvement is so small, it may be dominated by other factors.
-
-== Recommendations ==
-
-SMT improves X11 performance, as measured by `x11perf`, by improving the speed of operations that are transport bound but that are not render bound. Operations that render tens or hundreds of pixels can be improved, but operations that render larger numbers of pixels (and are, therefore, already limited by the speed of the graphics adapter) are not improved. The amount of improvement for transport-bound operations is a function of the mismatch in speed between the host CPU and the graphics subsystem. When considering the host CPU the quality of the implementation of the X server and the operating system must also be included, since these impact the amount of work that the host CPU must do.
-
-On older workstations, the graphics subsystem often cost more than the rest of the machine, and was relatively much faster than the host CPU. On machines like this, marketing numbers for the improvement provided by SMT were often in the 15-25% range. Unfortunately, none of these machines were available for testing.
-
-A very small sample of newer workstations were tested, and the overall performance improvement provided by SMT was found to be in the 6-8% range.
-
-On typical PC-class hardware, the cost of the graphics adapter usually represents 5-15% of the cost of the rest of the machine and the rendering engine is relatively well matched to the speed of the host CPU. For systems like this, the current SMT implementation for XFree86 provided an overall speed improvement of less than 5%. This improvement will vary:
-
- * as a function of the mismatch in speeds between the host CPU and the graphics renderer, and
- * as a function of the optimization of the SMT implementation.
-
-However, on modern PC-class hardware an extremely optimized SMT implementation will probably improve performance by less than 10% (based on observations of workstation implementations and current graphics hardware) and a significant portion of this improvement can be obtained by building well-matched machines (e.g., using a faster host CPU when using a faster graphics adapter).
-
-Therefore, I do not recommend continued work on the current SMT project. The current SMT implementation will be submitted to XFree86, either for archival purposes or for inclusion in the distribution. SMT may be of significant benefit to those users who have mismatched hardware (e.g., an older CPU with a newer graphics card), but will probably not benefit high-end graphics users.
-
-== Future Work ==
-
-As noted above, I do not recommend pursuing further SMT optimizations since they are not expected to provide a large performance win for the vast majority of PC-class systems. However, there may be some niche where further development of SMT is justified, so some possible avenues of exploration are discussed in this section.
-
-=== Elimination of Client-Side Copies ===
-
-Elimination of client-side copies is difficult and adds additional synchronization points between the client and the X server (because the request must be contiguous in the buffer and cannot wrap). Further, many operations use an auxiliary buffer that is allocated on-the-fly. Elimination of client-side copies should address the synchronization problem and should eliminate copying of the auxiliary buffer. These problems were not addresses fully in the Stage 2c prototype discussed above.
-
-=== PutImage and GetImage ===
-
-PutImage and GetImage are commonly-used operations that transport large amounts of protocol to or from the X server. These operations are candidates for performance improvements that may be orthogonal to a general SMT implementation (i.e., they could be transparently improved using shared memory without using a full shared-memory transport). However, there are several factors that may eliminate the helpfulness of these optimizations:
-
- * Any performance improvement would depend on the size of the shared-memory region that was used for these operations. For example, a 500x500 color pixmap can require nearly 1MB of memory. All of the SMT data in this paper that was collected using XFree86 used a 256kB shared-memory buffer. Using a buffer that was smaller or larger degraded performance (perhaps because of L2 cache issues). So, using a 1MB (or larger) buffer for specialized PutImage and GetImage transport may not provide the expected gains. (Note, however, that if 256kB of image transport memory was typically available, applications programmers would be willing to break larger images up into pieces if there was a significant performance boost.)
- * The expected gains, based on observed SMT data, is in the 10-40% range. Improvements in this range may not justify the cost of the initial implementation.
- * Applications that are PutImage intensive probably already use the MIT shared-memory extension [MITSHM]
-
-== Acknowledgements ==
-
-Special thanks to Jens Owen and Kevin Martin for discussing SMT implementation issues and for reviewing early versions of this document. Thanks to Red Hat for funding this project.
-
-== References Cited ==
-
-[BIGREQ] Bob Scheifler. Big Requests Extension, Version 2.0. Available from xc/doc/specs/Xext/bigreq.ms and xc/doc/hardcopy/Xext/bigreq.PS.
-
-[DEC] X Window System Environment (Digital UNIX Version 4.0 or higher, March 1996). Digital Equipment Corporation, 1996. Available from http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-Q7RNB-TE_html/TITLE.html. Section 4.1.10, "SMT - Shared Memory Transport Extension (Digital provided)" is available from http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-Q7RNB-TE_html/xenvCH4.html.
-
-[EP91] Jeremy Epstein and Jeffrey Picciotto. Trusting X: Issues in Building Trusted X Window Systems -or- What's not Trusted About X? In Proceedings of the 14th Annual National Computer Security Conference, Washington, DC, October 1991.
-
-[HP] http://hpcc940.external.hp.com/xwindow/noFrames/features/smt.html.
-
-[MITSHM] Keith Packard. MIT-SHM -- The MIT Shared Memory Extension. Available from xc/doc/specs/Xext/mit-shm.ms and xc/doc/hardcopy/Xext/mit-shm.PS.
-
-[XTRANS] Stuart Anderson and Ralph Mor. X Transport Interface. Available from xc/doc/specs/xtrans/xtrans.mm and xc/doc/hardcopy/xtrans/Xtrans.PS.
-
-[XPROTO] Adrian Nye, editor. X Protocol Reference Manual for X11 Version 4, Release 6 (X Volume Zero). Sebastopol, California: O'Reilly & Associates, 1995.
-
+
+
+# Shared Memory Transport for XFree86
+
+Rickard E. Faith, Precision Insight, Inc. 
+
+$Date: 2000/03/01 21:09:09 $, $Revision: 1.9 $ 
+
+Shared Memory Transport (SMT) is a mechanism for using shared memory to communicate X protocol information between the client application and the X server. This paper reviews existing SMT implementations, defines design criteria for SMT in XFree86, outlines a staged implementation of SMT for XFree86, and analyzes the performance of this implementation. On workstations, SMT has historically provided a significant improvement in performance. However, on modern workstations and on modern PC-class hardware, SMT improves overall performance by less than 10%. On modern hardware, the performance of the host CPU (including the X server and operating system implementations) is well-matched to the performance of the graphics hardware. Because of this, the performance of the typical X operation is almost completely limited by the performance of the graphics hardware, and the improvement in transport speed provided by SMT cannot provide large gains in rendering performance. Because of these observations, I do not recommend devoting more engineering time to the active improvement of the current SMT implementation for XFree86. 
+
+[[!toc ]] 
+
+
+## Preamble
+
+
+### Copyright
+
+Copyright © 2000 by Precision Insight, Inc., Cedar Park, Texas. 
+
+Permission is granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies. 
+
+
+### Trademarks
+
+Unix is a registered trademark of The Open Group. The 'X' device and X Windows System are trademarks of The Open Group. XFree86 is a trademark of The XFree86 Project. Linux is a registered trademark of Linus Torvalds. Intel is a trademark of Intel Corporation. SGI and Indigo2 High Impact are trademarks of Silicon Graphics, Inc. HP is a registered trademark of Hewlett-Packard Company. All other trademarks mentioned are the property of their respective owners. 
+
+
+## Introduction
+
+
+### X11 Transport
+
+X11 supports various methods for transporting information between the client application and the X server. For example, if the client and server are on different Unix machines, INET Domain Socket transport (i.e., via a common TCP/IP socket) might be used for the connection. Machines that support DECnet might use an alternative DECnet-based transport. 
+
+If the client and server are on the same machine, however, Unix Domain Socket (UDS) transport (i.e., via a named pipe) may have lower overhead than a socket-based transport (because of lower operating-system implementation overhead). If it is more efficient, an X server will use UDS transport when the client and server are on the same machine. Some vendors may have special kernel-level interfaces which are even more efficient that UDS. 
+
+
+### Shared-Memory Transport
+
+Shared memory is memory that can be accessed by more than one process. For Unix-like operating systems, shared memory is usually managed via the System V shm system calls. Although early BSD systems did not have these calls, most modern Unix-like operating systems have implemented them in a portable fashion. 
+
+Shared-memory transport (SMT) is an enhancement (or alternative) to pipe-based transport that uses shared memory in lieu of the pipe for the transport of X11 protocol between the client and the X server. XFree86 does not currently have a shared memory transport implementation because one was never included in the X11 sample server upon which XFree86 is based, and no one has subsequently donated an implementation. However, some vendors (e.g., DEC, HP, SGI, Sun) have implemented proprietary shared-memory transports that use shared-memory segments to communicate some or all of the X11 protocol data between the client and the server. 
+
+The next section discusses key design issues regarding SMT. This discussion is followed by a review of current shared-memory transports. 
+
+
+### Design Issues
+
+Pipes (and local sockets) are implemented in the operating system kernel as FIFO buffers. The writer makes a call that causes the kernel to copy data from a user-space buffer into a kernel-space buffer. The reader makes another call that causes the kernel to copy the data from the kernel-space buffer into another user-space buffer. Therefore, two memory-to-memory copies are involved. When using shared memory, the client's user-space buffer and the server's user-space buffer can be the same memory region. Hence, one of the potential performance gains obtained by using SMT is the elimination of two memory-to-memory copies. Other issues that complicate the design will be discussed below. 
+
+
+#### Synchronization
+
+The most basic complicating issue is that of synchronization: when a process writes to a pipe that is full, the kernel puts the process asleep until the reader has read part of the kernel-side buffer. Similarly, when a reader reads from an empty pipe, the reader is put to sleep until the writer writes more data. The X server and client both put the pipes in non-blocking mode so that they can perform other processing (e.g., reading from one pipe while waiting to write another pipe) while using `select(2)` or `poll(2)` to determine when the pipe is ready. 
+
+In marked contrast, a shared memory segment is written and read from user-space and does not provide any sort of kernel-mediated synchronization. So, any SMT design must solve the synchronization problem. As we will see later in this paper, this problem is substantial. 
+
+
+#### Size of X Requests
+
+When using pipes, the client assembles 1-3 different buffers into requests that are written to the pipe. The server then reads the pipe into a contiguous buffer. Since an X request (with the big requests extension [BIGREQ]) can be 4MB in length, an SMT implementation must either use a very large buffer (to assemble contiguous requests for use on the server side) or must provide fall-back involving memory-to-memory copies for large requests (thereby losing some fraction of the speedup provided by eliminating the copy). 
+
+If an X request cannot fit contiguously in the shared memory buffer, other synchronization problems must be solved: 
+
+1. If the request does not fit in the space remaining in the buffer, but would fit if the buffer was empty, then the client may request notification from the server when the buffer is empty. 
+1. If the request does not fit in the buffer at all, the client must write pieces into the buffer and wait for notification from the server that another piece can be written. 
+
+#### Security and Resource Management
+
+Since shared memory is a finite system resource, sharing a pool of shared-memory segments among several clients may be a reasonable resource management approach. However, if this means that one client can write into the shared-memory segment of another client, there is a potential security risk. 
+
+Since X lacks any notion of privileges and all clients are treated equally [EP91], a rogue client cannot use access to the SMT buffer of another client to do anything that could not already be done via the rogue client's own pipe. In this sense, the use of a shared pool of shared-memory segments is acceptable. From a practical debugging standpoint, however, poorly written application-level code in one application should not be able to crash another application by writing into the wrong shared memory segment. 
+
+From a resource management standpoint, using a shared pool of memory requires careful implementation so that the X server can always tell when a client is no longer using a segment. 
+
+
+### Related Work
+
+
+#### The MIT-SHM Extension
+
+The MIT-SHM extension [MIT-SHM] can provide some of the benefits of SMT. The MIT-SHM extension improves client performance by allowing for the creation of pixmaps in shared memory. In contrast to SMT, which is transparent to the client and has the potential to impact all protocol requests, MIT-SHM: 
+
+1. requires special code in the application, and 
+1. only improves code which uses XPutImage and XGetImage (and then only when certain restrictions apply to the pixmap format -- see [MITSHM] for details). 
+The MIT-SHM extension is compatible with SMT, although its use will increase overall shared-memory resource utilization. In implementations of SMT which do not optimize [[GetImage|GetImage]], the MIT-SHM extension may still be an important tool for implementation of efficient clients. 
+
+
+#### Other Shared-Memory Transport Implementations
+
+There is no example implementation of SMT available in the freely-available X11 source tree, and all vendor-specific SMT implementations are proprietary. Hence, implementation details are not readily available. 
+
+Information on the web [DEC, HP] and in man pages (e.g., for SGI and Sun) can provide some insight into implementation details, as discussed below. Note, however, that this information may be out of date, and our inferences may be incorrect regarding the details of a specific vendor's implementation. This discussion, however, will outline some of the major design decisions faced by any implementation of shared-memory transport. 
+
+
+##### Use of the Unix Domain Socket
+
+Vendor implementations of SMT [DEC, HP] use the usual UDS transport to provide: 
+
+* SMT Flow control: UDS transport is used to notify the server when a request (or set of requests) is available for processing. This implies that a special X protocol extension must be used. 
+* Responses: Minimally, all events and errors are sent from the server to the client using UDS transport. Many vendors also send all replies via the UDS transport, reserving SMT for requests. 
+
+##### Use of the Shared Memory Segment
+
+Vendors [DEC, HP] generally use the shared-memory segment only for protocol requests, although [[GetImage|GetImage]] has the potential to be dramtically improved by using shared-memory for replies. For some implementations, synchronization overhead can be dramatic (e.g., XNoOp may take significantly longer with SMT than with UDS [DEC]). 
+
+
+##### Activation of SMT
+
+Most vendors key off the `DISPLAY` environment variable to determine if SMT should be used. For example, if `DISPLAY=local:0` [DEC] or `DISPLAY=shmlink:0` [HP], then SMT will be used. If `DISPLAY=unix:0`, then UDS transport will be used. And, if `DISPLAY=:0`, then the best possible transport will be used (e.g., SMT until the limit of SMT connections is reached, and UDS transport thereafter). 
+
+Other vendors use the presence of an environment variable to alert the client that shared-memory transport should be requested. 
+
+
+##### Tuning SMT
+
+SGI/IRIX man pages note that the number of SMT clients allowed by a particular server invocation is a tunable X server command-line parameter. 
+
+Sun/Solaris man pages note that the size of the shared-memory segment can be tuned with an environment variable. This allows for per-client adjustment of the shared-memory segment. 
+
+
+#### Profile of an HP X Server
+
+`x11perf` data was collected for HP's SMT-aware X server running under under HP-UX 10.20 on an HP 9000/735. Highlights of the output of `x11perfcomp` are presented here. (The means were computed from the raw rate (operations per second) data.) 
+
+
+[[!format txt """
+   No SMT         SMT    Ratio   Operation
+2390000.0   3320000.0     1.39   Dot 
+1260000.0   1640000.0     1.30   1x1 rectangle 
+ 280000.0    293000.0     1.05   10x10 rectangle 
+   9150.0      9150.0     1.00   100x100 rectangle 
+    437.0       437.0     1.00   500x500 rectangle
+1860000.0   2300000.0     1.24   1-pixel line 
+ 936000.0   1020000.0     1.09   10-pixel line 
+ 123000.0    124000.0     1.01   100-pixel line 
+  25300.0     25300.0     1.00   500-pixel line 
+  16900.0     20900.0     1.24   PutImage 10x10 square 
+    988.0      1620.0     1.64   PutImage 100x100 square 
+     40.0        33.9     0.85   PutImage 500x500 square 
+  20100.0     23300.0     1.16   ShmPutImage 10x10 square 
+   3390.0      3540.0     1.04   ShmPutImage 100x100 square 
+    131.0       131.0     1.00   ShmPutImage 500x500 square 
+ 247000.0    252000.0     1.02   X protocol NoOperation
+
+Geometric mean for all operations:  1.06
+Maximum ratio:                      1.79 (1-pixel solid circle)
+Minimum ratio:                      0.80 (GetProperty)
+"""]]
+         
+
+Note the trend over the rectangle and line operations: each of these operations requires the same amount of protocol to be transmitted, but the operations that can be rendered faster are accelerated more by SMT. Here, rendering time is the limiting factor on SMT performance improvement. Other operations with small protocol footprints showed a similar profile. 
+
+For the [[PutImage|PutImage]] operations, images that will fit in the shared-memory area are accelerated by SMT, with larger images being accelerated more, presumably because of the copy elimination. When the image no longer fits in the shared-memory area, the synchronization overhead of SMT slows the operation. 
+
+
+#### Profile of an SGI X Server
+
+`x11perf` data was collected for SGI's SMT-aware X server running under IRIX 6.5 on an SGI Indigo2 High Impact. Highlights of the output of `x11perfcomp` are presented here. (The means were computed from the raw rate (operations per second) data. The SMT run did not complete, so all operations are not represented in the aggregate results.) 
+
+
+[[!format txt """
+   No SMT         SMT    Ratio   Operation
+1940000.0   5270000.0    2.72    Dot 
+1400000.0   2370000.0    1.69    1x1 rectangle 
+1070000.0   1510000.0    1.41    10x10 rectangle 
+  18900.0     18900.0    1.00    100x100 rectangle 
+   1110.0      1110.0    1.00    500x500 rectangle 
+1450000.0   3180000.0    2.19    1-pixel line 
+1450000.0   3110000.0    2.14    10-pixel line 
+ 409000.0    446000.0    1.09    100-pixel line 
+  92000.0     91900.0    1.00    500-pixel line 
+  34900.0     53100.0    1.52    PutImage 10x10 square 
+    601.0      1530.0    2.55    PutImage 100x100 square 
+     41.5        75.1    1.81    PutImage 500x500 square 
+  30400.0     40600.0    1.34    ShmPutImage 10x10 square 
+   1990.0      1940.0    0.97    ShmPutImage 100x100 square 
+    303.0       298.0    0.98    ShmPutImage 500x500 square 
+ 529000.0    771000.0    1.46    X protocol NoOperation
+
+[See comment above: these aggregate values based on incomplete data.]
+Geometric mean for executed operations:  1.08
+Maximum ratio:                           2.72 (Dot)
+Minimum ratio:                           0.62 (10-pixel wide partial circle)
+"""]]
+         
+
+Again, there is a trend over the rectangle and line operations: operations that take less time to render have a great improvement when SMT is used. 
+
+
+## Design Criteria
+
+The previous section outlines some of the possible trade-offs involved in the design of an SMT system. This section outlines the design choices that were made for the XFree86 SMT implementation: 
+
+
+### Performance Goals
+
+The SMT implementation must have the following performance characteristics (performance will be measured using x11perf): 
+
+* When SMT is not in use, the SMT-aware X server should have performance that is identical with a non-SMT-aware X server. This will ensure that when the SMT patches are enabled, they do not impact the performance of any non-SMT clients. 
+* The performance of an SMT client should, on average, be better than that of a non-SMT client. 
+* The performance of every `x11perf` tests should not be significantly worse when using SMT as compared to not using SMT (e.g., 50% performance from XNoOp is not acceptatble). 
+* The addition of support for SMT should not impact the performance of other performance-related extensions, such as MIT-SHM [MITSHM] and the big requests extension [BIGREQ]. Indeed, big requests should transparently use the capabilities of the SMT implementation. 
+
+### Security and Stability
+
+
+#### Authenticated Connection
+
+A client can only initiate SMT after another local transport (e.g., UDS) has been connected. Any client authentication (i.e., via xauth) will be performed using the other transport, so the SMT implementation does not have to do any additional authentication. 
+
+
+#### No Segment Sharing
+
+Some SMT implementations have used a shared pool of shared-memory segments to which all clients have access. This style of implementation is difficult because of the complexity of resource sharing issues, and should be avoided for an initial implementation. Therefore, the initial implementation of SMT for XFree86 will use a separate shared-memory segment for each client. 
+
+If additional segments are required, they will either be private (per-client) read-write segments, as described in this section; or they will be public segments that allow read-only access by all of the clients and read-write access only by the X server. 
+
+
+#### Server Creates and Destroys
+
+The X server will create all shared-memory segments. At the request of the client, the X server will create a segment, change the owner of the segment to the user ID of the client, and provide segment identifier to the client. This will ensure that a rogue client cannot attach to arbitrary shared memory segments. A rogue client could attach to the segment of other clients that shared its user id, but there is no advantage to this type of attack: without any SMT, the rogue could still open a standard connection to the X server and issue commands that impact the other clients [EP91]. 
+
+After the client attaches to the segment, the client will request that the X server start using the segment for transport. At this point, the X server can mark the segment as destroyed. This will prevent any other clients from attaching to the segment, and will ensure that the segment is returned to the system when the client and the X server detach. The server will also destroy and detach the segment if the client closes the non-SMT X protocol connection. 
+
+
+### Resource Management
+
+Shared memory is a precious system-wide resource. The `XF86Config` file should specify: 
+
+* minimum and maximum values for the amount of shared memory that may be used by each client, and 
+* a maximum value for the amount of shared memory that may be used by all clients. 
+When the shared memory limits are exceeded, a request for SMT should fall-back to a non-SMT connection. 
+
+A client will request SMT if the `XF86SMT` environment variable is set to a non-zero value that specifies the number of bytes requested for the shared memory segment. The shared memory segment actually used will be the lesser of the requested size and the minimum specified in the config file. SMT will not be activated if there is no more shared memory available. 
+
+
+## Staged Implementation
+
+This section discusses a staged development process for adding SMT to XFree86. Early stages will lead to the rapid implementation of a usable shared-memory transport for XFree86. Later stages will require more implementation work, but will increase the performance improvement provided by SMT. 
+
+
+### Stage 1: Simple Two-Copy Implementation
+
+The first stage of SMT implementation will implement: 
+
+* New Shared-Memory Transport: The X transport interface [XTRANS] has been encapsulated to simplify the addition of new transports. The SMT transport is a special case, however, since it relies on another transport being available for synchronization and, possibly, events, errors, and replies. 
+* New X Protocol Extension: A protocol extension is required to establish the SMT connection. 
+Stage 1 will demonstrate the feasibility of a simple, straight-forward SMT implementation that touches a minimum amount of code in the [[X11R6|X11R6]] source tree. This stage of implementation will send all X protocol commands through the shared-memory segment, using two user-space memory-to-memory copies (one on the client-side, and one on the server-side). The shared-memory segment is divided into two parts. The first part contains read and write pointers into the second part. The second part is treated as a large circular buffer. 
+
+This implementation stage avoids moving data through the kernel, but still uses two copies to move the data between the client and the server. Since these two copies approximate the amount of work performed by a UDS-based implementation, this stage is not expected to be faster than pure UDS transport. Indeed, because of the simplistic synchronization used for this stage of implementation, performance will suffer. 
+
+
+#### Performance Evaluation
+
+The initial implementation used the UDS (pipe) transport to send the size of the SMT data to the server after each write, and polled when the pipe was full. Because of this polling, this stage had extremely poor performance: 
+
+
+[[!format txt """
+   No SMT         SMT    Ratio   Operation
+5720000.0   1320000.0    0.23    Dot 
+2060000.0    497000.0    0.24    1x1 rectangle 
+ 808000.0    311000.0    0.38    10x10 rectangle 
+  24300.0     24200.0    1.00    100x100 rectangle 
+   1070.0      1070.0    1.00    500x500 rectangle 
+  57100.0      8020.0    0.14    PutImage 10x10 square 
+   1110.0       488.0    0.44    PutImage 100x100 square 
+     32.0        22.6    0.71    PutImage 500x500 square 
+2150000.0   2180000.0    1.01    X protocol NoOperation 
+"""]]
+After the polling was eliminated, the performance improved: 
+
+
+[[!format txt """
+   No SMT         SMT    Ratio   Operation
+5720000.0   4240000.0    0.74    Dot 
+2060000.0   1810000.0    0.88    1x1 rectangle 
+ 808000.0    768000.0    0.95    10x10 rectangle 
+  24300.0     24200.0    1.00    100x100 rectangle 
+   1070.0      1070.0    1.00    500x500 rectangle 
+  57100.0     52400.0    0.92    PutImage 10x10 square 
+   1110.0       818.0    0.74    PutImage 100x100 square 
+     32.0        28.4    0.89    PutImage 500x500 square 
+2150000.0   2160000.0    1.00    X protocol NoOperation 
+"""]]
+Without polling, operations that take longer to render perform at a speed similar to pipes. Operations that render quickly are slower because the overhead of copying and synchronization is starving the rendering engine. The Stage 2 implementation will concentrate on removing this overhead. 
+
+
+### Stage 2: Copy and Synchronization Elimination
+
+One of the well-known ways that SMT improves X performance is via copy-elimination: without SMT, the client does a copy from its buffer into the kernel-side pipe, and the server makes a copy of the pipe contents into its own buffer. However, use of the pipe has some constant overhead. Experiments that I've done suggest that pipe overhead can dominate copy time (especially when each buffer is already in the L2 cache, which may be a significant amount of the time). Hence, elimination of synchronization via the pipe is an extremely important part of SMT implementation. 
+
+Stage 2 contains several sub-stages which are relatively independent: 
+
+* Stage 2a: Elimination of server-side copy 
+* Stage 2b: Partial elimination of synchronization 
+* Stage 2c: Elimination of client-side copy 
+* Stage 2d: Further elimination of synchronization 
+Note that the elimination of client-side copies (Stage 2c) requires the introduction of additional synchronization. For the current implementation, Stage 2d is a replacement for Stage 2c. In this implementation, both the Stage 2c and the Stage 2d implementations sit on top of Stages 2a and 2b. 
+
+
+### Stage 2a: Elimination of Server-Side Copy
+
+Elimination of server-side copies requires solving two problems: 
+
+* handling requests that are too big to fit in the shared-memory segment, or that are non-contiguous in the segment, and 
+* notifying the client when the request is finished so that that part of the segment can be reused. 
+Any request that falls off the end of the shared-memory segment causes the server to revert to a copy-based buffer. This same method also handles the case of a request that is too big for the buffer. 
+
+Whenever the server asks for a new request, it is guaranteed that the server has finished processing all previous requests. At this time, the read pointer for the circular buffer in the shared-memory segment can be advanced. Currently, the pointer is advanced only after a complete subsequent request is received (or immediately, if reversion to a copy-based buffer has taken place). 
+
+
+### Stage 2b: Partial Elimination of Synchronization
+
+In the Stage 2a implementation, the pipe was used to notify the server whenever a copy into the shared-memory area was performed. This use of the pipe approximates the frequency at which the pipe would be used by a non-SMT implementation. In order to reduce use of the pipe in these situations, the following changes had to be made: 
+
+* The client should use the pipe only when the server is sleeping. 
+* Before doing a `select(2)`, the server should check all shared-memory areas to determine if there is pending input. 
+The first problem was solved by creating another shared-memory segment that was writable by the server and readable by all of the clients. This segment contains a flag that the server sets before going to sleep (i.e., before calling `select(2)`). After copying information to the shared-memory segment, the client examines this flag and uses the pipe only if the server is asleep. Also, before the client goes to sleep (i.e., before calling `select(2)` or `poll(2)`), it makes sure the server is awake. 
+
+Obviously, this scheme could introduce a race condition that would create deadlock with both the client and server sleeping. This race condition is avoided using strict client-side and server-side ordering. The client will: 
+
+1. Update the write pointer for the shared-memory segment. 
+1. Check the flag and write to the pipe if the server is sleeping. 
+1. Go to sleep if the client must wait on the server. 
+The server will: 
+
+1. Set the flag. 
+1. Check all shared-memory areas for data (this can be optimized using a bitmap). If data is available, reset the flag and process the data, skipping the next step. 
+1. Go to sleep. 
+
+#### Performance Evaluation
+
+
+[[!format txt """
+   No SMT         SMT    Ratio   Operation
+5720000.0   5650000.0    0.99    Dot 
+2060000.0   2270000.0    1.10    1x1 rectangle 
+ 808000.0    838000.0    1.04    10x10 rectangle 
+  24300.0     24300.0    1.00    100x100 rectangle 
+   1070.0      1070.0    1.00    500x500 rectangle 
+  57100.0     63900.0    1.12    PutImage 10x10 square 
+   1110.0      1200.0    1.08    PutImage 100x100 square 
+     32.0        28.4    0.89    PutImage 500x500 square 
+2150000.0   2460000.0    1.14    X protocol NoOperation 
+"""]]
+
+### Stage 2c: Elimination of Client-Side Copy
+
+The client-side library uses several buffers for protocol requests to the server. The primary buffer is used for protocol headers and for many complete protocol requests. Elimination of the copy is easy for this buffer, since it can be directly replaced with the shared-memory segment. The only difficult problem is dealing with protocol requests that would wrap off the end of the buffer. These are handled by detecting when a wrap would have occurred, writing a special protocol request to the buffer that tells the server to wrap the pointers, and either writing into the first part of the buffer (if it is available) or waiting for the server to free up space in the buffer. 
+
+The client also mallocs auxiliary buffers on-the-fly to handle the data portion of larger requests. Copies involving these buffers were not eliminated in this implementation, but would be a potential area for future improvement. 
+
+
+#### Performance Evaluation
+
+
+[[!format txt """
+5720000.0   5940000.0    1.04    Dot 
+2060000.0   2260000.0    1.10    1x1 rectangle 
+ 808000.0    837000.0    1.04    10x10 rectangle 
+  24300.0     24300.0    1.00    100x100 rectangle 
+   1070.0      1070.0    1.00    500x500 rectangle 
+  57100.0     77700.0    1.36    PutImage 10x10 square 
+   1110.0      1430.0    1.29    PutImage 100x100 square 
+     32.0        28.5    0.89    PutImage 500x500 square 
+2150000.0   2410000.0    1.12    X protocol NoOperation 
+"""]]
+
+### Stage 2d: Further Elimination of Synchronization
+
+Since Stage 2c added additional synchronization points, and since the use of the pipe appears to dominate any potential performance gain obtained from copy-elimination, Stage 2d will focus on elimination of synchronization without the elimination of client-side copies: 
+
+* Optimize server-side reversion to copy-based buffer: only copy the current request, not all available bytes in the shared-memory segment. This should allow a rapid return to the copy-free state. 
+* Clean up code to avoid unnecessary function calls (e.g., to test if the client is using SMT). 
+
+#### Performance Evaluation
+
+
+[[!format txt """
+   No SMT         SMT    Ratio   Operation
+5720000.0   6590000.0 (  1.15)   Dot 
+2060000.0   2290000.0 (  1.11)   1x1 rectangle 
+ 808000.0    842000.0 (  1.04)   10x10 rectangle 
+  24300.0     24300.0 (  1.00)   100x100 rectangle 
+   1070.0      1070.0 (  1.00)   500x500 rectangle 
+  57100.0     79900.0 (  1.40)   PutImage 10x10 square 
+   1110.0      1260.0 (  1.14)   PutImage 100x100 square 
+     32.0        28.4 (  0.89)   PutImage 500x500 square 
+2150000.0   2480000.0 (  1.15)   X protocol NoOperation 
+"""]]
+These results are as good as or better then the Stage 2c results for most operations, without the additional complexity required for reduction of client-side copies. 
+
+
+## Evaluation
+
+The data above were collected during the implementation phase using versions of XFree86 prior to 3.9.18. The following data were collected using XFree86 3.9.18 after a reboot on a 350MHz Pentium II with an ATI Rage 128 Pro card and 64MB of PC-100 SDRAM running Linux 2.3.42. 
+
+The following table shows the means of `x11perf` output with the SMT patches, for clients that do or do not use SMT as the transport mechanism, compared with `x11perf` output for an X server built from a pristine XFree86 3.9.18 tree. Comparisons are made for 8 bit (8 bits per pixel) and 24 bit (32 bits per pixel) color depths. 
+
+
+[[!format txt """
+                        No SMT      SMT
+8bit geometric mean:      1.01     1.03
+24bit geometric mean:     1.01     1.03
+"""]]
+While some operations are more than 40% faster with SMT enabled, enabling SMT makes other operations up to 20% slower. The overall gain provided by the current SMT implementation is less than 5%. 
+
+Clearly, SMT cannot improve operations that are render-bound, so the amount of overall improvement will depend on the speed of the graphics card compared with the speed of the host CPU: as the mismatch in relative speed increases, the improvement provided by SMT will also increase. 
+
+Data from a small sample of mature proprietary SMT implementations support this conclusion, showing an overall 6-8% performance improvement when using SMT, with some operations up to 80-170% faster and other operations 20-40% slower. Workstation graphics subsystems often cost more, relative to the rest of the machine, than do PC-class graphics solutions. Since the relative mismatch in speed is greater, the relative improvement in SMT is also greater. This was demonstrated by gathering test data using a slower graphics card: the results, as expected, showed that the performance gain from SMT was under 3%. 
+
+A fairer evaluation of SMT would examine only those operations which are not render bound. To illustrate, the following data was computed from `x11perf` operations that contain less than 101 pixels or less than 5 kids: 
+
+
+[[!format txt """
+8bit geometric mean:      1.06
+24bit geometric mean:     1.05
+"""]]
+These data suggest that applications that use small rendering operations frequently (e.g., window managers) would have a larger performance improvement that other applications. However because the improvement is so small, it may be dominated by other factors. 
+
+
+## Recommendations
+
+SMT improves X11 performance, as measured by `x11perf`, by improving the speed of operations that are transport bound but that are not render bound. Operations that render tens or hundreds of pixels can be improved, but operations that render larger numbers of pixels (and are, therefore, already limited by the speed of the graphics adapter) are not improved. The amount of improvement for transport-bound operations is a function of the mismatch in speed between the host CPU and the graphics subsystem. When considering the host CPU the quality of the implementation of the X server and the operating system must also be included, since these impact the amount of work that the host CPU must do. 
+
+On older workstations, the graphics subsystem often cost more than the rest of the machine, and was relatively much faster than the host CPU. On machines like this, marketing numbers for the improvement provided by SMT were often in the 15-25% range. Unfortunately, none of these machines were available for testing. 
+
+A very small sample of newer workstations were tested, and the overall performance improvement provided by SMT was found to be in the 6-8% range. 
+
+On typical PC-class hardware, the cost of the graphics adapter usually represents 5-15% of the cost of the rest of the machine and the rendering engine is relatively well matched to the speed of the host CPU. For systems like this, the current SMT implementation for XFree86 provided an overall speed improvement of less than 5%. This improvement will vary: 
+
+* as a function of the mismatch in speeds between the host CPU and the graphics renderer, and 
+* as a function of the optimization of the SMT implementation. 
+However, on modern PC-class hardware an extremely optimized SMT implementation will probably improve performance by less than 10% (based on observations of workstation implementations and current graphics hardware) and a significant portion of this improvement can be obtained by building well-matched machines (e.g., using a faster host CPU when using a faster graphics adapter). 
+
+Therefore, I do not recommend continued work on the current SMT project. The current SMT implementation will be submitted to XFree86, either for archival purposes or for inclusion in the distribution. SMT may be of significant benefit to those users who have mismatched hardware (e.g., an older CPU with a newer graphics card), but will probably not benefit high-end graphics users. 
+
+
+## Future Work
+
+As noted above, I do not recommend pursuing further SMT optimizations since they are not expected to provide a large performance win for the vast majority of PC-class systems. However, there may be some niche where further development of SMT is justified, so some possible avenues of exploration are discussed in this section. 
+
+
+### Elimination of Client-Side Copies
+
+Elimination of client-side copies is difficult and adds additional synchronization points between the client and the X server (because the request must be contiguous in the buffer and cannot wrap). Further, many operations use an auxiliary buffer that is allocated on-the-fly. Elimination of client-side copies should address the synchronization problem and should eliminate copying of the auxiliary buffer. These problems were not addresses fully in the Stage 2c prototype discussed above. 
+
+
+### PutImage and GetImage
+
+[[PutImage|PutImage]] and [[GetImage|GetImage]] are commonly-used operations that transport large amounts of protocol to or from the X server. These operations are candidates for performance improvements that may be orthogonal to a general SMT implementation (i.e., they could be transparently improved using shared memory without using a full shared-memory transport). However, there are several factors that may eliminate the helpfulness of these optimizations: 
+
+* Any performance improvement would depend on the size of the shared-memory region that was used for these operations. For example, a 500x500 color pixmap can require nearly 1MB of memory. All of the SMT data in this paper that was collected using XFree86 used a 256kB shared-memory buffer. Using a buffer that was smaller or larger degraded performance (perhaps because of L2 cache issues). So, using a 1MB (or larger) buffer for specialized [[PutImage|PutImage]] and [[GetImage|GetImage]] transport may not provide the expected gains. (Note, however, that if 256kB of image transport memory was typically available, applications programmers would be willing to break larger images up into pieces if there was a significant performance boost.) 
+* The expected gains, based on observed SMT data, is in the 10-40% range. Improvements in this range may not justify the cost of the initial implementation. 
+* Applications that are [[PutImage|PutImage]] intensive probably already use the MIT shared-memory extension [MITSHM] 
+
+## Acknowledgements
+
+Special thanks to Jens Owen and Kevin Martin for discussing SMT implementation issues and for reviewing early versions of this document. Thanks to Red Hat for funding this project. 
+
+
+## References Cited
+
+[BIGREQ] Bob Scheifler. Big Requests Extension, Version 2.0. Available from xc/doc/specs/Xext/bigreq.ms and xc/doc/hardcopy/Xext/bigreq.PS. 
+
+[DEC] X Window System Environment (Digital UNIX Version 4.0 or higher, March 1996). Digital Equipment Corporation, 1996. Available from [[http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-Q7RNB-TE_html/TITLE.html|http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-Q7RNB-TE_html/TITLE.html]]. Section 4.1.10, "SMT - Shared Memory Transport Extension (Digital provided)" is available from [[http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-Q7RNB-TE_html/xenvCH4.html|http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/HTML/AA-Q7RNB-TE_html/xenvCH4.html]]. 
+
+[EP91] Jeremy Epstein and Jeffrey Picciotto. Trusting X: Issues in Building Trusted X Window Systems -or- What's not Trusted About X? In Proceedings of the 14th Annual National Computer Security Conference, Washington, DC, October 1991. 
+
+[HP] [[http://hpcc940.external.hp.com/xwindow/noFrames/features/smt.html|http://hpcc940.external.hp.com/xwindow/noFrames/features/smt.html]]. 
+
+[MITSHM] Keith Packard. MIT-SHM -- The MIT Shared Memory Extension. Available from xc/doc/specs/Xext/mit-shm.ms and xc/doc/hardcopy/Xext/mit-shm.PS. 
+
+[XTRANS] Stuart Anderson and Ralph Mor. X Transport Interface. Available from xc/doc/specs/xtrans/xtrans.mm and xc/doc/hardcopy/xtrans/Xtrans.PS. 
+
+[XPROTO] Adrian Nye, editor. X Protocol Reference Manual for X11 Version 4, Release 6 (X Volume Zero). Sebastopol, California: O'Reilly & Associates, 1995. 
diff --git a/SiS.mdwn b/SiS.mdwn
new file mode 100644
index 0000000..362aca4
--- /dev/null
+++ b/SiS.mdwn
@@ -0,0 +1,37 @@
+
+
+# Silicon Integrated Systems (SiS)
+
+**Chipsets** [[!map pages="^SiS.+"]] 
+
+
+## Status
+
+A DRI driver for the [[SiS300|SiS300]] series cards (300/305, 540, 630/730) is currently available in DRI CVS.  A DRI driver for the [[SiS6326|SiS6326]] and 530 cards is in development.  The newer 315 and Xabre series chips are not supported; neither are the SiS-based Volari chips from XGI (Volari V3XT, V5, and V8). 
+
+
+### [SiS] 661/741/760 PCI/AGP DRI Bounty
+
+There is no DRI driver for "[SiS] 661/741/760 PCI/AGP" chipset, if you want to get paid for writing it, or donate some money, you can do it at SiS DRI Bounty: 
+
+   * [[Donate using Creditcard / Paypal|http://sis-dri-bounty.harvie.cz/]] 
+   * [[Bid money or make offer to code drivers at cofundos.org|http://www.cofundos.org/project.php?id=185]] 
+
+## Specifications
+
+UtahGLX has posted some basic specs for some SiS chipsets (300 & 630): 
+
+   * [[http://prdownloads.sourceforge.net/utah-glx/300ds03.pdf?download|http://prdownloads.sourceforge.net/utah-glx/300ds03.pdf?download]] 
+   * [[http://prdownloads.sourceforge.net/utah-glx/630ds10a.pdf?download|http://prdownloads.sourceforge.net/utah-glx/630ds10a.pdf?download]] 
+There are no 2D or 3D specs available. 
+
+
+## Resources
+
+   * [[SiS homepage|http://www.sis.com/]] 
+   * [[Thomas Winischhofer's SiS graphics chipsets on Linux/XFree86 page|http://www.winischhofer.net/linuxsisvga.shtml]] 
+
+
+---
+
+ [[CategoryHardwareVendor|CategoryHardwareVendor]] 
diff --git a/SiS.moin b/SiS.moin
deleted file mode 100644
index 50b242e..0000000
--- a/SiS.moin
+++ /dev/null
@@ -1,29 +0,0 @@
-= Silicon Integrated Systems (SiS) =
-
-'''Chipsets'''
-<<PageList(^SiS.+)>>
-
-== Status ==
-
-A DRI driver for the SiS300 series cards (300/305, 540, 630/730) is currently available in DRI CVS.  A DRI driver for the SiS6326 and 530 cards is in development.  The newer 315 and Xabre series chips are not supported; neither are the SiS-based Volari chips from XGI (Volari V3XT, V5, and V8).
-
-=== [SiS] 661/741/760 PCI/AGP DRI Bounty ===
-There is no DRI driver for "[SiS] 661/741/760 PCI/AGP" chipset, if you want to get paid for writing it, or donate some money, you can do it at SiS DRI Bounty:
-  * [[http://sis-dri-bounty.harvie.cz/|Donate using Creditcard / Paypal]]
-  * [[http://www.cofundos.org/project.php?id=185|Bid money or make offer to code drivers at cofundos.org]]
-
-== Specifications ==
-
-UtahGLX has posted some basic specs for some SiS chipsets (300 & 630):
-  * http://prdownloads.sourceforge.net/utah-glx/300ds03.pdf?download
-  * http://prdownloads.sourceforge.net/utah-glx/630ds10a.pdf?download
-
-There are no 2D or 3D specs available.
-
-== Resources ==
-
-  * [[http://www.sis.com/|SiS homepage]]
-  * [[http://www.winischhofer.net/linuxsisvga.shtml|Thomas Winischhofer's SiS graphics chipsets on Linux/XFree86 page]]
-
-----
-CategoryHardwareVendor
diff --git a/SiS300.mdwn b/SiS300.mdwn
new file mode 100644
index 0000000..30b1895
--- /dev/null
+++ b/SiS300.mdwn
@@ -0,0 +1,34 @@
+
+
+# Chipset Name
+
+* SiS 300 
+* SiS 305 
+* SiS 540 
+* SiS 630/S/ST/E/ET 
+* SiS 730/S 
+
+## Status
+
+The SiS DRI driver which supported these cards was shipped disabled in XFree86 4.3.0.  It has been updated for Mesa 5.x by Eric Anholt with the support of [[LinuxFund|LinuxFund]], and will be included in XFree86 4.4.0. 
+
+
+## Specifications
+
+UtahGLX has posted basic specs for some SiS chipsets (300 & 630): 
+
+   * [[http://prdownloads.sourceforge.net/utah-glx/300ds03.pdf?download|http://prdownloads.sourceforge.net/utah-glx/300ds03.pdf?download]] 
+   * [[http://prdownloads.sourceforge.net/utah-glx/630ds10a.pdf?download|http://prdownloads.sourceforge.net/utah-glx/630ds10a.pdf?download]] 
+There are no 2D or 3D specs available. 
+
+
+## Resources
+
+   * [[SiS homepage|http://www.sis.com/]] 
+   * [[Thomas Winischhofer's SiS graphics chipsets and Xfree86/Linux page|http://www.winischhofer.net/linuxsisvga.shtml]] 
+   * [[Thomas Winischhofer's SiS 300 series and DRI page|http://www.winischhofer.net/sisdri.shtml]] 
+
+
+---
+
+ [[CategoryHardwareChipset|CategoryHardwareChipset]] 
diff --git a/SiS300.moin b/SiS300.moin
deleted file mode 100644
index a69cd3a..0000000
--- a/SiS300.moin
+++ /dev/null
@@ -1,26 +0,0 @@
-= Chipset Name =
- * SiS 300
- * SiS 305
- * SiS 540
- * SiS 630/S/ST/E/ET
- * SiS 730/S
-
-== Status ==
-The SiS DRI driver which supported these cards was shipped disabled in XFree86 4.3.0.  It has been updated for Mesa 5.x by Eric Anholt with the support of LinuxFund, and will be included in XFree86 4.4.0.
-
-== Specifications ==
-
-UtahGLX has posted basic specs for some SiS chipsets (300 & 630):
-  * http://prdownloads.sourceforge.net/utah-glx/300ds03.pdf?download
-  * http://prdownloads.sourceforge.net/utah-glx/630ds10a.pdf?download
-
-There are no 2D or 3D specs available.
-
-== Resources ==
-  * [[http://www.sis.com/|SiS homepage]]
-  * [[http://www.winischhofer.net/linuxsisvga.shtml|Thomas Winischhofer's SiS graphics chipsets and Xfree86/Linux page]]
-  * [[http://www.winischhofer.net/sisdri.shtml|Thomas Winischhofer's SiS 300 series and DRI page]]
- 
-
-----
-CategoryHardwareChipset
diff --git a/SiS530.mdwn b/SiS530.mdwn
new file mode 100644
index 0000000..ae8343c
--- /dev/null
+++ b/SiS530.mdwn
@@ -0,0 +1,26 @@
+
+
+# Chipset Name
+
+sis530 
+
+
+## Status
+
+A driver for the sis530/6326 is in development. 
+
+
+## Specifications
+
+   * SiS530 datasheet (using for [[SiS53fb|SiS53fb]] driver) 
+   * [[http://softpixel.com/~cwright/papers/tech/0530DS10.PDF|http://softpixel.com/~cwright/papers/tech/0530DS10.PDF]] 
+
+## Resources
+
+   * [[SiS homepage|http://www.sis.com/]] 
+   * [[Thomas Winischhofer's SiS graphics chipsets on Linux/XFree86 page|http://www.winischhofer.net/linuxsisvga.shtml]] 
+
+
+---
+
+ [[CategoryHardwareChipset|CategoryHardwareChipset]] 
diff --git a/SiS530.moin b/SiS530.moin
deleted file mode 100644
index f6df241..0000000
--- a/SiS530.moin
+++ /dev/null
@@ -1,16 +0,0 @@
-= Chipset Name =
-sis530
-
-== Status ==
-A driver for the sis530/6326 is in development.
-
-== Specifications ==
-  SiS530 datasheet (using for SiS53fb driver)
-  * [[http://softpixel.com/~cwright/papers/tech/0530DS10.PDF]]
-
-== Resources ==
-  * [[http://www.sis.com/|SiS homepage]]
-  * [[http://www.winischhofer.net/linuxsisvga.shtml|Thomas Winischhofer's SiS graphics chipsets on Linux/XFree86 page]]
-
-----
-CategoryHardwareChipset
diff --git a/SiS6326.mdwn b/SiS6326.mdwn
new file mode 100644
index 0000000..7ab2e65
--- /dev/null
+++ b/SiS6326.mdwn
@@ -0,0 +1,30 @@
+
+
+# Chipset Name
+
+* SiS 6326 
+* SiS 530 
+
+## Status
+
+A driver for the SiS 6326 series is currently in development by [[EricAnholt|EricAnholt]]. [[AlanCox|AlanCox]] has ported it to run with XFree 4.3.0 and the sis-4.4.0 DRI module. Basic 3D stuff works with some depth and triangle setup problems, also no textures yet. 
+
+Notable differences from the [[SiS300|SiS300]] series are that these cards have a single texture unit and a 16-bit Z buffer. A UtahGLX driver for these cards is available. 
+
+
+## Specifications
+
+   * [[SiS530|SiS530]] datasheet (using for [[SiS53fb|SiS53fb]] driver) 
+   * [[http://softpixel.com/~cwright/papers/tech/0530DS10.PDF|http://softpixel.com/~cwright/papers/tech/0530DS10.PDF]] 6326 SiS datasheet (chipset) exe (self extracting) 
+   * [[http://softpixel.com/~cwright/papers/tech/6326ds10.exe|http://softpixel.com/~cwright/papers/tech/6326ds10.exe]] 
+
+## Resources
+
+   * [[SiS homepage|http://www.sis.com/]] 
+   * [[Thomas Winischhofer's SiS graphics chipsets and Linux/XFree86 page|http://www.winischhofer.net/linuxsisvga.shtml]] 
+   * [[Current code drop from Alan Cox|http://www.linux.org.uk/~alan/sis6326.tar.gz]] 
+
+
+---
+
+ [[CategoryHardwareChipset|CategoryHardwareChipset]] 
diff --git a/SiS6326.moin b/SiS6326.moin
deleted file mode 100644
index 64f4e5a..0000000
--- a/SiS6326.moin
+++ /dev/null
@@ -1,26 +0,0 @@
-= Chipset Name =
- * SiS 6326
- * SiS 530
-
-== Status ==
-A driver for the SiS 6326 series is currently in development by EricAnholt.
-AlanCox has ported it to run with XFree 4.3.0 and the sis-4.4.0 DRI module.
-Basic 3D stuff works with some depth and triangle setup problems, also no textures yet.
-
-Notable differences from the SiS300 series are that these cards have a single texture unit and a 16-bit Z buffer.
-A UtahGLX driver for these cards is available.
-
-== Specifications ==
-  SiS530 datasheet (using for SiS53fb driver)
-  * [[http://softpixel.com/~cwright/papers/tech/0530DS10.PDF]]
-
-  6326 SiS datasheet (chipset) exe (self extracting)
-  * [[http://softpixel.com/~cwright/papers/tech/6326ds10.exe]]
-
-== Resources ==
-  * [[http://www.sis.com/|SiS homepage]]
-  * [[http://www.winischhofer.net/linuxsisvga.shtml|Thomas Winischhofer's SiS graphics chipsets and Linux/XFree86 page]]
-  * [[http://www.linux.org.uk/~alan/sis6326.tar.gz|Current code drop from Alan Cox]]
-
-----
-CategoryHardwareChipset
diff --git a/SigGraph.mdwn b/SigGraph.mdwn
new file mode 100644
index 0000000..d022168
--- /dev/null
+++ b/SigGraph.mdwn
@@ -0,0 +1,11 @@
+
+
+## SigGraph
+
+See [[http://www.siggraph.org/|http://www.siggraph.org/]] 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/SigGraph.moin b/SigGraph.moin
deleted file mode 100644
index 9f9812c..0000000
--- a/SigGraph.moin
+++ /dev/null
@@ -1,6 +0,0 @@
-== SigGraph ==
-
-See http://www.siggraph.org/
-
-----
-CategoryGlossary
diff --git a/SiliconMotion.mdwn b/SiliconMotion.mdwn
new file mode 100644
index 0000000..0eda8a1
--- /dev/null
+++ b/SiliconMotion.mdwn
@@ -0,0 +1,23 @@
+
+
+# Silicon Motion, Inc.
+
+**Chipsets** [[!map pages="^SiliconMotion.+"]] 
+
+* [[SiliconMotionSM722|SiliconMotionSM722]] 
+* [[SiliconMotionSM731|SiliconMotionSM731]] 
+
+## Status
+
+There is no SiliconMotion driver yet.  There could be though.  The [[SM722|ftp://ftp.siliconmotion.com.tw/databooks/SM722_Rev08.pdf]] and [[SM731|ftp://ftp.siliconmotion.com.tw/databooks/SM731_Rev_1.5.pdf]] databooks appear to have all the information needed to build a working driver.  This would make a good project for a few people to tackle. 
+
+
+## Resources
+
+* [[Silicon Motion, Inc. homepage|http://www.siliconmotion.com/en/]] 
+* [[Paceblade: builds devices with these chipsets and has a Linux support site|http://www.paceblade.com/]] 
+
+
+---
+
+ [[CategoryHardwareVendor|CategoryHardwareVendor]] [[CategoryHelpWanted|CategoryHelpWanted]] 
diff --git a/SiliconMotion.moin b/SiliconMotion.moin
deleted file mode 100644
index 43c3294..0000000
--- a/SiliconMotion.moin
+++ /dev/null
@@ -1,19 +0,0 @@
-= Silicon Motion, Inc. =
-
-'''Chipsets'''
-<<PageList(^SiliconMotion.+)>>
- * [[SiliconMotionSM722]]
- * [[SiliconMotionSM731]]
-
-== Status ==
-
-There is no SiliconMotion driver yet.  There could be though.  The [[ftp://ftp.siliconmotion.com.tw/databooks/SM722_Rev08.pdf|SM722]] and [[ftp://ftp.siliconmotion.com.tw/databooks/SM731_Rev_1.5.pdf|SM731]] databooks appear to have all the information needed to build a working driver.  This would make a good project for a few people to tackle.
-
-== Resources ==
-
- * [[http://www.siliconmotion.com/en/|Silicon Motion, Inc. homepage]]
- * [[http://www.paceblade.com/|Paceblade: builds devices with these chipsets and has a Linux support site]]
-
-----
-CategoryHardwareVendor
-CategoryHelpWanted
diff --git a/SiliconMotionSM722.mdwn b/SiliconMotionSM722.mdwn
new file mode 100644
index 0000000..421d19a
--- /dev/null
+++ b/SiliconMotionSM722.mdwn
@@ -0,0 +1,36 @@
+
+
+# SiliconMotion SM722
+
+[[SiliconMotion|SiliconMotion]] chipset, sometimes named SMI722 or LYNX3DM 
+
+Overview from their website: 
+[[!format txt """
+ + 128-Bit 2D/3D Graphics Engine
+ + High Integration with up to 8MB of Internal Memory
+ + Hardware Accelerated MPEG2/DVD Playback
+ + Industrial Temperature Available (-40° to +85°)
+ + Long Term Supply Assurance
+"""]]
+
+## Status
+
+[[ToDo|ToDo]] 
+
+
+## Specifications
+
+Complete register level spec.: [[ftp://ftp.siliconmotion.com.tw/databooks/SM722_Rev08.pdf|ftp://ftp.siliconmotion.com.tw/databooks/SM722_Rev08.pdf]] 
+
+btw: there are some more databooks available in the directory 
+
+
+## Resources
+
+[[http://www.siliconmotion.com.tw/en/en2/products4c.htm|http://www.siliconmotion.com.tw/en/en2/products4c.htm]] 
+
+
+
+---
+
+ [[CategoryHardwareChipset|CategoryHardwareChipset]], [[CategoryHelpWanted|CategoryHelpWanted]] 
diff --git a/SiliconMotionSM722.moin b/SiliconMotionSM722.moin
deleted file mode 100644
index 40a9040..0000000
--- a/SiliconMotionSM722.moin
+++ /dev/null
@@ -1,29 +0,0 @@
-= SiliconMotion SM722 =
-[[SiliconMotion]] chipset, sometimes named SMI722 or LYNX3DM
-
-Overview from their website:
-{{{
- + 128-Bit 2D/3D Graphics Engine
- + High Integration with up to 8MB of Internal Memory
- + Hardware Accelerated MPEG2/DVD Playback
- + Industrial Temperature Available (-40° to +85°)
- + Long Term Supply Assurance
-}}}
-
-== Status ==
-
-ToDo
-
-== Specifications ==
-
-Complete register level spec.:
-[[ftp://ftp.siliconmotion.com.tw/databooks/SM722_Rev08.pdf]]
-
-btw: there are some more databooks available in the directory
-
-== Resources ==
-
-[[http://www.siliconmotion.com.tw/en/en2/products4c.htm]]
-
-----
-CategoryHardwareChipset, CategoryHelpWanted
diff --git a/SiliconMotionSM731.mdwn b/SiliconMotionSM731.mdwn
new file mode 100644
index 0000000..f7ac0f9
--- /dev/null
+++ b/SiliconMotionSM731.mdwn
@@ -0,0 +1,35 @@
+
+
+# SiliconMotion SM731
+
+[[SiliconMotion|SiliconMotion]] chipset, sometimes named SMI731 or COUGAR3DR 
+
+Overview from their website: 
+[[!format txt """
+ + Ultra low-power 3D/2D display controller
+ + DualMon technology for expanded view on secondary monitor
+ + QuickRotate feature for instantaneous rotation
+ + Hardware supported rotation for 90, 180 and 270
+ + TabView(TM) for extended desktop view on secondary monitor for docked TabletPC
+ + Enhanced ReduceOn(TM) power management
+"""]]
+
+## Status
+
+[[ToDo|ToDo]] 
+
+
+## Specifications
+
+Complete register level spec.: [[ftp://ftp.siliconmotion.com.tw/databooks/SM731_Rev_1.5.pdf|ftp://ftp.siliconmotion.com.tw/databooks/SM731_Rev_1.5.pdf]] 
+
+
+## Resources
+
+[[http://www.siliconmotion.com.tw/en/en2/products4d.htm|http://www.siliconmotion.com.tw/en/en2/products4d.htm]] 
+
+
+
+---
+
+ [[CategoryHardwareChipset|CategoryHardwareChipset]], [[CategoryHelpWanted|CategoryHelpWanted]] 
diff --git a/SiliconMotionSM731.moin b/SiliconMotionSM731.moin
deleted file mode 100644
index 8cbdbca..0000000
--- a/SiliconMotionSM731.moin
+++ /dev/null
@@ -1,27 +0,0 @@
-= SiliconMotion SM731 =
-SiliconMotion chipset, sometimes named SMI731 or COUGAR3DR
-
-Overview from their website:
-{{{
- + Ultra low-power 3D/2D display controller
- + DualMon technology for expanded view on secondary monitor
- + QuickRotate feature for instantaneous rotation
- + Hardware supported rotation for 90, 180 and 270
- + TabView(TM) for extended desktop view on secondary monitor for docked TabletPC
- + Enhanced ReduceOn(TM) power management
-}}}
-== Status ==
-
-ToDo
-
-== Specifications ==
-
-Complete register level spec.:
-[[ftp://ftp.siliconmotion.com.tw/databooks/SM731_Rev_1.5.pdf]]
-
-== Resources ==
-
-[[http://www.siliconmotion.com.tw/en/en2/products4d.htm]]
-
-----
-CategoryHardwareChipset, CategoryHelpWanted
diff --git a/Solaris.mdwn b/Solaris.mdwn
new file mode 100644
index 0000000..aaf1113
--- /dev/null
+++ b/Solaris.mdwn
@@ -0,0 +1,23 @@
+
+
+# Solaris
+
+Unix operating system from Sun Microsystems for sparc, sparc64, x86, and amd64 hardware. 
+
+
+## Status
+
+For the DRI to work on Solaris, someone would need to implement the DRM layer.  This would involve adding a DRM kernel subsystem to the Solaris kernel, and possibly adding some Solaris support to libdrm. 
+
+This has been done in the development release of Solaris ("Nevada"), and the i915 DRM module provided. 
+
+
+## Resources
+
+   * [[OpenSolaris Heads-up: Direct Rendering Infrastructure (DRI) Integration|http://www.opensolaris.org/os/community/on/flag-days/pages/2006102901/]] 
+   * [[Notes for porting DRI to Solaris|http://bolthole.com/solaris/drivers/DRI.html]] 
+
+
+---
+
+ [[CategoryOperatingSystem|CategoryOperatingSystem]], [[CategoryHelpWanted|CategoryHelpWanted]] 
diff --git a/Solaris.moin b/Solaris.moin
deleted file mode 100644
index 54fae49..0000000
--- a/Solaris.moin
+++ /dev/null
@@ -1,17 +0,0 @@
-= Solaris =
-
-Unix operating system from Sun Microsystems for sparc, sparc64, x86, and amd64 hardware.
-
-== Status ==
-
-For the DRI to work on Solaris, someone would need to implement the DRM layer.  This would involve adding a DRM kernel subsystem to the Solaris kernel, and possibly adding some Solaris support to libdrm.
-
-This has been done in the development release of Solaris ("Nevada"), and the i915 DRM module provided.
-
-== Resources ==
-
-  * [[http://www.opensolaris.org/os/community/on/flag-days/pages/2006102901/|OpenSolaris Heads-up: Direct Rendering Infrastructure (DRI) Integration]]
-  * [[http://bolthole.com/solaris/drivers/DRI.html|Notes for porting DRI to Solaris]]
-
-----
-CategoryOperatingSystem, CategoryHelpWanted
diff --git a/SourceForge.moin b/SourceForge.mdwn
index 327d955..89e58e1 100644
--- a/SourceForge.moin
+++ b/SourceForge.mdwn
@@ -1 +1,2 @@
-SourceForge``.net is a site that provides services including CVS, web, bug tracking, and mailing lists to open-source projects.   Currently the DRI project uses the mailinglist and web services.  Our CVS services are provided by http://www.freedesktop.org/, and bug tracking is done through BugZilla.
+
+SourceForge``.net is a site that provides services including CVS, web, bug tracking, and mailing lists to open-source projects.   Currently the DRI project uses the mailinglist and web services.  Our CVS services are provided by [[http://www.freedesktop.org/|http://www.freedesktop.org/]], and bug tracking is done through [[BugZilla|BugZilla]]. 
diff --git a/Status.mdwn b/Status.mdwn
new file mode 100644
index 0000000..86d23c5
--- /dev/null
+++ b/Status.mdwn
@@ -0,0 +1,28 @@
+
+
+# DRI Status
+
+If your hardware is not listed then it its 3D features are most likely not supported or work is in very early stages of development. Note that some vendor pages might be more up to date than chipset pages, and vice versa. 
+
+Links: 
+
+* [[RadeonFeature|http://xorg.freedesktop.org/wiki/RadeonFeature]] (X.org wiki): Status of ATI/AMD Radeon 3D features among else 
+* [[FeatureMatrix|http://nouveau.freedesktop.org/wiki/FeatureMatrix]] (Nouveau wiki): Status of Nouveau drivers 
+* [[GalliumStatus|http://www.x.org/wiki/GalliumStatus]] (X.org wiki): Status of Gallium3D Pipes and State Trackers 
+* [[FeatureMatrix|FeatureMatrix]] (outdated): Detailed summary of DRI driver features for a card and all supported cards 
+   * <small>[[even more outdated, static version|http://dri.sourceforge.net/doc/dri_driver_features.phtml]]</small> 
+* [[Listing of 3D chips and their capabilities|http://pclinks.xtreemhost.com/video.htm]] 
+
+## Independent Hardware Vendors
+
+[[!inline pages="link('CategoryHardwareVendor')" quick feeds="no" archive="yes"]] 
+
+
+## Chipsets
+
+[[!inline pages="link('CategoryHardwareChipset')" quick feeds="no" archive="yes"]] 
+
+
+## Operating Systems
+
+[[!inline pages="link('CategoryOperatingSystem')" quick feeds="no" archive="yes"]] 
diff --git a/Status.moin b/Status.moin
deleted file mode 100644
index 3d30dcb..0000000
--- a/Status.moin
+++ /dev/null
@@ -1,24 +0,0 @@
-= DRI Status =
-
-If your hardware is not listed then it its 3D features are most likely not supported or work is in very early stages of development. Note that some vendor pages might be more up to date than chipset pages, and vice versa.
-
-Links:
- * [[http://xorg.freedesktop.org/wiki/RadeonFeature|RadeonFeature]] (X.org wiki): Status of ATI/AMD Radeon 3D features among else
- * [[http://nouveau.freedesktop.org/wiki/FeatureMatrix|FeatureMatrix]] (Nouveau wiki): Status of Nouveau drivers
- * [[http://www.x.org/wiki/GalliumStatus|GalliumStatus]] (X.org wiki): Status of Gallium3D Pipes and State Trackers
-
- * FeatureMatrix (outdated): Detailed summary of DRI driver features for a card and all supported cards
-  * ~-[[http://dri.sourceforge.net/doc/dri_driver_features.phtml|even more outdated, static version]]-~
- * [[http://pclinks.xtreemhost.com/video.htm|Listing of 3D chips and their capabilities]]
-
-== Independent Hardware Vendors ==
-
-<<FullSearch('CategoryHardwareVendor')>>
-
-== Chipsets ==
-
-<<FullSearch('CategoryHardwareChipset')>>
-
-== Operating Systems ==
-
-<<FullSearch('CategoryOperatingSystem')>>
diff --git a/StereoSupport.mdwn b/StereoSupport.mdwn
new file mode 100644
index 0000000..ce105e6
--- /dev/null
+++ b/StereoSupport.mdwn
@@ -0,0 +1,11 @@
+
+
+## Stereoscopic 3D support
+
+See [[AndreasEhliar|AndreasEhliar]]'s page on the subject: [[http://www.lysator.liu.se/~ehliar/3d/|http://www.lysator.liu.se/~ehliar/3d/]] . 
+
+Implementation of Quad-Buffer Stereo for radeon and r200. 
+
+Latest post: 20041019 -- [[http://marc.theaimsgroup.com/?l=mesa3d-dev&m=109817901921774|http://marc.theaimsgroup.com/?l=mesa3d-dev&m=109817901921774]] 
+
+Older posts: [[http://sourceforge.net/mailarchive/forum.php?thread_id=4834128&forum_id=5154|http://sourceforge.net/mailarchive/forum.php?thread_id=4834128&forum_id=5154]] or [[http://marc.theaimsgroup.com/?l=mesa3d-dev&m=108610583529027|http://marc.theaimsgroup.com/?l=mesa3d-dev&m=108610583529027]] 
diff --git a/StereoSupport.moin b/StereoSupport.moin
deleted file mode 100644
index 6b8a296..0000000
--- a/StereoSupport.moin
+++ /dev/null
@@ -1,13 +0,0 @@
-== Stereoscopic 3D support ==
-
-See AndreasEhliar's page on the subject: http://www.lysator.liu.se/~ehliar/3d/ .
-
-
-
-Implementation of Quad-Buffer Stereo for radeon and r200.
-
-Latest post: 20041019 -- http://marc.theaimsgroup.com/?l=mesa3d-dev&m=109817901921774
-
-Older posts:
-http://sourceforge.net/mailarchive/forum.php?thread_id=4834128&forum_id=5154
-or http://marc.theaimsgroup.com/?l=mesa3d-dev&m=108610583529027
diff --git a/SummerOfCode.mdwn b/SummerOfCode.mdwn
new file mode 100644
index 0000000..8c4243e
--- /dev/null
+++ b/SummerOfCode.mdwn
@@ -0,0 +1,22 @@
+
+The DRI project is looking to take part in the Google [[Summer of Code 2005|http://code.google.com/summerofcode.html]].  This project endeavors to fund students to contribute to an open-source project over summer break.  There are many interesting projects to be done in the DRI, and a fun group of developers to work with.  Below are some example ideas, but we are open to other projects, too! 
+
+**Update:** We were not accepted as a mentoring organization.  However, Bart Massey at Portland State University (one of the mentoring orgs) is knowledgable in X and suggested that he would gladly be an official mentor for students interested in doing DRI or X projects for SoC. 
+
+
+## Example project ideas
+
+* Fix the SiS 6326 driver texturing support and integrate into head CVS.  This would involve updating older code to current Mesa, debugging texturing, and CVS integration. 
+* Port the utah-glx NVIDIA driver to the DRI.  This would involve creating a DRM, determining how integration with the updated 2D driver would work, and porting the driver itself. 
+* Integrate the partially-completed S3 Virge driver. 
+* Integrate the partially-completed Trident driver. 
+* Rewrite the 3dfx driver to not depend on Glide and support SLI. 
+* Create a modern Gamma GMX DRI driver based on the currently-defunct one. 
+* Write a [[SiliconMotion|SiliconMotion]] DRI driver. 
+* Extend [[glean|http://glean.sf.net/]] to cover new extensions and more core functionality. 
+* Dynamic code generation for fragment/pixel shaders. 
+
+## Mentors
+
+* [[EricAnholt|EricAnholt]] (DRM, client drivers) 
+* [[AdamJackson|AdamJackson]] (server bits, client drivers) 
+\ No newline at end of file
diff --git a/SummerOfCode.moin b/SummerOfCode.moin
deleted file mode 100644
index c00eebd..0000000
--- a/SummerOfCode.moin
+++ /dev/null
@@ -1,18 +0,0 @@
-The DRI project is looking to take part in the Google [[http://code.google.com/summerofcode.html|Summer of Code 2005]].  This project endeavors to fund students to contribute to an open-source project over summer break.  There are many interesting projects to be done in the DRI, and a fun group of developers to work with.  Below are some example ideas, but we are open to other projects, too!
-
-'''Update:''' We were not accepted as a mentoring organization.  However, Bart Massey at Portland State University (one of the mentoring orgs) is knowledgable in X and suggested that he would gladly be an official mentor for students interested in doing DRI or X projects for SoC.
-
-== Example project ideas ==
- * Fix the SiS 6326 driver texturing support and integrate into head CVS.  This would involve updating older code to current Mesa, debugging texturing, and CVS integration.
- * Port the utah-glx NVIDIA driver to the DRI.  This would involve creating a DRM, determining how integration with the updated 2D driver would work, and porting the driver itself.
- * Integrate the partially-completed S3 Virge driver.
- * Integrate the partially-completed Trident driver.
- * Rewrite the 3dfx driver to not depend on Glide and support SLI.
- * Create a modern Gamma GMX DRI driver based on the currently-defunct one.
- * Write a SiliconMotion DRI driver.
- * Extend [[http://glean.sf.net/|glean]] to cover new extensions and more core functionality.
- * Dynamic code generation for fragment/pixel shaders.
-
-== Mentors ==
- * EricAnholt (DRM, client drivers)
- * AdamJackson (server bits, client drivers)
diff --git a/SunFFB.mdwn b/SunFFB.mdwn
new file mode 100644
index 0000000..9a55f0a
--- /dev/null
+++ b/SunFFB.mdwn
@@ -0,0 +1,22 @@
+
+
+# Sun Creator3D
+
+**Chipsets** [[!map pages="^Vendor.+"]] 
+
+
+## Status
+
+The Creator3D and Elite3D are sort of supported.  The driver reportedly has serious issues.  Help is always appreciated. 
+
+
+## Specifications
+
+
+## Resources
+
+
+
+---
+
+ [[CategoryHardwareVendor|CategoryHardwareVendor]] 
diff --git a/SunFFB.moin b/SunFFB.moin
deleted file mode 100644
index 134d196..0000000
--- a/SunFFB.moin
+++ /dev/null
@@ -1,15 +0,0 @@
-= Sun Creator3D =
-
-'''Chipsets'''
-<<PageList(^Vendor.+)>>
-
-== Status ==
-
-The Creator3D and Elite3D are sort of supported.  The driver reportedly has serious issues.  Help is always appreciated.
-
-== Specifications ==
-
-== Resources ==
-
-----
-CategoryHardwareVendor
diff --git a/Sven-Hendrik_Haase.mdwn b/Sven-Hendrik_Haase.mdwn
new file mode 100644
index 0000000..3624e4b
--- /dev/null
+++ b/Sven-Hendrik_Haase.mdwn
@@ -0,0 +1,47 @@
+
+
+## Sven-Hendrik Haase
+Email
+: 
+[[sh@lutzhaase.com|mailto:sh@lutzhaase.com]] 
+
+
+Homepage
+: customalized.org 
+
+Docs
+: 
+
+
+1. [[http://www.x.org/docs/AMD/|http://www.x.org/docs/AMD/]] 
+1. [[http://developer.amd.com/documentation/guides/Pages/default.aspx#open_gpu|http://developer.amd.com/documentation/guides/Pages/default.aspx#open_gpu]] Learning
+: 
+
+
+1. [[http://dri.freedesktop.org/wiki/GettingStarted|http://dri.freedesktop.org/wiki/GettingStarted]] 
+1. [[http://wiki.x.org/wiki/Development|http://wiki.x.org/wiki/Development]] 
+1. [[http://dri.freedesktop.org/wiki/NormalUserBuild|http://dri.freedesktop.org/wiki/NormalUserBuild]] 
+1. [[http://dri.freedesktop.org/wiki/R300ToDo|http://dri.freedesktop.org/wiki/R300ToDo]] 
+1. [[http://wiki.x.org/wiki/RadeonFeature|http://wiki.x.org/wiki/RadeonFeature]] 
+1. [[http://dri.freedesktop.org/wiki/MailingLists|http://dri.freedesktop.org/wiki/MailingLists]] 
+1. [[https://bugs.freedesktop.org/|https://bugs.freedesktop.org/]] 
+1. [[http://dri.freedesktop.org/wiki/Radeon|http://dri.freedesktop.org/wiki/Radeon]] 
+1. [[http://people.freedesktop.org/~nh/piglit/|http://people.freedesktop.org/~nh/piglit/]] 
+1. [[https://github.com/apitrace/apitrace|https://github.com/apitrace/apitrace]] 
+1. [[http://dri.freedesktop.org/wiki/Profiling|http://dri.freedesktop.org/wiki/Profiling]] 
+1. [[http://sysprof.com/|http://sysprof.com/]] 
+1. [[http://zrusin.blogspot.com/|http://zrusin.blogspot.com/]] 
+1. [[http://airlied.livejournal.com/|http://airlied.livejournal.com/]] 
+1. [[http://www.mesa3d.org/install.html|http://www.mesa3d.org/install.html]] 
+1. [[http://www.mesa3d.org/envvars.html|http://www.mesa3d.org/envvars.html]] Git trees
+: 
+
+
+1. [[http://cgit.freedesktop.org/mesa/mesa/?h=master|http://cgit.freedesktop.org/mesa/mesa/?h=master]] 
+1. [[http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/gpu/drm;hb=HEAD|http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/gpu/drm;hb=HEAD]] 
+1. [[http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/|http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/]] 
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/Sven-Hendrik_Haase.moin b/Sven-Hendrik_Haase.moin
deleted file mode 100644
index 15a4b26..0000000
--- a/Sven-Hendrik_Haase.moin
+++ /dev/null
@@ -1,35 +0,0 @@
-== Sven-Hendrik Haase ==
-
- Email:: sh@lutzhaase.com
-
- Homepage:: customalized.org
-
- Docs::
- *http://www.x.org/docs/AMD/
- *http://developer.amd.com/documentation/guides/Pages/default.aspx#open_gpu
-
- Learning::
- *http://dri.freedesktop.org/wiki/GettingStarted
- *http://wiki.x.org/wiki/Development
- *http://dri.freedesktop.org/wiki/NormalUserBuild
- *http://dri.freedesktop.org/wiki/R300ToDo
- *http://wiki.x.org/wiki/RadeonFeature
- *http://dri.freedesktop.org/wiki/MailingLists
- *https://bugs.freedesktop.org/
- *http://dri.freedesktop.org/wiki/Radeon
- *http://people.freedesktop.org/~nh/piglit/
- *https://github.com/apitrace/apitrace
- *http://dri.freedesktop.org/wiki/Profiling
- *http://sysprof.com/
- *http://zrusin.blogspot.com/
- *http://airlied.livejournal.com/
- *http://www.mesa3d.org/install.html
- *http://www.mesa3d.org/envvars.html
-
- Git trees::
- *http://cgit.freedesktop.org/mesa/mesa/?h=master
- *http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/gpu/drm;hb=HEAD
- *http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/
-
-----
-CategoryHomepage
diff --git a/TCL.mdwn b/TCL.mdwn
new file mode 100644
index 0000000..d6b68e0
--- /dev/null
+++ b/TCL.mdwn
@@ -0,0 +1,18 @@
+
+
+## Transform, Clipping and Lighting (TCL)
+
+TCL is a common name for three operations: 
+
+* transformation (moving and rotating objects in a scene) 
+* clipping (removing non-visible objects) 
+* lighting (applying light effects on objects) 
+Most modern graphics cards are able to perform TCL internally with the card's chip - this allows greater speed in all applications, the main system processor(s) doesn't have to do additional work with graphics. 
+
+TCL allows far more complex scenes to be calculated in very short time. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/TCL.moin b/TCL.moin
deleted file mode 100644
index 8b07508..0000000
--- a/TCL.moin
+++ /dev/null
@@ -1,14 +0,0 @@
-== Transform, Clipping and Lighting (TCL) ==
-
-TCL is a common name for three operations:
-
- * transformation (moving and rotating objects in a scene)
- * clipping (removing non-visible objects)
- * lighting (applying light effects on objects)
-
-Most modern graphics cards are able to perform TCL internally with the card's chip - this allows greater speed in all applications, the main system processor(s) doesn't have to do additional work with graphics.
-
-TCL allows far more complex scenes to be calculated in very short time.
-
-----
-CategoryGlossary
diff --git a/TG.mdwn b/TG.mdwn
new file mode 100644
index 0000000..c85ea09
--- /dev/null
+++ b/TG.mdwn
@@ -0,0 +1,7 @@
+
+
+# Tungsten Graphics Inc. (TG)
+
+Tungsten Graphics Inc. (TG) is a graphics software consulting company that develops state of the art graphics and open infrastructure solutions running on Linux, FreeBSD, and other operating systems. TG was founded by [[BrianPaul|BrianPaul]] (owner and principal author of Mesa), [[FrankLaMonica|FrankLaMonica]] (former CEO of Precision Insight), [[JensOwen|JensOwen]] (founding partner and former engineering manager of Precision Insight), and [[KeithWhitwell|KeithWhitwell]] (senior engineer and major contributor to Mesa.) 
+
+TG is an active participant in many graphics initiatives, including XFree86, Mesa, DRI, Chromium, VNC, and Khronos' OpenGL ES project. 
diff --git a/TG.moin b/TG.moin
deleted file mode 100644
index 06c8aef..0000000
--- a/TG.moin
+++ /dev/null
@@ -1,12 +0,0 @@
-= Tungsten Graphics Inc. (TG) =
-
-Tungsten Graphics Inc. (TG) is a graphics software consulting company that
-develops state of the art graphics and open infrastructure solutions running on
-Linux, FreeBSD, and other operating systems. TG was founded by BrianPaul
-(owner and principal author of Mesa), FrankLaMonica (former CEO of Precision
-Insight), JensOwen (founding partner and former engineering manager of
-Precision Insight), and KeithWhitwell (senior engineer and major contributor
-to Mesa.)
-
-TG is an active participant in many graphics initiatives, including XFree86,
-Mesa, DRI, Chromium, VNC, and Khronos' OpenGL ES project.
diff --git a/TTMFencing.mdwn b/TTMFencing.mdwn
new file mode 100644
index 0000000..fec5fc6
--- /dev/null
+++ b/TTMFencing.mdwn
@@ -0,0 +1,68 @@
+
+
+# TTM Fencing
+
+More information can be found here: [[http://marc.theaimsgroup.com/?t=120407426000002&r=1&w=2|http://marc.theaimsgroup.com/?t=120407426000002&r=1&w=2]] 
+
+
+## Fence Flags
+
+fence_flags are to tweak the behavior of calls into the fence manager. 
+
+      * DRM_FENCE_FLAG_EMIT causes a fence to enter the command stream 
+            * instead of just being created. 
+      * DRM_FENCE_FLAG_SHAREABLE makes sure the fence object is shareable 
+            * between processes. 
+      * DRM_FENCE_FLAG_WAIT_LAZY hints that a polling wait should sleep 
+            * in-between polls. 
+      * DRM_FENCE_FLAG_IGNORE_SIGNALS ignore signals while waiting. 
+      * DRM_FENCE_FLAG_NO_USER don't return a user-space fence object on a 
+            * superioctl. Just have the fence live in the kernel. 
+
+## Fence Type
+
+fence_type is something completely different. It's there to expose GPU states, or how far the GPU has proceeded with the command sequence associated with the fence. This info is needed so that the buffer object code knows when a buffer object is idle. A TTM object (buffer, regiser, whatever) is considered idle if (object->fence_type & ((object->fence_type & object->fence->signaled_types) == object->fence_type). 
+
+Let's take i915 as a typical example. Batch buffers should be idle and can be reused as soon as the GPU command reader is done with the buffer. At that point fence->sigaled_types will contain DRM_BO_FENCE_TYPE_EXE. However, render targets and textures aren't idle until that has happend AND and MI_FLUSH has executed, at which point fence->signaled_types will also contain DRM_I915_FENCE_TYPE_RW. 
+
+In an ideal situation we would like to only issue an MI_FLUSH at the end of a full scene, however, we might need a huge number of batch buffers to build that scene, and we'd like to be able to reuse these as soon as they've delivered their contents. We don't want them hanging around useless until someone issues a MI_FLUSH at the end of the scene. 
+
+Other uses for fence_type are when different engines are fed through the same command submission mechanism. A typical example would be the Unichrome which has different ways to signal 2D done, 3D done, video blit done, mpeg done etc. All these engines  are fed through the same command submission mechanism. 
+
+This is contrary to the fence_class which is intended for separate command submission mechanisms and the TTM has ways to synchronize these on a per-buffer level. Typical usage would be hardware with completely separate 2D and 3D engines that operate in parallel with separate command FIFOs. 
+
+The callback has_irq should take fence_type and not fence_flags. I think this is just a bad naming of the parameter that has survived cleanups. 
+
+The callback "needed_flush" is there to tell the fence manager whether some kind of GPU flush is needed to signal any fence type in fence->waiting_types. In the intel example case above, If the DRM_I915_FENCE_TYPE_RW flag is set in fence->waiting_types, a flush would be needed, but only if there isn't already a flush pending that would make sure this flag signals. Also, since the flushes that are currently implemented on intel are asynchronous, a flush is not needed until the DRM_BO_FENCE_TYPE_EXE has signaled. Otherwise we would flush a previous command sequence instead of the intended one. 
+
+The callback "flush" should schedule a GPU flush for the fc->pending_flush types, and clear fc->pending_flush when the flush has been scheduled. 
+
+
+## Flush
+
+flush() only needs to start a flush, and poll() will report it when it's done, but note that on, for example intel, the flush mechanism currently implemented doesn't have an IRQ that reports when it's done. Hence the polling part of the intel fence wait. A better way of implementing this is to have flushes go through a high-priority ring, accompanied by a user irq. Not done yet. A third way is to just add an MI_FLUSH to the ring and keep track of its execution. The disadvantage of this is that the ring might be full of rendering commands that will take a lot of time to complete and we will drain the ring waiting for idle buffers. 
+
+Note also, that if poll() sees that fc->flush_pending is non-zero, it should also start a flush and clear fc->flush_pending. It can be set to non-zero in the drm fence handler. 
+
+So what happens is that the drm fence handler calls needed_flush() when it has signaled a fence_type on a fence.  If needed_flush() determines that further flushing is needed, it should then check  if there is a flush in the command  stream that would perform the required action, and if so return zero. A simple way to track flushes is to store the sequence number for the last flush. If that sequence number is higher than the current sequence number, no flush is needed, and needed_flush() would return zero. 
+
+So yes, you need to check fc->pending_flush during poll, and make sure needed_flush() is smart enough to check the ring for previous flushes that would do the job, so we don't issue any unnecessary flushes. 
+
+So over to the question, how does the poll() function tell that a flush has executed? One option is to have a separate list with all flushes in the ring, and a corresponding sequence number. Everytime we hit a new sequence number we check the list, and see if a flush has executed, and in that case call drm_fence_handler() with the correct fence_type. 
+
+One other option is to use fence->native_type. When TYPE_EXE signals on a fence with a non-zero native_type, it will also automatically signal fence->native_type on itself and all previous fences. There is a problem with this, however, and that is that such a fence might disappear when it's no longer referenced by a buffer and thus we will lose track of that flush. This can probably be fixed with refcounting tricks, but now it starts to get more and more complicated.  
+
+The Radeon driver is probably going to use a simpler and attractive approach: To encode flush presence in the fence sequence blit. Bit 31 will be reserved for this. 
+
+If you look in the intel_driver, native_type is used exactly in this way to track flushes that are programmed by user-space. Here, a driver-specific fence-flag is used to tell the intel fence driver that we have programmed an MI_FLUSH. However, if you look even more closely, the intel needed_flush() implementation ignores these user-space flushes, unless they occur on the current fence. This is to avoid the previously mentioned ring round-trip delay. So currently it's a bit stupid since even if a flush occurs on the next fence, it will go on initiating a sync_flush operation. 
+
+
+## Command stream barrier
+
+A related topic is the command stream barrier, which is used when the hardware cannot synchronize by itself, and needs software assistance. Such a typical case is hardware with multiple command streams. Assume that you want to render to a buffer using the 3D engine and blit from it using the 2D engine, but then engines have no way to synchronize, and are fed with two different command streams. When the ttm detects, during the buffer validation, that you want to change command stream (which is the fence_class), it will, by default, idle the buffer. However, it might be that the 2D engine has a command to wait for a 3D event. In that case you'd want to add that command to the 2D stream, and make it want to wait for the 3D engine to finish rendering to the buffer in question. In that case you should impelement this in the command_stream_barrier callback. Note that the default behaviour is always to idle the buffer, which should be safe during all circumstances.  
+
+Another use case is flushing when changing access mode. Intel, for example, needs a flush when changing from 3D GPU write to 2D GPU read, but still it's using the same command  stream. The way to implement this is to have one fence_type for READ an one for WRITE.  When, during buffer validate, you want to change bo->fence_type from WRITE to READ, the  TTM sync mechanism will detect that you are dropping a fence_type on the buffer and either idle the buffer (which will automatically flush it), or call command_stream_barrier if it's implemented. Now, command_stream_barrier() will simply issue a write_flush to the command stream and return, and the WRITE flag in bo->fence_type will be dropped when the buffer is fenced with the new fence. Of course, command_stream_barrier should first check to make sure there isn't already a flush in the command stream that would do the job. 
+
+Now what happens if we issue such a barrier (flush) and then hit an error. Let's say an  EAGAIN which is common during X server operation. Then it's extremely  important that we don't drop the WRITE type flag on the buffer, because then it might seem to be idle before the flush (barrier) has actually executed. This case is taken care of by the fact that he type flag will not be dropped until the buffer is fenced with the new fence. If an error occurs, the buffer will retain its old type flags and old fence. 
+
+In that case one might think that we will lose track of the flush and a new attempt to issue the command sequence will issue a new (unnecessary) barrier flush. That's not the case, because  command_stream_barrier will check the command stream for old flushes. 
diff --git a/TTMFencing.moin b/TTMFencing.moin
deleted file mode 100644
index 68f8e6c..0000000
--- a/TTMFencing.moin
+++ /dev/null
@@ -1,167 +0,0 @@
-= TTM Fencing =
-
-More information can be found here: http://marc.theaimsgroup.com/?t=120407426000002&r=1&w=2
-
-
-== Fence Flags ==
-
-fence_flags are to tweak the behavior of calls into the fence manager.
-
-   * DRM_FENCE_FLAG_EMIT causes a fence to enter the command stream
-     instead of just being created.
-   * DRM_FENCE_FLAG_SHAREABLE makes sure the fence object is shareable
-     between processes.
-   * DRM_FENCE_FLAG_WAIT_LAZY hints that a polling wait should sleep
-     in-between polls.
-   * DRM_FENCE_FLAG_IGNORE_SIGNALS ignore signals while waiting.
-   * DRM_FENCE_FLAG_NO_USER don't return a user-space fence object on a
-     superioctl. Just have the fence live in the kernel.
-
-== Fence Type ==
-
-fence_type is something completely different. It's there to expose GPU
-states, or how far the GPU has proceeded with the command sequence
-associated with the fence. This info is needed so that the buffer object
-code knows when a buffer object is idle. A TTM object (buffer, regiser,
-whatever) is considered idle if (object->fence_type &
-((object->fence_type & object->fence->signaled_types) == object->fence_type).
-
-Let's take i915 as a typical example. Batch buffers should be idle and
-can be reused as soon as the GPU command reader is done with the buffer.
-At that point fence->sigaled_types will contain DRM_BO_FENCE_TYPE_EXE.
-However, render targets and textures aren't idle until that has happend
-AND and MI_FLUSH has executed, at which point fence->signaled_types will
-also contain DRM_I915_FENCE_TYPE_RW.
-
-In an ideal situation we would like to only issue an MI_FLUSH at the end
-of a full scene, however, we might need a huge number of batch buffers
-to build that scene, and we'd like to be able to reuse these as soon as
-they've delivered their contents. We don't want them hanging around
-useless until someone issues a MI_FLUSH at the end of the scene.
-
-Other uses for fence_type are when different engines are fed through the
-same command submission mechanism. A typical example would be the
-Unichrome which has different ways to signal 2D done, 3D done, video
-blit done, mpeg done etc. All these engines  are fed through the same
-command submission mechanism.
-
-This is contrary to the fence_class which is intended for separate
-command submission mechanisms and the TTM has ways to synchronize these
-on a per-buffer level. Typical usage would be hardware with completely
-separate 2D and 3D engines that operate in parallel with separate
-command FIFOs.
-
-The callback has_irq should take fence_type and not fence_flags. I think this is just a bad naming of the parameter that has
-survived cleanups.
-
-The callback "needed_flush" is there to tell the fence manager whether
-some kind of GPU flush is needed to signal any fence type in
-fence->waiting_types.
-In the intel example case above, If the DRM_I915_FENCE_TYPE_RW flag is
-set in fence->waiting_types, a flush would be needed, but only if there
-isn't already a flush pending that would make sure this flag signals.
-Also, since the flushes that are currently implemented on intel are
-asynchronous, a flush is not needed until the DRM_BO_FENCE_TYPE_EXE has
-signaled. Otherwise we would flush a previous command sequence instead
-of the intended one.
-
-The callback "flush" should schedule a GPU flush for the
-fc->pending_flush types, and clear fc->pending_flush when the flush has
-been scheduled.
-
-== Flush ==
-
-flush() only needs to start a flush, and poll() will report it when it's
-done, but note that on, for example intel, the flush mechanism currently
-implemented doesn't have an IRQ that reports when it's done. Hence the
-polling part of the intel fence wait. A better way of implementing this
-is to have flushes go through a high-priority ring, accompanied by a
-user irq. Not done yet.
-A third way is to just add an MI_FLUSH to the ring and keep track of its
-execution. The disadvantage of this is that the ring might be full of
-rendering commands that will take a lot of time to complete and we will
-drain the ring waiting for idle buffers.
-
-Note also, that if poll() sees that fc->flush_pending is non-zero, it
-should also start a flush and clear fc->flush_pending. It can be set to
-non-zero in the drm fence handler.
-
-So what happens is that the drm fence handler calls needed_flush() when
-it has signaled a fence_type on a fence.  If needed_flush() determines
-that further flushing is needed, it should then check  if there is a
-flush in the command  stream that would perform the required action, and
-if so return zero. A simple way to track flushes is to store the
-sequence number for the last flush.
-If that sequence number is higher than the current sequence number, no
-flush is needed, and needed_flush() would return zero.
-
-So yes, you need to check fc->pending_flush during poll, and make sure
-needed_flush() is smart enough to check the ring for previous flushes
-that would do the job, so we don't issue any unnecessary flushes.
-
-So over to the question, how does the poll() function tell that a flush
-has executed?
-One option is to have a separate list with all flushes in the ring, and
-a corresponding sequence number. Everytime we hit a new sequence number
-we check the list, and see if a flush has executed, and in that case
-call drm_fence_handler() with the correct fence_type.
-
-One other option is to use fence->native_type. When TYPE_EXE signals on
-a fence with a non-zero native_type, it will also automatically signal
-fence->native_type on itself and all previous fences. There is a problem
-with this, however, and that is that such a fence might disappear when
-it's no longer referenced by a buffer and thus we will lose track of
-that flush. This can probably be fixed with refcounting tricks, but now
-it starts to get more and more complicated. 
-
-The Radeon driver is probably going to use a simpler and attractive
-approach: To encode flush presence in the fence sequence blit. Bit 31
-will be reserved for this.
-
-If you look in the
-intel_driver, native_type is used exactly in this way to track flushes
-that are programmed by user-space. Here, a driver-specific fence-flag is
-used to tell the intel fence driver that we have programmed an MI_FLUSH.
-However, if you look even more closely, the intel needed_flush()
-implementation ignores these user-space flushes, unless they occur on
-the current fence. This is to avoid the previously mentioned ring
-round-trip delay.
-So currently it's a bit stupid since even if a flush occurs on the next
-fence, it will go on initiating a sync_flush operation.
-
-== Command stream barrier ==
-
-A related topic is the command stream barrier, which is used when the hardware
-cannot synchronize by itself, and needs software assistance.
-Such a typical case is hardware with multiple command streams. Assume that you want
-to render to a buffer using the 3D engine and blit from it using the 2D engine, but
-then engines have no way to synchronize, and are fed with two different command
-streams. When the ttm detects, during the buffer validation, that you want to change
-command stream (which is the fence_class), it will, by default, idle the buffer.
-However, it might be that the 2D engine has a command to wait for a 3D event. In that
-case you'd want to add that command to the 2D stream, and make it want to wait for
-the 3D engine to finish rendering to the buffer in question. In that case you should
-impelement this in the command_stream_barrier callback. Note that the default behaviour
-is always to idle the buffer, which should be safe during all circumstances. 
-
-Another use case is flushing when changing access mode. Intel, for example, needs a flush
-when changing from 3D GPU write to 2D GPU read, but still it's using the same command 
-stream. The way to implement this is to have one fence_type for READ an one for WRITE. 
-When, during buffer validate, you want to change bo->fence_type from WRITE to READ, the 
-TTM sync mechanism will detect that you are dropping a fence_type on the buffer and either
-idle the buffer (which will automatically flush it), or call command_stream_barrier if it's
-implemented. Now, command_stream_barrier() will simply issue a write_flush to the command
-stream and return, and the WRITE flag in bo->fence_type will be dropped when the buffer is
-fenced with the new fence. Of course, command_stream_barrier should first check to make
-sure there isn't already a flush in the command stream that would do the job.
-
-Now what happens if we issue such a barrier (flush) and then hit an error. Let's say an 
-EAGAIN which is common during X server operation. Then it's extremely 
-important that we don't drop the WRITE type flag on the buffer, because then it might seem to be idle
-before the flush (barrier) has actually executed. This case is taken care of by the fact that he
-type flag will not be dropped until the buffer is fenced with the new fence. If an error occurs, the
-buffer will retain its old type flags and old fence.
-
-In that case one might think that we will lose track of the flush and a new attempt to issue the
-command sequence will issue a new (unnecessary) barrier flush. That's not the case, because 
-command_stream_barrier will check the command stream for old flushes.
diff --git a/TestingAndDebugging.mdwn b/TestingAndDebugging.mdwn
new file mode 100644
index 0000000..ff663fa
--- /dev/null
+++ b/TestingAndDebugging.mdwn
@@ -0,0 +1,134 @@
+
+
+# Testing And Debugging
+
+
+## How do you put a breakpoint in the dynamically loaded modules?
+
+You need [[xfree86-gdb|http://www.dawa.demon.co.uk/xfree-gdb/]] -- a version of gdb modified to understand the module binary format that XFree86 uses in addition to the standard elf/coff binary formats. 
+
+Type: 
+
+      * [[!format txt """
+module mach64_drv.o mach64_dri.o
+"""]]
+after starting the debugger to load symbols, etc. 
+
+
+## How do I do benchmarking with Unreal Tournament?
+
+Start a practice level. Type `timedemo 1` in the console or in alternative select the _Tools > Time``Demo Statistic_ menu entry. 
+
+You should see two numbers in white text on the right side of the screen showing the average framerate (_Avg_) and the number of frame rates in the last second (_Last Sec_). If this doesn't work check whether the stats get reported in your `~/.loki/ut/System/UnrealTournament.log` file. 
+
+
+## Is there any way for us to detect which features are implemented with hardware support for a given driver?
+
+OpenGL doesn't have such a query. This is a potential problem with any OpenGL implementation. The real question one wants answered is "is this feature or GL state combination fast enough for my needs?". Whether a feature is implemented in hardware or software isn't always consistent with that question. 
+
+You might consider implementing a benchmark function to test the speed during start-up and making a decision depending on the result. The info could be cached in a file keyed by `GL_RENDERER`. 
+
+Check [[isfast|http://www.berkelium.com/OpenGL/isfast.html]] 
+
+
+## Which OpenGL benchmarking program can I use to test and compare various facets of the performance of graphics cards?
+
+   * Games. You can use OpenGL games such as Quake 3, Unreal Tournament, etc. 
+   * [[SPECviewperf|http://www.specbench.org/gpc/opc.static/opcview.htm]] is a portable OpenGL performance benchmark program written in C providing a vast amount of flexibility in benchmarking OpenGL performance. 
+   * [[SPECglperf|http://www.specbench.org/gpc/opc.static/glperf.htm]] is an executable toolkit that measures the performance of OpenGL 2D and 3D graphics operations. These operations are low-level primitives (points, lines, triangles, pixels, etc.) rather than entire models. 
+   * [[piglit|http://piglit.freedesktop.org]] is a suite of tools for evaluating the quality of an OpenGL implementation and diagnosing any problems that are discovered. It also has the ability to compare two OpenGL implementations and highlight the differences between them. 
+   * [[machtest|http://wwwvis.informatik.uni-stuttgart.de/machtest/intro.html]] is a thorough benchmark for graphics cards. It has literally thousands of command line options, is easily extensible and it can produce machine readable output. 
+   * [[Mesa demos|http://cgit.freedesktop.org/mesa/demos/]]. 
+   * [[Nate Robins' OpenGL Tutors|http://www.xmission.com/~nate/tutors.html]] are a set of tutorial programs that demonstrate basic OpenGL functionality by allowing the user to modify the parameters of a function and see the effect on the scene. 
+   * [[Frustum|http://frustum.org/3d/]] has some demos to some >= 1.2 GL extensions, including shaders 
+   * [[Humus|http://www.humus.ca/index.php?page=3D]] also has some demos to GL extensions, including shaders and ATI specific extensions 
+   * [[GPU Shader Demo Programs|http://cs.anu.edu.au/people/Hugh.Fisher/shaders/]] using nVidia (NV) and/or ARB shader extensions, featured at opengl.org. 
+
+## What environment variables affect libGL behavior?
+[[!table header="no" class="mointable" data="""
+ `LIBGL_DEBUG`  |  If defined debug information will be printed to _stderr_. If set to `verbose` additional information will be printed. 
+ `LIBGL_DRIVERS_PATH`  |   Path were to search for 3D DRI drivers. 
+ `LIBGL_MULTIHEAD`  |   Define to specify the presence of more than one display. 
+ `LIBGL_ALWAYS_INDIRECT`  |   Assures that no direct rendering will take place. See also here. 
+ `LIBGL_DRI_AUTOFULLSCREEN`  |   If set to `enable`, `1`, `on`, `true`, `t`, `yes` or `y` the driver it will check for the potential to enter an automatic full-screen mode. 
+ `LIBGL_SOFTWARE_RENDERING`  |   If set it will force software rendering. 
+ `LIBGL_NO_MULTITEXTURE`  |   If set it will disable the GL_ARB_multitexture extension. 
+ `LIBGL_PERFORMANCE_BOXES`  |   If set the r128 driver, when built with `ENABLE_PERF_BOXES` will draw performance boxes. 
+ `LIBGL_THROTTLE_REFRESH`  |   Throttle the framerate to the refresh rate on radeon, r200, and possibly other drivers. 
+"""]]
+
+* (!) Due to their specificity and volatility is not worth to have all driver specific environment variables here. An interesting way to list them is to do: 
+      * [[!format txt """
+strings /usr/X11R6/lib/modules/dri/<driver>_dri.so | grep DEBUG
+"""]]
+
+## How should I report bugs?
+
+Please submit bugs to [[BugZilla|BugZilla]].  It's best if you can create a small example that shows what you think is the problem. 
+
+For those who really want to be Open Source heroes -- you can create a test for the bug under [[piglit|http://piglit.freedesktop.org]]. The intention would be to run piglit quite often, so any functionality you can verify there, is much less likely to reappear in a broken form at some random time in the future. 
+
+
+## Capturing debugging info without networking
+
+Here is a sort of simple shell script that I just thought of that might make people's lives a little easier.  Cut & paste this into a file (maybe `/usr/local/bin/dri_debug.sh`) and then add this line to your equivalent of `/etc/rc.local`: 
+
+   * [[!format txt """
+/bin/sh /usr/local/bin/dri_debug.sh
+"""]]
+to have it run at boot time to save info from the last crash. Otherwise, just run it any old time to get a snapshot of log data. 
+
+If there's interest, I'll put together a nice rc script that should work on most distros for distribution with the testing binaries.  This is just a "mock up" (I haven't even run it - I hate dog food ;) of what should be a bit more complicated and grab a few more things, but you get the idea. 
+
+   * [[!format txt """
+DRI_DEBUG_DIR=/var/tmp/dri_debug_`date +%d-%b-%Y-%T`
+mkdir $DRI_DEBUG_DIR
+cp /var/log/XFree86.0.log $DRI_DEBUG_DIR
+# this should work, but a grep might be better ...
+tail -5000 /var/log/messages >$DRI_DEBUG_DIR/syslog.log
+cp /etc/X11/XF86Config* $DRI_DEBUG_DIR
+ls -l /usr/lib/libGL* >>$DRI_DEBUG_DIR/usr_GLFiles.txt
+ls -l /usr/X11R6/lib  >>$DRI_DEBUG_DIR/X11R6_libFiles.txt
+ldd /usr/X11R6/bin/glxgears >>$DRI_DEBUG_DIR/ldd_glxgears.txt
+                                                                                            
+# any other files ...
+                                                                                            
+tar -czf $DRI_DEBUG_DIR.tar.gz $DRI_DEBUG_DIR
+#rm -rf $DRI_DEBUG_DIR
+"""]]
+It might be nice to patch xinitrc to do this: 
+
+   * [[!format txt """
+glxinfo >>/var/tmp/glxinfo.txt
+"""]]
+every time so it can be bundled up, too. 
+
+Then when people start having problems, the list can expect (somewhat) consistent reports.  Lemme know what you think. 
+
+I take no responsibility for the meltdown of your system ;)  
+
+   * -- [[AlTobey|AlTobey]]                                                                                             
+
+## How to get a backtrace on the core dump?
+
+   1. If core dumps aren't turned on in your shell, turn them on. For tcsh it's a command like ```limit coredumpsize 200000``` For bash it is ```ulimit -c unlimited```.  See the man page. Start the server ```startx``` from the same shell. 
+   1. When the server crashes and you get a core file, run gdb on it. The core file might be in ```/etc/X11``` if it's not in the current directory.                                                                                                                                                         
+         * [[!format txt """
+gdb -c core /usr/X11R6/bin/XFree86
+"""]]                                                                                                                                                     
+   1. From the gdb prompt type ```bt``` to get a backtrace.  Hopefully you have symbols and it will give us an idea where it actually segfaulted. -- [[MarkVojkovich|MarkVojkovich]] 
+[[http://dri.sourceforge.net/cgi-bin/moin.cgi/RecentChanges|http://dri.sourceforge.net/cgi-bin/moin.cgi/RecentChanges]] 
+
+
+## How to dump video bios ?
+
+Find the pci device associated to your gpu with lspci. If lspci report: 
+[[!format txt """
+01:05.0 VGA compatible controller: ATI Technologies Inc RS880 [Radeon HD 4200]
+"""]]
+Then 
+[[!format txt """
+cd /sys/bus/pci/devices/0000:01:05.0
+sudo sh -c "echo 1 > rom"
+sudo sh -c "cat rom > ~/bios.rom"
+"""]]
+\ No newline at end of file
diff --git a/TestingAndDebugging.moin b/TestingAndDebugging.moin
deleted file mode 100644
index b52d16b..0000000
--- a/TestingAndDebugging.moin
+++ /dev/null
@@ -1,168 +0,0 @@
-= Testing And Debugging =
-
-== How do you put a breakpoint in the dynamically loaded modules? ==
-
-You need [[http://www.dawa.demon.co.uk/xfree-gdb/|xfree86-gdb]] -- a version of
-gdb modified to understand the module binary format that XFree86 uses in
-addition to the standard elf/coff binary formats.
-
-Type:
-
-   {{{
-module mach64_drv.o mach64_dri.o
-}}}
-
-after starting the debugger to load symbols, etc.
-
-== How do I do benchmarking with Unreal Tournament? ==
-
-Start a practice level. Type {{{timedemo 1}}} in the console or in alternative
-select the ''Tools > Time``Demo Statistic'' menu entry.
-
-You should see two numbers in white text on the right side of the screen
-showing the average framerate (''Avg'') and the number of frame rates in the last
-second (''Last Sec''). If this doesn't work check whether the stats get reported in
-your `~/.loki/ut/System/UnrealTournament.log` file.
-
-== Is there any way for us to detect which features are implemented with hardware support for a given driver? ==
-
-OpenGL doesn't have such a query. This is a potential problem with any OpenGL
-implementation. The real question one wants answered is "is this feature or GL
-state combination fast enough for my needs?". Whether a feature is implemented
-in hardware or software isn't always consistent with that question.
-
-You might consider implementing a benchmark function to test the speed during
-start-up and making a decision depending on the result. The info could be
-cached in a file keyed by `GL_RENDERER`.
-
-Check [[http://www.berkelium.com/OpenGL/isfast.html|isfast]]
-
-== Which OpenGL benchmarking program can I use to test and compare various facets of the performance of graphics cards? ==
-
-  * Games. You can use OpenGL games such as Quake 3, Unreal Tournament, etc.
-
-  * [[http://www.specbench.org/gpc/opc.static/opcview.htm|SPECviewperf]] is a portable OpenGL performance benchmark program written in C providing a vast amount of flexibility in benchmarking OpenGL performance.
-
-  * [[http://www.specbench.org/gpc/opc.static/glperf.htm|SPECglperf]] is an executable toolkit that measures the performance of OpenGL 2D and 3D graphics operations. These operations are low-level primitives (points, lines, triangles, pixels, etc.) rather than entire models.
-
-  * [[http://piglit.freedesktop.org|piglit]] is a suite of tools for evaluating the quality of an OpenGL implementation and diagnosing any problems that are discovered. It also has the ability to compare two OpenGL implementations and highlight the differences between them.
-
-  * [[http://wwwvis.informatik.uni-stuttgart.de/machtest/intro.html|machtest]] is a thorough benchmark for graphics cards. It has literally thousands of command line options, is easily extensible and it can produce machine readable output.
-
-  * [[http://cgit.freedesktop.org/mesa/demos/|Mesa demos]].
-
-  * [[http://www.xmission.com/~nate/tutors.html|Nate Robins' OpenGL Tutors]] are a set of tutorial programs that demonstrate basic OpenGL functionality by allowing the user to modify the parameters of a function and see the effect on the scene.
-
-  * [[http://frustum.org/3d/|Frustum]] has some demos to some >= 1.2 GL extensions, including shaders
-  * [[http://www.humus.ca/index.php?page=3D|Humus]] also has some demos to GL extensions, including shaders and ATI specific extensions
-  * [[http://cs.anu.edu.au/people/Hugh.Fisher/shaders/|GPU Shader Demo Programs]] using nVidia (NV) and/or ARB shader extensions, featured at opengl.org.
-
-== What environment variables affect libGL behavior? ==
-
-|| `LIBGL_DEBUG` || If defined debug information will be printed to ''stderr''. If set to `verbose` additional information will be printed. ||
-|| `LIBGL_DRIVERS_PATH` ||  Path were to search for 3D DRI drivers. ||
-|| `LIBGL_MULTIHEAD` ||  Define to specify the presence of more than one display. ||
-|| `LIBGL_ALWAYS_INDIRECT` ||  Assures that no direct rendering will take place. See also here. ||
-|| `LIBGL_DRI_AUTOFULLSCREEN` ||  If set to `enable`, `1`, `on`, `true`, `t`, `yes` or `y` the driver it will check for the potential to enter an automatic full-screen mode. ||
-|| `LIBGL_SOFTWARE_RENDERING` ||  If set it will force software rendering. ||
-|| `LIBGL_NO_MULTITEXTURE` ||  If set it will disable the GL_ARB_multitexture extension. ||
-|| `LIBGL_PERFORMANCE_BOXES` ||  If set the r128 driver, when built with `ENABLE_PERF_BOXES` will draw performance boxes. ||
-|| `LIBGL_THROTTLE_REFRESH` ||  Throttle the framerate to the refresh rate on radeon, r200, and possibly other drivers. ||
-
- (!) Due to their specificity and volatility is not worth to have all driver specific environment variables here. An interesting way to list them is to do:
-
-   {{{
-strings /usr/X11R6/lib/modules/dri/<driver>_dri.so | grep DEBUG
-}}}
-
-== How should I report bugs? ==
-
-Please submit bugs to BugZilla.  It's best if you can create a small example that shows what you think is the
-problem.
-
-For those who really want to be Open Source heroes -- you can create a test for
-the bug under [[http://piglit.freedesktop.org|piglit]]. The intention would be to
-run piglit quite often, so any functionality you can verify there, is much less
-likely to reappear in a broken form at some random time in the future.
-
-== Capturing debugging info without networking ==
-
-Here is a sort of simple shell script that I just thought of that might
-make people's lives a little easier.  Cut & paste this into a file
-(maybe `/usr/local/bin/dri_debug.sh`) and then add this line to your
-equivalent of `/etc/rc.local`:
-
-  {{{
-/bin/sh /usr/local/bin/dri_debug.sh
-}}}
-
-to have it run at boot time to save info from the last crash.
-Otherwise, just run it any old time to get a snapshot of log data.
-                                                                                            
-If there's interest, I'll put together a nice rc script that should work
-on most distros for distribution with the testing binaries.  This is
-just a "mock up" (I haven't even run it - I hate dog food ;) of what
-should be a bit more complicated and grab a few more things, but you get
-the idea.
-
-  {{{                                                                                            
-DRI_DEBUG_DIR=/var/tmp/dri_debug_`date +%d-%b-%Y-%T`
-mkdir $DRI_DEBUG_DIR
-cp /var/log/XFree86.0.log $DRI_DEBUG_DIR
-# this should work, but a grep might be better ...
-tail -5000 /var/log/messages >$DRI_DEBUG_DIR/syslog.log
-cp /etc/X11/XF86Config* $DRI_DEBUG_DIR
-ls -l /usr/lib/libGL* >>$DRI_DEBUG_DIR/usr_GLFiles.txt
-ls -l /usr/X11R6/lib  >>$DRI_DEBUG_DIR/X11R6_libFiles.txt
-ldd /usr/X11R6/bin/glxgears >>$DRI_DEBUG_DIR/ldd_glxgears.txt
-                                                                                            
-# any other files ...
-                                                                                            
-tar -czf $DRI_DEBUG_DIR.tar.gz $DRI_DEBUG_DIR
-#rm -rf $DRI_DEBUG_DIR
-}}}
-                                                                                            
-It might be nice to patch xinitrc to do this:
-
-  {{{
-glxinfo >>/var/tmp/glxinfo.txt
-}}}
-
-every time so it can be bundled up, too.
-                                                                                            
-Then when people start having problems, the list can expect (somewhat)
-consistent reports.  Lemme know what you think.
-                                                                                            
-I take no responsibility for the meltdown of your system ;) 
-
-  -- AlTobey                                                                                            
-
-== How to get a backtrace on the core dump? ==
-
-  1. If core dumps aren't turned on in your shell, turn them on.
-  For tcsh it's a command like ```limit coredumpsize 200000```
-  For bash it is ```ulimit -c unlimited```.  See the man page.
-  Start the server ```startx``` from the same shell.
-                                                                                                                                                        
-  1. When the server crashes and you get a core file, run gdb on it. The core file might be in ```/etc/X11``` if it's not in the current directory.                                                                                                                                                        
-    {{{
-gdb -c core /usr/X11R6/bin/XFree86
-}}}                                                                                                                                                     
-  1. From the gdb prompt type ```bt``` to get a backtrace.  Hopefully you
-  have symbols and it will give us an idea where it actually segfaulted.
- 
-  -- MarkVojkovich
-http://dri.sourceforge.net/cgi-bin/moin.cgi/RecentChanges
-
-== How to dump video bios ? ==
-Find the pci device associated to your gpu with lspci.
-If lspci report:
-{{{
-01:05.0 VGA compatible controller: ATI Technologies Inc RS880 [Radeon HD 4200]
-}}}
-Then
-{{{
-cd /sys/bus/pci/devices/0000:01:05.0
-sudo sh -c "echo 1 > rom"
-sudo sh -c "cat rom > ~/bios.rom"
-}}}
diff --git a/TextureCompression.mdwn b/TextureCompression.mdwn
new file mode 100644
index 0000000..87c1539
--- /dev/null
+++ b/TextureCompression.mdwn
@@ -0,0 +1,41 @@
+
+
+# Texture Compression
+
+
+## S3 Texture Compression (S3TC)
+
+See S3TC. 
+
+
+## ATIMach64 / ATIR128 texture compression
+
+According to an ATI press release:  
+
+   * _3D RAGE PRO supports several methods of texture compression, including use of palletized textures, with VQ permitting 8:1 compression, allowing content developers to produce richer content without limits on texture size. Texture compression technology and the ability to share host memory gives the developer more memory to work with when handling complex textures and removes the need to write complicated texture management schemes._ -- [[IanRomanick|IanRomanick]] 
+This is something interesting that I had also noticed when reading the chip specs, a TEX_COMPRESS bit that enabled 4:1 VQ compression. (the 8:1 must be with palletized textures simultaneously). At that time I didn't fully understand what was the meaning of this so I left this for a later time. 
+
+   * -- [[JoseFonseca|JoseFonseca]] 
+I took a peek at the ARB_texture_compression extension.  New internal format tokens would need to be created for each of the compressed formats available.  So, if only compressed RGB textures are supported by the hardware, then something like GL_COMPRESSED_RGB_VQ1_MESA would need to be added.  Then, when a texture is sent into the driver, if the texture format is non-compressed (i.e., GL_RGB) and the internal format is either GL_COMPRESSED_RGB_VQ1_MESA *or* GL_COMPRESSED_RGB, the driver would need to compress it.  If the texture format is already GL_COMPRESSED_RGB_VQ1_MESA (very, very, very, unlikely), it would just get passed through. 
+
+Now, the new token could probably be skipped.  If the requested internal format is GL_COMPRESSED_RGB, just compress the texture and be done with it. Given the likely hood of ANYONE having pre-compressed textures for this format, this is probably both the easiest and best route to take.  This is amplified by the fact that I don't think that even the ATI drivers export this functionality in OpenGL.  Does anyone know any different? 
+
+Perhaps we could discuss this more in the IRC chat today. 
+
+[[http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_compression.txt|http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_compression.txt]] [[http://oss.sgi.com/projects/ogl-sample/registry/3DFX/texture_compression_FXT1.txt|http://oss.sgi.com/projects/ogl-sample/registry/3DFX/texture_compression_FXT1.txt]] [[http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt|http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt]] 
+
+   * -- [[IanRomanick|IanRomanick]] 
+While I was searching around the net for papers on texture memory management, I came across some references to Talisman and DirectX 6.0 texture compression.  It seems that the compression algorithm used is called "TREC," which is short for "Texture and Rendering Compression." 
+
+[[http://www.ubicom.tudelft.nl/docs/UbiCom-TechnicalReport_1998_6.PDF|http://www.ubicom.tudelft.nl/docs/UbiCom-TechnicalReport_1998_6.PDF]] [[http://research.microsoft.com/MSRSIGGRAPH/96/Talisman.htm|http://research.microsoft.com/MSRSIGGRAPH/96/Talisman.htm]] 
+
+Apparently, it is some sort of DCT based compression scheme.  That would explain why ATI is the only company to ever implement it in hardware. :) 
+
+   * -- [[IanRomanick|IanRomanick]] 
+According to the docs, mach64 implements 4:1 VQ de-compression, but there's no other info.  Rage 128 also has a VQ texture format bit, according to the register header file.  Sega dreamcast used a form of VQ compression also, I think. 
+
+   * -- [[LeifDelgass|LeifDelgass]] 
+
+## General resources
+
+[[Image Compression with Vector Quantization|http://www.gamasutra.com/features/20010416/ivanov_01.htm]] (registration required) has a fairly extensive description to VQ (vector quatitization) encoding, including sample code. It actually distuinguishes VQ from DXTN (which is S3TC). 
diff --git a/TextureCompression.moin b/TextureCompression.moin
deleted file mode 100644
index e89ad8b..0000000
--- a/TextureCompression.moin
+++ /dev/null
@@ -1,75 +0,0 @@
-= Texture Compression =
-
-== S3 Texture Compression (S3TC) ==
-
-See S3TC.
-
-== ATIMach64 / ATIR128 texture compression ==
-
-According to an ATI press release: 
-
-  ''3D RAGE PRO supports several methods of texture compression, including use
-  of palletized textures, with VQ permitting 8:1 compression, allowing content
-  developers to produce richer content without limits on texture size. Texture
-  compression technology and the ability to share host memory gives the
-  developer more memory to work with when handling complex textures and
-  removes the need to write complicated texture management schemes.''
-
-  -- IanRomanick
-
-This is something interesting that I had also noticed when reading the
-chip specs, a TEX_COMPRESS bit that enabled 4:1 VQ compression. (the 8:1
-must be with palletized textures simultaneously). At that time I didn't
-fully understand what was the meaning of this so I left this for a later
-time.
-                                                                                                                        
-  -- JoseFonseca
-
-I took a peek at the ARB_texture_compression extension.  New internal format
-tokens would need to be created for each of the compressed formats
-available.  So, if only compressed RGB textures are supported by the
-hardware, then something like GL_COMPRESSED_RGB_VQ1_MESA would need to be
-added.  Then, when a texture is sent into the driver, if the texture format
-is non-compressed (i.e., GL_RGB) and the internal format is either
-GL_COMPRESSED_RGB_VQ1_MESA *or* GL_COMPRESSED_RGB, the driver would need to
-compress it.  If the texture format is already GL_COMPRESSED_RGB_VQ1_MESA
-(very, very, very, unlikely), it would just get passed through.
-                                                                                                                        
-Now, the new token could probably be skipped.  If the requested internal
-format is GL_COMPRESSED_RGB, just compress the texture and be done with it.
-Given the likely hood of ANYONE having pre-compressed textures for this
-format, this is probably both the easiest and best route to take.  This is
-amplified by the fact that I don't think that even the ATI drivers export
-this functionality in OpenGL.  Does anyone know any different?
-                                                                                                                        
-Perhaps we could discuss this more in the IRC chat today.
-                                                                                                                        
-http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_compression.txt
-http://oss.sgi.com/projects/ogl-sample/registry/3DFX/texture_compression_FXT1.txt
-http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt
-                                                                                                                        
-  -- IanRomanick
-
-While I was searching around the net for papers on texture memory
-management, I came across some references to Talisman and DirectX 6.0
-texture compression.  It seems that the compression algorithm used is
-called "TREC," which is short for "Texture and Rendering Compression."
-
-http://www.ubicom.tudelft.nl/docs/UbiCom-TechnicalReport_1998_6.PDF
-http://research.microsoft.com/MSRSIGGRAPH/96/Talisman.htm
-                                                                                            
-Apparently, it is some sort of DCT based compression scheme.  That would
-explain why ATI is the only company to ever implement it in hardware. :)
-
-  -- IanRomanick
-
-According to the docs, mach64 implements 4:1 VQ de-compression, but
-there's no other info.  Rage 128 also has a VQ texture format bit,
-according to the register header file.  Sega dreamcast used a form of VQ
-compression also, I think.
-                                                                                                                        
-  -- LeifDelgass
-
-== General resources ==
-
-[[http://www.gamasutra.com/features/20010416/ivanov_01.htm|Image Compression with Vector Quantization]] (registration required) has a fairly extensive description to VQ (vector quatitization) encoding, including sample code. It actually distuinguishes VQ from DXTN (which is S3TC).
diff --git a/TextureMapping.mdwn b/TextureMapping.mdwn
new file mode 100644
index 0000000..7de8807
--- /dev/null
+++ b/TextureMapping.mdwn
@@ -0,0 +1,11 @@
+
+
+## Texture mapping
+
+A graphic design process in which a 2D surface, called a texture map, is "wrapped around" a 3D object. Thus, the 3-D object acquires a surface texture similar to that of the 2-D surface. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/TextureMapping.moin b/TextureMapping.moin
deleted file mode 100644
index 574c4ca..0000000
--- a/TextureMapping.moin
+++ /dev/null
@@ -1,8 +0,0 @@
-== Texture mapping ==
-
-A graphic design process in which a 2D surface, called a
-texture map, is "wrapped around" a 3D object. Thus, the 3-D object acquires a
-surface texture similar to that of the 2-D surface.
-
-----
-CategoryGlossary
diff --git a/TextureMemoryManagement.mdwn b/TextureMemoryManagement.mdwn
new file mode 100644
index 0000000..0b817ac
--- /dev/null
+++ b/TextureMemoryManagement.mdwn
@@ -0,0 +1,21 @@
+
+
+# Texture Memory Management
+
+
+## Issues
+
+Here's a very rough list of issues and goals to consider:  
+
+   1. Single-copy textures Don't want to have every texture duplicated in two places: client memory (libGL) and on the card. If a texture is only present in the card's memory, what happens when we need to (re)move it to make room for new stuff? Need to make sure we never lose or corrupt a texture image. Consider glCopyTexImage(), don't ever want to lose the contents of texmem since we have no backup of the image. 
+   1. Share texmem among _n_ OpenGL clients. This works in recent DRI drivers, but is kind of klunky.  Basically, if the working set of textures for all clients can simultaneously fit in texture memory, we don't want to reload textures when we context switch. 
+   1. Dynamic allocator, to accomodate vertex buffers, pbuffers, etc. Beyond textures, there are vertex buffers, pbuffers, back buffers, depth buffers, etc that may be competing for card memory. 
+   1. AGP texturing (i.e. textures reside in AGP memory). Any circumstances when we'd have to move the textures to card memory or vice versa?  Render to texture? 
+   1. Render to texture. Can cards render to AGP memory?  Yes? This interacts with pbuffers (bind pbuffer to texture, render to the pbuffer texture). 
+   1. GL_SGIS_generate_mipmaps Use h/w image scaler to generate filtered mipmap levels? Or, for _n_x_n_ texture, render a _(n/2)_x_(n/2)_ polygon?  (w/ render-to-texture) 
+   1. [[AllenAkin|AllenAkin]]'s memory management proposal:  'pinned' textures, etc. If we ever expose memory management to the user (beyond texture priorities) we want to be sure our allocator is designed with this in mind. 
+   1. 1-D, 3-D, cube maps, texture rectangles, compression, etc. Don't forget that there's more than just traditional 2-D textures. -- [[BrianPaul|BrianPaul]] 
+
+## Design
+
+   * See [[DriMemoryManagerDesign|DriMemoryManagerDesign]]. 
+\ No newline at end of file
diff --git a/TextureMemoryManagement.moin b/TextureMemoryManagement.moin
deleted file mode 100644
index 4123e63..0000000
--- a/TextureMemoryManagement.moin
+++ /dev/null
@@ -1,60 +0,0 @@
-= Texture Memory Management =
-
-== Issues ==
-
-Here's a very rough list of issues and goals to consider: 
-
-  1. Single-copy textures
-
-  Don't want to have every texture duplicated in two places: client
-  memory (libGL) and on the card.
-
-  If a texture is only present in the card's memory, what happens
-  when we need to (re)move it to make room for new stuff?
-
-  Need to make sure we never lose or corrupt a texture image.
-  Consider glCopyTexImage(), don't ever want to lose the contents of
-  texmem since we have no backup of the image.
-
-  2. Share texmem among ''n'' OpenGL clients.
-
-  This works in recent DRI drivers, but is kind of klunky.  Basically,
-  if the working set of textures for all clients can simultaneously fit
-  in texture memory, we don't want to reload textures when we context
-  switch.
-
-  3. Dynamic allocator, to accomodate vertex buffers, pbuffers, etc.
-
-  Beyond textures, there are vertex buffers, pbuffers, back buffers,
-  depth buffers, etc that may be competing for card memory.
-
-  4. AGP texturing (i.e. textures reside in AGP memory).
-
-  Any circumstances when we'd have to move the textures to card memory
-  or vice versa?  Render to texture?
-
-  5. Render to texture.
-
-  Can cards render to AGP memory?  Yes?
-  This interacts with pbuffers (bind pbuffer to texture, render to the
-  pbuffer texture).
-
-  6. GL_SGIS_generate_mipmaps
-
-  Use h/w image scaler to generate filtered mipmap levels?
-  Or, for ''n''x''n'' texture, render a ''(n/2)''x''(n/2)'' polygon?  (w/ render-to-texture)
-
-  7. AllenAkin's memory management proposal:  'pinned' textures, etc.
-
-  If we ever expose memory management to the user (beyond texture priorities)
-  we want to be sure our allocator is designed with this in mind.
-
-  8. 1-D, 3-D, cube maps, texture rectangles, compression, etc.
-
-  Don't forget that there's more than just traditional 2-D textures.
-
-  -- BrianPaul
-
-== Design ==
-
-  See DriMemoryManagerDesign.
diff --git a/TimoJyrinki.mdwn b/TimoJyrinki.mdwn
new file mode 100644
index 0000000..2f39e2f
--- /dev/null
+++ b/TimoJyrinki.mdwn
@@ -0,0 +1,23 @@
+
+
+## Timo Jyrinki
+Email
+: timo.jyrinki at iki dot fi 
+
+Homepage
+: 
+[[http://iki.fi/tjyrinki/|http://iki.fi/tjyrinki/]] 
+
+
+Interests
+: 
+      * [[http://www.debian.fi/|http://www.debian.fi/]] 
+      * [[http://www.ubuntu-fi.org/|http://www.ubuntu-fi.org/]] 
+      * [[http://www.vapaasuomi.fi/|http://www.vapaasuomi.fi/]] 
+
+
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/TimoJyrinki.moin b/TimoJyrinki.moin
deleted file mode 100644
index 16a87b0..0000000
--- a/TimoJyrinki.moin
+++ /dev/null
@@ -1,12 +0,0 @@
-== Timo Jyrinki ==
-
- Email:: timo.jyrinki at iki dot fi
- Homepage:: http://iki.fi/tjyrinki/
-
- Interests::
-   * http://www.debian.fi/
-   * http://www.ubuntu-fi.org/
-   * http://www.vapaasuomi.fi/
-
-----
-CategoryHomepage
diff --git a/TnL.mdwn b/TnL.mdwn
new file mode 100644
index 0000000..64a474c
--- /dev/null
+++ b/TnL.mdwn
@@ -0,0 +1,11 @@
+
+
+## Transform & Lighting (T&L)
+
+This is a technique where the 3D card does even more of the 3D calculations. This eases the load on the host CPU which results in significant speed increases for certain applications (especially games). 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/TnL.moin b/TnL.moin
deleted file mode 100644
index 6642d8b..0000000
--- a/TnL.moin
+++ /dev/null
@@ -1,8 +0,0 @@
-== Transform & Lighting (T&L) ==
-
-This is a technique where the 3D card does even more of the 3D calculations.
-This eases the load on the host CPU which results in significant speed
-increases for certain applications (especially games).
-
-----
-CategoryGlossary
diff --git a/ToDo.mdwn b/ToDo.mdwn
new file mode 100644
index 0000000..272833a
--- /dev/null
+++ b/ToDo.mdwn
@@ -0,0 +1,109 @@
+
+
+## todo in DRI driver
+
+See also [[IanRomanickToDo|IanRomanickToDo]]. 
+
+
+### List of OpenGL Extensions supported at least partially by the Hardware but not by DRI driver
+
+This list is probably incomplete. 
+
+[[ARB_fragment_program_shadow|http://oss.sgi.com/projects/ogl-sample/registry/ARB/fragment_program_shadow.txt]]: `i915` 
+
+* Mesa's fragment program code will need some work to support this.  It doesn't currently track information about shadow samplers in the texture instructions. According to [[this|http://cgit.freedesktop.org/mesa/mesa/log/?qt=grep&q=fragment_program_shadow]] mesa and i965 parts should be done. 
+[[ARB_texture_cube_map|http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_cube_map.txt]]: `tdfx` (possibly on Voodoo 4/5) 
+
+[[ARB_texture_env_combine|http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_env_combine.txt]] / [[EXT_texture_env_combine|http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_env_combine.txt]]: `rage128` (with some fallbacks), `savage` 
+
+[[ARB_texture_env_crossbar|http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_env_crossbar.txt]]: `rage128`, `i915` 
+
+[[ARB_texture_non_power_of_two|http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_non_power_of_two.txt]]: `mga` (G400) (?) 
+
+[[ARB_vertex_blend|http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_blend.txt]] / [[ARB_matrix_palette|http://oss.sgi.com/projects/ogl-sample/registry/ARB/matrix_palette.txt]]: `radeon`, `r200` 
+
+* This would also need support in Mesa. 
+[[ATI_envmap_bumpmap|http://oss.sgi.com/projects/ogl-sample/registry/ATI/envmap_bumpmap.txt]]: `radeon`, `r200`, `mga`, `i830`, `savage` (?) 
+
+* This would also need support in Mesa. [[Mesa  part is done|http://cgit.freedesktop.org/mesa/mesa/commit/?id=114152e068ec919feb0a57a1259c2ada970b9f02]] 
+[[ATI_fragment_shader|http://oss.sgi.com/projects/ogl-sample/registry/ATI/fragment_shader.txt]] / [[ATI_text_fragment_shader|http://oss.sgi.com/projects/ogl-sample/registry/ATI/text_fragment_shader.txt]]: `i915` 
+
+[[EXT_fog_coord|http://oss.sgi.com/projects/ogl-sample/registry/EXT/fog_coord.txt]]: `savage`, `via` 
+
+[[EXT_paletted_texture|http://oss.sgi.com/projects/ogl-sample/registry/EXT/paletted_texture.txt]] / [[EXT_shared_texture_palette|http://oss.sgi.com/projects/ogl-sample/registry/EXT/shared_texture_palette.txt]]: `r128`, `mga` (probably G200 only), `i810`, `i830`, `via` 
+
+* The G400 is a little hinkey about the way it handles texture palettes.  The texture palette has no format.  It's just a 256x16-bit array of values.  To use a color-index texture, you blit it to a new location.  This performs a color expansion on the texture.  The "expanded" texture is then used for texture operations.  This may or may not be that useful.  The only savings would be texture upload bandwidth. 
+[[EXT_texture3D|http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture3D.txt]]: `radeon` (with some limitations) [[how to do it on r100|http://dri.sourceforge.net/IRC-logs/20040510.txt]] [[related bug #4799|https://bugs.freedesktop.org/show_bug.cgi?id=4799]] 
+
+[[EXT_texture_compression_s3tc|http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt]]: `radeon`, `r200`, `i830`, `tdfx` (voodoo4/5), `savage` 
+
+* There's an issue: see S3TC 
+[[EXT_texture_compression_dxt1|http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_dxt1.txt]]: `radeon`, `r200`, `i830`, `tdfx` (voodoo4/5), `savage` 
+
+[[EXT_texture_filter_anisotropic|http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_filter_anisotropic.txt]]: `mga` (G400) [[experimental patches|http://www.sci.fi/~syrjala/gl/]], `savage` (?), `unichrome` (?) 
+
+[[MESA_ycbcr_texture|http://oss.sgi.com/projects/ogl-sample/registry/MESA/ycbcr_texture.txt]]: `tdfx`, `gamma` (maybe), `savage` 
+
+[[NV_fog_distance|http://oss.sgi.com/projects/ogl-sample/registry/NV/fog_distance.txt]]: `radeon`, `r200` 
+
+* The `radeon` register header gives no indication that this extension is supportable on that hardware, but Apple [[supports it|http://developer.apple.com/graphicsimaging/opengl/extensions.html#GL_NV_fog_distance]]. 
+[[SGIS_sharpen_texture|http://oss.sgi.com/projects/ogl-sample/registry/SGIS/sharpen_texture.txt]]: unichrome (?) 
+
+* This would also need support in Mesa. The [[UniChrome Windows driver|http://delphi3d.net/hardware/viewreport.php?report=962]] doesn't support this extension, but [[via_3d_reg.h|http://freedesktop.org/cgi-bin/viewcvs.cgi/mesa/Mesa/src/mesa/drivers/dri/unichrome/via_3d_reg.h?view=markup]] (search for "_Sharp") has some register defines that appear to be for it.  Some experimentation would be needed. 
+
+### Non-OpenGL features
+
+These are features the hardware provides that don't have a corresponding OpenGL extension. 
+
+Texture wrap extensions: `rage128`, `i810` 
+
+texture compression: `mach64`, `rage128` 
+
+
+### Resources
+
+* mail about this topic: [[http://marc.theaimsgroup.com/?l=dri-devel&m=105332698114871&w=2|http://marc.theaimsgroup.com/?l=dri-devel&m=105332698114871&w=2]] 
+* Matrox G400 Spec. [[http://www.matrox.com/mga/products/tech_info/pdfs/g400/chip_specs.pdf|http://www.matrox.com/mga/products/tech_info/pdfs/g400/chip_specs.pdf]] 
+* OpenGL Extension Registry: [[http://oss.sgi.com/projects/ogl-sample/registry/|http://oss.sgi.com/projects/ogl-sample/registry/]] 
+* OpenGL Hardware Registry Database: [[http://delphi3d.net/hardware/|http://delphi3d.net/hardware/]] 
+* On the Status page theres info about already implemented Extensions. 
+* There is an issue with [[S3TC|http://dri.freedesktop.org/wiki/S3TC]]... 
+
+### Enhancements
+
+* Improve texture handling (`radeon`, `r200`) 
+* Include Jakub Jelineks [[libGL.so optimizations|http://marc.theaimsgroup.com/?l=dri-devel&m=105189638411789&w=2]]. [[IanRomanick|IanRomanick]] has been [[working on this|http://marc.theaimsgroup.com/?t=108786261800004&r=1&w=2&]]. 
+* Fix glDrawElements/glDrawRangeElements to not convert everything to GL_UNSIGNED_INT if the driver can handle GL_UNSIGNED_SHORT. 
+* ATIRage128: revive hw-accelerated projective texturing (was already working for singletexturing, should be possible for multitexturing, too) - [[recent attempt|http://thread.gmane.org/gmane.comp.video.dri.devel/36982]] 
+
+### Big Projects
+
+* Unify drivers where it makes sense.  `radeon` and `r200` are begging to be unified. Radeon/r200/r300 work was started as part of new memory management-related rework in [[branch|http://cgit.freedesktop.org/mesa/mesa/commit/?h=radeon-rewrite&id=692ca82116485a9c6191e5265c5b369d5b4f82f3]] and then was merged into mesa master. `i915` could be extended to cover `i810` chips as well (and possibly even `i740` if you're insane enough to try). 
+* Port the nVidia driver from UtahGLX to DRI. [[WIP as nouveau project|http://nouveau.freedesktop.org/wiki/]] 
+* Finish the [[S3Virge|S3Virge]] and Trident drivers from old CVS branches. 
+* Convert remaining drivers to t_vertex.c [[freedesktop bug id for radeon, with patch|https://bugs.freedesktop.org/show_bug.cgi?id=2195]] 
+* Get codegen working, tested, and enabled. 
+* Implement OpenGL 2.0. Done for core mesa since Mesa 7.0 and as in  (still unreleased) mesa-7.9 r300/r600, i965, nvfx/nv50 (Nouveau), and llvmpipe (new software rasterizer) advertise at least 2.0 and in some cases 2.1 support. Bugs included. 
+* [[DirectRenderingToRedirectedWindows|DirectRenderingToRedirectedWindows]] Nearly done as part of DRI2 rewrite. You need new X server and kernel drivers. 
+* Openchrome-ttm [[mesa part|http://cgit.freedesktop.org/mesa/mesa/log/?h=openchrome-branch]] , [[DRM part|http://cgit.freedesktop.org/mesa/drm/log/?h=modesetting-newttm]] , [[DDX|http://svn.openchrome.org/svn/branches/ttm_branch/]], [[Outdated instruction/announce|http://wiki.openchrome.org/pipermail/openchrome-devel/2009-January/000192.html]] 
+
+
+---
+
+ 
+
+
+## todo in DRI wiki pages
+
+Here is a list of all Wiki pages requiring attention:  
+
+Non-Wiki pages that need their important parts put into the wiki: 
+
+* [[http://dri.sourceforge.net/faq.phtml|http://dri.sourceforge.net/faq.phtml]] 
+Other structural changes the Wiki requires: 
+
+* Do not use automatic wikinames. 
+* Add a pragma to enable/disable the source code documentation x-refering. 
+Anti-Spam Protection: 
+
+* [[!MoinMoin AntiSpamGlobalSolution desc="AntiSpamGlobalSolution"]] 
+\ No newline at end of file
diff --git a/ToDo.moin b/ToDo.moin
deleted file mode 100644
index 29216d2..0000000
--- a/ToDo.moin
+++ /dev/null
@@ -1,99 +0,0 @@
-== todo in DRI driver ==
-
-See also IanRomanickToDo.
-
-=== List of OpenGL Extensions supported at least partially by the Hardware but not by DRI driver ===
-
-This list is probably incomplete.
-
-[[http://oss.sgi.com/projects/ogl-sample/registry/ARB/fragment_program_shadow.txt|ARB_fragment_program_shadow]]: `i915`
- Mesa's fragment program code will need some work to support this.  It doesn't currently track information about shadow samplers in the texture instructions. According to [[ http://cgit.freedesktop.org/mesa/mesa/log/?qt=grep&q=fragment_program_shadow | this]] mesa and i965 parts should be done.
-
-[[http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_cube_map.txt|ARB_texture_cube_map]]: `tdfx` (possibly on Voodoo 4/5)
-
-[[http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_env_combine.txt|ARB_texture_env_combine]] / [[http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_env_combine.txt|EXT_texture_env_combine]]: `rage128` (with some fallbacks), `savage`
-
-[[http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_env_crossbar.txt|ARB_texture_env_crossbar]]: `rage128`, `i915`
-
-[[http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_non_power_of_two.txt|ARB_texture_non_power_of_two]]: `mga` (G400) (?)
-
-[[http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_blend.txt|ARB_vertex_blend]] / [[http://oss.sgi.com/projects/ogl-sample/registry/ARB/matrix_palette.txt|ARB_matrix_palette]]: `radeon`, `r200`
- This would also need support in Mesa.
-
-[[http://oss.sgi.com/projects/ogl-sample/registry/ATI/envmap_bumpmap.txt|ATI_envmap_bumpmap]]: `radeon`, `r200`, `mga`, `i830`, `savage` (?)
- This would also need support in Mesa. [[http://cgit.freedesktop.org/mesa/mesa/commit/?id=114152e068ec919feb0a57a1259c2ada970b9f02 | Mesa  part is done]]
-
-[[http://oss.sgi.com/projects/ogl-sample/registry/ATI/fragment_shader.txt|ATI_fragment_shader]] / [[http://oss.sgi.com/projects/ogl-sample/registry/ATI/text_fragment_shader.txt|ATI_text_fragment_shader]]: `i915`
-
-
-[[http://oss.sgi.com/projects/ogl-sample/registry/EXT/fog_coord.txt|EXT_fog_coord]]: `savage`, `via`
-
-[[http://oss.sgi.com/projects/ogl-sample/registry/EXT/paletted_texture.txt|EXT_paletted_texture]] / [[http://oss.sgi.com/projects/ogl-sample/registry/EXT/shared_texture_palette.txt|EXT_shared_texture_palette]]: `r128`, `mga` (probably G200 only), `i810`, `i830`, `via`
-
- The G400 is a little hinkey about the way it handles texture palettes.  The texture palette has no format.  It's just a 256x16-bit array of values.  To use a color-index texture, you blit it to a new location.  This performs a color expansion on the texture.  The "expanded" texture is then used for texture operations.  This may or may not be that useful.  The only savings would be texture upload bandwidth.
-
-[[http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture3D.txt|EXT_texture3D]]: `radeon` (with some limitations) [[http://dri.sourceforge.net/IRC-logs/20040510.txt|how to do it on r100]] [[https://bugs.freedesktop.org/show_bug.cgi?id=4799|related bug #4799]]
-
-[[http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt|EXT_texture_compression_s3tc]]: `radeon`, `r200`, `i830`, `tdfx` (voodoo4/5), `savage`
- There's an issue: see S3TC
-[[http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_dxt1.txt|EXT_texture_compression_dxt1]]: `radeon`, `r200`, `i830`, `tdfx` (voodoo4/5), `savage`
-
-[[http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_filter_anisotropic.txt|EXT_texture_filter_anisotropic]]: `mga` (G400) [[http://www.sci.fi/~syrjala/gl/|experimental patches]], `savage` (?), `unichrome` (?)
-
-[[http://oss.sgi.com/projects/ogl-sample/registry/MESA/ycbcr_texture.txt|MESA_ycbcr_texture]]: `tdfx`, `gamma` (maybe), `savage`
-
-[[http://oss.sgi.com/projects/ogl-sample/registry/NV/fog_distance.txt|NV_fog_distance]]: `radeon`, `r200`
- The `radeon` register header gives no indication that this extension is supportable on that hardware, but Apple [[http://developer.apple.com/graphicsimaging/opengl/extensions.html#GL_NV_fog_distance|supports it]].
-
-[[http://oss.sgi.com/projects/ogl-sample/registry/SGIS/sharpen_texture.txt|SGIS_sharpen_texture]]: unichrome (?)
- This would also need support in Mesa.
-
- The [[http://delphi3d.net/hardware/viewreport.php?report=962|UniChrome Windows driver]] doesn't support this extension, but [[http://freedesktop.org/cgi-bin/viewcvs.cgi/mesa/Mesa/src/mesa/drivers/dri/unichrome/via_3d_reg.h?view=markup|via_3d_reg.h]] (search for "_Sharp") has some register defines that appear to be for it.  Some experimentation would be needed.
-
-=== Non-OpenGL features ===
-
-These are features the hardware provides that don't have a corresponding OpenGL extension.
-
-Texture wrap extensions: `rage128`, `i810`
-
-texture compression: `mach64`, `rage128`
-
-=== Resources ===
- * mail about this topic: [[http://marc.theaimsgroup.com/?l=dri-devel&m=105332698114871&w=2]]
- * Matrox G400 Spec. [[http://www.matrox.com/mga/products/tech_info/pdfs/g400/chip_specs.pdf]]
- * OpenGL Extension Registry: [[http://oss.sgi.com/projects/ogl-sample/registry/]]
- * OpenGL Hardware Registry Database: [[http://delphi3d.net/hardware/]]
- * On the Status page theres info about already implemented Extensions.
- * There is an issue with [[ http://dri.freedesktop.org/wiki/S3TC | S3TC ]]...
-
-=== Enhancements ===
- * Improve texture handling (`radeon`, `r200`)
- * Include Jakub Jelineks [[http://marc.theaimsgroup.com/?l=dri-devel&m=105189638411789&w=2|libGL.so optimizations]]. IanRomanick has been [[http://marc.theaimsgroup.com/?t=108786261800004&r=1&w=2&|working on this]].
- * Fix glDrawElements/glDrawRangeElements to not convert everything to GL_UNSIGNED_INT if the driver can handle GL_UNSIGNED_SHORT.
- * ATIRage128: revive hw-accelerated projective texturing (was already working for singletexturing, should be possible for multitexturing, too) - [[ http://thread.gmane.org/gmane.comp.video.dri.devel/36982 | recent attempt ]]
-
-=== Big Projects ===
- * Unify drivers where it makes sense.  `radeon` and `r200` are begging to be unified. Radeon/r200/r300 work was started as part of new memory management-related rework in [[ http://cgit.freedesktop.org/mesa/mesa/commit/?h=radeon-rewrite&id=692ca82116485a9c6191e5265c5b369d5b4f82f3| branch ]] and then was merged into mesa master. `i915` could be extended to cover `i810` chips as well (and possibly even `i740` if you're insane enough to try).
- * Port the nVidia driver from UtahGLX to DRI. [[http://nouveau.freedesktop.org/wiki/ | WIP as nouveau project]]
- * Finish the S3Virge and Trident drivers from old CVS branches.
- * Convert remaining drivers to t_vertex.c [[https://bugs.freedesktop.org/show_bug.cgi?id=2195|freedesktop bug id for radeon, with patch]]
- * Get codegen working, tested, and enabled.
- * Implement OpenGL 2.0. Done for core mesa since Mesa 7.0 and as in  (still unreleased) mesa-7.9 r300/r600, i965, nvfx/nv50 (Nouveau), and llvmpipe (new software rasterizer) advertise at least 2.0 and in some cases 2.1 support. Bugs included.
- * DirectRenderingToRedirectedWindows Nearly done as part of DRI2 rewrite. You need new X server and kernel drivers.
- * Openchrome-ttm [[ http://cgit.freedesktop.org/mesa/mesa/log/?h=openchrome-branch | mesa part ]] , [[ http://cgit.freedesktop.org/mesa/drm/log/?h=modesetting-newttm | DRM part ]] , [[ http://svn.openchrome.org/svn/branches/ttm_branch/| DDX ]], [[ http://wiki.openchrome.org/pipermail/openchrome-devel/2009-January/000192.html | Outdated instruction/announce]]
-----
-
-== todo in DRI wiki pages ==
-
-Here is a list of all Wiki pages requiring attention:
-<<FullSearch>>
-
-Non-Wiki pages that need their important parts put into the wiki:
- * http://dri.sourceforge.net/faq.phtml
-
-Other structural changes the Wiki requires:
- * Do not use automatic wikinames.
- * Add a pragma to enable/disable the source code documentation x-refering.
-
-Anti-Spam Protection:
- * MoinMoin:AntiSpamGlobalSolution
diff --git a/TormodVolden.moin b/TormodVolden.mdwn
index 7b620ca..05c7fad 100644
--- a/TormodVolden.moin
+++ b/TormodVolden.mdwn
@@ -1,8 +1,13 @@
-== Tormod Volden ==
-
-Email: $1 . $2 @gmail.com
-
-I am mainly active in testing ati and savage drivers, working with Debian and Ubuntu distributions. Try to help with documentation as well.
-
-----
-CategoryHomepage
+
+
+## Tormod Volden
+
+Email: $1 . $2 @gmail.com 
+
+I am mainly active in testing ati and savage drivers, working with Debian and Ubuntu distributions. Try to help with documentation as well. 
+
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/Trident.mdwn b/Trident.mdwn
new file mode 100644
index 0000000..074f070
--- /dev/null
+++ b/Trident.mdwn
@@ -0,0 +1,28 @@
+
+
+# Trident
+
+[[!map pages="^Trident.+"]] 
+
+
+## Status
+
+[[AlanHourihane|AlanHourihane]] started writing a 3D driver for certain trident chips.  The DRI component is available in Mesa CVS; the DRM and DDX are available on the trident-0-0-2 branch on DRI CVS.  It is not yet finished. 
+
+The XGI Volari V3 is also based on a Trident core. 
+
+
+## Specifications
+
+Complete specs (2D, 3D, Overlay and MC/IDCT, capture, and dualhead) for the Trident CyberBLADE i1 (VIA Apollo PLE133 Chipset VT8601A North Bridge) [[http://www.viavpsd.com/product/Download.jsp?motherboardId=21|http://www.viavpsd.com/product/Download.jsp?motherboardId=21]] 
+
+
+## Resources
+
+Trident Microsystems, Inc: Videographics: [[http://www.tridentmicro.com/videographics/index.asp|http://www.tridentmicro.com/videographics/index.asp]] 
+
+
+
+---
+
+ [[CategoryHardwareVendor|CategoryHardwareVendor]] [[CategoryHelpWanted|CategoryHelpWanted]] 
diff --git a/Trident.moin b/Trident.moin
deleted file mode 100644
index 204c95d..0000000
--- a/Trident.moin
+++ /dev/null
@@ -1,21 +0,0 @@
-= Trident =
-
-<<PageList(^Trident.+)>>
-
-== Status ==
-
-AlanHourihane started writing a 3D driver for certain trident chips.  The DRI component is available in Mesa CVS; the DRM and DDX are available on the trident-0-0-2 branch on DRI CVS.  It is not yet finished.
-
-The XGI Volari V3 is also based on a Trident core.
-
-== Specifications ==
-
-Complete specs (2D, 3D, Overlay and MC/IDCT, capture, and dualhead) for the Trident CyberBLADE i1 (VIA Apollo PLE133 Chipset VT8601A North Bridge) http://www.viavpsd.com/product/Download.jsp?motherboardId=21
-
-== Resources ==
-
-Trident Microsystems, Inc: Videographics: http://www.tridentmicro.com/videographics/index.asp
-
-
-----
-CategoryHardwareVendor CategoryHelpWanted
diff --git a/Troubleshooting.mdwn b/Troubleshooting.mdwn
new file mode 100644
index 0000000..9189f3f
--- /dev/null
+++ b/Troubleshooting.mdwn
@@ -0,0 +1,12 @@
+
+
+# Troubleshooting
+
+This is a list of problems users may run into and potential solutions. 
+
+[[!inline pages="link('CategoryTroubleshooting')" quick feeds="no" archive="yes"]] 
+
+
+## Adding new troubleshooting items
+
+To add new troubleshooting items choose the [[TroubleshootingTemplate|TroubleshootingTemplate]] when creating a new page. 
diff --git a/Troubleshooting.moin b/Troubleshooting.moin
deleted file mode 100644
index 0b8319c..0000000
--- a/Troubleshooting.moin
+++ /dev/null
@@ -1,10 +0,0 @@
-= Troubleshooting =
- 
-This is a list of problems users may run into and potential solutions.
- 
-<<FullSearch('CategoryTroubleshooting')>>
- 
-== Adding new troubleshooting items ==
- 
-To add new troubleshooting items choose the TroubleshootingTemplate when
-creating a new page.
diff --git a/TroubleshootingTemplate.mdwn b/TroubleshootingTemplate.mdwn
new file mode 100644
index 0000000..d0ee149
--- /dev/null
+++ b/TroubleshootingTemplate.mdwn
@@ -0,0 +1,23 @@
+
+
+# Application
+
+
+## A problem
+
+**Problem** 
+
+   * Detailed description. 
+**Solution** 
+
+   * How to fix it, if known. 
+
+## Another problem
+
+... 
+
+
+
+---
+
+ [[CategoryTroubleshooting|CategoryTroubleshooting]] 
diff --git a/TroubleshootingTemplate.moin b/TroubleshootingTemplate.moin
deleted file mode 100644
index 0b0e014..0000000
--- a/TroubleshootingTemplate.moin
+++ /dev/null
@@ -1,16 +0,0 @@
-= Application =
-
-== A problem ==
-
-'''Problem'''
-  Detailed description.
-
-'''Solution'''
-  How to fix it, if known.
- 
-== Another problem ==
- 
-...
-
-----
-CategoryTroubleshooting
diff --git a/UtahGLX.mdwn b/UtahGLX.mdwn
new file mode 100644
index 0000000..f23a22d
--- /dev/null
+++ b/UtahGLX.mdwn
@@ -0,0 +1,17 @@
+
+
+## Utah-GLX
+
+An early project to integrate accelerated 3D into XFree86 3.3. The primitive architecture of UtahGLX makes it slower than the DRI but it is much simpler to implement and is also easier to write drivers for. This meant UtahGLX was available earlier than the DRI and with a greater range of supported 3D cards. UtahGLX is still the only available option for accelerated 3D under XFree86 3.3 unless you have a Voodoo based card. 
+
+Most of UtahGLX is based on earlier Mesa code. Some of the work is the DRI work, and some is the Mesa work. The Mesa work will transfer over reasonably well. The DRI work is mostly initialization and kernel drivers. 
+
+
+### Resources
+
+   * [[Utah-GLX homepage|http://utah-glx.sourceforge.net/]] 
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/UtahGLX.moin b/UtahGLX.moin
deleted file mode 100644
index cf1d10a..0000000
--- a/UtahGLX.moin
+++ /dev/null
@@ -1,19 +0,0 @@
-== Utah-GLX ==
-
-An early project to integrate accelerated 3D into XFree86 3.3. The primitive
-architecture of UtahGLX makes it slower than the DRI but it is much simpler to
-implement and is also easier to write drivers for. This meant UtahGLX was
-available earlier than the DRI and with a greater range of supported 3D cards.
-UtahGLX is still the only available option for accelerated 3D under XFree86 3.3
-unless you have a Voodoo based card.
-
-Most of UtahGLX is based on earlier Mesa code. Some of the work is the DRI
-work, and some is the Mesa work. The Mesa work will transfer over reasonably
-well. The DRI work is mostly initialization and kernel drivers.
-
-=== Resources ===
-
-  * [[http://utah-glx.sourceforge.net/|Utah-GLX homepage]]
-
-----
-CategoryGlossary
diff --git a/V4L2Integration.mdwn b/V4L2Integration.mdwn
new file mode 100644
index 0000000..c3eb4d1
--- /dev/null
+++ b/V4L2Integration.mdwn
@@ -0,0 +1,4 @@
+
+So far none successed in proper integration of [[V4L2|http://linuxtv.org/wiki/index.php/Main_Page]] (Video-for-Linux, v2, used in Linux kernel at least) and DRI  (now DRI2/KMS-enabled)  drivers. One attempt seems to be started by Dave Airlie: [[Radeon-AiW|http://people.freedesktop.org/~airlied/aiw/]].  
+
+Just creating stub page, for people who able to work in this area or share ideas. 
diff --git a/V4L2Integration.moin b/V4L2Integration.moin
deleted file mode 100644
index 7e6dc42..0000000
--- a/V4L2Integration.moin
+++ /dev/null
@@ -1,3 +0,0 @@
-So far none successed in proper integration of [[ http://linuxtv.org/wiki/index.php/Main_Page | V4L2 ]] (Video-for-Linux, v2, used in Linux kernel at least) and DRI  (now DRI2/KMS-enabled)  drivers. One attempt seems to be started by Dave Airlie: [[ http://people.freedesktop.org/~airlied/aiw/ | Radeon-AiW ]]. 
-
-Just creating stub page, for people who able to work in this area or share ideas.
diff --git a/VIA.mdwn b/VIA.mdwn
new file mode 100644
index 0000000..198b64d
--- /dev/null
+++ b/VIA.mdwn
@@ -0,0 +1,12 @@
+
+
+# VIA
+
+**Chipsets** [[!map pages="^VIA.+"]] 
+
+* [[VIACLE266|VIACLE266]] 
+
+
+---
+
+ [[CategoryHardwareVendor|CategoryHardwareVendor]] 
diff --git a/VIA.moin b/VIA.moin
deleted file mode 100644
index 8e802c8..0000000
--- a/VIA.moin
+++ /dev/null
@@ -1,8 +0,0 @@
-= VIA =
-
-'''Chipsets'''
-<<PageList(^VIA.+)>>
- * [[VIACLE266]]
-
-----
-CategoryHardwareVendor
diff --git a/VIACLE266.mdwn b/VIACLE266.mdwn
new file mode 100644
index 0000000..afab39c
--- /dev/null
+++ b/VIACLE266.mdwn
@@ -0,0 +1,30 @@
+
+
+## Chipset Name
+
+* CLE266 
+* Castlerock 
+* Unichrome 
+* [[ProSavage|ProSavage]]-DDR400 
+
+## Status
+
+Alan Cox ported the 3D driver to a more recent version of mesa.  [[ErdiChen|ErdiChen]] put the 3D driver in Mesa cvs.  The cleaned up and improved 2D driver from XFree86 has not yet been integrated into DRI cvs. 
+
+
+## Specifications
+
+The basics can be deduced from the driver_lite source from VIA. Its a fairly generic "queue up the vertices and fire" type chipset and the most noticable thing about it appears to be the lack of hardware clipping. When its not doing fallbacks performance seems comparable to the onboard intel stuff but its not radeon grade. 
+
+
+## Resources
+
+* [[Product homepage|http://www.s3graphics.com/en/products/unichrome/]] 
+* [[Vendor drivers|http://www.viaarena.com/default.aspx?PageID=420&OSID=20&CatID=2260&SubCatID=158]] 
+* Continuing work on the 2D driver in the [[Unichrome project|http://unichrome.sourceforge.net/]], and the [[openChrome project|http://www.openchrome.org]] fork. 
+* [[Alan's patches|http://people.redhat.com/alan]] 
+
+
+---
+
+ [[CategoryHardwareChipset|CategoryHardwareChipset]], [[CategoryHelpWanted|CategoryHelpWanted]] 
diff --git a/VIACLE266.moin b/VIACLE266.moin
deleted file mode 100644
index ca0970a..0000000
--- a/VIACLE266.moin
+++ /dev/null
@@ -1,25 +0,0 @@
-== Chipset Name ==
-
- * CLE266
- * Castlerock
- * Unichrome
- * ProSavage-DDR400
-
-== Status ==
-
-Alan Cox ported the 3D driver to a more recent version of mesa.  ErdiChen put the 3D driver in Mesa cvs.  The cleaned up and improved 2D driver from XFree86 has not yet been integrated into DRI cvs.
-
-== Specifications ==
-
-The basics can be deduced from the driver_lite source from VIA. Its a fairly generic "queue up the vertices and fire" type chipset and
-the most noticable thing about it appears to be the lack of hardware clipping. When its not doing fallbacks performance seems comparable to the onboard intel stuff but its not radeon grade.
- 
-== Resources ==
- 
- * [[http://www.s3graphics.com/en/products/unichrome/|Product homepage]]
- * [[http://www.viaarena.com/default.aspx?PageID=420&OSID=20&CatID=2260&SubCatID=158|Vendor drivers]]
- * Continuing work on the 2D driver in the [[http://unichrome.sourceforge.net/|Unichrome project]], and the [[http://www.openchrome.org|openChrome project]] fork.
- * [[http://people.redhat.com/alan|Alan's patches]]
-
-----
-CategoryHardwareChipset, CategoryHelpWanted
diff --git a/VNC.mdwn b/VNC.mdwn
new file mode 100644
index 0000000..13b213b
--- /dev/null
+++ b/VNC.mdwn
@@ -0,0 +1,4 @@
+
+VNC stands for "Virtual Network Computing" 
+
+A spinoff project at [[http://xf4vnc.sourceforge.net|http://xf4vnc.sourceforge.net]] was created to tightly integrate the original VNC code into the XFree86 v4 architecture. 
diff --git a/VNC.moin b/VNC.moin
deleted file mode 100644
index f7e6d0b..0000000
--- a/VNC.moin
+++ /dev/null
@@ -1,3 +0,0 @@
-VNC stands for "Virtual Network Computing"
-
-A spinoff project at http://xf4vnc.sourceforge.net was created to tightly integrate the original VNC code into the XFree86 v4 architecture.
diff --git a/VilleSyrjala.mdwn b/VilleSyrjala.mdwn
new file mode 100644
index 0000000..ca76793
--- /dev/null
+++ b/VilleSyrjala.mdwn
@@ -0,0 +1,22 @@
+
+
+## Ville Syrjälä
+Email
+: syrjala at sci dot fi 
+
+Homepage
+: 
+[[http://www.sci.fi/~syrjala/|http://www.sci.fi/~syrjala/]] 
+
+
+Interests
+: 
+      * Matrox driver 
+      * DirectFB 
+
+
+
+
+---
+
+ [[CategoryHomepage|CategoryHomepage]] 
diff --git a/VilleSyrjala.moin b/VilleSyrjala.moin
deleted file mode 100644
index 0b540d9..0000000
--- a/VilleSyrjala.moin
+++ /dev/null
@@ -1,12 +0,0 @@
-== Ville Syrjälä ==
-
- Email:: syrjala at sci dot fi
-
- Homepage:: http://www.sci.fi/~syrjala/
-
- Interests::
-   * Matrox driver
-   * DirectFB
-
-----
-CategoryHomepage
diff --git a/WhosWho.mdwn b/WhosWho.mdwn
new file mode 100644
index 0000000..9db9728
--- /dev/null
+++ b/WhosWho.mdwn
@@ -0,0 +1,17 @@
+
+
+# Who's who on IRC
+
+Here you can find informations about people hanging on dri related channels (#radeon, #radeonhd, #dri-devel, #intel-gfx, #nouveau) 
+[[!table header="no" class="mointable" data="""
+ **Name**  |  **IRC Nick**  |  **Contact**  |  **Location**  |  **Timezone** 
+ Alex Deucher  |  agd5f  |  <alexdeucher AT SPAMFREE gmail DOT com>  |  Virginia, USA  |  UTC-5 (EST) 
+ Christoph Brill  |  egore/cbrill/tirdc  |  <egore911 AT SPAMFREE egore911 DOT de>  |  Germany  |   UTC+1 (CET) 
+ Corbin Simpson  |  [[MostAwesomeDude|MostAwesomeDude]]  |  <[[MostAwesomeDude|MostAwesomeDude]] AT SPAMFREE gmail DOT com>  |  Eugene, Oregon, USA  |  UTC-8 (PST) 
+ Dave Airlie  |  airlied  |  airlied@ <insert domain >  |  Brisbane, Australia  |  UTC+10 (ASS) 
+ Jakob Bornecrantz  |  Dr_Jakob/Wallbraker  |  <wallbraker AT SPAMFREE gmail DOT com>  |  Sweden  |  UTC+1 (CET) 
+ John Bridgman  |  bridgman  |  <johnb AT SPAMFREE interlog DOT com>  |  Toronto, Canada  |  UTC-5 (EST) 
+ Maciej Cencora  |  osiris |  <m DOT cencora AT SPAMFREE gmail DOT com>  |  Poland  |  UTC+1 (CET) 
+ Nicolai Hähnle  |  nha  |  <nhaehnle AT SPAMFREE gmail DOT com>  |  Germany  |  UTC+1 (CET) 
+ Owain Ainsworth  |  oga  |  <oga AT SPAMFREE openbsd DOT org>  |  London, England  |  UTC+0 (GMT/BST) 
+"""]]
diff --git a/WhosWho.moin b/WhosWho.moin
deleted file mode 100644
index 47970ff..0000000
--- a/WhosWho.moin
+++ /dev/null
@@ -1,14 +0,0 @@
-= Who's who on IRC =
-
-Here you can find informations about people hanging on dri related channels (#radeon, #radeonhd, #dri-devel, #intel-gfx, #nouveau)
-
-|| '''Name''' || '''IRC Nick''' || '''Contact''' || '''Location''' || '''Timezone''' ||
-|| Alex Deucher || agd5f || <alexdeucher AT SPAMFREE gmail DOT com> || Virginia, USA || UTC-5 (EST) ||
-|| Christoph Brill || egore/cbrill/tirdc || <egore911 AT SPAMFREE egore911 DOT de> || Germany ||  UTC+1 (CET) ||
-|| Corbin Simpson || MostAwesomeDude || <MostAwesomeDude AT SPAMFREE gmail DOT com> || Eugene, Oregon, USA || UTC-8 (PST) ||
-|| Dave Airlie || airlied || airlied@ <insert domain > || Brisbane, Australia || UTC+10 (ASS) ||
-|| Jakob Bornecrantz || Dr_Jakob/Wallbraker || <wallbraker AT SPAMFREE gmail DOT com> || Sweden || UTC+1 (CET) ||
-|| John Bridgman || bridgman || <johnb AT SPAMFREE interlog DOT com> || Toronto, Canada || UTC-5 (EST) ||
-|| Maciej Cencora || osiris|| <m DOT cencora AT SPAMFREE gmail DOT com> || Poland || UTC+1 (CET) ||
-|| Nicolai Hähnle || nha || <nhaehnle AT SPAMFREE gmail DOT com> || Germany || UTC+1 (CET) ||
-|| Owain Ainsworth || oga || <oga AT SPAMFREE openbsd DOT org> || London, England || UTC+0 (GMT/BST) ||
diff --git a/WikiSandBox.mdwn b/WikiSandBox.mdwn
new file mode 100644
index 0000000..4cb6593
--- /dev/null
+++ b/WikiSandBox.mdwn
@@ -0,0 +1,8 @@
+
+Wiki is as Wiki was.  Wiki is triki.  Would you lite my Wiki? 
+
+Me like Wiki, Wiki the one for me! 
+
+More Wiki. 
+
+Wiki for all. 
diff --git a/WikiSandBox.moin b/WikiSandBox.moin
deleted file mode 100644
index 8a54ec6..0000000
--- a/WikiSandBox.moin
+++ /dev/null
@@ -1,7 +0,0 @@
-Wiki is as Wiki was.  Wiki is triki.  Would you lite my Wiki?
-
-Me like Wiki, Wiki the one for me!
-
-More Wiki.
-
-Wiki for all.
diff --git a/WorkQueue.mdwn b/WorkQueue.mdwn
new file mode 100644
index 0000000..e950868
--- /dev/null
+++ b/WorkQueue.mdwn
@@ -0,0 +1,164 @@
+[[!table header="no" class="mointable" data="""
+**Item ID**        | **Dependencies** | **Est. Days** | **Priority** | **Category** | **Description** | **Item Author** | **Current Owner** | **Notes**
+<a name="XF01"></a>XF01 (Done, pending tests) |    | 3 | high | GL 3.0 | Enhance state tracking for transform feedback | [[DanMcCabe|DanMcCabe]] | [[DanMcCabe|DanMcCabe]] | Previously completed by [[BrianPaul|BrianPaul]]
+<a name="XF02"></a>XF02 (Done, pending tests) |    | 2 | high | GL 3.0 | Add 9 transform feedback entry points | [[DanMcCabe|DanMcCabe]] | [[DanMcCabe|DanMcCabe]] | Previously completed by [[BrianPaul|BrianPaul]]
+<a name="XF03"></a>XF03 (Done, pending tests) | [[XF02|WorkQueue]]  | 5 | high | GL 3.0 | Validate parameters in transform feedback entry points | [[DanMcCabe|DanMcCabe]] | [[DanMcCabe|DanMcCabe]] | Previously completed by [[BrianPaul|BrianPaul]] 
+<a name="XF04"></a>XF04 (Done, pending tests) |    | 5 | high | GL 3.0 | Validate transform feedback related parameters in existing GL entry points | [[DanMcCabe|DanMcCabe]] | [[DanMcCabe|DanMcCabe]] | Previously completed by [[BrianPaul|BrianPaul]] 
+<a name="XF05"></a>XF05 (Done, pending tests) |    | 5 | high | GL 3.0 | glBindBuffers support for transform feedback | [[DanMcCabe|DanMcCabe]] | [[DanMcCabe|DanMcCabe]] | Previously completed by [[BrianPaul|BrianPaul]]
+<a name="XF06"></a>XF06 |    | 5 | high | GL 3.0 | Varying variable support for transform feedback.  This is filling in the guts of glTransformFeedbackVaryings and glGetTransformFeedbackVarying. | [[DanMcCabe|DanMcCabe]] | [[EricAnholt|EricAnholt]] |  
+<a name="XF07"></a>XF07 (Done, pending tests) | [[XF06|WorkQueue]]  | 5 | high | GL 3.0 | Enhance linker support for transform feedback | [[DanMcCabe|DanMcCabe]] | [[PaulBerry|PaulBerry]] |  
+<a name="XF_SNB_1"></a>XF_SNB_1 (Done) |   |   | high | GL 3.0 | Learn how to test stream output logic in the simulator | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="XF_SNB_2"></a>XF_SNB_2 (Done) |   |   | high | GL 3.0 | Implement pass-through GS shader program | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="XF_SNB_3"></a>XF_SNB_3 (Done) |   |   | high | GL 3.0 | Output dummy data to transform feedback buffer | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="XF_SNB_4"></a>XF_SNB_4 (Done) |   |   | high | GL 3.0 | Output correct data in SEPARATE_ATTRIBS mode | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="XF_SNB_5"></a>XF_SNB_5 (Done) |   |   | high | GL 3.0 | Output correct data in INTERLEAVED_ATTRIBS mode | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="XF_SNB_6"></a>XF_SNB_6 (Done) |   |   | high | GL 3.0 | Ensure that buffer overflow behavior is correct | [[PaulBerry|PaulBerry]] | [[KennethGraunke|KennethGraunke]] |  
+<a name="XF_SNB_7"></a>XF_SNB_7 (Done) |   |   | high | GL 3.0 | Update pointers correctly on begin/end/pause/resume | [[PaulBerry|PaulBerry]] | [[KennethGraunke|KennethGraunke]] |  
+<a name="XF_SNB_8"></a>XF_SNB_8 (Done) |   |   | high | GL 3.0 | Implement rasterizer discard | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="XF_SNB_9"></a>XF_SNB_9 |   |   | high | GL 3.0 | Thoroughly test and debug all SNB XF behavior except queries | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="XF_SNB_10"></a>XF_SNB_10 (Done) |   |   | high | GL 3.0 | Implement PRIMITIVES_GENERATED and TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN queries | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="XF_SNB_11"></a>XF_SNB_11 (Done) |   |   | high | GL 3.0 | Test PRIMITIVES_GENERATED and TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN queries | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="XF_IVB_1"></a>XF_IVB_1 (Done) |   |   | high | GL 3.0 | Kernel interface for setting registers | [[PaulBerry|PaulBerry]] | [[EricAnholt|EricAnholt]] |  
+<a name="XF_IVB_2"></a>XF_IVB_2 (Done) |   |   | high | GL 3.0 | Output correct data in SEPARATE_ATTRIBS mode | [[PaulBerry|PaulBerry]] | [[EricAnholt|EricAnholt]] |  
+<a name="XF_IVB_3"></a>XF_IVB_3 (Done) |   |   | high | GL 3.0 | Output correct data in INTERLEAVED_ATTRIBS mode | [[PaulBerry|PaulBerry]] | [[EricAnholt|EricAnholt]] |  
+<a name="XF_IVB_4"></a>XF_IVB_4 |   |   | high | GL 3.0 | Ensure that buffer overflow behavior is correct | [[PaulBerry|PaulBerry]] | [[EricAnholt|EricAnholt]] |  Should be fine, need to review tests and run them.
+<a name="XF_IVB_5"></a>XF_IVB_5 (Done) |   |   | high | GL 3.0 | Update pointers correctly on begin/end/pause/resume | [[PaulBerry|PaulBerry]] |   |  Cross-batchbuffer pointers incorrect, need to review tests and implement.
+<a name="XF_IVB_6"></a>XF_IVB_6 (Done) |   |   | high | GL 3.0 | Implement rasterizer discard | [[PaulBerry|PaulBerry]] | [[EricAnholt|EricAnholt]] | (works)
+<a name="XF_IVB_7"></a>XF_IVB_7 (Done) |   |   | high | GL 3.0 | Thoroughly test and debug all IVB XF behavior except queries | [[PaulBerry|PaulBerry]] |   |  (note: some oglc failures remain, one class may be IVB specific) 
+<a name="XF_IVB_8"></a>XF_IVB_8 (Done) |   |   | high | GL 3.0 | Implement PRIMITIVES_GENERATED and TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN queries | [[PaulBerry|PaulBerry]] |   |  
+<a name="XF_IVB_9"></a>XF_IVB_9 (Done) |   |   | high | GL 3.0 | Test PRIMITIVES_GENERATED and TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN queries | [[PaulBerry|PaulBerry]] |   |  
+<a name="XF14"></a>XF14 (Done) |    | 5 | low | GL 3.0 | Test input validity | [[DanMcCabe|DanMcCabe]] | [[EugeniDodonov|EugeniDodonov]], [[PaulBerry|PaulBerry]] | [[http://cgit.freedesktop.org/~eugeni/piglit/|http://cgit.freedesktop.org/~eugeni/piglit/]], priority is lowered because Marek's piglit test already covers this partly
+<a name="XF15"></a>XF15 |    | 3 | low | GL 3.0 | Test buffer binding | [[DanMcCabe|DanMcCabe]] | [[EugeniDodonov|EugeniDodonov]], [[PaulBerry|PaulBerry]] | [[http://cgit.freedesktop.org/~eugeni/piglit/|http://cgit.freedesktop.org/~eugeni/piglit/]], priority is lowered because Marek's piglit test already covers this partly
+<a name="XF16"></a>XF16 (Done) |    | 2 | high | GL 3.0 | Test linking and glUseProgram | [[DanMcCabe|DanMcCabe]] | [[PaulBerry|PaulBerry]] |  
+<a name="XF17"></a>XF17 |    | 2 | high | GL 3.0 | Test tesselation and incomplete primitives | [[DanMcCabe|DanMcCabe]] | Paul Berry | I think this estimate is low.
+<a name="XF18"></a>XF18 |    | 1 | high | GL 3.0 | Test buffer overflow | [[DanMcCabe|DanMcCabe]] | Paul Berry | I think this estimate is low.
+<a name="XF19"></a>XF19 |    | 3 | high | GL 3.0 | Test varyings | [[DanMcCabe|DanMcCabe]] | Paul Berry | I think this estimate is low.
+<a name="XF20"></a>XF20 (Done) |    | 5 | high | GL 3.0 | Test output | [[DanMcCabe|DanMcCabe]] | [[MarekOlsak|MarekOlsak]] |  
+<a name="IR1"></a>IR1 |    | 10 | high | perf | Replace context “program” attached state with SSO-style shader state | [[IanRomanick|IanRomanick]] | [[IanRomanick|IanRomanick]] |  
+<a name="IR2"></a>IR2 | [[IR1|WorkQueue]]  | 10 | high | perf | Generate GLSL IR for ARB assembly programs | [[IanRomanick|IanRomanick]] |   |  
+<a name="IR3"></a>IR3 | [[IR1|WorkQueue]]  | 10 | high | perf | Generate GLSL IR for NV vertex assembly programs | [[IanRomanick|IanRomanick]] |   | There will be a lot of cut-and-paste between IR2 and IR3
+<a name="IR4"></a>IR4 |    | 3 | high | perf | Remove NV fragment assembly program support | [[IanRomanick|IanRomanick]] |   |  
+<a name="CD0"></a>CD0 (Done) |    | 10 | high | GL 3.0 | Refactor VUE layout code in preparation for `gl_ClipDistance` | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="CD1"></a>CD1 (Done) |    | 5 | high | GL 3.0 | Compiler front-end support for `gl_Distance` | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="CD2"></a>CD2 (Done) | [[CD1|WorkQueue]]  | 5 | high | GL 3.0 | Lower `gl_ClipDistance` from float[8] to vec4[2] | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="CD3"></a>CD3 (Done) | [[CD2|WorkQueue]]  | 5 | high | GL 3.0 | Test `gl_ClipDistance` lowering pass | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="CD4"></a>CD4 (Done) | [[CD3|WorkQueue]]  | 5 | high | GL 3.0 | SNB support for `gl_ClipDistance` | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] | "First triangle" achieved on private branch 9/2
+<a name="CD5"></a>CD5 (Done) | [[CD1|WorkQueue]]  | 3 | med | GL 3.0 | Emit error if a shader writes both `gl_ClipDistance` and `gl_ClipVertex` | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="CD6"></a>CD6 (Done) |    | 5 | high | GL 3.0 | Add `gl_ClipDistance` as a fragment shader built-in input | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="CD7"></a>CD7 (Done) |    | 5 | high | GL 3.0 | Implement and test `gl_ClipDistance` sizing rules | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="CD8"></a>CD8 (Done) |    | 3 | high | GL 3.0 | `gl_ClipDistance` tests | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="CV1"></a>CV1 (Done) |    | 5 | med | GL 2.x | Add gl_vert_result slot for `gl_ClipVertex` | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="CV2"></a>CV2 (Done) |   | 5 | med | GL 2.x | Detect writes to `gl_ClipVertex` in the linker | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] | Proved to be unnecessary
+<a name="CV3"></a>CV3 | [[CV2|WorkQueue]]  | 3 | low | GL 2.x | Use proper slot for writes to `gl_ClipVertex` (i915) | [[PaulBerry|PaulBerry]] |   |  
+<a name="CV4"></a>CV4 | [[CV2|WorkQueue]]  | 3 | low | GL 2.x | Use proper slot for writes to `gl_ClipVertex` (i965, pre-SNB) | [[PaulBerry|PaulBerry]] |   |  
+<a name="CV5"></a>CV5 (Done) | [[CV2|WorkQueue]]  | 3 | low | GL 2.x | Use proper slot for writes to `gl_ClipVertex` (i965, SNB+) | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="CV6"></a>CV6 (Done) |    | 3 | low | GL 2.x | `gl_ClipVertex` tests | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] | These could be co-developed w/CD8
+<a name="HTRIG1"></a>HTRIG1 (Done) |    | 2 | med | GL 3.0 | Test GLSL 1.30 hyperbolic trig functions | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="HTRIG2"></a>HTRIG2 (Done) | [[VS12|WorkQueue]]  | 3 | med | GL 3.0 | Fix GLSL 1.30 hyperbolic trig functions | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="TEST1"></a>TEST1 (Done) |    | 5 | med | GL 3.0 | Adapt built-in tests for new unsigned types (vector and scalar) | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="TEST2"></a>TEST2 (Done) |    | 3 | med | GL 3.0 | Adapt built-in tests to test operators | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] |  
+<a name="TEST3"></a>TEST3 (Done) | [[TEST6|WorkQueue]]   | 3 | med | GL 3.0 | Test `isinf` and `isnan` | [[PaulBerry|PaulBerry]] | [[PaulBerry|PaulBerry]] | Depends on TEST6 because otherwise interpolation turns infinities into [[NaNs|NaNs]]
+<a name="TEST4"></a>TEST4 (Done) |    | 3 | med | GL 3.0 | Test `noperspective` interpolation qualifier. | [[ChadVersace|ChadVersace]] | [[PaulBerry|PaulBerry]] |  
+<a name="TEST5"></a>TEST5 |    | 3 | med | GL 3.0 | Test `centroid` interpolation qualifier. | [[ChadVersace|ChadVersace]] | [[PaulBerry|PaulBerry]] |  
+<a name="TEST6"></a>TEST6 (Done) |    | 3 | med | GL 3.0 | Test flat interpolation qualifier. | [[ChadVersace|ChadVersace]] | [[PaulBerry|PaulBerry]] |  
+<a name="TEST7"></a>TEST7 (Done) |    | 1 | med | GL 3.0 | Shader inputs are read-only.  We already mark global inputs as ro, but have no tests for it. | [[ChadVersace|ChadVersace]] | [[PaulBerry|PaulBerry]] |  
+<a name="HIZ1"></a>HIZ1 (Done) |    | 5 | high | perf | Write resolve meta-ops for hiz->depth and depth->hiz | [[ChadVersace|ChadVersace]] | [[ChadVersace|ChadVersace]] |  
+<a name="HIZ2"></a>HIZ2 (Done) |    | 5 | high | perf | Hook resolves into texture & draw functions (no mipmaps yet) | [[ChadVersace|ChadVersace]] | [[ChadVersace|ChadVersace]] |  
+<a name="HIZ3"></a>HIZ3 (Done) | [[HIZ2|WorkQueue]]  | 4 | high | perf | Test and debug hiz->depth resolve hooks (single ctx, no mipmaps). | [[ChadVersace|ChadVersace]] | [[ChadVersace|ChadVersace]] |  
+<a name="HIZ4"></a>HIZ4 (Done) | [[HIZ2|WorkQueue]]  | 4 | high | perf | Test and debug depth->hiz resolve hooks (single ctx, no mipmaps). | [[ChadVersace|ChadVersace]] | [[ChadVersace|ChadVersace]] |  
+<a name="HIZ5"></a>HIZ5 (Done) | [[HIZ3|WorkQueue]] [[HIZ4|WorkQueue]]  | 4 | high | perf | Test and debug multi-context resolve hooks. | [[ChadVersace|ChadVersace]] | [[ChadVersace|ChadVersace]] |  
+<a name="HIZ6"></a>HIZ6 (Done) |    | 5 | med | perf | Fast clear | [[ChadVersace|ChadVersace]] | [[ChadVersace|ChadVersace]] |  
+<a name="HIZ7"></a>HIZ7 (Done) | [[HIZ3|WorkQueue]] [[HIZ4|WorkQueue]]  | 4 | high | perf | Resolve mipmap depth textures. | [[ChadVersace|ChadVersace]] | [[ChadVersace|ChadVersace]] |  
+<a name="GLSL1"></a>GLSL1 (Done) |    | 1 | med | GL 3.0 | Generate errors for integer literals that are out of bounds | [[ChadVersace|ChadVersace]] | [[EricAnholt|EricAnholt]] |  
+<a name="GLSL2"></a>GLSL2 (Done) |    | 3 | med | GL 3.0 | Add `gl_VertexID` and related global variables | [[ChadVersace|ChadVersace]] | [[IanRomanick|IanRomanick]] | Finished by Ian in 2010
+<a name="GLSL3"></a>GLSL3 (Done) |    | 2 | med | GL 3.0 | Add opcodes for `isinf` and `isnan` | [[IanRomanick|IanRomanick]] | [[PaulBerry|PaulBerry]] | Proved to be unnecessary
+<a name="GLSL4"></a>GLSL4 (Done) | [[GLSL3|WorkQueue]]  | 5 | med | GL 3.0 | Lower `isinf` and `isnan` opcodes to various modes of detection on different hardware | [[IanRomanick|IanRomanick]] | [[PaulBerry|PaulBerry]] | Proved to be unnecessary
+<a name="GLSL5"></a>GLSL5 (Done) | [[TEST3|WorkQueue]]  | 3 | med | GL 3.0 | Add `isinf` and `isnan` built-in functions. | [[IanRomanick|IanRomanick]] | [[PaulBerry|PaulBerry]] |  
+<a name="GLSL6"></a>GLSL6 (Done) |    | 2 | med | GL 3.0 | Implement proper integer division and modulus support. | [[KennethGraunke|KennethGraunke]] | [[KennethGraunke|KennethGraunke]] | Patches on mailing list
+<a name="LINK1"></a>LINK1 |    | 2 | med | GL 3.0 | Generate errors when interpolation qualifiers on `gl_Color` don't match | [[ChadVersace|ChadVersace]] | [[PaulBerry|PaulBerry]] |  
+<a name="LINK2"></a>LINK2 |    | 2 | low | GL 3.0 | Generate errors when precision qualifiers don't match. | [[ChadVersace|ChadVersace]] | [[PaulBerry|PaulBerry]] |  
+<a name="LINK3"></a>LINK3 |    | 3 | med | GL 3.0 | Generate an error when there is an assignment to more than one of `gl_FragColor`, `gl_FragData`, and a user-defined fragment shader output. | [[ChadVersace|ChadVersace]] | [[PaulBerry|PaulBerry]] |  
+<a name="TEX1"></a>TEX1 (Done) |    | 5 | med | GL 3.0 | [[EXT_texture_shared_exponent|http://www.opengl.org/registry/specs/EXT/texture_shared_exponent.txt]] | [[ChadVersace|ChadVersace]] | [[EricAnholt|EricAnholt]] |  
+<a name="TEX2"></a>TEX2 (Done) |    | 1 | med | GL 3.0 | [[EXT_packed_float (texturing)|http://www.opengl.org/registry/specs/EXT/packed_float.txt]] | [[ChadVersace|ChadVersace]] | [[EricAnholt|EricAnholt]] |  
+<a name="TEX2.5"></a>TEX2.5 (Done) |    | 4 | med | GL 3.0 | [[EXT_packed_float (renderbuffer)|http://www.opengl.org/registry/specs/EXT/packed_float.txt]] | Eric Anholt |   |  
+<a name="TEX3"></a>TEX3 (Done) |    | 5 | low | perf | Real half-float texture support | [[ChadVersace|ChadVersace]] |   |  
+<a name="TEX4"></a>TEX4 (Done) |    | 4 | med | GL 3.0 | Floating-point depth buffer support. | [[KennethGraunke|KennethGraunke]] | [[EricAnholt|EricAnholt]] |  
+<a name="TEX5"></a>TEX5 (Done) |    | 3 | med | GL 3.0 | Add 6 [[EXT_texture_integer|http://www.opengl.org/registry/specs/EXT/texture_integer.txt]] entry points | [[IanRomanick|IanRomanick]] | [[BrianPaul|BrianPaul]] |  
+<a name="TEX6"></a>TEX6 (Done) |    | 2 | med | GL 3.0 | Update existing entry points to accept [[EXT_texture_integer|http://www.opengl.org/registry/specs/EXT/texture_integer.txt]] enums | [[IanRomanick|IanRomanick]] | [[BrianPaul|BrianPaul]] |  
+<a name="TEX7"></a>TEX7 (Done) | [[TEX6|WorkQueue]]  | 5 | med | GL 3.0 | Update pixel (texel) transfer paths to support integer textures | [[IanRomanick|IanRomanick]] | [[BrianPaul|BrianPaul]] |  
+<a name="TEX8"></a>TEX8 (Done) |    | 3 | med | GL 3.0 | Add GLSL built-in integer sampler types and functions. | [[IanRomanick|IanRomanick]] | [[KennethGraunke|KennethGraunke]] | Compiler support in place since 2010
+<a name="TEX9) (Done"></a>TEX9 | [[TEX8|WorkQueue]]  | 3 | med | GL 3.0 | 965 back-end support for integer samplers. | [[IanRomanick|IanRomanick]] | [[EricAnholt|EricAnholt]] |  
+<a name="TEX9.1) (Done"></a>TEX9.1 |   | 3 | med | GL 3.0 | integer: clamping and conversion in readback path. | [[EricAnholt|EricAnholt]] |   |  
+<a name="TEX9.2) (Done"></a>TEX9.2 |   | 3 | med | GL 3.0 | integer: [[BlitFramebuffer|BlitFramebuffer]] | [[EricAnholt|EricAnholt]] |   |  
+<a name="TEX9.3) (Done"></a>TEX9.3 (Done) |   | 3 | med | GL 3.0 | integer: [[DrawPixels|DrawPixels]] | [[EricAnholt|EricAnholt]] | [[EricAnholt|EricAnholt]] |  
+<a name="TEX9.3) (Done"></a>TEX9.4 |   | 3 | med | GL 3.0 | integer: [[CopyPixels|CopyPixels]] | [[EricAnholt|EricAnholt]] |   |  
+<a name="TEX10"></a>TEX10 (Done) |    | 5 | med | GL 3.0 | Test 3.0 spec section "Required Texture Formats" | [[EricAnholt|EricAnholt]] | [[EricAnholt|EricAnholt]] |  
+<a name="TEX11"></a>TEX11 (Done) |    | 5 | med | GL 3.0 | Test 3.0 spec section "Required Framebuffer Formats" | [[EricAnholt|EricAnholt]] | [[EricAnholt|EricAnholt]] |  
+<a name="VSTEX"></a>VSTEX (Done) | [[VS12|WorkQueue]]  | 10 | high | GL 3.0 | Implement Vertex Shader Texturing | [[KennethGraunke|KennethGraunke]] | [[KennethGraunke|KennethGraunke]] | Upstream; still need piles more tests.
+<a name="VS1"></a>VS1 (Done) |    | 5 | high | perf | i965 vertex shader “first triangle” | [[EricAnholt|EricAnholt]] |   |  
+<a name="VS2"></a>VS2 (Done) |    | 5 | high | perf | Register allocator | [[EricAnholt|EricAnholt]] |   |  
+<a name="VS3"></a>VS3 (Done) |    | 5 | high | perf | Assignment handling | [[EricAnholt|EricAnholt]] |   |  
+<a name="VS4"></a>VS4 (Done) |    | 5 | high | perf | Copy propagation | [[EricAnholt|EricAnholt]] | [[EricAnholt|EricAnholt]] |  ||
+<a name="VS5"></a>VS5 |    | 5 | high | perf | Dead code elimination | [[EricAnholt|EricAnholt]] |   |  
+<a name="VS6"></a>VS6 (Done) |    | 5 | high | perf | Uniform arrays | [[EricAnholt|EricAnholt]] | [[EricAnholt|EricAnholt]] |  
+<a name="VS7"></a>VS7 (Done) | [[GLSL2|WorkQueue]]  | 5 | high | perf | Support built-in `gl_VertexID` in i965 vertex shader back-end | [[EricAnholt|EricAnholt]] | [[EricAnholt|EricAnholt]] |  
+<a name="VS8"></a>VS8 (Done) |    | 5 | high | perf | Compute to MRF | [[EricAnholt|EricAnholt]] | [[EricAnholt|EricAnholt]] |  
+<a name="VS9"></a>VS9 (Done) |    | 5 | high | perf | Constant propagation | [[EricAnholt|EricAnholt]] | [[EricAnholt|EricAnholt]] |  
+<a name="VS10"></a>VS10 |    | 5 | med | perf | Instruction scheduling | [[EricAnholt|EricAnholt]] |   |  
+<a name="VS11"></a>VS11 (Done) |    | 5 | high | perf | Large URB entries | [[EricAnholt|EricAnholt]] |   |  
+<a name="VS12"></a>VS12 (Done) |    | 5 | high | perf | New VS backend on by default | [[EricAnholt|EricAnholt]] | [[EricAnholt|EricAnholt]] |  
+<a name="PERF1"></a>PERF1 |    | 3 | low | perf | IVB conditional rendering support | [[EricAnholt|EricAnholt]] |   |  
+<a name="PERF2"></a>PERF2 |    | 10 | med | perf | Kernel domain tracking lobotomy | [[EricAnholt|EricAnholt]] | [[EricAnholt|EricAnholt]] |  
+<a name="PERF3"></a>PERF3 |    | 10 | high | perf | Non-blocking [[ARB_map_buffer_range|http://www.opengl.org/registry/specs/ARB/map_buffer_range.txt]] | [[EricAnholt|EricAnholt]] | [[BenWidawski|BenWidawski]] |  
+<a name="PERF4"></a>PERF4 (Done) | [[RBMAP4|WorkQueue]]  | 3 | high | perf | Uncached -> cached map blits | [[EricAnholt|EricAnholt]] | [[EricAnholt|EricAnholt]] |  
+<a name="PERF5"></a>PERF5 |    | 3 | med | perf | Kernel GFDT testing | [[EricAnholt|EricAnholt]] |   |  
+<a name="PERF6"></a>PERF6 |    | 5 | low | perf | Guardband clipping | [[EricAnholt|EricAnholt]] |   |  
+<a name="PERF7"></a>PERF7 |    | 5 | med | perf | GLSL expression CSE | [[EricAnholt|EricAnholt]] |   |  
+<a name="PERF8"></a>PERF8 |    | 5 | med | perf | GLSL texture operation CSE | [[EricAnholt|EricAnholt]] |   |  
+<a name="PERF9.1"></a>PERF9.1 |    | 3 | low | perf | Hack in the constant color write and analyze performance impact | [[EricAnholt|EricAnholt]] |   |  
+<a name="PERF9.2"></a>PERF9.2 | [[PERF9.1|WorkQueue]]  | 5 | low | perf | Detect glClear constant color writes and emit correct constant color write code | [[EricAnholt|EricAnholt]] |   |  
+<a name="PERF10.1"></a>PERF10.1 |    | 5 | med | perf | Fragment shader uniform array indexing.  Plumb in reladdrs and fix up optimization to know about them. | [[EricAnholt|EricAnholt]] |   |  
+<a name="PERF10.2"></a>PERF10.2 | [[PERF10.1|WorkQueue]]  | 5 | med | perf | Get the send message working for loading uniforms | [[EricAnholt|EricAnholt]] |   |  
+<a name="PERF11"></a>PERF11 |    | 5 | med | perf | Meta-ops winsys -> texture bind hook | [[EricAnholt|EricAnholt]] |   |  
+<a name="PERF12"></a>PERF12 | [[PERF11|WorkQueue]]  | 5 | med | perf | glCopyTexImage from winsys | [[EricAnholt|EricAnholt]] |   |  
+<a name="PERF13"></a>PERF13 | [[PERF11|WorkQueue]]  | 5 | med | perf | glBlitFramebuffer from winsys | [[EricAnholt|EricAnholt]] |   |  
+<a name="PERF14"></a>PERF14 (Done) |    | 3 | med | perf | FS assignment handling rework. Port over the lesson from VS assignment handling, revert the old mess. | [[EricAnholt|EricAnholt]] | [[KennethGraunke|KennethGraunke]] | 
+<a name="FFS1"></a>FFS1 (Done) |    | 5 | high | perf | Finish fixed-function fragment shader support | [[EricAnholt|EricAnholt]] |   | High priority because the work is mostly done.
+<a name="FFS2"></a>FFS2 |    | 5 | high | perf | Get glxgears running in fixed-function vertex shader conversion | [[EricAnholt|EricAnholt]] |   | High priority because the work is mostly done.
+<a name="FFS3"></a>FFS3 | [[FFS2|WorkQueue]]  | 5 | high | perf | Make sure fixed-function vertex shader conversion doesn't regress softpipe | [[EricAnholt|EricAnholt]] |   |  
+<a name="FFS4"></a>FFS4 | [[FFS2|WorkQueue]] [[VS12|WorkQueue]]  | 5 | high | perf | Make sure fixed-function vertex shader conversion doesn't regress i965 VS | [[EricAnholt|EricAnholt]] |   |  
+<a name="RBMAP1"></a>RBMAP1 (Done) |    | 10 | med | perf | Renderbuffer mapping hook.  This includes nouveau and radeon, unfortunately.  It also includes getting public support for dropping DRI1 drivers from the tree. | [[EricAnholt|EricAnholt]] | [[EricAnholt|EricAnholt]] |  
+<a name="RBMAP2"></a>RBMAP2 | [[RBMAP1|WorkQueue]]  | 5 | low | perf | swrast render-buffer color mapping | [[EricAnholt|EricAnholt]] |   |  
+<a name="RBMAP3"></a>RBMAP3 | [[RBMAP1|WorkQueue]]  | 5 | low | perf | swrast render-buffer depth mapping | [[EricAnholt|EricAnholt]] |   |  
+<a name="RBMAP4"></a>RBMAP4 (Done) | [[RBMAP1|WorkQueue]]  | 5 | med | perf | swrast glReadPixels mapping | [[EricAnholt|EricAnholt]] | [[EricAnholt|EricAnholt]] |  
+<a name="RBMAP5"></a>RBMAP5 | [[RBMAP1|WorkQueue]]  | 5 | low | perf | swrast glDrawPixels mapping | [[EricAnholt|EricAnholt]] |   |  
+<a name="RBMAP6"></a>RBMAP6 | [[RBMAP1|WorkQueue]]  | 5 | low | perf | swrast stencil mapping | [[EricAnholt|EricAnholt]] |   |  
+<a name="RBMAP7"></a>RBMAP7 |    | 3 | med | perf | Accumulation buffer tests | [[EricAnholt|EricAnholt]] |   |  
+<a name="RBMAP8"></a>RBMAP8 (Done) | [[RBMAP1|WorkQueue]]  | 5 | low | perf | swrast accumulation buffer mapping | [[EricAnholt|EricAnholt]] | [[BrianPaul|BrianPaul]] |  
+<a name="RBMAP9"></a>RBMAP9 (Done) | [[RBMAP1|WorkQueue]]  | 5 | low | perf | swrast clear mapping | [[EricAnholt|EricAnholt]] | [[BrianPaul|BrianPaul]] |  
+<a name="CUBE1"></a>CUBE1 (Done) |    | 3 | med | GL 3.0 | Allow glTexImage2D and glCopyTexImage2D with a depth component cube map | [[IanRomanick|IanRomanick]] | [[AnujPhogat|AnujPhogat]] |  
+<a name="CUBE2"></a>CUBE2 | [[CUBE1|WorkQueue]]  | 5 | med | GL 3.0 | Enable back-end generation of cube shadow samplers | [[IanRomanick|IanRomanick]] | [[AnujPhogat|AnujPhogat]] |  
+<a name="CUBE3"></a>CUBE3 (Done) | [[CUBE2|WorkQueue]]  | 10 | med | GL 3.0 | Figure out what AMD & NVIDIA do for fixed-function cube shadows and imitate that. | [[IanRomanick|IanRomanick]] | [[AnujPhogat|AnujPhogat]] | NVIDIA and AMD each do something different, so undefined is undefined.  There's nothing to do here.
+<a name="ARRAY"></a>ARRAY (Done) |    | 5 | ? | GL 3.0 | Finish support for [[ARB_texture_array|http://www.opengl.org/registry/specs/ARB/texture_array.txt]] | [[EricAnholt|EricAnholt]] | [[EricAnholt|EricAnholt]] |  
+<a name="CB1"></a>CB1 (Done) |    | 3 | low | GL 3.0 | Verify error code generation for `glClearBuffer`* | [[IanRomanick|IanRomanick]] | [[IanRomanick|IanRomanick]] |  
+<a name="CB2"></a>CB2 (Done) |    | 3 | med | GL 3.0 | Verify depth clears with `glClearBuffer`* | [[IanRomanick|IanRomanick]] | [[IanRomanick|IanRomanick]] |  
+<a name="CB3"></a>CB3 (Done) |    | 3 | med | GL 3.0 | Verify stencil clears with `glClearBuffer`* | [[IanRomanick|IanRomanick]] | [[IanRomanick|IanRomanick]] |  
+<a name="CB4"></a>CB4 |    | 3 | med | GL 3.0 | Verify mixed format color buffer clears with `glClearBuffer`* | [[IanRomanick|IanRomanick]] |   |  
+<a name="CB5"></a>CB5 |    | 3 | med | GL 3.0 | Verify that `glClearBuffer`* can be compiled into display lists | [[IanRomanick|IanRomanick]] |   |  
+<a name="CC1"></a>CC1 |    | 5 | med | GL 3.0 | Implement GLX protocol for `SetClientInfo` (client & server) | [[IanRomanick|IanRomanick]] | [[IanRomanick|IanRomanick]] | The client bits are mostly done on the GLX_ARB_create_context branch of my Mesa tree.  XCB patches heading to the list soon.
+<a name="CC2"></a>CC2 | [[CC1|WorkQueue]]  | 5 | med | GL 3.0 | Implement GLX protocol for `CreateContextAttribs` | [[IanRomanick|IanRomanick]] | [[IanRomanick|IanRomanick]] |  
+<a name="CC3"></a>CC3 | [[CC2|WorkQueue]]  | 3 | med | GL 3.0 | Implement DRI2 `createContext2` interface that sends the attributes to the driver. | [[IanRomanick|IanRomanick]] | [[IanRomanick|IanRomanick]] |  
+<a name="CC4"></a>CC4 | [[CC3|WorkQueue]]  | 3 | med | GL 3.0 | Add support for the DRI2 `createContext2` interface to the Intel drivers. | [[IanRomanick|IanRomanick]] | [[IanRomanick|IanRomanick]] |  
+<a name="UNI1"></a>UNI1 (Done) |    | 10 | ? | GL 3.0 | Create data structure similar to glsl_type for storing uniform data.  It should contain the original typed data and the float “shadow” for drivers that need that. | [[KennethGraunke|KennethGraunke]] | [[IanRomanick|IanRomanick]] | Patches in the idr-work branch of my personal git repo.
+<a name="UNI2"></a>UNI2 (Done) | [[UNI1|WorkQueue]]  | 5 | ? | GL 3.0 | Create map from uniform names to storage (new structure). | [[KennethGraunke|KennethGraunke]] | [[IanRomanick|IanRomanick]] |  
+<a name="UNI3"></a>UNI3 (Done) | [[UNI2|WorkQueue]]  | 10 | ? | GL 3.0 | Store uniform data in new structure. | [[KennethGraunke|KennethGraunke]] | [[IanRomanick|IanRomanick]] |  
+<a name="UNI4"></a>UNI4 (Done) | [[UNI3|WorkQueue]]  | 10 | ? | GL 3.0 | Make `ir_to_mesa` use the new uniform storage and mapping | [[KennethGraunke|KennethGraunke]] | [[IanRomanick|IanRomanick]] |  
+<a name="UNI5"></a>UNI5 | [[UNI7|WorkQueue]]  | 10 | ? | GL 3.0 | Make `brw_fs` use the new uniform storage and mapping | [[KennethGraunke|KennethGraunke]] |   | With the other work, this will just be an optimization.  It can wait a bit.
+<a name="UNI6"></a>UNI6 | [[UNI4|WorkQueue]]  | ? | ? | GL 3.0 | Split out any remaining uniform handling & resource allocation from `ir_to_mesa` | [[KennethGraunke|KennethGraunke]] | [[IanRomanick|IanRomanick]] |  
+<a name="UNI7"></a>UNI7 | [[UNI6|WorkQueue]]  | ? | ? | GL 3.0 | make `ir_to_mesa` stop generating code for fragment shaders when there is another (hardware) back-end active. | [[KennethGraunke|KennethGraunke]] | [[IanRomanick|IanRomanick]] |  
+<a name="TXF1"></a>TXF1 (Done) |    | 3 | med | GL 3.0 | Add support for the `ir_txf` opcode using the “ld” sampler message in `brw_fs` | [[KennethGraunke|KennethGraunke]] | [[KennethGraunke|KennethGraunke]] |  
+<a name="TXF2"></a>TXF2 (Done) |    | 4 | med | GL 3.0 | Write tests for texelFetch | [[KennethGraunke|KennethGraunke]] | [[DaveAirlie|DaveAirlie]] |  
+<a name="TXS1"></a>TXS1 (Done) |    | 3 | high | GL 3.0 | Merge kwg/txs branch with airlied's patch, and push both. | [[KennethGraunke|KennethGraunke]] |   | High priority because the work is mostly done.
+<a name="TXS2"></a>TXS2 (Done) |    | 3 | high | GL 3.0 | Write tests for textureSize | [[KennethGraunke|KennethGraunke]] |   | Could add more tests
+<a name="TXS3"></a>TXS3 (Done) |    | 3 | med | GL 3.0 | Implement TXS on GEN4 via SIMD16 resinfo message | [[KennethGraunke|KennethGraunke]] |   |  
+"""]]
diff --git a/WorkQueue.moin b/WorkQueue.moin
deleted file mode 100644
index 57d73b0..0000000
--- a/WorkQueue.moin
+++ /dev/null
@@ -1,162 +0,0 @@
-||'''Item ID'''       ||'''Dependencies'''||'''Est. Days'''||'''Priority'''||'''Category'''||'''Description'''||'''Item Author'''||'''Current Owner'''||'''Notes'''||
-||<style="background-color: #00FF00"><<Anchor(XF01)>>XF01 (Done, pending tests)||  ||3||high||GL 3.0||Enhance state tracking for transform feedback||DanMcCabe||DanMcCabe||Previously completed by BrianPaul||
-||<style="background-color: #00FF00"><<Anchor(XF02)>>XF02 (Done, pending tests)||  ||2||high||GL 3.0||Add 9 transform feedback entry points||DanMcCabe||DanMcCabe||Previously completed by BrianPaul||
-||<style="background-color: #00FF00"><<Anchor(XF03)>>XF03 (Done, pending tests)||[[#XF02|XF02]] ||5||high||GL 3.0||Validate parameters in transform feedback entry points||DanMcCabe||DanMcCabe||Previously completed by BrianPaul ||
-||<style="background-color: #00FF00"><<Anchor(XF04)>>XF04 (Done, pending tests)||  ||5||high||GL 3.0||Validate transform feedback related parameters in existing GL entry points||DanMcCabe||DanMcCabe||Previously completed by BrianPaul ||
-||<style="background-color: #00FF00"><<Anchor(XF05)>>XF05 (Done, pending tests)||  ||5||high||GL 3.0||glBindBuffers support for transform feedback||DanMcCabe||DanMcCabe||Previously completed by BrianPaul||
-||<<Anchor(XF06)>>XF06||  ||5||high||GL 3.0||Varying variable support for transform feedback.  This is filling in the guts of glTransformFeedbackVaryings and glGetTransformFeedbackVarying.||DanMcCabe||EricAnholt|| ||
-||<style="background-color: #00FF00"><<Anchor(XF07)>>XF07 (Done, pending tests)||[[#XF06|XF06]] ||5||high||GL 3.0||Enhance linker support for transform feedback||DanMcCabe||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(XF_SNB_1)>>XF_SNB_1 (Done)|| || ||high||GL 3.0||Learn how to test stream output logic in the simulator||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(XF_SNB_2)>>XF_SNB_2 (Done)|| || ||high||GL 3.0||Implement pass-through GS shader program||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(XF_SNB_3)>>XF_SNB_3 (Done)|| || ||high||GL 3.0||Output dummy data to transform feedback buffer||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(XF_SNB_4)>>XF_SNB_4 (Done)|| || ||high||GL 3.0||Output correct data in SEPARATE_ATTRIBS mode||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(XF_SNB_5)>>XF_SNB_5 (Done)|| || ||high||GL 3.0||Output correct data in INTERLEAVED_ATTRIBS mode||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(XF_SNB_6)>>XF_SNB_6 (Done)|| || ||high||GL 3.0||Ensure that buffer overflow behavior is correct||PaulBerry||KennethGraunke|| ||
-||<style="background-color: #00FF00"><<Anchor(XF_SNB_7)>>XF_SNB_7 (Done)|| || ||high||GL 3.0||Update pointers correctly on begin/end/pause/resume||PaulBerry||KennethGraunke|| ||
-||<style="background-color: #00FF00"><<Anchor(XF_SNB_8)>>XF_SNB_8 (Done)|| || ||high||GL 3.0||Implement rasterizer discard||PaulBerry||PaulBerry|| ||
-||<<Anchor(XF_SNB_9)>>XF_SNB_9|| || ||high||GL 3.0||Thoroughly test and debug all SNB XF behavior except queries||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(XF_SNB_10)>>XF_SNB_10 (Done)|| || ||high||GL 3.0||Implement PRIMITIVES_GENERATED and TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN queries||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(XF_SNB_11)>>XF_SNB_11 (Done)|| || ||high||GL 3.0||Test PRIMITIVES_GENERATED and TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN queries||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(XF_IVB_1)>>XF_IVB_1 (Done)|| || ||high||GL 3.0||Kernel interface for setting registers||PaulBerry||EricAnholt|| ||
-||<style="background-color: #00FF00"><<Anchor(XF_IVB_2)>>XF_IVB_2 (Done)|| || ||high||GL 3.0||Output correct data in SEPARATE_ATTRIBS mode||PaulBerry||EricAnholt|| ||
-||<style="background-color: #00FF00"><<Anchor(XF_IVB_3)>>XF_IVB_3 (Done)|| || ||high||GL 3.0||Output correct data in INTERLEAVED_ATTRIBS mode||PaulBerry||EricAnholt|| ||
-||<<Anchor(XF_IVB_4)>>XF_IVB_4|| || ||high||GL 3.0||Ensure that buffer overflow behavior is correct||PaulBerry||EricAnholt|| Should be fine, need to review tests and run them.||
-||<style="background-color: #00FF00"><<Anchor(XF_IVB_5)>>XF_IVB_5 (Done)|| || ||high||GL 3.0||Update pointers correctly on begin/end/pause/resume||PaulBerry|| || Cross-batchbuffer pointers incorrect, need to review tests and implement.||
-||<style="background-color: #00FF00"><<Anchor(XF_IVB_6)>>XF_IVB_6 (Done)|| || ||high||GL 3.0||Implement rasterizer discard||PaulBerry||EricAnholt||(works)||
-||<style="background-color: #00FF00"><<Anchor(XF_IVB_7)>>XF_IVB_7 (Done)|| || ||high||GL 3.0||Thoroughly test and debug all IVB XF behavior except queries||PaulBerry|| || (note: some oglc failures remain, one class may be IVB specific) ||
-||<style="background-color: #00FF00"><<Anchor(XF_IVB_8)>>XF_IVB_8 (Done)|| || ||high||GL 3.0||Implement PRIMITIVES_GENERATED and TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN queries||PaulBerry|| || ||
-||<style="background-color: #00FF00"><<Anchor(XF_IVB_9)>>XF_IVB_9 (Done)|| || ||high||GL 3.0||Test PRIMITIVES_GENERATED and TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN queries||PaulBerry|| || ||
-||<style="background-color: #00FF00"><<Anchor(XF14)>>XF14 (Done)||  ||5||low||GL 3.0||Test input validity||DanMcCabe||EugeniDodonov, PaulBerry||http://cgit.freedesktop.org/~eugeni/piglit/, priority is lowered because Marek's piglit test already covers this partly||
-||<<Anchor(XF15)>>XF15||  ||3||low||GL 3.0||Test buffer binding||DanMcCabe||EugeniDodonov, PaulBerry||http://cgit.freedesktop.org/~eugeni/piglit/, priority is lowered because Marek's piglit test already covers this partly||
-||<style="background-color: #00FF00"><<Anchor(XF16)>>XF16 (Done)||  ||2||high||GL 3.0||Test linking and glUseProgram||DanMcCabe||PaulBerry|| ||
-||<<Anchor(XF17)>>XF17||  ||2||high||GL 3.0||Test tesselation and incomplete primitives||DanMcCabe||Paul Berry||I think this estimate is low.||
-||<<Anchor(XF18)>>XF18||  ||1||high||GL 3.0||Test buffer overflow||DanMcCabe||Paul Berry||I think this estimate is low.||
-||<<Anchor(XF19)>>XF19||  ||3||high||GL 3.0||Test varyings||DanMcCabe||Paul Berry||I think this estimate is low.||
-||<style="background-color: #00FF00"><<Anchor(XF20)>>XF20 (Done)||  ||5||high||GL 3.0||Test output||DanMcCabe||MarekOlsak|| ||
-||<<Anchor(IR1)>>IR1||  ||10||high||perf||Replace context “program” attached state with SSO-style shader state||IanRomanick||IanRomanick|| ||
-||<<Anchor(IR2)>>IR2||[[#IR1|IR1]] ||10||high||perf||Generate GLSL IR for ARB assembly programs||IanRomanick|| || ||
-||<<Anchor(IR3)>>IR3||[[#IR1|IR1]] ||10||high||perf||Generate GLSL IR for NV vertex assembly programs||IanRomanick|| ||There will be a lot of cut-and-paste between IR2 and IR3||
-||<<Anchor(IR4)>>IR4||  ||3||high||perf||Remove NV fragment assembly program support||IanRomanick|| || ||
-||<style="background-color: #00FF00"><<Anchor(CD0)>>CD0 (Done)||  ||10||high||GL 3.0||Refactor VUE layout code in preparation for {{{gl_ClipDistance}}}||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(CD1)>>CD1 (Done)||  ||5||high||GL 3.0||Compiler front-end support for {{{gl_Distance}}}||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(CD2)>>CD2 (Done)||[[#CD1|CD1]] ||5||high||GL 3.0||Lower {{{gl_ClipDistance}}} from float[8] to vec4[2]||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(CD3)>>CD3 (Done)||[[#CD2|CD2]] ||5||high||GL 3.0||Test {{{gl_ClipDistance}}} lowering pass||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(CD4)>>CD4 (Done)||[[#CD3|CD3]] ||5||high||GL 3.0||SNB support for {{{gl_ClipDistance}}}||PaulBerry||PaulBerry||"First triangle" achieved on private branch 9/2||
-||<style="background-color: #00FF00"><<Anchor(CD5)>>CD5 (Done)||[[#CD1|CD1]] ||3||med||GL 3.0||Emit error if a shader writes both {{{gl_ClipDistance}}} and {{{gl_ClipVertex}}}||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(CD6)>>CD6 (Done)||  ||5||high||GL 3.0||Add {{{gl_ClipDistance}}} as a fragment shader built-in input||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(CD7)>>CD7 (Done)||  ||5||high||GL 3.0||Implement and test {{{gl_ClipDistance}}} sizing rules||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(CD8)>>CD8 (Done)||  ||3||high||GL 3.0||{{{gl_ClipDistance}}} tests||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(CV1)>>CV1 (Done)||  ||5||med||GL 2.x||Add gl_vert_result slot for {{{gl_ClipVertex}}}||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(CV2)>>CV2 (Done)|| ||5||med||GL 2.x||Detect writes to {{{gl_ClipVertex}}} in the linker||PaulBerry||PaulBerry||Proved to be unnecessary||
-||<<Anchor(CV3)>>CV3||[[#CV2|CV2]] ||3||low||GL 2.x||Use proper slot for writes to {{{gl_ClipVertex}}} (i915)||PaulBerry|| || ||
-||<<Anchor(CV4)>>CV4||[[#CV2|CV2]] ||3||low||GL 2.x||Use proper slot for writes to {{{gl_ClipVertex}}} (i965, pre-SNB)||PaulBerry|| || ||
-||<style="background-color: #00FF00"><<Anchor(CV5)>>CV5 (Done)||[[#CV2|CV2]] ||3||low||GL 2.x||Use proper slot for writes to {{{gl_ClipVertex}}} (i965, SNB+)||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(CV6)>>CV6 (Done)||  ||3||low||GL 2.x||{{{gl_ClipVertex}}} tests||PaulBerry||PaulBerry||These could be co-developed w/CD8||
-||<style="background-color: #00FF00"><<Anchor(HTRIG1)>>HTRIG1 (Done)||  ||2||med||GL 3.0||Test GLSL 1.30 hyperbolic trig functions||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(HTRIG2)>>HTRIG2 (Done)||[[#VS12|VS12]] ||3||med||GL 3.0||Fix GLSL 1.30 hyperbolic trig functions||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(TEST1)>>TEST1 (Done)||  ||5||med||GL 3.0||Adapt built-in tests for new unsigned types (vector and scalar)||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(TEST2)>>TEST2 (Done)||  ||3||med||GL 3.0||Adapt built-in tests to test operators||PaulBerry||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(TEST3)>>TEST3 (Done)||[[#TEST6|TEST6]]  ||3||med||GL 3.0||Test {{{isinf}}} and {{{isnan}}}||PaulBerry||PaulBerry||Depends on TEST6 because otherwise interpolation turns infinities into NaNs||
-||<style="background-color: #00FF00"><<Anchor(TEST4)>>TEST4 (Done)||  ||3||med||GL 3.0||Test {{{noperspective}}} interpolation qualifier.||ChadVersace||PaulBerry|| ||
-||<<Anchor(TEST5)>>TEST5||  ||3||med||GL 3.0||Test {{{centroid}}} interpolation qualifier.||ChadVersace||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(TEST6)>>TEST6 (Done)||  ||3||med||GL 3.0||Test flat interpolation qualifier.||ChadVersace||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(TEST7)>>TEST7 (Done)||  ||1||med||GL 3.0||Shader inputs are read-only.  We already mark global inputs as ro, but have no tests for it.||ChadVersace||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(HIZ1)>>HIZ1 (Done)||  ||5||high||perf||Write resolve meta-ops for hiz->depth and depth->hiz||ChadVersace||ChadVersace|| ||
-||<style="background-color: #00FF00"><<Anchor(HIZ2)>>HIZ2 (Done)||  ||5||high||perf||Hook resolves into texture & draw functions (no mipmaps yet)||ChadVersace||ChadVersace|| ||
-||<style="background-color: #00FF00"><<Anchor(HIZ3)>>HIZ3 (Done)||[[#HIZ2|HIZ2]] ||4||high||perf||Test and debug hiz->depth resolve hooks (single ctx, no mipmaps).||ChadVersace||ChadVersace|| ||
-||<style="background-color: #00FF00"><<Anchor(HIZ4)>>HIZ4 (Done)||[[#HIZ2|HIZ2]] ||4||high||perf||Test and debug depth->hiz resolve hooks (single ctx, no mipmaps).||ChadVersace||ChadVersace|| ||
-||<style="background-color: #00FF00"><<Anchor(HIZ5)>>HIZ5 (Done)||[[#HIZ3|HIZ3]] [[# HIZ4| HIZ4]] ||4||high||perf||Test and debug multi-context resolve hooks.||ChadVersace||ChadVersace|| ||
-||<style="background-color: #00FF00"><<Anchor(HIZ6)>>HIZ6 (Done)||  ||5||med||perf||Fast clear||ChadVersace||ChadVersace|| ||
-||<style="background-color: #00FF00"><<Anchor(HIZ7)>>HIZ7 (Done)||[[#HIZ3|HIZ3]] [[#HIZ4|HIZ4]] ||4||high||perf||Resolve mipmap depth textures.||ChadVersace||ChadVersace|| ||
-||<style="background-color: #00FF00"><<Anchor(GLSL1)>>GLSL1 (Done)||  ||1||med||GL 3.0||Generate errors for integer literals that are out of bounds||ChadVersace||EricAnholt|| ||
-||<style="background-color: #00FF00"><<Anchor(GLSL2)>>GLSL2 (Done)||  ||3||med||GL 3.0||Add {{{gl_VertexID}}} and related global variables||ChadVersace||IanRomanick||Finished by Ian in 2010||
-||<style="background-color: #00FF00"><<Anchor(GLSL3)>>GLSL3 (Done)||  ||2||med||GL 3.0||Add opcodes for {{{isinf}}} and {{{isnan}}}||IanRomanick||PaulBerry||Proved to be unnecessary||
-||<style="background-color: #00FF00"><<Anchor(GLSL4)>>GLSL4 (Done)||[[#GLSL3|GLSL3]] ||5||med||GL 3.0||Lower {{{isinf}}} and {{{isnan}}} opcodes to various modes of detection on different hardware||IanRomanick||PaulBerry||Proved to be unnecessary||
-||<style="background-color: #00FF00"><<Anchor(GLSL5)>>GLSL5 (Done)||[[#TEST3|TEST3]] ||3||med||GL 3.0||Add {{{isinf}}} and {{{isnan}}} built-in functions.||IanRomanick||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(GLSL6)>>GLSL6 (Done)||  ||2||med||GL 3.0||Implement proper integer division and modulus support.||KennethGraunke||KennethGraunke||Patches on mailing list||
-||<<Anchor(LINK1)>>LINK1||  ||2||med||GL 3.0||Generate errors when interpolation qualifiers on {{{gl_Color}}} don't match||ChadVersace||PaulBerry|| ||
-||<<Anchor(LINK2)>>LINK2||  ||2||low||GL 3.0||Generate errors when precision qualifiers don't match.||ChadVersace||PaulBerry|| ||
-||<<Anchor(LINK3)>>LINK3||  ||3||med||GL 3.0||Generate an error when there is an assignment to more than one of {{{gl_FragColor}}}, {{{gl_FragData}}}, and a user-defined fragment shader output.||ChadVersace||PaulBerry|| ||
-||<style="background-color: #00FF00"><<Anchor(TEX1)>>TEX1 (Done)||  ||5||med||GL 3.0||[[http://www.opengl.org/registry/specs/EXT/texture_shared_exponent.txt|EXT_texture_shared_exponent]]||ChadVersace||EricAnholt|| ||
-||<style="background-color: #00FF00"><<Anchor(TEX2)>>TEX2 (Done)||  ||1||med||GL 3.0||[[http://www.opengl.org/registry/specs/EXT/packed_float.txt|EXT_packed_float (texturing)]]||ChadVersace||EricAnholt|| ||
-||<style="background-color: #00FF00"><<Anchor(TEX2.5)>>TEX2.5 (Done)||  ||4||med||GL 3.0||[[http://www.opengl.org/registry/specs/EXT/packed_float.txt|EXT_packed_float (renderbuffer)]]||Eric Anholt|| || ||
-||<style="background-color: #00FF00"><<Anchor(TEX3)>>TEX3 (Done)||  ||5||low||perf||Real half-float texture support||ChadVersace|| || ||
-||<style="background-color: #00FF00"><<Anchor(TEX4)>>TEX4 (Done)||  ||4||med||GL 3.0||Floating-point depth buffer support.||KennethGraunke||EricAnholt|| ||
-||<style="background-color: #00FF00"><<Anchor(TEX5)>>TEX5 (Done)||  ||3||med||GL 3.0||Add 6 [[http://www.opengl.org/registry/specs/EXT/texture_integer.txt|EXT_texture_integer]] entry points||IanRomanick||BrianPaul|| ||
-||<style="background-color: #00FF00"><<Anchor(TEX6)>>TEX6 (Done)||  ||2||med||GL 3.0||Update existing entry points to accept [[http://www.opengl.org/registry/specs/EXT/texture_integer.txt|EXT_texture_integer]] enums||IanRomanick||BrianPaul|| ||
-||<style="background-color: #00FF00"><<Anchor(TEX7)>>TEX7 (Done)||[[#TEX6|TEX6]] ||5||med||GL 3.0||Update pixel (texel) transfer paths to support integer textures||IanRomanick||BrianPaul|| ||
-||<style="background-color: #00FF00"><<Anchor(TEX8)>>TEX8 (Done)||  ||3||med||GL 3.0||Add GLSL built-in integer sampler types and functions.||IanRomanick||KennethGraunke||Compiler support in place since 2010||
-||<style="background-color: #00FF00"><<Anchor(TEX9) (Done)>>TEX9||[[#TEX8|TEX8]] ||3||med||GL 3.0||965 back-end support for integer samplers.||IanRomanick||EricAnholt|| ||
-||<<Anchor(TEX9.1) (Done)>>TEX9.1|| ||3||med||GL 3.0||integer: clamping and conversion in readback path.||EricAnholt|| || ||
-||<<Anchor(TEX9.2) (Done)>>TEX9.2|| ||3||med||GL 3.0||integer: BlitFramebuffer||EricAnholt|| || ||
-||<style="background-color: #00FF00"><<Anchor(TEX9.3) (Done)>>TEX9.3 (Done)|| ||3||med||GL 3.0||integer: DrawPixels||EricAnholt||EricAnholt|| ||
-||<<Anchor(TEX9.3) (Done)>>TEX9.4|| ||3||med||GL 3.0||integer: CopyPixels||EricAnholt|| || ||
-||<style="background-color: #00FF00"><<Anchor(TEX10)>>TEX10 (Done)||  ||5||med||GL 3.0||Test 3.0 spec section "Required Texture Formats"||EricAnholt||EricAnholt|| ||
-||<style="background-color: #00FF00"><<Anchor(TEX11)>>TEX11 (Done)||  ||5||med||GL 3.0||Test 3.0 spec section "Required Framebuffer Formats"||EricAnholt||EricAnholt|| ||
-||<style="background-color: #00FF00"><<Anchor(VSTEX)>>VSTEX (Done)||[[#VS12|VS12]] ||10||high||GL 3.0||Implement Vertex Shader Texturing||KennethGraunke||KennethGraunke||Upstream; still need piles more tests.||
-||<style="background-color: #00FF00"><<Anchor(VS1)>>VS1 (Done)||  ||5||high||perf||i965 vertex shader “first triangle”||EricAnholt|| || ||
-||<style="background-color: #00FF00"><<Anchor(VS2)>>VS2 (Done)||  ||5||high||perf||Register allocator||EricAnholt|| || ||
-||<style="background-color: #00FF00"><<Anchor(VS3)>>VS3 (Done)||  ||5||high||perf||Assignment handling||EricAnholt|| || ||
-||<style="background-color: #00FF00"><<Anchor(VS4)>>VS4 (Done)||  ||5||high||perf||Copy propagation||EricAnholt||EricAnholt|||| ||
-||<<Anchor(VS5)>>VS5||  ||5||high||perf||Dead code elimination||EricAnholt|| || ||
-||<style="background-color: #00FF00"><<Anchor(VS6)>>VS6 (Done)||  ||5||high||perf||Uniform arrays||EricAnholt||EricAnholt|| ||
-||<style="background-color: #00FF00"><<Anchor(VS7)>>VS7 (Done)||[[#GLSL2|GLSL2]] ||5||high||perf||Support built-in {{{gl_VertexID}}} in i965 vertex shader back-end||EricAnholt||EricAnholt|| ||
-||<style="background-color: #00FF00"><<Anchor(VS8)>>VS8 (Done)||  ||5||high||perf||Compute to MRF||EricAnholt||EricAnholt|| ||
-||<style="background-color: #00FF00"><<Anchor(VS9)>>VS9 (Done)||  ||5||high||perf||Constant propagation||EricAnholt||EricAnholt|| ||
-||<<Anchor(VS10)>>VS10||  ||5||med||perf||Instruction scheduling||EricAnholt|| || ||
-||<style="background-color: #00FF00"><<Anchor(VS11)>>VS11 (Done)||  ||5||high||perf||Large URB entries||EricAnholt|| || ||
-||<style="background-color: #00FF00"><<Anchor(VS12)>>VS12 (Done)||  ||5||high||perf||New VS backend on by default||EricAnholt||EricAnholt|| ||
-||<<Anchor(PERF1)>>PERF1||  ||3||low||perf||IVB conditional rendering support||EricAnholt|| || ||
-||<<Anchor(PERF2)>>PERF2||  ||10||med||perf||Kernel domain tracking lobotomy||EricAnholt||EricAnholt|| ||
-||<<Anchor(PERF3)>>PERF3||  ||10||high||perf||Non-blocking [[http://www.opengl.org/registry/specs/ARB/map_buffer_range.txt|ARB_map_buffer_range]]||EricAnholt||BenWidawski|| ||
-||<style="background-color: #00FF00"><<Anchor(PERF4)>>PERF4 (Done)||[[#RBMAP4|RBMAP4]] ||3||high||perf||Uncached -> cached map blits||EricAnholt||EricAnholt|| ||
-||<<Anchor(PERF5)>>PERF5||  ||3||med||perf||Kernel GFDT testing||EricAnholt|| || ||
-||<<Anchor(PERF6)>>PERF6||  ||5||low||perf||Guardband clipping||EricAnholt|| || ||
-||<<Anchor(PERF7)>>PERF7||  ||5||med||perf||GLSL expression CSE||EricAnholt|| || ||
-||<<Anchor(PERF8)>>PERF8||  ||5||med||perf||GLSL texture operation CSE||EricAnholt|| || ||
-||<<Anchor(PERF9.1)>>PERF9.1||  ||3||low||perf||Hack in the constant color write and analyze performance impact||EricAnholt|| || ||
-||<<Anchor(PERF9.2)>>PERF9.2||[[#PERF9.1|PERF9.1]] ||5||low||perf||Detect glClear constant color writes and emit correct constant color write code||EricAnholt|| || ||
-||<<Anchor(PERF10.1)>>PERF10.1||  ||5||med||perf||Fragment shader uniform array indexing.  Plumb in reladdrs and fix up optimization to know about them.||EricAnholt|| || ||
-||<<Anchor(PERF10.2)>>PERF10.2||[[#PERF10.1|PERF10.1]] ||5||med||perf||Get the send message working for loading uniforms||EricAnholt|| || ||
-||<<Anchor(PERF11)>>PERF11||  ||5||med||perf||Meta-ops winsys -> texture bind hook||EricAnholt|| || ||
-||<<Anchor(PERF12)>>PERF12||[[#PERF11|PERF11]] ||5||med||perf||glCopyTexImage from winsys||EricAnholt|| || ||
-||<<Anchor(PERF13)>>PERF13||[[#PERF11|PERF11]] ||5||med||perf||glBlitFramebuffer from winsys||EricAnholt|| || ||
-||<style="background-color: #00FF00"><<Anchor(PERF14)>>PERF14 (Done)||  ||3||med||perf||FS assignment handling rework. Port over the lesson from VS assignment handling, revert the old mess.||EricAnholt||KennethGraunke||||
-||<style="background-color: #00FF00"><<Anchor(FFS1)>>FFS1 (Done)||  ||5||high||perf||Finish fixed-function fragment shader support||EricAnholt|| ||High priority because the work is mostly done.||
-||<<Anchor(FFS2)>>FFS2||  ||5||high||perf||Get glxgears running in fixed-function vertex shader conversion||EricAnholt|| ||High priority because the work is mostly done.||
-||<<Anchor(FFS3)>>FFS3||[[#FFS2|FFS2]] ||5||high||perf||Make sure fixed-function vertex shader conversion doesn't regress softpipe||EricAnholt|| || ||
-||<<Anchor(FFS4)>>FFS4||[[#FFS2|FFS2]] [[# VS12| VS12]] ||5||high||perf||Make sure fixed-function vertex shader conversion doesn't regress i965 VS||EricAnholt|| || ||
-||<style="background-color: #00FF00"><<Anchor(RBMAP1)>>RBMAP1 (Done)||  ||10||med||perf||Renderbuffer mapping hook.  This includes nouveau and radeon, unfortunately.  It also includes getting public support for dropping DRI1 drivers from the tree.||EricAnholt||EricAnholt|| ||
-||<<Anchor(RBMAP2)>>RBMAP2||[[#RBMAP1|RBMAP1]] ||5||low||perf||swrast render-buffer color mapping||EricAnholt|| || ||
-||<<Anchor(RBMAP3)>>RBMAP3||[[#RBMAP1|RBMAP1]] ||5||low||perf||swrast render-buffer depth mapping||EricAnholt|| || ||
-||<style="background-color: #00FF00"><<Anchor(RBMAP4)>>RBMAP4 (Done)||[[#RBMAP1|RBMAP1]] ||5||med||perf||swrast glReadPixels mapping||EricAnholt||EricAnholt|| ||
-||<<Anchor(RBMAP5)>>RBMAP5||[[#RBMAP1|RBMAP1]] ||5||low||perf||swrast glDrawPixels mapping||EricAnholt|| || ||
-||<<Anchor(RBMAP6)>>RBMAP6||[[#RBMAP1|RBMAP1]] ||5||low||perf||swrast stencil mapping||EricAnholt|| || ||
-||<<Anchor(RBMAP7)>>RBMAP7||  ||3||med||perf||Accumulation buffer tests||EricAnholt|| || ||
-||<style="background-color: #00FF00"><<Anchor(RBMAP8)>>RBMAP8 (Done)||[[#RBMAP1|RBMAP1]] ||5||low||perf||swrast accumulation buffer mapping||EricAnholt||BrianPaul|| ||
-||<style="background-color: #00FF00"><<Anchor(RBMAP9)>>RBMAP9 (Done)||[[#RBMAP1|RBMAP1]] ||5||low||perf||swrast clear mapping||EricAnholt||BrianPaul|| ||
-||<style="background-color: #00FF00"><<Anchor(CUBE1)>>CUBE1 (Done)||  ||3||med||GL 3.0||Allow glTexImage2D and glCopyTexImage2D with a depth component cube map||IanRomanick||AnujPhogat|| ||
-||<style="background-color: #00FF00"><<Anchor(CUBE2)>>CUBE2||[[#CUBE1|CUBE1]] ||5||med||GL 3.0||Enable back-end generation of cube shadow samplers||IanRomanick||AnujPhogat|| ||
-||<style="background-color: #00FF00"><<Anchor(CUBE3)>>CUBE3 (Done)||[[#CUBE2|CUBE2]] ||10||med||GL 3.0||Figure out what AMD & NVIDIA do for fixed-function cube shadows and imitate that.||IanRomanick||AnujPhogat||NVIDIA and AMD each do something different, so undefined is undefined.  There's nothing to do here.||
-||<style="background-color: #00FF00"><<Anchor(ARRAY)>>ARRAY (Done)||  ||5||?||GL 3.0||Finish support for [[http://www.opengl.org/registry/specs/ARB/texture_array.txt|ARB_texture_array]]||EricAnholt||EricAnholt|| ||
-||<style="background-color: #00FF00"><<Anchor(CB1)>>CB1 (Done)||  ||3||low||GL 3.0||Verify error code generation for {{{glClearBuffer}}}*||IanRomanick||IanRomanick|| ||
-||<style="background-color: #00FF00"><<Anchor(CB2)>>CB2 (Done)||  ||3||med||GL 3.0||Verify depth clears with {{{glClearBuffer}}}*||IanRomanick||IanRomanick|| ||
-||<style="background-color: #00FF00"><<Anchor(CB3)>>CB3 (Done)||  ||3||med||GL 3.0||Verify stencil clears with {{{glClearBuffer}}}*||IanRomanick||IanRomanick|| ||
-||<<Anchor(CB4)>>CB4||  ||3||med||GL 3.0||Verify mixed format color buffer clears with {{{glClearBuffer}}}*||IanRomanick|| || ||
-||<<Anchor(CB5)>>CB5||  ||3||med||GL 3.0||Verify that {{{glClearBuffer}}}* can be compiled into display lists||IanRomanick|| || ||
-||<<Anchor(CC1)>>CC1||  ||5||med||GL 3.0||Implement GLX protocol for {{{SetClientInfo}}} (client & server)||IanRomanick||IanRomanick||The client bits are mostly done on the GLX_ARB_create_context branch of my Mesa tree.  XCB patches heading to the list soon.||
-||<<Anchor(CC2)>>CC2||[[#CC1|CC1]] ||5||med||GL 3.0||Implement GLX protocol for {{{CreateContextAttribs}}}||IanRomanick||IanRomanick|| ||
-||<<Anchor(CC3)>>CC3||[[#CC2|CC2]] ||3||med||GL 3.0||Implement DRI2 {{{createContext2}}} interface that sends the attributes to the driver.||IanRomanick||IanRomanick|| ||
-||<<Anchor(CC4)>>CC4||[[#CC3|CC3]] ||3||med||GL 3.0||Add support for the DRI2 {{{createContext2}}} interface to the Intel drivers.||IanRomanick||IanRomanick|| ||
-||<style="background-color: #00FF00"><<Anchor(UNI1)>>UNI1 (Done)||  ||10||?||GL 3.0||Create data structure similar to glsl_type for storing uniform data.  It should contain the original typed data and the float “shadow” for drivers that need that.||KennethGraunke||IanRomanick||Patches in the idr-work branch of my personal git repo.||
-||<style="background-color: #00FF00"><<Anchor(UNI2)>>UNI2 (Done)||[[#UNI1|UNI1]] ||5||?||GL 3.0||Create map from uniform names to storage (new structure).||KennethGraunke||IanRomanick|| ||
-||<style="background-color: #00FF00"><<Anchor(UNI3)>>UNI3 (Done)||[[#UNI2|UNI2]] ||10||?||GL 3.0||Store uniform data in new structure.||KennethGraunke||IanRomanick|| ||
-||<style="background-color: #00FF00"><<Anchor(UNI4)>>UNI4 (Done)||[[#UNI3|UNI3]] ||10||?||GL 3.0||Make {{{ir_to_mesa}}} use the new uniform storage and mapping||KennethGraunke||IanRomanick|| ||
-||<<Anchor(UNI5)>>UNI5||[[#UNI7|UNI7]] ||10||?||GL 3.0||Make {{{brw_fs}}} use the new uniform storage and mapping||KennethGraunke|| ||With the other work, this will just be an optimization.  It can wait a bit.||
-||<<Anchor(UNI6)>>UNI6||[[#UNI4|UNI4]] ||?||?||GL 3.0||Split out any remaining uniform handling & resource allocation from {{{ir_to_mesa}}}||KennethGraunke||IanRomanick|| ||
-||<<Anchor(UNI7)>>UNI7||[[#UNI6|UNI6]] ||?||?||GL 3.0||make {{{ir_to_mesa}}} stop generating code for fragment shaders when there is another (hardware) back-end active.||KennethGraunke||IanRomanick|| ||
-||<style="background-color: #00FF00"><<Anchor(TXF1)>>TXF1 (Done)||  ||3||med||GL 3.0||Add support for the {{{ir_txf}}} opcode using the “ld” sampler message in {{{brw_fs}}}||KennethGraunke||KennethGraunke|| ||
-||<style="background-color: #00FF00"><<Anchor(TXF2)>>TXF2 (Done)||  ||4||med||GL 3.0||Write tests for texelFetch||KennethGraunke||DaveAirlie|| ||
-||<style="background-color: #00FF00"><<Anchor(TXS1)>>TXS1 (Done)||  ||3||high||GL 3.0||Merge kwg/txs branch with airlied's patch, and push both.||KennethGraunke|| ||High priority because the work is mostly done.||
-||<style="background-color: #00FF00"><<Anchor(TXS2)>>TXS2 (Done)||  ||3||high||GL 3.0||Write tests for textureSize||KennethGraunke|| ||Could add more tests||
-||<style="background-color: #00FF00"><<Anchor(TXS3)>>TXS3 (Done)||  ||3||med||GL 3.0||Implement TXS on GEN4 via SIMD16 resinfo message||KennethGraunke|| || ||
diff --git a/X11.mdwn b/X11.mdwn
new file mode 100644
index 0000000..1e5f73c
--- /dev/null
+++ b/X11.mdwn
@@ -0,0 +1,11 @@
+
+
+## X11
+
+Eleventh version of the X Window System. The X Window System is a network transparent window system which runs on a wide range of computing and graphics machines. X11 has primitives which are useful for the creation of graphical desktops (e.g., Windows, Colors, Displays, Screens). You can almost think of X11 as a 2D graphics library but in practice it does far more than that. X11 is also responsible for delivering a unified stream of events describing the user's interaction with input devices like the keyboard, mouse, touch pads, etc. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/X11.moin b/X11.moin
deleted file mode 100644
index 25f2a73..0000000
--- a/X11.moin
+++ /dev/null
@@ -1,13 +0,0 @@
-== X11 ==
-
-Eleventh version of the X Window System. The X Window System is a
-network transparent window system which runs on a wide range of computing and
-graphics machines. X11 has primitives which are useful for the creation of
-graphical desktops (e.g., Windows, Colors, Displays, Screens). You can almost
-think of X11 as a 2D graphics library but in practice it does far more than
-that. X11 is also responsible for delivering a unified stream of events
-describing the user's interaction with input devices like the keyboard, mouse,
-touch pads, etc.
-
-----
-CategoryGlossary
diff --git a/XEngine.moin b/XEngine.mdwn
index 844de44..9307719 100644
--- a/XEngine.moin
+++ b/XEngine.mdwn
@@ -1,13 +1,15 @@
-=== Shader translation framework/3D engine ===
-
-  Webpage: [[http://xengine.sourceforge.net/| http://xengine.sourceforge.net/]]
-
-Probably we can count this as  a very early attempt at unification various  3d rendering  data processing languages, from Cg to fixed-function combiners (!).
-
-From webpage (code itself was last updated  more than 3 years ago): 
-
-{{{
-Cg Fragment Shaders on Older ATI Radeons August 28, 2003 (10:45)
-
-XEngine now has a translator that can translate the DirectX pixel shader assembler (PSA) versions 1.0-1.3 to ATI_text_fragment_shader or ATI_fragment_shader. When using XEngine's internal Cg runtime this also means that it is now possible to have Cg fragment shaders run on older ATI Radeon cards, such as the Radeon 8500 or 9200, with the OpenGL renderer. Please see the DirectX PSA page in the related pages section of the documentation for details and restrictions of the translation process. Furthermore, the ATI_text_fragment_shader parser has been more intensively tested and debugged.
-}}}
+
+
+### Shader translation framework/3D engine
+
+   * Webpage: [[http://xengine.sourceforge.net/|http://xengine.sourceforge.net/]] 
+Probably we can count this as  a very early attempt at unification various  3d rendering  data processing languages, from Cg to fixed-function combiners (!). 
+
+From webpage (code itself was last updated  more than 3 years ago):  
+
+
+[[!format txt """
+Cg Fragment Shaders on Older ATI Radeons August 28, 2003 (10:45)
+
+XEngine now has a translator that can translate the DirectX pixel shader assembler (PSA) versions 1.0-1.3 to ATI_text_fragment_shader or ATI_fragment_shader. When using XEngine's internal Cg runtime this also means that it is now possible to have Cg fragment shaders run on older ATI Radeon cards, such as the Radeon 8500 or 9200, with the OpenGL renderer. Please see the DirectX PSA page in the related pages section of the documentation for details and restrictions of the translation process. Furthermore, the ATI_text_fragment_shader parser has been more intensively tested and debugged.
+"""]]
+\ No newline at end of file
diff --git a/XFree86.mdwn b/XFree86.mdwn
new file mode 100644
index 0000000..a9b06ea
--- /dev/null
+++ b/XFree86.mdwn
@@ -0,0 +1,11 @@
+
+
+## XFree86
+
+XFree86 is a free open-source implementation of X11. XFree86 implements [[drivers|http://www.wikipedia.org/wiki/device_driver]] for a vast array of popular graphics cards and input devices. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/XFree86.moin b/XFree86.moin
deleted file mode 100644
index dcca518..0000000
--- a/XFree86.moin
+++ /dev/null
@@ -1,7 +0,0 @@
-== XFree86 ==
-
-XFree86 is a free open-source implementation of X11. XFree86 implements [[http://www.wikipedia.org/wiki/device_driver|drivers]]
-for a vast array of popular graphics cards and input devices.
-
-----
-CategoryGlossary
diff --git a/XGI.mdwn b/XGI.mdwn
new file mode 100644
index 0000000..6d883d5
--- /dev/null
+++ b/XGI.mdwn
@@ -0,0 +1,34 @@
+
+
+# XGI
+
+**Chipsets** [[!map pages="^Vendor.+"]] 
+[[!table header="no" class="mointable" data="""
+ **Chip**  |  **Bus**  |  **Cards using this chip** 
+ XG43  |  AGP  |  V3XT / V3XE 
+ XG41  |  AGP  |  V5 
+ XG40  |  AGP  |  V8, V8 Ultra, V8 Duo 
+ XP10  |  PCI-Express  |  Volari 8300 
+"""]]
+
+
+## Status
+
+3D driver not _yet_ available. 
+
+
+## Specifications
+
+* [[V3XE Datasheet|https://bugs.freedesktop.org/attachment.cgi?id=7378]] 
+* [[V3XE 2D Programming Guide|https://bugs.freedesktop.org/attachment.cgi?id=7379]] 
+* [[8300 Datasheet|https://bugs.freedesktop.org/attachment.cgi?id=7939]] 
+* [[8300 2D Programming Guide|https://bugs.freedesktop.org/attachment.cgi?id=7938]] 
+* [[8300 3D Programming Guide|https://bugs.freedesktop.org/attachment.cgi?id=8338]] 
+
+## Resources
+
+
+
+---
+
+ [[CategoryHardwareVendor|CategoryHardwareVendor]] [[CategoryHardwareVendor|CategoryHardwareVendor]] 
diff --git a/XGI.moin b/XGI.moin
deleted file mode 100644
index 9e2d9d9..0000000
--- a/XGI.moin
+++ /dev/null
@@ -1,27 +0,0 @@
-= XGI =
-
-'''Chipsets'''
-<<PageList(^Vendor.+)>>
-
-|| '''Chip''' || '''Bus''' || '''Cards using this chip''' ||
-|| XG43 || AGP || V3XT / V3XE ||
-|| XG41 || AGP || V5 ||
-|| XG40 || AGP || V8, V8 Ultra, V8 Duo ||
-|| XP10 || PCI-Express || Volari 8300 ||
-
-== Status ==
-
-3D driver not ''yet'' available.
-
-== Specifications ==
-
- * [[https://bugs.freedesktop.org/attachment.cgi?id=7378|V3XE Datasheet]]
- * [[https://bugs.freedesktop.org/attachment.cgi?id=7379|V3XE 2D Programming Guide]]
- * [[https://bugs.freedesktop.org/attachment.cgi?id=7939|8300 Datasheet]]
- * [[https://bugs.freedesktop.org/attachment.cgi?id=7938|8300 2D Programming Guide]]
- * [[https://bugs.freedesktop.org/attachment.cgi?id=8338|8300 3D Programming Guide]]
-
-== Resources ==
-
-----
-CategoryHardwareVendor CategoryHardwareVendor
diff --git a/Xinerama.mdwn b/Xinerama.mdwn
new file mode 100644
index 0000000..dafec82
--- /dev/null
+++ b/Xinerama.mdwn
@@ -0,0 +1,22 @@
+
+
+# Xinerama
+
+
+## Status
+
+Traditional Xinerama distributes 2D commands to a basic [[MultiHead|MultiHead]] configuration. Providing the equivelent 3D distribution for the direct rendering 3D stream is new functionality.  
+
+This [[diagram|http://www.tungstengraphics.com/dri/Traditional_Xinerama.txt]] from TG gives an overview of the 2D and 3D streams. The 2D stream is distributed in the fourth box from the top, labeled "Xinerama's Single Logical Screen". The missing functionality, is the third box from the top, which distributes the 3D stream. It is labeled "Chromium-like 3D Command MUX". 
+
+Chromium has addressed many of the technical challenges for distributing a single 3D stream over multiple rendering pipelines. However, Chromium is focused on providing this solution over multiple systems in a cluster rather than a single system with multiple heads. 
+
+
+## See also
+
+   * [[MultiHead|MultiHead]] 
+
+
+---
+
+ [[CategoryHelpWanted|CategoryHelpWanted]] 
diff --git a/Xinerama.moin b/Xinerama.moin
deleted file mode 100644
index f382812..0000000
--- a/Xinerama.moin
+++ /dev/null
@@ -1,16 +0,0 @@
-= Xinerama =
-
-== Status ==
-
-Traditional Xinerama distributes 2D commands to a basic MultiHead configuration. Providing the equivelent 3D distribution for the direct rendering 3D stream is new functionality. 
-
-This [[http://www.tungstengraphics.com/dri/Traditional_Xinerama.txt|diagram]] from TG gives an overview of the 2D and 3D streams. The 2D stream is distributed in the fourth box from the top, labeled "Xinerama's Single Logical Screen". The missing functionality, is the third box from the top, which distributes the 3D stream. It is labeled "Chromium-like 3D Command MUX".
-
-Chromium has addressed many of the technical challenges for distributing a single 3D stream over multiple rendering pipelines. However, Chromium is focused on providing this solution over multiple systems in a cluster rather than a single system with multiple heads.
-
-== See also ==
-
-  * MultiHead
-
-----
-CategoryHelpWanted
diff --git a/ZBuffer.mdwn b/ZBuffer.mdwn
new file mode 100644
index 0000000..39fb767
--- /dev/null
+++ b/ZBuffer.mdwn
@@ -0,0 +1,11 @@
+
+
+## Z Buffer
+
+Z-buffering is an algorithm used in 3-D graphics to ensure that perspective works the same way in the virtual world as it does in the real one: a solid object in the foreground will block the view of one behind it. It works by testing pixel depth and comparing the current position (z coordinate) with stored data in a buffer (called a z-buffer ) that holds information about each pixel's last position. The pixel in the closer position to the viewer is the one that will be displayed, just as the person in front of the television is what the viewer sees rather than the screen.  Z-buffering is one of three Visual Surface Determination (VSD) algorithms commonly used for this purpose. The other two, BSP trees and depth sorting, work with polygons and consequently are less effective for portrayal of movement and overlap. Since it works at the pixel level, z-buffering can be demanding in terms of memory and processing time. Nevertheless, its more complex and life-like simulation of real-world object dynamics ensures its continuing popularity as a 3-D graphics development tool. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/ZBuffer.moin b/ZBuffer.moin
deleted file mode 100644
index c18525f..0000000
--- a/ZBuffer.moin
+++ /dev/null
@@ -1,20 +0,0 @@
-== Z Buffer ==
-
-Z-buffering is an algorithm used in 3-D graphics to ensure that perspective
-works the same way in the virtual world as it does in the real one: a solid
-object in the foreground will block the view of one behind it. It works by
-testing pixel depth and comparing the current position (z coordinate) with
-stored data in a buffer (called a z-buffer ) that holds information about each
-pixel's last position. The pixel in the closer position to the viewer is the
-one that will be displayed, just as the person in front of the television is
-what the viewer sees rather than the screen.  Z-buffering is one of three
-Visual Surface Determination (VSD) algorithms commonly used for this purpose.
-The other two, BSP trees and depth sorting, work with polygons and
-consequently are less effective for portrayal of movement and overlap. Since
-it works at the pixel level, z-buffering can be demanding in terms of memory
-and processing time. Nevertheless, its more complex and life-like simulation
-of real-world object dynamics ensures its continuing popularity as a 3-D
-graphics development tool.
-
-----
-CategoryGlossary
diff --git a/chipset.mdwn b/chipset.mdwn
new file mode 100644
index 0000000..fbec8a9
--- /dev/null
+++ b/chipset.mdwn
@@ -0,0 +1,11 @@
+
+
+## Chipset
+
+High density electronic circuits are often called 'chips' or 'microchips' because they're laid out on a small square of silicon or another thin, flat substrate. That's what's embedded inside the plastic/ceramic squares inside your computer. 'Chipset' then, generally refers to a collection of microchips designed together to handle some task. In the context of graphic driver development, there are generally two senses used.  Specifically, 'chipset' can refer to the particular acceleration engine used in your graphics card (such as 'ATI Rage Pro', 'Voodoo 3', or 'Matrox G400'.) This term is also (more generally) used to refer to the larger chips on your motherboard which interface between the main processor, memory, and the various peripherals. If you're talking about, e.g., the agpgart kernel driver for dma support, this is the chipset people will be asking about (such as '440BX' or 'VIA MVP3'.) These days, the 'chipset' may well be integrated into a single package, but the historical usage persists. 
+
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/chipset.moin b/chipset.moin
deleted file mode 100644
index 86c0791..0000000
--- a/chipset.moin
+++ /dev/null
@@ -1,19 +0,0 @@
-== Chipset ==
- 
-High density electronic circuits are often called 'chips' or 'microchips'
-because they're laid out on a small square of silicon or another thin, flat
-substrate. That's what's embedded inside the plastic/ceramic squares inside
-your computer. 'Chipset' then, generally refers to a collection of microchips
-designed together to handle some task. In the context of graphic driver
-development, there are generally two senses used.  Specifically, 'chipset' can
-refer to the particular acceleration engine used in your graphics card (such as
-'ATI Rage Pro', 'Voodoo 3', or 'Matrox G400'.) This term is also (more
-generally) used to refer to the larger chips on your motherboard which
-interface between the main processor, memory, and the various peripherals. If
-you're talking about, e.g., the agpgart kernel driver for dma support, this is
-the chipset people will be asking about (such as '440BX' or 'VIA MVP3'.) These
-days, the 'chipset' may well be integrated into a single package, but the
-historical usage persists.
- 
-----
-CategoryGlossary
diff --git a/glXGetProcAddressNeverReturnsNULL.mdwn b/glXGetProcAddressNeverReturnsNULL.mdwn
new file mode 100644
index 0000000..dbf773f
--- /dev/null
+++ b/glXGetProcAddressNeverReturnsNULL.mdwn
@@ -0,0 +1,63 @@
+
+
+# Why does glXGetProcAddress never return NULL?
+
+The issue of using glXGetProcAddress with GL and GLX extensions often comes up on various X, DRI, Mesa, and OpenGL related mailing lists.  It turns out that a lot of developers, even developers experienced with OpenGL and GLX related issues, have a few very, _very_ wrong misconceptions.  This document tries to clear up the most common of those misconceptions.  I'm not trying to pick on any one here.  Every issue in this document has come up _numerous_ times over the years. 
+
+
+## Misconception #1: glXGetProcAddress and glXGetProcAddressARB may not be available at run-time
+
+In section 3.6 [[Linux OpenGL ABI|http://oss.sgi.com/projects/ogl-sample/ABI/index.html]] **requires** that all libGL implementations on Linux statically export glXGetProcAddressARB.  It also common practice, though not required by the ABI, to statically export glXGetProcAddress.  At the very least, Nvidia's libGL does _not_ export glXGetProcAddress, so it is probably not wise for applications to depend on that symbol being available. 
+
+
+## Misconception #2: Pointers returned by glXGetProcAddress are context-dependent
+
+The [[GLX_ARB_get_proc_address|http://oss.sgi.com/projects/ogl-sample/registry/ARB/get_proc_address.txt]] specification details this quite clearly in the issues section, and that text won't be repeated here.  glXGetProcAddress is used to get pointers to both GL extension functions and GLX extension functions.  Many GLX extension functions are called before the application has a context bound (e.g., glXMakeCurrentReadSGI).  In order for pointers returned by glXGetProcAddress to be context-dependent the application would have to have a context to call glXGetProcAddress.  The chicken-and-egg problem here should be obvious. 
+
+Note, however, that this is _not_ the case with wglGetProcAddress.  The pointers returned by wglGetProcAddress are context-dependent.  This is probably the source of this misconception. 
+
+
+## Misconception #3: glXGetProcAddress will return NULL if the function is not supported
+
+Go back and look at misconception #2 for a few moments.  Now, repeat this phrase ten times:  glXGetProcAddress can be called before there is a context.  Before a context is bound, it is **impossible** to know what extensions or which OpenGL version is available.  At the time glXGetProcAddress is called by an application, it may not even be possible for libGL to know what driver or graphics card will be used.  Because of that, the default X.org libGL will _always_ return a non-NULL pointer. 
+
+Each GL context contains a dispatch table.  This table operates similarly to the virtual function table in a C++ object.  When glXGetProcAddress is called for an as yet unknown function a new slot is added to the dispatch table for that function.  In addition a short code segment that calls the function pointer stored in the dispatch table is created.  A pointer to this short function is returned by glXGetProcAddress.  Here's the catch:  if the driver does not support the function, it won't put anything in the function's dispatch table entry.  If the application calls the function returned by glXGetProcAddress, that function will try to call a NULL function pointer, and the application will crash. 
+
+To illustrate this, use X.org's default libGL and call: 
+
+`fptr = glXGetProcAddressARB( (const GLubyte *) "glThisFunctionWillNeverExist" );` 
+
+Create and bind a context and try to call that function. 
+
+Keep in mind that Nvidia's libGL does _not_ behave this way.  Nvidia's libGL knows that it will only ever load Nvidia's drivers, so it can make assumptions about what functions may or may not be made available at run-time.  If an application calls glXGetProcAddress on a function that it has never heard of, it knows that none of the drivers that it will ever load will ever export that function.  In that case it can return NULL. 
+
+You can try the same trick on Nvidia's libGL, however.  Try calling the pointer returned by glXGetProcAddressARB( (const GLubyte *) "glActiveStencilFaceEXT" ) on a TNT.  My guess is that glXGetProcAddress will return non-NULL because the function is known.  However, a TNT does not support [[GL_EXT_stencil_two_side|http://oss.sgi.com/projects/ogl-sample/registry/EXT/stencil_two_side.txt]], so the function won't actually be supported.  It is entirely possible that Nvidia's driver just routes the call to a no-op function in cases like this.  Nvidia does function dispatching a little differently than X.org's default libGL, so this is purely conjecture. 
+
+Things work slightly differently with GLX extension functions.  All GLX functions require at least some processing inside libGL.  In addition, there is no dispatch table for GLX functions.  Because of this, X.org's default libGL will return NULL when glXGetProcAddress is called for an unknown GLX functions (i.e., any unknown function whose name begins with "glX"). 
+
+
+## Misconception #4: Naming function pointers the same thing as the function makes code more readable
+
+A common tactic used by _eh-hem_ Windows developers is to name the pointer to an extension function the same thing as the extension function (see the sample code below).  On Windows, where opengl32.dll only exports functions for OpenGL 1.1, this is a semi-reasonable practice.  On Linux, it is pure evil. 
+
+
+[[!format txt """
+PFNGLACTIVESTENCILFACEEXT glActiveStencilFaceEXT = NULL;
+
+...
+
+glActiveStencilFaceEXT = (PFNGLACTIVESTENCILFACEEXT) glXGetProcAddressARB( (const GLubyte *) "glActiveStencilFaceEXT" );
+
+...
+
+glActiveStencilFaceEXT( GL_BACK );
+"""]]
+Conceptually, the problem is that an application has now redefined a symbol exported by a library with a symbol _of a different type_.  This is morally equivalent to putting 'void * printf' in a C program and expecting things to work correctly.  What happens when another library is loaded that expects the original symbol to have it's original meaning?  In the example above, if the application linked to a library that directly called glActiveStencilFaceEXT, that library would bind to the symbol in the application.  Since the library is expecting glActiveStencilFaceEXT to be a function (but it's actually a pointer), it will jump to the symbol and crash. 
+
+In X.org 6.8.0 and earlier, this exactly what happened with the open-source 3D drivers.  The _drivers_ called several GL extension functions directly.  If an application overrode those symbols with its own the driver would jump to function pointers, as if they were functions, and crash.  The worst part is that backtraces from these crashes showed the problem to be in the driver. 
+
+Even though more resent open-source drivers have worked around this issue, it **is** still an application bug to give any symbol the same name as an existing symbol that has a different type.  Period. 
+
+---
+
+ [[CategoryFaq|CategoryFaq]] 
diff --git a/glXGetProcAddressNeverReturnsNULL.moin b/glXGetProcAddressNeverReturnsNULL.moin
deleted file mode 100644
index f8211fa..0000000
--- a/glXGetProcAddressNeverReturnsNULL.moin
+++ /dev/null
@@ -1,55 +0,0 @@
-= Why does glXGetProcAddress never return NULL? =
-
-The issue of using glXGetProcAddress with GL and GLX extensions often comes up on various X, DRI, Mesa, and OpenGL related mailing lists.  It turns out that a lot of developers, even developers experienced with OpenGL and GLX related issues, have a few very, ''very'' wrong misconceptions.  This document tries to clear up the most common of those misconceptions.  I'm not trying to pick on any one here.  Every issue in this document has come up ''numerous'' times over the years.
-
-== Misconception #1: glXGetProcAddress and glXGetProcAddressARB may not be available at run-time ==
-
-In section 3.6 [[http://oss.sgi.com/projects/ogl-sample/ABI/index.html|Linux OpenGL ABI]] '''requires''' that all libGL implementations on Linux statically export glXGetProcAddressARB.  It also common practice, though not required by the ABI, to statically export glXGetProcAddress.  At the very least, Nvidia's libGL does ''not'' export glXGetProcAddress, so it is probably not wise for applications to depend on that symbol being available.
-
-== Misconception #2: Pointers returned by glXGetProcAddress are context-dependent ==
-
-The [[http://oss.sgi.com/projects/ogl-sample/registry/ARB/get_proc_address.txt|GLX_ARB_get_proc_address]] specification details this quite clearly in the issues section, and that text won't be repeated here.  glXGetProcAddress is used to get pointers to both GL extension functions and GLX extension functions.  Many GLX extension functions are called before the application has a context bound (e.g., glXMakeCurrentReadSGI).  In order for pointers returned by glXGetProcAddress to be context-dependent the application would have to have a context to call glXGetProcAddress.  The chicken-and-egg problem here should be obvious.
-
-Note, however, that this is ''not'' the case with wglGetProcAddress.  The pointers returned by wglGetProcAddress are context-dependent.  This is probably the source of this misconception.
-
-== Misconception #3: glXGetProcAddress will return NULL if the function is not supported ==
-
-Go back and look at misconception #2 for a few moments.  Now, repeat this phrase ten times:  glXGetProcAddress can be called before there is a context.  Before a context is bound, it is '''impossible''' to know what extensions or which OpenGL version is available.  At the time glXGetProcAddress is called by an application, it may not even be possible for libGL to know what driver or graphics card will be used.  Because of that, the default X.org libGL will ''always'' return a non-NULL pointer.
-
-Each GL context contains a dispatch table.  This table operates similarly to the virtual function table in a C++ object.  When glXGetProcAddress is called for an as yet unknown function a new slot is added to the dispatch table for that function.  In addition a short code segment that calls the function pointer stored in the dispatch table is created.  A pointer to this short function is returned by glXGetProcAddress.  Here's the catch:  if the driver does not support the function, it won't put anything in the function's dispatch table entry.  If the application calls the function returned by glXGetProcAddress, that function will try to call a NULL function pointer, and the application will crash.
-
-To illustrate this, use X.org's default libGL and call:
-
-{{{fptr = glXGetProcAddressARB( (const GLubyte *) "glThisFunctionWillNeverExist" );}}}
-
-Create and bind a context and try to call that function.
-
-Keep in mind that Nvidia's libGL does ''not'' behave this way.  Nvidia's libGL knows that it will only ever load Nvidia's drivers, so it can make assumptions about what functions may or may not be made available at run-time.  If an application calls glXGetProcAddress on a function that it has never heard of, it knows that none of the drivers that it will ever load will ever export that function.  In that case it can return NULL.
-
-You can try the same trick on Nvidia's libGL, however.  Try calling the pointer returned by glXGetProcAddressARB( (const GLubyte *) "glActiveStencilFaceEXT" ) on a TNT.  My guess is that glXGetProcAddress will return non-NULL because the function is known.  However, a TNT does not support [[http://oss.sgi.com/projects/ogl-sample/registry/EXT/stencil_two_side.txt|GL_EXT_stencil_two_side]], so the function won't actually be supported.  It is entirely possible that Nvidia's driver just routes the call to a no-op function in cases like this.  Nvidia does function dispatching a little differently than X.org's default libGL, so this is purely conjecture.
-
-Things work slightly differently with GLX extension functions.  All GLX functions require at least some processing inside libGL.  In addition, there is no dispatch table for GLX functions.  Because of this, X.org's default libGL will return NULL when glXGetProcAddress is called for an unknown GLX functions (i.e., any unknown function whose name begins with "glX").
-
-== Misconception #4: Naming function pointers the same thing as the function makes code more readable ==
-
-A common tactic used by ''eh-hem'' Windows developers is to name the pointer to an extension function the same thing as the extension function (see the sample code below).  On Windows, where opengl32.dll only exports functions for OpenGL 1.1, this is a semi-reasonable practice.  On Linux, it is pure evil.
-
-{{{
-PFNGLACTIVESTENCILFACEEXT glActiveStencilFaceEXT = NULL;
-
-...
-
-glActiveStencilFaceEXT = (PFNGLACTIVESTENCILFACEEXT) glXGetProcAddressARB( (const GLubyte *) "glActiveStencilFaceEXT" );
-
-...
-
-glActiveStencilFaceEXT( GL_BACK );
-}}}
-
-Conceptually, the problem is that an application has now redefined a symbol exported by a library with a symbol ''of a different type''.  This is morally equivalent to putting 'void * printf' in a C program and expecting things to work correctly.  What happens when another library is loaded that expects the original symbol to have it's original meaning?  In the example above, if the application linked to a library that directly called glActiveStencilFaceEXT, that library would bind to the symbol in the application.  Since the library is expecting glActiveStencilFaceEXT to be a function (but it's actually a pointer), it will jump to the symbol and crash.
-
-In X.org 6.8.0 and earlier, this exactly what happened with the open-source 3D drivers.  The ''drivers'' called several GL extension functions directly.  If an application overrode those symbols with its own the driver would jump to function pointers, as if they were functions, and crash.  The worst part is that backtraces from these crashes showed the problem to be in the driver.
-
-Even though more resent open-source drivers have worked around this issue, it '''is''' still an application bug to give any symbol the same name as an existing symbol that has a different type.  Period.
-----
-CategoryFaq
diff --git a/glxinfo.moin b/glxinfo.mdwn
index 6d8aae4..99b42ef 100644
--- a/glxinfo.moin
+++ b/glxinfo.mdwn
@@ -1,47 +1,49 @@
-`glxinfo` is a command-line tool that can help you diagnose problems with your 3D acceleration setup. It can also provide additional helpful information for developers. Use `man glxinfo` to get an overview of its options.
-
-<<TableOfContents>>
-
-=== How to tell whether your setup is good ===
-
-Run `glxinfo | grep render`. You should get two lines of output, for example:
-
-{{{
-direct rendering: Yes
-OpenGL renderer string: Mesa DRI Intel(R) 945GM GEM 20090326 2009Q1 RC2 x86/MMX/SSE2
-}}}
-
-The OpenGL renderer string tells you which driver was used; it distinguishes between software rendering and hardware rendering. In the example above, an Intel driver is used for hardware rendering.
-
-The first line tells you whether direct rendering is used. In this example, direct rendering is enabled, which means that all 3D rendering commands are handled by the client application, and the X server is not involved in the rendering. If ''indirect'' rendering is used, all rendering commands are sent to the server, and the server may use either software or hardware rendering. Consider the following example:
-
-{{{
-direct rendering: No (LIBGL_ALWAYS_INDIRECT set)
-OpenGL renderer string: Mesa DRI Intel(R) 945GM GEM 20090326 2009Q1 RC2 x86/MMX/SSE2
-}}}
-
-Here, OpenGL was forced to use indirect rendering using an environment variable, meaning that all rendering commands are sent to the X server. However, the X server actually uses hardware accelerated rendering. Now consider this example:
-
-{{{
-direct rendering: Yes
-OpenGL renderer string: Software Rasterizer
-}}}
-
-This means that software rendering is used, but all software rendering is done in the client application, so that the X server is free to service requests from other applications.
-
-As you can see, all four combinations of direct/indirect software/hardware rendering are possible. In terms of performance, direct hardware rendering is fastest, followed by (with a noticeable, but not completely horrible performance penalty) indirect hardware rendering. Software rendering is always pretty slow.
-
-
-=== Troubleshooting options ===
-
-If you get software rendering and do not understand why, it might help to run `LIBGL_DEBUG=verbose glxinfo` to get additional debug output (actually, you can use this environment variable with any other OpenGL application as well). You should see some lines like:
-{{{
-libGL: OpenDriver: trying /usr/lib/dri/tls/r300_dri.so
-libGL: OpenDriver: trying /usr/lib/dri/r300_dri.so
-}}}
-Surrounding these lines there may be additional messages indicating errors. In particular, if the driver is not found in the mentioned path, OpenGL will try to fall back to the software renderer called `swrast_dri.so`. This is an indication that the DRI drivers are not installed correctly.
-
-
-=== Source code and availability ===
-
-`glxinfo` should be installed by default by all (desktop) distributions. `glxinfo` is part of Mesa, its source code residing in [[http://cgit.freedesktop.org/mesa/demos/tree/src/xdemos/glxinfo.c|demos/src/xdemos/glxinfo.c]].
+
+`glxinfo` is a command-line tool that can help you diagnose problems with your 3D acceleration setup. It can also provide additional helpful information for developers. Use `man glxinfo` to get an overview of its options. 
+
+[[!toc ]] 
+
+
+### How to tell whether your setup is good
+
+Run `glxinfo | grep render`. You should get two lines of output, for example: 
+
+
+[[!format txt """
+direct rendering: Yes
+OpenGL renderer string: Mesa DRI Intel(R) 945GM GEM 20090326 2009Q1 RC2 x86/MMX/SSE2
+"""]]
+The OpenGL renderer string tells you which driver was used; it distinguishes between software rendering and hardware rendering. In the example above, an Intel driver is used for hardware rendering. 
+
+The first line tells you whether direct rendering is used. In this example, direct rendering is enabled, which means that all 3D rendering commands are handled by the client application, and the X server is not involved in the rendering. If _indirect_ rendering is used, all rendering commands are sent to the server, and the server may use either software or hardware rendering. Consider the following example: 
+
+
+[[!format txt """
+direct rendering: No (LIBGL_ALWAYS_INDIRECT set)
+OpenGL renderer string: Mesa DRI Intel(R) 945GM GEM 20090326 2009Q1 RC2 x86/MMX/SSE2
+"""]]
+Here, OpenGL was forced to use indirect rendering using an environment variable, meaning that all rendering commands are sent to the X server. However, the X server actually uses hardware accelerated rendering. Now consider this example: 
+
+
+[[!format txt """
+direct rendering: Yes
+OpenGL renderer string: Software Rasterizer
+"""]]
+This means that software rendering is used, but all software rendering is done in the client application, so that the X server is free to service requests from other applications. 
+
+As you can see, all four combinations of direct/indirect software/hardware rendering are possible. In terms of performance, direct hardware rendering is fastest, followed by (with a noticeable, but not completely horrible performance penalty) indirect hardware rendering. Software rendering is always pretty slow. 
+
+
+### Troubleshooting options
+
+If you get software rendering and do not understand why, it might help to run `LIBGL_DEBUG=verbose glxinfo` to get additional debug output (actually, you can use this environment variable with any other OpenGL application as well). You should see some lines like: 
+[[!format txt """
+libGL: OpenDriver: trying /usr/lib/dri/tls/r300_dri.so
+libGL: OpenDriver: trying /usr/lib/dri/r300_dri.so
+"""]]
+Surrounding these lines there may be additional messages indicating errors. In particular, if the driver is not found in the mentioned path, OpenGL will try to fall back to the software renderer called `swrast_dri.so`. This is an indication that the DRI drivers are not installed correctly. 
+
+
+### Source code and availability
+
+`glxinfo` should be installed by default by all (desktop) distributions. `glxinfo` is part of Mesa, its source code residing in [[demos/src/xdemos/glxinfo.c|http://cgit.freedesktop.org/mesa/demos/tree/src/xdemos/glxinfo.c]]. 
diff --git a/iXMicro.moin b/iXMicro.mdwn
index 4b411c1..ccbe9db 100644
--- a/iXMicro.moin
+++ b/iXMicro.mdwn
@@ -1,23 +1,30 @@
-= iXMicro =
-
-Mac-only series of 3D accelerators from Integrated Micro Systems, who later renamed themselves iXMicro.  There appear to be only two iterations of this device:
-
- * IMS Twin Turbo 128
- * IMS Twin Turbo 3D
-
-It is unclear how these two differ.  They are probably standard boring queue-and-fire chips, but their feature set (multitexturing, etc.) is pretty much unknown.
-
-iXMicro went out of business some time ago, but no one knows who bought their assets (if anyone).  Apple would be the most likely candidate.
-
-== Status ==
-
-Supported for 2D in Xorg, but no 3D driver.
-
-3D support was available in Mac OS.  Someone with sufficient time, dedication, and familiarity with MacsBug could probably reverse-engineer the support.
-
-== Specifications ==
-
-== Resources ==
-
-----
-CategoryHardwareChipset
+
+
+# iXMicro
+
+Mac-only series of 3D accelerators from Integrated Micro Systems, who later renamed themselves iXMicro.  There appear to be only two iterations of this device: 
+
+* IMS Twin Turbo 128 
+* IMS Twin Turbo 3D 
+It is unclear how these two differ.  They are probably standard boring queue-and-fire chips, but their feature set (multitexturing, etc.) is pretty much unknown. 
+
+iXMicro went out of business some time ago, but no one knows who bought their assets (if anyone).  Apple would be the most likely candidate. 
+
+
+## Status
+
+Supported for 2D in Xorg, but no 3D driver. 
+
+3D support was available in Mac OS.  Someone with sufficient time, dedication, and familiarity with [[MacsBug|MacsBug]] could probably reverse-engineer the support. 
+
+
+## Specifications
+
+
+## Resources
+
+
+
+---
+
+ [[CategoryHardwareChipset|CategoryHardwareChipset]] 
diff --git a/ioctl.mdwn b/ioctl.mdwn
new file mode 100644
index 0000000..6e50465
--- /dev/null
+++ b/ioctl.mdwn
@@ -0,0 +1,12 @@
+
+
+## ioctl
+
+From the _Linux Programmer's Manual_: 
+
+   * The ioctl function manipulates the underlying device parameters of spe- cial files.  In particular, many operating characteristics of character special  files  (e.g. terminals) may be controlled with ioctl requests. 
+
+
+---
+
+ [[CategoryGlossary|CategoryGlossary]] 
diff --git a/ioctl.moin b/ioctl.moin
deleted file mode 100644
index 9da3abb..0000000
--- a/ioctl.moin
+++ /dev/null
@@ -1,10 +0,0 @@
-== ioctl ==
-
-From the ''Linux Programmer's Manual'':
-
-  The ioctl function manipulates the underlying device parameters of spe-
-  cial files.  In particular, many operating characteristics of character
-  special  files  (e.g. terminals) may be controlled with ioctl requests.
-
-----
-CategoryGlossary
diff --git a/libGL.mdwn b/libGL.mdwn
new file mode 100644
index 0000000..bc901dd
--- /dev/null
+++ b/libGL.mdwn
@@ -0,0 +1,30 @@
+
+
+## libGL
+
+
+### What is libGL?
+
+OpenGL-based programs must link with the _libGL_ library. _libGL_ implements the GLX interface as well as the main OpenGL API entrypoints. When using indirect rendering, _libGL_ creates GLX protocol messages and sends them to the X server via a socket. When using direct rendering, _libGL_ loads the appropriate 3D DRI driver then dispatches OpenGL library calls directly to that driver. 
+
+libGL also has the ability to support heterogeneous, multi-head configurations. That means one could have two or more graphics cards (of different types) in one system and libGL would allow an application program to use all of them simultaneously. 
+
+
+### Where does libGL reside?
+
+The GLcore extension source code resides at [[xc/lib/GL/GL/|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/GL/]] . 
+
+[[!inline pages="libGLDriver" quick="yes" raw="yes"]] 
+
+
+### How do X modules and X applications communicate?
+
+X modules are loaded like kernel modules, with symbol resolution at load time, and can thus call each other functions. For kernel modules, the communication between applications and modules is done via the _/dev/*_ files. 
+
+X applications call X libraries function which creates a packet and sends it to the server via sockets which processes it. That's all well documented in the standard X documentation. 
+
+There are 3 ways 3D clients can communicate with the server or each other: 
+
+   1. Via the X protocol requests. There are DRI extensions. 
+   1. Via the SAREA (the shared memory segment) 
+   1. Via the kernel driver. 
+\ No newline at end of file
diff --git a/libGL.moin b/libGL.moin
deleted file mode 100644
index 79ee775..0000000
--- a/libGL.moin
+++ /dev/null
@@ -1,26 +0,0 @@
-== libGL ==
-
-=== What is libGL? ===
-
-OpenGL-based programs must link with the ''libGL'' library. ''libGL'' implements the GLX interface as well as the main OpenGL API entrypoints. When using indirect rendering, ''libGL'' creates GLX protocol messages and sends them to the X server via a socket. When using direct rendering, ''libGL'' loads the appropriate 3D DRI driver then dispatches OpenGL library calls directly to that driver.
-
-libGL also has the ability to support heterogeneous, multi-head configurations. That means one could have two or more graphics cards (of different types) in one system and libGL would allow an application program to use all of them simultaneously.
-
-=== Where does libGL reside? ===
-
-The GLcore extension source code resides at [[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/GL/|xc/lib/GL/GL/]] .
-
-<<Include(libGLDriver)>>
-
-=== How do X modules and X applications communicate? ===
-
-X modules are loaded like kernel modules, with symbol resolution at load time, and can thus call each other functions. For kernel modules, the communication between applications and modules is done via the ''/dev/*'' files.
-
-X applications call X libraries function which creates a packet and sends it to the server via sockets which processes it. That's all well documented in the standard X documentation.
-
-There are 3 ways 3D clients can communicate with the server or each other:
-
-  1. Via the X protocol requests. There are DRI extensions.
-  1. Via the SAREA (the shared memory segment)
-  1. Via the kernel driver.
-
diff --git a/libGLDriver.mdwn b/libGLDriver.mdwn
new file mode 100644
index 0000000..5887f21
--- /dev/null
+++ b/libGLDriver.mdwn
@@ -0,0 +1,45 @@
+
+
+### libGL (3D) Driver
+
+A DRI aware 3D driver currently based on Mesa. 
+
+
+#### Where does the 3D Driver reside?
+
+Normally libGL loads 3D DRI drivers from the `/usr/X11R6/lib/modules/dri` directory but the search patch can be overridden by setting the `LIBGL_DRIVERS_PATH` environment variable. 
+
+The DRI aware 3D driver resides in `xc/lib/GL/mesa/src/drv` 
+
+
+## The DRI driver initialization process
+
+   * The whole process begins when an application calls glXCreateContext ([[xc/lib/GL/glx/glxcmds.c|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/glx/glxcmds.c?rev=HEAD&content-type=text/vnd.viewcvs-markup]]). glXCreateContext is just a stub that call [[CreateContext|CreateContext]]. The real work begins when [[CreateContext|CreateContext]] calls `__glXInitialize` ([[xc/lib/GL/glx/glxext.c|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/glx/glxext.c?rev=HEAD&content-type=text/vnd.viewcvs-markup]]). 
+   * The driver specific initialization process starts with `__driCreateScreen`. Once the driver is loaded (via dlopen), dlsym is used to get a pointer to this function. The function pointer for each driver is stored in the _createScreen_ array in the `__DRIdisplay` structure. This initialization is done in driCreateDisplay ([[xc/lib/GL/dri/dri_glx.c|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/dri/dri_glx.c?rev=HEAD&content-type=text/vnd.viewcvs-markup]]), which is called by `__glXInitialize`. Note that `__driCreateScreen` really is the bootstrap of a DRI driver. It's the only [^1] function in a DRI driver that libGL directly knows about. All the other DRI functions are accessed via the `__DRIdisplayRec`, `__DRIscreenRec`, `__DRIcontextRec` and `__DRIdrawableRec` structs defined in [[xc/lib/GL/glx/glxclient.h|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/glx/glxclient.h?rev=HEAD&content-type=text/vnd.viewcvs-markup]]). Those structures are pretty well documented in the file. 
+   * After performing the `__glXInitialize` step, [[CreateContext|CreateContext]] calls the createContext function for the requested screen. Here the driver creates two data structures. The first, GLcontext, contains all of the device independent state, device dependent constants (i.e., texture size limits, light limits, etc.), and device dependent function tables. The driver also allocates a structure that contains all of the device dependent state. The GLcontext structure links to the device dependent structure via the [[DriverCtx|DriverCtx]] pointer. The device dependent structure also has a pointer back to the GLcontext structure. The device dependent structure is where the driver will store context specific hardware state (register settings, etc.) for when context (in terms of OpenGL / X context) switches occur. This structure is analogous to the buffers where the OS stores CPU state where a program context switch occurs. The texture images really are stored within Mesa's data structures. Mesa supports about a dozen texture formats which happen to satisfy what all the DRI drivers need. So, the texture format/ packing is dependent on the hardware, but Mesa understands all the common formats. See Mesa/src/texformat.h. Gareth and Brian spent a lot of time on that. 
+   * createScreen (i.e., the driver specific initialization function) is called for each screen from [[AllocAndFetchScreenConfigs|AllocAndFetchScreenConfigs]] ([[xc/lib/GL/glx/glxext.c|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/glx/glxext.c?rev=HEAD&content-type=text/vnd.viewcvs-markup]]). This is also called from `__glXInitialize`. 
+   * For all of the existing drivers, the `__driCreateScreen` function is just a wrapper that calls `__driUtilCreateScreen` ([[xc/lib/GL/dri/dri_util.c|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/dri/dri_util.c?rev=HEAD&content-type=text/vnd.viewcvs-markup]]) with a pointer to the driver's API function table (of type `__DriverAPIRec`). This creates a `__DRIscreenPrivate` structure for the display and fills it in (mostly) with the supplied parameters (i.e., screen number, display information, etc.). It also opens and initializes the connection to DRM. This includes opening the DRM device, mapping the frame buffer (note: the DRM documentation says that the function used for this is called drmAddMap, but it is actually called drmMap), and mapping the SAREA. The final step is to call the driver initialization function for the driver (from the [[InitDriver|InitDriver]] field in the `__DriverAPIRec` (DriverAPI field of the `__DRIscreenPrivate`). 
+   * The [[InitDriver|InitDriver]] function does (at least in the Radeon and i810 drivers) two broad things. It first verifies the version of the services (XFree86, DDX, and DRM) that it will use. The driver then creates an internal representation of the screen and stores it (the pointer to the structure) in the private field of the `__DRIscreenPrivate` structure. The driver-private data may include things such as mappings of MMIO registers, mappings of display and texture memory, information about the layout of video memory, chipset version specific data (feature availability for the specific chip revision, etc.), and other similar data. This is the handle that identifies the specific graphics card to the driver (in case there is more than one card in the system that will use the same driver). 
+   * After performing the `__glXInitialize` step, [[CreateContext|CreateContext]] calls the createContext function for the requested screen. This is where it gets pretty complicated. I have only looked at the Radeon driver. radeonCreateContext ([[xc/lib/GL/mesa/src/drv/radeon/radeon_context.c|http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.c?rev=HEAD&content-type=text/vnd.viewcvs-markup]]) allocates a GLcontext structure (actually `struct __GLcontextRec` from extras/Mesa/src/mtypes.h). Here it fills in function tables for virtually every OpenGL call. Additionally, the `__GLcontextRec` has pointers to buffers where the driver will store context specific hardware state (textures, register settings, etc.) for when context (in terms of OpenGL / X context) switches occur. The `__GLcontextRec` (i.e. GLcontext in Mesa) doesn't have any buffers of hardware-specific data (except texture image data if you want to be picky). All Radeon-specific, per-context data should be hanging off of the struct radeon_context. All the DRI drivers define a hardware-specific context structure (such as structure radeon_context, typedef'd to be radeonContextRec, or structure mga_context_t typedef'd to be mgaContext). radeonContextRec has a pointer back to the Mesa `__GLcontextRec` and Mesa's `__GLcontextRec->DriverCtx` pointer points back to the radeonContextRec. If we were writing all this in C++ (don't laugh) we'd treat Mesa's `__GLcontextRec` as a base class and create driver-specific derived classes from it. Inheritance like this is actually pretty common in the DRI code, even though it's sometimes hard to spot. These buffers are analogous to the buffers where the OS stores CPU state where a program context switch occurs. Note that we don't do any fancy hardware context switching in our drivers. When we make-current a new context, we basically update all the hardware state with that new context's values. 
+   * When each of the function tables is initialized (see radeonInitSpanFuncs for an example), an internal Mesa function is called. This function (e.g., _swrast_[[GetDeviceDriverReference|GetDeviceDriverReference]]) both allocates the buffer and fills in the function pointers with the software fallbacks. If a driver were to just call these allocation functions and not replace any of the function pointers, it would be the same as the software renderer. 
+   * The next part seems to start when the createDrawable function in the `__DRIscreenRec` is called, but I don't see where this happens. createDrawable should be called via glXMakeCurrent since that's the first time we're given an X drawable handle. Somewhere during glXMakeCurrent we use a DRI hash lookup to translate the X Drawable handle into an pointer to a `__DRIdrawable`. If we get a `NULL` pointer that means we've never seen that handle before and now have to allocate the `__DRIdrawable` and initialize it (and put it in the hash table). -- [[IanRomanick|IanRomanick]] and [[BrianPaul|BrianPaul]] 
+
+### Of what use is the Mesa code in the xc tree?
+
+Mesa is used to build some server side modules/libraries specifically for the benefit of the DRI. The libGL is the client side aspect of Mesa which works closely with the server side components of Mesa. 
+
+The GLU and GLUT libraries are entirely client side things, and so they are distributed separately. 
+
+
+### Is there any documentation about the XMesa* calls?
+
+There is no documentation for those functions. However, one can point out a few things. 
+
+First, despite the prolific use of the word "Mesa" in the client (and server) side DRI code, the DRI is not dependent on Mesa. It's a common misconception that the DRI was designed just for Mesa. It's just that the drivers that we at Precision Insight have done so far have Mesa at their core. Other groups are working on non-Mesa-based DRI drivers. 
+
+In the client-side code, you could mentally replace the string "XMesa" with "Driver" or some other generic term. All the code below `xc/lib/GL/mesa/` could be replaced by alternate code. libGL would still work. libGL has no knowledge whatsoever of Mesa. It's the drivers which it loads that have the Mesa code. 
+
+On the server side there's more of the same. The XMesa code used for indirect/software rendering was originally borrowed from stand-alone Mesa and its pseudo GLX implementation. There are some crufty side-effects from that. 
+
+
+[^1] that's not really true- there's also the `__driRegisterExtensions` function that libGL uses to implement glXGetProcAddress. That's another long story. 
diff --git a/libGLDriver.moin b/libGLDriver.moin
deleted file mode 100644
index eeeea28..0000000
--- a/libGLDriver.moin
+++ /dev/null
@@ -1,69 +0,0 @@
-=== libGL (3D) Driver ===
-
-A DRI aware 3D driver currently based on Mesa.
-
-==== Where does the 3D Driver reside? ====
-
-Normally libGL loads 3D DRI drivers from the `/usr/X11R6/lib/modules/dri` directory but the search patch can be overridden by setting the `LIBGL_DRIVERS_PATH` environment variable.
-
-The DRI aware 3D driver resides in `xc/lib/GL/mesa/src/drv`
-
-== The DRI driver initialization process ==
-
-  * The whole process begins when an application calls glXCreateContext ([[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/glx/glxcmds.c?rev=HEAD&content-type=text/vnd.viewcvs-markup|xc/lib/GL/glx/glxcmds.c]]). glXCreateContext is just a stub that call CreateContext. The real work begins when CreateContext calls `__glXInitialize` ([[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/glx/glxext.c?rev=HEAD&content-type=text/vnd.viewcvs-markup|xc/lib/GL/glx/glxext.c]]).
-
-  * The driver specific initialization process starts with `__driCreateScreen`. Once the driver is loaded (via dlopen), dlsym is used to get a pointer to this function. The function pointer for each driver is stored in the ''createScreen'' array in the `__DRIdisplay` structure. This initialization is done in driCreateDisplay ([[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/dri/dri_glx.c?rev=HEAD&content-type=text/vnd.viewcvs-markup|xc/lib/GL/dri/dri_glx.c]]), which is called by `__glXInitialize`.
-
-  Note that `__driCreateScreen` really is the bootstrap of a DRI driver. It's the only <<FootNote(that's not really true- there's also the `__driRegisterExtensions` function that libGL uses to implement glXGetProcAddress. That's another long story. )>> function in a DRI driver that libGL directly knows about. All the other DRI functions are accessed via the `__DRIdisplayRec`, `__DRIscreenRec`, `__DRIcontextRec` and `__DRIdrawableRec` structs defined in [[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/glx/glxclient.h?rev=HEAD&content-type=text/vnd.viewcvs-markup|xc/lib/GL/glx/glxclient.h]]). Those structures are pretty well documented in the file.
-  * After performing the `__glXInitialize` step, CreateContext calls the createContext function for the requested screen. Here the driver creates two data structures. The first, GLcontext, contains all of the device independent state, device dependent constants (i.e., texture size limits, light limits, etc.), and device dependent function tables. The driver also allocates a structure that contains all of the device dependent state. The GLcontext structure links to the device dependent structure via the DriverCtx pointer. The device dependent structure also has a pointer back to the GLcontext structure.
-
-  The device dependent structure is where the driver will store context specific hardware state (register settings, etc.) for when context (in terms of OpenGL / X context) switches occur. This structure is analogous to the buffers where the OS stores CPU state where a program context switch occurs.
-
-  The texture images really are stored within Mesa's data structures. Mesa supports about a dozen texture formats which happen to satisfy what all the DRI drivers need. So, the texture format/ packing is dependent on the hardware, but Mesa understands all the common formats. See Mesa/src/texformat.h. Gareth and Brian spent a lot of time on that.
-
-  * createScreen (i.e., the driver specific initialization function) is called for each screen from AllocAndFetchScreenConfigs ([[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/glx/glxext.c?rev=HEAD&content-type=text/vnd.viewcvs-markup|xc/lib/GL/glx/glxext.c]]). This is also called from `__glXInitialize`.
-
-  * For all of the existing drivers, the `__driCreateScreen` function is just a wrapper that calls `__driUtilCreateScreen` ([[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/dri/dri_util.c?rev=HEAD&content-type=text/vnd.viewcvs-markup|xc/lib/GL/dri/dri_util.c]]) with a pointer to the driver's API function table (of type `__DriverAPIRec`). This creates a `__DRIscreenPrivate` structure for the display and fills it in (mostly) with the supplied parameters (i.e., screen number, display information, etc.).
-
-  It also opens and initializes the connection to DRM. This includes opening the DRM device, mapping the frame buffer (note: the DRM documentation says that the function used for this is called drmAddMap, but it is actually called drmMap), and mapping the SAREA. The final step is to call the driver initialization function for the driver (from the InitDriver field in the `__DriverAPIRec` (DriverAPI field of the `__DRIscreenPrivate`).
-  * The InitDriver function does (at least in the Radeon and i810 drivers) two broad things. It first verifies the version of the services (XFree86, DDX, and DRM) that it will use.
-
-  The driver then creates an internal representation of the screen and stores it (the pointer to the structure) in the private field of the `__DRIscreenPrivate` structure. The driver-private data may include things such as mappings of MMIO registers, mappings of display and texture memory, information about the layout of video memory, chipset version specific data (feature availability for the specific chip revision, etc.), and other similar data. This is the handle that identifies the specific graphics card to the driver (in case there is more than one card in the system that will use the same driver).
-
-  * After performing the `__glXInitialize` step, CreateContext calls the createContext function for the requested screen. This is where it gets pretty complicated. I have only looked at the Radeon driver. radeonCreateContext ([[http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.c?rev=HEAD&content-type=text/vnd.viewcvs-markup|xc/lib/GL/mesa/src/drv/radeon/radeon_context.c]]) allocates a GLcontext structure (actually `struct __GLcontextRec` from extras/Mesa/src/mtypes.h). Here it fills in function tables for virtually every OpenGL call. Additionally, the `__GLcontextRec` has pointers to buffers where the driver will store context specific hardware state (textures, register settings, etc.) for when context (in terms of OpenGL / X context) switches occur.
-
-  The `__GLcontextRec` (i.e. GLcontext in Mesa) doesn't have any buffers of hardware-specific data (except texture image data if you want to be picky). All Radeon-specific, per-context data should be hanging off of the struct radeon_context.
-
-  All the DRI drivers define a hardware-specific context structure (such as structure radeon_context, typedef'd to be radeonContextRec, or structure mga_context_t typedef'd to be mgaContext).
-
-  radeonContextRec has a pointer back to the Mesa `__GLcontextRec` and Mesa's `__GLcontextRec->DriverCtx` pointer points back to the radeonContextRec.
-
-  If we were writing all this in C++ (don't laugh) we'd treat Mesa's `__GLcontextRec` as a base class and create driver-specific derived classes from it. Inheritance like this is actually pretty common in the DRI code, even though it's sometimes hard to spot.
-
-  These buffers are analogous to the buffers where the OS stores CPU state where a program context switch occurs.
-
-  Note that we don't do any fancy hardware context switching in our drivers. When we make-current a new context, we basically update all the hardware state with that new context's values.
-
-  * When each of the function tables is initialized (see radeonInitSpanFuncs for an example), an internal Mesa function is called. This function (e.g., _swrast_GetDeviceDriverReference) both allocates the buffer and fills in the function pointers with the software fallbacks. If a driver were to just call these allocation functions and not replace any of the function pointers, it would be the same as the software renderer.
-
-  * The next part seems to start when the createDrawable function in the `__DRIscreenRec` is called, but I don't see where this happens.
-
-  createDrawable should be called via glXMakeCurrent since that's the first time we're given an X drawable handle. Somewhere during glXMakeCurrent we use a DRI hash lookup to translate the X Drawable handle into an pointer to a `__DRIdrawable`. If we get a `NULL` pointer that means we've never seen that handle before and now have to allocate the `__DRIdrawable` and initialize it (and put it in the hash table).
-
-  -- IanRomanick and BrianPaul
-
-=== Of what use is the Mesa code in the xc tree? ===
-
-Mesa is used to build some server side modules/libraries specifically for the benefit of the DRI. The libGL is the client side aspect of Mesa which works closely with the server side components of Mesa.
-
-The GLU and GLUT libraries are entirely client side things, and so they are distributed separately.
-
-=== Is there any documentation about the XMesa* calls? ===
-
-There is no documentation for those functions. However, one can point out a few things.
-
-First, despite the prolific use of the word "Mesa" in the client (and server) side DRI code, the DRI is not dependent on Mesa. It's a common misconception that the DRI was designed just for Mesa. It's just that the drivers that we at Precision Insight have done so far have Mesa at their core. Other groups are working on non-Mesa-based DRI drivers.
-
-In the client-side code, you could mentally replace the string "XMesa" with "Driver" or some other generic term. All the code below `xc/lib/GL/mesa/` could be replaced by alternate code. libGL would still work. libGL has no knowledge whatsoever of Mesa. It's the drivers which it loads that have the Mesa code.
-
-On the server side there's more of the same. The XMesa code used for indirect/software rendering was originally borrowed from stand-alone Mesa and its pseudo GLX implementation. There are some crufty side-effects from that.
diff --git a/nVidia.mdwn b/nVidia.mdwn
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/nVidia.mdwn
diff --git a/nVidia.moin b/nVidia.moin
deleted file mode 100644
index b69501e..0000000
--- a/nVidia.moin
+++ /dev/null
@@ -1 +0,0 @@
-#REDIRECT NVIDIA