Dxvk On FreeBSD Outperforms DxvK on Linux...How can that Be?

General system Newbie
1

Hi all. I will try to stay focused on Linux, though by the nature of the issue it may be difficult. I’m dual booting FreeBSD and Endeavouros on separate drives, using refind as my boot loader. This is on an ancient Dell Optiplex 7050.

Following a guide I found on google, I successfully used Dracut to generate a new initramfs that defaults to the amdgpu driver. I searched Google and DDgo for so many hours that I don’t remember the guide’s url; sorry.

The Video card is a Radeon HD 8570, made circa 2017.

In FreeBSD land you just tell the kernel to load the module at boot in a simple text file. But Dracut did it’s job. I’m still limited to 1920x1080@60 Hz - any other setting and my monitor shows a “signal out of range” error. xRandR reports the max refresh of the display as 75hz, which is incorrect.

The game in question is “Empires Dawn of the Modern World”. I bought it from from GOG Games.

The game switches resolution on the fly when you switch to the game’s editor (800x600@60). One can (from either os) invoke the game’s editor, and it will work with a bit of registry hacking and “vandalizing” a file named “gog.ini “ to disable the default registry entries being regenerated.

But what gets me is that the game editor fonts under Linux are blurred and hard to read. Running on FreeBSD everything is crystal clear. In BSD I installed and configured drm-kmod. For Endeavour I installed the “Default UEFI” choice from the installer.

So what I don’t get is how a driver loaded by FreeBSD that is ported from Linux would look better than in the OS it came from. ..? Makes no sense to me.

I understand that I haven’t provided enough info for an immediate answer, but if anyone can point me in the right direction, or tell me about some diagnostic commands, I would be most grateful. I would like to use either OS to play the game.

2

As you said yourself, you have not provided much info.

Also, I’m really lost about how “Default UEFI” would do any difference in considering graphics. Why do you need to force amdgpu to work? Do you have two GPUs?

Do you plan to use game’s editor? Have you tried actual game, how does it look?

There are so many questions rising here, so it would be really nice to have something concrete from where to begin solving this issue of yours.

3

It has often been said anecdotally that many native Windows games run faster under Linux + Proton.

When you describe FreeBSD outperforming Linux using a Linux driver, that thought crosses my mind.

I can’t offer anything in the way of specifics to your question, except to note that FreeBSD is a highly optimised and focused OS, and improved performance is plausible.

4

Do you plan to use game’s editor?

Yes, extensively. Being able to read the text inside it is a must if I am going to run it on Linux.

Why do you need to force amdgpu to work?

The graphics card supports both the amdgpu and radeon drivers. Only amdgpu supports the Vulkan api. Endeavouros automatically detects the card and selects the radeon driver during installation. By ‘UEFI Default’ I just meant that I picked the first option from the installer iso during setup. The guide I mentioned was just an entry in the Arch wiki:

The output from lspci -k -d ::03xx is as follows:

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Oland [Radeon HD 8570 / R5 430 OEM / R7 240/340 /

Radeon 520 OEM] (rev 87)
Subsystem: Dell Radeon R5 430 OEM (2048 MByte)
Kernel driver in use: amdgpu
Kernel modules: radeon, amdgpu

And the output from vulkaninfo --summary :

Vulkan Instance Version: 1.4.328

Instance Extensions: count = 24

VK_EXT_acquire_drm_display : extension revision 1
VK_EXT_acquire_xlib_display : extension revision 1
VK_EXT_debug_report : extension revision 10
VK_EXT_debug_utils : extension revision 2
VK_EXT_direct_mode_display : extension revision 1
VK_EXT_display_surface_counter : extension revision 1
VK_EXT_headless_surface : extension revision 1
VK_EXT_surface_maintenance1 : extension revision 1
VK_EXT_swapchain_colorspace : extension revision 5
VK_KHR_device_group_creation : extension revision 1
VK_KHR_display : extension revision 23
VK_KHR_external_fence_capabilities : extension revision 1
VK_KHR_external_memory_capabilities : extension revision 1
VK_KHR_external_semaphore_capabilities : extension revision 1
VK_KHR_get_display_properties2 : extension revision 1
VK_KHR_get_physical_device_properties2 : extension revision 2
VK_KHR_get_surface_capabilities2 : extension revision 1
VK_KHR_portability_enumeration : extension revision 1
VK_KHR_surface : extension revision 25
VK_KHR_surface_protected_capabilities : extension revision 1
VK_KHR_wayland_surface : extension revision 6
VK_KHR_xcb_surface : extension revision 6
VK_KHR_xlib_surface : extension revision 6
VK_LUNARG_direct_driver_loading : extension revision 1

Instance Layers: count = 5

