Vulkan 1.0 goes official

[toneddu2000]

making a batch file with

Code: Select all

fteqw64.exe +setrenderer vk

makes the engine crash. Same thing if set ingame.
my new (but used) card is gtx970 4gb

Interesting (but crappy) stuff is that new card has more or less same performance on my game projectUnknown with just one dynamic light.(first 50/60 fps, now 110fps)
With this card now I can play DOOM demo with everything at ultra detail at 60fps stable, what the heck!

[toneddu2000]

no, my fault. My game directory uses shaders vulkan fte doesn't like. A simple directory with just maps and defaultwall shader works. Realtime lights don't work anyway

[toneddu2000]

no, my fault. My game directory uses shaders vulkan fte doesn't like. Even glsl postprocessing. A simple directory with just maps and defaultwall / rtlights shaders works.
No huge performance boost, by the way (opengl 80fps - vulkan 110fps)

r_bloom doesn't work right and r_fxaa (antialiasing) makes the texture like nintendo 8 bit pikels!
But it's a great start, Spike! Thanks for your hard work!!

[Spike]

vulkan requires precompiled spirv blobs instead of glsl. fte's glsl renderer does try to take advantage of an nvidia extension to use glsl directly, but it doesn't support any permutations, so its kinda only useful for 2d stuff, like post-processing effects. shouldn't crash though. :/

