Bringing The R600 Gallium3D Driver Up To Speed

[Jimbo]

It's a pitty to see that expectations about gallium being an unified driver with very common architecture, where vendors only need to implement a "small" winsys part for each chip model... apparently are not achieved, that small chip specific part appears to be, in fact, an huge chip specific part.

[airlied]

It's a pitty to see that expectations about gallium being an unified driver with very common architecture, where vendors only need to implement a "small" winsys part for each chip model... apparently are not achieved, that small chip specific part appears to be, in fact, an huge chip specific part.

I hate to be a dickhead, but citation needed.

Nobody ever said gallium was going to be that.

The pipe driver has always been gpu specific, with the winsys being a GPU+OS specific interface.

Like large parts of how GPUs work can be common, but even larger parts are GPU specific. Its not like general purpose CPUs in that the GPUs generally take a lot of shortcuts for the sake of speed that a general purpose device could never take.

Dave.

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

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

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

[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]

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]

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

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

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