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.

Latest Videos FromTom's Hardware
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