|
* Overview
* Hw_script
* Preload
* Musplay
* Mixer
* Cdman
* Tgt-edif
* fx2_programmer
* Software Radio
* LIGO viewer
* R300 driver
* Status
* CVS
* Download
* About me
|
The development of R300 drivers and code has moved to a separate project on SourceForge: R300.
This page is left here for reference purposes.
Overview
This webpage was created to document my progress in understanding R300 3d acceleration engine. (R300 is a family of cards made by ATI, in particular
it includes Radeon 9700 cards and Mobility M10 cards used in notebooks).
The source code on this page may damage your hardware.
It is *UNTESTED* and *BROKEN* !
Or, at least, some of it is.
Development
There is an unspoken rule in the community that if someone is working on
a project it is "reserved" and the person should be given some space..
Please, this does *NOT* apply here!
I am so busy nowadays that I frequently
don't have time to read mailing lists I am subscribed to, let alone code this driver. (The comment about mailing lists includes gatos-devel and dri-devel - so if you want to contact me personally send an e-mail with me as a single recipient to get past my procmail filter.)
Current status
- DRM kernel module updated.
- 2d driver updated - CP acceleration appears to work correctly.
- Made an attempt at hacking R200 Mesa driver to work with R300. Nothing new..
Lots of debug messages and lockups. About one lockup per 300 characters of debug
output.
- Wrote drmtest - a command line utility to exercise R300 CP engine.
Had it successfully send BITBLT_MULTI via indirect buffer.
- Incorporated patch from Nicolai Haehnle - this should make 2d driver more stable.
Hard lockups went away (unless I do something stupid), albeit X can still hang. Still, being
able to shutdown cleanly and examine dmesg is a big help.
- Cleaned up drmtest a little and added more register info that I am somewhat more certain about.
This is still based on educated guesses and study of DirectX - the assumption being that ATI would not care to mess around with the bitmap flags in the driver and will design hardware to accept them
as is.
- I did some benchmarking and it appears that running with DRM driver some 2d operations (in particular PutImage and ShmPutImage)
are twice as fast.
- Wrote glxtest - an application to exercise GL drawing commands and save resulting command stream to a file for later analysis.
- Updated drmtest to paint a triangle and a square using Radeon Mobility M10 hardware. You can see the screenshot here.
- Wrote r300_demo - this paints some triangles. This package has a start of a library to paint things.
- The academic year will start in full soon, so I guess I will have to pause at this stage.
TODO / Notes
- Hacking the Mesa driver turned out to be a lot messier than I thought.
Give a try at writing a small DRM client for the single purpose of exercising CP engine. The major goal is to find out whether the CP packets I know about work without the lockup and whether I can actually draw anything with them.
- Write an app that interfaces with DRM - DONE
- Modify to exercise BITMAP_MULTI (supposed to work.. 2d packet) - DONE
- Modify to exercise one of CP packets that have vertex data in the packet itself
(instead of using an indirect buffer). - DONE
- Write a combination GL test/register dump application that would use immediate mode to find out which registers are actually changed by 3d operations. Useful for
debugging the driver and general exploration. Possibly modify hw_script for this purpose. - DONE
- Start writing library for translating drawing calls into CP packets. Not sure when I will have time for this.
- Debug reset procedure for R300. There was an occasion when a manual reset (via hw_script) of VAP only did the trick - while the same in X server apparently had no effect.
Perhaps all bits in RBBM_SOFT_RESET should not be set at once ?
- Study architecture of programmable shaders - do they have halt or exit instructions ? It looks like the cause of lockups is VAP itself.. Perhaps default
pixel shader program is endless loop.
Source code
|
