Revenge On Reverse Engineering

[phoronix]

Phoronix: Revenge On Reverse Engineering

Revenge, a clean-room reverse engineering utility being developed by Oliver McFadden for Radeon graphics cards, is nearing its 1.0 release. This utility is designed for reverse engineering the ATI graphics cards and their binary driver.

http://www.phoronix.com/scan.php?page=news_item&px=NjAyNA

[dotancohen]

I'd like to help. Is there a deb package for Ubuntu? Also, how will this affect my everyday computer use? With the machine be slower/more crash prone/something else?

[d2kx]

I'd like to help. Is there a deb package for Ubuntu? Also, how will this affect my everyday computer use? With the machine be slower/more crash prone/something else?

I don't think that these reports are needed any more due to the RadeonHD driver and the specifications AMD provides/will provide.

Correct me if I'm wrong.

[yoshi314]

documentation is not going to cover everything....

as ati said - radeonhd will be a simple opensource driver, with basic functionality.

when ati will release final set of docs and say that it's not going to release any more - then revenge will be put to use again. it's going to be way easier then, since many registers name and behavior will be already known.

[Svartalf]

documentation is not going to cover everything....

as ati said - radeonhd will be a simple opensource driver, with basic functionality.

when ati will release final set of docs and say that it's not going to release any more - then revenge will be put to use again. it's going to be way easier then, since many registers name and behavior will be already known.

Heh... You weren't s'posed to say that... :D

[yoshi314]

well, sorryy about that :D

but that's common knowledge. isn't it? :D

[bridgman]

"la la la la la la...."

I think there are two different discussions going on here -- one about Conntest and one about Revenge.

Conntest is a utility the SuSE guys used to collect connector information on cards so that they could put the resulting info into the radeonhd driver and support new configurations. Those reports are generally not needed any more since the driver now picks up connector info from AtomBIOS. Revenge is a reverse engineering tool designed to intercept driver accesses to help figure out how to program the chip.

Without sounding naive, our plan is to release all the information we can have in the public domain with acceptable business risk, so that open source developers can spend more time writing great drivers and less time trying to understand the hardware.

If the outcome of our documentation effort is that we just raise the starting point for reverse engineering, which will pretty much guarantee that RE efforts will discover and disclose information which puts our business at risk, that's not a great way to motivate other HW suppliers (or even AMD) to support open source development in the future.

I am asking you to fundamentally re-think the relationship between open source developers and hardware vendors, at least in our case. Make sense ?

Now, where was I ? Oh yes, "la la la la la ...." ;)

[Svartalf]

I am asking you to fundamentally re-think the relationship between open source developers and hardware vendors, at least in our case. Make sense ?

Now, where was I ? Oh yes, "la la la la la ...." ;)

Heh... I do believe I said "You shouldn't have said that" as much for tongue in cheek purposes as for a very real thing- we're both walking a fine line here, the community and AMD. I don't want to step on your employer's toes to the point that they don't do this anymore. I want to have a Winner all the way around with this. But, in the same breath, I have to point out that every one of the hardware companies (AMD included in that...) dealing with Media "protection" have it bass-ackwards when it comes to the media space.

You see...

Media Companies: Multi-Billion Dollar Business.
Hardware and Software Companies: Multi-TRILLION Dollar Business that hardly depends on the other to exist.

You don't NEED them. Honest.

There's enough wonderous stuff popping up without the Warner's and Disney's of the world- and it's happening in spite of them. That's because they're more interested in strip mining the profits out of Culture and trying to "dictate" what is and isn't Culture.

[bridgman]

Heh... I do believe I said "You shouldn't have said that" as much for tongue in cheek purposes as for a very real thing- we're both walking a fine line here, the community and AMD. I don't want to step on your employer's toes to the point that they don't do this anymore.

You summed it up well -- I'm getting very "wise", professional reactions from the developers w.r.t. reverse engineering -- enough so to surprise some of the folks here.

There's a sign on a roof garden in London -- "Gentlemen will not, and others must not pick the flowers". So far I've run into nothing but gentlemen.

Media Companies: Multi-Billion Dollar Business.
Hardware and Software Companies: Multi-TRILLION Dollar Business that hardly depends on the other to exist. You don't NEED them. Honest.

Yeah, last time I looked the entertainment business was smaller than the potato chip business. Question is what the exit strategy would be -- if we say "we're not supporting DRM any more" the OEMs will thank us for sharing our views, make it clear that they respect our philosophical stand, and then buy all their graphics chips from Green or Blue.

