Ultra Software Company Blog

Yeah, but Khronos scrapped OpenGL NG for Vulkan lol... and even if Vulkans not the future somethings going to have to replace OpenGL soon. Most engines are adding/have added support for when it's ready, it's simply not ready. Apples lack of support is kind of disappointing, but only weeks after they announced they aren't supporting it MoltenGL came out to allow Vulkan to work on Apple products. The community support is huge.  ANYWAYS enough thread-highjacking

(P.S: Roblox, Dota2, Doom, and vkQuake use Vulkan already!)

Does LE use direct state access right now? If not do you plan on changing to use it so you don't have to constantly bind different states?

1 hour ago, Crazycarpet said:

Yeah, but Khronos scrapped OpenGL NG for Vulkan lol... and even if Vulkans not the future somethings going to have to replace OpenGL soon. Most engines are adding/have added support for when it's ready, it's simply not ready. ANYWAYS enough thread-highjacking

(P.S: Roblox, Dota2, Doom, and vkQuake use Vulkan already!)

Does LE use direct state access right now? If not do you plan on changing to use it so you don't have to constantly bind different states?

 

Khronos also put out Collada, which is a dead exchange file format no one uses.  They have a dozen specifications, all with lots of logos from all around the tech industry, and OpenGL has been their only hit.  None of those companies really believe in Vulkan.  If they did, why would they still be supporting DX or OpenGL?  I'm afraid we're going back to the days of proprietary fragmented APIs.

Actually, now Khronos wants to create another standard to work as an abstraction layer for all their other standards!:
https://www.khronos.org/3dportability

They're not even trying to get people to adopt Vulkan anymore, now they are trying to make a wrapper for DX12 and Metal.  So really shouldn't "Khronos 3D Portability Standard" be considered the future?

Regarding direct state access, it's not part of the 4.0 spec, so no.  Looks like that was added in GL 4.5, and Mac supports up to 4.1.

Putting all the OpenGL classes up on GitHub (I might rename the main class GraphicsEngine instead of GraphicsDriver) might be a way to stay flexible.  The code would show how I did everything in OpenGL, and if anyone wanted to they could implement new classes based on Vulkan, Metal, DX, or whatever.  You can do this right now with Leadwerks 4 but it's pretty hard to figure out when you only have header files.  You could even modify it for OpenGL 4.5 and find out if the newer features even make a difference, and how much.

I had high hopes for the Steam paid workshop store so will Leadwerks 5 have its own paid asset store? I would love to seriously sit down and make some cool plugins, scripts shaders for people to use. However I am not going to setup my webshop for this again like I did with FlowGUI (too much setup and maintenance for it to be profitable). 

 

2 hours ago, AggrorJorn said:

I had high hopes for the Steam paid workshop store so will Leadwerks 5 have its own paid asset store? I would love to seriously sit down and make some cool plugins, scripts shaders for people to use. However I am not going to setup my webshop for this again like I did with FlowGUI (too much setup and maintenance for it to be profitable). 

 

The Workshop has actually started finally picking up, enough that one artist who has a lot of content is very interested in publishing his own stuff, instead of waiting for me to convert models for him.  That was my whole goal, to make it self-sustaining so sellers were motivated to publish their items.  So it looks like it will be good, and it just took a while to get going.

But will paid scripts be accepted eventually then? I am still eager to sell little but usefull scripts.

Just now, AggrorJorn said:

But will paid scripts be accepted eventually then? I am still eager to sell little but usefull scripts.

Yes.  The 4.x API isn't going to change, so we're probably at a point where it's okay to start selling scripts and shaders in the Workshop store, if you are interested.

22 minutes ago, Josh said:

Yes.  ...... it's okay to start selling scripts and shaders in the Workshop store, if you are interested.

Thats awesome. I will get back to the drawing board then :).

I know it redirects, but the pinned steam topic refers to the wrong link: https://steamcommunity.com/app/251810/discussions/0/485622866441513850/

LE5 sounds great, however still have some questions about LE4.x.

1. Will the 4.4 be the last version of 4.x?

2. What are the main new features will be added in the version 4.4?

3. Is that possible to see the visual GUI editor before 5 released?

4. After 5 is released, will the 4.x still be officially maintained and supported, like docs and bugfix updates?

Because of some payment problems, it unlikely for me to have a monthly subscription version. So the steam edition and version 4.x could be the only option for me.

35 minutes ago, zyzz1995 said:

LE5 sounds great, however still have some questions about LE4.x.

