AMD Releases 3D Programming Documentation

Michael Larabel writes "With the Free Open Source Developers' European Meeting (FOSDEM) starting today, where John Bridgman of AMD will be addressing the X.Org developers, AMD has this morning released their 3D programming documentation. This information covers not only the recent R500 series, but goes back in detail to the R300/400 series. This is another one of AMD's open source documentation offerings, which they had started doing at the X Developer Summit 2007 with releasing 900 pages of basic documentation. Phoronix has a detailed analysis of what is being offered with today's information as well as information on sample code being released soon. This information will allow open source 3D/OpenGL work to get underway with ATI's newer graphics cards."

Comments

Re:Makes me ask

[bersl2]

fglrx is probably a technical and legal mess unable to be cleaned up with less effort than it would take to re-write the drivers using good documentation.

Way to go AMD

[schwaang]

For ages, the FOSS community has said "just give us the specs for your graphics cards and we'll write the drivers". Well it looks like AMD is taking real steps in that direction, and I for one, say Thanks!

According to TFA, the small group at AMD who has spent time clearing the docs for legal issues are going to speak at FOSDEM, and the maintainer for the open source driver for AMD/ATI graphics (RadeonHD) will be giving an update.

And thanks also to Intel for putting out their 3D graphics specs last month. These are good days for Linux.

Re:Way to go AMD

[644bd346996]

Depends on what you mean by better. There's no doubt that the open source drivers will be more stable and have better software compatibility than the proprietary stuff. The 3d performance will really only matter to the Linux gamers (a very small market, that), as the performance should definitely be more than enough for simpler things like compiz, etc.

You should take a look at the existing 3d drivers. The folks reverse-engineering the r300 series did a pretty good job (well enough for it to be the development platform for xgl). And the open-source drivers also guarantee that the card will continue to work just as well with software written long after the demise of the company (eg. with the 3dfx drivers).

Re:Way to go AMD

[X0563511]

Gamers are not the only ones who like 3D acceleration.

Quickly and off the top of my head, here are two big ones:
1. Compiz/Fusion and the like is gaining popularity.
2. Some applications NEED good 3D or they crawl. See Blender for instance.

Of these, I would say gaming would be the least demanding - at least if my assumption that "stable is harder than fast" is correct.

Re:Way to go AMD

[forkazoo]

Gamers are not the only ones who like 3D acceleration.

Quickly and off the top of my head, here are two big ones:
1. Compiz/Fusion and the like is gaining popularity.
2. Some applications NEED good 3D or they crawl. See Blender for instance.

Of these, I would say gaming would be the least demanding - at least if my assumption that "stable is harder than fast" is correct.

Sure, Blender needs good OpenGL acceleration. But, nobody is going to be that concerned about getting an extra 1 fps in Blender. If proprietary drivers go twice as fast, or ten times as fast, then the open source devs would look like idiots. If the open source ones are ten percent slower, then 99% of people will be completely satisfied. Games are flashy, and they sell cards, and people will complain about getting killed by somebody with a faster machine because it couldn't possibly have anything to do with lack of skill. In Blender, you just need sufficient speed to work. If the guy next to you has an extra 2 fps, it doesn't make him appreciably more productive, and you certainly can't justify needing to display faster than the refresh rate of the monitor in Blender!

Re:Way to go AMD

[Alcoholic Synonymous]

"These are good days for Linux."

These are good days for Xorg, which isn't Linux. Everyone running X will benefit, not just Linux. Linux isn't the only non-Windows platform.

H.264 acceleration included?

[pyite69]

Feature parity with Windows must be the goal if they want to beat NVidia. I hope we can get some sort of media acceleration beyond the stale old XVideo & XV-MC.

Re:H.264 acceleration included?

[Jah-Wren Ryel]

I hope we can get some sort of media acceleration beyond the stale old XVideo & XV-MC. You won't get it, and the reason is DRM.

ATI's cards that have h.264 acceleration (and all kinds of other good stuff like smart de-interlacing all collectively branded as "UVD") are unlikely to ever have the specs for UVD disclosed because they integrated the good stuff with the bad stuff (DRM) and are afraid the exposing how to use the good stuff in UVD will also expose how to circumvent the bad stuff on microsoft windows systems.

So, once again, those DRM apologists who say that DRM is purely optional, that if you don't want to use it, it won't hurt you, are proven wrong again.

On the plus side, the next gen cards will have the DRM broken out into a separate part of the chip so that they can feel safe in publishing the specs for good video stuff while leaving the bad stuff locked away.

One of many such statements by ATI/AMD.

Yeeha!!!!

[Anonymous Coward]

