About experimental features in QZDoom

[Graf Zahl]

This is in response to BoA adding some postprocessing shaders and making the mod incompatible with current GZDoom.

QZDoom may add features GZDoom does not have, like currently the postprocessing shaders.

If you want to use such features in your mod you always have to be careful! QZDoom calls itself experimental for good reasons. Even if those features may look interesting, there is no guarantee that they may get integrated into GZDoom's mainline, and even less guarantee that they get integrated in exactly the same way as written. It may later be decided that those features may require some changes to work better for both technical and usability reasons.

Unless I have given a clear comment about any such feature they must be considered unstable or incomplete. In the case of those shaders I haven't even reviewed the code yet so I cannot tell how they will be handled.

If you decide to release a mod with such a feature it may easily end up compatible only with the single QZDoom version it was developed against because if GZDoom alters the feature, so will most likely all future QZDooms as well.

[Rachael]

QZDoom exists as a fork for a reason. Unless there is a very good reason, I will not allow changes that will break compatibility like that.

This is a feature that people have been wanting for a long time - and that you have been vocally against. We responded to that demand - simple as that (actually - because we wanted it, too). And the purpose of 2.0.0 was quite plainly to finalize the GLDEFS format for this feature. If you want it for GZDoom you may take it, we have nothing against that - but in this case, we do consider at least the invocation of this particular feature mostly final.

[Graf Zahl]

but in this case, we do consider at least the invocation of this particular feature mostly final.

The main problem here is that I cannot say yet if this needs some changes for Vulkan and I won't act on it until I am starting to work on that. Unfortunately, due to budget constraints I cannot buy the new graphics card I need for that until early September so it's still some time off.

For the same reason I have been holding back a more extensive shader generalization feature I've already been working on. I know I can make it work with OpenGL but the way I initially designed it will need some change in Vulkan.

[Rachael]

The cat's already out of the bag, and has been for quite a few years now. How are you going to handle fragment shaders? Some compatibility code will already need to be in place just to handle that, and that is a very long-time GZDoom feature itself. Doing the PP shaders in addition to that will be much the same deal.

And I would STRONGLY urge against allowing Vulkan-specific PP shaders unless you can force them to be open-source. That was one of the reasons for allowing GLSL shaders in their current implementation, at least from my view.

At any rate, even if we have to change the GLDEFS format (ugh!) Torm only put in one shader. It's still easy to change at this point, at least for him.

[Graf Zahl]

Take one guess why I never expanded the feature set of the texel fetching hardware shaders. The thing is, right now I simply do not know what needs to be done to make the transition so working right at the critical points of the shader interface (like adding the postprocessing shaders) is something I put on the back burner until it becomes more clear.

Regarding GLDEFS, I've been thinking about deprecating that lump as it's a mess and replace it with something better defined. Most of it was inherited from ZDoomGL and it contains too much code only present to parse over unimplemented content, which is always bad.

In any case, that's not the point about this post, but that the assumption "It's present in QDoom so it will be available in GZDoom later hence it's safe to use" may cause unexpected trouble if things do not pan out for whatever unforeseen reason.

[Rachael]

Graf - I respect you a lot - you are a great programmer, and you are the real reason ZDoom has survived as it has to this day.

But features cannot always depend on one person's hardware. You have two developers that are already capable of running Vulkan on their systems, and if you ask nicely I'll even give you remote access to my own (I have to be away from the computer a lot the next two weeks as it is, anyway).

One of the motivations behind adding those PP shaders is because GZDoom was stagnating as it was. It's a feature we wanted - it's a feature we discussed quite a lot before adding it - and finally, we decided to put it in. As for Vulkan support - we didn't think anything was even going to happen, on that, because it was so little discussed and nothing happened on it even when it was. It would require a significant rewrite of many core parts of the renderer in order to even support it. As it was, the PP shaders feature has been out and discussed for quite a lot - you hardly, if ever, gave any feedback on it until now, when a major project starts to make use of it. And NOW it becomes an issue?

Supporting what will essentially be an additional renderer, at this point, is a pretty shaky prospect by itself. I have no doubt that if anyone can pull that off, you can - but even still, that's a LOT of different code that in the end will all be doing much the same thing: presenting some sort of 2.5D map on the screen. Counting all the code paths and compatibility, we have what is essentially 5 (maybe 6?) different renderers already. But hey, what's one more, eh?

