Support for vsync

[senevoldsen]

Is it intended that vsync is only supported for Direct3D backends, or is it just temporary? Looking at the source, nothing seems to be done in the other backends?

Thanks for the library.

No, was not the intent, Not sure about OpenGL, but this absolutely should work on Vulkan.

[senevoldsen]

Haven't used Vulkan yet, but though it, like the other non-D3D backends, have code in the Present(Uint32 SyncInterval) implementation for the swap chain, none of them seem to make use of the SyncInterval parameter.

From some searching, it seems it should be possible for OGL, thought it varies a bit by platform, e.g. wglSwapIntervalEXT vs glXSwapIntervalEXT.

[senevoldsen]

Not sure where to post this question - and since it is likely not a bug, but probably me misunderstanding something, I reuse this issue, since it is at least OpenGL related.

I am porting NanoVG to Diligent and have it working in D3D11 and D3D12. But, when I switch to OpenGL I got a problem with the appearance. The can replicate it in D11/D12 by changing the texture format for the render target to one without a stencil, so I am quite sure OpenGL is not properly using the stencil. Looking through Diligent's source I can see it does indeed call glEnable(STENCIL_TEST) when binding the PSO, but I cannot find where the stencil buffer is set, or how to enable it.

The texture format I am using is SCDesc.DepthBufferFormat = TEX_FORMAT_D24_UNORM_S8_UINT; and getting the TextureInfoFormat from the device indicates it is supported.

Hi! The stencil test as well as stencil operations are configured in the DepthStencilDesc of the pipeline state. The engine keeps track of the current stencil test state and enables it when needed. Stencil test should work fine in OpenGL because there are some test and also atmospheric light scattering post effect uses stencil a lot.

Double checked at the effect uses D24S8 format, so it should work fine. A potential difference could be that Diligent ignores viewport and scissor when clearing render targets, similar to Direct3D. glClear respects scissor, so this may somehow cause the difference.

@senevoldsen Did you figure out what was the problem?

[senevoldsen]

@DiligentGraphics No, not yet. Seems NanoVG does not use scissor. I tried outputting the stencil test state using glGetBooleanv direct and it is indeed enabled. I then tried querying the GL_STENCIL_BITS, but was not allowed to query that parameter.

I tried searching the samples and other repositories, and the only actual usage of stencil I could find was the Epipolar Light Scattering in the FX repository: https://github.com/DiligentGraphics/DiligentFX/blob/master/Postprocess/EpipolarLightScattering/interface/EpipolarLightScattering.h#L143 . But this is a "manually" allocated texture that is then the non-default target of a rendering operation https://github.com/DiligentGraphics/DiligentFX/blob/master/Postprocess/EpipolarLightScattering/src/EpipolarLightScattering.cpp#L995 . Whereas I am just using the default RTV and DSV. But I tried copying it and attaching it as the stencil target using SetRenderTargets to the context. But when I do I cannot clear the RTV or DSV since only the default targets can be cleared (at least in OpenGL).

I must admit I am still working on the assumption that the default DSV does not have stencil bits, at least in my case on Diligent's OpenGL backend. This assumption is strenghtened by the fact that if I apply the following glfwWindowHint(GLFW_STENCIL_BITS, 0);, which requests zero stencil bits, to the original NanoVG demo example using GL3 before creating the window, I get the exact same issue, but when I remove the line, the issue is gone. Looking through Diligent's source I cannot find the actual place where the "raw" opengl stencil buffer is created/applied/requested or stencil bits requested.

At this stage, I am thinking of creating a tiny sample application using OpenGL and some stencil operation to see what happens.

Also from what I can tell SCDesc.DepthBufferFormat is not used by the OpenGL backend.

Ah, I see, you are trying to create D24S8 depth buffer in the swap chain. You are right then, in GL backend the depth format is actually hardcoded to 32-bit without stencil. Will fix that:
https://github.com/DiligentGraphics/DiligentCore/issues/new

[senevoldsen]

Sounds great; thank you.

@senevoldsen Try getting the latest Core, the stencil should work now. Note: the stencil will not yet work on Android

[senevoldsen]

Had to change the calls to resource creation functions to get it to compile since the interface changed to pointer, but excellent, it works great now 👍

OK, great! Yes, the API is still in flux little bit, and few more updates are coming.

[senevoldsen]

Don't think a new issue is needed for this little thing: Uint32 Stride = AutoOffset; think you mean AutoStride, this is in InputLayout.h - they are both the same though, but still.