Page 11 of 13 FirstFirst ... 910111213 LastLast
Results 101 to 110 of 123

Thread: Digging Deeper Into AMD's UVD Code Drop

  1. #101
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    Quote Originally Posted by bridgman View Post
    AFAIK it's still a series of hypothetical scenarios trying to explain why binary microcode in ROM is OK but binary microcode in RAM is bad.
    Does it really matter though? ROM can be flashed as I proved when I flashed my 9500Pro with a 9700Pro BIOS. My opinion is that it doesnt matter where microcode exists.

    I think a similar analogy would be whether you installed on a HDD or SSD. I mean really does it matter? They are both storage media. Just because the location is different doesnt really mean very much.
    Last edited by duby229; 04-09-2013 at 02:31 PM.

  2. #102
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,269

    Default

    ROM = Read Only Memory



    Your card's bios was flash, not rom.

  3. #103
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    Flash -is- EEPROM. Electronic Erasable Programmable Read Only Memory

  4. #104
    Join Date
    Oct 2009
    Posts
    2,137

    Default

    Well, the funny thing is that basically nobody anywhere uses write-once-and-its-toast storage any more. Its basically always some form of EEPROM.

    This discussion over where the code is stored starts to get really funny when you start using media that blurs the lines between "disk" and "ROM".... like, SSD's, NAND flash, eMMC... proving once and for all, that it simply does not matter on what the code is stored. The only thing that matters is on what the code *RUNS*.

  5. #105
    Join Date
    Oct 2009
    Posts
    2,137

    Default

    Quote Originally Posted by duby229 View Post
    Does it really matter though? ROM can be flashed as I proved when I flashed my 9500Pro with a 9700Pro BIOS. My opinion is that it doesnt matter where microcode exists.
    ... who or what are you arguing against, and what point are you trying to make?

  6. #106
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    Quote Originally Posted by droidhacker View Post
    ... who or what are you arguing against, and what point are you trying to make?
    Well thats what I'm trying to figure out. The conversation in this thread seems to suggest that depending on where a firmware is located it should be OSS or not. I'm arguing that it doesnt matter where it is located. If Firmware is considered to be part of the hardware design as Bridgman suggested then it doesnt need to be OSS. The point that I made was that by simply making a solder point on a 9500Pro and flashing it with a 9700Pro BIOS it BECAME a 9700Pro. Therefore the firmware can be considered hardware design. It doesnt matter where it is located.

  7. #107
    Join Date
    Oct 2009
    Posts
    2,137

    Default

    Quote Originally Posted by curaga View Post
    The correct way would be to fit the 4-speed model with an engine that can only do 4 speeds, and then sell it at the $80k. I'm probably not good at car analogies :P
    "speed", in this context, has nothing to do with the rate of travel (or engine), rather the number of gear ratios offered by the transmission. More gear ratios (aka "speeds") = more efficiency and more performance, with the SAME engine.

  8. #108
    Join Date
    Oct 2009
    Posts
    2,137

    Default

    Quote Originally Posted by duby229 View Post
    Well thats what I'm trying to figure out. The conversation in this thread seems to suggest that depending on where a firmware is located it should be OSS or not. I'm arguing that it doesnt matter where it is located. If Firmware is considered to be part of the hardware design as Bridgman suggested then it doesnt need to be OSS. The point that I made was that by simply making a solder point on a 9500Pro and flashing it with a 9700Pro BIOS it BECAME a 9700Pro. Therefore the firmware can be considered hardware design. It doesnt matter where it is located.
    Ok, so you're on Bridgman's side. I understand.

  9. #109
    Join Date
    Oct 2008
    Posts
    3,212

    Default

    Quote Originally Posted by bridgman View Post
    I don't think your analogy really works other than sounding good (and maybe aligning with an emotional response)... it suggests little or no extra cost for development & qualification on that extra cost feature (5th gear), which is not the case at all for most of the real world product scenarios we are discussing here.
    You don't think a lot of time and money went into providing that 5th gear feature on the car? Good engines have a ton of R&D that go into them.

    I don't personally mind if firmware is binary in the case where it's just initializing hardware. There are cases where it does a lot more, like that ARM GPU that has the whole GL stack running in firmware, and that is a lot tougher to describe as just "part of the hardware". Although i can even buy that, as long as it isn't updateable.

    But if you are allowing something to be updated on the fly, that sounds an awful lot like software to me, and open-sourcing it gets more important. I don't think there's any good line in the sand you can draw that easily takes care of everything, you just have to decide on a case by case basis.

    Firmware that artificially limits the features of a product is not something i would want to ever try to defend, and it's not a good reason to keep firmware proprietary. Unless your only concern is making money, of course, and then it's a fine reason.

  10. #110
    Join Date
    Jul 2010
    Posts
    449

    Default

    Nobody has yet mentioned one problem of closed-source firmware residing in ROM: bugs. If your ROM has bugs then you hardware will *always* have bugs, it will always fail certain conformance tests etc.

    If it's in RAM, you can complain to the hardware vendor who can look into it and potentially fix it, sending you a firmware update that's much easier to apply (and can be applied by everybody else) than sending you a new card.

    I realise that "don't make firmware with bugs" is likely to be a response, but bugs happen: we're all people and we're all fallible. I'd rather AMD were able to correct any mistakes with my graphics card's programming. I'd definitely rather the firmware was open source (in case the company doesn't devote resources to solving a problem), but on this one I'm a pragmatist: if I can freely redistribute it then I'm happy enough.

Posting Permissions

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