Announcement

Collapse
No announcement yet.

Radeon's ROCm OpenCL Runtime Finally Open-Sourced

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

  • bridgman
    replied
    Originally posted by Marc.2377 View Post
    1) Can ROCm OpenCL be made to work with older cards, even back to the Southern Islands family?
    Two part answer... ROCm itself requires the MEC block found in CI and up (we support Hawaii today) so running ROCm on CI parts is certainly doable in principle. Each generation back requires additional compiler and runtime work in OpenCL, however, so OpenCL support doesn't come for free just because CI runs on it.

    Going back to SI would require larger changes, essentially bypassing the current ROCm kernel/runtime interface and submitting work via kernel calls.

    Originally posted by Marc.2377 View Post
    2) Is support for OpenCL v2.0+ in the works? 1.2 runtime is... less than ideal nowadays.
    AFAIK the current support is a hybrid of 1.2 and 2.0 - kernel language support is 2.0 while runtime feature set is 1.2. The current level of support was based on our understanding of what developers actually use / plan to use so I imagine any changes would be driven by that.

    Leave a comment:


  • illwieckz
    replied
    dungeon please stop wasting other's free time, and please stop pollute that thread with fallacies and lies. And please listen when people answers to you the answers you need. No one said you need me to read the answer they made to you.

    Leave a comment:


  • illwieckz
    replied
    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; 16 May 2017, 12:33 PM.

    Leave a comment:


  • dungeon
    replied
    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; 16 May 2017, 04:03 AM.

    Leave a comment:


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

    Leave a comment:


  • Marc.2377
    replied
    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.

    Leave a comment:


  • Marc.2377
    replied
    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.

    Leave a comment:


  • Tomin
    replied
    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.)

    Leave a comment:


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

    Leave a comment:


  • sykobee
    replied
    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).

    Leave a comment:

Working...
X