Slashdot Mirror
AMD Releases Register Specs For R5xx And R6xx
ianare writes "AMD has recently released register specifications for the ATI Radeon R5xx and R6xx graphic devices. This will (theoretically) allow the OSS community to develop drivers, given time. In fact, engineers from Novell have released a first alpha quality Open Source driver which currently supports initial mode settings. Although current work is focused on 2D, rather than 3D acceleration, this type of information sharing could conceivably lead to an OSS 3D driver."
OSS 3D driver, great! Now we just need some games play.
These files are 12 days old. Aren't these the same files that were released sometime last week?
Get your own free personal location tracker
Games, schmames. If we have complete specs of the hardware, there are plenty of things besides graphics we can do with it.
Escher was the first MC and Giger invented the HR department.
Note that the reason why Novell's engineer were able to deliver an alpha driver this week is because they had access to the ATI's specification under NDA since two month.
So the driver isn't the result of only one week of work, even if it's still in an alpha state.
No, let's hope not. Just release the specs for the benefit of the entire free software community, and let people who know what they're doing write the drivers.
That the words 'texture', 'instruction pointer' or 'blitter' appear nowhere in either PDF file is a bit of a giveaway.
Whilst the registers are essential for getting any kind of driver to work, the documents don't describe the exciting features of the graphics processor. They give you enough control over the memory-controller timings to convert any Radeon card into a smoking brick with a small kernel-mode driver, but they don't give instructions which actually make the graphics silicon do things. There's no indication of what the machine-code for the vector processors looks like.
If you compare this to the documentation that Intel has for its (obsolete) 845 graphics controller, you notice that the whole block of registers for controlling even something as basic as the blitter, let alone the 'set instruction pointer for processing unit N' registers which actually let you set the high-performance processing units in the card to work, are missing.
These documents let you use an R500 or R600 card as a frame buffer. Not worth making a song and dance about that one.
Myself, I'd be fascinated to see documentation for the Intel G965 like the documentation for the G845; it clearly exists, there's a paper in the most recent Intel Technical Journal about low-level programming on the 965, it's just not available to mortals unless by attempting to reverse-engineer the x.org 965 driver.
It's entirely possible that they don't -have- specs written in a way that's suitable for public consumption.
my sig's at the bottom of the page.
If I remember correctly, AMD have stated that there is more to come - the specs and documentation covering the 3D functions has been promised for the "near future". The reason for the delay is due to patents and third party code in those areas and have had to take greater care to make sure the specs and docs aren't encumbered. I hope they follow through on this.
"...So I hung back and lurked. For 18 months. Can't beat a good old-fashioned lurking."
I's not the OpenGL teapot, it's the Utah Teapot or teapotahedron.
I develop drivers for a living (actually for the last year I haven't). I went through the docs a few weeks ago - I spent about 2 hours having a "good" read.
These docs will let one do the following
1 - Setup you own video mode
2 - Setup up a video overlay (not video acceleration)
3 - Setup a full colour mouse cursor
That's all. These do not explain how to blit, alpha blend, scale, ROP2, ROP3 or ROP4 or perform any other transform.
This is useful, but not _that_ useful!
Hopefully there will be more to come specifically more on the memory/cache controller (essential to get performance up), more on the PCI/AGP bus control, more on the 2D source/dest blit registers, pitch, loop counters and I'd like to know how much of the 2D guts is programmable. TBH I thought we'd have moved on to the point of (somewhat) programmable shaders for 2D these days with loops etc built into the HW (0 clock loops and addressing etc).
Time flies like an arrow. Fruit flies like a banana.