Open ATI R600/700 3D Graphics For Christmas?

[elanthis]

Would be nothing but a burden!!! are you Fing kidding me????

I am absolutely serious. What the hell do you expect people to contribute? White-space fixes and comment typo corrections to toy demo code that was intended to be thrown away, used only to verify and validate the incomplete and inaccurate documentation? Yeah, I'm sure the AMD folks are just gunning to spend time reviewing those patches.

When AMD has a real, working driver that's actually ready (for the highly adventurous) to use, it would of course be useful for said driver to be Open. Right now, I can't possibly imagine any contribution anybody is going to make that is going to be remotely helpful, especially when you consider that almost every skilled and interested developer is already working on the project through AMD, Novell, or Red Hat.

Aside from the core developers of the projects, there isn't a flood of people submitting useful stuff to Intel, nor a mass of talented hackers improving the existing ATI driver, nor a group of rockstar coders bringing the Nouveau driver into a useful state. When the new AMD driver is finally Opened up, I will bet you money that every single truly useful and noteworthy contribution is going to continue coming from the exact same people working on the private repos right now. Just like the Intel driver is still developed almost exclusively by people with an @intel.com or @redhat.com email address.

Yes, AMD will certainly benefit in the long term from having an Open Source driver. No, I do not believe that AMD would benefit from having an Open Source repo of experimental demo code and a bunch of inaccurate and incomplete hardware documentation available to the public.

Most projects don't actually put any code or docs up until they have something actually useful. The kind of developer that makes a public repo the day he starts a project is the kind of developer that abandons his SourceForge account with a still-empty CVS repo six months after he created it. The only reason we're even having this conversation at all is that AMD is publicizing this project before it's at a useful stage, which is uncommon. Most projects materialize on the Internet as an already partially-useful code drop; I see no reason why AMD's driver should be any different just because it's high profile.

Heck, let's play it your way. I have some new AMD driver code! Send in your patches so we can get this rolling ASAP! Here's what I have so far:

/* AMD driver.  Copyright (C) 2008 Everyone.
 Released under the X license. */

#include <stdio.h>

int main(int argc, char **argv) {
  printf("I'm an AMD driver project. Release early, release often!\n");
}

Bonus points to anyone who can send in a patch for the first bug in our Open Source GPL driver! Never mind that I see it and could fix it in less time than it will take for you to even read its four lines of code.... patches from other people are useful!!!!

[bridgman]

-int main(int argc, char **argv) {
+int main(int argc, char *argv) {

But I already have access to the repo

Seriously, elanthis is explaining things more clearly than I was.

The project is not at the point where it would even benefit from testing yet - we're still writing the initial actual driver code and getting it to work for the first time, and writing the documentation as we get each part figured out. If everything works out, we should get through the IP review at about the same time we have the first working driver code to release. In the meantime, 10-ish developers have access to the repository but only 4 have had time to actually contribute anything or even look at the contents.

I would prefer that the work be completely in the open if only because closed work tends to make people suspicious, but as long as we get the IP and code out into the public soon I don't think we will have lost much in terms of potential progress or contributions. It's probably fair to say that "we started talking too soon" rather than "we opened up too late" but my view is that we should be telling you what is going on even if we can't show you anything yet. If I had known how long it would take to get the new 3d engine working enough to write useful documentation I probably wouldn't have said anything until maybe October, but I can't go back and change that now.

FYI, current thinking is that the first release will include X driver code for EXA and Xv, drm code to support the X driver, the r600demo program (which also runs over drm), and register specs for the 3D engine. We have a pretty good list of what needs to be done for 3D support but there is a lot of code to be changed and I don't think we will be very far into it by the first release (assuming we can get the first release out as quickly as I hope).

[rohcQaH]

Bridgman just broke the latest SVN Version of the new, better(tm) Open Source R700 driver. Proposed patch for fixing:

-int main(int argc, char *argv) {
+int main(int argc, char **argv) {

printf("I'm an AMD driver project. Release early, release often!\n");
+return 0;

Proposed patch for fixing bridgman's coding: more coffee

just kidding. Thanks for your work, bridgman, I prefer waiting while knowing what's going on to waiting in the dark. Noone here likes the problems that are delaying the release, but you're doing an awesome job of communicating, making the problems understandable and the waiting bearable.

[Kjella]

Seeing is believing

-int main(int argc, char **argv) {
+int main(int argc, char *argv) {

But I already have access to the repo

You're not exactly making a good argument that the right people have repo access... or maybe my humor detector is off. At any rate, it's not so much the waiting coders but more that seeing is believing since we've been told umpteen times that it's not possible to release full specs because of IP licensing agreements, DRM concerns and so on and so forth. Open specs to the latest generation of graphics hardware hasn't happened in a long, long time. I know there's been quite a bit of information released already but not the most important ones.

Until it does happen, everyone on the outside hears promises but fears that legal one day puts the foot down "Sorry, but there's just no way of doing this without an NDA, you'll just have to scrap the idea". I know that might seem very unlikely from where you're sitting, but the rest of us want confirmation that "Yep, they're REALLY doing it" even if the code isn't quite up to par just yet. There's been too many tales told of Linux support (I don't mean AMD, but in general) that just never materialized.

[Linuxhippy]

I hope once out, RadeonHD will have full support for RENDER accaleration (at least full composite support) on R6/7xx
Gradient and Trapezoid accaleration would be welcome too, Gradients eat a lot of CPU for themes using them.

[bridgman]

You're not exactly making a good argument that the right people have repo access... or maybe my humor detector is off.

Auggh. I forgot the stinkin' brackets. That's what happens when you don't build and test patches before posting

New patch to fix the last one :

-int main(int argc, char *argv) {
+int main(int argc, char *argv[]) {

I was trying to make the point that in the esrly stages the patches are as likely to be changes in coding style as they are to be something that actually adds or fixes functionality.

At any rate, it's not so much the waiting coders but more that seeing is believing since we've been told umpteen times that it's not possible to release full specs because of IP licensing agreements, DRM concerns and so on and so forth. Open specs to the latest generation of graphics hardware hasn't happened in a long, long time. I know there's been quite a bit of information released already but not the most important ones.

There's no question; it's a lot harder getting specs out for the latest chips. It's not so much that the IP is more sensitive (although that is a factor), it's that if you screw up you are stuck with the consequences of the mistake for a lot longer so you have to work to a very high standard of care.

Until it does happen, everyone on the outside hears promises but fears that legal one day puts the foot down "Sorry, but there's just no way of doing this without an NDA, you'll just have to scrap the idea". I know that might seem very unlikely from where you're sitting, but the rest of us want confirmation that "Yep, they're REALLY doing it" even if the code isn't quite up to par just yet. There's been too many tales told of Linux support (I don't mean AMD, but in general) that just never materialized.

Earlier in the year (right after the first IP review) it was looking like we might not be able to put out enough info to enable the 6xx 3d engine at all. We were eventually able to work through the issues (I hope) but it was looking pretty grim for a while.

In cases where simply publishing the source code for a working driver is enough to cause problems even an NDA won't help, unfortunately.

[duby229]

I am absolutely serious. What the hell do you expect people to contribute? White-space fixes and comment typo corrections to toy demo code that was intended to be thrown away, used only to verify and validate the incomplete and inaccurate documentation? Yeah, I'm sure the AMD folks are just gunning to spend time reviewing those patches.

When AMD has a real, working driver that's actually ready (for the highly adventurous) to use, it would of course be useful for said driver to be Open. Right now, I can't possibly imagine any contribution anybody is going to make that is going to be remotely helpful, especially when you consider that almost every skilled and interested developer is already working on the project through AMD, Novell, or Red Hat.

Aside from the core developers of the projects, there isn't a flood of people submitting useful stuff to Intel, nor a mass of talented hackers improving the existing ATI driver, nor a group of rockstar coders bringing the Nouveau driver into a useful state. When the new AMD driver is finally Opened up, I will bet you money that every single truly useful and noteworthy contribution is going to continue coming from the exact same people working on the private repos right now. Just like the Intel driver is still developed almost exclusively by people with an @intel.com or @redhat.com email address.

Yes, AMD will certainly benefit in the long term from having an Open Source driver. No, I do not believe that AMD would benefit from having an Open Source repo of experimental demo code and a bunch of inaccurate and incomplete hardware documentation available to the public.

Most projects don't actually put any code or docs up until they have something actually useful. The kind of developer that makes a public repo the day he starts a project is the kind of developer that abandons his SourceForge account with a still-empty CVS repo six months after he created it. The only reason we're even having this conversation at all is that AMD is publicizing this project before it's at a useful stage, which is uncommon. Most projects materialize on the Internet as an already partially-useful code drop; I see no reason why AMD's driver should be any different just because it's high profile.

Heck, let's play it your way. I have some new AMD driver code! Send in your patches so we can get this rolling ASAP! Here's what I have so far:

/* AMD driver.  Copyright (C) 2008 Everyone.
 Released under the X license. */

#include <stdio.h>

int main(int argc, char **argv) {
  printf("I'm an AMD driver project. Release early, release often!\n");
}

Bonus points to anyone who can send in a patch for the first bug in our Open Source GPL driver! Never mind that I see it and could fix it in less time than it will take for you to even read its four lines of code.... patches from other people are useful!!!!

I think you've got it entirely backwards. But there is no point in pointing out the obvious flaws in your logic, because your not gonna change your mind..

EDIT: I read the IRC logs too, and I know that most open development is done by a core set of people, based on testing and specific suggestions made by other people. Without that the end result will be more incomplete, with poorer structure, and riddled with syntax errors. Hell I think the last couple of posts proves that point.

[bridgman]

I hope once out, RadeonHD will have full support for RENDER accaleration (at least full composite support) on R6/7xx

Not sure if it will be in the first release (top priority is getting code and info out to the community) but it will definitely get added soon anyways.

Gradient and Trapezoid accaleration would be welcome too, Gradients eat a lot of CPU for themes using them.

Not sure about timing on this but I imagine both will be easier as a result of using the 3D engine for everything.

Someone will probably have to write a fancy shader to accelerate gradients but we'll be giving out enough info to do that. At first glance I didn't think you could implement gradients with flat shaded triangles because the interpolators are not constrained to X & Y... but I guess if you broke the area into triangles where every triangle had one horizontal and one vertical line then maybe it could work without a shader after all. Someone's going to have fun with that...

I haven't looked at implementing trapezoid support but maybe one of the devs can jump in. Unless I'm missing something it should actually be easier with the 3D engine than the 2D engine 'cause you just have to break the trap down into a bunch of triangles. Not sure if getting the patterns lined up where the triangles meet will be a problem, but in theory the hardware takes care of all that automatically.

[duby229]

There's no question; it's a lot harder getting specs out for the latest chips. It's not so much that the IP is more sensitive (although that is a factor), it's that if you screw up you are stuck with the consequences of the mistake for a lot longer so you have to work to a very high standard of care.

But you see that is EXACTLY the strength that open development brings to the table.Your still gonna have a core set of developers that do most of the work. But nobody is perfect, there will be poorly implemented functions, there will be bad structure, there will be syntax errors, and so on.

That very high standard of care is --FAR-- easier to achieve in an open development model.

[bridgman]

Sorry, not talking about care in context of coding, I'm talking about the IP review we need to complete *before* releasing anything to the open development community. Once we have an IP package that can pass review and release it to the community, then yes I agree completely -- we'll get better code as a result of having it visible to more people.