Implementing BGFX as a driver...

[JFT90]

Ok, good to know. We probably need more test systems - we have some people with amd gpus though, and they didn't report any problems.

At the moment, I am considering dropping all other Videodrivers except the bgfxDriver and the nulldriver in our fork , that would allow to make changes to the rendering a lot quicker and adding new features would also not be as complicated anymore.
Anyone sees a problem with dropping the other drivers?

[robmar]

Only that the DX9 driver works so well, and fast. Is there any guarantee that the bGFX driver would be as fast and fully compatible, with all the same shaders working?

In regards to shaders, the GLSLC tool looks great, converting HLSL and GLSL to SPIRV. It would be useful if the HLSL/GLSL source could be available where converted to SPIRV, which I guess must be the way to go, for shading and general compute.

So will bGFX be SPIRV compatible, or how does this work?

PS There is no refractive/metal surface shader like in Irrlicht with this driver yet? The Irrlicht one works well and can be used with a reflection render texture to give reflection.

[JFT90]

Bgfx is/will be SPIRV compatible: https://github.com/bkaradzic/bgfx/blob/ ... _spirv.cpp (it's bgfx specific spirv i think - so you can not use spirv created from other compilers)

There is no guarantee at the moment that all the same shaders will be working - we would need help to implement all material shaders that are builtin in the normal irrlicht drivers.
Since we didn't need most of them yet I didn't implement them. If you implement some of the materials for bgfx - we will happily merge them.

Concerning the loading of shaders on startup (not having them inside the source code) will produce the need to ship a shader package with the library to properly run irrlicht.
So we are sticking with the method of hard coding the shaders into irrlicht.

There is no refractive/metal surface shader like in Irrlicht with this driver yet?

Yes, was not needed yet - I can have a look (if I have time) to see how hard it is to implement it for bgfx.

[robmar]

Okay, sounds good!

Where the hell are those pesky irrlich shaders stored? I'll convert them, I think they are in asm, to HLSL if any one can tell me where they are hard coded?

In particular, the bump map shader, and the metal one.

Once they're working in HSLS, it will be easy to add them for bGFX using the cross-compiler if needed.

[CuteAlien]

Some Irrlicht shaders are in media folder. Some are directly in c++ classes for materials like COpenGLNormalMapRenderer.cpp (right at the top).

[robmar]

The D3D shader, bump shader, is in CD3DNormalMapRenderer.cpp then?

I guess these shader were written in asm... any good reference guides or tools to convert them to HLSL??

[CuteAlien]

Yeah, CD3D9NormalMapRenderer.cpp. And no idea about tools or converting, sorry.

[robmar]

Thanks, will sort it and post an HLSL version

[devsh]

I wonder how BGFX handles multi-threaded OpenGL rendering, since all of its API-calls are mutexed.

Reading its API reference right now, its interesting... but I was hoping their Vulkan implementation is complete.

[JFT90]

Unfortunately the Vulkan implementation still takes some time..

I would not call it real multithreading - its just one rendering thread.
The thread just runs through the current internal command buffer and calls OpenGL/DirectX/Vulkan API as soon as you call bgfx::frame() from your main thread.
So you basicly have your main thread(s) and the bgfx rendering thread.

[devsh]

So you basicly have your main thread(s) and the bgfx rendering thread.

That's most probably the only place where the BGFX OpenGL over native-Irrlicht OpenGL performance gain comes from (other than using core-profile).

[JFT90]

Yes, that and some rendering reordering (Sort-based draw call bucketing: http://realtimecollisiondetection.net/blog/?p=86).

[devsh]

Irrlicht already does that (incompletely), however the functionality is implemented by ISceneManager ... after all why do you think the registered node for rendering has a sort operator?

However the approach of a dedicated render submission thread has downsides, they didnt go with it for Doom BFG, because it increases latency.
In a normal engine you poll for input, and start drawing something ASAP, kicking off GPU work and then you worry about not starving it.
In deferred submission systems you only call GPU functions once you have a big batch built up and processed, which means that you introduce quite some latency if you misplace code other than draw argument preparation. All the while seeing an increase in FPS you don't really see a problem in latency until you profile it or try to implement VR.

These systems are ok in RTS games (but again 24 FPS is too), games other than FPS and MOBA, the FPS and MOBA games can get by on this system if you put some serious thought into the design and usage of the system (like Naughty Dog did for Last Of Us 2) but this is a definite problem for VR.