6 ms·

This article lays out a solid overview as to how Nvidia got to where they are now. I'm curious (as someone without a deep knowledge of the technology or the ind

This article lays out a solid overview as to how Nvidia got to where they are now. I'm curious (as someone without a deep knowledge of the technology or the industry) as to why AMD can't create a similar dedicated ray-tracing functionality in their chips? It seems to be where the industry is going, and the article later goes on to point out how Meta and Google are doing this themselves. Why has AMD ceded this market? Is it a patent issue? Capability issue? Something else?

BudaDude 4y ago
I'm also curious why AMD hasn't implemented something like CUDA cores for ML. AMD cards are basically useless for doing any intensive ML task.
- smoldesu 4y ago
  They did try. A few years ago AMD and Apple collaborated to make OpenCL, which was a pretty half-hearted attempt at building a platform-agnostic GPGPU library. Their heart was in the right place, but that was part of the problem. Nvidia's vertical control over their hardware and software stack gave them insane leveraging power for lots of dedicated use cases (video editing, gaming, 3D rendering, machine learning, etc.) In the end, even after years of development, OpenCL was just really slow. There wasn't a whole lot of adoption in the backend market, and Apple was getting ready to kick them to the curb anyways. It's a little bit of a shame that AMD got their teeth kicked in for playing Mr. Nice Guy, but they should have know that Nvidia and Apple race for pinks.
  - paulmd 4y ago
    OpenCL had a bit of a "second-mover curse" where instead of trying to solve one problem (GPGPU acceleration) it tried to solve everything (a generalized framework for heterogeneous dispatch) and it just kinda sucks to actually use. It's not that it's slower or faster, in principle it should be the same speed when dispatched to the hardware (+/- any C/C++ optimization gotchas of course), but it just requires an obscene amount of boilerplate to "draw the first triangle" (or, launch the first kernel), much like Vulkan, and their own solution is still a pretty clos HIP was supposed to rectify this, but now you're buying into AMD's custom language and its limitations... and there are limitations, things that CUDA can do that HIP can't (texture unit access was an early one - and texture units aren't just for texturing, they're for coalescing all kinds of 2d/3d/higher-dimensional memory access). And AMD has a history of abandoning these projects after a couple years and leaving them behind and unsupported... like their Thrust framework counterpart, Bolt, which hasn't been updated in 8 years now. https://github.com/HSA-Libraries/Bolt https://github.com/HSA-Libraries/Bolt The old bit about "Vendor B" leaving behind a "trail of projects designed to pad resumes and show progress to middle managers" still reigns absolutely true with AMD. AMD has a big uphill climb in general to shake this reputation about being completely unserious with their software... and I'm not even talking about drivers here. This is even more the widespread community perception with their GPGPU/ML efforts than with their drivers. http://richg42.blogspot.com/2014/05/the-truth-on-opengl-driver-quality.html http://richg42.blogspot.com/2014/05/the-truth-on-opengl-driv... AMD doesn't have a library of warp-level/kernel-level/global "software primitives" like Cuda Unbound or Thrust either. So instead of writing your application, you are writing the primitives library, or writing your own poor implementation of them. https://github.com/NVIDIA/cub https://github.com/NVIDIA/cub https://github.com/NVIDIA/thrust https://github.com/NVIDIA/thrust It's just a fractal problem of "the software doesn't exist and AMD would really rather you write it for them" all the way down and nobody wants to do that instead of doing their own work. AMD is the one who benefits from the rewrite, for everyone else it's a "best case scenario it works the same as what we've already got", so if AMD isn't gonna do it then pretty much nobody else is gonna leap on it. And then AMD has poor adoption and no software and the cycle continues. AMD really really just needs to get serious and hire a half dozen engineers to sit there and write this software, cause it's just not going to happen otherwise. It's a drop in the bucket vs the sales to be realized here even in the medium term, like one big ML sale would probably more than pay those salaries. They're not doing it because they're cheap or they're doing it because they're not really serious, take your pick, but, AMD is no longer that broke, they can afford it and it makes financial sense. Again, not a "nice" thing to say but it's the cold truth here. I feel like I've made some variation on this post about every 6 months for like 5 years now but it's still relevant. If you as a vendor don't care about writing good code for key features/libraries for your product, nobody else is either, and you'll never get uptake. It's the same thing with AMD/ATI not embedding developers with studios to get those optimizations for their architectures. Console lock-in will only get you so far. If you don't care about the product as a vendor, nobody else will either. It's remarkable how much flak Jensen got for "NVIDIA is a software company now" back in 2009, and how people still don't get it, AMD is not a software company and that's why they keep failing. Writing the framework that turns into StableDiffusion and sells a billion dollars of GPUs is the NVIDIA business model, AMD keeps trying to jump straight to the "sell a billion dollars of GPUs" part and keeps failing.
    - slavik81 4y ago
      The ROCm software primatives library is rocPRIM [1] and the ROCm equivalent to Thrust is rocThrust [2]. Though, if you're a user of CUB, it might be easier to use hipCUB [3] to support both platforms. [1]: https://github.com/ROCmSoftwarePlatform/rocPRIM https://github.com/ROCmSoftwarePlatform/rocPRIM [2]: https://github.com/ROCmSoftwarePlatform/rocThrust https://github.com/ROCmSoftwarePlatform/rocThrust [3]: https://github.com/ROCmSoftwarePlatform/hipCUB https://github.com/ROCmSoftwarePlatform/hipCUB
      - paulmd 4y ago
        That's HIP, and you're putting your faith in ongoing support, but, it's cool that those libraries got ported. I bet my old thesis would probably HIPify pretty well.
        slavik81 4y ago
        I work on the ROCm libraries and I have faith in my ongoing employment. There's still lots of work on our roadmap. I joined AMD because I believed HIP could be successful. I don't plan to leave until either we have made it so or I no longer believe it can be.
  - pjmlp 4y ago
    Intel and AMD never bothered to move OpenCL beyond bare bones C source, while NVidia not only moved CUDO into a polyglot ecosystem early on, they doubled down on IDE for GPGPU computing and first class libraries. Google never bothered with OpenCL on Android, pushing their C99 Renderscript dialect instead. Apple repented themselves of offering OpenGL to Khronos and the direction not going into the way they wanted to. Those that blame NVidia for their "practices" should rather look into how bad the competition has been from day one.
