ATI R300-R500 Gallium3D Driver Is "Mostly" Done

[Zajec]

What we really need is developer manpower. If you're curious about this stuff, try running r300g and fixing one of the many problems that Piglit reports. Once we have the majority of Piglit tests running, there's a fair chance that complex apps (Compiz, games) have reasonable support. So get out those debuggers, or don't get your expectations up too high, because this thing is still crawling full of seriously bad bugs.

Unfortunately you lack manpower, and ppl who could involve in Mesa lack documentation. You work on drivers, nobody have time to create howtos, and ppl can't start working on drivers without howtos. We have some sad loop there

When I decided to hack on radeonhd to improve something I found:
http://wiki.x.org/wiki/Development/Documentation/
especially:
http://wiki.x.org/wiki/Development/D...VideoCardsWork
which have me some idea how modesetting is made.

Unfortunately I can't find any such a nice howto on 2D, Xv or 3D. I've heard many times "read the driver/code" and I agree it's kind of way of learning, but... not without any knowledge.

When I read /HowVideoCardsWork/ I knew what is VRAM, CRTC, PLL and driver code made sense to me. It's hard to read it without basic knowledge. You don't even know where to start.

It would be nice if you could guys think about some documentation on how 2D/Xv/3D works. This won't give you any new developer in a months, but maybe some ppl will able to produce single patches for little issues.

[mdias]

Unfortunately you lack manpower, and ppl who could involve in Mesa lack documentation. You work on drivers, nobody have time to create howtos, and ppl can't start working on drivers without howtos. We have some sad loop there

When I decided to hack on radeonhd to improve something I found:
http://wiki.x.org/wiki/Development/Documentation/
especially:
http://wiki.x.org/wiki/Development/D...VideoCardsWork
which have me some idea how modesetting is made.

Unfortunately I can't find any such a nice howto on 2D, Xv or 3D. I've heard many times "read the driver/code" and I agree it's kind of way of learning, but... not without any knowledge.

When I read /HowVideoCardsWork/ I knew what is VRAM, CRTC, PLL and driver code made sense to me. It's hard to read it without basic knowledge. You don't even know where to start.

It would be nice if you could guys think about some documentation on how 2D/Xv/3D works. This won't give you any new developer in a months, but maybe some ppl will able to produce single patches for little issues.

+1.

I tried helping before, and failed exacly because of this. I don't know where to start.
I'll be reading those links now, they seem to be full of great info I've never been able to find before.

Thanks!

[pvtcupcakes]

Unfortunately you lack manpower, and ppl who could involve in Mesa lack documentation. You work on drivers, nobody have time to create howtos, and ppl can't start working on drivers without howtos. We have some sad loop there

When I decided to hack on radeonhd to improve something I found:
http://wiki.x.org/wiki/Development/Documentation/
especially:
http://wiki.x.org/wiki/Development/D...VideoCardsWork
which have me some idea how modesetting is made.

Unfortunately I can't find any such a nice howto on 2D, Xv or 3D. I've heard many times "read the driver/code" and I agree it's kind of way of learning, but... not without any knowledge.

When I read /HowVideoCardsWork/ I knew what is VRAM, CRTC, PLL and driver code made sense to me. It's hard to read it without basic knowledge. You don't even know where to start.

It would be nice if you could guys think about some documentation on how 2D/Xv/3D works. This won't give you any new developer in a months, but maybe some ppl will able to produce single patches for little issues.

AMD released a bunch of documentation, but I don't know where you can find it. I believe bridgeman worked on it.

[Zajec]

AMD released a bunch of documentation, but I don't know where you can find it. I believe bridgeman worked on it.

Hm, I thought they released only chipsets programming docs. Like "Put 0x01 to register 0x5000 to enable CRTC1".

AFAIK all they released is available on: http://www.x.org/docs/AMD/

Will browse that in free time. For now I've checked R6xx_R7xx_3D.pdf and it seems to explain for ex. what CP is. That can be really nice document. Now I think we still need some Mesa API documentation. Does anyone how about such?

Thanks a lot for pointing that docs, it may be really useful.

[agd5f]

Things like Xv using textures is a basic example of a 3d operation (drawing a textured quad). This post explains it:
http://www.botchco.com/agd5f/?p=22
and can be extrapolated to other 3d operations. The basic idea is:
1. set up engine state (textures, render buffers, shaders, etc.)
2. send verts for primitives or setup vertex buffer
3. issue draw command
These guides explain how to set up the 3d pipeline of AMD GPUs:
http://www.x.org/docs/AMD/R5xx_Acceleration_v1.3.pdf
http://www.x.org/docs/AMD/R6xx_R7xx_3D.pdf
Looking at some basic GL apps/tutorials is a good starting point.
these posts give some basic info on the AMD GPU architecture:
http://www.botchco.com/agd5f/?p=14
http://www.botchco.com/agd5f/?p=15
http://www.botchco.com/agd5f/?p=16
http://www.botchco.com/agd5f/?p=17

[nhaehnle]

Indeed, documentation is a problem. For those who are interested in Mesa: do you know OpenGL? Knowing about OpenGL is kind of a prerequisite, unfortunately, and I don't see a way around it. Once you know OpenGL, a lot of the terminology etc. should already make more sense.

Apart from that, if you seriously want to get into it and get stuck in some place, maybe you can just ask? I'm sure we'll be able to answer questions, if you promise to the produce patches that add useful comments. After all, I don't even know *where* you get stuck, so how can I write better documentation? It's not impossible, just very difficult, and I'm not convinced that it's the best way for me to spend my time.

[BlackStar]

Indeed, documentation is a problem. For those who are interested in Mesa: do you know OpenGL? Knowing about OpenGL is kind of a prerequisite, unfortunately, and I don't see a way around it. Once you know OpenGL, a lot of the terminology etc. should already make more sense.

Apart from that, if you seriously want to get into it and get stuck in some place, maybe you can just ask? I'm sure we'll be able to answer questions, if you promise to the produce patches that add useful comments. After all, I don't even know *where* you get stuck, so how can I write better documentation? It's not impossible, just very difficult, and I'm not convinced that it's the best way for me to spend my time.

Is there a list of todo tasks WRT Mesa? How do we set up a development and testing environment? Where do we post patches? (they seem to get ignored in the bugtracker) What license must they be in?

In my experience, there's a big difference between "start coding and ask if you have any problems" and "here's what we need, here's how you start, ask if you have any problems". Such a guide wouldn't take more than a couple of hours to write and, unlikely as that may seem now, it will help people get involved.

Some developer guidelines are here. Add a few notes on the dev and review process (i.e. "post a bug at http://foobar.com and attach your patch there" or "subscribe to mesa-dev and post your patch there"), add a couple of todo items (i.e. "implement ARB_foo_bar on R600") and you'll have a good starting point for contributors.

Edit: I'd also love a rough overview of how the OpenGL state tracker works. I have a rough idea of the dispatching mechanism but I haven't seen any documentation on the who (what, where and how) tracks the actual GL state.

[Zajec]

Edit: I'd also love a rough overview of how the OpenGL state tracker works. I have a rough idea of the dispatching mechanism but I haven't seen any documentation on the who (what, where and how) tracks the actual GL state.

+1, please. I god some short conversation about this on IRC but would like to see this explained once more in more suitable form.

[agd5f]

The basic idea is that mesa manages state and provides driver callbacks where the driver can hook in hardware specific functions. The driver updates the hardware state in those functions and flushes command buffers to the GPU as needed. For example, in the r600 3D driver, see r700InitStateFuncs() at the end of r700_state.c; you can see the driver specific state callbacks registered there. r700BlendColor updates the hardware blend color state. mesa calls the the BlendColor driver callback when the GL app changes the blend color state. Next lets looks at r700BlendColor. First it calls R600_STATECHANGE which marks the blend color state as dirty so that when the updated command buffer is sent to the hardware we make sure to include the new blend color. Next the driver updates its copy of the blend color state regs (r700->CB_BLEND_*) with the new blend color from mesa (cf[4]). Finally when either the accumulated state gets big enough or the driver flush function is called, the driver's copy of the register state is written to a command buffer and send to the GPU. If the blend color was updated (and henced marked as dirty), r700SendCBBlendColorState in r700_chip.c would eventually be called. It appends the new blend color state to the command buffer.