Outsiders of the group of developers regularly complain that it's very hard to get an understanding of what happens in development of the Radeon driver(s). They have convinced me.
So I've spent some time to refactor the documentation on the DRI Wiki, creating a new, cleanup up and up-to-date portal page in the process. However, this refactoring is not complete, and the amount of information is not yet entirely satisfying. The real test now is whether this can be more than a one-shot effort by me, so this is a shout out to others - particularly to the users who have been asking for this - to help improve the documentation.
Partly, this can be done in very mundane ways by normal users. The application support matrix needs to be updated for Mesa 7.6 (there have been a lot of significant improvements), which mostly requires testing by a lot of people who own the necessary hardware/software combinations.
I have also created a stub page for 3D troubleshooting and known problems, and I want to rely mostly on users to help filling that with useful information. After all, the kind of trouble I run into usually has to do with me breaking the driver during development, which is on a rather different level from the kind of trouble users run into.
Now my main goal is actually to improve the way we present ourselves to potential new developers. This is also quite tricky because after having been immersed in this stuff for so long, it is hard for me to judge what kind of information and documentation would be most helpful to newcomers. If you have a concrete question, or set of questions, I'd be curious to know, and I may end up blogging on it, or documenting it on the Wiki, or documenting it in the source code. However, please give me more than a muddy "this stuff is complicated, can you hold my hand through it?", because yes, unfortunately, this stuff is complicated.
In my experience, the first step to understanding the 3D driver is to understand OpenGL. After all, the purpose of the 3D driver is ultimately to implement an API - and you just won't understand the driver if you don't understand that API. So if you're curious about 3D driver development, hack on little OpenGL samples first, or even at the same time! It doesn't have to be a large game engine; the samples that come with Mesa may be more than enough as a starting point. Then maybe you want to step through your program and what the driver does in a debugger, or experiment with other little ways that can help you understand the driver.
I hope that we will be able to welcome you into the fold one day.
Abonnieren
Kommentare zum Post (Atom)
5 Kommentare:
Huh, thanks for looking at this :)
I'll try to hack on something, but it will definitely take me some time to just read the docs.
Could you tell me if my understanding of general 3D rendering is correct? Here is how I imagine glxgears:
[first,once: init gpu]
driver tells GPU to create new contex
driver sends GPU eye coords
for (i = 0..2) {
driver tells GPU to use colors[i]
driver draws gear
}
while (1) {
for (0..2) {
rotate += 1
}
}
OK, that probably looks silly for you... ;) But maybe there are some important steps I missed, or I get sth totally wrong. Or maybe my knowledge should be more detailed? So I could understand code flow better?
I sort of understand how my ATI 9800 All-in-Wonder pro card relates to X (X loads radeon_drv.so because that is the open-source video driver supporting the R350 chip ). Until your post I had no idea if there is a separate DRI driver, or how to tell what the mysterious "mesa" uses.
glxinfo reports "OpenGL vendor string: DRI R300 Project" but there's no indication of it loading any driver. So when your Radeon portal page starts talking about the "r300" driver, I was completely mystified. Now looking much further down in Xorg.0.log I see "(II) AIGLX: Loaded and initialized /usr/lib/dri/r300_dri.so". Live and learn! (One problem with the DRI project is searching for "dri" returns so many matches for "driver".)
I think you need to step back and explain the basics on the DRI wiki: "Your card has a video driver for the X Window System, and may also have a separate DRI driver for 3D acceleration. You can find out what driver is used for each by... looking in /var/log/Xorg.0.log(?) You can tell what 3D in X uses by ... running glxinfo (?)"
Cheers.
I tried to do the "marketing" stuff using tirdc. I don't think it really gathered developers, but it was good to do something in the public. I currently totally lack the time, so I only randomly publish information. Hope we can improve this situation together. Thanks for your hard efforts!
Rafal: Thanks to open source, the functionality of glxgears doesn't have to remain a mystery. The source to glxgears is in Mesa, in the file progs/xdemos/glxgears.c.
The original version, gears, uses the GLUT library, which means that it doesn't contain any X window calls but only OpenGL calls, which should make the OpenGL aspects of the program easier to understand. You can find the source in gears.c.
skierpage: The thing is, all this information is already on the X.org and DRI wikis. Maybe it needs to be made more accessible. Perhaps a "how to learn to understand what the heck is going on" kind of introduction would be helpful.
egore911: Yes I know, and I'm grateful for what you did and still do. As for attracting new developers, I have the feeling that driver development is just fundamentally hard and we just cannot expect to get hordes of new developers, but still I feel that by trying to lower the bars just a little bit, we can increase the chances of attracting new developers. Unfortunately, we'll probably never be able to say "this guy/gal started hacking the driver because of this Wiki page" unless they personally tell us that. Because of that, it may seem futile at times, but I'm pretty sure it's not.
In the long run, we just need to find a mode of operation where we occasionally do small things to the Wiki to keep it up to date without spending too much time on it.
One thing that would help me, is describing a typical SW setup to do driver debugging and development.
Ive got enough experience in userland 3d dev, some embedded and windows driver dev etc, just that i havent seen a short "getting started" guide or "setting up environment" guide for doing mesa driver dev without locking up Xorg on my main machine all the time.
Kommentar veröffentlichen