AMD Pushes Out New R600/700 3D Code

[Louise]

More like 3-4 years for a new generation. We're already hooked into future GPU development work so the delay from intro to open source driver support should be shorter than for previous generations when we were mostly playing "catch-up".

So the future is being made today

One of the big changes with 6xx was at least partially separating the programming model from the hardware implementation, so big changesa in the hardware have relatively less impact on the driver than in previous generations. 6xx and 7xx are very different hardware implementations but the programming interface is pretty similar. The downside was that it took a lot of work to get drivers running on the new programming model in the first place, but we're mostly past that now.

It is much appreciated nevertheless

The discussion about "separating" was for DRM and UVD, shouldn't have any impact on 3D. I obviously can't comment on status.

Reading Wikipedia it sounds like quite a complicated task!

http://en.wikipedia.org/wiki/Unified_Video_Decoder

[Qaridarium]

Bridgman shared in a post for some time ago, that the whole problem of releasing the 3D specs was the DRM (Digital Restrictions Management).

For the R800 this was taken into account, so the 3D stuff and DRM was separated.

So the R800 will maybe not (?) share much with R6xx and R7xx ?

No! 3D is free! UVD the mpeg2 und generaly the viedeo part has the DRM di-re-ma part in it!

so amd do not have bring the spec for the viedeo render part! becourse they can't

the R800 will Hopefulle chance this but AMD run's Out of money so i think amd can't chance this!

so i think... they bring DirectX11 by driver and microcode update to the rv740!

and the don't chance the UVD part in the R800--- but if they have more money again the will chance this in the future. --->R900

[viddak]

Hi,

Do you know where the source code is published?
Is it in mesa repo? I found two branches, r6xx-r7xx-support and radeon-rewrite.

Is it in these?

[bridgman]

The 3d code is in r6xx-r7xx-support. The radeon-rewrite branch is where airlied and others are adding support for running over a drm with memory manager and kernel modesetting (KMS/GEM/TTM).

There is a third branch, r6xx-rewrite, which is where we made a copy of radeon-rewrite and have started porting the 6xx/7xx 3d code into radeon-rewrite -- so the name is a hybrid of 6xx-7xx-support and radeon-rewrite

[duby229]

The 3d code is in r6xx-r7xx-support. The radeon-rewrite branch is where airlied and others are adding support for running over a drm with memory manager and kernel modesetting (KMS/GEM/TTM).

There is a third branch, r6xx-rewrite, which is where we made a copy of radeon-rewrite and have started porting the 6xx/7xx 3d code into radeon-rewrite -- so the name is a hybrid of 6xx-7xx-support and radeon-rewrite

So these are not different drivers then, just different branches of the same code base?

[agd5f]

So these are not different drivers then, just different branches of the same code base?

The r6xx-r7xx-support branch is the current 3D driver code we had internally which was started before Dave started reworking the radeon 3D driver code in the radeon-rewrite branch. We decided it would be easier going forward to rebase the r6xx/r7xx 3D driver on the radeon-rewrite code base. To do so, I created a new r6xx-rewrite branch that's based on radeon-rewrite. Over the coming weeks we'll be porting the code in r6xx-r7xx-support over to r6xx-rewrite. At the moment, there is no r6xx/r7xx specific code in r6xx-rewrite. So far it's all been infrastructural work to get the branch ready for r6xx/r7xx hw specific code.

[bridgman]

And here's the "Readers Digest" version :

* master - no 6xx/7xx, doesn't work with memory manager

* radeon-rewrite - no 6xx/7xx, works with memory manager

* 6xx-7xx-support - works with 6xx/7xx, doesn't work with memory manager

* 6xx-rewrite - merge of the previous two branches, so will have 6xx/7xx *and* work with memory manager once finished

The most likely sequence of events is :

1. radeon-rewrite merges to master, adding memory manager support for 5xx/690 and below

2. 6xx-rewrite merges to master, adding 6xx/7xx support

If, however, the 6xx/7xx port to rewrite goes more quickly than finishing radeon-rewrite, the sequence would be :

1. 6xx-rewrite merges to radeon-rewrite

2. radeon-rewrite merges to master

[duby229]

Well, I gotta be honest here... Readers Digest definitely helped me..

That makes sense. I can certainly understand the values of a well thought out project that goes exactly according to plan. Every new network I assemble is different, and requires a bit of planning to get it in working order.

Taking an object that is one way and making it communicate with another object that is a different way. I guess APIs and networks have something in common.

[89c51]

And here's the "Readers Digest" version :

* master - no 6xx/7xx, doesn't work with memory manager

* radeon-rewrite - no 6xx/7xx, works with memory manager

* 6xx-7xx-support - works with 6xx/7xx, doesn't work with memory manager

* 6xx-rewrite - merge of the previous two branches, so will have 6xx/7xx *and* work with memory manager once finished

The most likely sequence of events is :

1. radeon-rewrite merges to master, adding memory manager support for 5xx/690 and below

2. 6xx-rewrite merges to master, adding 6xx/7xx support

If, however, the 6xx/7xx port to rewrite goes more quickly than finishing radeon-rewrite, the sequence would be :

1. 6xx-rewrite merges to radeon-rewrite

2. radeon-rewrite merges to master

what happens with radeonhd ??

it might be a stupid question but i though that the code -when it was made available- would be simply merged to radeonhd and radeon

[nanonyme]

what happens with radeonhd ??

it might be a stupid question but i though that the code -when it was made available- would be simply merged to radeonhd and radeon

No, this has nothing to do with the X drivers. It only has to do with the 3D drivers in Mesa.