• Advertisement
Sign in to follow this  

Vulkan Advises for graphics APIs to learn

Recommended Posts

Hey Guys,

 

I have being playing around directx since dx9 to dx12, and haven't touch any other graphics APIs yet. For all those years, I really enjoy developing dx with all its helping tools/libs: dx debuglayer, GPU-validation layer, GPUView, VSGD, and recently, the PIX. Now I have to switch to use mac os (and ios maybe?) exclusively in the near future. So I need to pick up another compatible graphics API to play with. What I really enjoy is DX12 style lower level APIs, and have heard that there are maybe only two choices for me: Vulkan (not sure mac os support it or not?) and Metal.

 

Since I haven't touched either APIs, I really wish to know what you guys think of it: is it in a mature state for beginner? (I remember when I work on my first DX12 project when DX12 just coming out, driver bugs drives me crazy....) are there any good GPU debug tools available for the API? (does Metal get renderDoc support?) are there any good profiling tools? (like GPUView for DX) are there plenty of tutorials/samples on the internet for beginners?

 

Also it will be great if anyone could talk about the general pros and cons for using Vulkan/Metal on apple devices.

 

Thanks in advance 

Share this post


Link to post
Share on other sites
Advertisement

edit - and opengl but you said you wanted low level.

 

I know Vulkan and Metal are *really* low level, but are we at the point where opengl is considered NOT low level?

Share this post


Link to post
Share on other sites

I know Vulkan and Metal are *really* low level, but are we at the point where opengl is considered NOT low level?

Then what API do you consider high-level?  Most things are handled for you in Opengl aren't they?  That makes it high level to me.  Also I wouldn't call Vulkan "*really* low level" I would call it lower level then previous API's.  It's constructs are still IHV agnostic... so it not that low level. 

Share this post


Link to post
Share on other sites

Cant you like just look at RenderDoc's project page? https://github.com/baldurk/renderdoc
Sorry for my laziness,  I thought since I already ask a lot, it may not be super annoying to add such easy-to-find question, maybe someone work for renderdoc could reveal their real 'future plan' in this thread......

but are we at the point where opengl is considered NOT low level?
well, I really wish to be exposed to explicit resource barrier (handling resource transition by myself) which IIRC is not available in openGL 

Share this post


Link to post
Share on other sites

So it seems 'cross-platform' Vulkan could only work on windows, linux/unix (for desktop/laptop)? Feel really bad to see that 'cross-platform' is narrowing down....  

 

