Vulkan support
Re: Vulkan support
yes I was thinking about normal on terrain, I added them when implementing dynamic lighting. When Vulkan branch get merged I can start to import dynamic lighting related code again.
BTW there should be some appveyor generated installer for the vulkan branch soon.
BTW there should be some appveyor generated installer for the vulkan branch soon.
Re: Vulkan support
Do you have a normal map (in tangent space) for the terrain of the main map of campaign alpha ? Something crude, I need a map to check that everything works correctly.MaNGusT wrote: As for the terrain, yeah, I think we could generate normals at load time and place all map's tris in one smooth group (no sharp edges). When I will get a test build whith these improvements, I can start to work on terrain normal maps.
When I was creating current diffuse textures for terrain, I did some experiments in editor with normal maps, looked awesome and was easy for me to edit them in a 2d software.
Re: Vulkan support
Hmm. I could make one, but I need to know directions of +-xyz(rgb). I could make a texture with a classic directions, btw.Vincent wrote:Do you have a normal map (in tangent space) for the terrain of the main map of campaign alpha ? Something crude, I need a map to check that everything works correctly.
![Pensive :hmm:](./images/smilies/icon_pensive.gif)
I think 1-2 textures will be enough for your tests.
Re: Vulkan support
The 1st one. Just for your tests, not final.
Sorry, it's not that fast to create NM from diffuse maps that will look good enough.
I will make and upload two more textures later. It can be normalized to reduce the strangeness of a bump effect.
Sorry, it's not that fast to create NM from diffuse maps that will look good enough.
I will make and upload two more textures later. It can be normalized to reduce the strangeness of a bump effect.
- moltengear
- Trained
- Posts: 170
- Joined: 22 Jul 2017, 15:05
Re: Vulkan support
it seems to me that it would be nice to create a 4th version of the pie format.
It would be nice if there was a numeric identifier, not just the name of the texture.
Does the texture need a full range of transparency? + normal vectors.
It would be nice if there was a numeric identifier, not just the name of the texture.
Does the texture need a full range of transparency? + normal vectors.
Re: Vulkan support
I'm a bit busy atm so I didn't make any progress but I'm still interested in the feature
Re: Vulkan support
Picking up on this, I've been working with Vincent's gfx_api and Vulkan backend patches (rebased on the current master branch, with refactoring, fixes, and enhancements). Some help testing would be greatly appreciated.
For anyone running Windows, here are new (beta) Vulkan-supporting builds:
New Builds (2019-07-13a)
Full Installer (Windows x86): https://ci.appveyor.com/api/buildjobs/b ... taller.zip
Portable Build (Windows x86): https://ci.appveyor.com/api/buildjobs/b ... rtable.zip
To start with the Vulkan backend, run:
warzone2100.exe --vulkan
To enable additional 3D-graphics-related logging, use:
warzone2100.exe --vulkan --debug=3d
(We'll need this extra logging information if you have any issues.)
(IMPORTANT: These builds default to the OpenGL backend if --vulkan is not specified. They support both the existing OpenGL backend and the new Vulkan backend.)
You will, of course, need a graphics card & drivers that support Vulkan. (Vulkan 1.0 support should be all that's required.)
I'm very curious about any feedback. Does it work / not work on your system? How does the performance compare to the (default) OpenGL backend?
The changes since vlj's original Vulkan patch are too many to list, but the highlights are:
- Support the changed gfx_api interface (and other WZ changes since vlj's original patch)
- Require only C++11
- Limit requirements to the "Vulkan Portable Subset"
- Compile on all supported compilers
- Work on non-Windows platforms, in addition to Windows
- Use dynamic loading of Vulkan APIs / libraries
- Support the new backend_Impl_Factory
- Handle many more recommended practices for initializing Vulkan
- Handle systems with multiple GPUs
- Query and handle instance / device / etc features, extensions and limits
- Provide more comprehensive device selection / surface creation / initialization (etc)
- Handle separate graphics and presentation queues
- Handle swapchain minImageCount / maxImageCount
- Handle *many* more error conditions (ex. re-creating swapchain, lost surface)
- Support live window resizing
- Restructure the render pass (and barriers / related)
- Fix bugs / restructure based on the latest Vulkan validation layers
- Rebuild graphics pipelines if necessary
- Handle generating mipmaps
- Handle cleanup and shutdown (and destroying resources in the proper order)
- Clamp drawableSize to VkSurfaceCapabilitiesKHR minImageExtent / maxImageExtent
- Use Vulkan Memory Allocator
- Run on MoltenVK (Vulkan -> Metal)
- Support Multisample Anti-aliasing (MSAA)
Some things that currently don't work in Vulkan mode:
- Toggling vsync (vsync is always enabled)
- Built-in screenshot support
- Using the debug-mode "Make a performance measurement sample" key binding
Some differences in Vulkan mode:
- "Fullscreen" is the so-called "borderless windowed fullscreen" / "fullscreen desktop" mode, instead of the classic / old-fashioned "exclusive" full-screen. As such, the fullscreen resolution will always be the same as your desktop resolution. If you'd like to change the size at which the UI (etc) renders, use the "Display Scaling" option in the Video Options menu.
- Mods that use custom shaders will not load the custom shaders (ex. ArtRev mod). They will need to be updated to also provide Vulkan shaders (instructions coming in the future).
EDIT:
Compiling notes:
For anyone running Windows, here are new (beta) Vulkan-supporting builds:
New Builds (2019-07-13a)
Full Installer (Windows x86): https://ci.appveyor.com/api/buildjobs/b ... taller.zip
Portable Build (Windows x86): https://ci.appveyor.com/api/buildjobs/b ... rtable.zip
To start with the Vulkan backend, run:
warzone2100.exe --vulkan
To enable additional 3D-graphics-related logging, use:
warzone2100.exe --vulkan --debug=3d
(We'll need this extra logging information if you have any issues.)
(IMPORTANT: These builds default to the OpenGL backend if --vulkan is not specified. They support both the existing OpenGL backend and the new Vulkan backend.)
You will, of course, need a graphics card & drivers that support Vulkan. (Vulkan 1.0 support should be all that's required.)
I'm very curious about any feedback. Does it work / not work on your system? How does the performance compare to the (default) OpenGL backend?
The changes since vlj's original Vulkan patch are too many to list, but the highlights are:
- Support the changed gfx_api interface (and other WZ changes since vlj's original patch)
- Require only C++11
- Limit requirements to the "Vulkan Portable Subset"
- Compile on all supported compilers
- Work on non-Windows platforms, in addition to Windows
- Use dynamic loading of Vulkan APIs / libraries
- Support the new backend_Impl_Factory
- Handle many more recommended practices for initializing Vulkan
- Handle systems with multiple GPUs
- Query and handle instance / device / etc features, extensions and limits
- Provide more comprehensive device selection / surface creation / initialization (etc)
- Handle separate graphics and presentation queues
- Handle swapchain minImageCount / maxImageCount
- Handle *many* more error conditions (ex. re-creating swapchain, lost surface)
- Support live window resizing
- Restructure the render pass (and barriers / related)
- Fix bugs / restructure based on the latest Vulkan validation layers
- Rebuild graphics pipelines if necessary
- Handle generating mipmaps
- Handle cleanup and shutdown (and destroying resources in the proper order)
- Clamp drawableSize to VkSurfaceCapabilitiesKHR minImageExtent / maxImageExtent
- Use Vulkan Memory Allocator
- Run on MoltenVK (Vulkan -> Metal)
- Support Multisample Anti-aliasing (MSAA)
Some things that currently don't work in Vulkan mode:
- Toggling vsync (vsync is always enabled)
- Built-in screenshot support
- Using the debug-mode "Make a performance measurement sample" key binding
Some differences in Vulkan mode:
- "Fullscreen" is the so-called "borderless windowed fullscreen" / "fullscreen desktop" mode, instead of the classic / old-fashioned "exclusive" full-screen. As such, the fullscreen resolution will always be the same as your desktop resolution. If you'd like to change the size at which the UI (etc) renders, use the "Display Scaling" option in the Video Options menu.
- Mods that use custom shaders will not load the custom shaders (ex. ArtRev mod). They will need to be updated to also provide Vulkan shaders (instructions coming in the future).
EDIT:
Compiling notes:
- Only the CMake build toolchain (currently) supports the Vulkan backend
- You will likely want to install the Vulkan SDK. See: https://vulkan.lunarg.com/sdk/home
- Some distros may have a package for this, but you will need both: (a) recent Vulkan SDK headers, and (b) glslc (to compile the shaders)
- SDL2 must be compiled with Vulkan support enabled. Some Linux distros (especially older releases) compile SDL2 without Vulkan support - to fix, you'll need to compile SDL2 from source (and make sure Vulkan support is enabled)
Last edited by pastdue on 13 Jul 2019, 15:16, edited 5 times in total.
Re: Vulkan support
ubuntu 18.04, nvidia 1050ti, driver nvidia-430
git hash 2c70abf6810ba26149516f260b35ad3448c93e71
compile without error.
if start
git hash 2c70abf6810ba26149516f260b35ad3448c93e71
compile without error.
if start
Code: Select all
./src/warzone2100 --vulkan
Code: Select all
error "Warzone was not compiled with the Vulkan backend enabled. Aborting."
vaut ΣΑ [GN], ru streamer.
Tournaments channel: https://www.youtube.com/channel/UCzusNa-54ydodtSz2TdHFww
Tournaments channel: https://www.youtube.com/channel/UCzusNa-54ydodtSz2TdHFww
Re: Vulkan support
@andrvaut: I added some compiling tips above. (You'll need to use the CMake build toolchain for now, and you'll have to ensure that the SDL2 library was compiled with Vulkan support enabled.)
- Berserk Cyborg
- Code contributor
- Posts: 938
- Joined: 26 Sep 2016, 19:56
Re: Vulkan support
Yo, this is pretty slick! I tested the linked build on Windows 10 (upgraded to the latest graphics driver available). Can't say I see much wrong. Performance was good.
I get this a few times. It can can be reproduced by opening the debug menu or by keeping the research window open.
- The research bar's yellow "progress bar" is on top of the timers (but not for ally research).
- Minimap trapezoid "viewing window" is a bit too opaque.
- Minimap is really blurry.
Code: Select all
info |17:24:46: [VkBuf::update:1279] Attempt to upload to buffer more than once per frame
info |17:24:46: [VkBuf::update:1279] Assert in Warzone: C:\projects\warzone2100\lib\ivis_opengl\gfx_api_vk.cpp:1279 (flag == update_flag::non_overlapping_updates_promise || (lastUploaded_FrameNum != current_FrameNum)), last script event: '<none>'
- The research bar's yellow "progress bar" is on top of the timers (but not for ally research).
- Minimap trapezoid "viewing window" is a bit too opaque.
- Minimap is really blurry.
Re: Vulkan support
Thank you for testing! If you have a chance, I'm very interested in performance comparisons vs. the default OpenGL mode. (I like to start a New Campaign - Beta Campaign, and zoom out all the way to get a fairly consistent sample with a decent amount going on.)Berserk Cyborg wrote: ↑13 Jul 2019, 00:52 Yo, this is pretty slick! I tested the linked build on Windows 10 (upgraded to the latest graphics driver available). Can't say I see much wrong. Performance was good.
Note: Vulkan anti-aliasing will differ from OpenGL anti-aliasing in implementation, so I'm also curious about performance with anti-aliasing on and off for both.
Thank you. If you find any other ways of triggering that assert, please let me know. (Have already fixed a bunch.)Berserk Cyborg wrote: ↑13 Jul 2019, 00:52I get this a few times. It can can be reproduced by opening the debug menu or by keeping the research window open.Code: Select all
info |17:24:46: [VkBuf::update:1279] Attempt to upload to buffer more than once per frame info |17:24:46: [VkBuf::update:1279] Assert in Warzone: C:\projects\warzone2100\lib\ivis_opengl\gfx_api_vk.cpp:1279 (flag == update_flag::non_overlapping_updates_promise || (lastUploaded_FrameNum != current_FrameNum)), last script event: '<none>'
Do those issues go away with the same build when running in OpenGL mode (without --vulkan specified)? There's a lot of additional gfx_api wrapping work in these builds, so it's possible some of those issues could be a result of that. (In fact, the minimap one might be is related to texture filtering.)Berserk Cyborg wrote: ↑13 Jul 2019, 00:52- The research bar's yellow "progress bar" is on top of the timers (but not for ally research). [Fixed build soon.]
- Minimap trapezoid "viewing window" is a bit too opaque. [Fixed build soon.]
- Minimap is really blurry. [Fixed build soon.]
Last edited by pastdue on 13 Jul 2019, 13:27, edited 1 time in total.
- Berserk Cyborg
- Code contributor
- Posts: 938
- Joined: 26 Sep 2016, 19:56
Re: Vulkan support
FWIW, The Vulkan backend is able to maintain 60 FPS at 100x speed(?), for OpenGL it drops to 18 and everything starts flashing and unit movement is jittery. With Vulkan everything more or less stays smooth. Antialiasing (I can get up to 8x) doesn't appear to have any negative performance impact, using both backends. According to the FPS counter, anyway. And, if I had to "eyeball it" then it would hold true.pastdue wrote: ↑13 Jul 2019, 01:00 Thank you for testing! If you have a chance, I'm very interested in performance comparisons vs. the default OpenGL mode. (I like to start a New Campaign - Beta Campaign, and zoom out all the way to get a fairly consistent sample with a decent amount going on.)
Note: Vulkan anti-aliasing will differ from OpenGL anti-aliasing in implementation, so I'm also curious about performance with anti-aliasing on and off for both.
However, using Fullscreen (1920x1080), the Vulkan backend drops to 30 FPS and 100x speeds drop down to 12 FPS and it gets laggy and flashy like the OpenGL backend.
The research time using Vulkan turns non-bold and gets obscured by the bar. OpenGL displays it correctly.pastdue wrote: ↑13 Jul 2019, 01:00 Do those issues go away with the same build when running in OpenGL mode (without --vulkan specified)? There's a lot of additional gfx_api wrapping work in these builds, so it's possible some of those issues could be a result of that. (In fact, the minimap one might be is related to texture filtering.)
- WZ2100ModsFAn
- Trained
- Posts: 371
- Joined: 15 Apr 2018, 17:25
- Location: United States.
Re: Vulkan support
Starting er up with the vulkan API worked perfectly when showing in game and in the main menu.pastdue wrote: ↑12 Jul 2019, 21:37 Picking up on this, I've been working with Vincent's gfx_api and Vulkan backend patches (rebased on the current master branch, with refactoring, fixes, and enhancements). Some help testing would be greatly appreciated.
For anyone running Windows, here are new (beta) Vulkan-supporting builds:
Full Installer (Windows x86): https://ci.appveyor.com/api/buildjobs/j ... taller.zip
Portable Build (Windows x86): https://ci.appveyor.com/api/buildjobs/j ... rtable.zip
To start with the Vulkan backend, run:
warzone2100.exe --vulkan
Re: Vulkan support
I've updated the post above with new builds (2019-07-13a).
These builds should fix:
- Add more debug logging
- Improve selection of the surface format (fixes an issue reported by Berg that could result in the entire interface being too "light" / washed-out)
- Improve some error messaging around backend initialization
You'll still see the occasional "Attempt to upload to buffer more than once per frame" assert (haven't gotten to all of those yet).
These builds should fix:
Additionally, they:Berserk Cyborg wrote: ↑13 Jul 2019, 00:52 - The research bar's yellow "progress bar" is on top of the timers (but not for ally research).
- Minimap trapezoid "viewing window" is a bit too opaque.
- Minimap is really blurry.
- Add more debug logging
- Improve selection of the surface format (fixes an issue reported by Berg that could result in the entire interface being too "light" / washed-out)
- Improve some error messaging around backend initialization
You'll still see the occasional "Attempt to upload to buffer more than once per frame" assert (haven't gotten to all of those yet).