3d development

[koolmanoncampus]

I remember reading around that 3d on the R500 is *similar* to the R300 and might be able to be ported. I understand there are some differences that make it harder rather than easier. (mentioned in Dave Airlie's blog)

Does anyone know if there is any ongoing work on this front going on with mesa dri driver development? Or are developers waiting for the docs before proceeding?

[bridgman]

It's a bit of both. Since most of the display, modesetting and video overlay stuff are controlled by registers we can create extracts of the register information, turn them into documents, and have a pretty good start. There are still questions and gaps but they're manageable.

On the 3d side there's a lot more interaction between the registers (plus the fact that a lot of the work is done through the command processor and never touches registers) so simple register-by-register documentation isn't really enough. Our current plan (which still seems on track) is to make more use of sample code on the 3d side, by open-sourcing some of the new OpenGL driver. We're thinking about patching that into the existing R3xx+ mesa driver so that the code can actually be executed and used (and, most likely, re-written ).

In shorter words, yes developers are waiting for the docs but since we plan to provide some working code along with the docs it won't take as long to get up to speed.

[koolmanoncampus]

Sounds good.

I look forward to having 3d on my desktop again. (8.40 doesn't play well with f8)

[TechMage89]

About the 3d backend code you keep talking about. Is it similar in function to the driver end of gallium3d? Could it be converted to a functional gallium3d driver without a lot of architectural changes?

This would be huge, because it would be a big leg-up on driver development to be able to use Gallium's state tracker.

I really like the look of Gallium3d. I'm not a very experienced programmer, but it seems like a very elegant approach to me to separate "translating" graphics operations and providing a high-level interface for the api.

[bridgman]

We're looking at that now. There are definitely some non-trivial differences -- a big one is that we put the shader compilers further up the stack than gallium does so some of the mid-level APIs are very different -- but the design objectives were certainly pretty similar, and both were optimized for fully shader-based chips.

Should be able to give a better answer in a couple of weeks.

[TechMage89]

Even with the differences, it sounds like a mostly functional gallium3d driver might not be to hard to build, even if parts of the existing code have to be re-written. Reusing code is always good .

With that advantage, I guess building a traditional mesa driver wouldn't make a lot of sense, so Gallium3d is probably the way to go.

[glisse]

Even with the differences, it sounds like a mostly functional gallium3d driver might not be to hard to build, even if parts of the existing code have to be re-written. Reusing code is always good .

With that advantage, I guess building a traditional mesa driver wouldn't make a lot of sense, so Gallium3d is probably the way to go.

The gallium driver in itself might be easy but to get somethings on the screen (my guess is that most people want to see their 3d application on screen, but that just a wild guess ) you need many pieces to be put together and this is the tricky part where in my opinion X provide a real painfull infrastructure: dri. Hopefully dri2 looks a lot more better than current dri.

[TechMage89]

The linux graphics system needs a lot of improvements. It looks like it's going to get the though. I just hope it's sooner rather than later.

[koolmanoncampus]

Is the 3d stuff still expected out of AMD sometime this quarter?

[Michael]

The tcore information, etc should be out soon.