81–90 of 91 posts
It'd be super-nice if AMD also produced, at a minimum, fully supported versions of PyTorch and TensorFlow for these. NVIDIA would crap its pants if perf is comparable (and possibly drop the prices some).
It is just right here: * https://rocm-documentation.readthedocs.io/en/latest/Deep_lea... * https://github.com/ROCmSoftwarePlatform/tensorflow-upstream
Earlier quoted context omitted.
Depends on how you define competitive, in gaming which this card at least partially is aimed at its about as fast as a 1080ti a card launched 2 years ago for $700.
I'm hoping a 8gb or 12 gb version comes out for $500 or so. 16gb seems like overkill for the next couple years of game releases.
Earlier quoted context omitted.
It looks like one of the card’s headline features, 1TB/sec of memory bandwidth, was only achievable with a 16gb design (basically a doubling of channels/memory over the previous Vega 64 design, with which this card shares many similarities).
Why can't they use 4x2GB and provide the same bandwidth? Or it's some limitation of HBM2?
Earlier quoted context omitted.
> Deep learning enthusiasts probably will stick to NVIDIA cards We've been building the wrong hardware for ML for a while now. A TPU doesn't delivery supremacy for problems over GPU hardware. It's a Google senior engineering retention and PR project. Exceedingly few problems resemble image recognition. You wouldn't be able to tell from the research, because due to the tools it's sort of the only affordable thing to d…
> Exceedingly few problems resemble image recognition. It makes it extremely difficult to take any of what you just said seriously knowing that you made this statement.
This is coming from a physicist starting to investigate ML tools in my own work.
Earlier quoted context omitted.
> Exceedingly few problems resemble image recognition. It makes it extremely difficult to take any of what you just said seriously knowing that you made this statement.
Care to expand? Prima facie this is a very reasonable stance. Further, image data has a lot of structure not present in other data and it's far from obvious what to do with ML techniques in other contexts. This is coming from a physicist starting to investigate ML tools in my own work.
Earlier quoted context omitted.
Based on the pixel sparkling in the video I've seen if Battlefield, it looks like Nvidia's raytracing is being used for each pixel. I'm not sure if it has to be that way or if it's just underoptomozed at the moment. I think you could get something 95% as good with far better performance by only tracing vertices and then raster rendering the resultant transform. Would be a good approach for accurate shadows too where…
> Based on the pixel sparkling in the video I've seen if Battlefield, it looks like Nvidia's raytracing is being used for each pixel. I'm not sure if it has to be that way or if it's just underoptomozed at the moment. 1-sample per pixel is already incredibly low for raytracing. A raw 1 spp raytraced image looks HORRIBLE. The reason why it looks anywhere close to usable is because NVidia post-processes all of that noi…
Of course that'd work for fps as slow as battle of duty \s
Earlier quoted context omitted.
The truth is that for many types/sizes of models AVS2 or AVS512 in Xeons is as fast and GPUs.
I am interested in seeing benchmarks regarding this. I believe this is true for models with truly huge embeddings, but otherwise if your models are even a little compute dense then GPUs are faster.
Perhaps a good candidate for mining coins like LivePeer (one of 8-10 actual solid blockchain projects IMO).
>LivePeer (one of 8-10 actual solid blockchain projects IMO) Interesting. Can anyone suggest a good curated list of solid blockchain projects?
Earlier quoted context omitted.
My experience is that you need the additional caveat of a streaming fairly homogeneous and highly parallelizable approach or the memory transfer, branching and communication overheads will eat away nearly all the GPU gains. I've also noticed that a lot of the time, people are comparing GPU to naive implementations (and sometimes, implementations written in dynamic languages) instead of to highly tuned BLAS or MKL imp…
No, they're not. Straight front the horse's mouth: https://software.intel.com/en-us/mkl/features/benchmarks In no case will you see it get close to 10TFLOPS. GPUs easily do this, and can approach 100TFLOPS with tensor cores.
Earlier quoted context omitted.
No, they're not. Straight front the horse's mouth: https://software.intel.com/en-us/mkl/features/benchmarks In no case will you see it get close to 10TFLOPS. GPUs easily do this, and can approach 100TFLOPS with tensor cores.
I don't dispute this. If you can remove memory transfer overhead and meet the requirements I mentioned, then GPUs will be much better. But there are many problems that do not fit that (SIMD per warp) regime. In short, GPUs are no panacea and have their own trade-offs and bottleneck sensitivities, just like everything else.