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

VkFFT – Vulkan Fast Fourier Transform Library

github.com

Post reply on HN
Print view View original

121–130 of 132 posts

Re: VkFFT – Vulkan Fast Fourier Transform Library

#121

Post by pjmlp »

littlestymaar wrote: post #116
pjmlp wrote: post #115

Earlier quoted context omitted.

Optix doesn't do Vulkan and I doubt that NVidia will ever bother, and OTOY most likely will rather use they resources elsewhere like the new Metal render.

> and OTOY most likely will rather use they resources elsewhere like the new Metal render. Maybe you're right, and this guy is wrong. But you gotta admit that contradicting the speaker of the video you're using as a source is unusual to say the least.

Apparently watching a 2h video is too much to ask nowadays, or am I now supposed to link all snippets and blogs from OTOY just to win a couple Internet brownie points?

Re: VkFFT – Vulkan Fast Fourier Transform Library

#122

Post by datenwolf »

DTolm wrote: post #120
datenwolf wrote: post #119

Earlier quoted context omitted.

I'm aware of all of that. And yes, we're very synchronization dependent. However we also spent a lot of time tinkering with the launch parameter and properly interleaving all synchronization events and fences due to our demands on achieving low latency. Find our original publication here: https://doi.org/10.1364/BOE.5.002963 Since then we improved on that. For the resampling and complex tonemapping we determined empi…

Well, most likely I won't be able to help explaining the fluctuation easily then, as you have spent a lot of time on it already. It would be cool to try VkFFT in this usage scenario at some pont in the future though - it also can do 1D FFTs of grouped in matrix sequences.

As I already mentioned over at https://www.reddit.com/r/vulkan/comments/i2ivzh/new_vulkan_f... I'm going to do that. And will let you know how it goes.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#123

Post by littlestymaar »

pjmlp wrote: post #121
littlestymaar wrote: post #116

Earlier quoted context omitted.

> and OTOY most likely will rather use they resources elsewhere like the new Metal render. Maybe you're right, and this guy is wrong. But you gotta admit that contradicting the speaker of the video you're using as a source is unusual to say the least.

Apparently watching a 2h video is too much to ask nowadays, or am I now supposed to link all snippets and blogs from OTOY just to win a couple Internet brownie points?

> Apparently watching a 2h video is too much to ask nowadays,

Sorry if I don't spend 2h of my time watching a video presenting the features included in the new version of a piece of software I will never use, just so we have the same knowledge about this product. You generously posted a link to a part of this video relevant to our discussion and I'm thankful for that, but I'm also puzzled because the speaker contradicts you in this very snippet you chose!

Good day.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#124

Post by DTolm »

datenwolf wrote: post #122
DTolm wrote: post #120

Earlier quoted context omitted.

Well, most likely I won't be able to help explaining the fluctuation easily then, as you have spent a lot of time on it already. It would be cool to try VkFFT in this usage scenario at some pont in the future though - it also can do 1D FFTs of grouped in matrix sequences.

As I already mentioned over at https://www.reddit.com/r/vulkan/comments/i2ivzh/new_vulkan_f... I'm going to do that. And will let you know how it goes.

If you happen to need any assistance in refining VkFFT for your use case, feel free to contact me.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#125

Post by eximius »

DTolm wrote: post #106
datenwolf wrote: post #102

Earlier quoted context omitted.

> GPU is a very consistent device. You'd think that, but I found all GPUs I'm using here to exhibit multimodal distribution of execution times in the FFT (this is for the cuFFT codepath). The GTX980 (not shown in the plot) and the Titan-X even have very prominent outliers. This is a figure that's going to be in the paper I'm currently writing: https://dl.datenwolf.net/gpu_oct_benchmark_plots.pdf I'm comparing the OCT…

I use the averaged data of 1000 merged launches and then average the end result over a number of runs. Merging FFT calls is actually the way how I use VkFFT in Vulkan Spirit (with some other shaders between), so this benchmark is fairly close to the real life application use case. My benchmark most likely averages out multimodal distribution effects by design.

If it's multimodal, then averaging it out is the wrong thing to do. A histogram would be more appropriate to display the different modes.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#126

Post by necubi »

andi999 wrote: post #66
necubi wrote: post #52

Earlier quoted context omitted.

Audio processing is real-time, which means that you cannot miss your deadline. If you do miss you get audible glitches, whereas in graphics you just get a slowdown. For that reason, audio code is written in a very particular, real-time safe style that avoids locks, allocations, syscalls, and anything else that is not guaranteed to return within a bounded amount time. How long the deadline is depends on your buffer si…

What OS are we talking? It sounds like you need a real time os.

MacOS has the ability to prioritize audio threads to avoid scheduling misses [0]. Linux has a set of patches [1] to give it soft real-time capabilities. I don't know as much about Windows, but I assume it has similar capabilities.

And it's not like this is ABS firmware, where someone might die if you miss your deadline, and where hard real-time OSes are used. But you do get glitches in the audio stream, which in performance contexts is still pretty bad.

[0] https://developer.apple.com/documentation/audiotoolbox/workg... [1] https://wiki.archlinux.org/index.php/Professional_audio#Real...

Re: VkFFT – Vulkan Fast Fourier Transform Library

#127

Post by tinus_hn »

slavik81 wrote: post #15
zdw wrote: post #4

If I were a hiring person at AMD or Intel, I'd shortlist this guy for a job, as they need help competing against the headstart CUDA has in the GPU-base compute space.

The AMD Math Libraries team is hiring [1], and one of the libraries they develop is rocFFT [2]. Disclosure: I work at AMD, though not on rocFFT. [1]: https://jobs.amd.com/job/Calgary-GPU-Libraries-Software-Deve... [2]: https://github.com/ROCmSoftwarePlatform/rocFFT

The author lists his email address on the site and indicates he’s looking for a position.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#128

Post by slavik81 »

tinus_hn wrote: post #127
slavik81 wrote: post #15

Earlier quoted context omitted.

The AMD Math Libraries team is hiring [1], and one of the libraries they develop is rocFFT [2]. Disclosure: I work at AMD, though not on rocFFT. [1]: https://jobs.amd.com/job/Calgary-GPU-Libraries-Software-Deve... [2]: https://github.com/ROCmSoftwarePlatform/rocFFT

The author lists his email address on the site and indicates he’s looking for a position.

I should probably make it clear that I have nothing to do with the hiring process whatsoever. Though, it seems I could provide a referral.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#129

Post by ncmncm »

FieryTransition wrote: post #69
ncmncm wrote: post #60

Earlier quoted context omitted.

The Microsoft Defense Force has been activated. Despite it, my statement remains true: I do, in fact, adjudge candidates the more favorably for a Gitlab account than a Github account. It demonstrates conscious choice in a knee-jerk world. (Microsoft doesn't need your assistance, boiz.)

If I ever got minus points for using github rather than gitlab in an interview, I think my opinion of the workplace would be that they would rather focus on minute details rather than actual problem solving and social skills.

You would have no idea whether you got minus points for failing to make the jump to Gitlab.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#130

Post by solipsism »

ncmncm wrote: post #129
FieryTransition wrote: post #69

Earlier quoted context omitted.

If I ever got minus points for using github rather than gitlab in an interview, I think my opinion of the workplace would be that they would rather focus on minute details rather than actual problem solving and social skills.

You would have no idea whether you got minus points for failing to make the jump to Gitlab.

You say that proudly? You'll judge a developer based on petty preferences, and then not do them the favor of telling them as much?

Must be a blast working there...

Post reply on HN