I thought bloom+fxaa were working now, but I guess I screwed something up with barriers (I was a little lazy and just went with what worked for me rather than going through it in great detail, so it doesn't exactly surprise me if you get glitches).

there's also some weird performance issues with vulkan, like 1920*1080 getting only half the framerate of d3d9, despite the vulkan renderer just clearing the screen with the d3d9 renderer drawing the entire world... but oh well... vulkan copes better with lower resolutions at least.

[toneddu2000]

Sorry for the very late reply Spike

vulkan requires precompiled spirv blobs instead of glsl. fte's glsl renderer does try to take advantage of an nvidia extension to use glsl directly, but it doesn't support any permutations, so its kinda only useful for 2d stuff, like post-processing effects.

Wow, thanks Spike, didn't know of Spir-V at all, start digging into!
Unfortunately I tried a very simple csqc postprocessing effect (add a vec4 col to GL_FragColor) but it doesn't take effect

I thought bloom+fxaa were working now, but I guess I screwed something up with barriers (I was a little lazy and just went with what worked for me rather than going through it in great detail, so it doesn't exactly surprise me if you get glitches).

Well, I made some errors. Bloom do works, but fxaa not. (At least bloom is safe!)

there's also some weird performance issues with vulkan, like 1920*1080 getting only half the framerate of d3d9, despite the vulkan renderer just clearing the screen with the d3d9 renderer drawing the entire world... but oh well... vulkan copes better with lower resolutions at least.

But, is it a peculiarity of Vulkan itself or is it regarding only FTEQW implementation?
Because in latter case, there's margin of improvements, in the first case, Vulkan will be very useless!

[Spike]

I think you need to use rendertargets, and NOT the $currentrender thing (grabbing a copy of the current framebuffer isn't going to be any faster with vulkan, and probably actually a bit slower due to much lazier (ie: none) optimisations for it).
also needs 'vk_loadglsl 1' set (when doing vid_restart) in order to enable the glsl-in-vulkan extension. be sure you're not using any debug layers at the time, because they'll probably crash... yeah, loading glsl isn't really a standard thing.
the spir-v that fte normally uses is directly embedded into the engine like the default glsl shaders are. I have some script to generate a c header file with the various blobs included for each shader language, using system-specific paths to the 3rd-party vulkan tools ('glslangvalidator'), and with an outdated version of the tools in order to avoid validation errors and driver crashes... the vertex+fragment shaders are merged into a single blob with an internal fte-specific header to deal with permutations+specialisations+3rdparty bugs, which kinda makes the whole thing a mess.
so no, fte does not officially try to support custom spir-v blobs right now. I expect you can generate one anyway, but don't expect it to be easy in any way, nor still work with the next revision too.
that reminds me, I really ought to rewrite some shader stuff some time... and not just for vulkan. don't worry, I'm sure I'll forget about it again soon.

regarding fxaa, I probably hardcoded the res or something lame. I could have sworn it was working for me.
bloom seemed to cause the framerate to seriously plummet in linux. windows didn't suffer nearly as much. I've no idea what was going on there, but like I said, I skipped some barriers.

regarding fullscreen performance, if you check the pipeline cache files from nvidia implementations, you can find some fragments of a variation on pre-glsl arb programs (ie: asm). it looks like it uses streamed ubos containing indirections (read: pointers) to the actual ubos.
so that's two extra levels of indirection for each shader invocation, which isn't needed with opengl. which also kills an entire class of optimisations that mobile vendors promote quite heavily too (though I've no idea if it affects desktop gpus much with all their spare cache).
so yeah, I'm going to say its a driver issue, rather than my fault. either way I've given up on trying to optimise it.
if you've a low resolution or a thousand draw calls then vulkan is a win. if you're quake, then it'll probably have lower performance at high resolutions than d3d and probably opengl too. either way, it'll probably still average above 1000fps, so who really cares? other than pedantic obsessives, that is... alright, so half my target players... fine, you win. GAH. just stick with d3d9 (on windows) if you want silly framerates.

[toneddu2000]

if you've a low resolution or a thousand draw calls then vulkan is a win. if you're quake, then it'll probably have lower performance at high resolutions than d3d and probably opengl too. either way, it'll probably still average above 1000fps, so who really cares? other than pedantic obsessives, that is... alright, so half my target players... fine, you win. GAH. just stick with d3d9 (on windows) if you want silly framerates.

No I asked you because I made some experiments with some games and I show them to you:

1. (i7 octa core, 6gb of ram, gtx970 4 gb)
2. DOOM - opengl / Vulkan: 60fps both at ultra detail
3. Quake DOPA by Machine Games - opengl [20fps - 50fps] Vulkan [60fps - 200fps] with all dynamic lights, bloom, etc. enabled. This is the game where Vulkan shows the muscles. There are scenes where openGL litterally hangs down to 20fps, making game unplayable. With Vulkan, instead, fps don't go never under 50-60fps, which it's cool
4. My own game projectUnknown - opengl [about 200/400fps ] Vulkan [about 150/200fps] with no gamecode with a map without lightmaps. Using a map with lightmaps, makes Vulkan exe to discard diffuse textures, even if scripts are washed out. I tried to open final map (with high quality 2048 px lightmaps, lots of static models, etc.) shown in the video trailer but Vulkan crashes, so I can't compare final map with lightmaps but I guess it'd discard diffuse textures anyway. And Vulkan gets beaten a lot by openGL. Very wierd...
5. Another game of my own with no lightmaps but only one dynamic light - opengl [about 110 fps] Vulkan [about 110 fps]. Here textures are visible and correct rendered, probably because there's no lightmaps in maps. A perfect tie, though, but no performance boost for Vulkan.

Postprocess on Vulkan will crash anyway. Bloom works, r_fxaa not.

I'm interested in Vulkan only because, we have huge performance drops with FTE using lots of dynamic lights and using Vulkan seemed to me a good idea to pump up framerate a little

I think you need to use rendertargets, and NOT the $currentrender thing (grabbing a copy of the current framebuffer isn't going to be any faster with vulkan, and probably actually a bit slower due to much lazier (ie: none) optimisations for it).
also needs 'vk_loadglsl 1' set (when doing vid_restart) in order to enable the glsl-in-vulkan extension. be sure you're not using any debug layers at the time, because they'll probably crash... yeah, loading glsl isn't really a standard thing.

I was making a mistake with GLSL postprocessing. Now I fixed it and Vulkan crashes. I DO use rendertargets. Tried also vk_loadglsl 1 but it crashes anyway.

the spir-v that fte normally uses is directly embedded into the engine like the default glsl shaders are. I have some script to generate a c header file with the various blobs included for each shader language, using system-specific paths to the 3rd-party vulkan tools ('glslangvalidator'), and with an outdated version of the tools in order to avoid validation errors and driver crashes... the vertex+fragment shaders are merged into a single blob with an internal fte-specific header to deal with permutations+specialisations+3rdparty bugs, which kinda makes the whole thing a mess.
so no, fte does not officially try to support custom spir-v blobs right now. I expect you can generate one anyway, but don't expect it to be easy in any way, nor still work with the next revision too.

Well, I'll need at least another year to learn SPIR-V!

don't worry, I'm sure I'll forget about it again soon.