>> The closed driver was primarily aimed at the workstation market,
>> where most of the users come from the Unix world and so open
>> source is really not a concern.
Sorry, closed drivers *are* a problem, not just in linux, but also
with real Unix.
> NVidia doesn't seem to be having problems with a closed driver;
Nvidia's closed drivers have bugs, including security holes.
Nvidia's closed drivers cause data loss.
Without source code these problems are effectively impossible to fix.
Binary-only drivers are unacceptable. It doesn't matter if
the chip is AMD/ATI or Nvidia or VIA or whoever's. It doesn't
matter if the OS is linux or real Unix or Plan-9 or whatever.
Binary-only drivers are unacceptable. PERIOD. How many times do
we have to say it?
> Stop defending your worthless closed driver, and get your open
> source developers on the same team.
Better yet, stop wasting resources on worthless closed driver(s),
pick one FLOSS driver (*) and have everyone work on that driver.
(*) If it makes sense for, say, R200 and R600 to have different
drivers, that's fine. I mean one driver per generation.
Announcement
Collapse
No announcement yet.
Tear-Free Acceleration For ATI EXA, Xv
Collapse
X
-
Originally posted by bridgman View PostIn most of the benchmarks I have seen Linux performance is *much* higher than 75% of Windows - probably 95% is more like it. I'll see if I can get some internal numbers for Doom3.
re: 2D, the code is perhaps 1/100th the size of 3D and the open source developers (mostly Alex) were able to implement support for a newly useful API (EXA) and get it into users hands quickly. We do expect that "new things in the framework" will hit the open source driver before fglrx; that is just one example. Alex was not fighting with himself very much while working on the EXA code (or the Textured Video code) so don't think that was a factor.
On the Textured Video side, the fglrx implementation was there for a couple of years before Compiz over AIGLX became an issue, and it was implemented in a way that didn't fit with a compositor so well. The open source implementation had the advantage of coming much later (Alex wrote it in Jan/Feb 08) so he was able to design it around Compiz from day one while the fglrx implementation needs some significant changes to work the same way.
Not sure what you mean by "a framework designed for Intel's inferior hardware". The X framework predated Intel's involvement by maybe 15 years. Keith has been working on it for a long time but only recently at Intel.
The closed driver was primarily aimed at the workstation market, where most of the users come from the Unix world and so open source is really not a concern. NVidia doesn't seem to be having problems with a closed driver; I don't think that is the main issue here.
Heres what I would like to see for once... I would like ATi to admit that they havent been allocating the resources that there products deserve. That the closed driver has no place in an open source environment. And to tell Novell just where they can shove it.
Stop defending your worthless closed driver, and get your open source developers on the same team.Last edited by duby229; 04 September 2008, 07:58 PM.
Leave a comment:
-
In most of the benchmarks I have seen Linux performance is *much* higher than 75% of Windows - probably 95% is more like it. I'll see if I can get some internal numbers for Doom3.
re: 2D, the code is perhaps 1/100th the size of 3D and the open source developers (mostly Alex) were able to implement support for a newly useful API (EXA) and get it into users hands quickly. We do expect that "new things in the framework" will hit the open source driver before fglrx; that is just one example. Alex was not fighting with himself very much while working on the EXA code (or the Textured Video code) so don't think that was a factor.
On the Textured Video side, the fglrx implementation was there for a couple of years before Compiz over AIGLX became an issue, and it was implemented in a way that didn't fit with a compositor so well. The open source implementation had the advantage of coming much later (Alex wrote it in Jan/Feb 08) so he was able to design it around Compiz from day one while the fglrx implementation needs some significant changes to work the same way.
Not sure what you mean by "a framework designed for Intel's inferior hardware". The X framework predated Intel's involvement by maybe 15 years. Keith has been working on it for a long time but only recently at Intel.
The closed driver was primarily aimed at the workstation market, where most of the users come from the Unix world and so open source is really not a concern. NVidia doesn't seem to be having problems with a closed driver; I don't think that is the main issue here.Last edited by bridgman; 04 September 2008, 03:40 PM.
Leave a comment:
-
Originally posted by TechMage89 View Postuhm, let me remind you that neither radeon nor radeonhd have anything to do with 3d acceleration. That's handled entirely in mesa, where the limitations that exist do so primarily because the whole stack needs a major update, which it's getting with gem, dri2, and gallium3d.
It's really not helpful to say that ATI is holding things back deliberately. They're making the best effort to open the docs without NDA, but unfortunately, the IP situation is a lot messier than was thought initially. The docs for r500 are already pretty much all public (except for AVIVO, which is pretty low priority anyway.)
flgrx may have crummy 2d acceleration and be buggy, but it is as fast for OpenGL as the Windows driver.
Why is that? How is it that a handful of open source developers that are are working against each other, can produce an incomplete, underdeveloped driver on an infrastructure that was designed for Intels inferior hardware? And get this, even under these extreme limitations,they still annihilate ATi's closed driver in almost every metric.
And I never said that ATi is holding the market back, but I did say that Novell is...ATi on the other hand for some reason that only they seem to know, thinks that a closed driver on an otherwise completely open platform is somehow, someway a good idea.... It may not be deliberate sabotage on ATi's part, but it certainly is stupid to the extreme.
Leave a comment:
-
Originally posted by TechMage89 View Postflgrx may have crummy 2d acceleration and be buggy, but it is as fast for OpenGL as the Windows driver.
But those games were all for Windows, isn't it? Or, there were some $$ spent for "hacking" Linux games?
Also, from what I heard, the closed driver is full of "Win blobs", adjusted via some hacking/work-arounds for working in X environment. While the OSS drivers were originally designed for X.
Yes, it supports more visuals, higher versions of OGL, etc, where OSS drivers fall back to software rendering. But I would doubt this is close to Windows version even in 3D...
Leave a comment:
-
uhm, let me remind you that neither radeon nor radeonhd have anything to do with 3d acceleration. That's handled entirely in mesa, where the limitations that exist do so primarily because the whole stack needs a major update, which it's getting with gem, dri2, and gallium3d.
It's really not helpful to say that ATI is holding things back deliberately. They're making the best effort to open the docs without NDA, but unfortunately, the IP situation is a lot messier than was thought initially. The docs for r500 are already pretty much all public (except for AVIVO, which is pretty low priority anyway.)
flgrx may have crummy 2d acceleration and be buggy, but it is as fast for OpenGL as the Windows driver.
Leave a comment:
-
Hi Bridgeman,
Sorry for the late response. After the weekend I came to work only to discover a massive outbreak of Antivirus 2008 XP... Oy...
Anyhoo....
Originally posted by bridgman View PostThere are some things about radeonhd which are more important to Novell than to Red Hat, at least for a while. One example is that the radeon modesetting code is built natively around randr1.2, which makes the code nice and simple but means that xservers without randr1.2 are not directly supported. A lot of Novell enterprise distros in use today are running pre-Randr1.2 x servers while the corresponding Red Hat distros are running slightly newer X servers and are happy with only RandR1.2-based modesetting. My understanding is that it should be possible to pick up the RandR1.2 code from the server and patch it into the driver but the Novell devs had a strong preference for supporting the pre-RandR1.2 API directly.
There are a number of similar issues. None of them are showstoppers but it will take time to work through them all. Once we have a combination of feature set and implementation style that all the major distros and devs can agree on we should be able to get to a single driver. The "duplicated effort" is mostly in the past, since the bulk of ongoing work will either be in the drm or mesa components, which were never duplicated.
They definitely have a financial bias against the linux community, and it is because of this that it is no coincidence that they chose to buy Suse, and has since then proceeded to obfuscate, and divert resources industry wide across a huge range of projects..
Depends on whether you are talking about 2D or 3D. On the 3D side the performance is pretty close already, and fglrx will probably continue to be faster than the open source driver because the API is common with other OSes and we can take advantage of a common code base across OSes.
On the 2D side the performance is probably slower but it's tough to compare apples-to-apples because the acceleration framework is different and a number of the apps use different rendering approaches on Linux vs. Windows. If you run EXA on the open source driver with 1.5 server you should get an idea of what is possible with the current accel framework, and I expect that fglrx will approximate that over time. Performance in 2D is more driven by framework improvements and application changes than by driver sophistication, so fglrx will not have the same kind of inherent performance edge that it does in 3D.
I don't understand this - can you fill me in ? Our open source drivers run on our high end workstation cards, and once the memory management work catches up with the recent change from TTM to GEM I expect the new framework features will arrive more or less simultaneously on Radeon parts. Most of the performance difference between fglrx and open source drivers today is a function of framework features and driver architecture, but those are all being addressed.
Are you saying that we are artificially holding back the open source drivers somehow, or are you just saying that by providing a closed source driver for the Linux workstation business we are somehow stealing resources from the open source drivers ?
And then there are ATi's excuses for why they cant support crossfire on the open drivers, or proper video decode on the open drivers, or etc, etc, etc... The list again goes on and on and on again. Tell me why ATi couldnt use an industry standards interconnect? And becouse they chose to implement a proprietary interconnect shouldnt they be obligated to document it?
The fglrx driver will probably continue to be faster in 3D because of the cross-OS $$ we invest in things like a proprietary shader compiler and performance optimizations, but that investment is only available to the Linux driver *because* we share closed-source code with other OSes. If we had a dedicated Linux open source driver then it would *not* benefit from the work done for other OSes in common code and would perform more like the open source drivers we have today.
That said, all this discussion is fairly pointless, since the performance of the open source driver stack today is not representative of how it will perform once the next round of framework improvements (primarily gated by memory management today) arrive and allow corresponding improvements to be made in the driver. I think the driver world will look quite different six months from now.
Once Intel gets a top end competitor out on a stable feature complete open source driver, ATi is done. It has no future from that point forward.Last edited by duby229; 04 September 2008, 12:31 AM.
Leave a comment:
-
Originally posted by duby229 View PostSo with that bolded statement in ming, again what was the point in radeonhd? You keep bringing up native modesetting as it's only saving grace except that you've already admitted that it was a watse of time due to KMS. I'm sorry but I just cant find anything redeeming. Nothing.
There are a number of similar issues. None of them are showstoppers but it will take time to work through them all. Once we have a combination of feature set and implementation style that all the major distros and devs can agree on we should be able to get to a single driver. The "duplicated effort" is mostly in the past, since the bulk of ongoing work will either be in the drm or mesa components, which were never duplicated.
Originally posted by duby229 View PostI think your totally mistaken about fglrx... It's linux performance --sucks-- compared to it's windows performance. I dont ever expect the open source driver to ever get the same level of performance that the windows driver has, but I'd be happy with 75%...fglrx doesnt even come close to offering that and I'm 100% convinced that the open source driver will surpass it....
On the 2D side the performance is probably slower but it's tough to compare apples-to-apples because the acceleration framework is different and a number of the apps use different rendering approaches on Linux vs. Windows. If you run EXA on the open source driver with 1.5 server you should get an idea of what is possible with the current accel framework, and I expect that fglrx will approximate that over time. Performance in 2D is more driven by framework improvements and application changes than by driver sophistication, so fglrx will not have the same kind of inherent performance edge that it does in 3D.
Originally posted by duby229 View PostSo far the only benefits that the closed driver has over the open driver is artificially imposed by ATi. Personally I think they should be ashamed of themselves, especially in the face of Intels open source driver running on Larrabee...
Are you saying that we are artificially holding back the open source drivers somehow, or are you just saying that by providing a closed source driver for the Linux workstation business we are somehow stealing resources from the open source drivers ?
The fglrx driver will probably continue to be faster in 3D because of the cross-OS $$ we invest in things like a proprietary shader compiler and performance optimizations, but that investment is only available to the Linux driver *because* we share closed-source code with other OSes. If we had a dedicated Linux open source driver then it would *not* benefit from the work done for other OSes in common code and would perform more like the open source drivers we have today.
That said, all this discussion is fairly pointless, since the performance of the open source driver stack today is not representative of how it will perform once the next round of framework improvements (primarily gated by memory management today) arrive and allow corresponding improvements to be made in the driver. I think the driver world will look quite different six months from now.Last edited by bridgman; 02 September 2008, 11:34 AM.
Leave a comment:
-
Originally posted by TechMage89 View PostDuby, you're being a bit abrasive and also unrealisitc. Radeon and radeonhd are *very* similar drivers. Very little effort is being duplicated at this poing and a lot of code is being shared. RadeonHD is arguably the better driver since the inclusion of ATOMBios, which enables it to do modesetting natively for cards that it knows about, and with ATOMBios for everything else. Also, the acceleration code for r600+ is totally different from anything prior, so including in radeon would be rather impractical.
Saying fglrx needs to go away is rather impractical. The mesa 3d driver will never equal the 3d performance of fglrx, simply because ATI spends the time and money to optimize their driver for specific games and has more resources at their desposal. The mesa driver may get withing 10-20 percent of fglrx, but probably no closer. ATI can't very well release code that contains IP that isn't theirs, so open-sourcing fglrx isn't practical either. Fglrx will always have a place, but hopefully a more marginal one as the open-source driver improves.
I think your totally mistaken about fglrx... It's linux performance --sucks-- compared to it's windows performance. I dont ever expect the open source driver to ever get the same level of performance that the windows driver has, but I'd be happy with 75%...fglrx doesnt even come close to offering that and I'm 100% convinced that the open source driver will surpass it....
So far the only benefits that the closed driver has over the open driver is artificially imposed by ATi. Personally I think they should be ashamed of themselves, especially in the face of Intels open source driver running on Larrabee... Like I said the window of opportunity is closing and ATi needs to get on the ball while they still can...Last edited by duby229; 01 September 2008, 10:51 AM.
Leave a comment:
-
Originally posted by TechMage89 View PostSaying fglrx needs to go away is rather impractical. The mesa 3d driver will never equal the 3d performance of fglrx, simply because ATI spends the time and money to optimize their driver for specific games and has more resources at their desposal. The mesa driver may get withing 10-20 percent of fglrx, but probably no closer.
Leave a comment:
Leave a comment: