Hacker News new | past | comments | ask | show | jobs | submit login

A good number of comments here mention dealing with the GPU is going to be a major hurdle. What makes porting GPU drivers significantly more challenging than everything else?



They're very complex, very stateful devices which also run their own compiled shader code. Not to mention auxiliary DSPs like video decoders (not sure if M1 has it as part of GPU or a separate block), power gating control and many many more.

They may have in order of 100 registers to talk to them and they're horribly proprietary with pretty much no standardisation.

Reverse engineering that is hellish at best - you can see projects like nouveau which barely manages to get nVidia cores up and working without help from the manufacturer. And that's after years and years of development.


The hurdle Noveau is facing is that some things, like reclocking, need firmware loaded onto the card. The firmware is not in non-volatile memory on the hardware, but a file shipped with drivers, the one shipped with proprietary drivers is not redistributable and if you wanted to make your own, it needs to be signed by Nvidia anyway.

That's pretty much game over for Noveau, and it is not due to difficulties in figuring out registers and NV ISA.


The reclocking never really worked well on chips that were older than this signing requirement either.

But that's a bit besides the point :)


Why would you make your FW blobs be non-redistributable? An FW blob has only the purpose of running your hardware for your customers.

I can understand preventing FW patching, maybe. But redistributing the manufacturer's genuine FW, why not?


> What makes porting GPU drivers significantly more challenging than everything else?

Multiple reasons:

1) GPU manufacturers are notorious for not publishing documentation out of IP/patent concerns. Worst offender is NVIDIA here.

2) For embedded GPUs there isn't much interest in open source drivers... the big customers (think Samsung and the likes) have direct support from the chip design vendor and get drop-in drivers as part of the board support package (BSP, basically a conglomerate of bootloader, kernel+modules+initrd, firmware blobs for components such as wifi) so they don't need OSS drivers

3) The mobile GPU space is... splintered. With desktops you got the three major players AMD/ATI, NVIDIA and Intel's built-in Iris, in the GPU space there are more.


> GPU manufacturers are notorious for not publishing documentation out of IP/patent concerns. Worst offender is NVIDIA here.

I think easily Apple takes the cake from nVidia - they don't even provide drivers for anything but their platforms (that is for their proprietary GPU core). The GPU core that's actually in the M1.


A lot of this comment I don't understand how it applies to the Apple M1. I'm not saying it doesn't. I'm completely ignorant of these things. Am I just missing it?


Apple's M1 chip has a custom GPU built into it. There is no documentation on how that GPU works and Apple hasn't released any.

Making any modern GPU work is a lot of work because of how complicated they are. That's even with the full documentation.

In the Apple M1 case, the GPU will have to be reverse engineered to understand how it works, then a driver will need to be written for Linux that supports it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: