Skip to content
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

Open
devshgraphicsprogramming opened this issue Oct 30, 2018 · 8 comments
Open

Optimize Raycasting when OpenCL 2.0 is present #197

devshgraphicsprogramming opened this issue Oct 30, 2018 · 8 comments

Comments

@devshgraphicsprogramming

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?

@manhnt9
Copy link

manhnt9 commented Oct 31, 2018

Seems like there is an on-going development of new version at https://github.com/yozhijk/radeonrays-next/commits/master

@devshgraphicsprogramming
Copy link
Author

The last commit on any of the branches is in 2017?

@manhnt9
Copy link

manhnt9 commented Oct 31, 2018

End of 2017 actually, that's newer than this repo anyways, recent commits here are mostly PR.

@scschaefer
Copy link
Contributor

Last I heard from Dmitry they were working on the Vulkan backend at the moment.
And concerning pull requests: IIRC in the past, significant new features and changes were often introduced via pull requests from a team members account.
But I'm unsure what's up at the moment, as one of my pull requests is currently stuck with no replies. I'm guessing that AMD is probably focusing their effort on DXR at the moment after Nvidia's RTX release. But that's just a hunch, so until we get a response from one of the repo maintainers we can only wait I guess.

@devshgraphicsprogramming
Copy link
Author

So will we get a VK_EXT_raytracing or VK_AMD_raytracing in Vulkan?

@scschaefer
Copy link
Contributor

AFAIK they were completely reworking the current RadeonRays Vulkan backend (which is deprecated at this point). Thus nothing GPU driver related.
I don't know if AMD is planning on releasing a counterpart to NVIDIA's VK_NVX_raytracing Vulkan extension. (I don't work for AMD so what I wrote earlier was just a guess)

@ivalylo
Copy link

ivalylo commented Nov 26, 2018

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...

@Degerz
Copy link

Degerz commented May 13, 2020

OpenCL has been officially dropped in the newest release!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants