Nvidia pushes more OpenGL and Vulkan blog posts for developers

From what I understand, documentation and support have been the two biggest obstacles to OpenGL. Hopefully things are starting to turn around.

Quoting: Mountain ManFrom what I understand, documentation and support have been the two biggest obstacles to OpenGL. Hopefully things are starting to turn around.

Also drivers' low quality. And decades of stratified features: there are at least 10 possible ways to do something in OpenGL, but only 1 is the fast path, and this path is very narrow, and oftentimes difficult to identify (because of poor documentation and drivers' idiosyncrasies).
So the net result is, generally, shoddy performance.


Last edited by whatever on 12 February 2016 at 5:07 pm UTC

Perfomance wise between Windows and Vulkan is just horrible..almost getting 10FPS less in the same games...

#GoVegan
#Steam

Quoting: metro2033fanboyPerfomance wise between Windows and Vulkan is just horrible..almost getting 10FPS less in the same games...

Did you accidentally send this message from the future? Vulkan hasn't actually been released, and none of your games run on it yet. :)

Quoting: tuubi

Quoting: metro2033fanboyPerfomance wise between Windows and Vulkan is just horrible..almost getting 10FPS less in the same games...

Did you accidentally send this message from the future? Vulkan hasn't actually been released, and none of your games run on it yet. :)

???
What are you talking about there mate?

10 FPS is too much, but I surely see a constant 5% difference. UT on Vulkan + Linux actually even run quite better than Win + DX12, since they decided to change the main developing platform for the game. Thanks to the Win 10 scandal two years ago hehehehe. Gj Epic :-)


Last edited by khalismur on 13 February 2016 at 1:44 pm UTC

Quoting: khalismur

Quoting: tuubiDid you accidentally send this message from the future? Vulkan hasn't actually been released, and none of your games run on it yet. :)

???
What are you talking about there mate?

10 FPS is too much, but I surely see a constant 5% difference. UT on Vulkan + Linux actually even run quite better than Win + DX12, since they decided to change the main developing platform for the game. Thanks to the Win 10 scandal two years ago hehehehe. Gj Epic :-)

Hey Doctor, I think you need to get your Tardis checked. Apparently you landed a couple of years off target. And take the other time traveller with you. You know, the one who seems to enjoy steamed vegetables and thinks this blog is actually twitter.

How are you gauging Vulkan performance? Vulkan hasn't been offficially released yet. No official drivers exist for any chipset. No game or game engine officially supports it yet. Do you have access to unreleased drivers and unreleased builds of games?

Quoting: barotto

Quoting: Mountain ManFrom what I understand, documentation and support have been the two biggest obstacles to OpenGL. Hopefully things are starting to turn around.

Also drivers' low quality. And decades of stratified features: there are at least 10 possible ways to do something in OpenGL, but only 1 is the fast path, and this path is very narrow, and oftentimes difficult to identify (because of poor documentation and drivers' idiosyncrasies).
So the net result is, generally, shoddy performance.

As far as I am aware, OpenGL drivers ( at least the AMD and NVidia binaries ) perform exactly as you would expect. They do have bugs ( as all code does ), but in general they correctly implement the current OpenGL programming model ( 4.x ), and provide backward compatibility both for previous OpenGL programming models ( 1.x, 2.x, 3.x ) on current generation hardware, and for all OpenGL programming models on older generation hardware. A lot of the backward compatibility, of necessity, is implemented by the driver more slowly than if using the current programming model on current hardware ( surprise! ), because, amongst other reasons, any OpenGL feature where hardware acceleration is not available will be implemented in software on the CPU.

This is actually no different to the situation with D3D on Windows. Does anyone think that writing a 2016 game using the D3D8 API would result in a stellar experience? Probably not, but a lot of OpenGL code still uses compatibility contexts and long obsolete functions associated with them from the same era as D3D8. Perhaps this is the fault of the way OpenGL has historically been specified. There has always been a view that they should try to accommodate every existing OpenGL developer when updating the specification, by not breaking things; I think this just leads to confusion as to what you should and should not use.

The other issue ( apart from using the wrong APIs through ignorance ) that causes developers to write sub-optimal code is the inability of the open source drivers to support the current programming model, and the variability of the open source software versions in the different Linux distributions used. This would be irrelevant except that Intel graphics hardware is still about 20% of the gaming market on Linux, which is itself already a tiny market. If developers want to cover the whole Linux market, there is a strong argument to use older APIs, which are generally not performant on modern AMD and NVidia hardware.

However, it is fair to say that it is not necessarily obvious for a programmer new to OpenGL to work out what they should and should not use because there is no single source pushing out information and tools as there is with D3D. The canonical information source is the Khronos specifications, but these are quite dry as they are intended for driver implementers. AMD and NVidia are, of course, also good sources of tools and information, but they will not always be unbiased.

But the best way learn to use OpenGL is simply to read a lot of books. If you read just one, you will probably get a skewed view. Each author has a particular goal in mind, and can only give you subset of the information you need to be a competent 3D coder.

For the avoidance of doubt, if you are writing OpenGL code in 2016, you should be using OpenGL 4.x APIs only, you should be using a "core" OpenGL context ( which removes access to all the really obsolete APIs and ways of doing things ), and in general you should be organizing your data in large buffers, preferably using bindless resources and indirect drawing commands. If you do this, you will probably see little performance benefit from moving to Vulkan ( although there may be other reasons you may want to switch ). This is what NVidia say ( the second blog link in the above article ) and what AMD say ( "OpenGL Superbible" seventh edition, written by Graham Sellers, the AMD rep at Khronos for OpenGL and Vulkan - also the Vulkan specification editor ).

Unfortunately, not all 2016 OpenGL games will follow ( or be able to follow ) these recommendations.