New Irrlicht team-member for iOS & metal: Daniel Bocksteger

[CuteAlien]

I'm glad to announce newest member of the Irrlicht team - Daniel Bocksteger. Apple recently decided to stop supporting OpenGL and no one in the current Irrlicht team was about to take on the challenge of adding a metal driver (see http://irrlicht.sourceforge.net/forum/v ... =4&t=52293). So Daniel offered to give it a shot. He has helped us out with patches for iOS before and I hope this will help keeping Irrlicht on Apple systems alife.

A new branch for metal will show up in svn soon (edit: It's now in branches/metal - but not doing anything yet).

[DanielBocksteger]

Hi there,

thanks to CuteAlien for introducing me to the community, I'm happy to help - or try to help

Glad to be part of Irrlicht, after working with it since 2012!

Best wishes,
Daniel

[AReichl]

"Hört hört!" ( = "listen listen!" ).

I do NOT want to complain, but do you really want to take that burden?
I know this is a long discussion, but you / we should make the most out of the least resources ( meaning developers and time ).
Let Apple be Apple and go on with the real outside world.

I herewith (inofficially) vote again for stripping down Irrlicht to an engine based solely on OpenGL/GLSL ( + Vulkan?, SPIR-V?, ... ).
See for example Irrlicht-BAW, but that's too "complicated" already - i cannot compile that beast, even if i follow the instructions step by step.
Then CuteAlien ( and you ) could concentrate on ONE interface and development would accelerate ( probably exponential, hehe ).

[devsh]

If you are having issues with IrrlichtBAW then open an issue on github, we'd love to resolve it.

We tried pretty hard to get CMake to fill all your compilation needs on Linux, and Visual Studio will compile on windows providing you have openssl on the right path (and the OpenCL SDK installed too).

The build instructions were updated 4 days ago.
https://github.com/buildaworldnet/Irrli ... he-Library

[DanielBocksteger]

"Hört hört!" ( = "listen listen!" ).

I do NOT want to complain, but do you really want to take that burden?
I know this is a long discussion, but you / we should make the most out of the least resources ( meaning developers and time ).
Let Apple be Apple and go on with the real outside world.

I herewith (inofficially) vote again for stripping down Irrlicht to an engine based solely on OpenGL/GLSL ( + Vulkan?, SPIR-V?, ... ).
See for example Irrlicht-BAW, but that's too "complicated" already - i cannot compile that beast, even if i follow the instructions step by step.
Then CuteAlien ( and you ) could concentrate on ONE interface and development would accelerate ( probably exponential, hehe ).

We‘re running more than one app based on Irrlicht for iOS and a support for metal will save our future for this’d apps. So it is not only a Personal, but a Business desk soon too.

[CuteAlien]

Irrlicht splits drivers & devices well, so apple support never really affected me in any way. Not having an apple computer I can't work on that, so I never touched that code. Having one more developer for apple sounds good to me and I'm glad when it's kept alive. On a side-node ... apple developers have now the majority in the Irrlicht team, but I'll fight to keep Linux&Windows support alive :-)

[devsh]

Daniel, its not the end of the world, the apps you already wrote will run on MacOS and iOS, even on the future versions of the OSes.

Apple deprecation of OpenGL has confirmed what was already the status quo, no further OpenGL version upgrades (support stopped progressing at GL 4.1 some more than 5 years ago).

I completely agree with AReichl, that one interface with one shading language (GLSL SPIR-V) is what is needed and necessary, otherwise in a modern engine, people will need to write the exact same shader in 2 or 3 different shading languages.
Nobody is going to do that, and unless you bridge the gap everyone will write for one API anyway, even if they release on multiple platforms, they will just use shitty cross-compiled shaders.

Cutting to the conclusion, since people will either make Metal only titles, or make Metal ports running on shitty cross-compiled GLSL shaders... I decided to take the cross-compilation in my hands with online 3rdparty tools such as spirv-cross and glslang (online).

Another note is that you cannot inject new modern APIs like D3D12,Vulkan or Metal into rendering frameworks with APIs structured around DirectX9 (its explicitly mentioned and drawn in GDC Vulkan/D3D12 presentations) and hope for any sort of a performance increase.
If you follow the model 1:1 you may even get a perf decrease, such as when you switch to D3D11 and OpenGL 3.3 core profile where you NEED to use a VAO to draw, and suddenly you find that making a secret map of one VAO to one IMeshBuffer in the driver that you have to look up every time you draw slows the scene to a crawl! And storing a VAO per IMeshBuffer doesn't work that great either!

Or what happens when you finally find out that Metal only supports Uniform/Constant Buffers as a way of sending uniforms/constatns to shaders?
What happens to the Irrlicht API then?
Do you emulate "setPixelShaderConstant", and rob yourself of all the advantages of Modern over Legacy API?
Or do you finally ditch DirectX 9, and force OpenGL 3.0+ and ES 2.0+ and UBO usage?
But if you use UBOs, then you better let the user actually "see" and "use"/"manipulate" their GPU Buffer Objects? Right?

