FNA3D D3D11 Linux: Alpha "Release"

Just over a year ago I started providing FNA3D Linux binaries that included support for D3D11. This was very early work, and at the time it didn't actually run anything because we were limited by our options for shader compilers. We didn't have a DXBC emitter that dxvk could read shaders from, nor did we have a complete HLSL->DXBC compiler, at least not at the time. There was a compiler in progress as part of vkd3d, but it was also in its early days, so I sort of just looked at both and said "let's figure it out later."

Fast forward to 2023, and vkd3d 1.7 releases - it was almost a year since I last tried, so I gave it another go:

It ran a lot more than I was expecting!

Wow!

It's working!

Ahhh there we go. So it turns out it wasn't perfect. But a small list of bugs is a whole lot easier to deal with than trying to run something and not even knowing where to start.

And so the Bug Filing Bonanza began. And then it grew into its own little tracker. And as you can see in each issue, a lot of patches came out of this too! Some even have my name on them! The end result is this:

I was really excited to help with this for a few reasons:

1. It was an excuse to work with CodeWeavers' programmers again
2. Having a Linux-native HLSL->DXBC compiler has been on every porter's wishlist forever (as Ryan can attest to)
3. It was also an excuse to start helping Joshua Ashton with making D3D9/10/11 a runtime provided by operating systems, as well as the Steam Runtime

While Valve still isn't prioritizing native, that hasn't stopped others from working on it independently - it's this cooperation that allowed the FNA team to release what I'm badly naming "The FNA3D D3D11 Linux Alpha"! Available on the FNA website, this is a supplementary archive for fnalibs.tar.bz2; by updating fnalibs and bundling linux_d3d11, you can now pass /gldevice:D3D11 as a launch arg, and it will use dxvk with the native Linux binaries. Is it any better than our native OpenGL/Vulkan renderers? Maybe! Is it still cool even if it isn't better? Sure! The main goal of this feature is that it showcases what's possible for studios using D3D that want to make native versions, since somebody needs to tell everyone that this is an option, and I don't see anyone else doing that, so... here we are.

Of course, this is an Alpha, which mostly means that it will probably work, but don't be too surprised if it doesn't - you should definitely file reports if you see anything break. You'll likely run into one message a lot:

As for what's left, here are the big TODOs:

1. Upstream all our vkd3d patches in time for 1.8
2. Establish a dxvk-native ABI
3. Get dxvk-native 2.2(?) and vkd3d 1.8(???) packaged in distributions, including the Steam Runtime

That will effectively fulfill my vision for what all of the recent DirectX work could be doing for native: Provide a built-in Direct3D runtime and HLSL compiler in distributions, just as we already do for other graphics libraries and shader languages, so that developers can target native Linux binaries without having to statically bundle what amounts to an entire graphics driver inside their game. The samples above may not look super cutting edge, but even small developers can make use of these features to improve energy efficiency for the new handheld PC craze, as well as improving on the usual performance and stability concerns.

And of course, I'm still supporting OpenGL as always, and the FNA team is still heavily invested in SDL_gpu, but this has been a fun thing to work on in between SDL_ActionSet work and some other console projects that I've been working on in the background. I hope the work will help continue to build a platform that developers feel confident shipping native games on, and maybe Valve will get excited about it too!

flibitBuild

Want to replicate my build machine? Grab a RHEL8-based OS and have a look!

"RHEL-based" OSes include RHEL for Developers, Rocky Linux, and AlmaLinux.

Your OS minimum will be "glibc 2.28+, 64-bit only".

# Update base install before doing anything else
dnf update
# Add EPEL
dnf install epel-release
crb enable
# SDL2 dependencies
dnf builddep SDL2
# All the base build tools!
dnf install bzip2 bzip2-devel chrpath clang cmake freetype-devel gcc-c++ \
    git gtk3-devel libstdc++-static libuuid-devel libvorbis-devel \
    libxml2-devel meson mingw32-gcc-c++ mingw64-gcc-c++ ninja-build \
    ocl-icd-devel openal-soft-devel opencl-headers openssl-devel patch \
    perl-IPC-Cmd svn unix2dos zlib-static

# libdecor
curl -O https://gitlab.gnome.org/jadahl/libdecor/-/archive/0.1.0/libdecor-0.1.0.tar.bz2
tar xvfj libdecor-0.1.0.tar.bz2
mkdir libdecor-0.1.0/flibitBuild
cd libdecor-0.1.0/flibitBuild
meson .. --libdir=lib -Ddemo=false
ninja
su -c 'ninja install'

# PipeWire 0.3.42 (Highest version usable with meson)
curl -O https://gitlab.freedesktop.org/pipewire/pipewire/-/archive/0.3.42/pipewire-0.3.42.tar.bz2
tar xvfj pipewire-0.3.42.tar.bz2
mkdir pipewire-0.3.42/flibitBuild
cd pipewire-0.3.42/flibitBuild
meson setup .. --libdir=lib -Dsession-managers= -Dpipewire-v4l2=disabled -Dv4l2=disabled -Draop=disabled
ninja
su -c 'ninja install'

# Also:
# Configure SDL with PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ./configure
# The CMake config provided by SDL2-mingw is terrible, delete the block
#  that starts with "if(NOT TARGET SDL2::SDL2)".

flibitBuild AArch64

This works fine on the latest Fedora. Your glibc minimum will be 2.34.

# On Fedora...
dnf install qemu-system-aarch64
dnf group install --with-optional virtualization
virt-builder fedora-35 --arch aarch64 --size 32G \
    --root-password password:!!YOUR_PASS!!
virt-install --name fedora_aarch64 --arch aarch64 --ram 3072 \
    --disk path=fedora-35.img,format=raw --os-variant fedora35 --import

# Inside the VM...
dnf builddep SDL2 libgdiplus
dnf install autoconf automake bison bzip2 chrpath cmake gettext-devel git \
    libicu-devel libtool python tar unzip

Wait, a "plan"?

Well, this is a .plan file, so here's my TODO. Expect nothing from it, ever.

In Progress
    SDL_ActionSet

Waiting Room (2023)
    SDL 3.0
        - SDL_ActionSet is what sponsor resources are going towards
        - SDL_StorageContainer is whenever I feel like it
        - Wayland/PipeWire are waiting on external components
    Codename TupTip
        - Waiting for third-party services to start up
    Marble It Up Ultra
        - Back in cert once more~
    Coding History
        - On call throughout development
    VVVVVV 2.4
        - Giving the localization project as much time as it wants
    Super Hexagon Neo Part 2
        - Occasional merge work
Waiting Room (Heat Death)
    ScoreRush PC
        - Need AppAdmin for publish, crosshair for mouse
    Proteus "Neo" Rewrite
        - Retirement project