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 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 (Source), started renaming some unkXXXX registers (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. (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 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 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 (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 (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 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 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. (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 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)