Another thing that I think does not get a lot of consideration is besides the obvious performance advantages (which probably won't improve common major CPU chokes like 20000 2-sided linedefs in a single scene), what are the real benefits to moving to Vulkan? What does it support that OpenGL does not, and will that be critical in the future?

A lot of the "issue" here is - it takes a very long time sometimes for features to be reviewed and accepted into GZDoom, if they are at all. QZDoom is a fork that enjoys some degree of independence from that situation, that in the end we've decided we'd rather not deal with. We didn't want to force you to take our features - nor did we want to make you feel like you had to take them - if you don't want it, don't take it, simple as that. It will continue to exist in QZDoom, one way or another, though. This is NOT to say you *have* to be more active in reviewing code in GZDoom - it's only to say that it's a reason why we moved forward with it in QZDoom, so you don't have to.

[nazakomu]

Another thing that I think does not get a lot of consideration is besides the obvious performance advantages (which probably won't improve common major CPU chokes like 20000 2-sided linedefs in a single scene), what are the real benefits to moving to Vulkan? What does it support that OpenGL does not, and will that be critical in the future?

I myself am definitely not the most knowledgeable on the subject of Vulkan versus OpenGL - but I can say for sure that I am an advocate of it being used for the future because if GZDoom were to really become a full on-its-own engine soon, Vulkan would hands-down overtake OpenGL for some of the stuff like shaders and any other postprocessing. It is not only that, but it does have the drastic performance advantages that can really allow people with heavy rigs to completely have the best performance over any of the other ports that are currently available with OpenGL. I can guarantee that Graf knows much more on the subject anyways and I am certain that is the type of topic he should discuss with the other developers on.

But features cannot always depend on one person's hardware.

I believe Graf deserves the mindfulness of being able to have remote access to your computer as a makeshift work space with Vulkan and all of that — and it certainly is very generous of you to offer that opportunity Rachael! We all—as the community—want the developers to have the comfort of being able to get things implemented and try to do it in a way that makes both (QZDoom and GZDoom) source ports happy. And from my point-of-view, I think Graf should absolutely take this opportunity and take advantage of it instead of having us all wait until September for him to even begin implementing stuff for Vulkan.

Supporting what will essentially be an additional renderer, at this point, is a pretty shaky prospect by itself. I have no doubt that if anyone can pull that off, you can - but even still, that's a LOT of different code that in the end will all be doing much the same thing: presenting some sort of 2.5D map on the screen.

If he is willing to work with it as well and is showing the interest, then he will indubitably be able to pull it off for sure! My standpoint has and always will be that if the developers can provide anything that will make improvements and especially drastic ones, then I (and probably a good portion of the community) certainly will want it to be an addition/omission for whatever it takes to make the improvement.

[ibm5155]

@Graf will Vulkan really improve the performance of Gzdoom?
Do you have some kind of Prototype for comparing the increase of performance from opengl to vulkan in a doom engine like scenario?
All I know is that gzdoom is CPU bound (may be wrong because I haven't tested the latest builds for some time) so idk if a new api will help in that case.

EDIT: To compare, I don't have a great rig right now but it supports vulkan, the performance increase ins't huge compared to what 3Dmark Says, I could even make a vídeo comparing the performance agains gl with doom 4 if you want

[Major Cooke]

@ibm:

The main problem here is that I cannot say yet if this needs some changes for Vulkan and I won't act on it until I am starting to work on that. Unfortunately, due to budget constraints I cannot buy the new graphics card I need for that until early September so it's still some time off.

For the same reason I have been holding back a more extensive shader generalization feature I've already been working on. I know I can make it work with OpenGL but the way I initially designed it will need some change in Vulkan.

[Graf Zahl]

@Graf will Vulkan really improve the performance of Gzdoom?

I cannot say yet. The main problem I am facing is that maps like Frozen Time cannot multithread the scene processing because OpenGL wants all API access through the main thread. In such cases Vulkan will definitely help. What it won't be able to do is make maps run faster that are mostly GPU bottlenecked. It also will require quite a bit of testing because if you do things wrong there won't be any speed gain.

[ZZYZX]

because OpenGL wants all API access through the main thread

Use different context in each thread and share them? I remember this worked for texture loading in background.
Actually, for texture loading even using mutex and setting context to the one of the main thread worked, but that kinda defeats the point of multithreading.

[Graf Zahl]

It's all very hacky and unstable to work with multiple contexts. The main issue isn't the textures but the drawing and that cannot be multithreaded. Which indeed defeats its purpose.