If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Open-Source R600 OpenGL Support May Come Soon

Phoronix: Open-Source R600 OpenGL Support May Come Soon

In late December AMD had released open-source R600/700 3D code and a month later they released the 3D documentation that covers these Radeon HD 2000/3000/4000 series graphics cards. The initial code drop didn't do much good for end-users as they couldn't do much more than render a couple triangles, but over the past few months the open-source developers have been working on the proper Mesa support for the R600/700 graphics cards in a private code repository...

Didn't RDR (redirected direct rendering) that fixes the composition problems in practise require GEM? I thought this was the Radeon 3D support in the classic Mesa model they were doing before moving to KMS/DRI2/Gallium3D. I must admit I've lost track of it all though.

I doubt Compiz will work yet, although I don't think it has been tested. Don't read too much into this, when the code appears in the public repo it will just mean "I finally had time to get it reviewed and released so the rest of the work can happen in public". It won't correspond to any particular milestone in the development.

We're in the middle of changing the code to be "fairly close to what is needed to run over a memory manager" and compatible with the radeon-rewrite work happening in another branch but AFAIK there is no 6xx/7xx memory manager yet so don't be dreaming about RDR next week.

Dream about glxgears at 100fps or something like that for now - we haven't accelerated upload/download yet so there are a lot of software copies from system memory to video ram still.

Can someone tell me why this code needs to be approved by AMD in the first place? I thought that was the point of putting out the documentation - the devs could base all their work off of that and know that it was OK'd by the lawyers ahead of time. Was the documentation released not enough to do all the work and they are still relying on private info? Or are these devs just AMD employees and have to get everything they do signed off on?

I'm curious as to how support for multiple cards is coming along in radeon(&hd). Will there be a point where I can plug in two cards, run one display device on each card, and start an instance of accelerated gears on each screen? Can I drag gears from one screen to another?

Can someone tell me why this code needs to be approved by AMD in the first place?
[...]
Or are these devs just AMD employees and have to get everything they do signed off on?

AFAIU for the newer chips (R600+) it is not clear which documentation you actually need to write a driver. Also documentation alone is not as good as documentation + working basic code to see how it works in the code.

Any yes, AFAICS many of the devs are emplyed, Red Hat, (Novell) and AMD. But there are also other people (w.g. students) working on the code for free.
I think the devs decide what makes sense to work on and in which order. Also the developer employed by AMD not only writes code, he also helps with writing drivers, if there are things unclear in the documentation for example.

Can someone tell me why this code needs to be approved by AMD in the first place? I thought that was the point of putting out the documentation - the devs could base all their work off of that and know that it was OK'd by the lawyers ahead of time. Was the documentation released not enough to do all the work and they are still relying on private info? Or are these devs just AMD employees and have to get everything they do signed off on?

Two main issues :

1. Work on the 3D code started before we finalized a documentation package, so we need to check the header files used by the 3D driver against what we finally released.

2. We borrowed shader compiler code from an in-house driver stack used for pre-silicon hardware testing. Richard ended up re-writing a fair amount of it but we still need to review the contents of that code before release.

That's it -- nothing to do with the developers being AMD employees, just that they were using "unreleased" programming info. All of their remaining work will go directly into the public repositories.