1. Will the 4.4 be the last version of 4.x?

2. What are the main new features will be added in the version 4.4?

3. Is that possible to see the visual GUI editor before 5 released?

4. After 5 is released, will the 4.x still be officially maintained and supported, like docs and bugfix updates?

Because of some payment problems, it unlikely for me to have a monthly subscription version. So the steam edition and version 4.x could be the only option for me.

1. No, there will be a few more 4.x versions, mostly focusing on engine features and improvements rather than the editor.  The point I break between 4 and 5 is when I introduce breaking changes to the API, whereas we've maintained nearly 100% backwards compatibility since version 3.1, with only one or two exceptions.
2. VR, networking, GUI, and update to latest version of Newton are all in the works.  The second two are probably definite, the first two might or might not make it.  Granted, all of these things are in the engine right now in some form, but the difference is they are official and documented and finished and won't change.
3. I don't have any plans for this right now, especially in the 4.x editor, since that code will not carry over to 5.0.
4. At some point, maybe 4.7 or 4.8, it will be considered finished and only receive updates if someone puts out a bad graphics driver.

Will ver. 4.x projects be supported in V5?

19 minutes ago, psychoanima said:

Will ver. 4.x projects be supported in V5?

Yes.

Leadwerks 5 sounds great, really pleased to hear that you will still be able to buy Leadwerks on a non subscription basis. Looking forwards to the new lighting equation and rendering! 

The multithreading sounds great! I think the plugins will add a lot of power to what you can do with the editor.

Why put culling and rendering on separate threads though? Culling really shouldn't take that long (plus this doesn't reduce the latency in any way for VR): https://www.gamedev.net/topic/675170-frustum-culling-question/

I really think you shouldn't dismiss Vulkan with superficial arguments though. You should get a better understanding about what Vulkan can do (what problems it solve with OpenGL). Khronos isn't "throwing in the towel", not sure where you would get that from. You know Khronos is made up of members of the GPU vendors who collaborated on the specification, so it's not some random standard. It's been one year since Vulkan was released, how do you expect game studios to completely rewrite their engines in that amount of time?

On 5/23/2017 at 6:45 PM, Josh said:

They have a dozen specifications, all with lots of logos from all around the tech industry, and OpenGL has been their only hit.

OpenGL isn't even their most popular graphics API, let alone API. Also, Vulkan is much more portable than OpenGL ever was. Have you heard of OpenCL, the API used in Autodesk Maya and Adobe Photoshop? Not to mention their other APIs for specialty use (OpenGL SC, OpenVX, etc.).

On 5/23/2017 at 6:45 PM, Josh said:

They're not even trying to get people to adopt Vulkan anymore, now they are trying to make a wrapper for DX12 and Metal.  So really shouldn't "Khronos 3D Portability Standard" be considered the future?

No, they are suggesting an abstraction layer over DX12, Metal, and Vulkan. Vulkan supports more Windows OSes than DX12, so the abstraction layer is accounting mostly for DX12 and Metal's faults. If they were "throwing in the towel", then why are Google and Valve so invested in Vulkan? Why is Vulkan a first-class API of OpenVR? And why would the Khronos Group suggest merging OpenCL with Vulkan?

On 5/23/2017 at 3:13 PM, Crazycarpet said:

A programmer can make a renderer with Vulkan that never locks a mutex by simply having 1 (or 2) command pools per thread.

Not sure you can do this for any benefit. Yes, you can have command pools per thread, but you need to synchronize the submission of command buffers or you can get undefined behavior. Building command buffers is what multithreading is intended for.

On 5/23/2017 at 5:52 PM, Josh said:

Notice there are no Vulkan-exclusive games in existence.  It's always just an experimental feature people add on to another renderer.

Microsoft has a solid working API that reliably does everything Vulkan does, except run on Linux, and Apple is not interested in Vulkan.  So really I would say DX12 is the future for a long time.  We will see.

Are there any games that support only DX12? And no, DX12 only runs on Windows 10, so they are neglecting a huge chunk of their own consumer base.

On 5/23/2017 at 3:10 PM, Josh said:

One will gather up batches of surfaces to be rendered, and the other thread will continuously rendering them.  This is basically how command buffer APIs work, as I understand it.  I don't think Vulkan will offer a big performance increase over the architecture I have in mind.  It's only AMD cards that get a significant boost, and OpenGL is still the only cross-platform graphics API for Windows, Mac, and Linux.

