Results 1 to 8 of 8

Thread: Is Vulkan important?

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1

    Is Vulkan important?

    Is it necessary to go for Vukan or can you stay with Firemonkey until Idera implements Firemonkey in Vulkan? (Performance for game development)

  2. #2
    If you are interested in good steady game performance then I'm afraid FireMonkey isn't the best choice. You see FireMonkey is primarily designed for application development. While you can stil develop games with it it FireMonkey isn't the best choice for this.

    By the way Firemonkey and Vulkan are two completely different things.
    Firemonkey is a set of libraries that allows development of graphic rich applications. In order to do this Firemonkey uses advanced graphical API-s for content rendering like DirectX or OpenGL instead of using GDI rendering as the VCL does.
    Vulkan is one of those advanced graphical API-s that allow programs to communicate with graphics card efficiently similar to DirectX or OpenGL.

    As for Idera/Embarcadero adding Vulkan support to FireMonkey I seriously doubt this would solve all performance issues FireMonkey has. The main reason for this is the way how FireMonkey is developed internally. If FireMonkey performance would be only affected by the graphical API the FireMonkey uses for rendering the it should be reaching similar performance to other DirectX or OpenGL based graphical engines but it does not.

  3. #3
    Thank you for your reply. I am very surprised about your answer and, to be honest, I cannot believe everything. I always thought that the main limiting factor for performance was the graphics card. Delphi does not anything else than every other 3D graphics engines. It sends out vertices to the graphics card. Delphi is even more respective to the underlying system architectures. For Windows it uses directX. I can't see where the performance could be freined. Even JavaScript achieves good 3d performance. I can't believe that Firemonkey in a compiled language could be slower than JavaScript scripts or C# bytecode. It does not anything else than sending vertices to the graphics cards, by an abstraction of the underlying graphics API. It can be true that very high level controls in Delphi are not programmed with the necessary performance. But for the main 3D functionality Firemonkey should be the same level as C++ OpenGL, on Windows even faster because of directX. With the Vulkan libraries support there should be the same performance as in C++ Vulkan applications. That was not even my original question. This was already clear for me. Therefore I am very surprised that you even disagree in my first suppositions. Do you have any informations or tests? That would be very strange. My question was only about the gain of performance of the Vulkan libraries themselves.

  4. #4
    Quote Originally Posted by gerdich View Post
    I am very surprised about your answer and, to be honest, I cannot believe everything. I always thought that the main limiting factor for performance was the graphics card.
    Raw computational power of your graphic cards means nothing if the Graphical Engine is poorly implemented and doesn't use it properly.

    Quote Originally Posted by gerdich View Post
    Delphi does not anything else than every other 3D graphics engines. It sends out vertices to the graphics card. Delphi is even more respective to the underlying system architectures. For Windows it uses directX. I can't see where the performance could be freined.
    According to my observations it does. I'm not sure what and how since Delphi doesn't ship with full source code for FireMonkey but I could never achieve performance of FireMonkey which would be even close to some other graphical engines.

    Quote Originally Posted by gerdich View Post
    I can't believe that Firemonkey in a compiled language could be slower than JavaScript scripts or C# bytecode. It does not anything else than sending vertices to the graphics cards, by an abstraction of the underlying graphics API. It can be true that very high level controls in Delphi are not programmed with the necessary performance.
    How could you then explain the masive performance difference seen with Asphyre Sphinx 3 game engine when you were using built in rendering and ran very fast versus FireMonkey rendering which was about 20 to 30 percent slower and was required if you wanted to use FireMonkey controls for UI development instead of designing your own UI from scratch.


    Quote Originally Posted by gerdich View Post
    But for the main 3D functionality Firemonkey should be the same level as C++ OpenGL, on Windows even faster because of directX.
    FireMonkey could never reach same performance as working directly with DirectX or OpenGL. Why? Because FireMonkey represents just another abstract layer on top of these API's. And as we all now each abstract layer costs some performance.
    I also see you are one of those people who are convinced that DirectX on Windows is much better than OpenGL. Well it is not. Instead they are pretty much equal. Sure if you are using graphical drivers that sip with windows then you don't expect to get muc performance when using OpenGL. Just another Microsoft attempt to keep DirecX relevant. But if you install vendors drivers for your graphics card then you are good to go.

    Any way in the end performance greatly relies on how optimized is the games graphical engine for working with specific graphical API. This is why some games run better in DirectX and some run better in OpenGL.

    [QUOTE=gerdich;148967]Do you have any informations or tests?

    Unfortunately I don't have any test available any more since it is some time from when I was evaluating FireMonkey for usage in game development. But in my last attempt I couldn't even make a complex UI for economic based sim game (lots of graphs and lists) without lowering FPS below 60. And this was only UI without the actual game scene.

    Quote Originally Posted by gerdich View Post
    My question was only about the gain of performance of the Vulkan libraries themselves.
    Here is another misconception people have about the Vulkan libraries. People think that switching to Vulkan will magically improve performance. But that won't happen.
    So how do then some games run much better when using Vulkan API in comparison of using OpenGL or DirectX?
    The reason for this is the fact that Vulkan allows much better control over the rendering pipeline and thus allows much better optimizations. Without that additional optimization there would be no performance gain whatsoever.

    And now for your question of whether FireMonkey performance would increase if FireMonkey starts using Vulkan API. I seriously doubt it. Why? Because if you want to get most out of the graphical engine then you need to optimize that graphical engine for its specific needs for specific scenario. But FireMonkey on the other end tries to support as many possible scenarios as possible. And it is practically impossible of optimizing something for so many possible scenarios because when you try improving performance for one scenario you may be hurting performance for another.

  5. #5
    "OpenGL or Vulkan" would be reasonable question. The one you are asking doesn't make sense because Firemonkey is Embarcadero's take on making cross platform gui applications easily while Vulkan is API for communicating with graphics card. Apples and oranges.

  6. #6
    I have to make a new application (C ++ / Qt), integrating a graphical interface. I am facing a big dilemma and I would like your opinion because I do not think I have enough perspective. Will Vulkan really replace long-term OpenGL? Which is the most profitable according to you?
    thank you in advance.


    VPN Sai Mannat AnyDesk
    Last edited by davido; 26-11-2019 at 10:46 PM.

  7. #7
    >Will Vulkan really replace long-term OpenGL?
    I've never tried Vulkan myself but I watch threads regularly @ GameDev.ru and I gained some insight into it.

    Vulkan has *extremely* high entrance threshold. Many menial tasks the OGL / DX driver performs "under the hood", tasks you never had idea exist (like syncing memory access between rendering stages), Vulkan requires you to program explicitly. Thus, even to make a rotating cube work you have to have very good in-depth understanding of how videocards work and their components interact.

    So, a simple answer, no. It is possible that OGL / DX will be (or already are) rewritten to be wrappers around Vulkan, but it the fact is Vulkan is a tool for seasoned pro veterans. 95% applications out there don't need such level of control over the video card.

  8. #8
    For my 2 cents, I don't see OGL going away before a long time, since it's heavily present everywhere and more into pro-software.
    I see more Vulkan replacing DirectX, but anyway.
    I'm in the same boat as SilverWarior considering Vulkan isn't a magical thing to resolve any problem/optimization. As usual we will see if it will live the hype.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •