Page 2 of 41 FirstFirst 123412 ... LastLast
Results 11 to 20 of 408

Thread: AMD's opensource lies exposed

  1. #11
    Join Date
    Jun 2009
    Posts
    2,926

    Default

    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.

  2. #12
    Join Date
    Oct 2009
    Posts
    353

    Default

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

  3. #13
    Join Date
    Jan 2008
    Posts
    772

    Default

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

  4. #14
    Join Date
    Jan 2007
    Posts
    459

    Default

    Quote 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

  5. #15
    Join Date
    Jan 2007
    Posts
    459

    Default

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

  6. #16
    Join Date
    Jan 2007
    Posts
    459

    Default

    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.

  7. #17
    Join Date
    Jun 2009
    Posts
    2,926

    Default

    3dfx is not really an option today, though.

  8. #18
    Join Date
    Apr 2010
    Posts
    1,946

    Default

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

  9. #19
    Join Date
    Apr 2010
    Posts
    1,946

    Default

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

  10. #20
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,386

    Default

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

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •