How To Help Improve, Develop Mesa Drivers

[whitecat]

If someone has got an Ubuntu build guide, please share.

Except the packages names in the STEP 1 and 4, it's the same.

[9a3eedi]

I am fairly proficient in C/C++ but I'm pretty sure that's not enough to get into Mesa development

In general I always found it difficult to get into opensource development, but Mesa probably is even more difficult because of its low level nature.

[Hamish Wilson]

In this this tutorial you will build the r600g driver (you can build other drivers too) so that you can use the upstream (git) driver without touching the Fedora driver. The compiled driver will be used only when you want. You can build the 64-bit driver for a 64-bit system, or the 32-bit driver for a 32-bit driver, and even a 32-bit driver for a 64-bit system (this is what you need in order to play 32-bit games like the awesone Enemy Territory: QUAKE Wars!!).

Sorry to burst your bubble, but ET:QW is running for me fine on the stock Mesa and R600 Gallium3D drivers currently available for Fedora 16. Just make sure that r_useIndexBuffers is set to 1 in .etqwctl/base/etqwconfig.cfg and you should be golden.

EDIT: Just saw that you only meant that you had to build a separate 32bit driver for playing certain 32bit games. My bad.

[Nille]

Its really sad that patches getting tested but are never comitted (e.g. GL_SELECT Patches for radeon) :/ Since over one year the code is there ( and from many ppl tested ) but no dev what to look at this :/

[89c51]

I am fairly proficient in C/C++ but I'm pretty sure that's not enough to get into Mesa development

In general I always found it difficult to get into opensource development, but Mesa probably is even more difficult because of its low level nature.

If you ask at the IRC or the mailing list people there will most certainly guide you on where to start, give you an introductory task or whatever. The TODOs that Michael posted is a place to start.

[whitecat]

Sorry to burst your bubble, but ET:QW is running for me fine on the stock Mesa and R600 Gallium3D drivers currently available for Fedora 16. Just make sure that r_useIndexBuffers is set to 1 in .etqwctl/base/etqwconfig.cfg and you should be golden.

Interesting, on my hardware (Pentium E2160@2,7GHz, 2 Go RAM, HD4850) I remember that ETQW worked on F16 but was too slow to be playable. With F17 that was much better, but the current upstream is for me the first "version" really playable. ETQW runs at 30~60 FPS in 1680*1050 (low details), without bugs or crash obviously (except with Linux 3.5).

[ssam]

Then there was this thread which died unfortunately (but not unexpected):

Sponsor An Open Source Driver Dev

it sounds like there is already money available through the xorg evoc. Just need to find some people to sign up to code.

[curaga]

Its really sad that patches getting tested but are never comitted (e.g. GL_SELECT Patches for radeon) :/ Since over one year the code is there ( and from many ppl tested ) but no dev what to look at this :/

Who uses that? It's old functionality, and a sw fallback in practically every driver.

[Nille]

Who uses that? It's old functionality, and a sw fallback in practically every driver.

Blender and many other Software that build the UI with OpenGL. But thats not the point. Someone has implement this feature but it is ignored from the other devs.

[Lynxeye]

Blender and many other Software that build the UI with OpenGL. But thats not the point. Someone has implement this feature but it is ignored from the other devs.

Yes it happens that devs ignore stuff, but that's not because they don't like it but more that no one has had the time to finish this up for inclusion. To get something into mesa you need someone actively driving stuff forward. In the GL_SELECT case there was a pretty good implementation that was even pushed to a branch upstream, but after that there was no one who did the work to cut the last rough edges.

If this is really a thing that bothers you, why don't you go ahead and try to get it mainline? It shouldn't be too hard, as it was nearly finished. Just get on the Mailing List and ask what other people think, what has to be done to get this integrated. Then if you fix up the last bits I think there will be no one that blocks this from inclusion. It's just not that devs go there and say: "oh, there's this code to enable a feature I never used and never tested, but ok I'll commit this". You need people to drive things forward, even if it's sometimes just a minor push that's needed to get things going.

So please don't just talk about "the devs", this is not a proprietary project, this is open source, so you can easily be a dev, too.