5 ms·

Very exciting! I wonder: when will we be able to start making projects with this? It would be interesting to see how it compares with OpenCL when it comes to do

Very exciting! I wonder: when will we be able to start making projects with this? It would be interesting to see how it compares with OpenCL when it comes to doing things like Bullet physics' GPU rigid body solver and so on. Also, of course, ray tracing! :D

yuumei 12y ago
Maybe there isn't a spec yet, but it seems there are demos running through vulkan: http://blog.imgtec.com/powervr/trying-out-the-new-vulkan-graphics-api-on-powervr-gpus http://blog.imgtec.com/powervr/trying-out-the-new-vulkan-gra...
- toxicFork 12y ago
  Thanks, this article has some really useful comments. Here's another thread on r/gamedev about it[1]. Not much discussion as of now but hopefully as people wake up it may have interesting comments too. [1]: http://www.reddit.com/r/gamedev/comments/2xrobv/an_overview_of_vulkan_the_new_graphics_and/ http://www.reddit.com/r/gamedev/comments/2xrobv/an_overview_...
runeks 12y ago
I'm by no means an expert in the field, but if I understand the role of Vulkan correctly, you -- as an application developer -- won't be writing your programs against the Vulkan API. OpenCL will become a library that is implemented by interacting with the GPU via the Vulkan API, and as an application developer you'd use OpenCL. Or perhaps you'd never again use OpenCL, because someone else develops a better library. Perhaps someone creates a Haskell library -- which talks to the GPU via the Vulkan API -- that implements a map function that executes in parallel on the GPU. In that case you wouldn't use OpenCL or Vulkan directly at all.
- shmerl 12y ago
  > I'm by no means an expert in the field, but if I understand the role of Vulkan correctly, you -- as an application developer -- won't be writing your programs against the Vulkan API. If I understood correctly, for graphics at least Vulkan gives great flexibility to application developers, giving them to decide how to manage multithreading. If developers care about high efficiency (and games usually do need it), they'll use it. Of course if developers are using third party engines which already handle it for them, they might not need to deal with Vulkan directly. But engine developers would have to in such case.
  - runeks 12y ago
    I agree. Engine developers would target Vulkan. But I don't consider a game engine to be an application. It's more of a library, I would say. The game that uses the engine is the application.
    - shmerl 12y ago
      Many games write their own engines, so I'd say that it concerns game developers too. They better understand the underlying logic anyway. By the way, it looks like Vulkan doesn't get rid of single thread bottleneck for submitting commands to the GPU: https://news.ycombinator.com/item?id=9140849 https://news.ycombinator.com/item?id=9140849 It doesn't look competitive in comparison with DX12 and Mantle.

yuumei 12y ago

Maybe there isn't a spec yet, but it seems there are demos running through vulkan: http://blog.imgtec.com/powervr/trying-out-the-new-vulkan-graphics-api-on-powervr-gpus http://blog.imgtec.com/powervr/trying-out-the-new-vulkan-gra...

toxicFork 12y ago
Thanks, this article has some really useful comments. Here's another thread on r/gamedev about it[1]. Not much discussion as of now but hopefully as people wake up it may have interesting comments too. [1]: http://www.reddit.com/r/gamedev/comments/2xrobv/an_overview_of_vulkan_the_new_graphics_and/ http://www.reddit.com/r/gamedev/comments/2xrobv/an_overview_...

runeks 12y ago

I'm by no means an expert in the field, but if I understand the role of Vulkan correctly, you -- as an application developer -- won't be writing your programs against the Vulkan API. OpenCL will become a library that is implemented by interacting with the GPU via the Vulkan API, and as an application developer you'd use OpenCL. Or perhaps you'd never again use OpenCL, because someone else develops a better library. Perhaps someone creates a Haskell library -- which talks to the GPU via the Vulkan API -- that implements a map function that executes in parallel on the GPU. In that case you wouldn't use OpenCL or Vulkan directly at all.

shmerl 12y ago
> I'm by no means an expert in the field, but if I understand the role of Vulkan correctly, you -- as an application developer -- won't be writing your programs against the Vulkan API. If I understood correctly, for graphics at least Vulkan gives great flexibility to application developers, giving them to decide how to manage multithreading. If developers care about high efficiency (and games usually do need it), they'll use it. Of course if developers are using third party engines which already handle it for them, they might not need to deal with Vulkan directly. But engine developers would have to in such case.
- runeks 12y ago
  I agree. Engine developers would target Vulkan. But I don't consider a game engine to be an application. It's more of a library, I would say. The game that uses the engine is the application.
  - shmerl 12y ago
    Many games write their own engines, so I'd say that it concerns game developers too. They better understand the underlying logic anyway. By the way, it looks like Vulkan doesn't get rid of single thread bottleneck for submitting commands to the GPU: https://news.ycombinator.com/item?id=9140849 https://news.ycombinator.com/item?id=9140849 It doesn't look competitive in comparison with DX12 and Mantle.