ATI FAQ, maybe

[leef]

Aw nuts, I just finished replying to your [post] and you changed the whole thing

I don't think duby229 changed anything. First duby reiterated the point from post 3, then repeated the points from the Tearing thread. I think I covered most of those points and your responses either directly or by reference in items 1, 3, 3a, and 7. (Am I 1337 now?)

The whole point of the FAQ is to ask the questions and get the answers only once.

Actually, I think we're all pretty much in agreement with the following possible exceptions:

(I'm paraphrasing here)
duby: ATI would be better off (make more money) if they worked with the open software community to write drivers for all their cards.
bridgman: ATI thinks they need to protect their fancy GL and Powerplay code for the "lucrative" CAD (and MSWindows) market, and
bridgman: ATI's plans for RadeonHD didn't quite work out, but they think they're getting some value now.

There may also be a question of how much responsibility a manufacturer has to provide good drivers. That's a good question, but overly broad for this FAQ.

So, does anyone think we should add the following to the FAQ?

8. What is the real/quick status of improving video experience with ATI on Linux?
A. What we want: Fast OpenGL 2.0 on the lastest card. h.264 acceleration on all cards. Indirect rendering (compiz) and multiple heads with multiple cards. Bullet Proof.
How we're going to get it: X developers are going to eventually create GEM, Gallium, DRI2 and RandR2. ATI will release the R7 docs. Then driver guys can code up OGL 2.0 and h.264.
What's actually happening: While working on getting the R7 docs released, ATI is working with a few developers under NDA to get OGL 1.2 for 7XX with RadeonHD. With some help from ATI, Radeon is being rewritten to use GEM and, later Gallium. Fglrx will take longer to convert to the new X architecture, so will be useful only for special niches - until the next rewrite.

9. Why can't ATI just fix their driver?
A. http://jonsmirl.googlepages.com/graphics.html

Please correct any mistakes or misunderstandings. Or, especially, any changes in status or strategy (like whether Radeon/HD will be combined or split along R5/R6 or ?). I don't think the exact X details are necessary for the GEM/TTM DRI/DRI2 Mesa/Gallium DDX DRM AIGLX EXA interactions here, and we don't really know what we'll end up with yet anyway.

Should be interesting to see which gets done first: R7 docs, OGL 1.2 in RadeonHD, fglrx rewrite.

Have a great weekend.

[bridgman]

I don't think duby229 changed anything. First duby reiterated the point from post 3, then repeated the points from the Tearing thread. I think I covered most of those points and your responses either directly or by reference in items 1, 3, 3a, and 7. (Am I 1337 now?)

I don't think duby229's edit changed the spirit of the post, but the revised post was longer, more aggressive, and had all new words in the middle (which is where I looked). I was very tired and all I saw was that the post looked completely different. I decided to go home rather than stay at my desk and start over

A. What we want: Fast OpenGL 2.0 on the lastest card. h.264 acceleration on all cards. Indirect rendering (compiz) and multiple heads with multiple cards. Bullet Proof.

You actually want Redirected Direct Rendering, not Indirect Rendering. The problem is that like it or not 3D apps normally use direct rendering, and so Compiz can not redirect and composite the output from those apps. Redirected Direct Rendering (which needs DRI2 and memory management) makes it possible for output from direct rendering applications to be redirected and composited, ie no more flicker when using the opengl driver under Compiz.

Are you talking about open source or fglrx here -- fglrx already has fast openGL 2.0 on the latest cards and multiple heads with multiple cards, although the latter is pretty recent and still teething.

How we're going to get it: X developers are going to eventually create GEM, Gallium, DRI2 and RandR2. ATI will release the R7 docs. Then driver guys can code up OGL 2.0 and h.264.

Open source openGL 2.0 is primarily waiting on memory management, not documentation. For 6xx/7xx 3D we will probably release relatively more code than documentation (other than the shader instruction set manual which is already out for 6xx and doesn't change much for 7xx). We have not yet committed to release docs for open source h.264 acceleration, just to investigate at it once 3D is in place.

What's actually happening: While working on getting the R7 docs released, ATI is working with a few developers under NDA to get OGL 1.2 for 7XX with RadeonHD.

The 3D engine docco we are working on is for 6xx/7xx together, since the programming model is pretty similar even if the underlying hardware is very different.

AFAIK the 5xx driver is at 1.3 now and very close to 1.4; initial target would definitely be the same level of functionality for 6xx/7xx. One of our guys is already working on the arb_fp/arb_vp shader code generation.

With some help from ATI, Radeon is being rewritten to use GEM and, later Gallium.

The pacing item here, of course, is implementing GEM and KMS in the DRM component, which is used by both radeon and radeonhd. As you say, though, radeon is being changed pretty significantly to make use of the new features in DRM.

Fglrx will take longer to convert to the new X architecture, so will be useful only for special niches - until the next rewrite.

The nice thing here is that the most user-visible aspects of the new architectural changes (DRI2, for example) are the easiest to adopt into fglrx. That said, fglrx's primary focus is still high performance workstation so any "niche-ing" would be in the niches we are targeting anyways. Could be worse.

9. Why can't ATI just fix their driver?
A. http://jonsmirl.googlepages.com/graphics.html

Not sure I understand the reference to this article. It was written in 2005 and most of the issues it mentions have already been addressed. The main outstanding area Jon talks about is memory management, and we finally have a more-or-less accepted API for that (GEM) and everyone is working on implementing and integrating that as top priority.

Smirl also warns of a day when the 2D engine will be taken away and a big heap of work will be required to shift everything over to the 3D engine. That happened 2 years ago and is the reason why 6xx/7xx acceleration is taking longer than similar efforts on previous chips. It's the transition to doing everything with the 3D engine which makes things complicated -- all of a sudden the 3D engine needs to worry about things like which direction it reads and draws the pixels since we're now using it as a blitter (with potentially overlapped source and destination rectangles) not just as a triangle-monster.

Should be interesting to see which gets done first: R7 docs, OGL 1.2 in RadeonHD, fglrx rewrite.

Pretty much that order, although I would say "R6xx/7xx 3D docs and/or sample code, OGL 1.3-1.4 in Mesa/DRM (the X driver has essentially nothing to do with OGL), fglrx integration of DRI2, KMS etc....

[leef]

I don't think duby229's edit changed the spirit of the post, but the revised post was longer, more aggressive, and had all new words in the middle (which is where I looked). I was very tired and all I saw was that the post looked completely different. I decided to go home rather than stay at my desk and start over

Honestly, I knew all that but ignored it in a misguided attempt to concentrate on items which should be improved or added to the FAQ. Sorry. My Fault. Why are you working on Saturday?

You actually want Redirected Direct Rendering, not Indirect Rendering. ...

I should have looked this up instead of guessing. The whole idea of the FAQ was to avoid having you write these corrections. But thanks.

Are you talking about open source or fglrx here -- fglrx already has fast openGL 2.0 on the latest cards and multiple heads with multiple cards, although the latter is pretty recent and still teething.

Both. But a driver should have all the attributes. I should add "Open" to the list, since this is mostly a Linux site. And power management.

Open source openGL 2.0 is primarily waiting on memory management, not documentation.

Yes, I should have made this clear. OGL, tearing, h.264* on X/etc.; R7xx on docs.
*unless someone wants to use UVD2.

I'm skipping the R6xx. If anyone thinks it is important, I'll add the necessary distinctions.

AFAIK the 5xx driver is at 1.3 now and very close to 1.4; initial target would definitely be the same level of functionality for 6xx/7xx. One of our guys is already working on the arb_fp/arb_vp shader code generation.

Sounds like good news.

The nice thing here is that the most user-visible aspects of the new architectural changes (DRI2, for example) are the easiest to adopt into fglrx. That said, fglrx's primary focus is still high performance workstation so any "niche-ing" would be in the niches we are targeting anyways. Could be worse.

Sounds like good news also.

Not sure I understand the reference to this article. It was written in 2005 and most of the issues it mentions have already been addressed. The main outstanding area Jon talks about is memory management, and we finally have a more-or-less accepted API for that (GEM) and everyone is working on implementing and integrating that as top priority.

This was intended as background material for people not expert in the history and workings of X (like me) to better understand why the drivers haven't already been fixed.

Smirl also warns of a day when the 2D engine will be taken away and a big heap of work will be required to shift everything over to the 3D engine. That happened 2 years ago and is the reason why 6xx/7xx acceleration is taking longer than similar efforts on previous chips. It's the transition to doing everything with the 3D engine which makes things complicated -- all of a sudden the 3D engine needs to worry about things like which direction it reads and draws the pixels since we're now using it as a blitter (with potentially overlapped source and destination rectangles) not just as a triangle-monster.

I like the way you use the old article to explain the delay in the 6xx/7xx acceleration.

Pretty much that order, although I would say "R6xx/7xx 3D docs and/or sample code, OGL 1.3-1.4 in Mesa/DRM (the X driver has essentially nothing to do with OGL), fglrx integration of DRI2, KMS etc....

Thanks for the clarifications. I quickly checked the FAQ, but I'm not sure anything really needs to be changed. I'm not really sure we even need to add the wishlist (8) or background (9) to the FAQ.

[mattst88]

Please add R128, R100, and R200 to your list unreleased documents.

[Erektium]

wasn't R100 and R200 documents released under NDA?

[mattst88]

wasn't R100 and R200 documents released under NDA?

Yes, I believe so, but so were the R600 3D documents, and they are included in that list.

The list is meant to be what documentation has not been opened to the public.

[duby229]

I don't think duby229 changed anything. First duby reiterated the point from post 3, then repeated the points from the Tearing thread. I think I covered most of those points and your responses either directly or by reference in items 1, 3, 3a, and 7. (Am I 1337 now?)

The whole point of the FAQ is to ask the questions and get the answers only once.

Well, I figured I could respond to this since it was about me. Your exactly right. I added the last line and the paragraph above it. I didnt change anything that was already there.

But anyway, awesome FAQ. It's really nice to have a one stop shop that doesnt have a pro proprietary bias. Someplace where I can look to see what questions have been asked and answered, that I can then compare with my own questions. I can think of a few more specific questions that I'd like to ask, but they are probably too harsh.

[duby229]

I don't think duby229's edit changed the spirit of the post, but the revised post was longer, more aggressive, and had all new words in the middle (which is where I looked). I was very tired and all I saw was that the post looked completely different. I decided to go home rather than stay at my desk and start over

I know I'm a bit harsh. Sorry. Please take this as a sincere apology. I get a little carried away sometimes, I have very strong convictions. And I do honestly believe that ATi is wasting an awefull lot of time and money on quite a few things. I also think that ATi is being disingenuous on a few issues, and that they need to make a few major modifications to there agenda.

In the end pretty please with sugar on top generally doesnt do jack.

[leef]

Please add R128, R100, and R200 to your list unreleased documents.

Thanks for the this. R200, Rage 128 yes. R100 almost certainly, Mach 32/64? I'll add them.

wasn't R100 and R200 documents released under NDA?

Yes, however, according to me, NDA doesn't count as open.

While we're here, iirc some of AMD's "docs" are actually "source code", which does count as open, but not as "docs". The FAQ does not yet make that distinction. Source is useful, (maybe more useful to some even than docs), and certainly better than nothing.

Tangentially, the BSD camp has some ideas on the relative value of docs and source, as well as on how to convince companies to release docs. Extra credit: Does obfuscated code count as open?