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

91–97 of 97 posts

Re: Vulkan – Graphics and computing belong together

#91

Post by gnoway »

ixtli wrote: post #55
readstoomuch wrote: post #16

Earlier quoted context omitted.

Apple are traditionally tardy when it comes to OpenGL. Yosemite is still on 4.1 (2010 release), lacking support for things like compute shaders.

It seems like it's unfair to say "Apple are late with OpenGL features." The third parties could put the same effort into making drivers for OS X that they do into making them (and their crapware frontends) for Windows, but they don't. I may be wrong, but it appears to me that it's Apple doing most of the work.

A bit of a tangent but... are you sure?

I just replaced a dead drive in an old Mini with an SSD, then installed Yosemite. I'm not really an Apple guy, so I was not aware that Yosemite implemented kext (driver) signing, which had the side effect of 'breaking' TRIM support for 3rd party SSDs. It was never supported to begin with, but prior to Yosemite you could enable it by changing strings in the kext; doing so now will render the Mac unbootable unless you globally disable kext signing. Apple does not offer any other ability for a 3rd party to write their own driver to make this work, short of possibly rewriting the entire AHCI stack, which is not feasible.

https://web.archive.org/web/20150205071750/http://coriolis-s...

Re: Vulkan – Graphics and computing belong together

#92

Post by runeks »

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?

> Sure you could have a standard like i386.

We're not talking about standardizing hardware (the ISA), but the API: Vulkan. It really doesn't matter in which form your hardware processing unit comes, as long as its driver accepts SPIR-V and can execute it on said processing unit.

Re: Vulkan – Graphics and computing belong together

#93

Post by kllrnohj »

shmerl wrote: post #86
kllrnohj wrote: post #85

Earlier quoted context omitted.

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 wil…

Graphics APIs are almost universally non-blocking, this won't be blocking either.

Vulkan is basically a rebranded Mantle. I suspect you're just mistaken about Mantle, but as that API is not (yet?) open we don't really know if this was a change Khronos made when adopting Mantle or if this is just how Mantle works as well.

DX12 works the same as Vulkan, though, with a single submission thread ("The only serial process necessary is the final submission of command lists to the GPU via the command queue, which is a highly efficient process." http://blogs.msdn.com/b/directx/archive/2014/03/20/directx-1...)

Re: Vulkan – Graphics and computing belong together

#94

Post by shmerl »

kllrnohj wrote: post #93
shmerl wrote: post #86

Earlier quoted context omitted.

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 wil…

Graphics APIs are almost universally non-blocking, this won't be blocking either. Vulkan is basically a rebranded Mantle. I suspect you're just mistaken about Mantle, but as that API is not (yet?) open we don't really know if this was a change Khronos made when adopting Mantle or if this is just how Mantle works as well. DX12 works the same as Vulkan, though, with a single submission thread ("The only serial process…

About Mantle, I saw this: http://techreport.com/review/25683/delving-deeper-into-amd-m...

It shows that multiple queues can be used for one GPU. I guess Vulkan can allow the same but it's not clear from that diagram.

Re: Vulkan – Graphics and computing belong together

#95

Post by kllrnohj »

shmerl wrote: post #94
kllrnohj wrote: post #93

Earlier quoted context omitted.

Graphics APIs are almost universally non-blocking, this won't be blocking either. Vulkan is basically a rebranded Mantle. I suspect you're just mistaken about Mantle, but as that API is not (yet?) open we don't really know if this was a change Khronos made when adopting Mantle or if this is just how Mantle works as well. DX12 works the same as Vulkan, though, with a single submission thread ("The only serial process…

About Mantle, I saw this: http://techreport.com/review/25683/delving-deeper-into-amd-m... It shows that multiple queues can be used for one GPU. I guess Vulkan can allow the same but it's not clear from that diagram.

Take a look at that again. There's one queue per type. One queue for graphics, one queue for compute, and one queue for DMA. Note that multiple threads are all feeding the single graphics queue.

Re: Vulkan – Graphics and computing belong together

#96

Post by shmerl »

kllrnohj wrote: post #95
shmerl wrote: post #94

Earlier quoted context omitted.

About Mantle, I saw this: http://techreport.com/review/25683/delving-deeper-into-amd-m... It shows that multiple queues can be used for one GPU. I guess Vulkan can allow the same but it's not clear from that diagram.

Take a look at that again. There's one queue per type. One queue for graphics, one queue for compute, and one queue for DMA. Note that multiple threads are all feeding the single graphics queue.

Yeah, I understood that. One queue per independent type of tasks. But Vulkan diagram didn't mention even that. May be such parallelism is AMD specific, and Vulkan being more generic has to cater for the wider range of GPUs. Not sure.

Re: Vulkan – Graphics and computing belong together

#97

Post by shmerl »

kllrnohj wrote: post #95
shmerl wrote: post #94

Earlier quoted context omitted.

About Mantle, I saw this: http://techreport.com/review/25683/delving-deeper-into-amd-m... It shows that multiple queues can be used for one GPU. I guess Vulkan can allow the same but it's not clear from that diagram.

Take a look at that again. There's one queue per type. One queue for graphics, one queue for compute, and one queue for DMA. Note that multiple threads are all feeding the single graphics queue.

I found the answer: https://www.youtube.com/watch?v=EUNMrU8uU5M&t=19m50s

Vulkan does support multiple command queues. And there can be several queues of the same type for one GPU.

Post reply on HN