Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vulkan – Graphics and computing belong together

khronos.org

Post reply on HN
Print view View original

71–80 of 97 posts

Re: Vulkan – Graphics and computing belong together

#71

Post by TD-Linux »

mattnewport wrote: post #61
runeks wrote: post #32

I applaud this effort. I hope we can get to a point where a GPU requires as many drivers as a CPU. I think one of the primary reasons more people don't target GPUs to offload computation, is because it -- most often -- requires proprietary drivers running on the host OS, for it to work (at an acceptable speed). Imagine if putting an AMD of nVidia card in your box was the same as adding a CPU. If you wanted to write O…

There have been significant benefits to having a driver / runtime layer between the application and the GPU. It has enabled a competitive ecosystem of GPU vendors and I don't think we would have seen as rapid a pace of innovation and performance improvements if we had had a de facto low level hardware interface proprietary to a particular vendor. This is not to criticize Vulkan, the trend to lower level APIs like Vul…

Having open GPU ISA's is not the same as requiring them all to be the same. GCC and LLVM both compile to a variety of architectures but manage to share a lot of code and optimizations between all of the targets.

Having the same for GPUs, where the vendor gives you an ISA and you can use whatever compiler you like (even hand written assembly), would be a lot more preferable. This is what the open-source Gallium3D stack does, though it's hindered by relying on reverse-engineered information.

Re: Vulkan – Graphics and computing belong together

#72

Post by taeric »

pjmlp wrote: post #70
taeric wrote: post #67

Earlier quoted context omitted.

I would imagine it comes down to costs. If this api does a good job, why spend the effort (read: money) to create a new one with all of the tooling around it? Though, I should note I doubt this will really save much. Just, on paper it is a costs savings. (Unless, as usual, I'm wrong on something.)

Consoles tend to have custom hardware architectures that don't map at all to generic APIs.

I think that was a more true statement before MS enterred the game.

Also, for something as low level as this api sounds, it probably mapped decently, while still requiring another set of primitives for processor and memory control.

That is, I think the point of this api is to be a subset that can remain a bit more common between platforms. Not the all inclusive api that rules everything.

Re: Vulkan – Graphics and computing belong together

#75

Post by green7ea »

graycoder wrote: post #58
moron4hire wrote: post #54

Earlier quoted context omitted.

I'm not really sure what exactly they are. I know I've had to update my BIOS to be able to use newer versions of CPUs that still fit in the old sockets before [1]. I know I've seen Windows updates for both the motherboard's chipset and for the CPU. But what difference any of that has made, I don't know. [1] Actually, that particular instance was a complete pain in the ass, because I had bought all of the parts new, b…

You seem to be mixing up different concepts. The BIOS runs outside of the OS and helps all the parts of your computer speak to each other. This is why the process is a bit more involved than just running an update from your OS's update manager. The "binary blob" that's referred to when talking about GPU's is the huge piece of software that you have to download and install in order to make you graphics card able to us…

There is actually a binary blob for processors that the BIOS is responsible for loading. The biggest difference is that you aren't responsible for downloading it as it is usually included with your motherboard (as the grandparent says). You can find CPU binary blobs in the open source Core Boot BIOS much like you can find the GPU binary blobs in the Linux kernel.

Re: Vulkan – Graphics and computing belong together

#76

Post by shmerl »

From this diagram[1] it looks like they didn't get rid of the single thread bottleneck for submitting commands to the GPU (which can handle commands in parallel). Didn't Mantle allow parallel submission for that instead of using a single thread with one queue? DX12 supposedly allows that as well. If Vulkan won't allow it, it will be at a disadvantage.

1. https://i.imgur.com/x1CJO96.png

Re: Vulkan – Graphics and computing belong together

#78

Post by runeks »

shmerl wrote: post #63
runeks wrote: post #36

Earlier quoted context omitted.

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. P…

> 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), the…

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.

Re: Vulkan – Graphics and computing belong together

#79

Post by tree_of_item »

nightski wrote: post #59
runeks wrote: post #56

Earlier quoted context omitted.

A driver is always required in order for the OS to speak to hardware. That's essentially what a driver is: an interface between software and hardware. With CPUs, the code needed to run in the host OS (the driver) is fairly simple code that gives access to the CPU hardware more or less as it is: practically speaking, everything the CPU itself can do, the compiler can output code to do directly. The output of the compi…

Wasn't this approach taken with good reason though? So the effort to get code running on multiple GPUs was a reasonable? Remember the days of when games would only support select GPUs? Sure you could have a standard like i386. But isn't it the case that there is a lot more innovation happening in the GPU architecture space making this very difficult?

This is the rhetoric GPU vendors will use to justify their behavior, of course, but $billions and modern technology can address this if AMD and Nvidia feel that it is important.

Re: Vulkan – Graphics and computing belong together

#80

Post by shmerl »

runeks wrote: post #78
shmerl wrote: post #63

Earlier quoted context omitted.

> 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), the…

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.

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

It doesn't look competitive in comparison with DX12 and Mantle.

Post reply on HN