- paulmd 4y ago
  AMD has "tensor cores" (called something different but they're very similar matrix accelerator units) in CDNA. RNDA3 is supposed to have "something", it has the same instruction as CDNA, it's supposed to be less than a full unit but presumably there wouldn't be an instruction without some level of hardware acceleration either. The bigger problem is that AMD doesn't want to pay to keep up on the software side... at the end of the day when you're coming from behind you just have to pay someone to port key pieces of software to your platform. AMD has really coasted for a long time on letting the open-source community do their work for them, but that's not going to fly with things like PyTorch or other key pieces of software... if AMD wants the sales and the adoption of their hardware, it's just going to have to pay someone to write the software, so that people who want to do research and not PyTorch maintenance can justify buying the hardware. I am not particularly interested in the perceived historical justifications for the current situation, it doesn't matter to the businesses who might be AMD's customers. And actually in many ways they've gotten even shakier recently, what with dropping RDNA support from their NN/ML package. As a cold statement of reality, this is table stakes going forward and if AMD doesn't want to do it they won't get the sales. It's not even just PyTorch either, it's... everything. AMD is just coming from a million miles behind on the software, and "welp just write it yourself if you want to use our hardware" is not an attitude that is conductive to selling hardware.
  - rektide 4y ago
    Which libraries is AMD dropping RDNA support in? That seems very inadvised. Nvidia's libraries being usable by a broad range of developers on a wide range of hardware is critical to their wide adoption. AMD cannot expect to have real adoption if only their fancy enterprise grade unobtanium cards support ML systems. AMD needs a wide & engaged community trying to yse their stuff to figure out what software/drivers they simply have to build.
    - paulmd 4y ago
      Talking specifically about ROCm here, their ML package. God this is such a tough paragraph to write accurately. AMD themselves have conflicting information all over their docs and repos and half of it is not even marked as "outdated"... https://docs.amd.com/bundle/ROCm-Getting-Started-Guide-v5.2.3 https://docs.amd.com/bundle/ROCm-Getting-Started-Guide-v5.2.... The official supported platforms at this point are RDNA2 (pro), GFX9 (pro), and CDNA. Consumer versions of these (RDNA2, Radeon VII, and Vega 56/64) probably work, although Vega 56/64 are an older version with much less hardware support as well. RDNA2 support is also "partial" and ymmv, things are often broken even on supported cards. If RDNA2 works, then RDNA1 may work, but again, mega ymmv, things may not even be great with RDNA2 yet. The "hardware guide" link talks about supporting Vega 10 (that's V56/64) and says GFX8 (Polaris) and GFX7 (Hawaii) are supported... but that doc is tagged 5.0 and 5.1 was the release that dropped the other stuff. So I'd say Vega 64/56 chips are probably broken at this point, on the current builds. Up until earlier this year though, it was unsupported on any consumer card except Radeon VII. They dropped Hawaii/Polaris/Vega support about 6 months before they started adding partial RDNA2 support back. And in contrast... NVIDIA's shit runs on everything, going back 10 years or more. At least to Kepler, if not Fermi or Tesla uarch (GTX 8800 series). It may not run great, but CUDA is CUDA, feature support has been a nearly forward ratchet, and they've had PTX to provide a rosetta stone in between the various architectural changes. I mean... at the end of the day the hardware hasn't changed that much, surely you can provide a shader fallback (which is required anyway since RDNA2 doesn't have tensor acceleration). I don't get what the deal is tbh. https://www.techpowerup.com/288864/amd-rocm-4-5-drops-polaris-architecture-support https://www.techpowerup.com/288864/amd-rocm-4-5-drops-polari... https://www.phoronix.com/news/Radeon-ROCm-5.1 https://www.phoronix.com/news/Radeon-ROCm-5.1
ActionHank 4y ago
AMD already has dedicated raytracing hardware on their GPUs, but are behind Nvidia. PC games that opted for Nvidia raytracing earlier on run poorly with an AMD GPU with raytracing turned on. Cyberpunk 2077 is an example of this, runs beautifully on Nvidia gpus with rt on, framerate falls through the floor on an AMD card. Raytracing on the "next gen" consoles PS5 and XBox Series X is done using AMD hardware and runs really well.
- yazzku 4y ago
  Indeed. The platform the devs target is very relevant. Often one can get caught up just comparing RT across vendors, but the reality is that the implementations are different and probably make different trade-offs. It's therefore no wonder that console games often outperform on AMD, and NVIDIA-signed games likewise on NVIDIA cards.
ckozlowski 4y ago
I'm theorizing here, but I suspect it's because AMD feels like building out a dedicated or proprietary capability could really hurt them if it didn't take off. By that logic, NVidia's risk here could hurt them as well (and that they are taking a risk is the point the article it trying to make.) AMD has for a long time favored an inclusive, compatible approach. First (that I can recall) with x86-64, more recently with AdaptiveSync over G-Sync, and now with their Ray Tracing approach. Each time they chose a move efficient path that was open to the industry as a whole. This seems to have had some pros and cons. On the one hand, they've been able to keep up with the market with a solution that is the best value for them. They've never been a large company against the likes of Intel and NVidia, so I suspect there's less appetite for risk. On the other hand, by always going that route, they cede the leadership role to others, or if they do have leadership, it's not in a way they can really leverage. It becomes commoditized. Note how when the industry was moving to 64bit, AMD ended up setting the direction over IA-64 with their more inclusive approach. But it didn't turn into any significant leverage for them. They set a standard, but it was one that everyone else then adopted, including Intel. So I feel like while AMD's approach keeps them alive and always in the running, it's an approach that will never put them on top. Whether or not this is a bad thing really depends on what the goals of the company are, and if the the goal is to remain steadily in the race, then they're doing great. But arguably, NVidia pulls the industry in directions by way of its choices. They're risky and sometimes irritable. It's also put them in front. So in my opinion, AMD hasn't ceded the market, but they have ceded leadership in many instances by their safe approach. It's still profitable and safe for them. But they'll always remain second place as a result.
- bee_rider 4y ago
  It makes sense -- as the underdog they need to erode entrenched advantages, starting up a standards-based compatible approach is a cheap way of doing so (on top of being totally laudable and good for the community). I wonder if we could ever see Radeon Rays on Intel's GPUs, or even their iGPUs. Raytracing in every low-resource-requirement MOBA, I say!
  - yazzku 4y ago
    The Intel ARC does seem to handle RT/DXR: https://game.intel.com/story/intel-arc-graphics-ray-tracing/ https://game.intel.com/story/intel-arc-graphics-ray-tracing/
gamdevthrowaway 4y ago
> as to why AMD can't create a similar dedicated ray-tracing functionality in their chips? They do and it works well. > out how Meta and Google are doing this themselves. Meta and Google develop products everywhere all the time. The author doesn't play or develop games, so it's okay that he doesn't really know anything or can meaningfully comment on it. He just took what Huang said and Ctrl+C Ctrl+V'd it. WHY DO PEOPLE CARE ABOUT RAYTRACING? Photoreal gets financing. For your game, for your crypto thing, whatever. Raytracing makes photoreal demos at pre-financing costs. Also essential reason why Unreal Engine is appealing. Unity is for people who make games, Unreal is for people who finance games. WHY DO PEOPLE CARE ABOUT AI-GENERATED CONTENT? The Darwinian force here is the same: people believe you can make a game (or whatever) out of DALL-E or whatever dogshite. They don't believe you when you say you would hire an artist in Indonesia for the same cost (or whatever). So you'll get financed by saying one and not the other. The reasons why don't really matter. It's idiosyncratic. You're going to spend the money however it is. Just like every startup. Also the AI generation thing attracts people who think they're the smartest, hottest shit on Earth. That attitude gets financing. Doesn't mean it reflects reality. DO THESE TECHNOLOGIES MATTER? I don't know. What does Ben Thompson know about making fun video games? It's so complicated. I doubt Big Corporate or VC capital is going to have financed the innovative video game that uses raytracing or AI generated content. It's going to be some indie game developer.
- 411111111111111 4y ago
  > Also essential reason why Unreal Engine is appealing. Is that why unreal engine deprecated ray tracing? You're honestly quiet clueless considering your phrasing. I bet you haven't worked in a large studio working with unreal engine either.
  - gamdevthrowaway 4y ago
    > Is that why unreal engine deprecated ray tracing? Unreal Engine didn't deprecate ray tracing, they are using the same DirectX DXR APIs in a different place. But I think you already know that. > I bet you haven't worked in a large studio working with unreal engine either. Have you?
samstave 4y ago
amd seed was intel having to lit give them chip designs... in the 90s. google was secretly making their own motherboards in ~2004 that were multi proc "meta" (fucking idiot name) was building a crap ton of secret datacenter hardware and architecture in the 2010s... and they are part of the secret sauce... (source ;;worked for all in diff capacities)
Maciek416 4y ago
IMO, a major ingredient of raytracing running well enough in a game that also looks as good as any other current AAA title in raster-only mode has been DLSS. Raytracing is (or at least, at time of 2xxx series GPUs, was) still quite expensive to run at full res at resolutions (1440p, 4K) and framerates (60,120,144) that PC gamers demand. However, rendering raytraced games at a much lower resolution is just within reach for dedicated CUDA hardware. So DLSS makes up the difference with very sophisticated upscaling. Without DLSS, I think the raytracing in titles like Cyberpunk 2077 might not be performant enough. In light of this, you might go back and see that AI and RT for NVidia have gone hand in hand, because one enables the other to be performant enough for AAA titles. Opinions may vary greatly on this, but personally, I don't think AMD's FSR upscaler is capable of matching what DLSS can do in this regard. (Intel's upscaling does seem to be capable of doing it, but very high performance parts are still some ways away from release).

BudaDude 4y ago

I'm also curious why AMD hasn't implemented something like CUDA cores for ML. AMD cards are basically useless for doing any intensive ML task.

smoldesu 4y ago
They did try. A few years ago AMD and Apple collaborated to make OpenCL, which was a pretty half-hearted attempt at building a platform-agnostic GPGPU library. Their heart was in the right place, but that was part of the problem. Nvidia's vertical control over their hardware and software stack gave them insane leveraging power for lots of dedicated use cases (video editing, gaming, 3D rendering, machine learning, etc.) In the end, even after years of development, OpenCL was just really slow. There wasn't a whole lot of adoption in the backend market, and Apple was getting ready to kick them to the curb anyways. It's a little bit of a shame that AMD got their teeth kicked in for playing Mr. Nice Guy, but they should have know that Nvidia and Apple race for pinks.
- paulmd 4y ago
  OpenCL had a bit of a "second-mover curse" where instead of trying to solve one problem (GPGPU acceleration) it tried to solve everything (a generalized framework for heterogeneous dispatch) and it just kinda sucks to actually use. It's not that it's slower or faster, in principle it should be the same speed when dispatched to the hardware (+/- any C/C++ optimization gotchas of course), but it just requires an obscene amount of boilerplate to "draw the first triangle" (or, launch the first kernel), much like Vulkan, and their own solution is still a pretty clos HIP was supposed to rectify this, but now you're buying into AMD's custom language and its limitations... and there are limitations, things that CUDA can do that HIP can't (texture unit access was an early one - and texture units aren't just for texturing, they're for coalescing all kinds of 2d/3d/higher-dimensional memory access). And AMD has a history of abandoning these projects after a couple years and leaving them behind and unsupported... like their Thrust framework counterpart, Bolt, which hasn't been updated in 8 years now. https://github.com/HSA-Libraries/Bolt https://github.com/HSA-Libraries/Bolt The old bit about "Vendor B" leaving behind a "trail of projects designed to pad resumes and show progress to middle managers" still reigns absolutely true with AMD. AMD has a big uphill climb in general to shake this reputation about being completely unserious with their software... and I'm not even talking about drivers here. This is even more the widespread community perception with their GPGPU/ML efforts than with their drivers. http://richg42.blogspot.com/2014/05/the-truth-on-opengl-driver-quality.html http://richg42.blogspot.com/2014/05/the-truth-on-opengl-driv... AMD doesn't have a library of warp-level/kernel-level/global "software primitives" like Cuda Unbound or Thrust either. So instead of writing your application, you are writing the primitives library, or writing your own poor implementation of them. https://github.com/NVIDIA/cub https://github.com/NVIDIA/cub https://github.com/NVIDIA/thrust https://github.com/NVIDIA/thrust It's just a fractal problem of "the software doesn't exist and AMD would really rather you write it for them" all the way down and nobody wants to do that instead of doing their own work. AMD is the one who benefits from the rewrite, for everyone else it's a "best case scenario it works the same as what we've already got", so if AMD isn't gonna do it then pretty much nobody else is gonna leap on it. And then AMD has poor adoption and no software and the cycle continues. AMD really really just needs to get serious and hire a half dozen engineers to sit there and write this software, cause it's just not going to happen otherwise. It's a drop in the bucket vs the sales to be realized here even in the medium term, like one big ML sale would probably more than pay those salaries. They're not doing it because they're cheap or they're doing it because they're not really serious, take your pick, but, AMD is no longer that broke, they can afford it and it makes financial sense. Again, not a "nice" thing to say but it's the cold truth here. I feel like I've made some variation on this post about every 6 months for like 5 years now but it's still relevant. If you as a vendor don't care about writing good code for key features/libraries for your product, nobody else is either, and you'll never get uptake. It's the same thing with AMD/ATI not embedding developers with studios to get those optimizations for their architectures. Console lock-in will only get you so far. If you don't care about the product as a vendor, nobody else will either. It's remarkable how much flak Jensen got for "NVIDIA is a software company now" back in 2009, and how people still don't get it, AMD is not a software company and that's why they keep failing. Writing the framework that turns into StableDiffusion and sells a billion dollars of GPUs is the NVIDIA business model, AMD keeps trying to jump straight to the "sell a billion dollars of GPUs" part and keeps failing.
  - slavik81 4y ago
    The ROCm software primatives library is rocPRIM [1] and the ROCm equivalent to Thrust is rocThrust [2]. Though, if you're a user of CUB, it might be easier to use hipCUB [3] to support both platforms. [1]: https://github.com/ROCmSoftwarePlatform/rocPRIM https://github.com/ROCmSoftwarePlatform/rocPRIM [2]: https://github.com/ROCmSoftwarePlatform/rocThrust https://github.com/ROCmSoftwarePlatform/rocThrust [3]: https://github.com/ROCmSoftwarePlatform/hipCUB https://github.com/ROCmSoftwarePlatform/hipCUB
    - paulmd 4y ago
      That's HIP, and you're putting your faith in ongoing support, but, it's cool that those libraries got ported. I bet my old thesis would probably HIPify pretty well.
      - slavik81 4y ago
        I work on the ROCm libraries and I have faith in my ongoing employment. There's still lots of work on our roadmap. I joined AMD because I believed HIP could be successful. I don't plan to leave until either we have made it so or I no longer believe it can be.
- pjmlp 4y ago
  Intel and AMD never bothered to move OpenCL beyond bare bones C source, while NVidia not only moved CUDO into a polyglot ecosystem early on, they doubled down on IDE for GPGPU computing and first class libraries. Google never bothered with OpenCL on Android, pushing their C99 Renderscript dialect instead. Apple repented themselves of offering OpenGL to Khronos and the direction not going into the way they wanted to. Those that blame NVidia for their "practices" should rather look into how bad the competition has been from day one.
paulmd 4y ago
AMD has "tensor cores" (called something different but they're very similar matrix accelerator units) in CDNA. RNDA3 is supposed to have "something", it has the same instruction as CDNA, it's supposed to be less than a full unit but presumably there wouldn't be an instruction without some level of hardware acceleration either. The bigger problem is that AMD doesn't want to pay to keep up on the software side... at the end of the day when you're coming from behind you just have to pay someone to port key pieces of software to your platform. AMD has really coasted for a long time on letting the open-source community do their work for them, but that's not going to fly with things like PyTorch or other key pieces of software... if AMD wants the sales and the adoption of their hardware, it's just going to have to pay someone to write the software, so that people who want to do research and not PyTorch maintenance can justify buying the hardware. I am not particularly interested in the perceived historical justifications for the current situation, it doesn't matter to the businesses who might be AMD's customers. And actually in many ways they've gotten even shakier recently, what with dropping RDNA support from their NN/ML package. As a cold statement of reality, this is table stakes going forward and if AMD doesn't want to do it they won't get the sales. It's not even just PyTorch either, it's... everything. AMD is just coming from a million miles behind on the software, and "welp just write it yourself if you want to use our hardware" is not an attitude that is conductive to selling hardware.
- rektide 4y ago
  Which libraries is AMD dropping RDNA support in? That seems very inadvised. Nvidia's libraries being usable by a broad range of developers on a wide range of hardware is critical to their wide adoption. AMD cannot expect to have real adoption if only their fancy enterprise grade unobtanium cards support ML systems. AMD needs a wide & engaged community trying to yse their stuff to figure out what software/drivers they simply have to build.
  - paulmd 4y ago
    Talking specifically about ROCm here, their ML package. God this is such a tough paragraph to write accurately. AMD themselves have conflicting information all over their docs and repos and half of it is not even marked as "outdated"... https://docs.amd.com/bundle/ROCm-Getting-Started-Guide-v5.2.3 https://docs.amd.com/bundle/ROCm-Getting-Started-Guide-v5.2.... The official supported platforms at this point are RDNA2 (pro), GFX9 (pro), and CDNA. Consumer versions of these (RDNA2, Radeon VII, and Vega 56/64) probably work, although Vega 56/64 are an older version with much less hardware support as well. RDNA2 support is also "partial" and ymmv, things are often broken even on supported cards. If RDNA2 works, then RDNA1 may work, but again, mega ymmv, things may not even be great with RDNA2 yet. The "hardware guide" link talks about supporting Vega 10 (that's V56/64) and says GFX8 (Polaris) and GFX7 (Hawaii) are supported... but that doc is tagged 5.0 and 5.1 was the release that dropped the other stuff. So I'd say Vega 64/56 chips are probably broken at this point, on the current builds. Up until earlier this year though, it was unsupported on any consumer card except Radeon VII. They dropped Hawaii/Polaris/Vega support about 6 months before they started adding partial RDNA2 support back. And in contrast... NVIDIA's shit runs on everything, going back 10 years or more. At least to Kepler, if not Fermi or Tesla uarch (GTX 8800 series). It may not run great, but CUDA is CUDA, feature support has been a nearly forward ratchet, and they've had PTX to provide a rosetta stone in between the various architectural changes. I mean... at the end of the day the hardware hasn't changed that much, surely you can provide a shader fallback (which is required anyway since RDNA2 doesn't have tensor acceleration). I don't get what the deal is tbh. https://www.techpowerup.com/288864/amd-rocm-4-5-drops-polaris-architecture-support https://www.techpowerup.com/288864/amd-rocm-4-5-drops-polari... https://www.phoronix.com/news/Radeon-ROCm-5.1 https://www.phoronix.com/news/Radeon-ROCm-5.1

ActionHank 4y ago

AMD already has dedicated raytracing hardware on their GPUs, but are behind Nvidia. PC games that opted for Nvidia raytracing earlier on run poorly with an AMD GPU with raytracing turned on. Cyberpunk 2077 is an example of this, runs beautifully on Nvidia gpus with rt on, framerate falls through the floor on an AMD card. Raytracing on the "next gen" consoles PS5 and XBox Series X is done using AMD hardware and runs really well.

yazzku 4y ago
Indeed. The platform the devs target is very relevant. Often one can get caught up just comparing RT across vendors, but the reality is that the implementations are different and probably make different trade-offs. It's therefore no wonder that console games often outperform on AMD, and NVIDIA-signed games likewise on NVIDIA cards.

ckozlowski 4y ago

I'm theorizing here, but I suspect it's because AMD feels like building out a dedicated or proprietary capability could really hurt them if it didn't take off. By that logic, NVidia's risk here could hurt them as well (and that they are taking a risk is the point the article it trying to make.) AMD has for a long time favored an inclusive, compatible approach. First (that I can recall) with x86-64, more recently with AdaptiveSync over G-Sync, and now with their Ray Tracing approach. Each time they chose a move efficient path that was open to the industry as a whole. This seems to have had some pros and cons. On the one hand, they've been able to keep up with the market with a solution that is the best value for them. They've never been a large company against the likes of Intel and NVidia, so I suspect there's less appetite for risk. On the other hand, by always going that route, they cede the leadership role to others, or if they do have leadership, it's not in a way they can really leverage. It becomes commoditized. Note how when the industry was moving to 64bit, AMD ended up setting the direction over IA-64 with their more inclusive approach. But it didn't turn into any significant leverage for them. They set a standard, but it was one that everyone else then adopted, including Intel. So I feel like while AMD's approach keeps them alive and always in the running, it's an approach that will never put them on top. Whether or not this is a bad thing really depends on what the goals of the company are, and if the the goal is to remain steadily in the race, then they're doing great. But arguably, NVidia pulls the industry in directions by way of its choices. They're risky and sometimes irritable. It's also put them in front. So in my opinion, AMD hasn't ceded the market, but they have ceded leadership in many instances by their safe approach. It's still profitable and safe for them. But they'll always remain second place as a result.

bee_rider 4y ago
It makes sense -- as the underdog they need to erode entrenched advantages, starting up a standards-based compatible approach is a cheap way of doing so (on top of being totally laudable and good for the community). I wonder if we could ever see Radeon Rays on Intel's GPUs, or even their iGPUs. Raytracing in every low-resource-requirement MOBA, I say!
- yazzku 4y ago
  The Intel ARC does seem to handle RT/DXR: https://game.intel.com/story/intel-arc-graphics-ray-tracing/ https://game.intel.com/story/intel-arc-graphics-ray-tracing/

gamdevthrowaway 4y ago

> as to why AMD can't create a similar dedicated ray-tracing functionality in their chips? They do and it works well. > out how Meta and Google are doing this themselves. Meta and Google develop products everywhere all the time. The author doesn't play or develop games, so it's okay that he doesn't really know anything or can meaningfully comment on it. He just took what Huang said and Ctrl+C Ctrl+V'd it. WHY DO PEOPLE CARE ABOUT RAYTRACING? Photoreal gets financing. For your game, for your crypto thing, whatever. Raytracing makes photoreal demos at pre-financing costs. Also essential reason why Unreal Engine is appealing. Unity is for people who make games, Unreal is for people who finance games. WHY DO PEOPLE CARE ABOUT AI-GENERATED CONTENT? The Darwinian force here is the same: people believe you can make a game (or whatever) out of DALL-E or whatever dogshite. They don't believe you when you say you would hire an artist in Indonesia for the same cost (or whatever). So you'll get financed by saying one and not the other. The reasons why don't really matter. It's idiosyncratic. You're going to spend the money however it is. Just like every startup. Also the AI generation thing attracts people who think they're the smartest, hottest shit on Earth. That attitude gets financing. Doesn't mean it reflects reality. DO THESE TECHNOLOGIES MATTER? I don't know. What does Ben Thompson know about making fun video games? It's so complicated. I doubt Big Corporate or VC capital is going to have financed the innovative video game that uses raytracing or AI generated content. It's going to be some indie game developer.

411111111111111 4y ago
> Also essential reason why Unreal Engine is appealing. Is that why unreal engine deprecated ray tracing? You're honestly quiet clueless considering your phrasing. I bet you haven't worked in a large studio working with unreal engine either.
- gamdevthrowaway 4y ago
  > Is that why unreal engine deprecated ray tracing? Unreal Engine didn't deprecate ray tracing, they are using the same DirectX DXR APIs in a different place. But I think you already know that. > I bet you haven't worked in a large studio working with unreal engine either. Have you?

samstave 4y ago

amd seed was intel having to lit give them chip designs... in the 90s. google was secretly making their own motherboards in ~2004 that were multi proc "meta" (fucking idiot name) was building a crap ton of secret datacenter hardware and architecture in the 2010s... and they are part of the secret sauce... (source ;;worked for all in diff capacities)

Maciek416 4y ago

IMO, a major ingredient of raytracing running well enough in a game that also looks as good as any other current AAA title in raster-only mode has been DLSS. Raytracing is (or at least, at time of 2xxx series GPUs, was) still quite expensive to run at full res at resolutions (1440p, 4K) and framerates (60,120,144) that PC gamers demand. However, rendering raytraced games at a much lower resolution is just within reach for dedicated CUDA hardware. So DLSS makes up the difference with very sophisticated upscaling. Without DLSS, I think the raytracing in titles like Cyberpunk 2077 might not be performant enough. In light of this, you might go back and see that AI and RT for NVidia have gone hand in hand, because one enables the other to be performant enough for AAA titles. Opinions may vary greatly on this, but personally, I don't think AMD's FSR upscaler is capable of matching what DLSS can do in this regard. (Intel's upscaling does seem to be capable of doing it, but very high performance parts are still some ways away from release).