No, that is not how command buffer APIs work. The point of a command buffer is to bind renderpasses, descriptor sets, pipelines, draw objects, etc. They are basically a list of commands that are "precompiled" in a way. For instance, a post-processing stack would benefit from this since it rarely changes.

Vulkan offers improvements over OpenGL in many areas. Your deferred rendering with MSAA can be improved by Vulkan by using input attachments, which would substantially reduce memory bandwidth. Subpasses also help with this. Vulkan doesn't have validation, and this was a huge performance hit in OpenGL. Vulkan has immutable state in the form of pipeline object, again a huge performance improvement. Notice that none of these even talk about multithreading. So regardless of how you design your renderer, you will be able to benefit from Vulkan features. I'm not sure how you can say AMD cards only benefit from Vulkan when it's largely CPU improvements (so driver improvements). You can even download NVidia demos if you don't believe me.

I'm not saying you should use Vulkan, use whatever you like, but the reasons you are dismissing it have no backing.

3 minutes ago, nick.ace said:

I'm not sure how you can say AMD cards only benefit from Vulkan when it's largely CPU improvements (so driver improvements).

The Doom 2016 benchmarks show slightly worse performance in Vulkan vs. OpenGL on Nvidia hardware.

5 minutes ago, Josh said:

The Doom 2016 benchmarks show slightly worse performance in Vulkan vs. OpenGL on Nvidia hardware.

Yes, at 4K resolution, which at that point has little to do with the API as you are so GPU limited. Also, considering those drivers were out for 3-4 months and the devs were probably still learning Vulkan, I don't think that's a fair conclusion. Also, their engine was basically structured similarly to how they structured their OpenGL engine (I know because they gave a talk about it at a Vulkan conference). The drivers are also much easier to write for Vulkan, so there will likely be less problems going forward.

Edited May 31, 2017 by nick.ace

11 hours ago, nick.ace said:

Not sure you can do this for any benefit. Yes, you can have command pools per thread, but you need to synchronize the submission of command buffers or you can get undefined behavior. Building command buffers is what multithreading is intended for.

On the contrary, this gives more performance benefits than anything else you can do in Vulkan. Yes, they have to be submitted all at once through a primary command buffer... but it's not about that, it's about how long it takes to generate the sub-command buffers before being able to submit them, instead of writing the drawing for 1 entity at a time, you can write up to as many free threads as you have at once. Threads operate for approx. the same length as eachother per frame.... Instead of having 1 primary command buffer and writing the commands 1 at a time, you're writing commands <free thread #> at a time, then you get to submit the end result much, much sooner... Instead of your GPU being bored and 1 CPU core working hard, all your free CPU cores work hard and your GPU has a lot of work to do, which is great!

You MUST have a command pool per thread, and when you generate cmd buffers you assign them to the pool of the thread you're working in, that's just the way the Vulkan API is designed. We have no say over that, this design is what allows us to do this without locks.

Don't take my word for it, Valve wrote one of their write-ups on how they came up with design, Nvidia and many others follow it as well.

As for the drivers for Vulkan, they're only easier to write because spir-v is a binary language, where as GLSL and some other shading languages may interpret the standards differently. Khronos provided a new verison of glslang that ensures your GLSL is conformant and compiles it to binary.

I'd like to stress that Doom is a horrible example of a Vulkan implementation... they don't take advantage of any of the custom-allocator options that Vulkan provides, nor the easy multithreading options it provides. It was a poor implementation that expected to drop in a young API and see improved performance. As for Nvidia's performance on Vulkan, this will come... AMD had horrible shader optimization which was a big pitfall in their GL drivers, this is not going to be a problem in Vulkan that's why AMD cards perform well... Nvidia always makes great drivers just give them time.

@Crazycarpet I think you are arguing the same point as me. My point was that you need to synchronize at some point.

12 hours ago, Crazycarpet said:

As for the drivers for Vulkan, they're only easier to write because spir-v is a binary language, where as GLSL and some other shading languages may interpret the standards differently. Khronos provided a new verison of glslang that ensures your GLSL is conformant and compiles it to binary.

You're point about drivers being easier to write because of Spir-V shouldn't be the reason. GLSL is pretty clearly defined, and you can easily write a shader that compiles on all platforms because of this. The compilation from GLSL to Spir-V isn't that difficult, as you can see from human-readable Spir-V code. Spir-V was made so that shader compilation on each platform would be faster (for some games this is a big deal) and so that other languages (e.g., HLSL) could compile down to it. A common trend with Vulkan is letting the application come up with abstractions. The driver still has to convert Spir-V to it's internal GPU format.

