As long as the drivers are portable wrt the platform specifics (endian-ness, memory model) then yes, it "should" work. However there's a lot more varied use cas

As long as the drivers are portable wrt the platform specifics (endian-ness, memory model) then yes, it "should" work. However there's a lot more varied use cases; for instance when you boot your PC straight into UEFI, the UEFI runtime environment doesn't have a full blown nvidia/amd/whatever driver you install like your OS, but it can still display graphics in this "pre-boot" environment through your HDMI cable. To do this, the UEFI runtime is configured (let's say magically) to run a little bit of x86 code that AMD/nvidia provides, very early on, which will essentially initialize the GPU for this specific mode of operation. Your PC just does this every time you boot into UEFI, no issue. But because this opaque blob is a piece of x86 code the UEFI runtime picks up, it wouldn't work out of the box on ARM64, but you can actually work around it. Some ARM64 platforms for example, actually compile QEMU as a UEFI application, and run that x86 pre-boot code under QEMU through emulation; the emulator translates memory accesses, the peeks/pokes, to ARM64 code and this allows you to initialize graphics normally. AMD/Nvidia could also provide ARM blobs too, of course. Naturally not every GPU has restrictions like this (Nvidia might be completely different?) and there may be alternate solutions, but it's just to give you a taste of the things PC users take for granted. The fundamentals should work but there are use cases beyond that.