There are many more readers than members

[HokTar]

@bridgeman:

It seems you missed my posts around #27 and #30. Or maybe they are not worthy to answer. No problem in that case either.

@everybody

Seriously guys, why are we talking about flamewars or almost-flamewars? This forum was interesting to read up until a couple of weeks ago.
Can't we just stop it because it is pretty obvious that it is not going to lead anywhere?

Why don't we talk about if the r600g can pass glxgears? If there's someone to work on opengl 3.x during the summer? If power management can change voltages and pci lanes? Etc, etc.

[Hans]

@bridgeman:

It seems you missed my posts around #27 and #30. Or maybe they are not worthy to answer. No problem in that case either.

@everybody

Seriously guys, why are we talking about flamewars or almost-flamewars? This forum was interesting to read up until a couple of weeks ago.
Can't we just stop it because it is pretty obvious that it is not going to lead anywhere?

Why don't we talk about if the r600g can pass glxgears? If there's someone to work on opengl 3.x during the summer? If power management can change voltages and pci lanes? Etc, etc.

You just asked the three most important questions in my opinion. Can we get a dev to answer that?

[bridgman]

I saw them but plans for most of the questions you asked are still under discussion. It's likely that GL3 will build on Gallium3D but I don't think the Intel devs are comfortable with that yet, and the whole "new GL3 doesn't include old GL support unless you run in compatibility profile but that means you need multiple drivers or need to run in compatibility profile all the time which kinda defeats the purpose of cleaning up the GL API" discussion is just starting now. I don't think we're at the point where ETAs make sense, just "everyone's working on the plan and developing the low-hanging fruit in parallel".

I don't think there are any real app dependencies on GL3 yet so we had been concentrating more on shorter term things like PM and Evergreen support.

All of the dependencies which are understood are maintained in the ugly little chart at the bottom of RadeonFeature.

[HokTar]

You just asked the three most important questions in my opinion. Can we get a dev to answer that?

Obviously these were not direct questions, anyway. Some heads up are always appreciated, though.

On the other hand I think we all know the answers which are "not yet" for all questions. Please reread my previous post to understand my point!

[bridgman]

I'm sure glisse will update his blog when 600g runs gears.

No plans that I know of for GL 3 work over the summer but *those* plans are just being discussed now as well

Reducing voltage requires that you first reduce engine and memory clocks. Right now I believe the focus is on reliably reducing engine and memory clocks. PCIE lanes are probably orthogonal but don't think anyone has looked at reducing them on the fly yet.

[bridgman]

Obviously these were not direct questions, anyway. Some heads up are always appreciated, though.

On the other hand I think we all know the answers which are "not yet" for all questions. Please reread my previous post to understand my point!

I guess what I'm saying is that everything we know *has* been communicated, and that you're asking for a concise summary of plans which have not been made yet...

... and as a result you ain't gettin' them

[HokTar]

I guess what I'm saying is that everything we know *has* been communicated, and that you're asking for a concise summary of plans which have not been made yet...

... and as a result you ain't gettin' them

You know that my only problem is that you say nothing about the plan which we discussed in February and I referred to that in my first post in this thread. Back then you said (or wrote actually) that it is on your todo list.

I might have made one mistake: I mentioned the (almost) banned word "ETA".

Could you please just ignore that and outline a "roadmap"?

I tried to give an example of what I mean but maybe that is not a good/feasible one. As an engineer I trust other engineers (at least those who proved themselves worthy of it ) so I think you can figure out an intermediate solution.

Thanks for your time, anyway. I really appreciate it.

[HokTar]

Edit: I tried...

I might be in a misunderstanding. Are you really saying that there is no such roadmap? So everyone is just "cluelessly" developing what he feels a good next step?
(I might exaggerate here a bit but I hope those involved get my point.)

[bridgman]

Sorry, I'm drawing a blank on what that plan was. Or did we just discuss the need for a plan ?

You mentioned in your first post from this thread that the order of implementation was essential, but that is going to become increasingly hard to provide now that the re-architecture work (which enforced a degree of sequentiality on the deliverables) is largely completed.

A year ago I was able to give you a pretty good summary of the sequence in which work would be done, but that sequence was determined by architectural constraints ("first you pillage, *then* you burn") not because I could control (or even predict) what the community developers would be doing.

Now that the transition from "old stack" to "new stack" is largely completed, we're back to the normal style of open source development, where new features and initiatives are largely independent of each other and progress depending on the degree of interest each developer has in a given area.

I can tell you the priorities that AMD is setting for the short term (Evergreen, getting ready for Fusion, supporting the other devs which probably touches on all the areas a bit) but that's really the only things we can predict with any confidence.

Put differently, the roadmap now has a lot of parallel lines with little arrows heading off to the right, all running more or less independently.

[bridgman]

What I'm saying is that there are far fewer dependencies between areas than there was during the last two years, so the *rate* of progress of each area is much harder to predict.

Back when everyone agreed that A had to be implemented and working before it made sense to spend much time on B you could count on most of the devs helping with A.

Now that D, E and F are all independent there's no reason for everyone to work on D first, and the allocation of time between D, E and F will be largely determined by "what the developers feel like working on".

So... the *design* aspects are still as coordinated as ever, there's just less need for coordination because invasive work on the really interdependent parts of the stack has largely been completed.