-
Notifications
You must be signed in to change notification settings - Fork 192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize Raycasting when OpenCL 2.0 is present #197
Comments
Seems like there is an on-going development of new version at https://github.com/yozhijk/radeonrays-next/commits/master |
The last commit on any of the branches is in 2017? |
End of 2017 actually, that's newer than this repo anyways, recent commits here are mostly PR. |
Last I heard from Dmitry they were working on the Vulkan backend at the moment. |
So will we get a VK_EXT_raytracing or VK_AMD_raytracing in Vulkan? |
AFAIK they were completely reworking the current RadeonRays Vulkan backend (which is deprecated at this point). Thus nothing GPU driver related. |
VK_NVX_raytracing is required to wrap the proprietary RTX technology and Optix. I'm not sure what to think about RTX, but I would prefer general GPU improvements and avoiding the need of so specialized hardware and back box programming. If AMD can do this, i.e. use only general unified computing architecture, and still achieve competitive ray tracing, this will be a big win for them. These RTX cores are taking chip space, and when you don't use them, it's total waste. You also can have only limited amount of them, so how much to put on the chip? It become clear that 2070 can't really handle ray tracing... At least my guess is that AMD will go with unified architecture, and will release standard Vulkan library, avoiding the need for extension. At least this is what I'm hoping for, but we probably have another 6 months to wait until their new video cards are released and more things go public... |
OpenCL has been officially dropped in the newest release! |
Pipes and Device-side Enqueue could eliminate the need to save intersections to intermediate buffers and the whole global read-write loop for every batch of rays dependant on the previous intersections.
I dont know if implementing recursive ray-tracing is possible in the context of the above OpenCL 2.0 functionality, but I'd like to get the discussion started.
Are there any plans for a
TraceRay
DXR equivalent function?The text was updated successfully, but these errors were encountered: