path: root/Radeon_Companion_1

# 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_