There's enough wonderous stuff popping up without the Warner's and Disney's of the world- and it's happening in spite of them. That's because they're more interested in strip mining the profits out of Culture and trying to "dictate" what is and isn't Culture.

I wouldn't know... I don't watch television. Just old Sledge Hammer re-runs ;)

[Svartalf]

You summed it up well -- I'm getting very "wise", professional reactions from the developers w.r.t. reverse engineering -- enough so to surprise some of the folks here.


Won't surprise me at all. I'm an old geezer in this space, having used Linux for well over a decade and been in the industry some 20+ years. I'm one of the people that worked hard to get us to the position that we're in today- and it didn't come by way of stepping on people's toes.

As it stands, while I've issues with DRM and all, I'll take what all I can get in the way of this sort of support you're working towards giving us. I wish it was happening faster (as the proprietary stuff just isn't there yet- sorry...) so we could get enough up that I don't have to question whether or not one of the titles I'm working on will have adequate driver support or not. As it stands right now, your main competitor has the only suitable parts and adequate drivers. I don't like that situation, as I'm sure you and AMD don't like it either.


There's a sign on a roof garden in London -- "Gentlemen will not, and others must not pick the flowers". So far I've run into nothing but gentlemen.


I think you'll find that I fit into the Gentlemen category in that analogy. I won't go and do RE on things unless it becomes clear that I won't get the info I need and I actually NEED some functionality.

Too easy to alienate a vendor otherwise- too easy to negotiate a rational response to things like DRM support in the hardware.


Yeah, last time I looked the entertainment business was smaller than the potato chip business. Question is what the exit strategy would be -- if we say "we're not supporting DRM any more" the OEMs will thank us for sharing our views, make it clear that they respect our philosophical stand, and then buy all their graphics chips from Green or Blue.


I'm not 100% sure that's what'll happen. We're already about to hit a threshold where the DRM and other stuff like it will get enough in the way of people doing things they've gotten used to doing that they'll quit buying the tech gear. What happens then?


I wouldn't know... I don't watch television. Just old Sledge Hammer re-runs ;)

I'm not much farther behind you there. All I care to watch is things like Future Weapons on Discovery- and the music I listen to the most isn't signed on a label and you find the live performances in Renaissance Festivals. :D

What the Media Companies tend to offer these days is Excrement Locked In A Safe. No thanks, I'll pass on that.

[bridgman]

>>We're already about to hit a threshold where the DRM and other stuff like it will get enough in the way of people doing things they've gotten used to doing that they'll quit buying the tech gear. What happens then?

My guess ? DRM will survive, entertainment $$ will drop, movie stars will stop earning $20M per movie and the crazy Hollywood spending will become unsustainable, costs and wages will fall to the point where the finished product can be sold at a decent price, a lot more countries will come onstream with first-world economies, media prices will drop enough that people start buying again, and DRM will get relaxed and become more like the lock on your front door than a vault door.

Not sure what will happen with professional sports, which is a remarkably similar business other than being able to rely on the appeal of live performances and so not having to worry about controlling what happens to recorded performances.

Music already seems to be going that way.

[TechMage89]

I think that, in the end, media companies will figure out that no DRM will stop a really determined hacker, and realize that they are only alienating their good customers.

They may not like it, but they may have to trust their customers. I know that the attitude in my generation (now entering college) is that there isn't really anything wrong with downloading copyrighted stuff from, for example, bittorent, but if the content is well made, you should pay to get it legit. In the entertainment industry (and I think this what the industry hasn't understood so far) people will pay for well made content, even if it is available for free from pirates. People want to support the people and the companies that make good content so that they can continue to do so.

Look for example at webcomics. Megatokyo is available for free online. And yet, people buy the books, buy the merchandise, and the creator makes his living off the comic. I really do think that the rest of the entertainment industry could offer something similar. They could even bypass the pirates and offer partial content for free as a hook to get people to buy the whole thing. Imagine being able to watch half a movie online for free. Can you imagine how many people would spring immediately to buy the second half?

[olivermcfadden]

Revenge can also be used as a debugging tool for driver development, as well as
for reverse engineering. Revenge was also started before AMD released any
documentation, so it's not just a project to annoy AMD. ;-)

