Ray tracing seems to be all the rage at GDC this year, so AMD has announced Radeon-Rays, an open source ray tracing SDK. From what I understand, it's basically them making a big splash over a re-named and updated AMD FireRays with Vulkan support.
Here's what they said about it:
Radeon-Rays is a GPU intersection acceleration library with basic support for heterogeneous systems. AMD developed Radeon-Rays to help developers get the most out of AMD GPUs and CPU or APUs, as well as save them from maintaining hardware-dependent code. Radeon-Rays exposes a well-defined C++ API for scene construction and performing asynchronous ray intersection queries. The current implementation is based on OpenCL, which means Radeon-Rays supports execution on all platforms conforming to the OpenCL 1.2 standard. It is not limited to AMD hardware or a specific operating system. Radeon-Rays can be easily distributed and through its API helps assure compatibility and best performance across a wide range of hardware platforms.
YouTube videos require cookies, you must accept their cookies to view. View cookie preferences.
Direct Link
Direct Link
It's nice to see AMD continue to put their stuff out in the open, with it not being tied to their hardware and available for anyone to use. You can find it on GitHub with some other info available in this post on the GPUOpen site.
They also have the "Baikal initiative", an open source (MIT license) GPU-based global illumination renderer that initially started as a sample application for showing off Radeon-Rays, which has since evolved into a fully functional rendering engine.
Thanks for the tip, mirv!
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
What's the story with actually open OpenCL implementation for Linux?
Last edited by Shmerl on 23 March 2018 at 1:58 pm UTC
Last edited by Shmerl on 23 March 2018 at 1:58 pm UTC
0 Likes
Good, that should answer the hype that MS are trying to create with their lock-in.
1 Likes, Who?
Good, that should answer the hype that MS are trying to create with their lock-in.
More likely in relation to Nvidia's recent RTX demos with their Volta cards.
0 Likes
Good, that should answer the hype that MS are trying to create with their lock-in.
Whats Microsoft upto now? I admit I dont follow much of the goings on in windows world as I only use it for work and nothing else so have no need to hunt news about it out.
0 Likes
Whats Microsoft upto now?
Spreading lock-in, as usual.
Last edited by Shmerl on 23 March 2018 at 2:40 pm UTC
4 Likes, Who?
elbuglione Mar 23, 2018
I hope AMD shows a Linux demo soon.
0 Likes
In the meantime, isn't Blender doing almost the same with their realtime Eevee renderer? I know Eevee is not technically a ray tracer, but isn't it pulling similar tricks?
0 Likes
TheRiddick Mar 24, 2018
MS and NVIDIA would be very happy if Vulkan died off, or developers steer away from it. But realistically who wants to forever be locked in to Windows10 and XBOX1 platform? at least who in their right mind would...
0 Likes
In the meantime, isn't Blender doing almost the same with their realtime Eevee renderer? I know Eevee is not technically a ray tracer, but isn't it pulling similar tricks?Any Blender users checked out AMD's ProRender yet?
Also the new, upcoming lightmapper for Unity seems to be making use of RadeonRays:
View video on youtube.com
I wonder how cross platform these technologies really are? I wouldn't be surprised if the optimization effort went mostly towards their own hardware. :)
1 Likes, Who?
TheRiddick Mar 24, 2018
I'd be keen to see how performance is with AMD's vs NVIDIA or Microsoft's methods. NV is claiming 2-3x performance boost over traditional shader methods, that's seems pretty crazy.
Does AMD's method require new hardware, is NV claims just because Volta has great 16FP precision (up to 125 tflops apparently at fp16).
Last edited by TheRiddick on 24 March 2018 at 10:16 am UTC
Does AMD's method require new hardware, is NV claims just because Volta has great 16FP precision (up to 125 tflops apparently at fp16).
Last edited by TheRiddick on 24 March 2018 at 10:16 am UTC
0 Likes
MS and NVIDIA would be very happy if Vulkan died off, or developers steer away from it. But realistically who wants to forever be locked in to Windows10 and XBOX1 platform? at least who in their right mind would...
Unfortunately most users don't know or care. :(
0 Likes
MS and NVIDIA would be very happy if Vulkan died off, or developers steer away from it. But realistically who wants to forever be locked in to Windows10 and XBOX1 platform? at least who in their right mind would...
Actually I think that many studios would be happy to be locked to a single platform like XBOX1 if this also meant that all customers where locked into it and there where no middle man taking 30% of the profits. A single platform means far easier development and also that you can cheaply create a remaster for the next gen console and sell the same game once more and console means less piracy.
1 Likes, Who?
That would be the rub, though (well, one of them). Once all your customers are stuck on one platform and you're dependent on the tools made by the vendor of that platform, they can take as much of your profits as they want, because you have no other choices. It's the vendor's tools or you're not selling anything.MS and NVIDIA would be very happy if Vulkan died off, or developers steer away from it. But realistically who wants to forever be locked in to Windows10 and XBOX1 platform? at least who in their right mind would...
Actually I think that many studios would be happy to be locked to a single platform like XBOX1 if this also meant that all customers where locked into it and there where no middle man taking 30% of the profits.
Why do people think companies struggle so hard to gain monopolies? Why do people think laws got passed against monopolies in the first place?
1 Likes, Who?
That would be the rub, though (well, one of them). Once all your customers are stuck on one platform and you're dependent on the tools made by the vendor of that platform, they can take as much of your profits as they want, because you have no other choices. It's the vendor's tools or you're not selling anything.
Why do people think companies struggle so hard to gain monopolies? Why do people think laws got passed against monopolies in the first place?
the issue is, is not an monopoly.
its sony (ps4) vs nintendo (switch) vs microsoft (xbox and windows with play anywhere) vs valve and others on pc.
game makers have no reason to support linux, if it where: one side linux, other side microsoft monopoly, sure, some of then would chose to support either linux or both linux and windows.
but that is not the case, they arent afraid of ms monopoly that aint gonna happen.
sure support windows/mac/linux is cool, that is a reason to use vulkan.
but xbox right now is more profitable than mac and linux.
android could be a savior for us, but the types of games that are made for android are very different from the ones made for pc/console.
Final fantasy 15 tried to make an dumbed down version for mobile (ff15 pocket edition) i'm not sure if it sold well, but it has completely different assets.
now with the remake of secret of mana, they made graphics that could be ported to mobile easily (instead of dumb down the graphics).
other than that examples, i dont see companies having more incentive to use vulkan than to use DX12.
if they can afford they will use both to see where they get better results.
game engines on the other hand, have clients that make games for mobile and clients that make games for pc or console, they have an good reason to use vulkan (or both but giving priority to vulkan)
0 Likes
Your comment isn't really relevant to what I was saying. I was commenting on the idea that many studios would be happy to be locked to a single platform, and making a general point about the implications of such locking. In the abstract, like. It wasn't about the specifics of what platforms what is on right now.That would be the rub, though (well, one of them). Once all your customers are stuck on one platform and you're dependent on the tools made by the vendor of that platform, they can take as much of your profits as they want, because you have no other choices. It's the vendor's tools or you're not selling anything.
Why do people think companies struggle so hard to gain monopolies? Why do people think laws got passed against monopolies in the first place?
the issue is, is not an monopoly.
its sony (ps4) vs nintendo (switch) vs microsoft (xbox and windows with play anywhere) vs valve and others on pc.
game makers have no reason to support linux, if it where: one side linux, other side microsoft monopoly, sure, some of then would chose to support either linux or both linux and windows.
but that is not the case, they arent afraid of ms monopoly that aint gonna happen.
sure support windows/mac/linux is cool, that is a reason to use vulkan.
but xbox right now is more profitable than mac and linux.
android could be a savior for us, but the types of games that are made for android are very different from the ones made for pc/console.
Final fantasy 15 tried to make an dumbed down version for mobile (ff15 pocket edition) i'm not sure if it sold well, but it has completely different assets.
now with the remake of secret of mana, they made graphics that could be ported to mobile easily (instead of dumb down the graphics).
other than that examples, i dont see companies having more incentive to use vulkan than to use DX12.
if they can afford they will use both to see where they get better results.
game engines on the other hand, have clients that make games for mobile and clients that make games for pc or console, they have an good reason to use vulkan (or both but giving priority to vulkan)
But, talking of such specifics, your comment also misses a huge factor. It may become accurate in the future, but right now there is another huge platform that DX12 does not cover and Vulkan does: Windows < 10. Mostly Win7 I guess. There's still a LOT of that out there, and there will be for a couple-three years yet. So unless you're expecting your game to have a pretty dang robust "long tail", the "Not yet on Windows 10" market looms large, and you lose it if you go DX12.
0 Likes
That would be the rub, though (well, one of them). Once all your customers are stuck on one platform and you're dependent on the tools made by the vendor of that platform, they can take as much of your profits as they want, because you have no other choices. It's the vendor's tools or you're not selling anything.MS and NVIDIA would be very happy if Vulkan died off, or developers steer away from it. But realistically who wants to forever be locked in to Windows10 and XBOX1 platform? at least who in their right mind would...
Actually I think that many studios would be happy to be locked to a single platform like XBOX1 if this also meant that all customers where locked into it and there where no middle man taking 30% of the profits.
Why do people think companies struggle so hard to gain monopolies? Why do people think laws got passed against monopolies in the first place?
Yes, I am fully aware of the dangers of vendor lock in and/or monopoly but I'm not 100% sure that all studios are. My original comment was an observation not an opinion :)
1 Likes, Who?
Ray-tracing is actually 50 years old this year! Happy half-century, ray-tracing!
But you would be hard pressed to believe this if you looked at the hype from MS, NVIDIA and AMD. And, unfortunately, the journalists just repeat the junk spewed by marketing departments, because, on the whole, they do not understand the software or hardware engineering at all.
The graphics rendering community is actually quite an open one; they talk readily about techniques and algorithms. Ray-tracing has been a hot topic for some years, and "one-bounce" ray-tracing has already appeared as an alternative to shadow mapping for determining the visibility of lights when rendering pixels.
More than that, ray-tracing is actually simple to implement. You can do so in DX12, Vulkan and OpenGL 4.x without much difficulty, and possibly older versions with a little thought.
So why is it not used much yet? The answer is simply that the classic ray-tracing algorithm is recursive, and unbounded. That is, you trace a ray from the camera through each screen pixel until it hits something in the scene, then you spawn reflection, refraction and shadow ( one per light source ) rays and follow them to see what they hit, potentially spawning more and more rays ( thus, unbounded ), and you cannot complete the processing of any ray until you have completed the processing of any additional rays it spawned ( recursive ).
This is completely at odds with the hardware architecture of current GPUs, which expect every calculation path to be bounded and even - that is, you should be doing the same amount of processing for each pixel, not an unbounded, potentially random, amount. This means GPUs are very inefficient at "proper" ray-tracing. To code a practical real-time ray-tracer with current hardware, you need to set a "depth limit" on the recursion to ensure the stream processors are generally fully occupied, rather than sitting idle waiting for the one outlier stream that needs hundreds of recursions. This limit will depend on scene complexity and target frame rate, but is probably no more than about 4 levels of recursion, probably less.
The value in these libraries is probably limited at the moment, but "free" gains may come later with *possible* direct hardware support ( it may not actually be a good idea to use dedicated silicon ), and more thought into alternative methods of non-recursive ray-tracing, along with perhaps optimisations using spatial and temporal coherence. The downside, from a developer perspective, is that using this sort of library begins to limit program flexibility and dictate data structures.
But you would be hard pressed to believe this if you looked at the hype from MS, NVIDIA and AMD. And, unfortunately, the journalists just repeat the junk spewed by marketing departments, because, on the whole, they do not understand the software or hardware engineering at all.
The graphics rendering community is actually quite an open one; they talk readily about techniques and algorithms. Ray-tracing has been a hot topic for some years, and "one-bounce" ray-tracing has already appeared as an alternative to shadow mapping for determining the visibility of lights when rendering pixels.
More than that, ray-tracing is actually simple to implement. You can do so in DX12, Vulkan and OpenGL 4.x without much difficulty, and possibly older versions with a little thought.
So why is it not used much yet? The answer is simply that the classic ray-tracing algorithm is recursive, and unbounded. That is, you trace a ray from the camera through each screen pixel until it hits something in the scene, then you spawn reflection, refraction and shadow ( one per light source ) rays and follow them to see what they hit, potentially spawning more and more rays ( thus, unbounded ), and you cannot complete the processing of any ray until you have completed the processing of any additional rays it spawned ( recursive ).
This is completely at odds with the hardware architecture of current GPUs, which expect every calculation path to be bounded and even - that is, you should be doing the same amount of processing for each pixel, not an unbounded, potentially random, amount. This means GPUs are very inefficient at "proper" ray-tracing. To code a practical real-time ray-tracer with current hardware, you need to set a "depth limit" on the recursion to ensure the stream processors are generally fully occupied, rather than sitting idle waiting for the one outlier stream that needs hundreds of recursions. This limit will depend on scene complexity and target frame rate, but is probably no more than about 4 levels of recursion, probably less.
The value in these libraries is probably limited at the moment, but "free" gains may come later with *possible* direct hardware support ( it may not actually be a good idea to use dedicated silicon ), and more thought into alternative methods of non-recursive ray-tracing, along with perhaps optimisations using spatial and temporal coherence. The downside, from a developer perspective, is that using this sort of library begins to limit program flexibility and dictate data structures.
0 Likes
Well, you may be quite right about that.That would be the rub, though (well, one of them). Once all your customers are stuck on one platform and you're dependent on the tools made by the vendor of that platform, they can take as much of your profits as they want, because you have no other choices. It's the vendor's tools or you're not selling anything.MS and NVIDIA would be very happy if Vulkan died off, or developers steer away from it. But realistically who wants to forever be locked in to Windows10 and XBOX1 platform? at least who in their right mind would...
Actually I think that many studios would be happy to be locked to a single platform like XBOX1 if this also meant that all customers where locked into it and there where no middle man taking 30% of the profits.
Why do people think companies struggle so hard to gain monopolies? Why do people think laws got passed against monopolies in the first place?
Yes, I am fully aware of the dangers of vendor lock in and/or monopoly but I'm not 100% sure that all studios are. My original comment was an observation not an opinion :)
0 Likes
Your comment isn't really relevant to what I was saying. I was commenting on the idea that many studios would be happy to be locked to a single platform, and making a general point about the implications of such locking. In the abstract, like. It wasn't about the specifics of what platforms what is on right now.That would be the rub, though (well, one of them). Once all your customers are stuck on one platform and you're dependent on the tools made by the vendor of that platform, they can take as much of your profits as they want, because you have no other choices. It's the vendor's tools or you're not selling anything.
Why do people think companies struggle so hard to gain monopolies? Why do people think laws got passed against monopolies in the first place?
the issue is, is not an monopoly.
its sony (ps4) vs nintendo (switch) vs microsoft (xbox and windows with play anywhere) vs valve and others on pc.
game makers have no reason to support linux, if it where: one side linux, other side microsoft monopoly, sure, some of then would chose to support either linux or both linux and windows.
but that is not the case, they arent afraid of ms monopoly that aint gonna happen.
sure support windows/mac/linux is cool, that is a reason to use vulkan.
but xbox right now is more profitable than mac and linux.
android could be a savior for us, but the types of games that are made for android are very different from the ones made for pc/console.
Final fantasy 15 tried to make an dumbed down version for mobile (ff15 pocket edition) i'm not sure if it sold well, but it has completely different assets.
now with the remake of secret of mana, they made graphics that could be ported to mobile easily (instead of dumb down the graphics).
other than that examples, i dont see companies having more incentive to use vulkan than to use DX12.
if they can afford they will use both to see where they get better results.
game engines on the other hand, have clients that make games for mobile and clients that make games for pc or console, they have an good reason to use vulkan (or both but giving priority to vulkan)
But, talking of such specifics, your comment also misses a huge factor. It may become accurate in the future, but right now there is another huge platform that DX12 does not cover and Vulkan does: Windows < 10. Mostly Win7 I guess. There's still a LOT of that out there, and there will be for a couple-three years yet. So unless you're expecting your game to have a pretty dang robust "long tail", the "Not yet on Windows 10" market looms large, and you lose it if you go DX12.
UWP isnt compatible with Vulkan nor any program with opengl above 1.0
that means that vulkan apps cant run on xbox, hololens and whatever else microsoft put on the market.
currently lose the xbox market would do more harm to the pockets of the developers than losing mac/linux.
0 Likes
Did you in fact read what I said before you replied to it?Your comment isn't really relevant to what I was saying. I was commenting on the idea that many studios would be happy to be locked to a single platform, and making a general point about the implications of such locking. In the abstract, like. It wasn't about the specifics of what platforms what is on right now.That would be the rub, though (well, one of them). Once all your customers are stuck on one platform and you're dependent on the tools made by the vendor of that platform, they can take as much of your profits as they want, because you have no other choices. It's the vendor's tools or you're not selling anything.
Why do people think companies struggle so hard to gain monopolies? Why do people think laws got passed against monopolies in the first place?
the issue is, is not an monopoly.
its sony (ps4) vs nintendo (switch) vs microsoft (xbox and windows with play anywhere) vs valve and others on pc.
game makers have no reason to support linux, if it where: one side linux, other side microsoft monopoly, sure, some of then would chose to support either linux or both linux and windows.
but that is not the case, they arent afraid of ms monopoly that aint gonna happen.
sure support windows/mac/linux is cool, that is a reason to use vulkan.
but xbox right now is more profitable than mac and linux.
android could be a savior for us, but the types of games that are made for android are very different from the ones made for pc/console.
Final fantasy 15 tried to make an dumbed down version for mobile (ff15 pocket edition) i'm not sure if it sold well, but it has completely different assets.
now with the remake of secret of mana, they made graphics that could be ported to mobile easily (instead of dumb down the graphics).
other than that examples, i dont see companies having more incentive to use vulkan than to use DX12.
if they can afford they will use both to see where they get better results.
game engines on the other hand, have clients that make games for mobile and clients that make games for pc or console, they have an good reason to use vulkan (or both but giving priority to vulkan)
But, talking of such specifics, your comment also misses a huge factor. It may become accurate in the future, but right now there is another huge platform that DX12 does not cover and Vulkan does: Windows < 10. Mostly Win7 I guess. There's still a LOT of that out there, and there will be for a couple-three years yet. So unless you're expecting your game to have a pretty dang robust "long tail", the "Not yet on Windows 10" market looms large, and you lose it if you go DX12.
UWP isnt compatible with Vulkan nor any program with opengl above 1.0
that means that vulkan apps cant run on xbox, hololens and whatever else microsoft put on the market.
currently lose the xbox market would do more harm to the pockets of the developers than losing mac/linux.
0 Likes
Patreon
PayPal
See more from me