VK_LAYER_INTEL_nullhw INTEL NULL HW 1.1.73 version 1
VK_LAYER_MESA_device_select Linux device selection layer 1.4.303 version 1
VK_LAYER_MESA_overlay Mesa Overlay layer 1.4.303 version 1
VK_LAYER_MESA_screenshot Mesa Screenshot layer 1.4.303 version 1
VK_LAYER_MESA_vram_report_limit Limit reported VRAM 1.4.303 version 1

Devices:

GPU0:
apiVersion = 1.3.318
driverVersion = 25.2.7
vendorID = 0x1002
deviceID = 0x6611
deviceType = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU
deviceName = AMD Radeon R7 200 Series (RADV OLAND)
driverID = DRIVER_ID_MESA_RADV
driverName = radv
driverInfo = Mesa 25.2.7-arch1.1
conformanceVersion = 1.4.0.0
deviceUUID = 00000000-0100-0000-0000-000000000000
driverUUID = 414d442d-4d45-5341-2d44-525600000000

From the BSD side it’s mostly the same, a snippit from vulkaninfo --summary yields this:

GPU0:

apiVersion = 1.3.278
driverVersion = 24.1.7
vendorID = 0x1002
deviceID = 0x6611
deviceType = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU
deviceName = AMD Radeon R7 200 Series (RADV OLAND)
driverID = DRIVER_ID_MESA_RADV
driverName = radv
driverInfo = Mesa 24.1.7
conformanceVersion = 0.0.0.0
deviceUUID = 00000000-0100-0000-0000-000000000000
driverUUID = 414d442d-4d45-5341-2d44-525600000000

The principle differences being the version of mesa in use as seen above, (24.x on FreeBSD vs 25.x on Endeavour), as well as the version of the api (1.3.278. vs 1.3.318)

Have you tried actual game, how does it look?

I’ve played for an hour or more with Endeavouros, no crashes. I’ve done the same on FreeBSD. The graphics look fine on both. Only the editor seems to be affected.

The only other graphics card is the integrated intel iGPU, but It’s disabled in the bios. This is mainly a ‘project box’ for tinkering, my main PC has been running Endeavouros exclusively for ages, and the font issue I am describing affects it also. That pc is up to date. The box I’m using now is a fresh install. Note that I am NOT using linux emulation from the BSD side.

5

Almost guaranteed that is not what is related to the fonts being blurry. This sounds like a scaling issue. On EndeavourOS are you using xorg or wayland…because we know you are using xorg on FreeBSD. DId you copy a bunch of ~/home/user files to both of these…if so the likelihood of a config buried in a hidden file in these wreaking havoc on one but not the other could also be the culprit or are these completely bare devoid of any configuration or files outside of the game. In short you probably have a configuration issue related to scaling and that is all.

1 Like
6

Well, you’ve hit the mark about wayland…in a sense at least.

But about the file copy issue..

The BSD install is using ufs, and the Linux drive is ext4. Linux doesn’t natively support ufs even as read only without extra kernel modules, or so that is my understanding. And I know better than to mount an ext4 partition from BSD, even read only you risk corrupting the fs journal.

It’s primitive, but I only share files from one disk to the other to the other by uploading them to google drive.

Back to wayland. My desktop of choice is xfce, so I don’t think the Endeavour iso would install wayland. But searching my system has shown that It does indeed have wayland installed.

The only explanation I can think of is that I installed Kate and Gwenview, and perhaps they pulled it in? I never installed it explicitly…

I fired up the ‘Welcome’ app and changed the DM to sddm, then installed the full Plasma desktop, launching (from the dropdown menu) 'Plasma Wayland"

This worked better than I thought it would. Now the game crashes gracefully. Editing the registry to force 1920x1080@60, then moving the whole game folder out of the wine prefix allowed the game to start, but when it switched resolutions the window appeared in the top left of the screen.

And a friendly FYI…FreeBSD-14.3-RELEASE-p5 does support Wayland on Plasma. Tried it once, didn’t care for it.

Thanks everyone for the replies. I’m going to give reinstalling the system with Plasma and Wayland in a proper fashion a try before I give up.

7

A quick comment as I mark this thread ‘solved’. After trying several experiments with X11,Wayland,Wine versions - etc etc…I have found that the issue is at a lower level in the kernel

FreeBSD is basically “holding my hand” due to the way it handles PAE (Physical Address Extensions).

In a nutshell: Where Linux segfaults on an memory address, FreeBSD remaps the call to an available address. That’s a gross oversimplification but this is a Linux forum so never mind the details.

Not saying FreeBSD is a better OS, it’s all about personal preference and use case in the end. Thanks to all who work on and support Endeavour, it’s a great distro.

1 Like
8

But you’re not not saying that either :grinning_face_with_smiling_eyes::winking_face_with_tongue:

But I jest, and agree with your sentiment about preference. Thanks for sharing the details. Whilst simplified for our benefit, it was an interesting discovery none the less :+1:

9

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.