D8VK translates Direct3D 8 to Vulkan, just like DXVK for Direct3D 9 / 10 / 11 and VKD3D-Proton for Direct3D 12 used with Wine and Proton on Linux and Steam Deck. Fantastic to see the progress on this. I reported on an earlier release, but now the "production-ready" 1.0 is available for you to play with.
In the release notes the developer mentioned "This is the first production-ready release of d8vk that has been tested against many hundreds of games with better performance and compatibility than is possible with WineD3D or d3d8to9".
The developer also included a bunch of benchmarks in 3DMark 2001 SE to show the differences in performance between different translations:
Implementation | WineD3D | d3d8to9 + dxvk (2.1) | d8vk |
---|---|---|---|
Score | 97134 | 118033 | 144660 |
Car Chase - Low | 1409.1 fps | 2075.5 fps | 2017.5 fps |
Car Chase - High | 352.1 fps | 148.9 fps | 553.8 fps |
Dragothic - Low | 1510.4 fps | 1853.3 fps | 2016.9 fps |
Dragothic - High | 807.6 fps | 792.3 fps | 1167.4 fps |
Lobby - Low | 1278.5 fps | 1528.5 fps | 1545.7 fps |
Lobby - High | 585.6 fps | 523.3 fps | 778.4 fps |
Nature | 1012.4 fps | 1708.6 fps | 1943.4 fps |
Fill Rate - Single Texture | 80163.2 MTexels/s | 64208.1 MTexels/s | 62904.5 MTexels/s |
Fill Rate - Multitexturing | 159903.7 MTexels/s | 97900.4 MTexels/s | 96772.7 MTexels/s |
High Poly Count (1 light) | 1335.1 MTris/s | 2217.0 MTris/s | 2375.5 MTris/s |
High Poly Count (8 lights) | 1267.6 MTris/s | 2092.4 MTris/s | 1853.5 MTris/s |
Environment Bump Mapping | 526.9 fps | 1430.8 fps | 2333.4 fps |
DOT3 (Normal) Mapping | 2025.1 fps | 1608.9 fps | 2331.6 fps |
Vertex Shader | 727.2 fps | 788.7 fps | 846.9 fps |
Pixel Shader | 1220.9 fps | 1059.8 fps | 1337.1 fps |
"Advanced" Pixel Shader | 4066.1 fps | 2808.6 fps (broken) | 2544.7 fps |
Point Sprites | 1193.9 MSprites/s | 1071.4 MSprites/s | 987.5 MSprites/s |
So clearly there's a few cases where D8VK is beaten but for an initial 1.0 release, this is a very good show for it. Hopefully it can continue to see upgrades over time too, so that we can all enjoy even more classics with great performance across Linux desktop and Steam Deck.
The main changes in v1.0:
Changes
- Single combined
d3d8.dll
(d3d9 is statically linked)- New custom batcher for certain drawcall-heavy games
- Support overriding vertex shader declaration for games with undefined behavior
- Vertex buffers may now be stored in the managed pool automatically for improved performance and to prevent write ordering issues
- Implemented
bem
instruction- Support compiling on MSVC
- Correct surface desc sizes based on format
- State block types are now supported and should capture the relevant state
- Allow preserving current Proton installation by @Sid127 in #51
- Support GetInfo queries
- Countless game-specific configurations and minor features and tweaks
Bug Fixes
- Fixed a bug where CreateTexture would try to wrap a null texture
- Always use at least one backbuffer by @WinterSnowfall in #91
- Fixed backbuffers not being cached or referenced by the owning device
- Fixed textures, streams, and indices not clearing on reset
- Red Faction: Disable direct buffer mapping by @WinterSnowfall in #96
- Fixed location of Direct3DCreate8 in d3d8.def
- Fixed ref counting for rendertargets, depth stencils, and textures.
- Fixed null pixel shaders not being remembered
- Fixed rendertargets and depth stencils not being cached
- Fixed error if the client tries to enable SWVP on a hardware device
- Fixed devices not being freed
- Fixed segfault on freeing device with bound textures
- Countless other fixes...
See more on the GitHub.
In my tests run very well
and run some interesting demos with d8vk 1.0:
Respect older version them stay working on this
Quotehttps://github.com/AlpyneDreams/d8vk/tree/d3d7
and have avalaible artifacts too here
Quotehttps://github.com/AlpyneDreams/d8vk/actions/runs/4937050854
but dont work in my case, i try testing eracer from rage software and divine divinity
Last edited by mrdeathjr on 13 May 2023 at 9:30 am UTC
A lot of games got updates that ported them to DX9 to keep them playable.
I hope this gets merged with DXVK (seems cooperative)
Quoting: GroganAwesome, I've not yet run into a DirectX 8 game, but I wondered how it would be if I ever did. I just assumed it wouldn't matter, for such old games the CPU overhead of WineD3D would be OK.On Proton at least, there doesn't seem to be much issue. I played Trails in the Sky FC just fine with the DX8 version -- it went better than using the DX9 with the mods, in fact. Of course, that's a really simple game, and I'd like to see how well this one works. Also, audio for movies was broken for some reason, not sure if it's a codec issue or issue with DX8 games on Linux.
A lot of games got updates that ported them to DX9 to keep them playable.
I hope this gets merged with DXVK (seems cooperative)
Quote3DMark 2001 SEWow that was a blast from the past.
Quoting: GroganAwesome, I've not yet run into a DirectX 8 gameEverything is fine until you find an overly specific rendering bug making playing it impossible in Wine 👴
Luckily, dgVoodoo2 dll files often help: http://dege.freeweb.hu/dgVoodoo2/
Quoting: fenglengshunAlso, audio for movies was broken for some reason, not sure if it's a codec issue or issue with DX8 games on Linux.
mfplat wine implementation attacking again but in last 6 months them stay working on that
thanks to that some h.264 playback begin work and some wmv too, but need more work specially with wmv audio format like wmapro (used in many cinematics)
however this weeks appear various commits around wmv (winegstreamer)
Quotewinegstreamer: Use codec format in stream_props_GetMediaType.
winegstreamer: Implement amt_from_wg_format_video_wmv.
winegstreamer: Implement wg_parser_stream_get_codec_format.
winegstreamer: Introduce format_is_compressed.
winegstreamer: Remove unnecessary media source stream states.
winegstreamer: Synchronize access to the media source from callbacks.
winegstreamer: Synchronize concurrent access to the media stream.
winegstreamer: Only break cyclic references in IMFMediaSource_Shutdown.
winegstreamer: Keep a IMFMediaSource pointer in the media stream.
winegstreamer: Query the wg_parser stream in media_stream_create.
mfplat/buffer: Implement IMF2DBuffer::ContiguousCopyTo().
mfplat/tests: Test IMF2DBuffer::ContiguousCopyTo().
mfplat/buffer: Implement IMF2DBuffer::ContiguousCopyFrom().
This is a generic implementation, which is probably fine for buffers
backed by system memory. The implementation for buffers backed by
GPU memory can probably be optimized.
mfplat/tests: Test IMF2DBuffer::ContiguousCopyFrom().
mfplat/tests: Test large RGB image formats.
mfplat/buffer: Support YV12, I420 and IYUV image formats.*** (this personally think can solve some issues respect color in some h264 like elderborn or greak)
mfplat/buffer: Use the appropriate image copy function for NV11.
mfplat/tests: Push image size and format as context.
mfplat: Implement MFCreatePathFromURL().
quartz: Check whether the pin is connected in IBasicVideo::GetVideoSize().
winegstreamer: Create media source presentation descriptor as needed.
winegstreamer: Keep a stream descriptor array on the media source.
winegstreamer: Avoid eating errors in media source async commands.
winegstreamer: Simplify media source wait_on_sample control flow.
winegstreamer: Start media streams in a dedicated media_stream_start helper.
winegstreamer: Use helpers to convert stream descriptor type to wg_format.
winegstreamer: Avoid potential leak of media source async commands.
winegstreamer: Return a IUnknown pointer from source_create_async_op.
mfplat/tests: Add another test for MFCopyImage().
maybe this friday wine 8.8 can be interesting in this area, in my case waiting for staging 8.8 in some point of this weekend
almost forget maybe *** can help you Avehicle7887
Last edited by mrdeathjr on 11 May 2023 at 1:31 pm UTC
Quoting: GroganI hope this gets merged with DXVK (seems cooperative)
https://github.com/doitsujin/dxvk/pull/3411
See more from me