Announcement

Collapse
No announcement yet.

AMD's opensource lies exposed

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

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


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


      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

      Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.


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

      Comment


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

        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


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


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

            Comment


            • #16
              Originally posted by glxextxexlg View Post

              DO NOT BUY AMD/ATI HARDWARE
              AHAHAHA!


              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


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

                Comment


                • #18
                  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".
                  Test signature

                  Comment


                  • #19
                    Originally posted by crazycheese View Post
                    Why, every single nvidia card has 3dfx legacy. *burp*
                    yea, and think about that for more than a second crazy....

                    it may be a bit cheesy , but they did buy All the 3dfx legacy IP including that real long lasting OSS innovation everyone's still using to write those derivative drivers for x64 etc.

                    you cant get away from it, that original massive OSS code is still littered around masses of OSS code even today, even though 3dfx is no more, and few people still have that hardware ( i do, and could use it in any 5v pci slot SBC [Single Board Computer], or 'IBM PC' if i could remember which old x86 board had the 5v and not the later 3.3v)

                    if Nvidia had a mind to finally provide OSS then AMD would be very put out even with their far longer time (this time around, remember they did it once before and removed it) , its hard to compete with that 3dfx legacy even today when you dont own the patents and IP.

                    Comment


                    • #20
                      Originally posted by popper View Post
                      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.
                      You do realize that in addition to the documentation dump, AMD also dumps a load of code into the public repos, giving each new generation of hardware a basic level of support using the current Xorg/Mesa codebase. AMD is getting closer to having this code in the communities hands prior to hardware launch, and if I'm not mistaken actually achieved this for their first Fusion product. I imagine that their goal is to have this code hit the distros prior to hardware launch, so they are going to be playing catch-up for a while longer.

                      More advanced levels of support (OpenGL 3/4, OpenCL, etc) have been left to the OSS community mainly because the required infrastructure to provide the support isn't there yet. This infrastructure is slowly evolving in the Gallium3D project within Mesa to support the more advanced features of newer cards. As new features are added to Mesa, you can see AMD employees updating the respective bits in their drivers to support the change.

                      I'd have to say that AMD's level of support is more than "kind of OK", and that they are doing an excellent job at providing OSS support for their hardware.

                      Comment

                      Working...
                      X