Revenge could be used to reverse engineer the parts that AMD are not releasing
for legal reasons; video decoding, etc. I won't be doing this, because I don't
care about the graphics cards video decoding capabilities. I can play video just
fine without hardware acceleration...

I would caution anyone else about reverse engineering the video decoding
capabilities; AMD are doing a very good thing by releasing documentation. I
think we should respect their wishes here.

[yoshi314]

you're right.

i just got curious what's the current opinion on revenge.

still, the tool is out. somebody is bound to use it the way it was used till now (reverse engineering), when ati didnt' care about linux that much.

i as basically thinking "what if the complete set of docs didn't cover some basic functionality that would seriously reduce their performance vs fglrx in 2d, 3d or video playback?" (as that's what the docs are about to cover).


My guess ? DRM will survive, entertainment $$ will drop, movie stars will stop earning $20M per movie and the crazy Hollywood spending will become unsustainable, costs and wages will fall to the point where the finished product can be sold at a decent price, a lot more countries will come onstream with first-world economies, media prices will drop enough that people start buying again, and DRM will get relaxed and become more like the lock on your front door than a vault door.they won't go down without a fight.

getting rid of drm is going to be like a weekend in hell.

when the profits will start to drop they'll increase the prices. then they'll start accusing everybody around of piracy and hurting their interests. then they might make copyright law even more. then you'll start being accused by hollywood riches that they can't make money because of you.

finally they'll accuse you of not being able to make a sequel to their movie (oh, that's actually a GOOD thing! :D) because the previous one didn't sell.

then it's going to be ugly. and maybe, just maybe, someone will realize that cutting costs by not paying all those redundant companies (copy protection company, distributor and the likes) will actually be more cost-effective than wasting money on fighting customers with drm.

still, the hardware market is ridden with drm. we have it in our tv, dvd players, blu-ray, game consoles, hdmi connectors. it just won't go away that easily.

I think that, in the end, media companies will figure out that no DRM will stop a really determined hacker, and realize that they are only alienating their good customers.they already do. every protection gets defeated sooner or later. discarding drm requires some courage, though. or some guarantee that this move will pay off. not many have tried yet, but some of them show pretty good profits in their drm-less adventure. (e.g. magnatune, amazon, apple, radiohead).

[givemesugarr]

then they might make copyright law even more.

look at what happened in france: people could be banned (permanently) from getting an internet connection if they're found downloading stuff.
the problem is not drm, the real problem is: don't bother getting money into such things and just invest that money into producing better stuff and at lower prices. i'm personally convinced that if music/films would cost half of now at least 60-70% of people who downloads them would instead buy them. i personally don't buy regular dvds but expect the movie to be passed on satellite tv or borrow them from blockbuster. the music around is not good anymore (thanks god that sometimes i can get old good metal or 70's - 80's music at low prices less than 15 euros).
the same goes for software: i've switched to linux about 2 years ago since i didn't liked being always behind with the software and i'm now using only opensource or free licensed software. i've got my working copy of windows xp but i won't go back to it since i don't have good licensed programs and admin tools. i don't play games since there's nothing good around and it seems that new games are working better on linux than windows (enemy territory for example).
on linux journal i've found a recent article about Intelectual Property that is quite interesting ( http://www.linuxjournal.com/node/1005736 ) and the redirection on some interesting free books about the argument.
closing this, i was wondering if i could use revenge to help radeon devs with the xpress 200m. for the moment i can use this board in a good way only with fglrx since i get some rendering and performance issues with the oss driver. i'm asking this since last time i've tried it i wasn't able to run it. or maybe it's just me that don't know how to use it.

[Michael]

the xpress 200m

That chip is notorious under Linux... Your best bet is probably waiting for AMD to release the documentation covering that IGP.

[bridgman]

You might also want to post to the xorg-ati mailing list to see what the latest status is. Dave Airlie made a lot of progress on implementing vertex shaders in software a few months ago -- not sure if anyone has had time to push ahead since then. Alex Deucher (one of the maintainers of the oss driver for the 200M) is starting at AMD next week so that should make digging up the info a lot easier.

[givemesugarr]

Alex Deucher (one of the maintainers of the oss driver for the 200M) is starting at AMD next week so that should make digging up the info a lot easier.

