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."
Not cost effective. It takes time and money to release specs. They are not making money from those chips so it is illogical to put any effort in to releasing the specs.
Actually your statement proves my point. You will fall in love with ATI if they get out FOSS drivers for the new GPUs. Even then you top video card is only a 6600GT. Not even a 7 series. You are not a high profit demographic but even then they will win you over if they get a good FOSS driver out for the current cards.
Note that the opensource drivers are only available in the recent releases on most distros. Some not so-recent releases did disable the R300 driver because it wasn't deemed stable enough (opensuse 10.0 come to mind). So either the GP poster will have to update to a more recent release of his favorite distro (latest Ubuntu FF and openSUSE 10.2 have it enabled by default. I don't know about the others distro).
Or if he wants to keep his current installation for some reasons, he has to get the latest DRM (kernel [freedesktop.org]
Hurrah! I just bought a Radeon X1650 Pro this weekend trusting that AMD would honour their commitment to open up the specs for their ATI cards, and I'm glad to hear about this. I'm currently running the ATI binary driver, but the sooner I can move off that, and onto something nice and open, the better.
Opening the source hasn't got much to do with gaming success. The so-called succesful platforms, Windows and all the game consoles, are closed. Linux gaming could be pretty good right now, with NVidia's drivers for example. Opening the source will hardly make things less geeky, more attractive, or easier for the masses.
Quite another thing is your definition of success. For me, Linux has been a major success since 1999, and I hope I'd have discovered it even earlier. I'm not very interested in games, so
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.
I can't comment on the quality of ATI's *nix drivers, but FWIW I've never had any trouble with their win32 drivers. My x800xt has served me well the last three years and it still ticks on nicely.
However, much to my regret the ATI of today seems to be a mere shadow of its former self. Given ATI's failure to meet expected release dates with the last two generations, the somewhat disappointing performance [dailytech.com] of both families when finally released, and the latest string of stories of senior employees signing of [beyond3d.com]
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.
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.
Matrox promised full specifications including 3D capability for the G200 series cards back in 1998. Being an idealistic sucker, I bought a G200 based on those promises. Those specifications, promised nearly ten years ago, never arrived to my knowledge. If they ever did, it happened long after the G200 was obsolete.
About six months after wasting money on that G200, I bought a Riva TNT2 and have been an NVidia customer since then. They don't make empty promises that we MIGHT be able to write a decent workin
Those specifications, promised nearly ten years ago, never arrived to my knowledge. If they ever did, it happened long after the G200 was obsolete.
They did arrive, and for the G400 as well. The first driver to make use of this information was the Utah-GLX [sourceforge.net] module thingy for XFree86 3 - that John Carmack helped with their development. I think the specifications for some particular, programmable section of the cards (WARP setup engine?) weren't released, but microcode blobs for the necessary functionality were
I sort of recall hearing sometime down the line that some of the 3D specs were released, but critical stuff needed for acceptable performance or modern effects was missing.
Well, if they said "that's all folks" then it'd not be much. But they've said 3D specs are coming, and you have to walk (2D) before you can run (3D) so it's better they release 2D when it's ready and 3D soon than nothing now and then all at once. Let's just hope that they'll actually give complete specs and not some half-accelerated stuff.
Welcome to the nice world of 2007, where graphic cards have more in common with supercomputers than with hardware blitter and rasteriser of early Amigas and 3DFx'. More seriously, once the 3D specs gets released, due to the highe programmability of latest generation of hardware, the 3D specs are probably going to contain much more information about building and uploading fragments, and setting up input and output streams, than occurence of the words "blitter" and "texture". In fact, I don't actually know if
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).
I'd also love to see some documentation for the terms and concepts you've mentioned. What are ROP2/3/4, why do we want them around, etc. Not just the registers for them, because not all of us know what those are for or why we care. How does one go from knowing little if anything about graphics to knowing what to do with registers defined in these and other Radeon documents?
When ATI were making their first murmurings of releasing specs a few weeks ago, I have to say I wasn't convinced - I've been burned by ATI's shoddy Linux support in the past, and it was going to take alot of convincing that AMD (traditionally very friendly to FOSS) was trying to steer the ship in a different direction.
And now they've released scads of docs - kudos. This was probably the only way to make a FOSS driver a reality without violating reams of licensed IP. On top of that, I believe their latest set of Linux drivers fix a number of long standing issues, as well as vastly increasing 3D performance (although obviously there are still are QA problems).
Granted, it's almost all 2D stuff at the moment, but being able to ship a functional, fast and non-crash-prone driver for ATI cards with every modern distro will be another win for Linux in general.
I'm quite interested to hear about advanced features though - will implementing things like iDCT in XvMC for MPEG2, MPEG4 ASP and H.264 be a reality? Can these things be implemented with 2D registers or do these things need to be run through the 3D shaders nowadays? The low end ATI cards, including the IGP's, would be ideal for HTPC boxes, espcially with Intel dragging their feet on similar support/documentation for their (admittedly otherwise excellent) GMA X3xxx series.
"When ATI were making their first murmurings of releasing specs a few weeks ago, I have to say I wasn't convinced - I've been burned by ATI's shoddy Linux support in the past, and it was going to take alot of convincing that AMD (traditionally very friendly to FOSS) was trying to steer the ship in a different direction." Just like I was burned by Matrox's promises to release 3D specs shortly after they released 2D specs for the G200 nearly a decade ago. They never delivered the documentation that was promis
Doesn't this just encourgage the hardware developers to leave it to "the community"?
Professional customers might still want a HW-developer-written driver.
Regardless of that, it's a better move than keeping the specs secret. Because in the latter case, you're totally at the mercy of the HW developer as far as driver availability and quality goes.
In the long run, I think you'll find that the kind of customer who won't trust a community-written open source driver to be very high quality won't be using Linux (or BSD or any other Unix) at all.
I use Linux but I have little faith that we will every see FOSS 3d drivers that are written for free by the "community" So far there are zero modern 3D drivers that do not have a lot of manufacture support. I will bet that the FOSS ATI drivers with still have a lot of code from ATI.
So, you think the "give us the specs and we'll do the rest" bit is a fantasy? Has it occured to you that all those reverse-engineered drivers would have been done 100 times faster with specs, resulting in working drivers while the products were still fairly new?
Look at the resources the r300 and nouveau projects have. If the manufacturers simply dumped the specs on them, they would be able to produce high quality drivers quickly. Even without the specs, they've proven their abilities to make decent drivers the hard way. Or do you have some reason to believe that they wouldn't be significantly more productive with specs? Is there something magic about ATI's programmers that makes them vastly more productive with the same specs to work from?
ATI(AMD) and NVidia by themselves are able to create drivers for most of the probable market. However, the community is not totally content with their drivers.
Other companies that produce well used hardware does not have drivers for Linux, and when access to their documentation will be available, the quality of the open source drivers will hopefully improve.
Calin
Cheaper for the companies. Better for the community.
The only losers are the companies (eg. nvidia) that compete with companies clever enough to do this, and companies (eg. microsoft) who have a vested interest in there not being any Free Software drivers.
companies (eg. microsoft) who have a vested interest in there not being any Free Software drivers.
Note that, with the availability of Mesa3D's source, it's not that much difficult to provide open source drivers for Windows, at least for openGL.
The 3DFX source community has been doing it since a long time. Because the source of the Glide API (the low level talking to 3DFx hardware) has been available, since the demise of 3DFx and because windows XP didn't provide any support for openGL on Voodoo boards, a st
Exactly, one of the things that held (or is still holding?) back the Nouveau project (an open source reverse engineered driver for nVidia cards) is the lack of developers with hardware to test their work against.
Talking of Nouveau, the 2D performance of their driver at one point exceeded that of the nVidia sponsored "nv" driver, but I think since they moved to the new EXA framework (some X acceleration API) they have negated these advantages.
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.
...as if there are legions of qualified 3D device driver writers just waiting around with nothing better to do. Writing drivers for 3D cards is difficult work. "Release the specs and we'll write the drivers" has been the mantra of the open source community for years, but I think we're all in for a disappointment if we're expecting feature-complete, high-performance open-source drivers for these cards any time soon.
I think some kind of sponsorship to dedicated, full-time devolopers is going to be necessary if
"Release the specs and we'll write the drivers" has been the mantra of the open source community for years, but I think we're all in for a disappointment if we're expecting feature-complete, high-performance open-source drivers for these cards any time soon.
I think that if you have a community making a decent driver, there will be enough 3D driver writers available who know the hardware well enough to delegate simple responsibilities, make good decisions, and code the hard stuff themselves. Probably. I ho
I'd rather there be one set of really stable drivers than two separate sets. With having only one set, we don't have to worry about some advanced programs only running with one driver set while another advanced program we need to use at the same time requires the other driver.
Politics, as a practice, whatever its professions, has always been the
systematic organisation of hatreds.
-- Henry Adams, "The Education of Henry Adams"
R250 (Score:2)
Re: (Score:2)
It takes time and money to release specs. They are not making money from those chips so it is illogical to put any effort in to releasing the specs.
Re: (Score:3, Insightful)
Even then you top video card is only a 6600GT. Not even a 7 series. You are not a high profit demographic but even then they will win you over if they get a good FOSS driver out for the current cards.
R300 opensource drivers (Score:3, Informative)
So either the GP poster will have to update to a more recent release of his favorite distro (latest Ubuntu FF and openSUSE 10.2 have it enabled by default. I don't know about the others distro).
Or if he wants to keep his current installation for some reasons, he has to get the latest DRM (kernel [freedesktop.org]
glxGears needs to be updated! (Score:3, Funny)
Re: (Score:2, Informative)
Re: (Score:3, Funny)
Isn't it written into the GL Spec that all OpenGL benchmarks must include some sort of tea kettle?
Re:glxGears needs to be updated! (Score:5, Interesting)
Parent
Hurrah (Score:2)
Re:Hurrah (Score:5, Funny)
Parent
Re:Hurrah (Score:5, Insightful)
Parent
Re: (Score:3, Insightful)
Opening the source hasn't got much to do with gaming success. The so-called succesful platforms, Windows and all the game consoles, are closed. Linux gaming could be pretty good right now, with NVidia's drivers for example. Opening the source will hardly make things less geeky, more attractive, or easier for the masses.
Quite another thing is your definition of success. For me, Linux has been a major success since 1999, and I hope I'd have discovered it even earlier. I'm not very interested in games, so
If you really wanted open source... (Score:2)
Obviously your priority for open source is below your other priorities.
Old files? (Score:5, Informative)
Zonk doesn't post dupes! (Score:3, Funny)
Novell's engineer started earlier (Score:5, Informative)
So the driver isn't the result of only one week of work, even if it's still in an alpha state.
About time! (Score:4, Insightful)
But I think ATI made a smart move. Outsourcing driver development to the OSS community certainly cuts costs.
Re: (Score:2)
I can't comment on the quality of ATI's *nix drivers, but FWIW I've never had any trouble with their win32 drivers. My x800xt has served me well the last three years and it still ticks on nicely.
However, much to my regret the ATI of today seems to be a mere shadow of its former self. Given ATI's failure to meet expected release dates with the last two generations, the somewhat disappointing performance [dailytech.com] of both families when finally released, and the latest string of stories of senior employees signing of [beyond3d.com]
These documents are not as exciting as you think (Score:5, Insightful)
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.
Re:These documents are not as exciting as you thin (Score:5, Informative)
Parent
Re: (Score:2)
patents seem to be a better excuse this time.
Promises mean nothing (Score:2)
Those specifications, promised nearly ten years ago, never arrived to my knowledge. If they ever did, it happened long after the G200 was obsolete.
About six months after wasting money on that G200, I bought a Riva TNT2 and have been an NVidia customer since then. They don't make empty promises that we MIGHT be able to write a decent workin
Re: (Score:3, Informative)
They did arrive, and for the G400 as well. The first driver to make use of this information was the Utah-GLX [sourceforge.net] module thingy for XFree86 3 - that John Carmack helped with their development. I think the specifications for some particular, programmable section of the cards (WARP setup engine?) weren't released, but microcode blobs for the necessary functionality were
Re: (Score:3, Interesting)
Re: (Score:2)
Complexity of moderns GPUs (Score:2)
More seriously, once the 3D specs gets released, due to the highe programmability of latest generation of hardware, the 3D specs are probably going to contain much more information about building and uploading fragments, and setting up input and output streams, than occurence of the words "blitter" and "texture". In fact, I don't actually know if
Absolutley _Spot On_ (Score:5, Informative)
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).
Parent
Re: (Score:3, Interesting)
Eating my words (Score:4, Interesting)
And now they've released scads of docs - kudos. This was probably the only way to make a FOSS driver a reality without violating reams of licensed IP. On top of that, I believe their latest set of Linux drivers fix a number of long standing issues, as well as vastly increasing 3D performance (although obviously there are still are QA problems).
Granted, it's almost all 2D stuff at the moment, but being able to ship a functional, fast and non-crash-prone driver for ATI cards with every modern distro will be another win for Linux in general.
I'm quite interested to hear about advanced features though - will implementing things like iDCT in XvMC for MPEG2, MPEG4 ASP and H.264 be a reality? Can these things be implemented with 2D registers or do these things need to be run through the 3D shaders nowadays? The low end ATI cards, including the IGP's, would be ideal for HTPC boxes, espcially with Intel dragging their feet on similar support/documentation for their (admittedly otherwise excellent) GMA X3xxx series.
Re: (Score:2)
Just like I was burned by Matrox's promises to release 3D specs shortly after they released 2D specs for the G200 nearly a decade ago. They never delivered the documentation that was promis
Re:Bad move? (Score:5, Insightful)
Parent
Re: (Score:3, Insightful)
Hardware makers do their thing and then they should pass the necessary info to the community so we can write the drivers.
Re:Bad move? (Score:4, Insightful)
Professional customers might still want a HW-developer-written driver.
Regardless of that, it's a better move than keeping the specs secret. Because in the latter case, you're totally at the mercy of the HW developer as far as driver availability and quality goes.
Parent
Re: (Score:3, Insightful)
Re: (Score:2)
So far there are zero modern 3D drivers that do not have a lot of manufacture support.
I will bet that the FOSS ATI drivers with still have a lot of code from ATI.
Re:Bad move? (Score:4, Insightful)
Look at the resources the r300 and nouveau projects have. If the manufacturers simply dumped the specs on them, they would be able to produce high quality drivers quickly. Even without the specs, they've proven their abilities to make decent drivers the hard way. Or do you have some reason to believe that they wouldn't be significantly more productive with specs? Is there something magic about ATI's programmers that makes them vastly more productive with the same specs to work from?
Parent
Re: (Score:2)
Other companies that produce well used hardware does not have drivers for Linux, and when access to their documentation will be available, the quality of the open source drivers will hopefully improve.
Calin
What's wrong with that? (Score:4, Insightful)
The only losers are the companies (eg. nvidia) that compete with companies clever enough to do this, and companies (eg. microsoft) who have a vested interest in there not being any Free Software drivers.
Parent
Open source drivers (Score:2)
Note that, with the availability of Mesa3D's source, it's not that much difficult to provide open source drivers for Windows, at least for openGL.
The 3DFX source community has been doing it since a long time. Because the source of the Glide API (the low level talking to 3DFx hardware) has been available, since the demise of 3DFx and because windows XP didn't provide any support for openGL on Voodoo boards, a st
Re: (Score:2)
Talking of Nouveau, the 2D performance of their driver at one point exceeded that of the nVidia sponsored "nv" driver, but I think since they moved to the new EXA framework (some X acceleration API) they have negated these advantages.
Re: (Score:2, Funny)
Re: (Score:2)
Re:drivers (Score:5, Insightful)
Parent
Re:drivers (Score:5, Insightful)
Parent
Re: (Score:3, Insightful)
You say that... (Score:2, Insightful)
Writing drivers for 3D cards is difficult work. "Release the specs and we'll write the drivers" has been the mantra of the open source community for years, but I think we're all in for a disappointment if we're expecting feature-complete, high-performance open-source drivers for these cards any time soon.
I think some kind of sponsorship to dedicated, full-time devolopers is going to be necessary if
Re: (Score:3)
I think that if you have a community making a decent driver, there will be enough 3D driver writers available who know the hardware well enough to delegate simple responsibilities, make good decisions, and code the hard stuff themselves. Probably. I ho
Re: (Score:2)
Re: (Score:2)
I'd rather have them contribute (Score:3, Insightful)