AMD Pushes Out New R600/700 3D Code

[89c51]

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

my mistake



sorry again

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

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

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

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

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.

So while it's not the complete focus of Gallium3D, it *will* allow "generic" cards to use it? I can only hope these generic features will be quite good, and that effort will focus on improving the API so that "generic" cards can be extremely good, featureful, and fast, hopefully to the point at which AMD, Intel, Nvidia, and others can release "generic" cards which won't even require any driver updates.

Plug-n-play, like UVC/firewire/etc, is what I'm hopin' for. Greatly simplifies life for everyone. ^^

[nanonyme]

So while it's not the complete focus of Gallium3D, it *will* allow "generic" cards to use it? I can only hope these generic features will be quite good, and that effort will focus on improving the API so that "generic" cards can be extremely good, featureful, and fast, hopefully to the point at which AMD, Intel, Nvidia, and others can release "generic" cards which won't even require any driver updates.

Plug-n-play, like UVC/firewire/etc, is what I'm hopin' for. Greatly simplifies life for everyone. ^^

The way I understood it was that you do have to write a basic card-specific driver for Gallium but the benefits come on high level. As in, every card that has a Gallium driver gets to benefit of all state trackers. As in, you do need to have a card-specific basic access (including KMS and memory manager) to the card but higher level stuff (including access to for X.org (whatever it means, I don't exactly know; I'd guess 2D accel), DRI2, video acceleration using Motion Compensation etc) are done with the state trackers - and might from one perspective come for free. Especially after Gallium matures, a completely new card that someone writes a Gallium driver for would immediately tap into a set of powerful working state trackers so it's a big future investment.
A developer can correct me if I was misleading or imprecise.

[bridgman]

Yeah, there isn't really such a thing as a "generic" graphics card or GPU (ie one with a standard programming model or register set shared across multiple vendors), and it seems unlikely there will ever be one.

The programming model for each GPU is constantly evolving, primarily to support new programming standards, both for graphics and for compute. The drivers have to keep changing at the same pace, in order to provide a standard API to other parts of the graphics stack.

[elanthis]

Even individual CPUs, bus architectures, and so on need specific drivers. Even the "generic driver" interfaces that exist (intel-hda, ac97, usb) all end up having tons of per-device tweaks and fixes. Generic is pretty pointless. It's done in the industry as is mostly to save time on engineering, not for consumer or FLOSS friendliness.

[monraaf]

Anyone success with the latest commit? I had to disable gallium to get it to build. But running glxinfo now gives me:

Fatal error in __driConfigOptions line 284, column 0: illegal default value: DRI_CONF_FP_OPTIMIZATION_SPEED
Aborted