Announcement

Collapse
No announcement yet.

AMD's opensource lies exposed

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

  • AMD's opensource lies exposed

    The famous argument of AMD spec fanboys is that AMD will allways go on with providing full specs for their hardware while binary blob support can eventually break. In fact the truth is the opposite of it. It appears that the false opensource prophecy can break any time soon:

    http://www.cs.auckland.ac.nz/~pgut00..._cost.html#oss

    From that text:
    The only way to protect the HFS process therefore is to not release any technical details on the device beyond a minimum required for web site reviews and comparison with other products.
    Will opensource "drivers" from AMD support OpenGL 3x/4x and video acceleration in the future? Given the patented floating point support in OGL 3 and s3tc and these DRM arrangements, I've my doubts.
    So amd linux users will have half-baked featureless opensource drivers when amd will drop binary driver support for r600/r700 hardware and another waiting period will start for these people to be able to play OilRush.

    Wake up.

  • #2
    The main conclusion I draw from this is actually that ZDNet consists of a bunch of asswipes

    Comment


    • #3
      Originally posted by glxextxexlg View Post
      The famous argument of AMD spec fanboys is that AMD will allways go on with providing full specs for their hardware while binary blob support can eventually break. In fact the truth is the opposite of it. It appears that the false opensource prophecy can break any time soon:

      http://www.cs.auckland.ac.nz/~pgut00..._cost.html#oss

      From that text:


      Will opensource "drivers" from AMD support OpenGL 3x/4x and video acceleration in the future? Given the patented floating point support in OGL 3 and s3tc and these DRM arrangements, I've my doubts.
      So amd linux users will have half-baked featureless opensource drivers when amd will drop binary driver support for r600/r700 hardware and another waiting period will start for these people to be able to play OilRush.

      Wake up.
      http://www.patentlit.com/2008/05/02/...ati-is-a-draw/

      maybe you are wrong because SGI allready sued ati/amd for that.

      and amd starts fighting on court against SGI and if AMD win the opensource driver can have floading point graphics to.

      Comment


      • #4
        This, friends, is a textbook definition of FUD.

        Back in reality, AMD has released thousands of pages of documentation and tens of thousands of lines of code over a period of several years.

        Nvidia has released a patch for X, which was needed to make their drivers work.

        Comment


        • #5
          Back in reality, AMD has released thousands of pages of documentation and tens of thousands of lines of code over a period of several years.

          Nvidia has released a patch for X, which was needed to make their drivers work.
          And the results? Nvidia's drivers do what they are supposed to do... And amd's opensource support hardly got to the point of opengl 2.1 support with unacceptable performance and bugs. You call this support?

          The year was early 2009 when amd dropped support for r300-r500 hardware and Doom3 in 2011 still doesn't run well with r300g drivers. And thats after tremendous amount of hard work done by marek olsak and corbin simpson...

          DO NOT BUY AMD/ATI HARDWARE

          Comment


          • #6
            Originally posted by glxextxexlg View Post
            [...]
            stop using big red letters. i show you an link about an SGI vs AMD court tropic.

            and you don't get the point its SGI fault its the US patent system that hurt opensource and not AMD.

            you are just writing FUD a lot if shit out of your mouth.

            Comment


            • #7
              Originally posted by Qaridarium View Post
              stop using big red letters. i show you an link about an SGI vs AMD court tropic.

              and you don't get the point its SGI fault its the US patent system that hurt opensource and not AMD.

              you are just writing FUD a lot if shit out of your mouth.
              Exactly. Maybe worth asking Michael to close/delete this thread?
              Obviously AMD can only do what doesn't hurt it too much, given the patent system it's options are limited and we should thank AMD for at least providing the lots of documentation and source code it already did. We should also thank Nvidia for not objecting to the nouveau effort and for being the only provider of (best) video acceleration on linux (vdpau) and best quality opengl drivers - if not for nvidia's proprietary driver's quality (and vdpau) I wouldn't be using Linux now.

              Comment


              • #8
                Originally posted by cl333r View Post
                Exactly. Maybe worth asking Michael to close/delete this thread?
                No. This would indicate that the OP is right and someone is trying to silence him.

                Comment


                • #9
                  Originally posted by glxextxexlg View Post
                  The famous argument of AMD spec fanboys is that AMD will allways go on with providing full specs for their hardware while binary blob support can eventually break. In fact the truth is the opposite of it. It appears that the false opensource prophecy can break any time soon:

                  http://www.cs.auckland.ac.nz/~pgut00..._cost.html#oss

                  From that text:


                  Will opensource "drivers" from AMD support OpenGL 3x/4x and video acceleration in the future? Given the patented floating point support in OGL 3 and s3tc and these DRM arrangements, I've my doubts.
                  So amd linux users will have half-baked featureless opensource drivers when amd will drop binary driver support for r600/r700 hardware and another waiting period will start for these people to be able to play OilRush.

                  Wake up.
                  wakes up,(being old so needing lots of power naps and so also know's and used so called OSS that was around well before so called Linux OSS even existed or was even called that, aka AmiNet, around that referenced so called "Many small companies, the traditional garage startup" time ).

                  looks and actually reads the supplied linked text as it good practice to never dismiss people before you check the real facts...

                  realises it says Auckland New Zealand and is a single personal "Cost Analysis" by a single non legal person after taking notes of a very Old "private security mailing list and had to be somewhat hastily retrofitted for non-security-geeks"

                  re-read's glxextxexlg post again , just to be sure of its meaning and point....

                  realises glxextxexlg is a little confused and points him to an equally confused NZ paper , they seem to have a lot of them...

                  http://www.cs.auckland.ac.nz/courses...pers/cyuen.pdf
                  as regards drm, copywrite, and personal Privacy !

                  confused about copywrite ?, you will be
                  http://www.copyright.net.nz/

                  Comment


                  • #10
                    Originally posted by popper View Post
                    http://www.cs.auckland.ac.nz/courses...pers/cyuen.pdf
                    as regards drm, copywrite, and personal Privacy !

                    confused about copywrite ?, you will be
                    http://www.copyright.net.nz/
                    Heh, your gonna get hammered on your spelling of copyright.

                    Comment


                    • #11
                      Nah, I'll keep buying AMD's stuff because I value open source software.

                      You're free to run whatever you want: closed source drivers, closed source kernel, closed source filesystem, knock yourself out.

                      I finished Doom3 and the expansion pack using free drivers on my r700, and almost everything I need runs acceptably, and it's open, thanks to AMD's efforts, as well as those of other developets -- that's how OSS works.

                      But you're trolling again, first you claimed that AMD is NOT releasing documentation, then you switched your argument to "they're releasing lots of documentation, but nobody wants documentation". This sort of circular argumentation is meant to confuse readers and discourage people from getting into pointless arguments with you, which is what you want.

                      Comment


                      • #12
                        Originally posted by RealNC View Post
                        No. This would indicate that the OP is right and someone is trying to silence him.
                        Do you yourself understand what you're saying and the half-logic behind it? Closing it doesn't prove anything, nor is it meant to prove anything. Give me a break, I thought people are sick of FUD and when such a thing pops up I think it's worth closing to spare people's nerves, but if you it's not FUD, than please, go on discussing, I don't mind, just don't use sophisms like the one above.

                        Comment


                        • #13
                          The quoted argument misconstrues the problem, and thus the conclusion is wrong. Others have already mentioned the proof that it's wrong (docs have been released), but I guess I'll explain how it's wrong, since on a superficial level it seems pretty convincing. It says that essentially no technical info can be released, but an HFS is not going to exercise the entire device. You generally can't just go around clobbering a whole device state, especially in a modern OS. In fact, the HFS might only exercise one peripheral block that is unique to the device, but isn't directly connected to the core functionality. Let's call it the Undocumented Verification Doohickey, just for the sake of argument. AMD/ATI can document everything else as long as the UVD block stays closed. Some people might be disappointed by the lack of UVD support, but the core GPU functionality can still be supported just fine.

                          As for the patent issues, the FOSS world has ways of dealing with that. FreeType had patent-covered hinting code for years, and simply didn't compile it in by default until the patents expired. S3TC support is already available; it's just in a separate library instead of being part of the Mesa tree. Brian Paul has suggested a similar approach for FP textures, and there is already a Mesa branch with FP texture support. In short, work is being done on this. Developers are aware of the issue, and they aren't just throwing up their hands and saying "aw shucks, we can't do anything".

                          Comment


                          • #14
                            Originally posted by pingufunkybeat View Post
                            Nah, I'll keep buying AMD's stuff because I value open source software.

                            You're free to run whatever you want: closed source drivers, closed source kernel, closed source filesystem, knock yourself out.

                            I finished Doom3 and the expansion pack using free drivers on my r700, and almost everything I need runs acceptably, and it's open, thanks to AMD's efforts, as well as those of other developets -- that's how OSS works.

                            But you're trolling again, first you claimed that AMD is NOT releasing documentation, then you switched your argument to "they're releasing lots of documentation, but nobody wants documentation". This sort of circular argumentation is meant to confuse readers and discourage people from getting into pointless arguments with you, which is what you want.
                            "I'll keep buying AMD's stuff because I value open source software.

                            You're free to run whatever you want:"

                            Yeah, although AMD will never be the real OSS innovation that was 3DFX and their Fully working open code drivers and innovative POV plus the 3dfx voodoo 2 sli dual Gfx Hardware cards still work fine OC today http://www.youtube.com/watch?v=e7WeTdpMCSI

                            hell you can even get the 3dfx voodoo 3 driver for windows xp x64
                            http://www.opendrivers.com/company/2...-download.html

                            AMD are kind of OK and have some form of derivative of a real OSS plan that may work, here's the docs now go and do our work please.

                            but 3DFX did write that OSS code OC and most of all they had cool 'save the planet' adverts to back that code up

                            http://www.youtube.com/watch?v=4crvOyq4NMM

                            Ohh well off for another nap in my Executive Power Nap chair, You do have one right

                            Comment


                            • #15
                              Originally posted by Ex-Cyber View Post
                              The quoted argument misconstrues the problem, and thus the conclusion is wrong. Others have already mentioned the proof that it's wrong (docs have been released), but I guess I'll explain how it's wrong, since on a superficial level it seems pretty convincing.

                              It says that essentially no technical info can be released, but an HFS is not going to exercise the entire device.

                              You generally can't just go around clobbering a whole device state, especially in a modern OS. In fact, the HFS might only exercise one peripheral block that is unique to the device, but isn't directly connected to the core functionality.

                              Let's call it the Undocumented Verification Doohickey, just for the sake of argument. AMD/ATI can document everything else as long as the UVD block stays closed.

                              Some people might be disappointed by the lack of UVD support, but the core GPU functionality can still be supported just fine.

                              As for the patent issues, the FOSS world has ways of dealing with that. FreeType had patent-covered hinting code for years, and simply didn't compile it in by default until the patents expired. S3TC support is already available; it's just in a separate library instead of being part of the Mesa tree.

                              Brian Paul has suggested a similar approach for FP textures, and there is already a Mesa branch with FP texture support. In short, work is being done on this. Developers are aware of the issue, and they aren't just throwing up their hands and saying "aw shucks, we can't do anything".
                              and is clear to those that actually look around and see what's happening right now, that "Undocumented Verification Doohickey" doesn't help you when you forget to verify with the executive that they removed or at least moved the 'Doohickey Recoverable Magic" in to a separate device for version 4 ready for that new low power embedded market, oh but wait that mean's OSS Linux so no "Undocumented Verification Doohickey" allowed there.

                              and the executive cant seem to think about anything but the BOM never mind find what other vendors are actually doing (and at a manageable BOM cost) to grow their markets there and elsewhere off the main track....

                              while there's no mention of a "Undocumented Verification Doohickey" there yet
                              http://www.eetimes.com/electronics-n...tom-FPGA-chips
                              it seem clear enough without over estimating the costs , mass consumer markets may have a chance and the potential to get real interesting and make mass new profits for all concerned (plant vendors,OEM's ,3rd party IP provider and end users alike) real soon, i dont know for sure but we shall see.

                              Comment

                              Working...
                              X