Open ATI R600/700 3D Graphics For Christmas?
Phoronix: Open ATI R600/700 3D Graphics For Christmas?
It's taken an eternity (well, to the Linux community that has been eagerly awaiting code and documentation since very early this year when it was first promised), but it looks like the open-source 3D support for the ATI R600/700 (Radeon HD 2000 through Radeon HD 4000 series) graphics processors may finally be coming soon! Back in February around the time of FOSDEM, AMD had released the R500 3D programming documentation that allowed the open-source community to achieve initial OpenGL R500 acceleration just a month later. At that time we were told the R600 3D documentation should be out in roughly a month, but that never ended up materializing. Since then we've been told the open-source R600 3D is their leading focus and that they're working to provide the needed documentation or source-code (either a straight-up Mesa implementation or internal AMD software projects like TCore and KGrids), but due to their limited staff and being burdened with intellectual property issues, it's been a slow process to say the least. In late June there was an initial R600 Direct Rendering Manager, but it was without any 3D support, and then earlier this month we found out that they're close with their R600 DRI support...
How bad would the worst case be? Of course that AMD got sued, and that would mean, that they won't be releasing any more specs. So that's pretty bad.
So the second worst that could happen would be that Microsoft(?) won't allow AMD to publish the newly written code and specs for R600 and R700 ?
That would be pretty bad, but not the end of the world, if we could get R500 working for now.
How long does a GPU generation last? 1 year? 2 years?
If that would mean, that R800 and beyond would be open source proof, I could live with a rock solid open source R500 with 3D for time
I'm sure my friend who bought two Radeon 4850's would be elated to find that LiveCDs had working 3d accel.
The GNewSense people will probably be pretty excited also.
mmh... christmas... i dont think so. seeing is believing.
Will R600 support not require distribution of a CP microcode blob? GNewSense doesn't even fully support R200/R300 for that reason.
Originally Posted by ethana2
If the worst case was as minor as not being able to release any more specs we wouldn't be worrying so much. The kind of risks we are worrying about are much larger, ie things which would either kill or cripple our graphics business.
Originally Posted by Louise
Worst case is that we lose the ability to sell our products into the Windows market as a result of releasing info which results in our DRM implementation no longer being considered sufficiently robust. Without the Windows market (which is >90 % of our revenues) we would, for all practical purposes, cease to exist as a GPU manufacturer, especially since we would probably lose the Mac market at the same time.
Next worst case is that we find a way to continue shipping into the Windows market but get sued under one or more of the DRM-related agreements we have signed. These all have high dollar-value penalties, again enough to significantly impact our ability to continue operating.
There are a bunch of smaller risks but we spend proportionally less time worrying about them. What makes all this complicated is that we have to consider not just the information we release but the information which is likely to be reverse-engineered and published. Each time we release information we simply raise the bar for where reverse engineering starts, and it's the combination of released plus "likely to be reverse-engineered" info that we need to consider.
If we tripped any of these risks then the impact would not only affect the GPUs we are shipping today but anything we have in the pipe. Best guess is that we would lose the next generation (ie the one after 7xx) and see significant delays in the one after that.
Since we don't want that to happen (right ?) the alternative is to trim back the information we release until it appears safe, going through the review process each time until we find an appropriate level. What "tricked" us with the 6xx was that the internal docs contained information on a lot of functionality we are not using in any drivers today, so the amount of information we had to cut out was much larger than in previous generations so it took a few attempts to find the right balance. The sheer complexity of the chip doesn't help either, since every review involves more people and more time than previous generations.
This is very typical risk management for a large company, but I don't think anyone has talked about it much before.
If you are talking about "worst case" in terms of "what if they can never release 6xx/7xx 3d info ?" I think we're already past that. There was a scary period back in August when that looked like a possiblity but I think we're OK in that area now.
Last edited by bridgman; 11-19-2008 at 12:07 AM.
I must say, I have never been more impressed by AMD that I am right now!!!
I had no idea, that it was that kind of serious challenges that was underneath
For the first time do I now understand, why no one have released specs before for their GPU's.
I'd wish HDCP, HDMI and Display Port was never invented.
Last edited by Louise; 11-19-2008 at 12:18 AM.
May I make a few suggestions for future products?
Originally Posted by bridgman
Make the cards boot in a DRM-less mode. That means that in a regular Linux boot, you can poke around at the registers but none of the DRM-related registers will actually do anything. Or decoy results if you think that's better. To activate the DRM-functions, use some binary magic in the closed source drivers. That should put a major reverse engineering effort that no open source hacker has interest in doing before you can even begin to poke at the interesting bits.
In addition, make a registry scrambler so that the closed-source DRM-enabled mode all use different addresses than the open mode. I imagine this can be implemented at essentially no cost or performance in hardware. Then you'll simply use a list of defines like:
On top of that, you could maybe try having a shared secret key between the DRM mode and your driver to encrypt (or at least obscure, if it's too much of a hit) the communication between the closed source driver and the hardware. That's another bit they'd have to figure out that again wouldn't impact open source functionality at all.
I'm not really sure how strong this protection is if you can run the exact same code on both platforms and compare calls, but it'd at least be a good attempt at security by obscurity (that's what DRM is anyway) that wouldn't make the documentation directly applicable to the closed source version at least. And that's the one they'd have to work with to try touching the DRM.
bridgman, what am I missing?
bridgman, first of all, I want to thank you for your participation in this forum. Your candid discussion, attention to the issues at hand, and the news you bring about the open-source effort being made at ATI are all very much appreciated.
Your post made earlier in this thread raised eyebrows and questions, though. I apologize in advance if what I'm about to ask seems barbed: my intent is to be clear, not to be argumentative.
The short summary of my argument below, for that majority which will skip the details:
1- The Windows Vista Premium logo creates an incentive *but not a requirement* for AMD to ship graphics parts which incorporate HDCP/AACS/DRM licensing;
2- The WD driver model creates a financial incentive to ship fewer parts and fewer driver sets, since each one requires length and expensive certification;
3- shipping parts and drivers which are inherently and inescapably vulnerable to reverse engineering and just hoping that people don't do so is incredibly naive, especially when such efforts can jeapordize AMD's continued viability as a business;
4- The two largest markets in which AMD competes are the embedded/business market (which actually has an incentive to *not* ship entertainment-capable systems) and the gaming market (which cares a hell of a lot more about framerates than HD, if Blu-Ray sales numbers are anything to go by) - the home theatre PC market is *at best* made up of early-adopting masochistic hobbyists and frankly doesn't figure into the picture at all;
5- Where are the parts and drivers which do not opt in to this losing DRM licensing game? Where is AMD's fallback plan? What is the huge deterrent which is preventing them from selling parts which customers obviously want and which do not expose AMD to enormous legal liability?
: I care about the HTPC market and refuse to use an operating system other than Linux. Ask me about masochism.
First of all, tapping the Windows market is what decides whether a company can compete as a manufacturer of graphics acceleration hardware (modulo the media-centric embedded space, where PowerVR is currently cleaning up). In order to sell into the current Windows market with a "Vista Capable" certification, graphics hardware must ship with a WDDM driver.
On page 109/500 of the Windows Hardware Logo Program Requirements for Devices (http://www.microsoft.com/whdc/winlog...uirements.mspx), requirement DISPLAY-0099 states that "Displays with digital inputs (for example DVI or HDMI) must support a digital monitor link protection mechanism such as HDCP". Additionally, on page 111/500 [ibid], the section GRAPHICS-0001 explicitly lists that HDCP (or at least a comparable "digital monitor link protection mechanism") is a requirement for Windows Vista Premium support. According to my understanding of these requirements, a Windows Vista driver could be created which would not mee the Premium requirements but would still meet the Vista Capable requirements, and still provide the full Aero experience; HDCP support is only required for devices explicitly sold as so-called 'Next Generation DVD' systems.
Since AMD now competes in both the business and the performance/enthusiast markets, it is reasonable to ship parts which allow integrators to use the Premium logo. Shipping such parts requires that AMD obey the requirements imposed by the AACS, HDCP and other DRM licensing bodies. If the DRM implemented in these parts proves vulnerable to attack, not only will AMD lose the markets to which those parts appeal, they open themselves up to enormous legal liability - so enormous that, as you state, it could make it impossible for AMD to continue to operate.
The WD driver model and the certification process imposes engineering (and therefore time-to-market, and therefore financial) penalties on diversification. The fewer parts that are shipped and the fewer sets of drivers that must be certified, the less expense the manufacturer incurs. This understandably creates financial pressure to minimize the number of unique parts shipped in any particular product generation.
So. Where is AMD's part which includes no active AACS/HDCP hardware and no such driver component? Surely the business sector could tolerate such a part (what responsible IT department would deploy system configurations which include entire subsystems dedicated entirely to strictly-defined entertainment and content playback?); surely the gaming market could bear a part strictly optimized for that purpose (perhaps emblazoned with a large "PURE GAMING" logo to clearly mark its strengths and highlight its lack of DRM nonsense); surely AMD doesn't consider the HTPC market so large and important that creating two parts which don't explicitly serve its needs would be a financially perilous move?
AMD has shipped an entire generation of hardware and supporting drivers which exposes the company to, by your own admission, liability so severe that it jeapordizes the viability of the company as a whole, and all signs point to the next generation repeating this commitment. AMD is a large company, and it employs very smart people: it is disingenous to suggest that as a group and as a company, AMD doesn't understand that shipping a solution based on security via obscurity is a losing battle. All it would take is a sufficiently motivated group of hackers and a few weeks of work to reverse-engineer the hardware and software components, and as you say, that would be the ball game for that whole product generation.
Where is the fallback plan? Where is the clean, risk-free part or product line? What is the unseen sword of Damocles hanging over AMD that prevents it from making the sober, reasonable and logical initiative?
I don't put much stock in wild conspiracies, but when I see a large, successful and smart company ignoring huge market and legal pressure in favour of doing something so obviously stupid, I can't help but suspect external pressure; and unless I'm missing something completely obvious, that kind of pressure is viewed with a very jaundiced eye by Canadian, US and international law.
What part of this picture am I missing?
Why bother putting in the effort of keeping the information in sync with the features you're actually using? This also implies keeping back those that work off of the released documentation, which I'm actually very worried about. That can be considered anti competitive behaviour.
Originally Posted by bridgman
I can understand competition reasons but you could also say that it is must easier to just release it all and focus on innovation and not worry about competition. This is the new paradigm anyway: innovate or die.
Let the open developers come up with new and interesting way of using your hardware... :-)
Also, in your next architecture, just split out the encumbered parts into separate blocks and do not release info about them. Release everything for the rest :-)