The Vulkan API

Post your questions, suggestions and experiences regarding to Image manipulation, 3d modeling and level editing for the Irrlicht engine here.

Re: The Vulkan API

Postby Mel » Mon Feb 29, 2016 12:21 am

Irrlich may support PBR shaders without modifications XD

Honestly i am not sure which would be the best approach with Irrlicht. It does some things right, but definitely, it needs to revamp some others.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
User avatar
Mel
Competition winner
 
Posts: 2271
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: The Vulkan API

Postby Mel » Sat Mar 05, 2016 2:31 am

Definitely some things will have to change in order not only to support Vulkan, but also, Direct3D12 (if it is gonna be supported any time in the future...) namely the rendertarget set up or the material set up, and basically, anything that means chainging any golbal state on the video driver, transforms included, the nature of both is to provide support to a multithreaded rendering, meaning that every draw call you send, contains in itself all the necesary information to be performed, and depending on a global state just means that you have to synchronize to it on every thread you do. This would mean that for instance, the materials themselves would need to include the rendertarget they are pointing to, the camera information, and for instance, some other stuff that before was provided by the driver, and changing shader would mean an aditional task that could be worked around. But for instance, as well, with this in mind, a multi render target is trivial, as you could perfectly perform in parallel 3, 4, 5 or any amount of renderings simultaneously, given each of them ran on its own queue, something also perfectly possible, at least, in Vulkan. And besides, i have to confirm it yet, but the depth buffer and the back buffer could be perfectly accessible, doing a couple of synchronization steps. I have to investigate more (i am ashamed i still haven't rendered a single pixel yet with Vulkan XD it takes much more than you may imagine) But at least, i am getting used to its workflow. And i even learnt how to make a Windows window :P
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
User avatar
Mel
Competition winner
 
Posts: 2271
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: The Vulkan API

Postby REDDemon » Thu Mar 31, 2016 12:15 pm

Actually the only (efficient) way to do multithreading in OpenGL is to use a separated thread to do OpenGL calls so that main thread is not blocked by long OpenGL calls and rendering thread is not blocked by long user interactions, then other stuff can be parallelized as usual, being able to submit GPU commands from multiple threads is really a big advantage. still guessing if it is worth learning Mantle to or just wait for Vulkan.
Junior Irrlicht Developer.
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
User avatar
REDDemon
Developer
 
Posts: 1044
Joined: Tue Aug 31, 2010 8:06 pm
Location: Genova (Italy)

Re: The Vulkan API

Postby Mel » Sun Apr 03, 2016 10:59 am

AMD provided Mantle as the base for Vulkan, so i guess Mantle is AMD only (and would even go as far as saying Windows only, but i am not sure about the later) but Vulkan is crossplatform and hardware independent (Intel, AMD, NVidia, PowerVR, Linux, Windows, Android...)

Well, i've always heard that the graphics calls must be on the main thread always, but it doesn't say the main thread has to be the one with the program as well, so as long as the graphics manager and application are separated, is okay.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
User avatar
Mel
Competition winner
 
Posts: 2271
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: The Vulkan API

Postby devsh » Mon Apr 04, 2016 1:37 pm

threading opengl is needless complication

userspace command buffers are just another layer of useless abstraction which is a bad idea from performance point of view

deferring openGL calls is the WORST IDEA IN THE funking UNIVERSE, why, you ask? Because you want to keep the following statistic to a minimum
cpp Code: Select all
Maximum(for each frame{time from input to display}) // the lower the better


And issuing OpenGL calls later than they could have been issued always increases latency.

Don't get me wrong, I'm all for kicking everything out of the main thread that is not input polling or OpenGL calls.
User avatar
devsh
Competition winner
 
Posts: 1882
Joined: Tue Dec 09, 2008 6:00 pm
Location: UK

Re: The Vulkan API

Postby REDDemon » Mon Apr 04, 2016 2:08 pm

devsh wrote:threading opengl is needless complication

userspace command buffers are just another layer of useless abstraction which is a bad idea from performance point of view

deferring openGL calls is the WORST IDEA IN THE funking UNIVERSE, why, you ask? Because you want to keep the following statistic to a minimum
cpp Code: Select all
Maximum(for each frame{time from input to display}) // the lower the better


And issuing OpenGL calls later than they could have been issued always increases latency.

Don't get me wrong, I'm all for kicking everything out of the main thread that is not input polling or OpenGL calls.


When it comes to optimization, everyone has supposition and hypotesis.
Have you ever tried that approach? I doubt it seriously. The only case where you get measurable latency increase is in simple demo applications with almost no GL commands and no processing on main thread. When you start really using thousands GL calls and some processing in main thread you actually get reduced latency, at same time you get near to optimal performance (pure gl calls with no logic) on rendering thread, wich can't be achieved with other approachs ...

Still happy to see ideas refused even before getting them considered seriously. Just try the approach once in an application with CPU and rendering causing some bottleneck and you'll change your mind about latency, still this is OT feel free to continue in the other topic.
Junior Irrlicht Developer.
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
User avatar
REDDemon
Developer
 
Posts: 1044
Joined: Tue Aug 31, 2010 8:06 pm
Location: Genova (Italy)

Re: The Vulkan API

Postby Mel » Mon Apr 04, 2016 2:42 pm

Well, i have already built my own "9 headed hydra" and i am wishing to see how it works, if it either goes off the scale, or if it just goes to hell and GL ends being a better API than VK is something i plan on finding out soon... The only thing i hate from VK right now is the amount of steps to set up the API. I take it is because of the variety of hardware it is aimed to, but i can't help but feel it could be much simpler.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
User avatar
Mel
Competition winner
 
Posts: 2271
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: The Vulkan API

Postby hendu » Mon Apr 04, 2016 7:22 pm

Clearly I must be doing something wrong, when I've never managed to be cpu-limited or in need of a separate rendering thread, yet for everyone else it's the second coming of Jesus :P

(devsh excepted, a proper minecraft thing is exquisitely heavy. I see how BaW pushes things.)
hendu
 
Posts: 2600
Joined: Sat Dec 18, 2010 12:53 pm

Re: The Vulkan API

Postby Granyte » Tue Apr 05, 2016 12:33 am

it depends highly on what you are doing i'm so damn cpu limited it's ridiculous
Granyte
 
Posts: 846
Joined: Tue Jan 25, 2011 11:07 pm

Re: The Vulkan API

Postby REDDemon » Tue Apr 05, 2016 8:07 am

well, you don't need to be cpu limited, you can still get advantage in simple things like a file loading, in the case it caused some lag, now it will not cause lag, and you don't have to write extra code to make it threaded. here I have a old core duo so it is much simpler for me being cpu limited than someone having a i7 XD
Junior Irrlicht Developer.
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
User avatar
REDDemon
Developer
 
Posts: 1044
Joined: Tue Aug 31, 2010 8:06 pm
Location: Genova (Italy)

Re: The Vulkan API

Postby devsh » Tue Apr 05, 2016 10:12 am

In reality cpu-boundedness of openGL calls is a non-issue, since you can use all sorts of extensions such as DSA and Nvidia OpenGL command lists or at least indirect rendering and fill up the instance buffers and uniforms on the CPU in a separate thread (OpenGL supports using GLSync objects from multiple threads)
User avatar
devsh
Competition winner
 
Posts: 1882
Joined: Tue Dec 09, 2008 6:00 pm
Location: UK

Re: The Vulkan API

Postby REDDemon » Wed Apr 06, 2016 8:48 am

well it depends..

if you have a i7, if you have a modern graphics card (possibly NVIDIA), if you are targeting GL 3.+/4.+ and you accept writing extra code to make client side blocking calls running in a thread then it is a non-issue.

One advantage of threading is not only in performance, but also in the fact that both graphics and rendering don't block each other (likely to be client code the blocking part). I have still to see if that is true but I also have the feeling that will help resolving some problems related to vsync (much more stable framerate, interpolation on threading side withouth interleaving of client code should be much more timin consistent resolving in part stuttering, wich is anyway almost solved by modern hardware and extensions)

Also I'm going to target Emscripten (by the way, econding a client side command buffer is the only way to use webworkers since webworkes cannot share data, a command buffer can be easily copied across webworkers) and GLES where such extensions are not available making a big difference there, with chance to be compatible with a lot more devices than ones supporting esotic extensions. I Still don't think that's the worst ******* idea in the universe ;)

Of course I could just wait Vulkan/VulkanMobile and don't bother doing what I'm already doing.. I could XD
Junior Irrlicht Developer.
Real value in social networks is not about "increasing" number of followers, but about getting in touch with Amazing people.
- by Me
User avatar
REDDemon
Developer
 
Posts: 1044
Joined: Tue Aug 31, 2010 8:06 pm
Location: Genova (Italy)

Re: The Vulkan API

Postby Mel » Mon Apr 11, 2016 1:31 am

https://software.intel.com/en-us/api-wi ... kan-part-1

I came across a good article about starting with Vulkan. Its level is almost for dummies, but compared to other APIs, the amount of typing you have to do (and typoing you will do :P) is huge. it is good because it pretty much covers every basic aspect you need to know, including one CRUCIAL aspect about Vulkan. It won't start working until you send a queue submit command... and somehow stops at the moment where pretty much has said everything Vulkan has, after that, you just have to start digging deeper into more elaborate ways of using the basics, and you're done with it. Vulkan, is unbelievably small compared to what DirectX or OpenGL look (to me anyway) Or at least, i think it is very small, to the point that it makes me doubt of its potential. But as they say, looks can be deceiving. I hope it is the case. And i hope you find that article interesting!
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
User avatar
Mel
Competition winner
 
Posts: 2271
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: The Vulkan API

Postby Mel » Wed Apr 20, 2016 12:05 pm

Image

"Big things have small beginings" that David8 would say...

Actually it is a remarkable achievement to get that done from scratch, and having no previous experience programming graphics on low level (OpenGL, Direct3D...) i think it is a nice starting point. It just clears the screen, yes, but is able to apply any color, or not clear the screen at all, pretty much like irr's "beginScene" and "endScene" commands.

The point of the swapchain usage though, is that it forces you to use command buffers and commands recording. So it is a good starting point.

Vulkan (and presumable DirectX12) rely on command buffer recording to the point that you can just create a whole scene (more properly would be to speak of a rendering pipeline) by just initializing a command buffer with a set of predefined commands, and play that command buffer once and again. The scene is posible to comprise it of just programmable resources, like vertex/fragment/geometry/compute programs, and the rest would be just updating the proper constants and the the whole rendering process would be just submitting that command buffer and that's all.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
User avatar
Mel
Competition winner
 
Posts: 2271
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: The Vulkan API

Postby chronologicaldot » Fri Apr 22, 2016 4:17 am

Mel wrote:Vulkan, is unbelievably small compared to what DirectX or OpenGL look (to me anyway) Or at least, i think it is very small, to the point that it makes me doubt of its potential.
... That all sounded like "Climb Mt Everest first and then after that you get to green pastures... empty, but green." X) Now I'm just being silly.
Thanks for the link!
User avatar
chronologicaldot
Competition winner
 
Posts: 560
Joined: Mon Sep 10, 2012 8:51 am

PreviousNext

Return to Everything 2d/3d Graphics

Who is online

Users browsing this forum: No registered users and 1 guest