Hacker News Reader

Comment by runeks | Hacker News Reader

Good point. Vulkan's purpose is for GPU hardware companies to stop having to write graphics software (drivers). GPU producers shouldn't be responsible for writing OpenGL compilers any more than AMD and Intel should be responsible for writing C/C++ compilers and Python VMs.

As I understand it, the goal is to move the API closer to the hardware. Hopefully so close that the driver will be very thin. There are plenty of software developers out there who can implement an OpenGL driver in Vulkan as well as the employees of AMD and Nvidia, I would think.

View on HN

I hope this is right.

Having to rely on companies to update their drivers or open the source code has been a major pain point for a long time. Especially on mobile where there are many custom chips from different companies.

Sure, but:

If Vulkan is too low level, perf will could be absolutely terrible. If chip makers expect a third party to -effectively- write an optimizing compiler for their graphics chips, they're probably[0] gonna have to tell people a lot more about those chips than they do already.

Worst case, maybe we're looking at another Itanium failure where noone decides that it's worth it to write such software.

(Note: I know next-to-nothing about Vulkan and only slightly more about modern graphics programming[1]. It's entirely possible that this worry is wholly unfounded. Also, given that the open-source AMD/ATI driver exists and has decent performance, it's highly unlikely that this will be a repeat of the Itanium failure.)

[0] Really, "they" is largely code for "Nvidia". :p

[1] I did a fair bit of fixed-function OpenGL software in a former life, tho! Remarkable how poor and ever-changing the support for that was from one NVidia driver revision to the next.

Developers have been asking for Vulkan for years. Essentially Vulkan and OpenGL ES provide two fundamental choices: going low level for highly tuned, architecture-specific optimizations (i.e. game engines) or high level, respectively, for quick and easy code writing that can run across multiple platforms (i.e. a simple UI or a 2D game).

> Developers have been asking for Vulkan for years.

I would wager that a very large slice of the folks doing graphics programming are largely incapable of writing a new high-performance graphics card driver.

Is there demand? Sure. Does anyone want to exert the effort required to meet that demand? I don't know.

Once upon a time, the CPU manufacturers were demanding a CPU that was easier for them to design, but just as performant. This lead to the Itanium, which had a simple hardware design but required very complex compilers for optimal performance. Thing is, noone wanted to expend the effort required to make a sufficiently clever compiler in order to get the best perf possible out of the CPU.

Anyway, if you can deliver more than platitudes, I'm all ears. I'm pretty ignorant on the topic and would love more information. :)

When I say developers, I mean graphics people like Unity, Epic, Gameloft, Steam etc. who want to have more control over performance optimization. When OpenGL was first designed, GPUs were fixed-function hardware that performed only a fraction of the tasks they handle now. Vulkan has been designed to be aware of tile-based renderers so that these developers can use them more efficiently. Driver and compiler development is a different topic although it is true that some parts of the driver will be more easier to write and manage.

> When I say developers, I mean graphics people like Unity...

Oh. You mean modern game 3D engine development houses. Okay. :) I would expect that these companies would be far more likely to employ very smart people than some random software house that also does OGL/D3D-driven graphics. However -as you allude to in your comment- skill in engine design and construction does not guarantee skill in graphics driver design and construction.

> When OpenGL was first designed, GPUs were fixed-function hardware...

Oh, I know. In my first message in this thread, I mention the fixed-function work that I did in a former life. I've read about OpenGL back when it was just SGI's GL. I've even made use of OpenGL's network transparency! :)

I think you've lost sight of why I started this thread.

runeks wrote:

> Vulkan's purpose is for GPU hardware companies to stop having to write graphics software (drivers)... Hopefully [Vulkan's API will be] so close [to the metal] that the driver will be very thin.

bobajeff replied:

> Having to rely on companies to update their drivers or open the source code has been a major pain point for a long time.

bobajeff seems to be thinking that Vulkan development will be handled primarily by third parties.

runeks's comment reminded of Itanium, a CPU whose programming API -as one could call it- was very, very thin; requiring compiler authors to do a huge amount of work -such as instruction scheduling- traditionally done by logic in the hardware.

A big reason Itanium failed in the wider market was because it asked far too much of what -i guess- could be called CPU driver writers. It hid far too little of what was required to get good performance out of modern CPUs, instead demanding that that work be offloaded on to compiler authors.

Do you see why I might be concerned about the same sort of problems with Vulkan? Can you provide some technical -rather than social- details about Vulkan plans to assuage this concern?

Ah, I see what you mean. I was thinking more in terms of market-driven motives for adoption rather than technical facts. Unfortunately, Vulkan is currently still under development and under strict NDA so I can't disclose any of the inner workings at this moment in time (beyond what we have posted on the blog). However, when the spec is final and public, we will talk a lot about the technical implications in more detail, offering code snippets and tutorials so developers can understand how to use Vulkan.

When it comes to Vulkan development, it is a pretty much a joint effort. We (the GPU providers) design the graphics processors and write the drivers/compilers to support Khronos. Then the application developers (the middleware guys) adopt their engines and libraries for Vulkan too in cooperation with us and other members of Khronos. Finally, the high-level application developers (e.g. games developers) port their software too. In addition, third parties might also create Vulkan open source drivers and compilers for the GPUs so it's a combination of in-house and third-party work.

But Intel does make a C/C++ compiler!

Not quite although I get your point. Vulkan is designed for developers that want to get close to the metal (e.g. game engine guys). OpenGL ES will still live for high-level rendering.

Reply on news.ycombinator.com