If I got it correctly writing driver for Vulkan should be easier than writing for OpenGL( since lots responsibilities is moving from driver to developer) Why mac os have opengl support but not Vulkan? (I don't have any experience with mac before....)

Share this post


Link to post
Share on other sites

Because in OSX it isn't up to the vendors. Apple supplies the "frontend" of the API, thus for example, you only get the OpenGL versions Apple supports, nothing more, nothing less.

Its the same for Vulkan. They dont want it in their OS.

Share this post


Link to post
Share on other sites

Why mac os have opengl support but not Vulkan?

Because backwards compatibility... as in before metal (which is relatively new) the 3d api for mac's was opengl.  Then they decided to support the in house metal instead of vulkan. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Tags

  • Advertisement
  • Popular Now

  • Similar Content

    • By AxeGuywithanAxe
      I wanted to see how others are currently handling descriptor heap updates and management.
      I've read a few articles and there tends to be three major strategies :
      1 ) You split up descriptor heaps per shader stage ( i.e one for vertex shader , pixel , hull, etc)
      2) You have one descriptor heap for an entire pipeline
      3) You split up descriptor heaps for update each update frequency (i.e EResourceSet_PerInstance , EResourceSet_PerPass , EResourceSet_PerMaterial, etc)
      The benefits of the first two approaches is that it makes it easier to port current code, and descriptor / resource descriptor management and updating tends to be easier to manage, but it seems to be not as efficient.
      The benefits of the third approach seems to be that it's the most efficient because you only manage and update objects when they change.
    • By khawk
      CRYENGINE has released their latest version with support for Vulkan, Substance integration, and more. Learn more from their announcement and check out the highlights below.
      Substance Integration
      CRYENGINE uses Substance internally in their workflow and have released a direct integration.
       
      Vulkan API
      A beta version of the Vulkan renderer to accompany the DX12 implementation. Vulkan is a cross-platform 3D graphics and compute API that enables developers to have high-performance real-time 3D graphics applications with balanced CPU/GPU usage. 

       
      Entity Components
      CRYENGINE has addressed a longstanding issue with game code managing entities within the level. The Entity Component System adds a modular and intuitive method to construct games.
      And More
      View the full release details at the CRYENGINE announcement here.

      View full story
    • By khawk
      The AMD GPU Open website has posted a brief tutorial providing an overview of objects in the Vulkan API. From the article:
      Read more at http://gpuopen.com/understanding-vulkan-objects/.


      View full story
    • By HateWork
      Hello guys,
      My math is failing and can't get my orthographic projection matrix to work in Vulkan 1.0 (my implementation works great in D3D11 and D3D12). Specifically, there's nothing being drawn on the screen when using an ortho matrix but my perspective projection matrix work fantastic!
      I use glm with defines GLM_FORCE_LEFT_HANDED and GLM_FORCE_DEPTH_ZERO_TO_ONE (to handle 0 to 1 depth).
      This is how i define my matrices:
      m_projection_matrix = glm::perspective(glm::radians(fov), aspect_ratio, 0.1f, 100.0f); m_ortho_matrix = glm::ortho(0.0f, (float)width, (float)height, 0.0f, 0.1f, 100.0f); // I also tried 0.0f and 1.0f for depth near and far, the same I set and work for D3D but in Vulkan it doesn't work either. Then I premultiply both matrices with a "fix matrix" to invert the Y axis:
      glm::mat4 matrix_fix = {1.0f, 0.0f, 0.0f, 0.0f, 0.0f, -1.0f, 0.0f, 0.0f, 0.0f, 0.0f, 1.0f, 0.0f, 0.0f, 0.0f, 0.0f, 1.0f}; m_projection_matrix = m_projection_matrix * matrix_fix; m_ortho_matrix = m_ortho_matrix * matrix_fix; This fix matrix works good in tandem with GLM_FORCE_DEPTH_ZERO_TO_ONE.
      Model/World matrix is the identity matrix:
      glm::mat4 m_world_matrix(1.0f); Then finally this is how i set my view matrix:
      // Yes, I use Euler angles (don't bring the gimbal lock topic here, lol). They work great with my cameras in D3D too! m_view_matrix = glm::yawPitchRoll(glm::radians(m_rotation.y), glm::radians(m_rotation.x), glm::radians(m_rotation.z)); m_view_matrix = glm::translate(m_view_matrix, -m_position); That's all guys, in my shaders I correctly multiply all 3 matrices with the position vector and as I said, the perspective matrix works really good but my ortho matrix displays no geometry.
      EDIT: My vertex data is also on the right track, I use the same geometry in D3D and it works great: 256.0f units means 256 points/dots/pixels wide.
      What could I possibly be doing wrong or missing?
      Big thanks guys any help would be greatly appreciated. Keep on coding, cheers.
       
    • By TheSargKyle
      My team and I are developing a game engine! We would like as much help as possible. The project is currently hobby only, but pay will be appropriately rolled out to those who work on the engine. people we are looking for are:
      Network Programmer Artist For User Interface Physics Programmer Graphics Programmer Prerequisites wanted, but not needed, are: 
      Intermediate C++ knowledge 1 Yr in Game development Industry Thank you for your intrest in the project. You can contact me at my email: thesargkyle@gmail.com or my discord: TheSargKyle#8978
  • Advertisement