AMD Pushes Out New R600/700 3D Code

[bridgman]

That's one of the goals of Gallium3D. If it works as hoped, it reduces the amount of device-specific acceleration code significantly and puts it all in one place.

The current Gallium3D implementation assumes the existence of DRI2, which in turn requires video memory management in the kernel. Once that is stable and merged into the upstream kernel tree you should see greater progress with and usage of Gallium3D by both the 3D and X drivers.

There's a reasonable chance that most cards will be able to use a "generic" X driver which uses KMS for modesetting and Gallium3D for 2D and video acceleration.

[Yfrwlf]

Could always be better...

This is great, though it's still programming for a single chipset. What is needed is a standardized unified driver system for graphics cards like what exists for USB devices now, and like other standards such as firewire. Graphics card makers need to form and support open graphics driver standards so that driver development isn't wasted by only being compatible with specific card chipsets. If you combined the devs in the various driver projects under a single umbrella, Linux graphics would be in a much better state today.

[lucky_]

I've just seen that Google released a plugin for some browsers to be able to render 3d. It requires opengl 2.0, maybe it's time to ask them to contribute with manpower to the development of free drivers.
I understood they were pushing hard amd and nvidia for open drivers, now that they want the web to take advantage of opengl, pushing open source drivers could be a good way to promote their plugins, by offering a more out of the box experience ?

[nanonyme]

Why should anyone care?

Now now, of course people should care. It's just not an imminent matter and can be safely ignored for the time being. (maybe even for years)

[89c51]

sorry i got confused with all the mesa radeons 2D 3D stuff

my mistake



sorry again

[elanthis]

what happens with radeonhd ??

Why should anyone care?

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

[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

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

[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