AMD's Radeon RX Announcement For E3 2016

[andrei_me]

Michael bridgman what is the future of opencl on radeonsi?
What is the relation of it and ROC or other Open GPU efforts?

[bridgman]

The clover implemention in radeonsi is moving pretty slowly right now - main focus has been getting the HSA/ROC stack solid.

We were looking at porting clover to run on top of ROC but had the opportunity to open source our proprietary OpenCL stack instead (after porting it to ROC) so that approach is our current thinking.

[chithanh]

imbecile

i think you are idiot

Classy.

it is still modifiable even in rom, it is just harder to modify

... which makes no sense, because you could replace the PROM with one that has different contents and you have just updated your firmware in exactly the same way as a microcode flash or filesystem update...

Mind you you a good portion of all hardware is generated from software these days. So why doesn't the FSF demand the code to whatever high level language was used to design the chip?

Yes, and you can change the hardwired circuits in a computer chip also if you want given the tools and enough patience. You have to draw the line somewhere, and the FSF draws the line between hardware and software. Software being the reprogrammable part, and hardware being the part that is not.

Which makes no sense at all because code burned into PROM can have bugs also.

What do bugs have to do with anything?

... and in the end this is the ONLY reason for the current belief set regarding HW microcode, with no logical justification whatsoever.

That the FSF will not be complicit in distributing proprietary software is neither surprising nor illogical to me.

Purely a matter of convenience, like people criticizing fur but not leather because old ladies are easier to harass than bikers.


An arbitrary decision was made to hack binaries out of packaged distros, and any hardware which still works after that is arbitrarily defined as "good"... leaving us in the situation where microcode stored in a file is bad but EXACTLY THE SAME MICROCODE stored in flash is acceptable.

Stallman and the FSF have done many good things but IMO this is not one of them.

I really have trouble understanding why the HW microcode which runs the GDDR5 link training state machine in the memory controller ABSOLUTELY HAS TO BE OPEN but the rest of the memory controller does not.

I really think the FSF position is asinine.

Does that make sense to anybody?

It doesn't make sense to you because you don't understand that the FSF has an ethical position against proprietary software (as a tool for subjugation of users). They freely admit that the ethical choice is often the less convenient or less practical one.
But you keep on looking for practical reasons and find none, then conclude that the FSF position is asinine.

[bridgman]

I'm not saying it's asinine, just that it has what appear to be unintended consequences and on balance might actually make things worse rather than improving them.

[pal666]

In general GPL takes away more freedom then it grants which is why I see a lot of people involved in free software moving away from GPL.

you just didn't get that gpl grants freedom not to you(to steal), but to software

[Veerappan]

The clover implemention in radeonsi is moving pretty slowly right now - main focus has been getting the HSA/ROC stack solid.

We were looking at porting clover to run on top of ROC but had the opportunity to open source our proprietary OpenCL stack instead (after porting it to ROC) so that approach is our current thinking.

Yeah, It's mostly a question of manpower. I used to spend time working on the libclc library implementation, but parenthood got in the way of most of my free time. Jan Vesely and Tom Stellard obviously do a bit, but in general, there's no dedicated focus on what kind of goal everyone is trying to achieve, and therefore no real drive to get specific things done.

At least in my case, and probably Jan's, we don't have access to the CL CTS either, so we end up either having to find CL suites that have their own internal tests, or we have to write our own piglit tests before we can attempt to validate the implementation ourselves.

We are within spitting distance of the cppamp driver (from multicoreware) being able to run on Clover, but I haven't been able to find time to finish off the half dozen or so math builtins that need doing. i'm sure there's other similar programs out there that are almost able to work, but missing one or two key built-in functions that we just haven't gotten around to yet.

And at this point, if AMD opens up their full CL driver for me to build/debug, I'm ok with that.... I'll mourn the time I wasted on some software that no longer matters, but I'll get over it (and maybe spend some time going over the AMD code and trying to find some vectorization/optimization opportunities.

[jstefanop]

The clover implemention in radeonsi is moving pretty slowly right now - main focus has been getting the HSA/ROC stack solid.

We were looking at porting clover to run on top of ROC but had the opportunity to open source our proprietary OpenCL stack instead (after porting it to ROC) so that approach is our current thinking.

Will the ROC stack ever support 300/400 based cards?