Add Intel Arc A750 #510
Comments
|
There's a good deal of coil whine on my card—when testing on the PC and it needs to render anything. At idle there isn't much, but when the fans stop spinning and the card is not displaying anything, or alternatively when the GPU is under heavy load, there's a lot of coil whine, enough to be pretty distracting. |
|
On Twitter someone mentioned this commit: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/i915/Kconfig?h=next-20230210 — it looks like the i915 has some hardcoded x86 dependencies: |
|
lspci output: And dmesg: |
|
To test out Intel's open source kernel driver, I cloned the 6.2.y branch of Raspberry Pi's linux fork: |
|
...except I can't select the Intel Graphics support using menuconfig, because of the dependencies: I asked about arm/arm64/aarch64 support on Intel Arc/Xe on Twitter and got a few responses, mostly suggesting X86 drivers are the current focus, but they may rewrite the driver and work on getting rid of the X86-specific dependencies... I also asked about it on Discord, but I noticed most of the active discussion (on Intel's official Arc/Xe community Discord) seems to center around where people can buy Nvidia graphics cards 🤣
The only other mention on Twitter is from @ric96, and he also seems to notice there's no support for arm64... |
|
Just FYI, the most likely reason x86 is listed as a dependency is that historically Intel only had iGPUs, and those can't exactly be plugged into an aarch64 system for obvious reasons. That being said, it seems quite likely that if those dependencies were removed (since they are for all we know completely bogus), chances are the driver would actually compile just fine. It seems quite unlikely that it uses assembly for anything, which is just about the only valid reason for it to not compile for aarch64 |
|
It looks like you could try again with Xe drivers in kernel 6.8: |
|
If you do decide to test this with 6.8, note that Ubuntu's Mesa doesn't have the Intel drivers enabled, and even if you check out the experimental branch of the mesa packaging from debian's "salsa" repo, it doesn't enable the Intel drivers for armhf or arm64/aarch64. You'll want to edit On my LX2160A, the kernel driver for my A770 loads once I add xe.force_probe=56a0. It complains about lack of resizable BAR, though. With a manually rebuilt Mesa, Weston works, but gdm3 and sddm both glitch out and freeze, and autologin doesn't give a working desktop either. If you can get the driver to work without glitching out, you'll also run into these chirping crickets: (I actually bought the A770 to use with arm64, but now it's just sitting unused.) |
|
Only slightly related but if anybody working for Intel is reading this, please note the new arm64 laptops all support USB4 / Thunderbolt and if Intel can release GPU drivers for these for arm64 Windows 11 and arm64 Linux then we would love that for eGPUs! Running a fast and efficient Snapdragon Elite X and then using eGPU for gaming or rendering would be amazing! |
|
@karatekid430 - Sadly, arm64 driver support on Windows for anything besides USB devices is pretty much nonexistent so far. I'm not sure if any graphics card (let alone NICs and other simpler devices) will support PCIe (especially through Thunderbolt/external enclosures) any time soon. Would love to be proven wrong on that! |
|
Some progress here with my Arc a750 xe drivers built, updated firmware. note: |
|
@martinx72 Excited to re-open this issue ;) |
|
Fedora 41 for aarch64 has xe kernel support out of the box. |
@pimzand Does this release support Pi 5? And some more progress here, at least no crash in the driver Page Size set as 4K, then it went to some error much easier for me to narrow down the crash issue, but, i think i probably have to stop here. As intel keep modifying their repo every single day here: https://gitlab.freedesktop.org/drm/xe/kernel IMO, never can chase their steps by myself. :( |
Not fully, apparently: https://discussion.fedoraproject.org/t/aarch64-support-for-raspberry-pi-5/134857 I tried an Arc 310 Eco in an Ampere Altra system while still Fedora 40. |
Just check the link in the post, https://rpmfusion.org/Howto/RaspberryPi Then it is 6.6,y, and it never can boot with xe drive at all. |
Intel doesn't have any ARM64 Windows drivers for any of their NICs I've checked. NVIDIA/Mellanox, on the other hand, does have in-the-box ARM64 Windows drivers for ConnectX-4 and newer. I've used a Mellanox ConnectX-4 Lx 10-/25-gigabit ethernet NIC with my Snapdragon X machine on Windows ARM64, via USB4 / Thunderbolt. It works, but oddly, one direction seems to give only 5 gigabits of throughput for some reason. As far as I can tell, there are no discrete GPU drivers for Windows ARM64. On ARM64 machines with UEFI, such as LX2160A, the closest you can get is loading AMD's GOP driver in UEFI to run the framebuffer with Microsoft Basic Graphics Adapter. |
|
@DanaGoyette From what I've heard, Nvidia may have working drivers for Windows arm64, as they've worked on support for enterprise use in Azure... at least that's what I infer from tweets like this. |
|
I see some fairly similar but different issues to what @martinx72 was seeing in their issue tracker, maybe worth reporting? |
|
Also, regarding Resizable BAR support: I open an issue in the Pi firmware repo: Enable Resizable BAR support on Pi 5. It can't hurt to ask ;) |
It outputs through the first available DRM card with connectors defined by default. Use You should get something like if it has found a connector to set up on that card. |
And apparently it's |
|
Sounds good. That means the basic DRM rendering of a plane works, and it's likely to be the 3D that is throwing a wobbler. You can always try Trying |
|
Trying |
|
Right now I am actually not sure anymore if I disabled the other GPU via Still building kernel and setting up the system 🤔 |
|
@geerlingguy looks like Iris is not built by default on the Raspberry Pi: $ dpkg-query -L libgl1-mesa-dri | grep iris Nor is the vulkan driver from looking at the mesa-vulkan-drivers package. So would require either rebuilding the mesa package to include it, or building locally in a directory just to test as well. |
I was about to say that iris_dri.so is unlikely to be built in the Raspberry Pi OS default Mesa. |
|
I finally found it, all my steps were okay, but I missed that I disabled the GPU from the Pi itself. I disabled it to have less noise while debugging all the XE issues. Inside the file With that disabled, I get the output via HDMI again. Here my full list of steps: Please not that I have not changed other firmware binaries, except the one the xe driver was checking and nagging about. My hardware setup:
Probably there is some configuration needed for lightDM to NOT pick up the builtin graphics card. EDIT: I am glad I could reproduce it 🐱 I was worried to have lost the missing bit EDIT 2: this works for my A380, haven't tested it with my A770 ;) because its "in use" right now, will check that card in a few days EDIT 3: disabling the builtin GPU means that there are not multiple /dev/dri/card* entries, but only one /dev/dri/card0, which makes all the tools "defauling" to the Intel card |
|
Indeed! Commenting Testing again with a reboot straight into the desktop environment, though, at least with a full Pi OS install using lightdm, gets a blank screen on the monitor and no warnings in dmesg. If I boot back into console, console is fine. Not sure what might be different with Any good guide for a quick Mesa compile? |
|
Thanks to the retropie subreddit and this forum post by @6by9 (you are everywhere!), Mesa compile steps:
Reboot, and check the mesa version with either |
|
Running |
New video incoming in 3, 2,... :) |
|
I could run |
|
With the latest Mesa, I do get output, but it is... quite interesting, and reminds me of how the radeon GPU driver was behaving early on when we were testing on the CM4. Lots of random lines here and there, then it seems like the rendering gets lazy, and things drop in and out, like memory is just not refreshing in certain areas until something nudges it along.
Here's vulkaninfo output after installing Mesa 24.3.2: And glinfo:
|
|
@FibreFoX - do you get any glitchy output with your setup? Or is it stable? And if you try running any GL stuff, does it use llvmpipe or the Intel GPU? |
|
@geerlingguy Will have to check tomorrow ;) it's late here in germany already. EDIT: But I've checked to run Firefox and opened Youtube, but it looked like software rendering. Not checked anything else so far. |
|
YouTube under Chromium on here: intel-arc-a750-fine.mp4Working great! (haha) |
|
I just installed "normal" packages, to check how they are performing. Chromium defaults to software rendering, had to enable "Override softwar rendering list" in the GLMark2 was slow too, using llvmpipe: Changing to any wayland tool just did not work out of the box :) but that was expected, so nothing new, just confirming. After some time my system just got unresponsive (it was VERY SLOW via SSH terminal, like half a minute per keystroke, even the power LED on the pi was not on anymore ... could be some other issue). Regarding the error I looked at the source code and maybe these asserts can be skipped by setting NDEBUG via some meson argument (haven't checked it yet, but found some hints): That is documented in the options: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/docs/meson.rst I will try to find some more time to debug this more :) EDIT: while the system is unreponsive, this was these were the processes, weird defunct entries |
|
Most Wayland compositors using wlroots (eg Wayfire and labwc) will abort if they find software rendering. You really need to get Mesa built for Iris. Jeff has posted the runes at #510 (comment) |
|
@6by9 Will try to compile mesa now :) just wanted to check how the state is with "default packages". That part of linux is new to me, normally I am just handling headless linux servers ;) but always fascinating EDIT: after compilation ... as Jeff already described, kinda unusable, glitches all over the place, but it launches with wayland at least ... just not pretty I will try to debug the xe driver a bit more, maybe I can find the root cause, maybe my other workaround is responsible for this |
|
I think I now understand the difference between "Full Desktop OS" and "Lite OS". I've checked the
It is easily possible to switch to X11 via raspi-config ( The configuration for the image seems to be set here: https://github.com/RPi-Distro/pi-gen/blob/e071d0de36561a13039bf4d561f5204a7ecd8e34/stage4/06-enable-wayland/00-run.sh#L4 |
|
Late to the party, is using Ubuntu somehow different to using Raspbian with these cards? Would love to get one that works with Box86/64 to try more games than CS 1.6 that you can play with integrated GPU on RPi5. |
|
@martincerven Haven't checked Ubuntu yet, but I somehow doubt that it'll help. They are using an older kernel (6.8 so far for LTS and 6.11 for their newer Ubuntu 24) according to https://ubuntu.com/kernel/lifecycle They might have a newer MESA version, but I tried using EDIT: and looking at the changelogs, they are quite some time behind https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/noble/log/drivers/gpu/drm/xe or https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/noble/log/drivers/gpu/drm/xe?h=master-next Right now there are many parts that need to be fixed before the XE driver is Raspberry Pi ready (like the 4K page size alignment on the Pi 5), let alone gaming. But hopefully just a matter of time (depends on Intel engineers getting time to work on this edge case userbase). |
|
Just want to add this detail: my A380 and A770 behave the same, no difference (and still they both work with the found workarounds to get to the console). |
|
I should have a B580 in my hands tomorrow — I will retry everything with it once it is here... but that progress I may document in #695 |
|
I just tested the B580 and got a wedged message: See the full messages over in the B580 issue #695 - #695 (comment) |
@FibreFoX , when you say "stays black" do you mean a steady black screen with sync, or black because there is no signal, turning the monitor to sleep? I am experiencing the latter, with a B580 in an Ampere Altra system, using vanilla kernel 6.13 with your patches, |
|
@pimzand If I recall correctly, I had to patch |
|
Thanks @FibreFoX . I have patched all three, and tried both X11 and Wayland. No crashes or errors with either, but no display either. I tried both HDMI and Displayport. I do see a short flash on the monitor every time I When I enable drm debugging, I get so many (continuous) output from dmesg, that I do not know where to look for. Nothing with "error" in it, though. I have not applied the Ampere Altra specific patches, that work around the PCIE alignment errata in this CPU. These patches do not apply yet, because of this issue. Perhaps I should wait for this to be fixed. |
I am testing an Intel Arc A750 8GB graphics card:
It requires external PCIe power, so needs to be used with a suitable power supply. Intel seems to only officially support Ubuntu 22.04, and by default only AMD64/x86_64... Here's the full Ubuntu installation guide for Arc drivers.
Not sure if I can get it to work at all on Debian, and I also haven't confirmed if aarch64/ARM64 support is at all existing, planned, or not planned. Would like to find out, because I'll soon have another ARM64 system to test this in with a bit more firepower.
See also: Intel Arc Graphics A750/A770 Performance Ahead Of Linux 6.2 + Mesa 23.0 — it may be possible if the Pi OS kernel is up to 6.2 (it was 6.1 last time I checked) to compile the driver and see what happens.
Current Status and setup instructions
Last updated: Jan 21, 2025
It looks like at least some of the Arc cards are functional if you compile the 6.12 kernel (the next LTS release, which is coming to the Pi soon), and apply one or two small changes.
Current steps to get this card working with Pi OS Bookworm
6.12.ykernel tree with my GPU-enablement patch (or just check out my branch directly).make menuconfigand select the options:1. Kernel Features > Page Size > 4 KB (for Box86 and general driver compatibility)
2. Device Drivers > Graphics support > Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) > Intel Xe Graphics
3. Device Drivers > Graphics support > Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) > Intel Xe Graphics > Force probe xe for selected Intel hardware IDs >
*(enter*manually for the value)/boot/firmware/config.txt:1. Comment out the
dtoverlay=vc4-kms-v3dline2. (Optional) Add the line
dtparam=pciex1_gen=3to the endInstall Firmware
Check if working
Confirm everything is working by plugging a monitor into the graphics card; then confirm the card's GPU is in use by running
glxinfo -B(part of themesa-utilspackage), for example:(Prepend
DISPLAY=:0if running commands over SSH.)Debugging / Troubleshooting
dmesg, adddrm.debug=0xeto/boot/firmware/cmdline.txtFor the source and more details of the patch in progress, see:
The text was updated successfully, but these errors were encountered: