AMD Pushes Out New R600/700 3D Code

[nanonyme]

RE: Radeonhd


One good thing about radeonhd is that it allows output of sound over hdmi. Radeon-ati doesn't do that, or at least I haven't easily figured out how to make it work. As catalyst is not working with the 2.6.29 kernel (without patching), radeonhd is an option unless 3D acceleration is required.

It only doesn't do that because no one has yet had spare time to port the functionality over afaik. Iirc someone said it wouldn't be a big task but quite frankly I understand if it atm isn't a priority. I'm confident it will eventually happen. (in the meantime your argument is valid)

[forum1793]

RE: Radeonhd

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)

One good thing about radeonhd is that it allows output of sound over hdmi. Radeon-ati doesn't do that, or at least I haven't easily figured out how to make it work. As catalyst is not working with the 2.6.29 kernel (without patching), radeonhd is an option unless 3D acceleration is required.

[nanonyme]

Which branch did you build ? Richard's latest push in 6xx-rewrite was just work-in-progress, still a bit more to do before it runs.

We're trying to keep the ported code visible even if it's not actually making triangles yet.

No sweat imo, it was already nice to see the rewrite effort going somewhere.

[monraaf]

Yeah I'm using r6xx-rewrite now. I guess I have to wait a little longer...

[bridgman]

Which branch did you build ? Richard's latest push in 6xx-rewrite was just work-in-progress, still a bit more to do before it runs.

We're trying to keep the ported code visible even if it's not actually making triangles yet.

[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

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

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

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

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