5 ms·
How did you decide on using Mac Pros for batch GPU processing in a data center? After a little deliberation I could come up only with downsides of using these m
by w-m 7y ago
How did you decide on using Mac Pros for batch GPU processing in a data center? After a little deliberation I could come up only with downsides of using these machines, which are quite expensive and have GPUs from 2013.
- chrischen 7y agoI believe one of the reasons imgix used macs as well was for Quartz and the macos apis.
- matylla 7y agoThis thread by imgix [1] perfectly explains the reasoning behind using Apple's hardware in a datacenter. [1]: https://news.ycombinator.com/item?id=9500301 https://news.ycombinator.com/item?id=9500301
- w-m 7y agoBrowsing through this thread, the main argument seems to be that they are most comfortable with the Mac APIs and think it would be harder to rewrite their stack using different technology. They would have to re-apply the new stack onto millions of existing images and make sure the results 100% match the previous version, which is a problem that you don't have launching a new API. So I'm not quite sure that I understand this reasoning in your case, as the operations performed (scaling, cropping, watermarking, flipping, filtering) are available in just about any image processing pipeline, and not really linked to anything that Quartz or Mac does particularly well.
- m0zg 7y agoFor image processing them being from 2013 doesn't matter all that much: they're more than sufficient. As to why Mac, let me try to offer a guess: Apple ships Core Image, and they've sunk close to 2 decades of hard work into it by now. This is why there are two dozen "photoshop alternative" image editors on the Mac and a lot fewer (and poorer quality) on Windows. So the benefit is, you can just use the API and get state of the art quality without spending three person-months tuning and debugging each and every op.
- matylla 7y agoCore Image by itself is worth investing in a proper (Apple) hardware. Now that we can write custom Metal kernels and plug them straight into Core Image is even more beneficial. We can come up with any pixel modifications that will be executed within the GPU context. Precompiled kernels anyone? :) The foundation of any image processing pipeline on MacOS/iOS is Image IO that offers crazy fast codecs for over a dozen different image formats. Even though I had to write extra integrations for WebP and animated GIFs it was really worth the effort. Native HEIC/HEIF support (reading and writing) is also neat. Apple's CoreML is another piece of software I am using more and more at Pixaven. The ease of testing and deployment of new ML models is just amazing (and yes, I am learning a lot along the way).
- m0zg 7y agoWhat baffles me is why doesn't NVIDIA offer a cross platform CoreImage counterpart. They do have nvjpeg for decoding, they have video codecs built in (so presumably HEIF should be doable also), but there isn't much available, as far as I can tell, if you want very high quality image manipulation with NVIDIA GPUs. I get that they're focused on 3D and deep learning now, but this is even useful for deep learning: I'd love to have hardware image decode and my entire image augmentation pipeline on the GPU and only do IO and perhaps some gnarly loss and metric computations on the CPU. Some of this is doable with NVIDIA DALI, but it doesn't seem to offer enough of a perf advantage to bother with it so far. What would be great is if they offered similar capabilities to CoreImage (that is, quality-focused, flexible image processing) that I could use everywhere I can use CUDA.
- matylla 7y agoI second that. High performance image processing with NVIDIA means writing low level CUDA, something I am not willing to invest my time in (at least for now). Translating all the code and custom kernels I wrote for Core Image would be quite a hassle to put it mildly.