You installed Fedora and the GPU is silent
You just finished installing Fedora on a machine with an AMD Radeon GPU. The desktop loads, the cursor moves, and the system feels responsive. You open a game or a 3D application and the frame rate drops to single digits. Or you run a quick check and see llvmpipe in the output. The system is falling back to software rendering because the kernel module didn't load or the Mesa stack isn't picking up the hardware correctly. This happens when the initramfs is stale, the secure boot keys are missing, or a conflicting parameter is blocking the driver.
The kernel module and the Mesa stack
Fedora includes the amdgpu kernel module and the Mesa graphics stack in the default installation. You do not need to download proprietary drivers from AMD's website. The open-source stack is the official, supported path for all modern AMD GPUs. The kernel module handles hardware initialization and memory management. Mesa provides the user-space libraries that translate OpenGL, Vulkan, and OpenCL calls into commands the GPU can execute.
Think of the setup like a bridge and a translator. The amdgpu kernel module is the bridge that connects the operating system to the silicon. It manages power states, memory allocation, and interrupt handling. Mesa is the translator. It takes the high-level instructions from applications and converts them into the specific microcode the GPU understands. When both parts work, the GPU accelerates rendering. When the bridge is down, traffic diverts to the CPU via llvmpipe. That fallback works for the desktop but kills performance for anything 3D.
The failure usually stems from a missing module in the initramfs, a Secure Boot configuration that rejects unsigned modules, or a kernel parameter that forces the wrong driver. Fedora updates Mesa frequently to support new GPU features and fix performance regressions. Run dnf upgrade --refresh as your weekly maintenance routine. This keeps the kernel and Mesa in sync with the latest bug fixes.
Reboot before you debug. Half the time the symptom is gone.
Verify the driver state
Check whether the system is using hardware acceleration or software rendering. The glxinfo tool queries the graphics stack and reports the active renderer. If the output mentions llvmpipe or swrast, the GPU is not accelerating rendering. If you see AMD Radeon or AMD Graphics, the driver is active.
Here's how to verify whether the system is using hardware acceleration or software rendering.
# Check the OpenGL renderer string to identify the active driver
glxinfo | grep "OpenGL renderer"
# WHY: glxinfo queries the GLX extension; grep filters the renderer line to show if you are on amdgpu or llvmpipe
If the output shows llvmpipe, the system is using software rendering. Proceed to the fix section. If the output shows your GPU model, the driver is working. You can stop here unless you are troubleshooting a specific performance issue.
Run glxinfo first. Read the renderer string before guessing.
Restore hardware acceleration
Ensure the kernel and Mesa packages are current before troubleshooting deeper. An outdated kernel might lack the amdgpu module for your specific GPU generation. An outdated Mesa version might have a regression that breaks acceleration.
Here's how to update the system to the latest kernel and graphics stack.
# Refresh metadata and upgrade all packages to the latest versions
sudo dnf upgrade --refresh
# WHY: --refresh forces dnf to download fresh metadata, ensuring you get the latest kernel and Mesa updates
After the upgrade, the new kernel is installed but not active. The initramfs might also be out of sync. The initramfs is a small filesystem loaded early in the boot process. It contains the drivers needed to mount the root filesystem. If the amdgpu module is missing from the initramfs, the driver won't load until the root filesystem is mounted, which can cause issues with early graphics initialization.
Here's how to regenerate the initramfs to include the current kernel modules.
# Regenerate the initramfs for the running kernel to include the amdgpu module
sudo dracut --force
# WHY: dracut rebuilds the initial ramdisk; --force ensures the new image overwrites the old one even if timestamps match
Secure Boot can also block driver loading. If your firmware has Secure Boot enabled, the kernel will refuse to load modules that are not signed with a trusted key. Fedora signs its modules, but custom kernels or third-party packages might not be. Check the Secure Boot state to rule out firmware restrictions.
Here's how to check if Secure Boot is enabled in the current boot environment.
# Check if Secure Boot is enabled in the current boot environment
mokutil --sb-state
# WHY: mokutil queries the firmware; if Secure Boot is enabled, unsigned modules will be rejected at boot
If Secure Boot is enabled and you see signature errors in the boot log, you need to enroll the Machine Owner Keys or disable Secure Boot in the firmware settings. Fedora works best with Secure Boot enabled and the default keys. Disabling it is a last resort.
Regenerate the initramfs after a kernel update. The new image only loads on reboot.
Check for parameter conflicts
Kernel parameters can override driver behavior. The nomodeset parameter disables kernel mode setting, which prevents the GPU driver from initializing. Users often add nomodeset to fix a black screen during installation. That parameter must be removed for the AMD driver to function.
Here's how to display the current kernel command line to check for conflicting parameters.
# Display the current kernel command line to check for conflicting parameters
cat /proc/cmdline
# WHY: /proc/cmdline shows the parameters passed to the kernel; look for nomodeset or radeon which can disable amdgpu
If you see nomodeset in the output, remove it. Edit the GRUB configuration to drop the parameter. Never edit files in /usr/lib/. Configuration for the bootloader lives in /etc/. Modify /etc/default/grub and run grub2-mkconfig to apply changes.
Another conflict is the radeon parameter. Very old AMD cards use the radeon driver. Newer cards use amdgpu. If you force radeon on a modern GPU, performance will be terrible and features will be missing. Conversely, forcing amdgpu on legacy hardware might fail. Fedora handles this automatically for most chips. If you have a specific legacy chip that needs amdgpu, you can enable support via parameters, but only if you know your GPU generation.
Remove nomodeset from the kernel parameters. The driver needs mode setting to function.
Validate Vulkan and OpenGL
OpenGL is the traditional API for graphics. Vulkan is the modern, low-overhead API used by most games and professional applications. Both rely on the Mesa stack. Verify that Vulkan is working to ensure the full stack is operational.
Here's how to check Vulkan support and identify the active device.
# Query Vulkan layers and devices to confirm Vulkan is functional
vulkaninfo | grep deviceName
# WHY: vulkaninfo dumps the Vulkan runtime state; grep isolates the device name to confirm the GPU is recognized by the Vulkan loader
If vulkaninfo fails or reports no devices, the Vulkan ICD files might be missing or misconfigured. This is rare on a default Fedora install. It usually indicates a broken Mesa installation. Reinstall the Mesa packages if this happens.
Check vulkaninfo to confirm the full stack is operational.
Common pitfalls
The radeon vs amdgpu confusion is the most common issue. The amdgpu driver supports GCN architecture and newer. That includes most AMD GPUs from the last decade. The radeon driver supports older TeraScale hardware. Fedora loads the correct driver automatically based on the PCI ID. If you see radeon in lspci -k on a modern GPU, the kernel might be missing the amdgpu module or the module failed to load. Check journalctl -xe for errors. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style. Look for lines mentioning amdgpu or drm.
Secure Boot errors appear as signature verification failed in the boot log. If you compiled a custom kernel or installed a third-party module, you must sign it with the MOK keys. Fedora's default modules are signed. If you see this error with default packages, the shim might be out of date. Upgrade the shim package.
Configuration drift happens when users edit files in the wrong location. Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. If you need to pass parameters to the amdgpu module, create a file in /etc/modprobe.d/ instead of modifying system files. The package manager will overwrite /usr/lib/ files on upgrade and destroy your changes.
Check journalctl -xe for module load failures. The logs tell you exactly why the driver refused to bind.
When to use which driver
Use amdgpu when you have a GCN 1.0 or newer GPU and want full hardware acceleration with Vulkan and OpenGL support. Use radeon when you have legacy TeraScale hardware that predates the GCN architecture. Use amdgpu-pro only when you are running specific professional workloads that require proprietary compute features and you accept the trade-offs of a closed-source stack. Stick to the default Mesa stack for desktop usage, gaming, and general development.
Trust the package manager. Manual file edits drift, snapshots stay.