# osy.dxvk

**Repository Path**: umu618/osy.dxvk

## Basic Information

- **Project Name**: osy.dxvk
- **Description**: Mirror of https://github.com/osy/dxvk
- **Primary Language**: Unknown
- **License**: Zlib
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-08-14
- **Last Updated**: 2026-08-26

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# DXVK

A Vulkan-based translation layer for Direct3D 8/9/10/11 which allows running 3D applications on Linux using Wine.

For the current status of the project, please refer to the [project wiki](https://github.com/doitsujin/dxvk/wiki).

The most recent development builds can be found [here](https://github.com/doitsujin/dxvk/actions/workflows/artifacts.yml?query=branch%3Amaster).

Release builds can be found [here](https://github.com/doitsujin/dxvk/releases).

## How to use
In order to install a DXVK package obtained from the [release](https://github.com/doitsujin/dxvk/releases) page into a given wine prefix, copy or symlink the DLLs into the following directories as follows, then open `winecfg` and manually add `native` DLL overrides for `d3d8`, `d3d9`, `d3d10core`, `d3d11` and `dxgi` under the Libraries tab.

In a default Wine prefix that would be as follows:
```
export WINEPREFIX=/path/to/wineprefix
cp x64/*.dll $WINEPREFIX/drive_c/windows/system32
cp x32/*.dll $WINEPREFIX/drive_c/windows/syswow64
winecfg
```

For a pure 32-bit Wine prefix (non default) the 32-bit DLLs instead go to the `system32` directory:
```
export WINEPREFIX=/path/to/wineprefix
cp x32/*.dll $WINEPREFIX/drive_c/windows/system32
winecfg
```

Verify that your application uses DXVK instead of wined3d by enabling the HUD (see notes below).

In order to remove DXVK from a prefix, remove the DLLs and DLL overrides, and run `wineboot -u` to restore the original DLL files.

Tools such as Steam Play, Lutris, Bottles, Heroic Launcher, etc will automatically handle setup of dxvk on their own when enabled.

#### DLL dependencies 
Listed below are the DLL requirements for using DXVK with any single API.

- d3d8: `d3d8.dll` and `d3d9.dll`
- d3d9: `d3d9.dll`
- d3d10: `d3d10core.dll`, `d3d11.dll` and `dxgi.dll`
- d3d11: `d3d11.dll` and `dxgi.dll`

### Notes on Vulkan drivers
Before reporting an issue, please check the [Wiki](https://github.com/doitsujin/dxvk/wiki/Driver-support) page on the current driver status and make sure you run a recent enough driver version for your hardware.

### Online multi-player games
Manipulation of Direct3D libraries in multi-player games may be considered cheating and can get your account **banned**. This may also apply to single-player games with an embedded or dedicated multiplayer portion. **Use at your own risk.**

### HUD
The `DXVK_HUD` environment variable controls a HUD which can display the framerate and some stat counters. It accepts a comma-separated list of the following options:
- `devinfo`: Displays the name of the GPU and the driver version.
- `fps`: Shows the current frame rate.
- `frametimes`: Shows a frame time graph.
- `submissions`: Shows the number of command buffers submitted per frame.
- `drawcalls`: Shows the number of draw calls and render passes per frame.
- `pipelines`: Shows the total number of graphics and compute pipelines.
- `descriptors`: Shows the number of descriptor pools and descriptor sets.
- `memory`: Shows the amount of device memory allocated and used.
- `allocations`: Shows detailed memory chunk suballocation info.
- `gpuload`: Shows estimated GPU load. May be inaccurate.
- `version`: Shows DXVK version.
- `api`: Shows the D3D feature level used by the application.
- `cs`: Shows worker thread statistics.
- `compiler`: Shows shader compiler activity
- `samplers`: Shows the current number of sampler pairs used *[D3D9 Only]*
- `ffshaders`: Shows the current number of shaders generated from fixed function state *[D3D9 Only]*
- `swvp`: Shows whether or not the device is running in software vertex processing mode *[D3D9 Only]*
- `scale=x`: Scales the HUD by a factor of `x` (e.g. `1.5`)
- `opacity=y`: Adjusts the HUD opacity by a factor of `y` (e.g. `0.5`, `1.0` being fully opaque).

Additionally, `DXVK_HUD=1` has the same effect as `DXVK_HUD=devinfo,fps`, and `DXVK_HUD=full` enables all available HUD elements.

### Logs
When used with Wine, DXVK will print log messages to `stderr`. Additionally, standalone log files can optionally be generated by setting the `DXVK_LOG_PATH` variable, where log files in the given directory will be called `app_d3d11.log`, `app_dxgi.log` etc., where `app` is the name of the game executable.

On Windows, log files will be created in the game's working directory by default, which is usually next to the game executable.

### Device filter
Some applications do not provide a method to select a different GPU. In that case, DXVK can be forced to use a given device:
- `DXVK_FILTER_DEVICE_NAME="Device Name"` Selects devices with a matching Vulkan device name, which can be retrieved with tools such as `vulkaninfo`. Matches on substrings, so "VEGA" or "AMD RADV VEGA10" is supported if the full device name is "AMD RADV VEGA10 (LLVM 9.0.0)", for example. If the substring matches more than one device, the first device matched will be used.
- `DXVK_FILTER_DEVICE_UUID="00000000000000000000000000000001"` Selects a device by matching its Vulkan device UUID, which can also be retrieved using tools such as `vulkaninfo`. The UUID must be a 32-character hexadecimal string with no dashes. This method provides more precise selection, especially when using multiple identical GPUs.

**Note:** If the device filter is configured incorrectly, it may filter out all devices and applications will be unable to create a D3D device.

### Debugging
The following environment variables can be used for **debugging** purposes.
- `VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation` Enables Vulkan debug layers. Highly recommended for troubleshooting rendering issues and driver crashes. Requires the Vulkan SDK to be installed on the host system.
- `DXVK_LOG_LEVEL=none|error|warn|info|debug` Controls message logging.
- `DXVK_LOG_PATH=/some/directory` Changes path where log files are stored. Set to `none` to disable log file creation entirely, without disabling logging.
- `DXVK_DEBUG=markers|validation` Enables use of the `VK_EXT_debug_utils` extension for translating performance event markers, or to enable Vulkan validation, respecticely.
- `DXVK_CONFIG_FILE=/xxx/dxvk.conf` Sets path to the configuration file.
- `DXVK_CONFIG="dxgi.hideAmdGpu = True; dxgi.syncInterval = 0"` Can be used to set config variables through the environment instead of a configuration file using the same syntax. `;` is used as a seperator.
- `DXVK_SHADER_CACHE=0`: Disables the internal shader cache.
- `DXVK_SHADER_CACHE_PATH=/some/directory`: Path to internal shader cache files. By default, this will use `%LOCALAPPDATA%/dxvk` in a Windows
  or Wine environment, and `$HOME/.cache` or `$XDG_CACHE_HOME` in a native Linux environment.

### Graphics Pipeline Library
On drivers which support `VK_EXT_graphics_pipeline_library` Vulkan shaders will be compiled at the time the game loads its D3D shaders, rather than at draw time. This reduces or eliminates shader compile stutter in many games when compared to the previous system.

In games that load their shaders during loading screens or in the menu, this can lead to prolonged periods of very high CPU utilization, especially on weaker CPUs. For affected games it is recommended to wait for shader compilation to finish before starting the game to avoid stutter and low performance. Shader compiler activity can be monitored with `DXVK_HUD=compiler`.

**Note:** Games which only load their D3D shaders at draw time (e.g. most Unreal Engine games) will still exhibit some stutter, although it should still be less severe than without this feature.

## Build instructions

In order to pull in all submodules that are needed for building, clone the repository using the following command:
```
git clone --recursive https://github.com/doitsujin/dxvk.git
```

### Requirements:
- [wine 10.0](https://www.winehq.org/) or newer
- [Meson](https://mesonbuild.com/) build system (at least version 0.58)
- [Mingw-w64](https://www.mingw-w64.org) compiler and headers (at least version 10.0)
- [glslang](https://github.com/KhronosGroup/glslang) compiler

### Building DLLs

#### The simple way
Inside the DXVK directory, run:
```
./package-release.sh master /your/target/directory --no-package
```

This will create a folder `dxvk-master` in `/your/target/directory`, which contains both 32-bit and 64-bit versions of DXVK, which can be set up in the same way as the release versions as noted above.

In order to preserve the build directories for development, pass `--dev-build` to the script. This option implies `--no-package`. After making changes to the source code, you can then do the following to rebuild DXVK:
```
# change to build.32 for 32-bit
cd /your/target/directory/build.64
ninja install
```

#### Compiling manually
```
# 64-bit build. For 32-bit builds, replace
# build-win64.txt with build-win32.txt
meson setup --cross-file build-win64.txt --buildtype release --prefix /your/dxvk/directory build.w64
cd build.w64
ninja install
```

The D3D8, D3D9, D3D10, D3D11 and DXGI DLLs will be located in `/your/dxvk/directory/bin`.

### Build troubleshooting
DXVK requires threading support from your mingw-w64 build environment. If you
are missing this, you may see "error: ‘std::cv_status’ has not been declared"
or similar threading related errors.

On Debian and Ubuntu, this can be resolved by using the posix alternate, which
supports threading. For example, choose the posix alternate from these
commands:
```
update-alternatives --config x86_64-w64-mingw32-gcc
update-alternatives --config x86_64-w64-mingw32-g++
update-alternatives --config i686-w64-mingw32-gcc
update-alternatives --config i686-w64-mingw32-g++
```
For non debian based distros, make sure that your mingw-w64-gcc cross compiler 
does have `--enable-threads=posix` enabled during configure. If your distro does
ship its mingw-w64-gcc binary with `--enable-threads=win32` you might have to
recompile locally or open a bug at your distro's bugtracker to ask for it. 

# DXVK Native

DXVK Native is a version of DXVK which allows it to be used natively without Wine.

This is primarily useful for game and application ports to either avoid having to write another rendering backend, or to help with port bringup during development.

[Release builds](https://github.com/doitsujin/dxvk/releases) are built using the Steam Runtime.

### How does it work?

DXVK Native replaces certain Windows-isms with a platform and framework-agnostic replacement, for example, `HWND`s can become `SDL_Window*`s, etc.
All it takes to do that is to add another WSI backend.

**Note:** DXVK Native requires a backend to be explicitly set via the `DXVK_WSI_DRIVER` environment variable. The current built-in options are `SDL3`, `SDL2`, and `GLFW`.

DXVK Native comes with a slim set of Windows header definitions required for D3D9/11 and the MinGW headers for D3D9/11.
In most cases, it will end up being plug and play with your renderer, but there may be certain teething issues such as:
- `__uuidof(type)` is supported, but `__uuidof(variable)` is not supported. Use `__uuidof_var(variable)` instead.

### Shared resources (dma-buf textures and fences)

On native Linux builds, D3D11 resource sharing is implemented over Linux dma-buf and opaque file descriptors rather than Win32 shared `HANDLE`s. A shared-resource `HANDLE` is **a pointer to a self-contained descriptor** (`include/native/dxvk_shared_resource.h`), not an opaque OS handle. The descriptor bytes together with the fd they carry are the transportable unit: ship `{descriptor, fd}` to another process (for example over a Unix socket with `SCM_RIGHTS`) and it can reconstruct the resource there. The pointer itself is process-local and carries no meaning across a process boundary.

**Exporting a texture.** Create an `ID3D11Texture2D` with `D3D11_RESOURCE_MISC_SHARED` (or `D3D11_RESOURCE_MISC_SHARED_NTHANDLE`) and query its shared handle through the resource's `IDXGIResource`:

```cpp
Com<IDXGIResource> dxgiRes;
texture->QueryInterface(__uuidof(IDXGIResource), (void**)&dxgiRes);

HANDLE handle = nullptr;
dxgiRes->GetSharedHandle(&handle);

// handle is a DxvkSharedTextureDescriptor* owned by the texture:
//   desc->fd                is the dma-buf
//   desc->drmFormatModifier, desc->planes[] describe its layout
//   desc->meta              mirrors the D3D11_TEXTURE2D_DESC
auto* desc = reinterpret_cast<DxvkSharedTextureDescriptor*>(handle);
```

The texture allocates dedicated external memory and tiles by a DRM format modifier negotiated from the driver's list (linear fallback when `VK_EXT_image_drm_format_modifier` is unavailable). Only **2D, single-sampled** textures can be shared; keyed-mutex sharing (`D3D11_RESOURCE_MISC_SHARED_KEYEDMUTEX`) is rejected. Sharing failures are loud — `CreateTexture2D` fails rather than silently handing back a non-shared resource.

**Importing a texture.** In the consumer, fill a `DxvkSharedTextureDescriptor` (copy the descriptor bytes you received, then set `fd` to your received fd) and pass its address, cast to `HANDLE`, to `OpenSharedResource` / `OpenSharedResource1`:

```cpp
DxvkSharedTextureDescriptor desc = receivedDescriptor;
desc.fd = receivedFd;

Com<ID3D11Texture2D> texture;
device->OpenSharedResource(reinterpret_cast<HANDLE>(&desc),
  __uuidof(ID3D11Texture2D), (void**)&texture);
```

DXVK validates the descriptor's `magic` / `version` / `structSize` (mismatch → `E_INVALIDARG`), recreates the image with the explicit modifier layout, and imports a `dup()` of the fd restricted to the memory types `vkGetMemoryFdPropertiesKHR` reports as compatible.

**Shared fences** follow the same pattern over opaque-fd timeline semaphores. Create an `ID3D11Fence` with `D3D11_FENCE_FLAG_SHARED`, export it with `ID3D11Fence::CreateSharedHandle` (yielding a `DxvkSharedFenceDescriptor*`), and import it in the other process with `ID3D11Device5::OpenSharedFence`. Values signaled on one device are then observed on all. Opaque fds require the **same Vulkan driver** on both ends.

**Ownership.** On export, the descriptor and its fd are owned by the exporting texture/fence and stay valid until that object is destroyed — do not free the descriptor or close the fd; `dup()` the fd to let it outlive the exporter. On import, DXVK reads the descriptor and `dup()`s the fd synchronously during the call, so the caller may release both as soon as it returns.

### Win32 event handle compatibility (`SetEvent` / `HEVENT`)

On native Linux builds, the Win32 `HANDLE`-based event API (`SetEvent`, `CreateEvent`, etc.) is shimmed in `src/util/util_win32_compat.h`. The `SetEvent` implementation treats the `HANDLE` as a Linux `eventfd(2)` file descriptor cast to `HANDLE` and writes a single 8-byte counter increment to it:

```cpp
inline BOOL SetEvent(HANDLE hEvent) {
  const uint64_t one = 1;
  return ::write(static_cast<int>(reinterpret_cast<intptr_t>(hEvent)),
                 &one, sizeof(one)) == static_cast<ssize_t>(sizeof(one));
}
```

Callers that need event signaling on Linux can create an `eventfd(0, EFD_CLOEXEC)`, cast the fd to `HANDLE`, and pass it to methods like `ID3D11Fence::SetEventOnCompletion` or `ID3D11DeviceContext3::Flush1`. When DXVK fires `SetEvent(hEvent)`, the eventfd becomes readable via `poll(fd, POLLIN)`, allowing the caller to detect completion without platform-specific threading.

If the `HANDLE` is not a valid writable file descriptor, the `write` call fails silently and returns `FALSE`, preserving the previous stub behavior for callers that do not use the eventfd convention.