Intel Clarifies HECI Usage For Arc Graphics' GSC

[pong]

That's absolutely an atrocious limitation / design decision.

If they designed it so you can't update the firmware other than via the SMBUS-like pins over the PCIE slot but could not do so over the PCIE lane traffic I find it very odd and likely problematic if they didn't know that (a) all platforms having PCIE slots had such SMBUS signals implemented and (b) all platforms had a suitable way to send update data to the peripheral card via that mechanism that would be equally well supported by the Intel tooling / drivers / updaters etc. Otherwise why wouldn't they just make it so the updates were sent to PCIE attached peripheral registers and have a much more simple / unified / portable implementation?

If they do intend to support all platforms but for the moment only the Intel chipset motherboards are supported by the OSS utility then the least they could do is fully document the necessary SMBUS or whatever exchange protocol and FW update data flow needed to send the FW image blobs through whatever the motherboard's plumbing may be to get it to the SMBUS pins on the right PCIE slot and be accepted by the GPU if someone else wanted to make an open source FW updater for other kinds of motherboards / platforms besides the one the intel utility presently works with -- that and commit publish the FW blobs in multi-platform usable formats so they could be handled by whatever other motherboard / platform specific update utilities might come to exist.

I ASSUME the UI tools like their control panel overlay and stuff may work on multiple platforms e.g. AMD and Intel CPU motherboards / chipsets and that reads and to some extent sets power / fan / temperature etc. stuff so I assume some of that may be at the level of talking to the GSC if so how does that manage to work
equally on AMD / Intel if not only using PCIE lane connectivity?

If this isn't just a very temporary short term delayed oversight in providing the compatible equitable utilities / protocols or resources for providing e.g. AMD chipset CPU / Motherboard platforms FW update capability but is really some baseless vendor lock in anti-consumer anti-trust BS that they should've known better than to insult their customers with their unwarranted and unreasonable lock in tactics then that's it, I'm done with Intel ANYTHING forever.

Ironically I actually bought an ARC so I could dip my toe in Intel OneAPI / GPU SW etc. development but not to be treated like an irrelevant / unsupported user just because I have some AMD based motherboard / CPU to go along with the Intel GPU I bought for the very reason of OPEN SOURCE / LINUX cross platform support.

I can easily just return the ARC still new in its box and buy an RX 7900XTX and Zen 4 instead and leave "Intel Outside"(C).

[willmore]

Slow down everyone! This may not be Intel being malicious and trying to push their own processors/MBs with ME. It could just be that the person who designed the firmware update was familiar with ME and how to do firmware updates through that and never considered that not everything has ME. So, not malice, just basic incompetence.

[milkylainen]

It's like they have a badwill account and are itching to overfill it.

[stormcrow]

gsc-windows.png

GSC firmware interface is available on Windows on my AMD server. But I don't know if it works.

I try not to jump to conclusions if I can manage it. My guess is that ME is just needed for certain firmware signing verification and the same functionality exists in AMD's equivilent PSP. Whoever wrote the Linux program may have overlooked this vector much like AMD often overlooks testing on Linux & BSD systems in general. Myopic corporate focus on market shares can have knock-on effects like this.

Now, that said it does mean that systems that try to kill most ME functionality may not be able to update ARC graphics card firmwares, so System 76 computers, for example, will be out.

Edit to add: It's almost a guarantee that if these cards don't actually require that kind of thing to update their firmware (ME or an equivalent security processor) then it won't be all that long before hackers figure it out and are able to compromise these cards with malicious firmware.

[nyanmisaka]

gsc-windows.png

GSC firmware interface is available on Windows on my AMD server. But I don't know if it works.

[archkde]

Apart from the lock-in aspect (which is obviously not good), I find it surprising there is updatable firmware at all. AFAIK, other GPUs (including Intel iGPUs) have their firmware loaded at runtime.

[r1348]

Dear Intel,

vendor lock-in tactics should be applied after market penetration.

Regards,
A Lost Potential Customer

[r_a_trip]

This is seriously myopic of Intel to curtail AMD hardware owner's interest in their GPU's. That's a significant portion of the bloody market! Does Intel not like money?

Maybe they like money too much, but they haven't thought through any possible consequences of their actions. "Now they have to get more Intel gear!" The alternative of eschewing their graphics cards hasn't dawned yet.

[r_a_trip]

Amazing, Intel is making Nvidia look good. Limiting important functions of your hardware to solely your own platform is extremely shortsighted. Who in their right mind is going to consider Arc when their systems aren't Intel based? Even when you have an Intel system, the prospect of lock in isn't a selling point.

Looks like it will be AMD for the foreseeable future.

[JPFSanders]

So, performance is not great, drivers are not great, no big differentiator from competition (IE: domestic support for SRV-IO) and now to sweeten the deal you can't upgrade the firmware unless you do it from an Intel system.

Who is in charge of the graphics unit making the decisions at intel? This is all pretty stupid getting into the full-retard territory quickly. I will never buy any of those cards now.