i've read about it some days ago about it on phoronix or on deucher's blog (i don't really recall where) and i was quite pleased about the news.

Dave Airlie made a lot of progress on implementing vertex shaders in software a few months ago -- not sure if anyone has had time to push ahead since then

i've tried the radeon when the famous 8.42 got released and tried to compare the two drivers but i've found out it to be a lot slower than fglrx and it had some problems with my board. it doesn't have the dedicated ram as some x200 based boards that i've seen around. when i got the pc (about 2 years ago) it wasn't usable in linux (i couldn't use it even with the vesa mode) and in windows it had a lot of problems (crashes and similar). only after 3-4 months it became stable and usable in windows xp and i could then install linux. fortunately after some months of windows enduring i've found out better and working drivers. but still the video is slow and has some performance issues. opengl is still very slow and i curently cannot really use it on linux, aiglx is still not a speedy gonzales and compiz is totaly unusable (less than 100 fps and 100% of processor speed to make the alt+tab switch in about 10 seconds). the oss drivers are still about 1/2 of fglrx in terms of speed and for that reason they're still no option. fglrx now is everyday usable and i can run old fellow beryl on it without speed decrease.
in my opinion ati has done in one year what it should have done in more than 5 years and the release of specs would further convince me on going with an amd-ati and for that i'd really want to thank amd/ati for improving its linux drivers and for the good job they've done in the last months since i've understood that the work is done by a few hand of devs that also have to mantain the windows drivers.

[Svartalf]

That chip is notorious under Linux... Your best bet is probably waiting for AMD to release the documentation covering that IGP.

Notorious?? Don't you mean "evil"? :D

