Open-Source ATI Evergreen Acceleration Builds Up

[monraaf]

It's a tossup which will be harder for the developers - making the card run reliably over AGP or making the card light up in the cardboard box.

How close is the cardboard box to the computer ?

About 6 feet. But I guess either option would be easier than to make the card work reliable with fglrx

[markg85]

and have cleared AMD's legal review.

I don't get that part... Why does the OSS driver needs any clearing from AMD's legal stuff?

Other then that. Awesome to finally see the early beginnings of 2d acceleration in the evergreen cards. I can certainly use it for my card ^_^

[Ex-Cyber]

I don't get that part... Why does the OSS driver needs any clearing from AMD's legal stuff?

It's (partly?) written by AMD employees who have access to internal info. AMD thus has to review the code to make sure that it only reveals "safe" information (e.g. not breaching NDAs that AMD has with other companies and not revealing details of DRM-related features).

[curaga]

One thing I've wondered about legal review of code is that doesn't that need people who are both lawyers and programmers?
Damn, they must have some huge salaries

[hanglekuk]

Radeon Feature Wiki page

Somehow RadeonFeature page at Xorg Wiki feels abandoned:
RadeonFeature (last edited 2010-02-28 22:27:45 by Louise Hoffman).

Would anyone care to update info?

[bridgman]

I don't get that part... Why does the OSS driver needs any clearing from AMD's legal stuff?

It's just the release of programming information (register offsets, bitfields, function of those fields etc..) that needs to be cleared. The activity is usually called "legal review" but think of it as "required by legal" rather than "performed by legal".

It's (partly?) written by AMD employees who have access to internal info. AMD thus has to review the code to make sure that it only reveals "safe" information (e.g. not breaching NDAs that AMD has with other companies and not revealing details of DRM-related features).

Exactly. It's primarily a technical review, done with an understanding of the legal issues. We're also looking for things like details of new product generations and hardware features. The basic idea is to draw a line between "how to program the chip" (which we want to expose) and "how the chip is implemented" (which we want to keep secret).

The initial preparation of code/docs is done almost entirely from internal hardware design information, even reading the hardware emulation code that was written a year or two before first silicon. Sometimes that's the best way to understand exactly how the hardware works.

One thing I've wondered about legal review of code is that doesn't that need people who are both lawyers and programmers?

Pretty much; they don't have to be actual lawyers but that is the kind of knowledge that's needed to make the reviews effective. You can do the reviews without those hybrid skills but it's very slow and painful. The requirement for an unusual combination of skills is IMO one of the things that holds companies back from supporting open source development.

[Louise]

Are there news on the Feature Matrix front?

http://www.x.org/wiki/RadeonFeature

Or perhaps an overview of the priorities are right now?

[bridgman]

The major blocks - "2D features", "Mesa 3D features" and "Gallium features" - seem to be correct, although it's possible that some of them could move to "Done" (we're not very good at deciding when to make that last transition). The big change over the last month or so has been going from "WIP with no visible sign of progress" to "WIP - oh look, code !" but not enough to move any of the WIP cells to Mostly.

In the last two blocks - "Output" and "Other" - I imagine that all of the "WIP" cells should probably read "Mostly" (but I haven't had a chance to test myself) and the "TODO" cells should read either "WIP" or "Mostly". Maybe someone who actually *has* a dual-link DVI display or a DisplayPort monitor could comment or update the page.

We probably need to update the definitions to make it clear whether "Done" means "Done in released drivers" or "Done but you need to build from git right now". I would update it but I'm not sure what current thinking is, will ask the IRC folks. Clarifying that would probably help make the transition from Mostly to Done a bit crisper.

[bridgman]

Right now I imagine every dev has a slightly different set of priorities, so it's probably safe to assume that work is happening pretty much everywhere with the possible exception of video decode acceleration. From an AMD point of view our priorities are (a) hardware enablement for Evergreen GPUs (b) getting ready for the upcoming Fusion parts (Evergreen support is a key part of that) and (c) supporting the other community devs in whatever *they* are working on (which is usually different stuff).

[smitty3268]

Right now I imagine every dev has a slightly different set of priorities, so it's probably safe to assume that work is happening pretty much everywhere with the possible exception of video decode acceleration. From an AMD point of view our priorities are (a) hardware enablement for Evergreen GPUs (b) getting ready for the upcoming Fusion parts (Evergreen support is a key part of that) and (c) supporting the other community devs in whatever *they* are working on (which is usually different stuff).

Does (b) mean there's a plan to support Fusion by the time it's released like Intel is able to do with their new hardware? Or are you just trying to get into a position where adding support afterward comes quicker than it has with Evergreen?