Intel Arc GPU hacked to work on a 64-core Arm Ampere system running Linux

Doom 3: BFG running on Intel Arc A750, Ampere Altra, and Linux
(Image credit: Vladimir Smirnov)

Vladimir Smirnov, a Google Switzerland Site Reliability Engineer, recently published an update saying that he was able to make the Arc A750 GPU work on his new Arm build that runs Linux, which certainly isn't a certified solution. Smirnov is building an ARM server running an Ampera Altra Arm chip. He bought the motherboard and processor together on Newegg and tested the system with various GPUs—an RX 550, RX 5700, and Intel Arc A750—while waiting for the rest of the parts of his build to arrive. Smirnov is sharing the details of his build on Medium.

The RX 550 worked on the system with no issues, and despite its age, the AMD GPU worked straight out of the box without further programming. On the other hand, the RX 5700 refuses to work with an Ampera Altra chip and a Linux OS. Nevertheless, several Linux Distros have already issued patches for the problem, so all he needed to do was follow instructions.

Unfortunately, the Intel Arc A750 GPU didn't work at all because of the ARM processor. While Intel GPUs historically work with the Linux operating system, Smirnov’s GPU refused to open without troubleshooting. The primary reason for this is that Intel’s GPU technology is closely aligned to x86-64 CPUs, where Intel Graphics has been used since 2010.

“The reason is that the Intel i915 kernel driver doesn’t work on non-x86 [processors],” Smirnov wrote. “They’ve started to upstream a new Xe kernel driver, which seems more focused on their recent GPUs.” This development is a boon for the Google Engineer, as his server build runs on an ARM processor, which he chose for its power efficiency and good I/O capabilities.

Nevertheless, it still wasn’t a straightforward fix, as his system ran into an error. His first fix was to comment out the VGA Console compatibility function, as it doesn’t work on recent ARM chips. After that, his system started outputting an image via HDMI on his ARM system.

comment code

(Image credit: Vladimir Smirnov)

However, the GPU still could not produce 3D output because it didn’t have the latest version of Mesa3D, the open-source version of many graphics APIs. He has since upgraded this, but he ran into another snag: the driver for Intel Xe graphics will only work with x86 and x86-64 systems.

Smirnov attempted to build a driver that worked with the Intel Arc GPU, but he ran into several errors that stopped the GPU from running. He eventually checked the kernel repository for drm/Xe and found patches that improved the stability of his driver. It still failed to work, as after he reapplied the PCIe patch for the RX5700 and tried again, the driver still hung.

Since he was experimenting with a GPU driver, he tried again, and this time, he got the Intel Arc to work on the Ampera Altra ARM processor. Although the system probably won’t run Starfield at 4K@120, it could at least run Doom 3: BFG Edition.

Doom 3: BFG running on Intel Arc A750, Ampere Altra ARM CPU, and Linux OS

(Image credit: Vladimir Smirnov)

Intel Arc GPU compatibility with non-x86/x86-64 systems is a significant development for graphics cards, especially as Qualcomm is poised to launch the Snapdragon X Series ARM chips that can go head-to-head with Intel’s and AMD’s most recent chips. While most consumers and users will not appreciate Smirnov’s efforts, it shows how ingenuity and a little effort can result in great open-source projects that others can iterate on.

Free and open-source software (FOSS) runs most of the backend systems we rely on — web servers, cloud computing, and even AI. FOSS is so crucial to our global digital economy that it has even become a target for backdoors and other malicious programs. Nevertheless, the contributions of people like Vladimir Smirnov drive software innovation and move our computer-based society forward.

Jowi Morales
Contributing Writer

