Radeon's ROCm OpenCL Runtime Finally Open-Sourced

[nevion]

True... but we implemented OpenCL 2.0 across the board back in early 2015 and none of the other vendors did anything... so pretty much all of the real world apps ended up being stuck at 1.2 level. Other vendors are finally starting to work on 2.0 support so I expect this will change eventually.

Well if you count Intel's CPU only side on Linux, and potentially CPU/IGPU on windows they've been beating everybody in timely delivery of 2.0+ support. Was painful seeing them claim this trophy. But I get you on the overall with the other vendors not updating. The conformance chart Neil Trevett put together in 2016 and 2017 hasn't changed much.

[starshipeleven]

So how's the protection against viruses like https://www.extremetech.com/computin...tem-activities ? Can any (invected) software read and write the firmware blob?

Afaik blobs are signed, any modification prevents loading them.

Also note, that article describes how you can use a GPU to help avoid detection of a malware running on CPU.

Running malware fully on GPU is pointless in modern systems that have IOMMU (and wise users that enable it if it's disabled), as with IOMMU the GPU itself can't snoop a damn since it has sandboxed DMA (direct memory access is allowed only to its own allocated space, not everywhere).

[StreamComputing]

Libre is about fully understanding what is going on, so protection can be increased. If it's just all open source, I'd label it "false libre".

So how's the protection against viruses like https://www.extremetech.com/computin...tem-activities ? Can any (invected) software read and write the firmware blob?

[Marc.2377]

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

Appreciate your answer. Do you think that a good C programmer and linux power user, however with no previous experience in kernel development, would be able to tackle on this, or is the idea too far-fetched? Although from reading what you said here I do believe this would be more sane than trying to improve the existing clover implementation.

True... but we implemented OpenCL 2.0 across the board back in early 2015 and none of the other vendors did anything... so pretty much all of the real world apps ended up being stuck at 1.2 level. Other vendors are finally starting to work on 2.0 support so I expect this will change eventually.

I'm just now really learning proper gpu programming, though in the past I've ported some OpenCL programs from Linux to Windows. In the book "Programming Massively Parallel Processors", which I'm reading now, the author says that the book is not based on OpenCL (but CUDA instead) because OpenCL was in its infancy when the book was written (my copy's from 2010-2011). I have a friend who is/was a CUDA programmer and he basically told me the same thing a few years ago. In my opinion Shared Virtual Memory was a major step forward, and now clCloneKernel and specially C++ support in OpenCL kernels (albeit not strictly complete) are even more compelling. I just hope you guys at AMD do not "regret" by any means from leading innovation, let alone refrain from continuing to do so.

[pal666]

And indeed it is software

it is not software for your cpu. it is software for some remote cpu like phoronix forum software

[bridgman]

Right. The hope was that the industry would follow the pioneer and not that the pioneer would step back to be aligned with the rest. Let's hope that will change.

Yeah, sometimes it actually works out that way

That said, we didn't actually "step back" as much as "started from zero with a new low-level driver framework and haven't stepped all the way forward yet" since nobody seemed to be using the last few features.

[ekondis]

True... but we implemented OpenCL 2.0 across the board back in early 2015 and none of the other vendors did anything... so pretty much all of the real world apps ended up being stuck at 1.2 level. Other vendors are finally starting to work on 2.0 support so I expect this will change eventually.

Right. The hope was that the industry would follow the pioneer and not that the pioneer would step back to be aligned with the rest.

Let's hope that will change.

[bridgman]

It's a two way relationship. For instance, people wouldn't make/plan to use of C++ if all available compilers supported just C.

True... but we implemented OpenCL 2.0 across the board back in early 2015 and none of the other vendors did anything... so pretty much all of the real world apps ended up being stuck at 1.2 level. Other vendors are finally starting to work on 2.0 support so I expect this will change eventually.

[illwieckz]

I knew you are total disrespectful, first response to me and like that... fuck you moron and your fucking shitty matrix

Everyone but you have read the very-dedicated 1000 words comment I wrote for you.

As stated, I didn't have to answer to your statements since others did. You polluted a thread up to 7 page to request me something others already did for you (it's a kind of harassment), and when I gave time to answer you, you just don't read the answer you asked for but said “I knew you are […]”, throwing insults in a row.

It's time for you to to look stupid and to apologize.

[ekondis]

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.

It's a two way relationship. For instance, people wouldn't make/plan to use of C++ if all available compilers supported just C.

Btw, OpenCL 2.2 was finalized today.