btarunr"VK_NV_raytracing" surfaced in tech-documents accessed by Phoronix, which is the company's contribution to a multi-vendor standard

Hmm...

I would be amazed if nVidia are going to release this fully, ie. not crippled in some way, when it comes to multi-vendor support.

nVidia don't usually do anything for the good of anyone or anything but themselves.

medi01Hmm...

The extensions has the name of the company which developed that extension.

Registry

ImsochoboThe extensions has the name of the company which developed that extension.

Registry

So, nVidia rolled out a VENDOR SPECIFIC extension of a multi-vendor standard, something that needs nVidia specific coding, something they did so much to OpenGL, until it collapsed... Do I see it right through the "multi-vendor standard" marketing spin?

The extension was coming...

Develop3DNvidia’s RTX software rendering stack sits on top of Volta. It can be accessed through a few different APIs, including Nvidia OptiX (that ray trace technology behind Nvidia Iray and other GPU renderers) and Microsoft DXR (DirectX Ray Tracing), an extension of DirectX 12. In the future it will also support Vulkan, the open API from the Khronos Group, the not for profit organisation that is also responsible for OpenGL.

Not implementing RTX into Vulkan just being able to access it with the extension.

But Nvidia said a metal API is useless and DX does everything...

I'd like to see them excluded from every single thing they lie about.

Great news, looking forward to seeing this tech used widely in the future just to annoy the lot above.

FluffmeisterGreat news, looking forward to seeing this tech used widely in the future just to annoy the lot above.

If unity goes this route it spells mostly death of rtx.

linky

as long as it's not vendor specific I'm happy and I couldn't care less about who created it.

I don't think that is the route Nvidia is going, I've just heard talk the new cards will have hardware aimed at speeding this lark up, so naturally it will need to be exposed via certain extensions.

medi01So, nVidia rolled out a VENDOR SPECIFIC extension of a multi-vendor standard, something that needs nVidia specific coding, something they did so much to OpenGL, until it collapsed... Do I see it right through the "multi-vendor standard" marketing spin?

Afaik Vulkan is full of vendor specific extensions. So it's VK_NV_raytracing now but nvidia is targeting it to be multi vendor extension so it will most likely to be VK_EXT_raytracing(or VK_KHR_raytracing) in future.

medi01So, nVidia rolled out a VENDOR SPECIFIC extension of a multi-vendor standard, something that needs nVidia specific coding, something they did so much to OpenGL, until it collapsed... Do I see it right through the "multi-vendor standard" marketing spin?

Then you need to learn how open standards are formed. As with OpenGL and OpenCL, most new features starts out as vendor-specific extensions. These are eventually reviewed by the Architecture Review Board and converted into an ARB extension, which in turn usually ends up as a feature set in the next revision of Vulkan/OpenGL/OpenCL etc.

Prototypes are essential to form mature and solid standards. You should rather be worried when software architects designs standards based on untested ideas.

stimpy88I would be amazed if nVidia are going to release this fully, ie. not crippled in some way, when it comes to multi-vendor support.

nVidia don't usually do anything for the good of anyone or anything but themselves.

Well, such misconceptions are expected when people base their opinions on the polarized discussions in forums, generally displaying a strong negative bias towards Nvidia.

Meanwhile in the real world, every OpenGL developer knows very well that no one comes close to Nvidia's contributions to open standards.

jabbadapAfaik Vulkan is full of vendor specific extensions. So it's VK_NV_raytracing now but nvidia is targeting it to be multi vendor extension so it will most likely to be VK_EXT_raytracing(or VK_KHR_raytracing) in future.

Something like OpenGL is truly full of vendor extension , Vulkan is still relatively clean.

jabbadap...but nvidia is targeting it to be multi vendor extension...

Wake me up when that happens.

efikkanMeanwhile in the real world, every OpenGL developer knows very well that no one comes close to Nvidia's contributions to open standards.

Yeah. It"s exactly what is written in the cemetery, where OpenGL rests, on it's R.I.P. stone:
"Thanks for destroying my competitor, dear nVidia, the shit you did to it is invaluable!
DirectX 9"

Vya DomusSomething like OpenGL is truly full of vendor extension , Vulkan is still relatively clean.

Only because Vulkan's only been aout bringing OpenGL to a lower-level API. Khronos were able to just pick and choose the from the subset of vendor-independent OGL extensions and bring those along to Vulkan. Now that Vulkan is a premier API on equal footing with OGL, Vulkan will start receiving vendor-specific extensions, and not just from nVidia, but from AMD, Intel, Qualcomm, PowerVR, ARM and everyone else too.

Vya DomusSomething like OpenGL is truly full of vendor extension , Vulkan is still relatively clean.

OpenGL is very old dinosaur, which were to be cleaned up by opengl next initiative. But Khoronos went to fresh start instead of cleaning it up(Thanks to AMD's donation of mantle). But yeah there are less vendor specific extensions on vulkan now. If one look one of the former nvidia specific extension i.e. VK_NV_external_memory, which were to be promoted to multivendor Khronos core extension VK_KHR_external_memory on vulkan 1.1 update. One might actually realize why it's open API(hint look at the contributors list).

jabbadap. One might actually realize why it's open API(hint look at the contributors list).

Most are still convinced Vulkan is secretly tweaked by AMD to give them an unparalleled advantage.

Vya DomusMost are still convinced Vulkan is secretly tweaked by AMD to give them an unparalleled advantage.

Nah that is nonsense, by itself Vulkan is nothing like that. But vendor specific extensions can make implementation of it benefit more one IHV than other.

Vya DomusMost are still convinced Vulkan is secretly tweaked by AMD to give them an unparalleled advantage.

Sure, the forums are full of conspiracy theories and wild speculation about AMD's hardware being more future-proof, none of which have proven to be true so far, so I call bullshit.

Many mistakenly claim that AMD will have an inherit advantage in Vulkan due to Mantle, but they are failing to realize that Vulkan is internaly based on SPIR-V from OpenCL. Vulkan have only got inspiration for some API syntax from Mantle, while the underlying implementation is completely different. Just because two APIs have similar syntax for a few functions doesn't make them the same, any programmer would know this. AMD were in fact the last vendor to release Vulkan drivers and get certified, quite a bit behind Nvidia and Intel. So far I've found nothing in Vulkan which favors AMD, and no one should be taken seriously claiming AMD have such advantages, until they can prove such inherit advantages exsist in the design.

I also want to remind everyone that no games so fare are using Vulkan directly, but instead uses an abstraction layer to simulate Direct3D 11 or OpenGL. It will take years before we see good game engines designed around Vulkan.