AMDKFD Looking To Be Merged Into AMDGPU Linux DRM Kernel Driver

[Marc.2377]

(...)

2. You're thinking "but one important part of HSA was eliminating the need to move data back and forth" and you're right, but the combination of having to learn a new environment of any kind AND learn a new style of programming was a fairly high bar for most application developers. They were OK with a new environment OR a new style of programming but not both at the same time, particularly if the resulting software would only run on APUs. Our major customers were and still are very interested in GPU compute on APUs but they had already invested in OpenCL and weren't in any rush to change.

YES - this, very much, indeed.

(...)
When you put all those together it became pretty clear that we needed to get dGPU support (including large multi-GPU configurations) and dGPU-style programming models supported, and supported well, before we could expect much success moving developers to the APU-style programming models.
(...)

Amen a thousand times.

Congratulations to your team for the change of focus.

[Marc.2377]

(...)

BTW we could potentially use IOMMUv2 for system memory accesses rather than having to pin that memory, but AFAIK Intel CPUs do not expose IOMMUv2 (aka ATS/PRI services) to the PCIE connector, so our first implementation had to rely on memory pinning in order to work on both Intel and AMD CPUs.

Still IOMMUv2 is a requirement for HSA because of PCIe atomic operations, correct? I was once considering whether this could be "compensated" for in drivers, but former AMD employee and IOMMU contributor Joerg Roedel told me that wasn't an option.

[bridgman]

But i am sure there is a lot of interest to write special software for a Open-Source GPU with open-source firmware

very few? I think people who are interested in "fully auditable hardware" have basically given up discussing this with AMD and they are now buying IBM Power9 hardware for the CPU side. This means instead of talking with you they just cross the border in a vote with your feet style move.

Hey... focus !!

You asked about GPUs; I answered about GPUs.

There is more interest on the CPU side, although none of that seems to have made it to large/corporate customers or OEMs yet..

[bridgman]

Still IOMMUv2 is a requirement for HSA because of PCIe atomic operations, correct? I was once considering whether this could be "compensated" for in drivers, but former AMD employee and IOMMU contributor Joerg Roedel told me that wasn't an option.

That's a tricky question to answer. IIRC on Kaveri (and maybe Carrizo) the same HW block implemented platform atomics and the address translation cache (ATC) used for accessing memory through IOMMUv2, so the two had to be used together.

On dGPUs we limit use of atomics to the optional PCIE atomic operations (HSA platform atomics support ~8 operations while PCIE atomics only support 3) and IOMMUv2 is not required. We had hoped to be able to standardize on IOMMUv2 for system memory accesses but AFAIK Intel ended up only exposing their IOMMUv2 functionality to the integrated GPU and not to the PCIE connectors.

[bridgman]

I think there is not more interest on the CPU side it is just the simple fact that on the CPU side the people start voting with their feet. in my point of view there is equal interest on the GPU side but right now people can not vote with their feet.

Not sure I agree - GPU "interest" is artificially inflated by the fact that CPUs have a built-in copy of microcode that you can run with if you don't care about security and correctness updates while GPUs won't run at all.

Libre distro users feel a lot more immediate pain on the GPU side, but while in theory the issue is about open source microcode in practice the decisions they make turn into "built in binary microcode" vs "binary microcode from a file" which I think you would agree is a different thing.

The decisions are defended by saying "oh it's all about whether you can change it or not" but if that were the case then locking down the microcode versions and confirming that with hashes would be sufficient to make microcode from a file equivalent to microcode from a ROM or flash

[bridgman]

Agree with everything you said. The only fly in the ointment is that today large data center customers sometimes are able to audit the hardware (I expect that includes microcode) since they have strong incentives (both reputation and financial) to protect whatever secrets they are exposed to, while there is no similar mechanism for individuals today other than open sourcing.

The consequence of that is less pressure than you would expect from large data center customers for open sourcing or publicly available audit reports, since *they* already have the information they need. I don't have a good answer for that yet.

[bridgman]

so your point is: as long as the big corporatism monopole customers who have the resources to check the microcode internally are fine with AMD hardware the smaller non-monopole competitors and private persons does not matter to AMD?

No, my point is what I actually said. Please try not to be this guy:

http://dilbert.com/strip/2015-06-07

You said that you expected large datacenter customers would be pushing for fully auditable hardware and that their influence would help everyone else - I responded and said "not as much as you expect, and here's why". That's it.

this really sound like we really need a strong government(Donald Trump Re-Election) who do the dirty work of Cutting these big companies down into little pieces to make sure no one do have the size and resources to be that big to be able to check the microcode internally and amd/intel also should not be that big to force politics like this on the market.

Yeah, between "a few large datacenter companies" and "a few large OEMs" it is a highly concentrated market.

Remember that Intel is about 12x our size - if we were big enough to force politics on the market the way you are implying I think you would be happier with the state of the market.

[bridgman]

No, but misdirection and baiting are going to be futile whenever I am paying attention

[Kano]

Q and B can turn every thread into a discussion about binary only microcode ;-)