OpenGL drivers are often multithreaded and do this command buffer generation behind the scenes. One of the problems is that they don't know what commands the application will give next. So driver writers take it on themselves to create heuristics guessing what patterns of commands will be sent. If you look at driver releases, they will often give performance metrics for speedups for certain games. This is because they change heuristics for certain games, something indie developers don't really have access to. Vulkan seeks to largely remove this disconnect, and it largely does if you are familiar with the API.

There are other things that go on in drivers as well such as how to handle state changes and how memory is managed. Again, these are heuristic based. For state changes for example, certain state combinations can be cached in OpenGL drivers. Vulkan makes it the application's responsibility to cache these (with immutable pipeline objects). Maybe this cached state gets discarded in OpenGL and is needed again, so there will be lag. Yet, you may have expected this state combination to be needed, but the driver doesn't know this.

The problem is that the implementation for certain things might involve more changes that you would expect, but you don't get many opportunities in OpenGL to work around this. For example, changing blend modes could force your shaders to change behind the scenes. Yes, your shaders, because many architectures implement blending as programmable.

And don't forget about validation because OpenGL tries to prevent undefined behavior :). Validation is expensive since you have to account for edges cases that many applications will never run into.

Well you are definitely right, I mean they are certainly easier to write because Vulkan puts most of the responsibility of memory management on the developer I didn't mean to overlook that.

What I more meant in regards to shaders is that if you look at the way AMD/Intel/Nvidia drives handle glsl shaders it's hugely different... with Nvidia's implementation clearly handling shader optimization and what not the best... With Vulkan their drivers will handle the spir-v bytecode more or less in the same way.

Long story short Vulkan gives the developer a lot more opportunity to capitalize on lowering the amount of allocations/deallocations, and concurrent command buffer writing... that handy little pNext variable in the structs also makes implementing things like Nvidia's bindless textures or AMD's rasterization order easily implemented with ~6 lines of code a piece. (I know it's easy in OpenGL as well, but not that easy!)

Can you link me to a driver implementation that multithreads anything in OpenGL? I don't see how they would accomplish this "behind the scenes" as the global states in OpenGL would prevent this... that's why you need a command pool per thread in Vulkan... OpenGL is an API that really doesn't look like it'd be able to accomplish multi-threading and especially not lock-less multi-threading. (When I say lock-less of course I'm excluding the single lock that ways for all the threads to report-back.)

I'm not argueing that you need to "synchronise" you have to wait for all threads to complete their jobs yes, but that doesn't by ANY means suggest that this won't give a performance gain... you get immense performance gains from this method, in fact Unity reported in their multithreaded Vulkan renderer release (that pretty much only optimizing through this method) 60 percent FPS gains out-of-box.

I'm not really sure what you mean by the shaders are handled very differently per vendor. Sure, they can do specific optimizations per architecture (like reorganize instructions to allow for more spaced texture lookups and better instruction-level parallelism), but that should be about it. I'm not sure you can say NVidia handles this the best though. The GPU performance in the initial benchmarks could be due to many things including suboptimal image layouts and poor memory management.

Yeah, you're not going to get much speedup with multithreaded OpenGL drivers. You should be able to see this if you run an OpenGL program, but it might depend on the vendor. However, drivers can be used to do GLSL compilation on multiple threads and can create command buffers since they OpenGL typically has many frames of latency. So it should be possible to cache these command buffers. How much this is done in practice though (if at all), I'm not sure, and it varies per vendor.

I am not a fan of leadwerks 5.  substance support and all these features are free in other engines.  I am not a fan of monthly subscriptions to use software, I can justify an actual game like WoW because of the enjoyment factor is way more than video game creation.  Both can be enjoying though.  If i want substance support I would use unreal engine 4 which is free, Epic just asks for 5% of your income when you actually sell a game.  Which is  superior to a monthly subscription model, only to be trumped by a reasonably priced engine like leadwerks 3 was when i picked it up a couple years ago, glad to see $100 go down the drain currently as this is planed.

Quote

Pricing for a perpetual license for the standard and pro editions would most likely be the same as now ($99-199), with a discount for early adopters / upgrades.

According to this post, the subscription service is just an option. If you want to put 100-200$ to own the software, that's cool too. I hope this remains the case when it comes time to release. I dislike the idea of 'renting' software, hence why I moved to most open source software, but I also understand the arguments.