Announcement

Collapse
No announcement yet.

AMD's opensource lies exposed

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

  • glxextxexlg
    replied
    Originally posted by pingufunkybeat
    I call bullshit.
    If not, who cares?
    C'mon maan! Relax... Sing a song:



    thats what I call beauty

    Leave a comment:


  • not.sure
    replied
    Time for a car analogy:
    If you have a car that is built to open specs, and another one that is rented, but not yours, it's pretty clear which one can be better seen during night, and how long ago the meal was cooked. And after all, that's what counts.

    Leave a comment:


  • pingufunkybeat
    replied
    Originally posted by deanjo View Post
    Yawn.....

    Is that nouveau?

    I call bullshit.

    If not, who cares?

    Leave a comment:


  • monraaf
    replied
    Originally posted by towo2099 View Post
    Then let me ask in other way, why is that firmware not in the chip?
    Putting the firmware on a chip doesn't suddenly make it 'free', it still remains proprietary. Perhaps putting the firmware on a chip will give Debian users a clear conscience, but from a 'freedom' perspective nothing has fundamentally changed.

    IMO Debian users and priests should take a good look at what they are doing, understand how ridiculous it is and develop a more sane approach to firmware.

    Leave a comment:


  • glxextxexlg
    replied
    %&+%&/&%%&/ 60 FPS ^()(!'/^&%(/& That's enough for me!
    Yawn.....
    ROFLMAO! well done... beautiful composition

    Leave a comment:


  • deanjo
    replied
    Originally posted by pingufunkybeat View Post
    locked to the refresh rate (60fps) at 1920x1080. On the cheapest r700 budget card on the market.

    That's enough for me!

    I'd rather have Unigine tech demos not working than have KDE and gvim not working, thank you very much Mr. WorkraFt!
    Yawn.....

    Leave a comment:


  • bridgman
    replied
    The microcode is not burned into the chip because running it from RAM allows us to have a shorter design cycle -- it lets us avoid having to re-fab the chips if we need to change microcode before launch.

    There are a few different kinds of code that all get lumped together as "firmware". Some is horizontal microcode driving hardware state machines, some is really a big chunk of the driver that runs on a general purpose CPU on chip, and there are a few examples in between. Our microcode is closer to the hardware state machine end of the spectrum (where it's really part of the hardware design) but it all gets lumped into the "non-free" repository together.

    Leave a comment:


  • pingufunkybeat
    replied
    Originally posted by towo2099 View Post
    Then let me ask in other way, why is that firmware not in the chip?
    It runs on the chip.

    The reason why it is uploaded by the drivers is that it makes it possible to fix errors after you release the hardware. Just update the microcode.

    If you burn the microcode onto the chip, you would have to replace the entire 300$ GPU if there is a bug in the microcode.

    Yeah, it sucks. But your Intel processor and your motherboard chipset and pretty much everything else in your computer runs unfree microcode too. It's just not as obvious.

    Leave a comment:


  • towo2099
    replied
    Then let me ask in other way, why is that firmware not in the chip?
    So the user needs to activate the non-free repo, if such repo exist, that he can use the "free" driver.

    Leave a comment:


  • pingufunkybeat
    replied
    Originally posted by towo2099 View Post
    But this firmware it's not free, so is not included in any free GNU/Linux distribution, even Debian does not ship it anymore.
    Your CPU runs closed firmware too, as does every piece of hardware in your computer, starting from the BIOS.

    It's unfortunate, but by your logic, nothing is free.

    Leave a comment:

Working...
X