Half Life 3 will release any day now!!! lol

As good as Vulcan promises to be I don't see this altering Linux's position very much. Thinking so obviously ignores the fact OGL has been keeping pace with DX (if not occasionally surpasing) for a very long time, to no real effect on the platform. Its always been an option, but most devs ignore it since it wasn't the API of choice on the dominant platform. Windows is the dominant gaming platform after consoles, and MS controls 1/3 of the console space at the same time. As long as MS caters to devs with an ease of cross development based on DX, more devs will continue with DX. Vulkan will likely be treated as an afterthought no different from any other version of OGL. The API is just one (small) part of the road block of Linux gaming adoption. There have certainly been OGL titles to never see a linux release. Valve has had a great effect there though, and their influence is far greater than the API alone.

so apparently, the talos principle is not full vulkan yet, its just wrapped to support vulkan: http://steamcommunity.com/app/257510/discussions/0/412447331651559970/ Edwin, engine design for Vulkan is basically consited of three major parts:\ 1) Port. Make it work as fast as possible just by wrapping current engine design around Vulkan. Avoid all pitfalls and bottlenecks. This is what we did by now and released as patch for Talos. 2) Use Vulkan for multi-threaded rendering. Our engine is designed really well for multi-threaded rendering, but we have only our wrapper for it - calls to graphics API (like Vulkan) are not multi-threaded. Yet. That being said, this is the next step what we'll do. And probably release that also as patch for Talos. I tried to do that with Direct3D 11 long time ago (support for its deffered contexts), but it was too much pain and too little or even no gain. 🙁 That's just one of reasons why we decided to stick with our own approach for MT renderer for that long. :/ 3) Redesign engine for Vulkan. This is the biggest step and can be split in two: 3a) Precache all rendering states (which mostly mean materials in game) up front. This will make rendering calls much simplier and faster. So, instead of deciding at rendering time what is needed for a material to be rendered via Vulkan, do this at loading time and then when material needs to be rendered just give it to Vulkan, via one or two simple function calls. 3b) Precache all geometry, material, textures, everything that is needed for rendering an object up front. This basically creates so called command buffer ready for Vulkan, and nothing extra needs to be set or created at render time. 3rd part of port is, obviously, the most complex one, and it'll take time to change engine design for it, step-by-step. Hope I explained this well. 🙂 DEN

Please let this become supported by lots of games devs....

A lot of people said the same thing when Mantle was introduced.

Vulkan is built on Mantle... so.. you never know.. I just hope games use it and it becomes widely supported

As good as Vulcan promises to be I don't see this altering Linux's position very much. Thinking so obviously ignores the fact OGL has been keeping pace with DX (if not occasionally surpasing) for a very long time, to no real effect on the platform. Its always been an option, but most devs ignore it since it wasn't the API of choice on the dominant platform. Windows is the dominant gaming platform after consoles, and MS controls 1/3 of the console space at the same time. As long as MS caters to devs with an ease of cross development based on DX, more devs will continue with DX. Vulkan will likely be treated as an afterthought no different from any other version of OGL. The API is just one (small) part of the road block of Linux gaming adoption. There have certainly been OGL titles to never see a linux release. Valve has had a great effect there though, and their influence is far greater than the API alone.

OpenGL hasn't really kept pace. Sure it performs nearly identically to DX in various different tasks, but the extensions/complexity/support killed it. DX contains all the libraries a developer needs to build whatever it is they are trying to accomplish. OGL has vendor specific extensions which often go completely unmaintained on various different architectures and are often undocumented. Which means the game developer would have to spend extensive time and cost either working around those issues, or rewriting the extensions themselves. That being said I agree with the general sentiment of your post. I don't think this is going to significantly impact Linux usage. The problem with Linux is the last time I installed Ubuntu, I had to spend 3+ hours configuring an xorg.conf file to get my multi-monitor setup working. Only to find out I couldn't switch headphone/speaker mode on my soundcard due to lack of proper driver support for the card. This was among numerous other configuration problems. Granted most of them aren't the problem of Linux, but OEM support in general -- but as a consumer that isn't really my problem. I just want to install the OS and have it work. I switch between Mint/Ubuntu on my laptop, and it works well there as it's a pretty standard setup. But until they sort all the configuration and driver issues on the more popular distro's, I won't be using it, Vulkan or not.

Don't expect faster performance at this point. Drivers and the implementation in their engine aren't mature yet. It will take some time before Vulkan will be faster.

Can confirm: https://dl.dropboxusercontent.com/u/8947194/g3d/talos_vulkan.png Top is DX11, bottom Vulkan, done using everything on Ultra through Auto-detect.

I disagree. While MS will still profit as you say, they would profit more if they could "force" all gamers to Windows 10 because of everything requiring DX12. They tried the same thing with Vista with Halo 2. MS wants people on Windows 10s' ecosystem with the Store and trash that comes with it.

