... just not the one and only classification of ray tracing tiers, which is now accepted to be a undoubted measure of value by anybody, lol.
AMD made a mistake letting NVIDIA drive Ray Tracing APIs
- Thread starter MfA
- Start date
... just not the one and only classification of ray tracing tiers, which is now accepted to be a undoubted measure of value by anybody, lol.
Well, better late than never.
But i wonder if AMDs approach will be still restricted to prevent future progress on 'coherency sorting', as imgtech calls it.
If so, to catch up here too, they'll need to do big changes on architecture again right after that.
Actually we don't know at what granularity NV implements their sorting, and maybe AMDs TMU approach can allow it at CU level at least.
Idk. But we will gain access to all those industry secrets just by looking at imgtechs next marketing slide, i'm sure...
A marketing slide from a paper presenting an Imagination concept of RT levels/tiers to promote their new products/tech compared to competitor solutions.
... just not the one and only classification of ray tracing tiers, which is now accepted to be a undoubted measure of value by anybody, lol.
They've always been ahead of competition in RT tech level, not just that slide.
Not just that, adding more levels to something does not necessarily equate to having higher performance. PowerVR had the most complex rasterization on PC, featuring perfect hidden surface removal. Yet, even in the most favorable times for such architecture, we all know how that ended up.
They also had working hardware they used in demos. No-one just licensed it at the time.
These levels themselves are just a marketing tool since I don't know anyone else on the market who thinks about RT in such levels - or even agree that this is the direction in which RT h/w should evolve in the future.
It is interesting as IMG's own view on this but that's about it.
Only if there is a PS5 Pro which launches before the end of next year which is when we'll likely see RDNA4.
And if it does launch before RDNA4 then like the PS5 and RDNA2, it may well be lacking the full RDNA4 feature set.
Regardless of who views it, IMG has had hardware doing more of the "steps" in RT process than any of the current competitors at any given point in time since first competitor (NV) entered the scene. The world might not evolve to the direction they've envisioned it, but considering that everyone else is currently on same road and doing subset of what they have available, it's more likely to continue on their envisioned road than not.
In case of PS5 it was a choice rather than anything else to my understanding, since MS had no issues launching full featured RDNA2 at the same time?
Could you please name the GPUs or APUs with Imagination's RT h/w which were/are present in PC gaming scene which Nv has entered?
In todays world you only show a prototype when you want to impress investors. Simulations are so good that you dont need to manufacture a prototype anymore.
Here you go, the card they used in CES 2016, doesn't look like simulation to me, or are you suggesting there's just FPGA in there (which is fast enough for realtime RT demos)?
Image from https://www.hardware.fr/tag_flux/210-211/imagination-technologies-powervr.html
but that's 2016. there has been no product since that uses Imagination's ray tracing IP. since then, Nvidia, AMD, Intel, Samsung, Qualcomm, and ARM has put their IP to products you can buy right now. Imagination isn't relevant in the ray tracing discussion until they join the party.
I believe their initial product was hybrid based using ray tracing and rasterization and designed primarily for mobile. They do have the IMG DXT gpu which they state eliminates the need to have combined ray tracing and rasterization, though I believe the card is only for professional use cases. Not sure if anyone is using their IP as RT was well researched in academia and concepts readily available for anyone to use prior to Imagination's h/w accelerator debut.
To be honest that's all I thought they did, all this info is new to me and fascinating!
That's the part where i disagree the most.
They have the BVH builder at the highest tier, but in practice the BVH builder will close the door to getting access to the BVH data structures even more shut.
Using the Nanite example again, with the BVH builder we'll likely end up at building BVH over all active clusters of the whole scene.
This might be fast enough due to hardware acceleration, or let's at least assume so.
However, it's still very inefficient, because we still pay the cost of the BVH builder processing very heavy workloads per frame and taking chip area.
So i don't see how's that more 'capable and feature-rich' than the alternative, which is just to converting the hierarchy of clusters data structure, which we already have streamed to memory already anyway, to the exposed HW BVH format.
The alternative is much more 'capable and feature-rich' than the snake oil they try to sell, even if it's just software.
However, i do not accuse them to sell snake oil intentionally. Likely they just ignore a need for dynamic geometry to solve LOD, like all those other chip makers too.
Also, in the mobile space fixed function acceleration may be the only way. E.g. if compute perf. is just ass.
But that's also one more reason why comparisons to desktop and consoles make little sense. I don't buy the claim of RT superiority. At least not anymore. Marketing hogwash they would not need to use.
Some research ironically supported by NVIDA to do simplified raytracing which invalidates most of the raytracing hardware. Meta's Deep Appearance Prefiltering does too, because it uses beam tracing which much like anisotropic cone tracing really doesn't suit the overly restrictive hardware. HWRT is hardware based vertex processing all over again, locking everything into a wrong path almost impossible to escape from. Just as UE finally was moving to a compute based pipeline, HWRT constricts everything again.
Traversal engines should be user programmable enough to do beam/cone/ray-differential tracing of variable resolution hierarchies. Intersection should be an exposed shader instruction.
Traversal engines should be user programmable enough to do beam/cone/ray-differential tracing of variable resolution hierarchies. Intersection should be an exposed shader instruction.
