Glm

[Desperado17]

We have a codebase that is heavily based on glm mathematics library. Does Diligent bring its own vector/matrix library? How compatible is this library to glm?

Regards

[TheMostDiligent]

Diligent graphics API is agnostic to a math library. A vec4 is always just four floats when it comes to graphics. You can use glm as well as any other mathematical library.

[Desperado17]

Ok, so none of the functions in Diligent depends on complex internal matrix/vector types? Only on low-level structures like float arrays etc. that glm is compatible to?

[Desperado17]

Another thing: This entry in Using the Api says there was no Vulkan support on Linux

http://diligentgraphics.com/diligent-engine/using-the-api/#Linux

which contradicts the table in

https://github.com/DiligentGraphics/DiligentEngine#supported-plaforms-and-low-level-graphics-apis

[TheMostDiligent]

Ok, so none of the functions in Diligent depends on complex internal matrix/vector types? Only on low-level structures like float arrays etc. that glm is compatible to?

That's right. All API functions take pointers to raw data (void*)

Another thing: This entry in Using the Api says there was no Vulkan support on Linux

This page is a bit out-of-date. Vulkan is supported on Linux

[Desperado17]

Oh, and another thing:

Do you support SVG loading?

[TheMostDiligent]

No, SVG is not currently supported

[Desperado17]

Ok, thank you.

Next I use GL_EXT_multisampled_render_to_texture to render to offscreen targets multisampled. Is this functionality available with Diligent for OpenGL and Vulkan?

[TheMostDiligent]

Yes. Take a look at tutorial 17.
Resolve operation may also be implemented through render passes, which is a preferred way for mobile devices.

[Desperado17]

Very well.

Ok, now for licensing: As far as I can tell, Diligent allows free use even for commercial settings, right? Is there any 3rd party library in the git repos https://github.com/DiligentGraphics that has a more restrictive license that would prevent this?

Regards

[TheMostDiligent]

Diligent Engine is distributed under the Apache License 2.0. There is a list of third-party libraries with their licenses in each submodule.

[Desperado17]

Greetings,

for integration in my build system it would be beneficial if the resulting libraries are not build into .//buildtype but into ./ . Can you tell me if there is an easy way to achieve this?

Regards

[TheMostDiligent]

Which platform are you building for?

[Desperado17]

Mostly Linux, but in theory it should be compilable for Windows.

Btw., I think there is a bug in ./DiligentEngine/DiligentTools/NativeApp/src/Linux/LinuxMain.cpp:506

It defines the key for the -mode flag to be "-mode " (with a trailing blank space). However, argv[1] will usually be "-mode" (without trailing blank space) so strstr will always fail make a mode chang impossible.

[TheMostDiligent]

Take a look at build configuration. You can tweak CMake target settings in a desired way.

[Desperado17]

Is it intended that the parameters are in quotation marks? Like ./example "-mode GL" ?

[TheMostDiligent]

Well, yes. This is how it works now.

[Desperado17]

Ah, I see.

Now another thing: That linux sample framework only has the modes GL and Vulkan, right? Is there an example that shows Linux and OpenGLES initialization (via EGL for example?). It's for an embedded Linux.

[Desperado17]

I use it all the time with Yocto Linux for Aarch64. Or do you mean it is merely not supported by the Engine?

[TheMostDiligent]

On Linux, the engine can be initialized in OpenGL or Vulkan modes. OpenGLES mode is not supported by the engine on Linux, it is used to initialize the engine on Android.

[Desperado17]

Is this expected to change in the foreseeable future?

[TheMostDiligent]

There have been no plans to implement this so far.

[Desperado17]

A pity. Can you recommend me an APi which can? Unfortunately, I cannot afford dropping GLES support for now.

[Desperado17]

It has come to my attention that there is a way to initialize the engine from an existing OpenGL/ES context via AttachToActiveGLContext. Is there a comparable mechanism for Vulkan?

Edit: Is EngineFactoryVk::AttachToVulkanDevice what I want? Is there an example app for that?

[TheMostDiligent]

In fact this function is not currently exposed in the API

[Desperado17]

Another thing: Is it possible to initialize Diligent with an external window handle (like a winid from QtWidget) ?

[TheMostDiligent]

Yes, as long as the window library provides access to the handle. The swap chain in Vulkan backend needs Window+Display on Linux, OpenGL initialization is coupled with window initialization on Linux, which is why the engine attaches to already initialized context.

[Desperado17]

Is there an example for that?

[TheMostDiligent]

https://github.com/DiligentGraphics/DiligentSamples/blob/master/Tutorials/Tutorial00_HelloLinux/src/Tutorial00_HelloLinux.cpp#L220

For OpenGL, you initialize the context using the handle from the window library and then attach to it in a similar fashion.

[Desperado17]

At first glance: Do I see right that the example creates the window itself and thus knows the type of the handle exactly when the engine is initialized?

[TheMostDiligent]

Well, yes. If you want to initialize the swap chain from the window handle, you will have to know exactly what this handle is.

[Desperado17]

Greetings,

I had a look at the Tutorial01_HelloTriangle example running un Vulkan mode. Is it possible, that the VkDescriptorSets and their associated VkDescriptorPool are deleted and recreated every frame for every command buffer? If yes, Is this efficient from your view?

Regards

[TheMostDiligent]

And shader resource binding commit happens every frame?

The context starts in default states every frame - no resources, pipelines, render targets etc. are bound.

If you need to bind a new buffer before every draw call - you need to use dynamic variable type. In this case a new descriptor set is allocated every time you commit the SRB.
If you need to change the contents of the buffer (e.g. write transform matrices) - you can bind it once and then update the buffer. No need to use dynamic variables and allocate new descriptor sets.

Do you cache dynamic sets in any way?

All resources in Vulkan are cached and reused when no longer used by GPU

[Desperado17]

With "No longer used by the GPU" you mean all command buffers that used it have finished rendering?

[TheMostDiligent]

Yes

[Desperado17]

One more thing: Are descriptor sets only ever used in one command buffer before it is reset or deleted or can multiple command buffers share one?

[TheMostDiligent]

Descriptor sets can be used with any command buffer.

[Desperado17]

I have another question about the difference betwen static and dynamic resources. Does static mean that the descriptor set is allocated/written once during program runtime? Or does it describe the ability ot Vulkan to use dynamic descriptor sets as part of vkCmdBindDescriptorSets?
Regards

[TheMostDiligent]

Static variables are only written once to a descriptor set, but they may use dynamic descriptors.

[FlightBlaze]

When writing glm matrices to the shader constant buffer, you need to transpose your matrices, because glm has column major ordering by default, while HLSL has row major ordering (or vice versa, idk).

[TheMostDiligent]

In GLM, column-major matrices are post-multiplied by the vector (M * v), while row-major matrices are pre-multiplied (v * M), which gives the same results. Even though the matrices are conceptually row- or column- major, in memory their layout is identical.
From the point of view of the low-level API all that matters is how data elements are written to GPU memory. In Diligent, by default this is column-major order.