Announcement

Collapse
No announcement yet.

Digging Deeper Into AMD's UVD Code Drop

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

  • 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; 09 April 2013, 01:31 PM.

    Comment


    • ROM = Read Only Memory



      Your card's bios was flash, not rom.

      Comment


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

        Comment


        • 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*.

          Comment


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

            Comment


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

              Comment


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

                Comment


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

                  Comment


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

                    Comment


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

                      Comment

                      Working...
                      X