Bringing The R600 Gallium3D Driver Up To Speed

[bridgman]

I don't want to hinder anybody's efforts. I was referring to the fact that so far you always said that you have 3 oss devs (which unfortunately decreased to 2 about half a year ago) and in addition only Alex's work is apparent to oss *consumers*. So I guess I was more like "you should not be proudly say we have 3 devs when it actually comes down to be just 1".

I guess I don't understand how you can ignore Richard's and Cooper's work. Anyone using 3D on 6xx/7xx is using their work, and Richard was working on GLSL right up until the end of last year. If you're saying that anyone not making a public commit every week is "dead to you" I guess that's OK, but I don't understand it.

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.

The information required for dynamic PM has been out for over a year already; it's hardly something that only AMD could work on. Alex was working on dynpm mostly because he was interested in it, and partly because we needed to have at least something equivalent to ForceLowPowerMode for KMS users.

Seems like I'm disagreeing with everything you say today; sorry about that

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.

That's the part that baffles me - our commitment never included providing the manpower in the first place, so how does lack of manpower constitute "falling behind on our part" ?

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.

The power management functionality in fglrx is woven all through millions of lines of code. There's a core module which handles hardware settings but Alex & Matthew had that part figured out early. You can't just "take the power management bits out of fglrx" and plug them into the open source stack - removing a Goa'uld symbiote would be easy by comparison.

With respect, I think you may be underestimating the complexity of writing a modern graphics driver.

[bridgman]

It seemed from outside they were sometimes pretty lost having no idea what is causing a certain problem. It was my impression, I might as well be wrong on this. Only Alex can tell this.

Welcome to driver development.

Alex has access to internal devs and architects, including both hardware and software teams. Even so, I didn't get the sense that Alex and Matthew were fighting "lack of hardware knowledge" problems as much as trying to find the right design approach for integrating PM into the new KMS stack and making that new design actually work.

The approach they ended up with is different from fglrx, but it allows one implementation to be used across many generations of GPU, while the fglrx driver uses different approaches depending on the GPU generation. This makes the open source drivers more maintainable over a long period of time.

HokTar, I don't really understand your previous comments. If you look back, any time anyone "proudly said there were three devs" there actually *were* three devs, so I don't see what's wrong with saying that at the time. Ditto your comments about management; are you saying that management is doing something wrong because we are not funding the entire open source development effort ourselves on top of the fglrx work which drives most of our sales ?

I really don't think Corbin's comment about getting a driver working in three months was for a *useable* driver, just for the basic framework which could then evolve into a useable driver over time.

[nanonyme]

It seemed from outside they were sometimes pretty lost having no idea what is causing a certain problem. It was my impression, I might as well be wrong on this. Only Alex can tell this.

Well, yeah. Even if you have someone who might theoretically know answers, finding out the right questions is a real bitch.

[HokTar]

How alone in the dark is he, really? I mean, he has an NDA meaning he can talk to other in-house engineers without that much of legal problems, just means there's some IP checking scrutiny sometimes when he wants to release.

It seemed from outside they were sometimes pretty lost having no idea what is causing a certain problem. It was my impression, I might as well be wrong on this. Only Alex can tell this.

[HokTar]

@ bridgeman & agd5f:
/* You probably already hate me, but in case you still read this... */

I think there's another layer of misunderstanding here which I'd like to clarify. So when I wrote AMD should not be proud I was referring to the leadership/managerial level. I forgot to think as if I were in your position so it was not obvious. My apologies for this.
But I still think AMD could improve in the oss area. If they thought they'll need 3 devs and "loose" one replacing him in 6 months should be the least.

What you guys have done is awesome as I myself and several others pointed out so many times. Obviously, you must be proud of your work.

[nanonyme]

So in the end Alex wouldn't have been alone in the dark. (Well, Rafal at least has been there, too

How alone in the dark is he, really? I mean, he has an NDA meaning he can talk to other in-house engineers without that much of legal problems, just means there's some IP checking scrutiny sometimes when he wants to release.

[HokTar]

Code btw fglrx & opensource can't be shared, people shouldn't believe that cut & paste btw 2 different driver can work. AFAIK fglrx has a radical different design from radeon KMS. So all the infrastructure that dynamic power, or other features, need is too different to share code btw the 2 drivers.

In my experience, code reuse on big complex project is a myth.

Well, I never sad open up fglrx, that's bullshit. Also, I take your word for code sharing. What I tried to explain was that the fglrx devs already know how to implement sync to vblank when changing clocks, what are the possibilities, common problems, shortcomings or similar stuff. So in the end Alex wouldn't have been alone in the dark. (Well, Rafal at least has been there, too )

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).

I never expected r600g to be here overnight. But Corbin mentioned on this forum that he needed ~3* month to bring up a working driver all on his own with the docs. So I do hope you will reach that point soon. Until that I keep hitting refresh in your personal repo.

* He wrote developer months and I know that you are working on several projects. Sorry, I just can't help being impatient. I cheer for you!

[nanonyme]

glxgears is not a benchmark.

Then again, you could hypothesize that since KMS is said to be somewhat more CPU-intensive than UMS at the moment (unless this is obsolete information), it would be very apparent in glxgears since glxgears fps mostly depends on how fast your CPU is.

[Luzipher]

I don't think there's enough news to provide an update on anything like that frequency. I reported last fall that Cooper had been pulled off onto another project, and it's now looking pretty definite that he won't be coming back to open source graphics (so I reported that), but there wasn't really any news in between to report.

Sorry to bring that up again (from page 3), but to clarify what I meant: It would even be good to know that nothing happend for a while, than not knowing anything.

So, even news like "Not much happened in the last 2 weeks" or "Richard made little progress, Alex is on vacation" would be nice. It's not about _if_ there is something to report, but a predictable frequency of reports :-)
(and this shall not be a request, but merely a suggestion I'd personally like)

[pingufunkybeat]

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!

glxgears is not a benchmark.