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

Re:Does it have info on Hybrid cross fire and othe

[Anonymous Coward]

The R500 cards only have crossfire via the external cable.

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.

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

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.

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: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).