
u/ilnarildarovuch

AMD FSR implementation on Russian PL "KuMiR"
Works on CPU, rendered in... about hour. Original shader — XorDev "Plasma".
This was just test of custom port KuMiR to FreeBSD
AMDGPU power1_cap setting
Since I couldn't find a native method to set power limits for the AMDGPU driver via drm-kmod on FreeBSD, I decided to write a small patch for drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c. (if You want to use that, please, execute it in the same directory as amdgpu_drv.c)
Currently, this patch is a quick workaround designed for single-GPU setups. If you have multiple AMD graphics cards installed, this implementation will trigger UB due to the global device pointer. It exposes a simple sysctl node hw.amdgpu.power1_cap to view and adjust the current GPU power cap in watts.
The reason I urgently needed this is my PSU. It frequently triggers sudden power outages whenever the GPU spikes in power consumption. Previously, I just tolerated it or setting up old Nvidia GT 240 and tried my best not to trigger heavy workloads, but honestly, I've had enough :D
For anyone working on the FreeBSD DRM graphics stack: is a native, multi-GPU-safe power management implementation already planned?
Hardware acceleration on FreeBSD 14.4 i386
I managed to get hardware acceleration working on a 32-bit Intel Atom CPU running FreeBSD 14.4.
Not long ago, FreeBSD dropped 32-bit support for drm-kmod, but there are patches available for drm-510-kmod that allow you to run it. The main issue was with the pci_get_slot function, which can be fixed by adding #define WANT_NATIVE_PCI_GET_SLOT to the source files that use it. I couldn't compile it myself: the system linker kept failing to see functions provided via MODULE_DEPEND(9). Fortunately, I found someone online who had made similar patches and compiled the module inside a FreeBSD 14.3 Jail. Interestingly, that 14.3 build worked out of the box.
Dealing with kernel drivers was only half the battle. The current Mesa-dri completely drops the classic i915 driver in favor of Gallium3D. Because of this, I had to build Mesa-amber. I installed it into /opt/mesa-amber to prevent conflicts with the stock Mesa. In the build configuration, I enabled only the i915 driver, since my graphics chip is a GMA 950.
After setting up the environment variables, I noticed that functions interacting with executable memory triggered a SIGSEGV. As it turned out, mesa-amber was trying to execute memory in a strict W^X environment. The solution was simply to disable code generation (CODEGEN), after which glxgears ran fine with OpenGL 1.4. The final environment flags are:
export LD_LIBRARY_PATH=/opt/mesa-amber/lib
export LIBGL_DRIVERS_PATH=/opt/mesa-amber/lib/dri
export __GLX_VENDOR_LIBRARY_NAME="amber"
export MESA_LOADER_DRIVER_OVERRIDE=i915
export LIBGL_ALWAYS_SOFTWARE=0
export MESA_NO_CODEGEN=1
Next, I want to try running Portal. Right now, it runs via llvmpipe on stock Mesa, but the hardware OpenGL version here is too old (the Source engine requires OpenGL 2.0). I plan to create a small shim using LD_PRELOAD to emulate some of the missing functions.
UPD1: Running EGL. export __EGL_VENDOR_LIBRARY_FILENAMES=/opt/mesa-amber/share/glvnd/egl_vendor.d/50_amber.json export EGL_PLATFORM=x11
So... Source already have ToGLES. I'll rebuild project with it, so, maybe this will run fully natively
Fixing Huanan reboot-on-shutdown problem
It often infuriated me that the Huanan X79G motherboard rebooted instead of poweroff on FreeBSD due to poor UEFI.
I recently thought about whether it is possible to simply make a hardware outw() with pm1_cnt to pm1_s5 (outw(0x404, 0x3C00); here).
Default settings, like: hw.efi.poweroff="0" or hw.acpi.disable_on_poweroff="0" does not work. Still reboots.
So, i want to set values of port and value by TUNABLE settings (/boot/loader.conf) and get them from custom module, so this simple fix can work on any Huanan or Machinist motherboard.
If someone has the same issue on another motherboard, please, add name of it
UPD: 0x3C00 on 0x404 also reboots. I need to check more info
UPD: tried again with disabled efi... now it works....
Killall!
killall in bsd/gnu: just kills processes by their names
killall in Solaris/SystemV: