Announcement

Collapse
No announcement yet.

Radeon's ROCm OpenCL Runtime Finally Open-Sourced

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

  • #61
    Originally posted by bridgman View Post

    ... and harder to maintain.

    When we announced the Radeon Pro SSG products my first thought was "hey we can put microcode images on the SSD...".

    My second thought was "... and then watch everyone scramble to redefine the rules again".
    Does this microcode contain card-specific quirks? If so, who's going to be adding those for cards no longer sold or under warranty? Or is the general idea that it's easier to put the quirks inside the driver?

    Comment


    • #62
      Originally posted by smitty3268 View Post

      The thing is, dungeon doesn't care about it. He uses the proprietary drivers anyway. This whole thing was just him trying to start a flamewar for whatever reason. I guess no good news can go without someone trying to shit all over it.
      How is that flamewar:

      1. someone posted a link...
      2. so, i read it...
      3. spotted something in my POV incorrect...
      4. sort of false advertising so i reported it

      https://www.phoronix.com/forums/foru...424#post951424

      And then someone else comment on that, without knowing maybe or reading anything from GNU/FSF sites at all to at least learn a bit what is their stance on this...

      With that in mine head Free/Libre is nowhere Yes, but more like Free/Libre No(blb fw req)
      Last edited by dungeon; 05-15-2017, 05:42 AM.

      Comment


      • #63
        If the hardware exposes an API (register level), then whatever is required to enable that API is part of the hardware, especially because it's the 21st Century and a lot of hardware is actually a fairly general-purpose CPU/DSP running firmware and exposing a function to the rest of the system. On AMD's GPUs many of the hardware blocks are 64-bit F32 CPUs (although I don't know much further than this).

        If money is saved by loading this firmware (or collection of firmwares) onto these GPU functional units at boot time, then great. It also means they can get updated should a bug be exposed.

        Without the firmware, you simply have a set on non-functional CPUs/DSPs that aren't doing anything, which in turn means the dedicated GPU resources don't get data, and nothing happens. Hence the firmware is clearly part of the hardware, and not the driver.

        I would hazard a guess that on the Scorpio games console, these on-GPU CPUs have had their firmware tweaked to optimise for DX12 offloading.

        I guess AMD could synthesise each of these CPU/DSP-enabled features as dedicated silicon, but it's not worth it (at least to date).

        Comment


        • #64
          Originally posted by nanonyme View Post
          Does this microcode contain card-specific quirks? If so, who's going to be adding those for cards no longer sold or under warranty? Or is the general idea that it's easier to put the quirks inside the driver?
          No card-specific quirks that I am aware of (they go in the driver) - we only change for "generational" updates (eg the 2xx to 3xx series) where accumulated fab process improvements allow for different timing/tuning. Those changes tend to be limited to the SMU block.

          Comment


          • #65
            Could we silence these people by saying it's a initialization sequence that must be written to the card and not microcode? So clearly it's not something that has source code, but just a byte string that the card needs to function.

            I find it annoying that people whine about microcode, especially when they somehow think it's better, if that doesn't need to be copied to the card by driver code as if that is any different. I'm quite happy that we have the open source drivers even if I need some small blob that runs on the card. It's not like the card sends my display content or VRAM content to some 3rd party when I upload this code there. (How do I know? Well, I don't, but either there would need to be some (well hidden) radio on the card or it would need to send it through PCI-E in which case the motherboard would need to be compromised as well and in that case there are better sources of information than VRAM so GPU blobs are the least of my concerns.)

            Comment


            • #66
              Originally posted by Tomin View Post
              ...

              It's not like the card sends my display content or VRAM content to some 3rd party when I upload this code there. (How do I know? Well, I don't
              You can check the microcode disassembly, as referenced by RussianNeuroMancer in #58.

              Comment


              • #67
                Echoing my Request For Comments and my question from previous posts, which were probably not seen by the active participants in this forum since the conversation was moving faster than it took for my posts to be approved:

                1) Can ROCm OpenCL be made to work with older cards, even back to the Southern Islands family?

                2) Is support for OpenCL v2.0+ in the works? 1.2 runtime is... less than ideal nowadays.

                Comment


                • #68
                  Originally posted by dungeon View Post

                  How is that flamewar:
                  It completely derailed this thread with something off-topic, so i'd say you got what you were looking for.

                  Comment


                  • #69
                    Originally posted by smitty3268 View Post
                    It completely derailed this thread with something off-topic, so i'd say you got what you were looking for.
                    I didn't get what i am looking for, i commented to illwieckz to his "linux GPU compatibility matrix" but he didn't respond.
                    Last edited by dungeon; 05-16-2017, 04:03 AM.

                    Comment


                    • #70
                      Originally posted by dungeon View Post
                      I didn't get what i am looking for, i commented to illwieckz to his "linux GPU compatibility matrix" but he didn't respond.
                      I didn't respond because others did.

                      Originally posted by dungeon View Post
                      Instead of "Yes" on "Driver status" and under "Free/Libre" it should say "No(firmware required)"
                      Closed firmware is a real, strong issue. Perhaps I will add it to my matrix, that's a nice point. But it's not a driver issue.

                      The answer was given to you by someone else right after your post, there was no need to wait 7 pages:

                      Originally posted by Spazturtle View Post
                      1) Firmware isn't part of the driver.
                      It's time to answer to other similar statement:

                      Originally posted by Serafean View Post
                      1) Driver is useless without firmware, so it effectively is.
                      Needing something does not mean being something. You need eggs to cook an omelette, you are not eggs even if you need them, and eggs are not you even if you need them. You're not the frying pan too, and the frying pan is not you, even if you need it.

                      Originally posted by Spazturtle View Post
                      1) Firmware isn't part of the driver.
                      Originally posted by dungeon View Post
                      If it is not, why you use it? Why not remove it?
                      If you remove the gaz canister from your gaz stove, you can't cook your omelette, but the gaz canister is not part of the omelette and vice versa (hopefully) even if you use it to cook your omelette. The gaz stove itself is not your omelette too, even if you use it to cook your omelette.

                      Originally posted by dungeon View Post
                      Stating something as friendly to Free/Libre, but everybody knows their stance on blob matters is already is total disrespect
                      I haven't said firmware was Free/Libre (and I'm not sure someone told it in that thread), so the disrespect is virtual. Saying firmware being Free/Libre while not being Free/Libre would be a total disrespect (and a lie), but as far as I see it did not happened, and on my own, I never said something like that. My comparison matrix does not any have firmware row yet.

                      Originally posted by Spazturtle View Post
                      2) Would you rather the firmware was on a read-only chip on the GPU?
                      Originally posted by Serafean View Post
                      2) yes. At that point it becomes hardware.
                      Having a Free/Libre firmware would be good too and I see not point on stating a firmware being a kind of hardware in some condition, the hardware has to be free too, so stating a firmware being hardware (which is false) does not exempt it from having to be free. Being embedded in hardware do not make a firmware an hardware part (exactly like needing does not mean being), it just means it's shipped with hardware as a whole, and the whole has to be free.

                      That comment I'm writing right now is 100% useless, others answered very well, and others answered very well to other flaws.

                      Originally posted by Serafean View Post
                      2) yes. At that point it becomes hardware.
                      Originally posted by wizard69 View Post
                      Personally id rather see blob free myself, however your arguements make no sense to me.
                      I'm not able to find an answer someone made, but someone said something like “The driver needs the hardware too", and that was a right statement, driver needing the hardware does not mean driver is hardware. It's the same for firmware.

                      Well, so many people answered, there was no need for me to answer. All this wall of text I'm writing up is just about telling things other told.

                      I just add a last random answer to some random statement by some random guy:

                      Originally posted by starshipeleven View Post
                      Unknown, but according to Stallman or other Free/Libre proponents it's like that. Suff in ROMs is ok, stuff loaded at runtime is not. Even if it is the same.
                      If that means Stallman is saying software has to not be updateable to be free, it means Stallman is wrong. If Stallman is saying that because of doing himself “embedding is like being” fallacy, Stallman would be wrong too: “embedding” is not “being”, and hardware has to be libre like software. Making something unmodifiable does not exempt it to be free. “Making something unmodifiable to make it free” is a kind of tivoisation, something Stallman disliked so much he rewrote a new GPL, not caring about introducing so many license incompatibility issues because the importance of stating “making something unmodifiable does not prevent it to be free” was evaluated as an higher need than not introducing inter-license incompatibilities.

                      So, for the end:

                      Originally posted by dungeon View Post
                      Column shoud say there "No (blob firmware required)" instead of "Yes" Even just that would be much more Free/Libre friendly, than stating something incorrectly
                      Please stop the fallacies and the lies. No, the column does not have to say “No (blob firmware required)”, an additional column can be added for firmware status, but it does not change driver status. Nothing is incorrectly stated.

                      It's possible to modify the matrix this way:

                      Code:
                      driver status: free
                      firmware status: non free
                      or this way:

                      Code:
                      driver status: free (notice: non-free firmware needed
                      You probably confuses things with distribution and packaging issues. Distros can't distribute a workable free package containing a free driver and a free firmware, but that does not mean the driver is not free. Shipping a package containing both free driver and non-free firmware means the whole package is not free, but it's not a driver issue. That's a package issue, that's a distro issue (and that's a problematic issue, yes), but even when the driver package is not free the driver itself is still free.
                      Last edited by illwieckz; 05-16-2017, 12:33 PM.

                      Comment

                      Working...
                      X