These are all the questions that have been asked and answered during the development of IrrlichtBAW, we do not break interfaces and APIs because we like to, or because we are like a Junior Programmer who comes to a team telling them to rewrite all their software to language XYZ (Rust, I'm looking at you) or switch their Version Control Software, we break because its necessary.

Once I finally get a working (not just demo, Build A World running on it by default) Vulkan backend, I will make it work on MacOS through MoltenVK.
And I'm ready to bet money that IrrBAW will run faster and consume less resources for the same scene than native Metal Irrlicht, simply because of the way that the APIs are structured.

P.S. AReichl, I actually comitted a bug recently to the engine which made it not compile, now its fixed (comm 270).

P.P.S. http://developer.download.nvidia.com/ga ... vulkan.pdf I hope page 63 can hammer in the point I've been making for the past 2 years about the API needing to follow the 3D API to get any mileage out of a port.

[CuteAlien]

@devsh: a) You assume speed matters in his case. Maybe it doesn't (there's not many games like yours which go to the limits - most games run fine on hardware from a decade ago). I guess you are right that we won't get a boost out of switching to Metal without changing the Irrlicht interface in some way. But it will allow Irrlicht apps to run then in an easy way - which is also not bad.
b) The way to learn how it needs to be changed is usually trying to implementing it once. Or did you know all that stuff _before_ you started coding it? I mean how else is anyone of us going to learn what is needed? Same if I ever have to add DX12 or Vulkan - I still would start by thinking about how to implement the interface because only running into the problems would teach me which changes it needs. So if Daniel finds out the Irrlicht interface _has_ to be changed - then at least I have someone to ask about which changes are needed for Metal. But there is no reason to not even _start_ with it!

[devsh]

A) The speed and memory consumption definitely matters for mobile, the drivers are really small and most of them can't even do constant folding or subexpression elimination for GLSL shaders in ES 2.0. They have really slow blending units, on some hardware you can only blend 7-12 screen sized alpha quads before you slow down to <30fps, this is all due to to tiled rendering and slow off-chip bandwidth. So while NOW the performance doesn't matter because you have a simple scene in ES and fps it 60+, it WILL matter once that 60+ drops into a 13 or you start getting 100ms stutters just because you switched to a modern 3D API, part of that is the requirement to always use a hardware buffer as source of data to draw, and small frequently updating meshbuffers such as GUI elements need to batched and streaming. Naive VAOs are actually slower than CPU mapped attributes from legacy OpenGL (https://www.opengl.org/discussion_board ... mentations).
My main argument is not that you won't get a boost, its that modern API accessed in a DirectX9 wrapper will be borderline unusable. If the occlusion queries are still done through a linear search and not even a map<> which makes them churn 25% of modern CPU time on a scene with 1000 nodes, how are your implementations of VAOs, Buffers, UBO, SSBO, Buffer Allocators, Pipelines and Command Buffers going to turn out?


There are a number of issues even with the current SVN shader-pipeline branch (which to my knowledge got stopped) API:
https://sourceforge.net/p/irrlicht/code ... reBuffer.h The buffers seem to be typed, they don't need to be for OpenGL and Vulkan.
The API is written to create one GPUBuffer per "VertexBuffer", "IndexBuffer" this prevents batching and geometry pooling.
This isn't a problem per-se for OpenGL and <=D3D11, but Vulkan has limits on the number of allocations it can request from the driver, and APIs like Metal and D3D12 will really benefit from the Vulkan approach.


B) Most stuff I put back into IrrlichtBAW was what we were already hacking in Build A World with direct video::COpenGLExtensionHandler method calls (made all extension functions static), so we already knew what we wanted/needed. I actually read the OpenGL and Vulkan spec before writing down any code that isn't "an interface ADT that I'm not using yet" , that's so I run into very few problems and usually I let other people's problems teach me. I actually haven't written a single like of Vulkan in IrrlichtBAW and I'm still dealing with the interface in the abstract as you can see here https://github.com/buildaworldnet/Irrli ... projects/3 and here https://github.com/buildaworldnet/Irrli ... GL-Support . This makes sense I guess as most Vulkan speakers at GDC told people to modernize their OpenGL first, and this applies especially to me because I intend on supporting OpenGL for as long as Intel Broadwell Graphics Drivers pass WHQL, or until some Vulkan to D3D12 working wrapper appears.

[CuteAlien]

The question of how our implementation is going to turn out is hard to answer unless someone actually works on it... no one will ever answer those questions and be able to talk with you if you stop us from even starting :-)

