
Khronos Group Releases Vulkan Ray Tracing - ingve
https://www.khronos.org/news/press/khronos-group-releases-vulkan-ray-tracing
======
chrisseaton
Can anyone give me any intuitive understanding of how ray tracing can be
adapted into a conventional rasteriser workflow?

Doesn't ray tracing need a persistent, whole-world scene graph? Rays can end
up anywhere, no matter where the camera is pointing, isn't that right? I
thought the whole scene wasn't on the GPU? I thought the CPU streamed polygons
to be drawn based on what was likely to be visible, but it can't stream the
entire world every draw can it?

~~~
garmaine
The data for each scene hasn't been streamed to the GPU in a long time, not
since the first few generations of GeForce cards. "Vertex buffers" store the
geometry in the GPU's RAM, so it's there. The game engine just swaps out
buffers as things come in and out of view.

I have the same questions as you regarding how this works with respect to
offloading the the scene graph data structures though.

~~~
mmozeiko
To shoot rays in scene you create acceleration structure (internal to
driver/GPU hardware). Input to this structure are vertex & index buffers &
model transform matrix. Geometry is specified as triangles or AABB. You can
update this structure later by providing new transform matrix. There are
different flags that control performance/memory usage - fast tracing or
updates vs less memory usage.

See following links:

* [https://www.khronos.org/registry/vulkan/specs/1.2-extensions...](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkCmdBuildAccelerationStructureNV.html)

* [https://www.khronos.org/registry/vulkan/specs/1.2-extensions...](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkGeometryNV.html)

~~~
garmaine
But efficient ray casting requires a scene graph structure--an octree, or a
bsd-tree, etc. Are the details of that just handled by the driver?

~~~
mmozeiko
Yes. Driver/GPU handles that. It "just works". You just manage things on high
level - what can be moved in world, what cannot and group the updates
together.

------
jagger27
Nice to see Intel, AMD, and Nvidia working together on an open standard. Do
Apple's in-house GPUs have Vulkan support or would something like this have to
go through a Vulkan-on-Metal translation layer instead?

~~~
enos_feedler
Looking more and more like Apple will never touch Vulkan directly. They are
heavily invested in cross-device performance graphics using Metal.

The more the API situation evolves, I can see Google, Microsoft and Sony going
all in all Vulkan for performance graphics. Only if MS is willing to part ways
with D3D12

For cross platform I could see WebGPU + WebAssembly being the choice, where it
abstracts both Metal and Vulkan.

~~~
pdelbarba
Honestly I feel like D3D12's days are numbered. Tons of engines and devs are
moving to Vulkan and while Vulkan has tons of tutorials and documentation, D12
has NOTHING. If you want to just go out and make a D12 game, you basically
need to join up with one of the existing DirectX shops that has all the
knowledge siloed within.

~~~
fxtentacle
I disagree. Sony / Nintendo use proprietary APIs, Windows and Xbox use
DirectX, and Android you need OpenGL ES for compatibility. Apple is self-
disqualifying with their hardware and insistence on Metal.

That leaves Vulkan for Linux games. The 1% of the market that no savvy
business person would touch with a 10 feet pole.

In Linux land, you'll meet people who feel suspicious of you in the first
place for charging for your game, and people who have compiled their GPU
driver from scratch, yet blame your game for being incompatible with their
wrong compiler flags.

So for almost every game studio, there is no viable market where you could
sell a Vulkan game.

~~~
Jyaif
Nintendo and Android use Vulkan. Windows supports it as well (along opengl and
directX) so it's a _bit_ more than just Linux (which powers Stadia and will
likely power most Stadia-clones in the future).

This pretty much only leaves out macOS and iOS, for which a Vulkan
compatibility layer exists anyways.

~~~
pjmlp
Not quite true, although it tends to be used a lot as Vulkan sales pitch.

Nintendo uses Vulkan on the Switch, but they also have their own Metal like
API, NVN.

Vulkan is mostly used by PC ports into the Switch.

Exclusive Switch titles do so via NVN, Unreal or Unity bindings to NVN, not
Vulkan.

Android has optional support for Vulkan, since only flagship devices ever
bothered to actually provide it, with Android 10 Google has changed it into
compulsory API. So only Android 10 or later devices are guaranteed to actually
have proper Vulkan drivers available.

Windows supports Vulkan on the classic OpenGL ICD driver model, not available
in Win32 and UWP sandboxes, which only allow for DirectX based code.

This is the actual reality, and not that typical Vulkan sales pitch.

~~~
ksec
>Vulkan sales pitch

I like this. I will use the word "sales pitch" next time other companies does
it, which to me is flat out lying. ( Cough; AV1 )

I still dont get why the hype on Vulkan, if you want Android support you will
still need to use OpenGL for the majority of devices, given their slow
replacement cycle and I doubt it will be mainstream anytime soon.

------
capableweb
If you're interested in some more details:
[https://devblogs.nvidia.com/vulkan-
raytracing/](https://devblogs.nvidia.com/vulkan-raytracing/)

Do note that the following is part of the article and it's from 2018, not sure
about it's accuracy anymore: "As denoted by the ‘NVX’ prefix, this API is not
yet final and could undergo some minor changes before the final release."

------
einpoklum
Obligatory...

Vulkan Ray Tracing: [https://is.gd/DMIKVs](https://is.gd/DMIKVs)