I've got 128M of dedicated RAM with my version of the chip and I can't use it (The old driver only reliably uses the UMA configuration...I'm...hesitant...to try the new one, for obvious reasons... :D)- which was the reasoning behind buying it when I bought the laptop a couple of years back.

[givemesugarr]

here i am again asking for some clarification about revenge:
is there some documentation on how to use it?
i've tried looking around the web for some hours but haven't yet found a list of options or something that could help me start it and when i start revenge it says that the option that i want is not recognized.
i think that if someone doesn't start to write some help on the matter it won't be so useful in the end.

now, i really think that in the end amd should release proprietary modules for some features like video decoding that could be loaded by the drivers like radeon or fglrx itself. i think that doing that would prevent the people from reverse engineering (losing time figuring out stuff) protected stuff and would put amd at safe from legal issues with the proprietary stuff. also it could help out the fixing of some features that aren't planned to be outsourced. this could also speed-up the process of the developing of new oss drivers.
for example they would load the unimplemented modules among the fglrx ones and use them until the documentation and the developing process would be mature enough to support new features.
in my opinion this would be the best choice and would integrate the driver in a more profound way since fglrx would mainly focus on implementing proprietary stuff and on the speed of these modules while the oss community would implement and mantain the outsourced hw capabilites and would port them to new releases faster than we had them ported with fglrx.
also, defining a communication layer for proprietary modules, for example based on opengl, thus independent from operating system, could push other devs to start creating own oss or closed drivers based on the specs and which would benefit of all the features via these modules.
try thinking about it in this simplified term:
at amd would develop an opengl module that controls hw video decoding. a linux developer which has this module would load it and use it via the common layer without having to worry about how the stuff works. all that it needs to know is what it has to pass to the layer and the layer would pass the right arguments to the video decoding module which would do the decoding and pass the results to the driver via the same intermediate layer. of course, the oss developer could just have the video decoded via software means without problems if he would have wanted that. the same would happen with a solaris dev: he would have these modules ready to use and he would just have to load them while he would have written the code for the documented features, if we would have felt the need for it.
also oss modules could be used by other oss drivers via the same layer (think of solaris drivers using linux oss modules).

now i'd like to ask bridgman if this could be a good idea and if it could be applied in the future for amd drivers.

[bridgman]

We can't use that architecture for "real" HD decoding, since we would be legally obligated to protect the video data that comes out of the decoder and that's kinda hard to do in an open driver, but it might be a possibility for using UVD on non-HD content if we could properly tamper-proof the binary. The obvious downside is that it's a heck of a lot easier to reverse engineer a single module than a 20 MB driver stack, and if we felt that we could safely release the info we would rather just give it to you than make you dance for it ;)

[givemesugarr]

We can't use that architecture for "real" HD decoding, since we would be legally obligated to protect the video data that comes out of the decoder and that's kinda hard to do in an open driver, but it might be a possibility for using UVD on non-HD content if we could properly tamper-proof the binary. The obvious downside is that it's a heck of a lot easier to reverse engineer a single module than a 20 MB driver stack, and if we felt that we could safely release the info we would rather just give it to you than make you dance for it ;)

i understand very well your point, but i'll ask you this: what use could be there for reverse eng the modules if someone gives you them working well?! why would someone do reverse eng on something that is working well and loose time doing this? i think it's a stupid thing.
anyway, i agree with you that releasing something that could break your legal obligation with someone else is a stupid thing. well, i hope that amd will come out with some idea to fix this in the future.

[TechMage89]

I'd be perfectly fine with a blob for video decoding. I understand the issues here. I hope eventually the industry will wise up and realize that DRM doesn't work, but until that happens, I'd really like to have hardware accelerated video decoding, and if it can't be free, then proprietary is fine.

I don't expect Richard Stallman would agree, but I think it's best for everyone if free and propietary software coexist.

[olivermcfadden]

here i am again asking for some clarification about revenge:
is there some documentation on how to use it?
i've tried looking around the web for some hours but haven't yet found a list of options or something that could help me start it and when i start revenge it says that the option that i want is not recognized.
i think that if someone doesn't start to write some help on the matter it won't be so useful in the end.


There isn't very much documentation right now; I really should write some. There
is a README (http://gitweb.freedesktop.org/?p=users/z3ro/revenge.git;a=blob_plain;h=9d6d886828ff95708b7c8f1 477930ab82faaa5bd;f=README) included with the latest Revenge from Git. I don't remember whether
it's included in the last release...

When I add PCI-ID based card detection a lot of the nastiness from interface
switches (AGP, PCI-E, etc) will disappear, but I haven't done that yet.

Btw, the email address in the README currently isn't setup, so you should send
dumps to me directly.

[deanjo]

We can't use that architecture for "real" HD decoding, since we would be legally obligated to protect the video data that comes out of the decoder and that's kinda hard to do in an open driver, but it might be a possibility for using UVD on non-HD content if we could properly tamper-proof the binary. The obvious downside is that it's a heck of a lot easier to reverse engineer a single module than a 20 MB driver stack, and if we felt that we could safely release the info we would rather just give it to you than make you dance for it ;)

Why can't we have true HD acceleration of non-DRM'd content?

[givemesugarr]

Why can't we have true HD acceleration of non-DRM'd content?

because releasing specs for the free hd video acceleration would let reverse engineering reveal how the drm works in a matter of no time and because usually the hd content (until now) was protected by drm, which is on its last moments of life after sony, the last drm sustainer, has declared that would abandon drm for some of its content - the news is on linux journal breaking news (http://www.linuxjournal.com/node/1006011 ) while the article to which it refers is available directly on business week: http://www.businessweek.com/technology/content/jan2008/tc2008013_398775.htm .
so for example if amd would reveal how udv works for the free part
on monday someone would have commit a patch to the radeon for the
drm part. at least that's what i've understood from john's explanation on the matter.

[jc87]

We can't use that architecture for "real" HD decoding, since we would be legally obligated to protect the video data that comes out of the decoder and that's kinda hard to do in an open driver, but it might be a possibility for using UVD on non-HD content if we could properly tamper-proof the binary. The obvious downside is that it's a heck of a lot easier to reverse engineer a single module than a 20 MB driver stack, and if we felt that we could safely release the info we would rather just give it to you than make you dance for it ;)

Funny thing how DRM in the end only screws the costumer ;-)

[duby229]

So hold on, let me get this straight... We are talking about DRM (Digital Restrictions Management) not DRM (Direct Rendering Manager).... Is that correct?

If so why cant you just bypass the frontend altogether and just let all those stream processors handle HD decoding directly through something like CTM? Or maybe through an abstraction layer like GLSL or something similar?

[bridgman]

Yes, DRM like digital rights management.

Video decoding isn't the greatest fit with the kind of work stream processors can do, or at least nobody has figured out how to find sufficient parallelism in the decoding workload to take real advantage of the shader power. Having said that, there's a big difference between inefficient and impossible.

The biggest issue, I think, is that we do use the shaders pretty heavily for the rendering part of the playback pipeline so I'm not sure how much shader horespower is left on the 2400/2600 anyways.

Good question though...

[bitnick]

I thought DRM was implemented though encryption of the encoded video data? So, to play DRM protected video, the stream has to be (roughly):

1) Unencrypted
2) Decoded
3) Rendered

Is this not right? If it is right, what is the problem with implementing 2) and 3) in the oss driver? (A pointer to a document explaining the problem would be appreciated, if such exist.)

I can see one other reason not to release the specs for video hw decoding on a system that is not able to play DRM'd material: it would raise the demand for undamaged material even more, thus making it even more popular to download movies in a sane format over, say, bittorrent.

*rant*

This whole thing is just sick - why not release the movies in an open, playable format that people can USE? I and many, many others would gladly pay for it!

*rant off*

[agd5f]

I thought DRM was implemented though encryption of the encoded video data? So, to play DRM protected video, the stream has to be (roughly):

1) Unencrypted
2) Decoded
3) Rendered

Is this not right? If it is right, what is the problem with implementing 2) and 3) in the oss driver? (A pointer to a document explaining the problem would be appreciated, if such exist.)

I can see one other reason not to release the specs for video hw decoding on a system that is not able to play DRM'd material: it would raise the demand for undamaged material even more, thus making it even more popular to download movies in a sane format over, say, bittorrent.

*rant*

This whole thing is just sick - why not release the movies in an open, playable format that people can USE? I and many, many others would gladly pay for it!

*rant off*

If that pisses you off, get this: the new wireless connectivity standard for DVD players and TVs is limited to a range of a few feet due to MPAA pressure so that your neighbors won't be able to pick up what movie you're watching:
http://www.cnn.com/2008/TECH/01/03/wirelesshigh.def.ap/index.html

[Kano]

Well broadcasting a vga signal is always a security flaw when the display could show "interesting" infos. But lets compare that to HDCP. Just for the sake of hardware vendors you have to use a vga card and monitor/tv with HDCP. You absolutely gain nothing over pure DVI. And the only thing you could avoid is that you could not record the signal with a hd capable recorder. As the protection of hd dvd/blueray is already broken and could be even removed on the fly with a commericial tool a standard DVI connector would be enough. So what would you buy...?

[bridgman]

I thought DRM was implemented though encryption of the encoded video data? So, to play DRM protected video, the stream has to be (roughly):

1) Unencrypted
2) Decoded
3) Rendered

Is this not right? If it is right, what is the problem with implementing 2) and 3) in the oss driver? (A pointer to a document explaining the problem would be appreciated, if such exist.)

The problem is depressingly simple. UVD handles #1 and #2 in the same block, and a lot of the setup operations are common between the functions. We haven't found a way to open up the info you need for #2 without also opening up #1.

Implementing #3 in the open source driver won't be a problem once the 3d framework is up and running, since we use shaders for #3 in the R5xx and higher chips. We are also planning to enable use of the parts of #2 which have not yet been moved into UVD.

[fhuberts]

The problem is depressingly simple. UVD handles #1 and #2 in the same block, and a lot of the setup operations are common between the functions. We haven't found a way to open up the info you need for #2 without also opening up #1.

Implementing #3 in the open source driver won't be a problem once the 3d framework is up and running, since we use shaders for #3 in the R5xx and higher chips. We are also planning to enable use of the parts of #2 which have not yet been moved into UVD.


well, if you could release information on how to setup the block for unencrypted streams you would not be in violation of anything while still allowing the open source driver the benefit of the UVD :-)

[rapsure]

I myself am not too concerned about hardware accelerated video decoding right now. Someday it would be nice, but my AMD X2 4200 can handle most of the video out there right now. However I would love to see enough documentation to finish up the opengl 1.3 that is currently in the driver for smoothline, and a few other miscellaneous incomplete implementations that are being covered by the low impact fall back. I would also see enough documentation to finish up to at least opengl 2.0 or 2.1 so that the latest games will work with the opensource driver. After those opengl extensions were implemented then the driver could be optimized to be the fastest open driver however it is not easy reverse engineering. It takes a lot of patience (I've tried before) a little intuition to see how the device behaves with certain commands. Many more hours tweaking trying, and so having the information would allow the driver to be completed a lot quicker than it is currently being worked on. Also reverse engineering can require a considerable amount of resources since passing a bad command can let the smoke out. Most of the time these devices are engineered so that letting the smoke out is not likely to happen, but not every case can be tested and engineers are still human.

I'd really love smoothline and a better way to get the command buffer to play nicely so that Google Earth will play more nicely with the open driver. fglrx is fast, but unstable and has a few bugs that the open driver does not have. The open driver is stable except it isn't complete.