Hacker News Reader

Comment by rijoja | Hacker News Reader

So it seems that what could be problematic is not getting it to boot but rather how to get proper graphics support. How difficult would it be to reverse engineer the GPU?

View on HN

Do we even know how to access the GPU? On x86-based systems there would be a standard bus (PCI/AGP/PCIe) to enumerate the the graphics device, but my impression is ARM doesn't have such things.

A lot of the recent improvement in graphics on Linux has come from manufacturers deciding to become cooperative rather than there being more people reverse-engineering graphics drivers. (Broadcom is contributing support for the Pi 4; AMD added its drivers to upstream; nVidia releases binary drivers to support enterprise customers.)

ARM does, in fact, use standard buses, PCIe on most high/medium end parts -- although, some low end chips just use a built-in USB controller or SPI/I2C for all peripherals.

What isn't always available is a way to dynamically enumerate a device's, uh, device tree. On PCs, this is usually accomplished through ACPI tables, where the bootloader (BIOS or UEFI) populates a table of data and callbacks to AML bytecode functions which the OS kernel can read and eval. [0]

So on x86, the OS finds the PCIe memory mapped addressed in the MCFG table.

On most ARM devices, this data has to be passed to the kernel at runtime, in what Linux calls a "device tree reference", compiled to a "DTB" file.

So, on a UEFI-based ARM system, it should be possible to just insert, say, an AMD graphics card onto the PCIe bus and get a working GPU.

[0] https://www.kernel.org/doc/html/latest/arm64/acpi_object_usa...

PCI and USB bus standards include dynamic enumeration but ARM SOCs normally only use them as external interfaces.

IP blocks inside the SOC itself usually just expose their registers on an AXI bus with no enumeration support at all, this is most likely the case with the M1 gpu.

If the reverse engineered Nvidia GPU drivers are any indication, very difficult

They're functional for very basic desktop stuff but 3D performance is abysmal

Not what you'd expect from a macbook. Perhaps it's in Apple's interest to let it happen though!

I wish it were so. Apple has no reason to allow other operating systems on its devices because macOS and iOS are gateways to their massive array of paid services.

A big reason for the abysmal performance is however that nvidia has intentionally locked down the performance for code that doesn't have the right credentials. We don't know if Apple have done something similar.

I assume you mean reclocking support, it is possible to reclock the older Kepler architecture on open source drivers but it still underperforms

Kepler is anywhere from 2x to 10x faster on the proprietary driver here: https://www.phoronix.com/scan.php?page=article&item=nvidia-n...

Apply to https://jobs.apple.com/en-us/details/200174315/apple-silicon... and find out ;)

And WiFi, audio, ... Basically what's problematic is proper (or any) hardware support.

One potential solution is to run a virtualized Linux in macOS.

It's still a PoverVR GPU with serial numbers filed off.

Apple has been designing their own GPUs for a while.

It's a Ship of Theseus situation.

Reply on news.ycombinator.com