Since nobody pushes to add a fancy new thing to DirectX unless they plan to ship hardware specifically to do that new thing, AMD would have to have been blind & deaf to not know Nvidia was going to ship RTX this year.
Nvidia is looting customers that want to use GPUs for Machine Learning on the cloud (like AWS, GCP)
It's AMD's job to make machine learning work in their GPU's. If they don't believe in it and spend the necessary time and effort, nobody else will. Radeon Open Compute Platform (ROCm) has existed for years but apparently it's not good enough.
ps. Tensorflow has ROCm backend support. https://hub.docker.com/r/rocm/tensorflow/ but is MI25 competitive? https://www.amd.com/en/products/professional-graphics/instin...
Why is it a separate repo rather than being contributed upstream to TF?
Both are being actively worked on, and I expect to see this gap shrink in the next few months to a year.
CUDA had C, C++ and Fortran support since the early days, followed by the PTX bytecode format for any compiler vendor that wanted to support CUDA on their languages.
It was necessary to loose the race for them to focus on C++ and come up with SPIR and SYSCL.
And tools still seem not to be on par with what NVidia offers.
Also regarding tooling, that isn't quite true, as they have engaged with LunarG for Vulkan, because they have learned from lack of OpenGL adoption, that the large majority of games developers wouldn't even bother without a proper SDK.
Nonsense. You'll be hard-pressed to find a platform that doesn't support C or a competent system design or even graphics design engineer who isn't confortable with C.
If their goal is to establish standards, they build upon standards.
Likewise for game consoles, Windows and now Apple graphics APIs.
Defining standards does not mean they must provide a lowest denominator single implementation.
They can be defined in an IDL kind of way, like e.g. WebIDL, abstractly e.g. Internet RFCs, or define mappings to all major languages in the GPGPU field, namely C, C++ and Fortran.
That's already done. Mozilla's Obsidian is an object-oriented WebIDL interface to Vulkan: https://github.com/KhronosGroup/WebGLNext-Proposals/tree/mas...
Again, Khronos is just a standards group. It does what its members tell it to. Khronos is far more lightweight of an organization than, say, ISO's C++ committee. Instead of blaming Khronos, you could perhaps encourage them to focus on initiatives like Obsidian.
Prior to the Ryzen launch, AMD lived through some really lean years. They saved wherever they could, and their GPU department saw very little investment on development for a long period. Since then, they have recapitalized the department, and are probably designing a proper next gen GPU architecture to replace GCN. However, it takes ~4-5 years to get a completely new arch on the market, and they only got to start a few years ago. Vega and Navi are both still shoestring budget designs.
The technology is a lot more interesting in professional 3D modelling where light baking and rendering can be done much faster.
> The only real performance advantages the GeForce3 currently offers exist in three situations: 1) very high-resolutions, 2) with AA enabled or 3) in DX8 specific benchmarks. You should honestly not concern yourself with the latter, simply because you buy a video card to play games, not to run 3DMark.
> The GeForce3 is consistently a couple of frames slower than the older GeForce2 cards
> Between now and the release of the GeForce3's successor, it is doubtful that there will be many games that absolutely require the programmable pixel and vertex shaders of the GeForce3
It would help if there was more explanation of what the RTX units are actually good at. Not every GPU innovation actually ends up widely used. It would be amusing if they lost out by being not programmable enough...
Mind you that you are seeing the early generation of hardware based real time raytracing now and it already can beat the quality of rasterization.
There is still a ton of room for improvements. One or two hardware generations from now we may finally see realtime generated images for which the term photorealistic is not just a silly marketing hype. They could truly fool you.
One of the problems is that raytracing is inherently noisy, so you actually have to shoot many rays (or trace many paths) for each pixel on the screen, and you really need to get into the high double digits for acceptable results purely from raytracing.
Part of NVidia's sales pitch is that you can reduce the number of samples / rays using advanced post-processing filters based on CNNs. But then you're back to building a jenga tower of hacks, just this time on top of raytracing instead of on top of rasterization. You may prefer the raytracing jenga tower perhaps, but truth in advertisement should make it clear that raytracing alone just isn't there yet.
It's true though that this current generation of hardware is promising, and things are bound to get better quickly. For now, the most you're going to get is hybrid techniques where rasterization is used for the bulk of the rendering, and raytracing is used selectively e.g. for parts of a scene or for shadows.
What has me worried is not the performance of the ray-scene intersection, but the dynamic BVH update that is required for each frame. Building acceleration structures for ray intersection tests is a hard tradeoff between fast construction times and fast intersection tests. With animated/deforming objects, this is quite an interesting challenge. But we might eventually see some dedicated hardware for that, too. Academic implementations exist.
Gamers want fast framerates, high polygon count, high textures much more than some currently-useless raytracing. Solve those into near-reality quality in at least 1440p resolution, and then we can talk about these gimmicks. I'll happily skip this (and next) gen and will be OK with some 1080 card.
RTX cards might allow porting Luxrender in a way that retains it's spectral treatment that actually physically simulated a dispersive prism generating a rainbow from a ray of white light, without more than specifying the dispersion of the glass. It goes without saying that such effects are inherently very noisy, but there might be ways using automatic differentiation (c.f. Julia (language)) combined with advanced numerical integration to make use of calculus to reduce the noise in individual samples.
If anyone knows about attempts to combine Metropolis light transport (MLT) with automatic differentiation or just about a more concrete idea to incorporate advanced numerical integration with MLT, or a potentially suitable MLT implementation in Julia, please let me know, i'd like to check it out and actually consider it a suitable "toy" project for learning Julia. The ease of efficient GPU use from this high level just allows so much flexibility in e.g. complex material node graphs getting handled with no extra work on the integrator then.
MLT is not used for animations because it is temporally unstable in a perceptually unfavorable way: the artifacts are more blotchy than noise while the human vision is more tolerant to noise. Recent developments around temporal MLT should mitigate that, but these require you to render multiple frames simultaneously. Thisnmakes them unsuitable for real time applications.
Also, the thing about MLT/bidirectional/unidirectional pathtracing is that there is no universally best method. All of then have weaknesses. There are examples where each method is worse than the others in an equal time comparison.
The best performance improvements that you can get with any of these Monte Carlo methods are always based on improved strategies for drawing the samples (importance sampling, QMC). Incorporating non-local information for local importance sampling will be the next big thing.
As for color noise: it is an undesirable artefact, but if you importance sample the spectral color response curves for the human eye (or your display device) correctly, then the spectral noise vanishes at least as fast as the other sources of noise in your scene.