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

81–90 of 97 posts

Re: Vulkan – Graphics and computing belong together

#81

Post by kllrnohj »

shmerl wrote: post #76

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

The idea that it's a bottleneck is wrong. Just because it's one thread doesn't make it a bottleneck. Draining from N queues into 1 queue and posting that work off to the GPU is never going to be a bottleneck. Even an arduino can handle that task fast enough to saturate the latest & greatest from Nvidia or AMD.

Also fwiw in DX12 even if parallel submission is supported, what's going to happen is N user threads are going to submit to 1 driver thread that then submits to the actual GPU.

Re: Vulkan – Graphics and computing belong together

#82

Post by shmerl »

kllrnohj wrote: post #81
shmerl wrote: post #76

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

The idea that it's a bottleneck is wrong. Just because it's one thread doesn't make it a bottleneck. Draining from N queues into 1 queue and posting that work off to the GPU is never going to be a bottleneck. Even an arduino can handle that task fast enough to saturate the latest & greatest from Nvidia or AMD. Also fwiw in DX12 even if parallel submission is supported, what's going to happen is N user threads are goi…

I understood it that GPU itself can handle multiple commands concurrently, no? So if hardware supports it and there is just one thread submitting them, hardware isn't used to full capacity. Or that's wrong? And what's the point of making one thread do it, if multiple can? Queuing through one usually makes sense if you need some ordering.

Re: Vulkan – Graphics and computing belong together

#84

Post by chongli »

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?

GCC supports waaaaay more different CPU architectures than these drivers do for GPU architectures. This argument has no merit. The only purpose for these closed architectures is vendor lock-in.

Re: Vulkan – Graphics and computing belong together

#85

Post by kllrnohj »

shmerl wrote: post #82
kllrnohj wrote: post #81

Earlier quoted context omitted.

The idea that it's a bottleneck is wrong. Just because it's one thread doesn't make it a bottleneck. Draining from N queues into 1 queue and posting that work off to the GPU is never going to be a bottleneck. Even an arduino can handle that task fast enough to saturate the latest & greatest from Nvidia or AMD. Also fwiw in DX12 even if parallel submission is supported, what's going to happen is N user threads are goi…

I understood it that GPU itself can handle multiple commands concurrently, no? So if hardware supports it and there is just one thread submitting them, hardware isn't used to full capacity. Or that's wrong? And what's the point of making one thread do it, if multiple can? Queuing through one usually makes sense if you need some ordering.

Most GPUs cannot handle multiple arbitrary commands concurrently, but even if they can you're still going to easily saturate that with a single thread pushing over command buffers. The command buffers in this case are large, complex work units, not small microtransactions like the APIs of old.

And yes, ordering is needed here.

Re: Vulkan – Graphics and computing belong together

#86

Post by shmerl »

kllrnohj wrote: post #85
shmerl wrote: post #82

Earlier quoted context omitted.

I understood it that GPU itself can handle multiple commands concurrently, no? So if hardware supports it and there is just one thread submitting them, hardware isn't used to full capacity. Or that's wrong? And what's the point of making one thread do it, if multiple can? Queuing through one usually makes sense if you need some ordering.

Most GPUs cannot handle multiple arbitrary commands concurrently, but even if they can you're still going to easily saturate that with a single thread pushing over command buffers. The command buffers in this case are large, complex work units, not small microtransactions like the APIs of old. And yes, ordering is needed here.

So how exactly then DX12 and Mantle do it? They don't appear to have such single queue manager thread. You said driver does that task. So if it does, can't it do it for Vulkan as well? Or their point is to reduce driver complexity here?

I can see that it might be not a major issue if time that takes it to fetch from the queue is way smaller than time it takes to execute some command [buffer]. I.e if queue manager will fetch and push commands to the queue, returning to fetch another without waiting for the first to finish, then it will work fine (it will have to handle GPU saturation though). But if it will be blocking - it will be some bottleneck which won't let using hardware fully.

Re: Vulkan – Graphics and computing belong together

#87

Post by anon4 »

chongli wrote: post #84
nightski wrote: post #59

Earlier quoted context omitted.

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?

GCC supports waaaaay more different CPU architectures than these drivers do for GPU architectures. This argument has no merit. The only purpose for these closed architectures is vendor lock-in.

And every vendor has an HLSL and a GLSL shader compiler. You also usually don't ship ten different binaries for ten different architectures, which you would need to do for GPUs.

Re: Vulkan – Graphics and computing belong together

#88

Post by semi-extrinsic »

runeks wrote: post #56
moron4hire wrote: post #50

Earlier quoted context omitted.

I thought CPUs did have binary blob drivers, both in the BIOS and on the operating system.

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…

Apropos your hypothetical Intel throwing restrictions scenario: Intel has been considering [0] dropping OpenCL support on the Xeon Phi. Which is exactly that kind of asshole move. Not to say that Nvidia or AMD are good guys in this respect...

[0] https://plus.google.com/105097056044353520580/posts/81ddzBqq...

Re: Vulkan – Graphics and computing belong together

#89

Post by semi-extrinsic »

runeks wrote: post #56
moron4hire wrote: post #50

Earlier quoted context omitted.

I thought CPUs did have binary blob drivers, both in the BIOS and on the operating system.

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…

Apropos your hypothetical Intel throwing restrictions scenario: Intel has been considering [0] dropping OpenCL support on the Xeon Phi. Which is exactly that kind of asshole move. Not to say that Nvidia or AMD are good guys in this respect...

[0] https://plus.google.com/105097056044353520580/posts/81ddzBqq...

Re: Vulkan – Graphics and computing belong together

#90

Post by gnoway »

anon4 wrote: post #87
chongli wrote: post #84

Earlier quoted context omitted.

GCC supports waaaaay more different CPU architectures than these drivers do for GPU architectures. This argument has no merit. The only purpose for these closed architectures is vendor lock-in.

And every vendor has an HLSL and a GLSL shader compiler. You also usually don't ship ten different binaries for ten different architectures, which you would need to do for GPUs.

In this model I think you'd distribute something in an intermediate bytecode, like .NET does w/ MSIL, and then the target system would be responsible for precompiling.

Edit: just saw this:

https://news.ycombinator.com/item?id=9140001

Post reply on HN