Good day, Masaru, and Packmans! On Thu, 19 Jan 2023 at 08:52, Masaru Nomiya <[email protected]> wrote:
> I'm curious about this too. > AMD is making major architectural changes every year. > What is your card? > This machine is an HP Gen10 Proliant Microserver, entry model. Quickspecs here: https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=a00008701enw As I recall, I bout this machine some time towards the end of 2018. The GPU, according to inxi, is an AMD Wani [Radeon R5/R6/R7 Graphics]. It is integrated into the Microserver unit, it's not a separate PCI card. I think it's part of the motherboard. As I recall, I only installed Tumbleweed on this machine in the first place because the Kabini sound card that is integrated into this video card was too new for the Leap kernel at the time. > Install the same version of libx264-devel and libx265-devel as the > x264 and x265 libraries, then build. > I have done so, and I must thank you for these instructions, Masaru! I noticed an immediate performance boost! Before installing ibx264-devel and libx265-devel, on the first build, the following RPMs were built: libgbm1-22.3.3-1422.1.x86_64.rpm libvulkan_radeon-22.3.3-1422.1.x86_64.rpm Mesa-libEGL-devel-22.3.3-1422.1.x86_64.rpm libgbm-devel-22.3.3-1422.1.x86_64.rpm libxatracker2-1.0.0-1422.1.x86_64.rpm Mesa-libGL1-22.3.3-1422.1.x86_64.rpm libLLVMSPIRVLib15-15.0.0-1.1.x86_64.rpm libxatracker-devel-1.0.0-1422.1.x86_64.rpm Mesa-libglapi0-22.3.3-1422.1.x86_64.rpm libLLVMSPIRVLib-devel-15.0.0-1.1.x86_64.rpm Mesa-22.3.3-1422.1.x86_64.rpm Mesa-libglapi-devel-22.3.3-1422.1.x86_64.rpm libOSMesa8-22.3.3-1422.1.x86_64.rpm Mesa-devel-22.3.3-1422.1.x86_64.rpm Mesa-libGL-devel-22.3.3-1422.1.x86_64.rpm libOSMesa-devel-22.3.3-1422.1.x86_64.rpm Mesa-dri-22.3.3-1422.1.x86_64.rpm Mesa-libGLESv1_CM-devel-22.3.3-1422.1.x86_64.rpm libvdpau_nouveau-22.3.3-1422.1.x86_64.rpm Mesa-dri-devel-22.3.3-1422.1.x86_64.rpm Mesa-libGLESv2-devel-22.3.3-1422.1.x86_64.rpm libvdpau_r300-22.3.3-1422.1.x86_64.rpm Mesa-dri-nouveau-22.3.3-1422.1.x86_64.rpm Mesa-libGLESv3-devel-22.3.3-1422.1.x86_64.rpm libvdpau_r600-22.3.3-1422.1.x86_64.rpm Mesa-gallium-22.3.3-1422.1.x86_64.rpm Mesa-libOpenCL-22.3.3-1422.1.x86_64.rpm libvdpau_radeonsi-22.3.3-1422.1.x86_64.rpm Mesa-KHR-devel-22.3.3-1422.1.x86_64.rpm Mesa-libRusticlOpenCL-22.3.3-1422.1.x86_64.rpm libvdpau_virtio_gpu-22.3.3-1422.1.x86_64.rpm Mesa-libd3d-22.3.3-1422.1.x86_64.rpm Mesa-libva-22.3.3-1422.1.x86_64.rpm libvulkan_intel-22.3.3-1422.1.x86_64.rpm Mesa-libd3d-devel-22.3.3-1422.1.x86_64.rpm Mesa-vulkan-device-select-22.3.3-1422.1.x86_64.rpm libvulkan_lvp-22.3.3-1422.1.x86_64.rpm Mesa-libEGL1-22.3.3-1422.1.x86_64.rpm Mesa-vulkan-overlay-22.3.3-1422.1.x86_64.rpm For the rebuild, I downloaded the latest src packages, and I noticed that this time, an extra RPM was built: Mesa-libRusticlOpenCL-22.3.3-1422.1.x86_64.rpm However, there was no change to what vdpauinfo reported with the first build and the Packman drivers. This machine has been set up as an HTPC, I mostly use it to play music, and sometimes, videos as well. I am also a big fan of emulators, and have several emulators installed for now-obsolete platforms. (I don't really play the games much, the fun for me is mainly in setting them up and getting them working.) The first thing I noticed after rebuilding these drivers is that Kodi's ProjectM visualisation addon became a lot more performant! I thought that may have been subjective, so I decided to test out a few of my emulators. My test procedure was to run Kodi with the visualisation running. (But the music was paused.) Then I started one of the emulators. I tested the following emulators: AdvanceMAME: https://www.advancemame.it/ DOSBox, ePSXe, PSX2, and the atari800 emulator. https://atari800.github.io/ The atari800 emulator was running at 100% with the default OpenSUSE Mesa drivers, I got the same result with this test. However, I assume the resource requirements for this emulator are very low. The PSX2 emulator was running at between 30% and 45% emulation speed, no matter what I tried. However, I have never been able to get this emulator working properly on that machine, I assume my hardware is too slow. Performance was degraded for all the other emulators. However, after I shut Kodi down, things improved substantially! ePSXe, DOSBox, and MAME were all running at full speed! Previously, the only way I could do that was by doing a reboot, and making sure that the emulator was the only application running. I couldn't even have Firefox open! I tested ePSXe with Tomb Raider, it was running at full speed. I tested MAME with three games, Double Dragon, Area 51, and Macross Plus. These are all resource-heavy games, and they were all running at full speed. Just a few notes about DOSBox - it's possible to change the emulation speed with hotkeys. I had recently run Ultima Underworld with the OpenSUSE drivers, and I had to increase the emulation speed to 3000% to get it to run smoothly. This time it worked perfectly well at 1500%. I tested it with Magic Carpet, and had to decrease the emulation speed to 25%, because it was running much too fast at 100%. It was playable at 25%. I tested it with Duke Nukem 3D, and it was running fine at 100%. Then I tested it with Quake, with the screen resolution set to 1024x768, the maximum setting. The game ran properly and was playable. But, something strange I noticed about that was I couldn't increase the emulation speed above 105%. (Quake is the most CPU and graphics-intensive DOS game I could think of.) So, I think this is the best I can hope for with my Tumbleweed box! I think I am at optimal performance now. A big thank you to everyone who helped! Later today, I am going to follow the notes I have made and build the Mesa drivers for the Leap machine, which is a much older Microserver - circa 2012, (as I recall), and make sure that the procedure is correct. After that, I will try to make time to write up my HOWTO. Kind regards, Steven. _______________________________________________ Packman mailing list [email protected] https://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
