Announcement

Collapse
No announcement yet.

Tear-Free Acceleration For ATI EXA, Xv

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    No tearing please, we're British

    The sync-to-vblank technique used by compiz can't work reliably with indirect rendering. Until we can use compiz with direct rendering with DRI2, the only hope there is to set the vblank_mode option to 2 or 3 in /etc/drirc. Unfortunately, that doesn't help in the non-fullscreen case either, as compiz uses the GLX_MESA_copy_sub_buffer extension instead of buffer swaps for incremental screen updates. And in the fullscreen case, compiz can unredirect the window anyway, in which case the following applies:

    It should be relatively straightforward to integrate the XVideo part of Alex's patch into mainline xf86-video-ati Git. Only the normal 2D rendering part isn't ready.

    Comment


    • #62
      Originally posted by TechMage89 View Post
      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.
      While it may have features that OSS doesn't(because of drm, etc), OSS will imo get ahead. Many games use OpenGL 2 and GLSL, this is where mesa is behind, once gallium comes, GL2 and 3 as well as the GLSL's should be implemented, then it should be very close

      Comment


      • #63
        Originally posted by TechMage89 View Post
        Duby, 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 simply cant agree with you... I've taken the liberty of bolding one thing that you've said... So 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.

        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; 09-01-2008, 10:51 AM.

        Comment


        • #64
          Originally posted by duby229 View Post
          So 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 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.

          Originally posted by duby229 View Post
          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....
          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.

          Originally posted by duby229 View Post
          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...
          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 ?

          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; 09-02-2008, 11:34 AM.

          Comment


          • #65
            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 Post
            There 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.
            Which is --exactly-- why ATi needs to tell Novell to suck on an orange. Time and time again Novel does something totally retarded specifically for the sole reason of holding our industry back. This is just one more example in a massive string of others. I could go on and on about just how corrupted Novell really is, and show where most of there money comes from, but I'll choose to keep this short and sweet. I'll just say this... Novells earnings reports are damn near illegal.


            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.
            3D, 2D, Video. It's all the same.... Buggy, slow, incompatable, unstable, incomplete, not standards compliant, etc, etc, etc. The list goes on and on and on.. I'll just put it like this, Play Doom3 on Windows, and then on Linux using fglrx on the same hardware, nuff said...... This is not a suggestion, you should actually do it. See for yourself.

            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 ?
            Absolutely yes. Beyond the shadow of any doubt. 100% Clearly and obviously. The problem is that while the radeonhd devs were busy accomplishing -nothing- the memory management code could have been worked on by more people. While ATi was busy writing a buggy, incomplete, unstable, non-compliant, propriatary driver they could have been working on releasing documentation faster, or helping the xserver devs, or helping the mesa devs... Hell any one of a 100 other things far more productive.

            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.
            No this is exactly what the point is. fglrx performance sucks, radeonhd is a waste, and radeon isnt anywhere near what it could be, and should be by now. ATi has spread itself too thin and --must-- consolidate.

            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; 09-04-2008, 12:31 AM.

            Comment


            • #66
              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.

              Comment


              • #67
                Originally posted by TechMage89 View Post
                flgrx may have crummy 2d acceleration and be buggy, but it is as fast for OpenGL as the Windows driver.
                It's very interesting point... "With all the $$ spent for hacking of Games' not-driver-friendly code", someone said..

                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...

                Comment


                • #68
                  Originally posted by TechMage89 View Post
                  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.
                  I fully understand and appreciate that, however fglrx's 3d performance is --not-- up to par with windows. Not even 75%. I fully expect that in the coming year or two mesa will at least hit 75% of the single GPU performance. On the other hand the open driver is responsible for 2d acceleration, and video acceleration, and in both cases the open driver is wholly inadequate and yet it still outperforms the closed 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.

                  Comment


                  • #69
                    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; 09-04-2008, 03:40 PM.

                    Comment


                    • #70
                      Originally posted by bridgman View Post
                      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.
                      I understand your position as a public face for ATi, and I appreciate it very much. We need more people like you in this industry for sure, but I really dont think that you are being at all realistic. I think your views are so far off base right now that they likely arent representative of the majority. I think you give ATi a much greater role in the open source community then they deserve. And you portray the closed driver as some sort of "requirement" I think your out of touch with reality, and are getting deeper and deeper in delusions that are driven by marketing.

                      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; 09-04-2008, 07:58 PM.

                      Comment


                      • #71
                        >> 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.

                        Comment


                        • #72
                          Sorry, closed drivers *are* a problem, not just in linux, but also with real Unix.
                          Well, the vast majority of companies out there use Windows and closed drivers and the Earth hasn't apparently exploded yet. Focusing on Nvidia, it can't be that bad when folks are using their tools and hardware to do molecular mechanics and weather simulations among others.

                          Nvidia's closed drivers have bugs, including security holes.
                          Of course, because free drivers are also bug free.

                          Nvidia's closed drivers cause data loss.
                          This is simply not true. Even if it was, it would have nothing to do with them being closed.

                          Without source code these problems are effectively impossible to fix.
                          You mean efectively impossible to fix by somebody outside their party. Nothing impedes them to fix their bugs, and the proof is that they do.

                          Binary-only drivers are unacceptable. PERIOD. How many times do we have to say it?
                          It's not how many times and how loud you say it. If you don't back up your position with an argument of some sort it basically goes nowhere. Even if you do it might be possible (marginally) that your interests do not equal, say, AMD's interests.

                          Stop defending your worthless closed driver, and get your open source developers on the same team.
                          Their 'worthless closed driver' is the only way many people has to play games at any half decent frame rate, or to run some 3D applications at its full power (*). Is fglrx crap? In my experience, yes; but wiping it out as suggested before is non sense. Fortunately for AMD's stakeholders, their guys know better than following the advice posted at some random forum.

                          You still haven't got that the open source drivers are not going to catch up with the closed driver in terms of 3D performance. No matter they themselves said it here, the mantra goes on and on. I have the feeling that some of this open source loving (I'm not pointing at you two, guys) comes more from the frustration that fglrx has brought to many linux users than to anything else.


                          (*) I can't run properly VMD with the open source drivers, and couldn't run Gtkradiant at all until some months ago. Given that I count with three fingers the number of 3D apps I use, the percentage is rather bad (_in my case_).

                          Comment


                          • #73
                            Originally posted by Dieter View Post
                            Better yet, stop wasting resources on worthless closed driver(s),
                            pick one FLOSS driver (*) and have everyone work on that driver.
                            I don't think that's something ATI controls. They contribute to the radeohHD effort, but it's run by Novell. I'm not sure what ATI's relationship is with "radeon" outside of moral support and possibly some technical assistance.

                            I'm sure ATI has some influence, but I doubt John or anyone else at ATI is in a position to call one of the open-source driver teams and tell them to cease what they're doing and just work on the other project. ATI might suggest that happen...ATI might have already suggested that happen, but I suspect the personal and theological divides are still too great and ATI cannot force it to happen. And, probably shouldn't, all things considered.

                            I'm very sure John isn't in a position to make the case to his management that they need to quit working on FGLRX and devote those resources to the open driver. Because like it or not, there's a butt-load of revenue tied to the CAD/Workstation market and almost zero revenue potential in gaming on Linux, which is what you want to see developed.

                            I'm as sorry as anyone else that Radeon/FGLRX doesn't work any better than it does with games, but I understand why it's not job #1.

                            FireGL/FGLRX is a pretty good solution for the CAD/Technical workstation segment. That's one area were a lot of people are betting it's going to be possible to make money with Linux-based solutions. It's a (comparatively) huge market and there are a lot of seats at stake. Have you priced a FireGL card, recently?

                            Look at what happened at SIGGRAPH this year. The Khronos Group threw the gamers under the bus (again) in favor of the development track pushed by the CAD/Workstation faction. When you look at who's funding Khronos that's no surprise, and it's pretty clear as to who's going to control the development of OpenGL for the forseeable future. I don't think they care much about wobbly windows. Or accelerated 3D.

                            That said, I do think ATI is coming around to the realization that even though there isn't much direct revenue to be had from Desktop Linux it's still something they ought to do better at. Pride if nothing else. And I think they decided to go open-source because it's a perfect approach for what they need to do...it doesn't cost much and what costs there are get split with others. ATI won't incur any support or maintenance liability and that is an important consideration if you don't expect the product to generate any revenue.

                            The drawbacks are what we see, of course.

                            Comment


                            • #74
                              >> Well, the vast majority of companies out there use Windows
                              >> and closed drivers and the Earth hasn't apparently exploded yet.

                              Lots of people do lots of stupid things and the Earth hasn't
                              exploded. But the Earth would be a much better place to live
                              if people made better choices.

                              >>> Nvidia's closed drivers have bugs, including security holes.

                              >> Of course, because free drivers are also bug free.

                              Compare OpenBSD's security record with ms-virus-server's.

                              >>> Nvidia's closed drivers cause data loss.

                              >> This is simply not true.

                              What, if something hasn't happened to you personally, you think
                              it hasn't happened to anyone?

                              >> Even if it was, it would have nothing to
                              >> do with them being closed.

                              The inability for users to fix it has everything to do with
                              not having source.

                              >> Their 'worthless closed driver' is the only way many people has
                              >> to play games at any half decent frame rate

                              If you think that playing games is more important than security and
                              data integrity you can expect a very bad experience in your future.

                              >> You still haven't got that the open source drivers are not going
                              >> to catch up with the closed driver in terms of 3D performance.

                              Personally, I don't expect to need *any* 3D performance in
                              the foreseeable future.

                              > almost zero revenue potential in gaming on Linux, which is what
                              > you want to see developed

                              I don't run linux, I run real Unix. I couldn't care less about
                              silly 3D gaming. What makes you think I care about gaming on linux?

                              > Have you priced a FireGL card, recently?

                              Not the GL, but the "FirePro V3700 will cost a mere $99 USD"
                              http://www.phoronix.com/scan.php?pag...item&px=NjY0NA

                              > ATI is coming around to the realization that even though there
                              > isn't much direct revenue to be had from Desktop Linux it's
                              > still something they ought to do better at

                              There is more to revenue than direct revenue. There is more to
                              FLOSS than just linux. There are more markets than just CAD
                              workstations and desktop. Big markets.

                              Comment


                              • #75
                                >>> Nvidia's closed drivers have bugs, including security holes.
                                >> Of course, because free drivers are also bug free.
                                Compare OpenBSD's security record with ms-virus-server's.
                                That's one example (from which I don't have and you haven't given any numbers, anyway). I'm sure you could come up with others pointing to the opposite direction and they would all still mean nothing, for just examples they are. But if we want to play this game, _my experience_ is that many open source applications are rather buggy. I use and enjoy them, but I'm not blind.

                                Nvidia's closed drivers cause data loss.
                                This is simply not true.
                                What, if something hasn't happened to you personally, you think it hasn't happened to anyone?
                                Definitely not, for the same reason that you don't think that what's happened to you must have happened to everybody else. To be honest, I get your point, but you'll admit that saying "Nvidia close drivers cause data loss" is a bit categorical and missleading.

                                >> Even if it was, it would have nothing to
                                >> do with them being closed.
                                The inability for users to fix it has everything to do with
                                not having source.
                                Sorry, users don't fix anything. Under a positive ligth, they use the software and report problems to developers. Under a negative one, they complain without having a clue. That there are sources out there doesn't mean that somebody is going to hack the hell out of them to bring the ultimate product to the masses; even less in a timely manner.

                                If you think that playing games is more important than security and
                                data integrity you can expect a very bad experience in your future. Personally, I don't expect to need *any* 3D performance in
                                the foreseeable future.
                                Of course I don't think so, and my 3D needs are very modest too. That's why I run the oss driver most of the time, because it works (*). When time ago Bridgman explained the strategy of having a decent, more or less feature complete oss driver and an optimised, fine tuned closed one I thought "bollocks". My first reaction was the typical defensive position. Then I realised that I was already doing exactly that, picking what best suits me according to my needs.

                                Oss developers are constantly adding more features and improving their drivers, while AMD's released the docs for their cards. I'm not sure what else is wanted. Sure, if you want it _here_ and you want it _now_ and under the conditions that _you_ happen to prefer, you're gonna get frustrated no matter what.



                                (*)Being rather busy at the moment I haven't play at all for a good while, meaning no fglrx. My laptop's uptime had never been this high.

                                Comment

                                Working...
                                X