Jowi Morales is a tech enthusiast with years of experience working in the industry. He’s been writing with several tech publications since 2021, where he’s been interested in tech hardware and consumer electronics.

  • CmdrShepard
    Another clickbait title.

    No, the GPU was not "hacked", do you even know what hacked means?
    Reply
  • evdjj3j
    Sounds like a typical Linux experience. Seems like there is always something that just doesn't want to work and requires combining the information from 3-4 different forum posts to get it working.
    Reply
  • 35below0
    CmdrShepard said:
    No, the GPU was not "hacked"
    It was exactly hacked. The method used to make it work is a hack.

    If you're refering to hacking security, no it was not that. But programming wise, it was hacked.
    Reply
  • HaninTH
    "Hacked" in this sense, probably should not be used as the "mainstream" usage in PC verbiage has it mean something else.

    I think the author means that they "hacked" together lots of code to get this to work were most would want to see custom/original code being used and/or modification of the hardware to circumvent or allow access to restricted resources on the board to be awarded the classification of "hacked".

    But, eh.... what do I know?
    Reply
  • bit_user
    CmdrShepard said:
    No, the GPU was not "hacked",
    Agreed. I also took exception to use of the word "hacked", in this context.

    35below0 said:
    It was exactly hacked. The method used to make it work is a hack.
    Well, the kernel's GPU driver framework is specifically designed to make graphics drivers portable across different platforms, including different ISAs. The fact that all he had to do was disable the VGA console stands as testament to this fact!

    Where things might've gotten a bit hacky is in his workarounds of the various issues he encountered in Mesa. In this case, perhaps you could say his solutions to some of those problems were a bit rough or ad hoc, rather than undertaking all the work needed to port it in a clean and elegant way like you'd do if you actually intended to upstream your fixes. However, like the Kernel's driver framework, Mesa is also designed to be cross-platform. So, any issues he hit should've been places in the Xe code that were somewhat needlessly x86-specific.

    The article said:
    While most consumers and users will not appreciate Smirnov’s efforts, it shows how ingenuity and a little effort can result in great open-source projects that others can iterate on.
    Not sure about the "ingenuity" part, but perhaps what he accomplished was to estimate the scope of work needed for a clean ARM port. As mentioned in the article, some AMD GPUs already work on ARM (and other ISAs).

    Nvidia's proprietary driver also supports ARM, but that only tells us about the kernel framework, because their userspace is not Mesa-based.
    Reply
  • bit_user
    evdjj3j said:
    Sounds like a typical Linux experience.
    No way. This is trying to make a GPU driver work on a completely new platform with a CPU ISA that it never previously supported! It's absolutely unlike anything you'd experience in the normal day-to-day.
    Reply
  • mitch074
    evdjj3j said:
    Sounds like a typical Linux experience. Seems like there is always something that just doesn't want to work and requires combining the information from 3-4 different forum posts to get it working.
    Yes, it's typical on Linux systems...
    Case : something doesn't work.step 1 : make it work.
    step 2 : test it.
    step 3 : make it work right-ish.
    step 4 : write patch.
    step 5 : test patch.
    step 6 : submit patch upstream
    step 7 : get upstream release for software.Result : something works.

    While on Windows :
    Case : something doesn't work.step 1 : look for someone who has solved the problem.
    step 2 : ask the vendor.
    step 3 : wait.
    step 4 : get no answer. Give up.Result : something still doesn't work.
    Reply
  • 35below0
    bit_user said:
    Well, the kernel's GPU driver framework is specifically designed to make graphics drivers portable across different platforms, including different ISAs. The fact that all he had to do was disable the VGA console stands as testament to this fact!

    Where things might've gotten a bit hacky is in his workarounds of the various issues he encountered in Mesa. In this case, perhaps you could say his solutions to some of those problems were a bit hacky, rather than undertaking all the work needed to port it in a clean and elegant way. However, like the Kernel's driver framework, Mesa is also designed to be cross-platform. So, any issues he hit should've been places in the Xe code that were somewhat needlessly x86-specific.
    Yeah, i was refering to the "hacks" made to get to a working solution.
    I get why you'd say it's not, because of cross platform compatibility. It's not fair to call every workaround or wrap a "hack". I was responding to a different comment about the word hacking.

    In it's state and how it got there, i'd say it's a hack. Though it could probably be more polished and tested. Ultimately, good solutions can arise from hacks.
    I don't see "hack" as a pejorative. Not that what i call it is decisive.
    bit_user said:
    Not sure about the "ingenuity" part, but perhaps what he accomplished was to estimate the scope of work needed for a clean ARM port. As mentioned in the article, some AMD GPUs already work on ARM (and other ISAs).
    Somehow that ended up as my quote, but i never posted it. Glitch?
    bit_user said:
    No way. This is trying to make a GPU driver work on a completely new platform with a CPU ISA that it never previously supported! It's absolutely unlike anything you'd experience in the normal day-to-day.
    I will hate on Linux any day of the week and twice on sundays, but THAT is still a ridiculous complaint to make.
    Agree that this has nothing to do with typical Linux experience.
    Reply
  • mitch074
    35below0 said:
    Yeah, i was refering to the "hacks" made to get to a working solution.
    I get why you'd say it's not, because of cross platform compatibility. It's not fair to call every workaround or wrap a "hack". I was responding to a different comment about the word hacking.
    The problem is that, for decades now, people have substituted "hacking" for "cracking"; etymologically, "hacking" in this article is proper - the author hacked on several pieces of code to make them work.
    The way it's used in the article's title though, instead of him hacking on the GPU's driver, may lead one to think he "physically" cracked the GPU instead.

    Which is wrong.
    35below0 said:
    In it's state and how it got there, i'd say it's a hack. Though it could probably be more polished and tested. Ultimately, good solutions can arise from hacks.
    I don't see "hack" as a pejorative. Not that what i call it is decisive.
    It is a hack, as the same driver code now has reduced functionality ; a proper fix would be to try and detect the presence of the VGA component before trying to initialize it, a "better" hack would be to limit loading the VGA component if built for x86/x86-64 (as it's not exactly used on other current platforms, to my knowledge).
    35below0 said:
    Somehow that ended up as my quote, but i never posted it. Glitch?
    or a little problem when bit_user added quotes...
    35below0 said:
    I will hate on Linux any day of the week and twice on sundays, but THAT is still a ridiculous complaint to make.
    Agree that this has nothing to do with typical Linux experience.
    Define "typical"
    If by "typical" you mean "using the computer to browse the web, watch a movie etc." then yes, definitely.
    On Linux, when a piece of software doesn't work, you can at least dig into it to try and fix it; I'm no C programmer, but I did once or twice fix bugs by building dependencies manually and/or commenting out a few problematic lines.
    On Windows, fat chance.
    Reply
  • bit_user
    35below0 said:
    Yeah, i was refering to the "hacks" made to get to a working solution.
    I get why you'd say it's not, because of cross platform compatibility. It's not fair to call every workaround or wrap a "hack". I was responding to a different comment about the word hacking.

    In it's state and how it got there, i'd say it's a hack. Though it could probably be more polished and tested. Ultimately, good solutions can arise from hacks.
    I don't see "hack" as a pejorative. Not that what i call it is decisive.
    If the bulk of his Mesa fixes were of the quick-n-dirty variety, rather than clean fixes conforming to the standards needed to upstream the changes, then I think it would be fair to say his solution is a hack.

    35below0 said:
    Somehow that ended up as my quote, but i never posted it. Glitch?
    Copy/paste mistake. I edit my posts in markup mode. I copied the
    tag from your post, rather than using a bare one. Fixed.
    Reply