I'm the owner of 5 boxes all with Nvidia graphic cards.
I've been using only Nvidia cards since 2000 because they had
the best 3D graphics card for my Linux box. I was willing to deal
with binary drivers because there was nothing else available to me
at my price range (loooow budget) for 3D graphics.

But.... over the years I would get burned every now and then
when
1) I would upgrade the kernel and then the X server would get borked
because the Nvidia kernel module didn't match the new kernel, or

2) Some funky memory leak in the binary Nvidia module would lock
up my box hard because of some damn NvAgp vs. Agpart setting or
some funky memory speed setting. Of course, this didn't happen with
every Nvidia driver so of course I wouldn't bother writing down
what it took to fix the problem.

Finally when I switched to Debian Linux in fall 2004 and had
beautiful apt-get/synaptic take care of all of my needs I thought
I was done ... until I found out that Nvidia doesn't time its
driver releases with kernel releases so if I wanted to upgrade
my kernel painlessly with apt-get/synaptic I would have to
wait for Nvidia to get off it's damn rocking chair playing their
damn banjo and release a driver to go with the newer kernel.

The final straw for me was when all of my 5 nvidia cards were
now listed in the "legacy driver" section. Can you guess what
"legacy driver" means about Nvidia fixing their closed source
driver? Yeah, that's exactly the point.

That's when I started looking around for open source 3d drivers.
I know about Nouveau for Nvidia, but frankly I'm too pissed off
about Nvidia to consider them. Ati had a long history of treating
Linux customers like second class scum. Intel on the other hand
earned the "golden throne" by providing full open source for their
graphic chipsets. So now that I'm looking for getting a dual core
64 bit cpu + 3D graphic chipset the only viable choice was intel,
which I was happy to do business with.

Now that Ati has decided to come forth with 3D documentation I'm
willing to give an intel/ATi or AMD/Ati combo serious consideration.

Way to go ATI!!!!

Re:Yeeha!!!!

[LWATCDR]

That isn't the issue. The interfaces are pretty stable other wise you couldn't just recompile most drivers when the new kernel comes out. What is missing is a stable binary interface. I am all for a binary interface. The developers don't want a binary interface for what I feel are bad reasons. But they are the devs and they get to make that call even if I don't like it.

Re:Yeeha!!!!

[Ryan Mallon]

The internal kernel API's are subject to change. Functions within the kernel for dealing with lists, interrupts, devices drivers etc, can and have changed many times in the past. The API (ie syscall interface) which is exposed to userspace is very stable, and in many cases pre-dates Linux itself.

Typically userspace application developers do not need to worry about changes to the kernel, since the userspace APIs are mostly stable. Drivers within the kernel usually do not need to worry either, since changes which break in kernel code are generally not accepted. The only people the unstable kernel API really affects is those maintaining out of kernel drivers (whether they are binary or source).

I would think that's more reason for specs..

[Junta]

I see that as a reason not to open source the existing drivers, but not to preclude releasing the details needed by the open source community to produce an open driver with their own shader programs, which may be lower performance, but good enough for default operation for a lot of distributions.

I find an interesting perspective being hinted at by AMD in this context. That they approach a common open source layer at the low level, and plug in their proprietary 'good stuff' as a replacement for higher layer things. As an example, they feel their powerplay stuff isn't top secret, so putting it at a layer where everyone can bang on it and improve it is ideal for everyone. Same with things like display handling. AMD and nVidia both do bizarre things requiring proprietary tools to configure display hotplug, instead of the full xrandr feature set, which has grown to include display hot plug.

In general, there are *many* things AMD has historically gotten wrong in their drivers. Mostly with respect to power management, suspend, stability with arbitrary kernels/X servers. One thing they seem to do better relative to the open source community is good 3D performance if all the underlying stuff happens to line up. If they can outsource the basic, but potentially widely varying work to the community, it would do wonders if their driver architecture lets them leverage that. And by giving open source 3D developers a chance to create a full stack, it's the best of all worlds. I would be delighted to see the Open Source 3D stack surpass the proprietary stack, but wonder what patents stand in the way of that being permitted...

Not lame at all.

[Timothy Brownawell]

It's actually quite nice when they tell us how to write our own drivers, so we're not dependent on them for needed maintenance (bug fixes, updates for newer kernels, etc). Companies can have all sorts of reasons to stop supporting a product, or to provide sub-par support, and being able to write our own drivers means that that isn't a problem.

Re:So is this all for any chip?

[TravisWatkins]

The previous releases covered initializing the card, mode setting, 2D output, etc. That's a lot of stuff to cover. These docs are basically just on how to setup the 3D engine and feed it shaders.

One Moment While I Go Dance in the Streets

[darkonc]

This is the end of the beginning.

Now that AMD/ATI has come over from the Dark Side, I expect that Nvidia and all of the other graphics chip manufacturers are going to be close behind. It may take them a year or two to work out the logistics, but they'll be here.

More and more people are moving over to Linux/BSD Free/Open software, and letting yourself be locked out of a growing market is the kind of things that CEOs and CTO's get fired for.

It used to be the case that manufacturers could peacefully close their eyes to the Open Source / Free communities and drink the Microsoft brand Kool-Aid because all of their competitors were doing the same thing. Now, however, with one of The big guns having committed to solid support of the Open Source universe, their less responsive competitors have a massive flank open that is going to have to be responded to.

Re:Makes me ask

[hr.wien]

fglrx has seen massive improvement lately. It is supposed to be mostly in sync with the Windows Catalyst drivers these days. It's still a bit off perfect of course, but a lot better than it was.

What's left?

[sudog]

So what's left before the complete documentation sets are in our hands?

Re:Too late

[Solra Bizna]

I've been lamenting for years that the R300 card in my G4 (now a G5, long story) would never get specs. I figured they'd start releasing only specs for R500 and up. So when I read this story, I LITERALLY jumped for joy. I'm so happy that I'm switching from nVidia to ATI in my next custom Linux box.

-:sigma.SB

Time to support ATI / AMD is NOW!

[Anonymous Coward]

I used to buy/recommend mostly AMD CPUs and Nvidia graphics cards till now.

I guess it's time to make it AMD / ATI now.

If they have released what we needed to get the drivers made, which is what we have always wanted, it's time we reciprocated by supporting them.

This will show other graphics companies *hint hint* that releasing the specs = good business.

Re:What's left?-experience

[z0M6]

Actually, r600 documentation is expected in a few months. That can hardly be called catching up compared to how it has been earlier.

Using the gpu to decode h264 etc is something I see as quite possible, but it is likely that it is something we have to implement ourselves (something I think we are capable of).

Still...

[Junta]

Comparing my R500 part with fglrx with an R300 part with the open source driver:
-With fglrx kernel module loaded, my laptop has not been able to suspend ever (using Ubuntu Gutsy)
-I have to do a goofy Virtual 1408x1050 resolution with fglrx to make 3D applications not look horribly corrupted. This is weird, but as long as I don't xrandr over to it, it's not a big deal, however..
-After doing above trick, fglrx shows corruption in lower right hand corner and hardware cursor if trying to do 3D apps at 1400x150 (native resolution). Have to run at 1280x960 to prevent that corruption.
-All acceleration (3D and 2D) has a horrible diagonal tearing effect.

The *ONLY* net improvement in the interval you deem 'massive' improvement is in the frames per second area. Though important, the top priority should be reliability.

Meanwhile, though much slower, the open source driver on the R300 part behaves quite in line with what I expect. I look *very* much forward to what the open source initiative ultimately yields. If AMD can cram the fglrx performance into binary blobs that leverage the open source layers for everything they get right, I would be ecstatic.

Re:One Moment While I Go blow hot air.

[Junta]

Uh huh. And just how many CEO's and CTO's have been fired for using ATI or Nvidia's binary blob? I suspect the number's between zero and your imagination. He was suggesting AMD's or Intel's CEO, not 'client' companies. I doubt it would get to C*O level, but I could see leadership being shuffled out of responsibility if they didn't, for example, make a correct strategy to get the GPUs sold into the HPC market for GPU computing while the competitor did. I.e. if someone takes the open source specs and designs a set of really kick-ass math libraries that cream anything done with nVidia's CUDA, that could lead to a lot of AMD GPUs being moved while nVidia rushes to leverage that. I doubt anyone would be fired though.

The total number of hardware and still growing that's released with a binary blob is still greater than the total number that have open source drivers. Huh? I can count two families with binary blobs as the only option for full-function, nVidia and AMD. This story hypothetically paves the way for the AMD half to go away, leaving only nVidia for now (rumor has it nVidia will follow suit). There exist some fakeraid cards that have binary only drivers to use the same format as the firmware support, but overwhelmingly this is skipped for pure software RAID. There exist a few wireless drivers without Linux drivers at all, but ndiswrapper has brought over the Windows drivers, so I guess you could say those are binary blobs. Even counting all that, you still have countless network adapters, graphics chips (current hardware is mostly Intel on that front), wireless adapters, storage controllers, audio devices, USB devices which in no way require a binary blob. The binary blob portion of linux support is a vast minority.