I likely still wouldn't know anything about Irrlicht driver implementations if I hadn't worked on the WebGL driver last year. That work is the _only_ reason I learned a lot about the OpenGL driver internals and can now at least somewhat talk about driver development. Before that stuff was a black box to me. So the idea that working on a new driver is a waste of time is in my experience completely wrong! You work on stuff - you start to understand it. And sadly no one is ever motivated much to work on stuff other people need. I needed WebGL - so I worked on that (instead of for example working on DX12 which certainly more people wanted). Daniel needs Metal - so he is going to work on that. DevSH - you need whatever you need in your game - so you worked on that (and learned from that I suppose). And it's a new branch, so if it doesn't work out I guess Daniel will still learn a lot about Irrlicht and Metal and library development. Which might help once we decide to break our interfaces for example.

I think Nadro mentioned the trouble with the meshbuffer interface in Irrlicht shader-pipeline once, maybe that was the reason he decided to write a new approach instead of using that branch? Anyway - yes that branch is likely dead as the people who created it are no longer actively working on Irrlicht. But I also don't consider it as someone wasting their time. If I ever work in that area myself (which I suppose will happen one day) I will certainly take a look at it! Also some people worked with it already. Btw, I also offered svn-write-access before to people who had interest in that branch, just no-one took it up so far.

Maybe I should have mentioned in the introduction that I certainly won't prevent Daniel from helping out with other Apple/iOS problems (kinda obvious....). For example he told me that they got multi-touch support for iPhone working in their Irrlicht version. And given that Nadro hasn't checked in something for Apple for a year now, having another maintainer with iOS simply makes sense.

I get that everyone prefers people would work on things they want&need. But that's not how it works in open source. As Eric Raymond once famously stated in his number one rule for creating good open source software: "Every good work of software starts by scratching a developer's personal itch."
So if someone joins Irrlicht because he likes working on Apple & Metal that's the area he should work on. You might not like Apple and think Metal is dead on arrival and shouldn't be supported, but really that's still no reason to stop anyone from working on the stuff he loves to work on! And technical problems which need to be solved for newer pipelines absolutely exist -but they certainly won't ever be solved by _not_ working on it!

[devsh]

I'm not trying to dissuade you from working on next-gen APIs, I'm just looking through the lens of your previous (and possibly current) allergy to major API changes.

If you are willing to change the Irrlicht 1.9/1.8 API to Irrlicht 2.0 API as much as Irrlicht 1.9 differs from Ogre or Urho3D, it's pretty straight forward and by all means go for it.

If you think you can change the APIs "slightly" then DirectX and OpenGL drivers will always be the best performing renderers and D3D11/D3D12/Metal/Vulkan forever unfinished.

I dont have any power over you and I would want to have it, so work on what you want by all means.


P.S.

You might not like Apple and think Metal is dead on arrival and shouldn't be supported

I didn't say "shouldn't be supported" just not supported with 100% effort

[CuteAlien]

Yeah, I have that allergy. But I also never stopped people from working on the shader-branch and actually expected it to become Irrlicht 2.0.

edit: *snip* - this thread is getting out of hand. Already I spend the first 3 hours of my weekend on it - time gets lost in mysterious ways some days :-) Just say hello to the new guy. Let's keep engine-API discussions to another (and please not every other) thread.

[MartinVee]

Just say hello to the new guy. Let's keep engine-API discussions to another (and please not every other) thread.

That's what I was about to say. Let's tone down the bickering, it makes it look like Daniel isn't welcome to Irrlicht.

So, baptised in fire, but welcome Daniel!

[Granyte]

Welcome to the new team member and while I personaly have no interest to Apple's side maybe Development for metal will give us a path forward to newer API

Btw my project is still running on an updated version of the shader-pipeline branch and dx11 driver but no one ever showed any interest to the patches I posted.

Also if there is ever an agreement to develop a branch that shows similar capabilities to the shader-pipeline branch I would gladly migrate the dx11 driver over.

[devsh]

Where are these patches, and what dx11 features do you require?

I never saw an actual repository with these, and stuff tends to get lost on the forum.

Maybe my fork has 90% coverage with these, and the rest I could put together for you in reasonably little time...
I never touched dx11 in my life so I would not want to integrate that into IrrBAW, Vulkan will be its sole target API (with OpenGL still supported as a transitioning back-up).
However note that my fork will exceed the capabilities of whatever the shader-pipeline branch has, FVF has been there and used stably in BaW for over 2 years now.

EDIT: For the first time in my life I actually took the time to read more than 2 posts from the DirectX 10/11 driver thread, and I can confirm that IrrBAW can do everything the shader-pipeline branch and the patches posted in that thread up until this date http://irrlicht.sourceforge.net/forum/v ... &start=750 could do (with notable exception of some weird blending and stencil op effects such as shadows -- that's really the fault of SMaterial which Nadro noted needs changind into CMaterial).
After this little baby https://github.com/buildaworldnet/Irrli ... Pipeline.h is half done (has the VAO, Shader Programs and Rasterizer states implemented), the feature parity will be 100%+