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 » Fri Apr 22, 2016 9:11 am

Well, i guess i lack of perspective here, I am comparing it to the 2 or something megabytes irrlicht takes ^^U Or to the fact that it doesn't provide almost anything save the most elemental GPU communication, and support for multiple GPU, the question about multiadapters memory sharing is still very green, or at least, it looks that way, it is a complete DIY API. But at the same time, if it provided more, it would "get in the way" of what you can really achieve with it.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
User avatar
Mel
Competition winner
 
Posts: 2224
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: The Vulkan API

Postby christianclavet » Fri Jun 17, 2016 12:29 am

Cool work Mel!
User avatar
christianclavet
 
Posts: 1638
Joined: Mon Apr 30, 2007 3:24 am
Location: Montreal, CANADA

Re: The Vulkan API

Postby Mel » Wed May 03, 2017 10:23 am

My own vulkan based engine :D (I must admit i've stuck to many of Irrlicht's gimmicks when it came to building it, but at least, it runs as smooth as my hard is capable of, 3000 FPS, with a sort of vertical synchronization Vulkan implements, that is not a VSync strictly but allows the screen to go without flickers much faster than VSync. I know rendering a tetrahedron isn't very interesting, but at least the set of features already available is not small:

  • a fully extensible pipeline creation system via function pointers and an internal pipeline cache.
  • a flexible mesh system allowing to build meshes in runtime, mapable both in device and system memory (i want to implement a stream system)
  • 4 vertex formats so far (it is complex to add more vertex types... but nobody says it is impossible to build a flexible vertex system on this)
  • 16/32 bit indices meshes.
  • Custom mipmap generation (Vulkan doesn't do this for you ^^U).
  • points lists, line lists, line strips, triangle lists, strips and fans primitives.
  • Cube map support (not tested yet)
  • texture arrays support, for both 2D and Cube maps (not tested yet)
  • 3D textures support (not tested yet)

And i plan on adding some more features such as:
  • Dynamic scene culling
  • Compute shaders (actually it is possible to create a compute shader and use it, but i haven't tested it yet...)
  • Hardware skinning
  • Instancing
  • Mouse/keyboard/controller support
  • Networking (But just not yet...)
  • Sound (i never said this was gonna be a graphics only engine XD)
  • Some GUI support (but i will surely end blending in an already built gui system...)
  • Some built in physics... nothing too fancy, just to be able to do some basic collision detection and that's it...
  • ... more features I sure forget...

Image

Almost any feature you want to program, you either need to program a shader for it or is fairly complex to get otherwise, for instance, if you plan on implementing instancing, you have to prepare a shader for it, as shaders become very "sticky" to the whole setup for them, They won't allow much flexibility in that matter. The gains, though, are that shaders aren't constrained neither to a minimum nor a maximum of resources, i.e. if a shader only needs 1 texture, it won't set any more texture stages, if it needs 5 or 6 or a texture array, that is what you will suply them. and that is what the shader will expect, (and if you fail to provide them, the debugging layers will complain..)
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
User avatar
Mel
Competition winner
 
Posts: 2224
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: The Vulkan API

Postby Mel » Fri May 05, 2017 4:42 pm

Let's add skyboxes... :D
Image
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
User avatar
Mel
Competition winner
 
Posts: 2224
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: The Vulkan API

Postby Mel » Sun May 07, 2017 3:56 pm

32 bit meshbuffers working properly: The polycount in this scene is over 2.000.000 (1024*1024*2) in that single sphere
Image

And still renders smooth...
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
User avatar
Mel
Competition winner
 
Posts: 2224
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: The Vulkan API

Postby robmar » Fri Jul 14, 2017 10:15 am

How's your Vulkan driver coming along Mel? Is it running as fast as with DX9, or even faster?
robmar
 
Posts: 1002
Joined: Sun Aug 14, 2011 11:30 pm

Re: The Vulkan API

Postby Mel » Wed Aug 30, 2017 10:26 pm

I've been away from the computer all this time, so i couldn't advance it QQ... But after seeing so many articles about how to pick the fastest paths with Vulkan, i think my own is very green, without multithreading nor other advances, seems that GL/DX11 is the choice (i can't speak out of experience, but i'd say DX12 is having similar issues... save if you want to program XBOX One you have to use DX12 almost forcefully XD)

I am having doubts about how to approach the memory management in Vulkan, as it seems to be one of the major responsibilities a programmer has now (i.e. before, things like video memory fragmentation were problems one would never have because those issues would lay on the system driver on DX11-/GL) as well as how to efficiently approach a fully multithreaded engine. (not only the command generation, but also the scene processing and such...) Depending on my decisions, i would have one thing or other.

So far, i got to push 18.000.000 triangles on a single meshbuffer, have 16/32 bit meshbuffers, diferent textures, mipmap generation, node/hierarchies/camera movements, generate commands per frame, all in a single thread and still run 30+fps...
https://www.instagram.com/p/BT_7o--F85e/
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
User avatar
Mel
Competition winner
 
Posts: 2224
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: The Vulkan API

Postby robmar » Sat Sep 16, 2017 8:19 am

18 millions at 30 FPS is pretty good especially if on mid-range hardware. What CPU/GPU did you use?

I manage to run just 6 million on Irrlicht 1.7.3 at 30 FPS in and AMD A10 APU.
robmar
 
Posts: 1002
Joined: Sun Aug 14, 2011 11:30 pm

Re: The Vulkan API

Postby Mel » Mon Sep 18, 2017 6:43 pm

I'm on the lowest range that can run Vulkan. The CPU is a core i7@ 3.4 GHz and the GPU is a NVidia GTX660.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
User avatar
Mel
Competition winner
 
Posts: 2224
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: The Vulkan API

Postby robmar » Thu Nov 30, 2017 3:27 pm

Have you look at or tested the Irrlicht bGFX addition, seems like the way to go to support all drivers, as long as its efficient.

I guess your Vulkan driver will be fast and easy to expand though, without all the other stuff needed for something like bGFX:
robmar
 
Posts: 1002
Joined: Sun Aug 14, 2011 11:30 pm

Re: The Vulkan API

Postby Mel » Sat Dec 02, 2017 1:59 pm

No, I havent. but i think that it isn't really a good idea to use another layer of abstraction to use Irrlicht, because, simply, Irrlicht on its own is already an abstraction over OpenGL and Direct3D11-. Instead of relying on another graphics API abstraction, Irrlicht should complete its own support on the existing ones, which are direct communication with the hardware.

Irrlicht has that it maps very well to OpenGL and DirectX so writting a Vulkan video driver is not a very good idea. Vulkan is as stateless as it gets and has no renderstates to change as the SMaterial does with Irrlicht, or they are a minimal set, so every combination of material types, renderstates and vertex types should be made explicit to use it with Vulkan, not to speak about rendertargets, which would increase the combinatory explosion even more, and creating a pipeline isn't trivial, to the point that Vulkan supports saving and loading pipelines to disk cache. Vulkan, for instance, doesn't allow you to use a pipeline (A material) on a diferent vertex type than the one you provided when you created it (on creation, the pipelines need to know what kind of vertex are they going to use), It is not that simple. Also, multithreading isn't very recomendable with Irrlicht because of its nature, synchronizing with the state machine would stall more the rendering operations than anything else. The irrlicht video driver is meant to use an immediate rendering API, something that vulkan is not.

The good thing, although, is that Irrlicht scene tree can be (and i think it should be) adapted into a multithreaded processing, reducing a lot the time needed to start the rendering process, So, if instead of rendering immediately during the scene processing, perhaps the scene tree was processed in parallel, and later, the rendering done straight, it would ease its transition to the command recording APIs such as METAL, VULKAN or Direct3D12
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
User avatar
Mel
Competition winner
 
Posts: 2224
Joined: Wed May 07, 2008 11:40 am
Location: Granada, Spain

Re: The Vulkan API

Postby robmar » Fri Dec 15, 2017 3:59 pm

Okay, so create n threads to process node animation (pos change), and rendering preparation up to the actual rendering point, then render the lot in the main thread, doesn't sound too difficult, is that what you mean?

I don't know how much overhead bGFX would have, but I guess to get the most out of the hardware what you say must be true.

How developed is the DX11 driver at the moment? I'm using a modified version of 1.7.3, will I be able to add it to that without too many changes???
robmar
 
Posts: 1002
Joined: Sun Aug 14, 2011 11:30 pm

Previous

Return to Everything 2d/3d Graphics

Who is online

Users browsing this forum: No registered users and 1 guest