Windows 10 is free, or it was, but Visual Studio is a significant wad of cash.

Can confirm: https://dl.dropboxusercontent.com/u/8947194/g3d/talos_vulkan.png Top is DX11, bottom Vulkan, done using everything on Ultra through Auto-detect.

yup, engine just wrapped to support Vulkan.

sidenote- haha, finally not newbie status after 13 years.

sidenote- haha, finally not newbie status after 13 years.

The ultimate lurker

Some more infos from AMD on GPUOpen: Sayhello http://gpuopen.com/say-hello/ Vulkan renderpasses: http://gpuopen.com/vulkan-renderpasses/ More update on Vulkan will be up days after days on GPUopen ( add on performances tweetseries for both DX12 and Vulkan ) AMD blog: https://community.amd.com/community/gaming/blog/2016/02/16/radeon-gpus-are-ready-for-the-vulkan-graphics-api

Can confirm: https://dl.dropboxusercontent.com/u/8947194/g3d/talos_vulkan.png Top is DX11, bottom Vulkan, done using everything on Ultra through Auto-detect.

Perhaps vsync is force-enabled? 59.7FPS doesn't convince me that the performance is in fact worse. Regardless - as with Mantle, Vulkan doesn't necessarily improve GPU performance. It's meant to be simpler to implement than OGL, and more importantly, it's supposed to reduce CPU overhead. As for Linux, I personally think Vulkan will help encourage more devs to support it. One of the issues with OGL is how much more difficult it was to work with compared to DX. But as with any API/ABI, it takes a long time to be adopted. Normally I would say DX12 would end up being far more popular, but Linux game support is growing quickly, and I'm not 100% sure if ported XB1 games will support DX12. So we'll see.

Perhaps vsync is force-enabled? 59.7FPS doesn't convince me that the performance is in fact worse. Regardless - as with Mantle, Vulkan doesn't necessarily improve GPU performance. It's meant to be simpler to implement than OGL, and more importantly, it's supposed to reduce CPU overhead. As for Linux, I personally think Vulkan will help encourage more devs to support it. One of the issues with OGL is how much more difficult it was to work with compared to DX. But as with any API/ABI, it takes a long time to be adopted. Normally I would say DX12 would end up being far more popular, but Linux game support is growing quickly, and I'm not 100% sure if ported XB1 games will support DX12. So we'll see.

I seriously doubt it is something developers will care about, more the people who create the games engines. Unreal Engine is already on board, so meh - news story over.

Oops here we go from Vulkan HW Database: Radeon R9 200 Series will support 3 queues(click on queues tab): http://vulkan.gpuinfo.org/displayreport.php?id=14 Gtx 980(Maxwell) will support 1 queue: http://vulkan.gpuinfo.org/displayreport.php?id=2 Meaning single-thread queues(Gtx) vs Multi-thread queues(Radeon).

They decided to launch it with half arsed port to the new api?? What sort of nonsense is that, it either means the api is not very good or that devs don't like it or find it hard to work with.

They decided to launch it with half arsed port to the new api?? What sort of nonsense is that, it either means the api is not very good or that devs don't like it or find it hard to work with.

Nonsense? How is that nonsense? That first port hardly says anything about the API's capabilities. Considering how it was officially released today, It's not like there was a lot of time to polish anything... Seriously, what's with the impatience and negativity? Most software that is first released has poor adoption and bug issues. Vulkan is different enough that it requires new GPU drivers, requires specific hardware, and has OS limitations. This isn't an update to OpenGL, it's entirely new. The fact that an independent developer managed to get a game ported in such a short amount of time would suggest the API is not hard to work with.

They decided to launch it with half arsed port to the new api?? What sort of nonsense is that, it either means the api is not very good or that devs don't like it or find it hard to work with.

It's more of a proof of concept at the moment, just showing that it can be done. AMD and Nvidia I'm sure will be okay with Vulcan drivers, but Qualcomm worries me for driver support. Their OpenGL ES support is awful. Same goes with Samsung.

It's nonsense as everything these days is judged on first impressions, and proof of concept or not this first impression is not good. It's not like this is a brand new api, it's based on Mantle which isn't that new anymore and allegedly ahead of DX12 nevermind DX11.

It's nonsense as everything these days is judged on first impressions, and proof of concept or not this first impression is not good. It's not like this is a brand new api, it's based on Mantle which isn't that new anymore and allegedly ahead of DX12 nevermind DX11.

The first impression is far from bad. One example isn't enough to judge something, especially when we don't know what the possible causes are for where it lags. Vulkan isn't directly based on Mantle either, but rather uses chunks of Mantle's code. If it were as simple as being a fork of Mantle, AMD could have just donated Mantle to Khronos.

The thing that is interesting about Vulkan is that it's a cross platform api, it will allow developers to not be tied down by Microsoft, it will allow better gaming on Mac, and other OS's like Steam OS for example. Future of PC gaming is looking a little more interesting that's for sure.