Implementing BGFX as a driver...

Discuss about anything related to the Irrlicht Engine, or read announcements about any significant features or usage changes.
JFT90
Posts: 22
Joined: Sun Jan 03, 2016 6:53 pm

Re: Implementing BGFX as a driver...

Post by 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?
Irrlicht with bgfx-Driver https://gitlab.com/JFT/Irrlicht_extended (forked from Irrlicht trunk)
robmar
Posts: 1125
Joined: Sun Aug 14, 2011 11:30 pm

Re: Implementing BGFX as a driver...

Post by 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
Posts: 22
Joined: Sun Jan 03, 2016 6:53 pm

Re: Implementing BGFX as a driver...

Post by 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.
Irrlicht with bgfx-Driver https://gitlab.com/JFT/Irrlicht_extended (forked from Irrlicht trunk)
robmar
Posts: 1125
Joined: Sun Aug 14, 2011 11:30 pm

Re: Implementing BGFX as a driver...

Post by 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
Admin
Posts: 9628
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: Implementing BGFX as a driver...

Post by CuteAlien »

Some Irrlicht shaders are in media folder. Some are directly in c++ classes for materials like COpenGLNormalMapRenderer.cpp (right at the top).
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
robmar
Posts: 1125
Joined: Sun Aug 14, 2011 11:30 pm

Re: Implementing BGFX as a driver...

Post by 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
Admin
Posts: 9628
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany
Contact:

Re: Implementing BGFX as a driver...

Post by CuteAlien »

Yeah, CD3D9NormalMapRenderer.cpp. And no idea about tools or converting, sorry.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
robmar
Posts: 1125
Joined: Sun Aug 14, 2011 11:30 pm

Re: Implementing BGFX as a driver...

Post by robmar »

Thanks, will sort it and post an HLSL version
devsh
Competition winner
Posts: 2057
Joined: Tue Dec 09, 2008 6:00 pm
Location: UK
Contact:

Re: Implementing BGFX as a driver...

Post by 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
Posts: 22
Joined: Sun Jan 03, 2016 6:53 pm

Re: Implementing BGFX as a driver...

Post by 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.
Irrlicht with bgfx-Driver https://gitlab.com/JFT/Irrlicht_extended (forked from Irrlicht trunk)
devsh
Competition winner
Posts: 2057
Joined: Tue Dec 09, 2008 6:00 pm
Location: UK
Contact:

Re: Implementing BGFX as a driver...

Post by 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
Posts: 22
Joined: Sun Jan 03, 2016 6:53 pm

Re: Implementing BGFX as a driver...

Post by JFT90 »

Yes, that and some rendering reordering (Sort-based draw call bucketing: http://realtimecollisiondetection.net/blog/?p=86).
Irrlicht with bgfx-Driver https://gitlab.com/JFT/Irrlicht_extended (forked from Irrlicht trunk)
devsh
Competition winner
Posts: 2057
Joined: Tue Dec 09, 2008 6:00 pm
Location: UK
Contact:

Re: Implementing BGFX as a driver...

Post by 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.
Post Reply