Announcement

Collapse
No announcement yet.

AMD's opensource lies exposed

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

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


            • #16
              OC the question remains, will the 'man with the plan' under the bridge (and a professional interest in IP licensing, security, open source Cottage and Self catering Caravan Accommodation. Mudgeon Farm ...?) and his new super CEO swinging the "Undocumented Verification Doohickey" V4 check book for the new financial year to come, be able to finally swing that long standing review and come up with something viable well before 2012 (that spare 12 mill just laying around the executive board rooms would have been very useful 'The Plan' id imagine) never mind the next 4 years (he tells us) it takes to make a new generation Chip etc.

              Comment


              • #17
                3dfx is not really an option today, though.

                Comment


                • #18
                  Originally posted by glxextxexlg View Post

                  DO NOT BUY AMD/ATI HARDWARE
                  AHAHAHA!
                  http://phoronix.com/forums/showthrea...Nouveau-Driver

                  So, you provide a link for windows driver? A proprietary one? And tell me opensource linux is bad?

                  Another reason for AMD and others to work on linux drivers as MORE AND MORE people will SWITCH from windows.

                  If AMD makes efficient mechanism to bind each of sold cards with opensource driver support, they will be unbeatable.

                  I wonder why MS does not publish information on large back-door in all windowses. It just should have already happened.

                  Comment


                  • #19
                    Originally posted by pingufunkybeat View Post
                    3dfx is not really an option today, though.
                    Why, every single nvidia card has 3dfx legacy. *burp*

                    Comment


                    • #20
                      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.
                      I don't believe anyone has ever made that argument, or at least I have never seen it.

                      What I think you mean is that "once a HW vendor has released specs and/or code for hardware into the open source community that information can't be taken back so the hardware can be supported indefinitely, while binary blob support can eventually break".

                      Comment

                      Working...
                      X