Originally posted by bridgman
View Post
Announcement
Collapse
No announcement yet.
Bringing The R600 Gallium3D Driver Up To Speed
Collapse
X
-
Originally posted by deanjo View PostI was referring more to the "not to write and release the drivers ourselves." .
Comment
-
Ahh, yes. That part
In terms of perception, I don't think it's working at all. The development community understands, and we're all sending out a consistent message, but I don't think that message is being broadly understood. I guess part of the reason is that we have taken a different approach from the other hardware vendors, but I think that's OK since no two vendors were doing the same thing before
The other problem is that right after we started the project the community launched into the whole KMS/GEM/TTM/DRI2/Galilum3D re-architecture effort, which sucked up almost all of the non-AMD community devs so we ended up focusing on implementing initial support for new generations of GPUs.
Now that the rearchitecture work is largely finished we're starting to see the community developers building new features on top of the new architecture, so it's a lot easier than a year ago to see how much the community is contributing.
Ask me again in a yearTest signature
Comment
-
I do *so* much miss the ability to edit. How did I end up with three smileys in one post ?
Originally posted by kgonzales View PostYeah I guess they should do that since the open source community is falling down at developing most of the hard part of open source. The cries of "gives us the docs and we will do the work" seem to not be working out.
On the other hand, *outside* the development community I think most people underestimated the complexity of writing a modern graphics driver, and expected a complete, polished driver stack to appear in a matter of months. The reality is different, of course -- a full featured graphics driver stack is *millions* of lines of vendor-specific code, and even the current open soruce stack has perhaps 1/4 million lines of new or substantially modified code, plus perhaps a million lines of common code shared between HW vendors.
Overall, I think it's worked out roughly the way we expected.Test signature
Comment
-
Originally posted by kgonzales View PostYeah I guess they should do that since the open source community is falling down at developing most of the hard part of open source. The cries of "gives us the docs and we will do the work" seem to not be working out.
I'm sure a lot of people would actually prefer some quality documentation (e.g. same quality as Intel Architecture processor docs) for ATI graphics cards over the source and header files.
Comment
-
Originally posted by monraaf View PostI'm not sure what documentation exactly you're talking about. AFAIK ATI/AMD has never released full documentation of their graphics cards, and for Evergreen they have released almost none. They have chosen themselves to release programming information in the form of header files and source code.
I'm sure a lot of people would actually prefer some quality documentation (e.g. same quality as Intel Architecture processor docs) for ATI graphics cards over the source and header files.
People always claim better docs will help but mostly I've found better docs just lead to better excuses.
Dave.
Comment
-
I hope the Gallivm3D r600 driver will really make the difference about performances. Today I switched to KMS(I have an ATI Radeon HD4850) with linux 2.6.33.3+(all the patches that are going to make release .4 that applied without failing), libdrm v2.4.20, mesa v7.8.1, xorg ati drivers v6.13.0. The performance of glxgears dropped from previous(UMS) 3207 to now(KMS) 2197!
Comment
-
Originally posted by bridgman View PostApart from ignoring Richard and Cooper's work (little things like the 6xx/7xx 3D driver), why is this something we should not be proud of ? On the closed source side we write the drivers; on the open source side tha plan was always to work with and support the developer community, not to write and release the drivers ourselves.
EDIT - Alex beat me again ;(
And some more about this "be proud" thing. Alex is doing an awesome work, granted. But still, evergreen is pretty much nowhere near, dynpm is far from being finished - I think this is AMD's side right now. On the oss side Jerome is writing r600g and Marek and Corbin *almost* finished r300g while Dave started so many projects to add some interesting features.
All in all, I had the feeling that AMD is falling behind on its part - in my opinion due to lack of manpower - and thus I said what I said. My intention was not to insult you or anyone, but it felt more like stating a fact that the oss side is currently doing a better job. Again, it's not your workers' fault but seems to be the lack of coders.
Providing the docs is much appreciated and seems to work just fine. I don't expect AMD to write all the drivers, but for example you should have done that with dynpm - just publish the powerplay bits of fglrx and don't make Alex and co. spend months to figure out how it works.
Please feel free to point out my mistakes and also to disagree.
Comment
-
Originally posted by HokTar View Post[...]
Providing the docs is much appreciated and seems to work just fine. I don't expect AMD to write all the drivers, but for example you should have done that with dynpm - just publish the powerplay bits of fglrx and don't make Alex and co. spend months to figure out how it works.
Please feel free to point out my mistakes and also to disagree.
In my experience, code reuse on big complex project is a myth.
And as John stressed out you don't write a full GL driver over a night no matter how good the doc you have are. Do you think someone with the intel doc on CPU can write a kernel over a night, a week, a month ? This kind of thing takes time (a GPU driver is as complex or maybe even more complex than a kernel, AFAIK fglx source code is bigger than linux kernel source).
Comment
Comment