Earlier quoted context omitted.
What effort to port tensorflow?
https://gpuopen.com/rocm-tensorflow-1-8-release/
Upstream it.
Nvidia announces RTX 2000 GPU series with ‘6x more performance’ and ray-tracing
381–390 of 392 posts
Re: Nvidia announces RTX 2000 GPU series with ‘6x more performance’ and ray-tracing
#382I just realized that what in dark corners of mobile games we call Whales, NVidia calls "enthusiasts".
Re: Nvidia announces RTX 2000 GPU series with ‘6x more performance’ and ray-tracing
#383Earlier quoted context omitted.
If it's data size in GPU RAM you are concerned about, couldn't you store fp16 and cast into fp32 just in the kernel? In OpenCL, you would do this with vload_halfN and vstore_halfN to convert during load and store. You won't get double throughput compared to fp32, but you shouldn't fall back to some terribly slow path either.
I haven't looked into it myself, but it could be that due to all this massaging you'd lose more on throughput than you gain on memory use. It's similar to doing 8 bit quantized stuff on general purpose CPUs. It's very hard to make it any faster than float32 due to all the futzing that has to be done before and after the (rather small) computation. In comparison, no futzing at all is needed for float32: load 4/8/16 th…
Right, you won't exceed the fp32 calculation rate, unless perhaps it was bandwidth-starved accessing the slowest memory tier. You are doing all fp32 operations after all. What you can do is fit twice the number of array elements into which ever GPU memory layer you decide to store as fp16, so potentially work on half as many blocks in a decomposed problem or twice the practical problem size on a non-decomposed problem.
You can separately decide which layer of cache to target for your loads and stores which convert, and then use fp32 with normalized 0-1 range math in that inner tier. You only have to introduce some saturation or rounding if your math heavily depends on the fp16 representation. The load and store routines are vectorized. You load one fp32 SIMD vector from one fp16 SIMD vector of the same size (edit: I mean same number of elements) and vice versa.
Re: Nvidia announces RTX 2000 GPU series with ‘6x more performance’ and ray-tracing
#384Earlier quoted context omitted.
And you also didn't. 'most people can't afford or justify'. Come one. People buy cars and other stuff. Someone working fulltime and buying a 1k cheaper car can already afford and justify a 1k graphics card.
Video cards tend to be from the entertainment part of the budget, cars are totally different. Cars do last way more than a video card as well, they have increased warranty period(in the EU video cards have 2y, cars usually 5-7y). Cars tend to be purchased on leasing due to their higher cost and actual necessity. So saving 1k on a car usually doesn't transfer to 1k in cash.
We are already talking about a small percentage of people who wanna buy a graphics card.
From those people, it is easily justifyable to spend less on a car, a holiday or rent and instead having a nicer gaming rig. If you spend a lot of time playing games why not?
Modern technology is way cheaper than the previous/old status symbols.
I'm thinking about buying a car and one simple calculation is still what else i can do with that money.
And yes in munich, where i live right now, there are enough people with a car who could use public transport and don't us it.
The target group of a 1k graphics card is not someone who can barely afford the car he/she needs every day and would not be able to earn anything if the car breaks down...
Re: Nvidia announces RTX 2000 GPU series with ‘6x more performance’ and ray-tracing
#385Earlier quoted context omitted.
It's a spectrum. Not every professional wants and/or can afford the top end cards. Many professionals (i.e. those who make money doing a thing) have been using high-end gaming cards for work pretty much since they existed. There's also the long-running debate as to the actual value of the 'pro' line of video cards for non-mission critical purposes (enough of one that nVidia in their license prohibited the use of gami…
But they are the low-to-mid segment of professionals doing weddings and local business presentations with median income around $50k. The ones doing interesting work can't live without real 10-bit HDR on calibrated 4k screens for realistic printing/video projections, without proper 5k+ RAW cameras and top-end lens etc. and those are extremely expensive.
These expensive items are actually useful equipment for video production, but it doesn't mean a video card has the same importance. Who cares about slightly longer rendering times for rarely used special effects?
Re: Nvidia announces RTX 2000 GPU series with ‘6x more performance’ and ray-tracing
#386Earlier quoted context omitted.
We used to call this model fishing and regard models that came from places that did it with fear and suspicion (due to sudden failure and poor performance in production) What has changed that people think this is a wise approach?
They don't suddenly fail any more, and performance in production is fine... This is a rather empirical science right now. If forced to speculate, I'd say far larger datasets are part of the answer. If you can afford to hold back 30%+ of your data for (multi-tranche) verification the difference between testing and production becomes a problem for the philosophers.
Hmm this isn't my experience. My experience is that highly complex models tend to reflect accurately the ground truth in the current dataset, but not the domain theory that generated it, so when things change (like, prevailing weather conditions, political alignments, interest rates, data usage) which move the distribution (but not the domain theory) they do fail. The question is : are you trading poorer compression for more fidelity or are you learning the system that generates the data?
Re: Nvidia announces RTX 2000 GPU series with ‘6x more performance’ and ray-tracing
#387Earlier quoted context omitted.
But they are the low-to-mid segment of professionals doing weddings and local business presentations with median income around $50k. The ones doing interesting work can't live without real 10-bit HDR on calibrated 4k screens for realistic printing/video projections, without proper 5k+ RAW cameras and top-end lens etc. and those are extremely expensive.
These expensive items are actually useful equipment for video production, but it doesn't mean a video card has the same importance. Who cares about slightly longer rendering times for rarely used special effects?
Last time I checked you needed at least Quadro for 10-bit HDR in normal Windows application (games in fullscreen worked on normal ones as well) :-(
Re: Nvidia announces RTX 2000 GPU series with ‘6x more performance’ and ray-tracing
#388Earlier quoted context omitted.
One of the major challenges when trying to generate realistic, believable graphics is correctly modeling ambient light. Without that, adding higher resolution displays or finer polygon meshes won't get you there. The most efficient and accurate methods of modeling ambient light are fundamentally based on ray tracing. Path tracing is probably the best known and most popular, photon mapping is another. They are both ba…
With denoising in place, the inaccuracies manifest as low resolution. (similar to pixellation or blur but not as even) Apparently nVidia is using a variant of beam tracing if patents are to be believed.
That's about what I'd expect. If they're doing it sensibly, though, it should only affect the resolution of ambient light effects, not the portion of the rendering that comes from primary rays. So, the geometry would have sharp edges, but the caustics might be blurry. Seems like a good tradeoff if it drastically reduces the overall computation.
Re: Nvidia announces RTX 2000 GPU series with ‘6x more performance’ and ray-tracing
#389Earlier quoted context omitted.
I haven't looked into it myself, but it could be that due to all this massaging you'd lose more on throughput than you gain on memory use. It's similar to doing 8 bit quantized stuff on general purpose CPUs. It's very hard to make it any faster than float32 due to all the futzing that has to be done before and after the (rather small) computation. In comparison, no futzing at all is needed for float32: load 4/8/16 th…
Right, you won't exceed the fp32 calculation rate, unless perhaps it was bandwidth-starved accessing the slowest memory tier. You are doing all fp32 operations after all. What you can do is fit twice the number of array elements into which ever GPU memory layer you decide to store as fp16, so potentially work on half as many blocks in a decomposed problem or twice the practical problem size on a non-decomposed proble…
The point is, you might end up with compute throughput _substantially_ worse than raw fp32. No one will take that tradeoff.
Re: Nvidia announces RTX 2000 GPU series with ‘6x more performance’ and ray-tracing
#390Earlier quoted context omitted.
Right, you won't exceed the fp32 calculation rate, unless perhaps it was bandwidth-starved accessing the slowest memory tier. You are doing all fp32 operations after all. What you can do is fit twice the number of array elements into which ever GPU memory layer you decide to store as fp16, so potentially work on half as many blocks in a decomposed problem or twice the practical problem size on a non-decomposed proble…
The point is, you might end up with compute throughput _substantially_ worse than raw fp32. No one will take that tradeoff.
I have used fp16 buffers frequently on NVIDIA GPUs with OpenGL in generations ranging from GTX 760 (GK104) to Titan X (GM200 and GP102) as well as mobile GPUs like GT 730M (GK208M). I do this for things like ray-casting volume rendering, where the dynamic range, precision, and space tradeoffs are very important.
My custom shaders performing texture-mapping and blending are implicitly performing the same underlying half-load and half-store operations to work with these stored formats. The OpenGL shader model is that you are working in normalized fp math and the storage format is hidden, controlled independently with format flags during buffer allocation, so the format conversions are implicit during the loads and stores on the buffers. The shaders on fp16 data perform very well and this is non-sequential access patterns where individual 3 or 4-wide vectors are being loaded and stored for individual multi-channel voxels and pixels.
If I remember correctly, I only found one bad case where the OpenGL stack seemed to fail to do this well, and it was something like a 2-channel fp16 buffer where performance would fall off a cliff. Using 1, 3, or 4-channel buffers (even with padding) would perform pretty consistently with either uint8, uint16, fp16, or fp32 storage formats. It's possible they just don't have a properly tuned 2-channel texture sampling routine in their driver, and I've never had a need to explore 2-wide vector access in OpenCL.