24 ms·

AMD is edging closer to breaking Nvidia's graphic dominance

143 points by toufiqbarhamov 8y ago

dragontamer 8y ago
I'm no graphics programmer. I'm mostly interested in the compute (OpenCL, CUDA) side of things. I don't own an NVidia GPU, so my experience mostly relates to AMD. I'm certainly interested in AMD's Linux "ROCm" push. I really think the programming model there is relatively easy to understand, but there are major flaws in the documentation and implementation. For example, OpenCL 1.2 on ROCm 2.0 isn't stable enough to run Blender Cycles. Yes, you can render the default cube, but very slowly. On a real scene, Blender Cycles on OpenCL ROCm can take 500+ seconds to compile, and the actual execution seems to hang (infinite loop and/or memory segfault, depending on the scene) on anything close to a typical geometry. Note that Blender's OpenCL code is explicitly written for AMD's older OpenCL (AMDGPU-Pro OpenCL implementation). Blender has a separate CUDA branch for NVidia cards. So OpenCL ROCm is at very least performance-incompatible with OpenCL AMDGPU-Pro. The Blender OpenCL code probably has to be rewritten to work (ie: not infinite loop), and maybe even become efficient on OpenCL ROCm again. -------- AMD's hardware is fine (not as power-efficient as NVidia, but performance is fine, in theory). But the drivers / software stack is clearly immature. Even as ROCm has hit a 2.0 release, these sorts of issues still exist. AMDGPU-PRO with OpenCL1.2 is workable, but feels old and cranky. (OpenCL 1.2 was specified in 2011, and is missing key features. Its atomics model is incompatible with C/C++11, its missing SVM and kernel-side enqueue... etc. etc.) AMDGPU-PRO OpenCL2.0 is theoretically supported, but is still unstable in my experience. ROCm OpenCL (both 1.2 and 2.0) is still under development, but doesn't seem to be ready for prime-time yet. (At least, with Blender 2.79 or 2.80 Cycles is any indication). AMD HCC seems usable, but there aren't many programs using it. AMD HIP is an interesting idea but I haven't used it. I know NVidia has driver issues / software issues. But CUDA Code written 5 years ago will still have similar performance / implementation if run on today's cards, on today's software stack. I'm not sure if the same is true for AMD's OpenCL code (between AMDGPU-PRO OpenCL1.2 and ROCm 1.2). ---------- Long story short: the only mature AMD OpenCL compute platform seems to be OpenCL 1.2 on AMDGPU-PRO. Fortunately, it also seems like AMDGPU-PRO will work for the foreseeable future, but AMD really needs to clarify its platform to attract developers. (Ex: prioritize testing of ROCm OpenCL to ensure performance-compatibility with existing OpenCL 1.2 code written for AMDGPU-PRO)
- shmerl 8y ago
  Is OpenCL implementation open source in the PRO package?
  - dragontamer 8y ago
    No. AMDGPU-PRO is closed-source. Which is partially why ROCm exists. Its the OpenSource implementation of AMD's driver stack. AMD seems to have indicated that the Open Source ROCm drivers are the way of the future. Its a sentiment I can certainly get behind (and AMD has even pushed the ROCm driver stack to the Linux Kernel proper). But ROCm isn't ready quite yet. So I think in practice, people will still be relying upon the older AMDGPU-Pro drivers. At least for the next year.
- jacobush 8y ago
  It's so interesting that ever since 1998 ATI (AMD) drivers have always been crap and the Nvidia ones good. That's more than 20 years now.
  - bryanlarsen 8y ago
    On Linux in my experience, Nvidia drivers are crap and have always been crap. AMD have gone from much crappier to almost OK.
    - jacobush 8y ago
      It's been a while now admittedly for me with Linux, but for me it was like, AMD was always trying to halfheartedly support open source, their proprietary drivers fast but buggy and hard to install. The open source driver slow and stable. Nvidia made no pretense, you downloaded a thin open source shim, typed "make" and then it worked and was fast. And 99.9% proprietary blob.
      - bryanlarsen 8y ago
        "and then it worked" not my experience
shmerl 8y ago
Radeon 7 (Vega 20) is a major overkill for gaming though. It looks more like a 3D rendering targeted card. Upcoming Navi cards supposedly should be more gaming oriented and more affordable.
- TwoNineA 8y ago
  Not overkill in 4K gaming or high refresh rate gaming.
  - shmerl 8y ago
    I think 4K gaming is a red herring really. At least at present. Here is a nice video on the topic: https://www.youtube.com/watch?v=ehvz3iN8pp4 https://www.youtube.com/watch?v=ehvz3iN8pp4 Nice optimum today are monitors with something like 2560x1440 and up to 144Hz adaptive sync. And you don't need Vega 20 with crazy expensive 16GB VRAM for that. Hopefully Navi will fit that use case well and will have less availability issues than Vega 10 (56/64) cards.
    - elif 8y ago
      > high refresh rate gaming > up to 144Hz adaptive sync you are agreeing with him... In my personal experience, I need every watt of performance out of 2080ti to approach achieve a consistent 180-240hz.
      - shmerl 8y ago
        > you are agreeing with him. Not really. For 2560x1440 resolution you don't need so much VRAM (that's what makes Radeon 7 so expensive). So it is an overkill and not very practical for gaming. It's probably a really good 3D rendering card though. > I need every watt of performance out of 2080ti to approach achieve a consistent 180-240hz I think 144Hz is more than enough. More would be an overkill as well. And Vega 64 and upcoming Navi should handle 60-144 fps well at 2560x1440.
        8y ago
meshenna 8y ago
Methinks the title is a bit too strongly worded. At that price point Radeon VII is unlikely to win many customers over. If some of the recent leaks[1] turn out to be true, then we can talk about "edging closer to breaking Nvidia's graphic dominance." [1] https://youtu.be/PCdsTBsH-rI?t=1247 https://youtu.be/PCdsTBsH-rI?t=1247 Edit: added timestamp to video
kordlessagain 8y ago
Related, AMD's stock has been heavily manipulated for years: https://seekingalpha.com/article/4153502-institutional-short-sale-amd-abusive https://seekingalpha.com/article/4153502-institutional-short...
- dpflan 8y ago
  This is very interesting. Are you aware of any more research into this?
twtw 8y ago
I'm not sure I follow the reasoning in the article. It says if ray tracing flops, AMD will take the lead, but then goes on to say that AMD believes ray tracing will be important and is working on it.
- devonkim 8y ago
  It’s not too dissimilar from how AVX instructions are so poorly implemented on AMD CPUs - they may support it but it may not be core to their strategy (no pun intended).
  - dragontamer 8y ago
    AVX instructions are actually done fine in my experience. 256-bit is emulated, but that's not really a big deal. Intel is faster for sure, but I never had issues running AVX code on AMD CPUs. The performance characteristics are different between Intel and AMD. In fact, AMD has some tricks up its sleeve. AMD Zen has two AES pipelines (while Intel Skylake only has one), so vectorized AES code is faster on AMD. There are some performance issues with vpgatherdd instructions, but Intel has those as uop emulated code too. So both Intel and AMD are equally to blame there. ---------- My "issues" with AMD CPUs are relatively tame. AMD's profiling tools are weaker than Intel's. (Ex: AMD has "Instruction Based Sampling" while Intel's "PEBS" (Precision Event Based Sampling) are a bit easier to use. True 256-bit execution would be nice, but its not a major hassle in most cases IMO: AMD's back-end is very thick, so you can still get a lot of ILP out of AVX2 instructions.
    - floatboth 8y ago
      > High Precision Event Timers Isn't HPET is just a basic system timer? (That is definitely present on Zen.) You might be thinking of something else? > 256-bit execution would be nice, but its not a major hassle in most cases Coming with Zen 2 anyway :)
      - dragontamer 8y ago
        > Isn't HPET is just a basic system timer? (That is definitely present on Zen.) You might be thinking of something else? You're right. I got the names confused. I've edited the post above to use the proper "PEBS" term. Intel's "Precise Event-Based Sampling" is what I was trying to talk about. Intel's PEBS can precisely tell you where a branch-mispredict happens. AMD's default event timers are inaccurate: your branch mispredictions will be all over "add" instructions, and other unrelated stuff. This is because a CPU is looking at roughly ~100 instruction windows (between the pipeline, decoder, and retirement... there's a lot of inaccuracy in determining "where did this branch misprediction happen??"). So when trying to track down a branch-misprediction on AMD systems, you have to switch to the harder to use "Instruction based Profiling" mode. Intel has a simpler PEBS switch which is easier to use IMO.
dogma1138 8y ago
With a $5000> card (MI50) AMD is forced to sell at a loss to be able to meet the same performance levels NVIDIA had for the same amount of money ($700) 2 years ago. If this is getting closer I think they need a better tape measurer. With 16GB of aquabolt HBM2 on a 7nm node there is no way AMD is losing less than $150 per card without even accounting for opportunity loss. In fact this card is the reason why the head of the RTG was fired when suggesting to sell it at $749 at a loss. The 2080 for all intents and purposes is a mid range die. The only thing AMD is competing on atm is price and for them it’s a lose lose situation until Navi comes out and that is only if Navi could actually be competitive above the $300 price bracket as it’s a Polaris successor its not clear if AMD will have anything on the level of the 2080 not to mention the 2080ti based on Navi. AMD had to drop the prices of VEGA to around $300 due to the RTX 2060 they are likely also losing money on that front, they are losing money on Radeon 7 and hopefully they will finally make money with Navi.
- throwaway2048 8y ago
  it is ridiculous to call a $750 GPU "midrange".
  - dogma1138 8y ago
    It’s still a mid range die - TU104, the high end die is the TU102, it’s all relative. We’re about 1 month away from NVIDIA’s next quarterly report it will be really interesting to see how much revenue they got so far from Turing especially considering the 2060 was released only 1 month prior to the date their revenue will be reported on.
    - dragontamer 8y ago
      The 2080 is 545mm^2. Intel's "HCC" 18-core Skylake Xeon is 485mm^2. There's nothing "mid-range" about a die at 545mm^2. Yeah, there are higher-end XCC Intel chips or higher end NVidia chips. But by any practical measurement, things pushing 500mm^2 or bigger is downright massive. Radeon VII is ~350mm^2, but on a very expensive 7nm process. Hard to tell what "high end" or "mid range" will be at 7nm right now, since there aren't too many chips being made to compare against.
brandon 8y ago
Depending on how much stock you put into the Steam Hardware Survey, it's worth noting that Nvidia still controls 74% of the market relative to AMD's 15%: https://store.steampowered.com/hwsurvey/videocard/ https://store.steampowered.com/hwsurvey/videocard/ I also feel like graphics cards are one of those weird things that command a lot of brand loyalty, so it's probably going to take more than near-performance-parity to move the needle.
- partiallypro 8y ago
  Absolutely for gaming, Nvidia has a very loyal fanbase (myself included since the 4600GTX days) but for data centers? Different ball game. Both companies are now pushing into that territory pretty hard.
  - shmerl 8y ago
    At least Linux gaming shows negative trend for Nvidia (though it's still a big majority), and for the obvious reason - AMD provide open source drivers which have become very competitive lately. See: https://www.gamingonlinux.com/index.php?module=statistics&view=trends https://www.gamingonlinux.com/index.php?module=statistics&vi...
    - mrtweetyhack 8y ago
      That' not a huge loss for Nvidia
  - pavon 8y ago
    I'd say CUDA has an even bigger lead over OpenCL than Nvidia has over AMD in the gaming market.
    - shmerl 8y ago
      Not CUDA itself, but lock-in of various libraries that are CUDA-only. No one stops you from making a library that works with OpenCL or Vulkan for example for compute purposes.
Octoth0rpe 8y ago
It's certainly a very small part of the overall GPU-buying community, but nearly the entire hackintosh community has more or less abandoned / foresworn NVIDIA due to lack of mojave drivers. Even on older macos releases, the nvidia drivers were awful.
so_tired 8y ago
Wanna know why AMD drivers are so broken? I talked once to an AMD project managery guy. He told me how they have several teams in different countries. And for each feature/bug different managers have to "bid" with weekly resource estimates. Bid too high and you dont get enough work for your peoples. Bid too low and they end up with unpaid overtime. Rinse and repeat. And these are kernel developers... EDIT: to be clear, I am rooting for competition to Intel and NVIDIA. I just dont think this kind of culture can work on the software side.
- thfuran 8y ago
  That's totally insane.
- ezoe 8y ago
  Seriously? That doesn't work in an entity who share the same revenue. Everyone lose. They should rather hire the economist as their boss.
- bane 8y ago
  I'm not sure how to respond to this other than WTF?
- Yizahi 8y ago
  Though it is anecdotal information and relevant to AMD drivers from several years ago, but when AMD driver crashed (about once a year) it did so without affecting the system and restarted itself correctly, I only saw error message and windows going briefly to "basic" theme and back to aero. When Nvidia driver crashed (again, about once a year) it takes down entire system, it actually freezed Windows so completely that even ctrl-alt-del didn't work, and I had to power cycle the PC.
xvilka 8y ago
Good, NVIDIA should bankrupt as soon as possible, because of their opensource stance.
m0zg 8y ago
I (selfishly) hope they succeed. NVIDIA is getting ridiculous with their constrained supply of $1200+ high end GPUs.
- verelo 8y ago
  as someone that bought AMD stock with the belief that NVIDIA was over priced and it was about time it swung back the other way...me too!
mrtweetyhack 8y ago
This article tells me AMD lost this battle. Even having a 7nm advantage, AMD basically tied with Nvidia at 14nm. When Nvidia moves to 7nm (anybody can, just contract with TSMC and some engineering effort) what's AMD's next move?
jclay 8y ago
Maybe for the competitive consumer graphics market, but I don't see them disrupting Nvidia's hold in the HPC world. With Nvidia's NVLink, you can achieve high bandwidth data transfer between graphics cards without having to pass through the PCIe to CPU. If you have large computations that require syncing data among multiple GPU's, NVLink is your most performant option by a large margin. That's not to mention how much further ahead CUDA is from Sycl, OpenCL, ROCm, etc. I certainly welcome the competition (and hopefully an open standard). In my experience, CUDA is ahead on developer tooling, performance and productivity features (Thrust, Unified Memory, C++17 support, etc).
- ct520 8y ago
  AMD's NVLink is infinity fabric (MI60, MI50) isnt it? with 200gb card to card transfer rate... Did you take that into account? I agree the toolset is light years ahead of what I seen from AMD, but I'm not much into that.
  - jclay 8y ago
    Ah, I hadn't seen that announcement. It looks like this was announced recently (November 2018) and it's still 100Gb/s slower throughput than the latest NVLink. Either way, it could certainly be interesting if they compete on price, but I cannot find any information yet on actually using it to sync with OpenCL / ROCm.
deleted 8y ago
[deleted]

I'm no graphics programmer. I'm mostly interested in the compute (OpenCL, CUDA) side of things. I don't own an NVidia GPU, so my experience mostly relates to AMD. I'm certainly interested in AMD's Linux "ROCm" push. I really think the programming model there is relatively easy to understand, but there are major flaws in the documentation and implementation. For example, OpenCL 1.2 on ROCm 2.0 isn't stable enough to run Blender Cycles. Yes, you can render the default cube, but very slowly. On a real scene, Blender Cycles on OpenCL ROCm can take 500+ seconds to compile, and the actual execution seems to hang (infinite loop and/or memory segfault, depending on the scene) on anything close to a typical geometry. Note that Blender's OpenCL code is explicitly written for AMD's older OpenCL (AMDGPU-Pro OpenCL implementation). Blender has a separate CUDA branch for NVidia cards. So OpenCL ROCm is at very least performance-incompatible with OpenCL AMDGPU-Pro. The Blender OpenCL code probably has to be rewritten to work (ie: not infinite loop), and maybe even become efficient on OpenCL ROCm again. -------- AMD's hardware is fine (not as power-efficient as NVidia, but performance is fine, in theory). But the drivers / software stack is clearly immature. Even as ROCm has hit a 2.0 release, these sorts of issues still exist. AMDGPU-PRO with OpenCL1.2 is workable, but feels old and cranky. (OpenCL 1.2 was specified in 2011, and is missing key features. Its atomics model is incompatible with C/C++11, its missing SVM and kernel-side enqueue... etc. etc.) AMDGPU-PRO OpenCL2.0 is theoretically supported, but is still unstable in my experience. ROCm OpenCL (both 1.2 and 2.0) is still under development, but doesn't seem to be ready for prime-time yet. (At least, with Blender 2.79 or 2.80 Cycles is any indication). AMD HCC seems usable, but there aren't many programs using it. AMD HIP is an interesting idea but I haven't used it. I know NVidia has driver issues / software issues. But CUDA Code written 5 years ago will still have similar performance / implementation if run on today's cards, on today's software stack. I'm not sure if the same is true for AMD's OpenCL code (between AMDGPU-PRO OpenCL1.2 and ROCm 1.2). ---------- Long story short: the only mature AMD OpenCL compute platform seems to be OpenCL 1.2 on AMDGPU-PRO. Fortunately, it also seems like AMDGPU-PRO will work for the foreseeable future, but AMD really needs to clarify its platform to attract developers. (Ex: prioritize testing of ROCm OpenCL to ensure performance-compatibility with existing OpenCL 1.2 code written for AMDGPU-PRO)

shmerl 8y ago
Is OpenCL implementation open source in the PRO package?
- dragontamer 8y ago
  No. AMDGPU-PRO is closed-source. Which is partially why ROCm exists. Its the OpenSource implementation of AMD's driver stack. AMD seems to have indicated that the Open Source ROCm drivers are the way of the future. Its a sentiment I can certainly get behind (and AMD has even pushed the ROCm driver stack to the Linux Kernel proper). But ROCm isn't ready quite yet. So I think in practice, people will still be relying upon the older AMDGPU-Pro drivers. At least for the next year.
jacobush 8y ago
It's so interesting that ever since 1998 ATI (AMD) drivers have always been crap and the Nvidia ones good. That's more than 20 years now.
- bryanlarsen 8y ago
  On Linux in my experience, Nvidia drivers are crap and have always been crap. AMD have gone from much crappier to almost OK.
  - jacobush 8y ago
    It's been a while now admittedly for me with Linux, but for me it was like, AMD was always trying to halfheartedly support open source, their proprietary drivers fast but buggy and hard to install. The open source driver slow and stable. Nvidia made no pretense, you downloaded a thin open source shim, typed "make" and then it worked and was fast. And 99.9% proprietary blob.
    - bryanlarsen 8y ago
      "and then it worked" not my experience

shmerl 8y ago

Radeon 7 (Vega 20) is a major overkill for gaming though. It looks more like a 3D rendering targeted card. Upcoming Navi cards supposedly should be more gaming oriented and more affordable.

TwoNineA 8y ago
Not overkill in 4K gaming or high refresh rate gaming.
- shmerl 8y ago
  I think 4K gaming is a red herring really. At least at present. Here is a nice video on the topic: https://www.youtube.com/watch?v=ehvz3iN8pp4 https://www.youtube.com/watch?v=ehvz3iN8pp4 Nice optimum today are monitors with something like 2560x1440 and up to 144Hz adaptive sync. And you don't need Vega 20 with crazy expensive 16GB VRAM for that. Hopefully Navi will fit that use case well and will have less availability issues than Vega 10 (56/64) cards.
  - elif 8y ago
    > high refresh rate gaming > up to 144Hz adaptive sync you are agreeing with him... In my personal experience, I need every watt of performance out of 2080ti to approach achieve a consistent 180-240hz.
    - shmerl 8y ago
      > you are agreeing with him. Not really. For 2560x1440 resolution you don't need so much VRAM (that's what makes Radeon 7 so expensive). So it is an overkill and not very practical for gaming. It's probably a really good 3D rendering card though. > I need every watt of performance out of 2080ti to approach achieve a consistent 180-240hz I think 144Hz is more than enough. More would be an overkill as well. And Vega 64 and upcoming Navi should handle 60-144 fps well at 2560x1440.
      - 8y ago

meshenna 8y ago

Methinks the title is a bit too strongly worded. At that price point Radeon VII is unlikely to win many customers over. If some of the recent leaks[1] turn out to be true, then we can talk about "edging closer to breaking Nvidia's graphic dominance." [1] https://youtu.be/PCdsTBsH-rI?t=1247 https://youtu.be/PCdsTBsH-rI?t=1247 Edit: added timestamp to video

kordlessagain 8y ago

Related, AMD's stock has been heavily manipulated for years: https://seekingalpha.com/article/4153502-institutional-short-sale-amd-abusive https://seekingalpha.com/article/4153502-institutional-short...

dpflan 8y ago
This is very interesting. Are you aware of any more research into this?

twtw 8y ago

I'm not sure I follow the reasoning in the article. It says if ray tracing flops, AMD will take the lead, but then goes on to say that AMD believes ray tracing will be important and is working on it.

devonkim 8y ago
It’s not too dissimilar from how AVX instructions are so poorly implemented on AMD CPUs - they may support it but it may not be core to their strategy (no pun intended).
- dragontamer 8y ago
  AVX instructions are actually done fine in my experience. 256-bit is emulated, but that's not really a big deal. Intel is faster for sure, but I never had issues running AVX code on AMD CPUs. The performance characteristics are different between Intel and AMD. In fact, AMD has some tricks up its sleeve. AMD Zen has two AES pipelines (while Intel Skylake only has one), so vectorized AES code is faster on AMD. There are some performance issues with vpgatherdd instructions, but Intel has those as uop emulated code too. So both Intel and AMD are equally to blame there. ---------- My "issues" with AMD CPUs are relatively tame. AMD's profiling tools are weaker than Intel's. (Ex: AMD has "Instruction Based Sampling" while Intel's "PEBS" (Precision Event Based Sampling) are a bit easier to use. True 256-bit execution would be nice, but its not a major hassle in most cases IMO: AMD's back-end is very thick, so you can still get a lot of ILP out of AVX2 instructions.
  - floatboth 8y ago
    > High Precision Event Timers Isn't HPET is just a basic system timer? (That is definitely present on Zen.) You might be thinking of something else? > 256-bit execution would be nice, but its not a major hassle in most cases Coming with Zen 2 anyway :)
    - dragontamer 8y ago
      > Isn't HPET is just a basic system timer? (That is definitely present on Zen.) You might be thinking of something else? You're right. I got the names confused. I've edited the post above to use the proper "PEBS" term. Intel's "Precise Event-Based Sampling" is what I was trying to talk about. Intel's PEBS can precisely tell you where a branch-mispredict happens. AMD's default event timers are inaccurate: your branch mispredictions will be all over "add" instructions, and other unrelated stuff. This is because a CPU is looking at roughly ~100 instruction windows (between the pipeline, decoder, and retirement... there's a lot of inaccuracy in determining "where did this branch misprediction happen??"). So when trying to track down a branch-misprediction on AMD systems, you have to switch to the harder to use "Instruction based Profiling" mode. Intel has a simpler PEBS switch which is easier to use IMO.

dogma1138 8y ago

With a $5000> card (MI50) AMD is forced to sell at a loss to be able to meet the same performance levels NVIDIA had for the same amount of money ($700) 2 years ago. If this is getting closer I think they need a better tape measurer. With 16GB of aquabolt HBM2 on a 7nm node there is no way AMD is losing less than $150 per card without even accounting for opportunity loss. In fact this card is the reason why the head of the RTG was fired when suggesting to sell it at $749 at a loss. The 2080 for all intents and purposes is a mid range die. The only thing AMD is competing on atm is price and for them it’s a lose lose situation until Navi comes out and that is only if Navi could actually be competitive above the $300 price bracket as it’s a Polaris successor its not clear if AMD will have anything on the level of the 2080 not to mention the 2080ti based on Navi. AMD had to drop the prices of VEGA to around $300 due to the RTX 2060 they are likely also losing money on that front, they are losing money on Radeon 7 and hopefully they will finally make money with Navi.

throwaway2048 8y ago
it is ridiculous to call a $750 GPU "midrange".
- dogma1138 8y ago
  It’s still a mid range die - TU104, the high end die is the TU102, it’s all relative. We’re about 1 month away from NVIDIA’s next quarterly report it will be really interesting to see how much revenue they got so far from Turing especially considering the 2060 was released only 1 month prior to the date their revenue will be reported on.
  - dragontamer 8y ago
    The 2080 is 545mm^2. Intel's "HCC" 18-core Skylake Xeon is 485mm^2. There's nothing "mid-range" about a die at 545mm^2. Yeah, there are higher-end XCC Intel chips or higher end NVidia chips. But by any practical measurement, things pushing 500mm^2 or bigger is downright massive. Radeon VII is ~350mm^2, but on a very expensive 7nm process. Hard to tell what "high end" or "mid range" will be at 7nm right now, since there aren't too many chips being made to compare against.

brandon 8y ago

Depending on how much stock you put into the Steam Hardware Survey, it's worth noting that Nvidia still controls 74% of the market relative to AMD's 15%: https://store.steampowered.com/hwsurvey/videocard/ https://store.steampowered.com/hwsurvey/videocard/ I also feel like graphics cards are one of those weird things that command a lot of brand loyalty, so it's probably going to take more than near-performance-parity to move the needle.

partiallypro 8y ago
Absolutely for gaming, Nvidia has a very loyal fanbase (myself included since the 4600GTX days) but for data centers? Different ball game. Both companies are now pushing into that territory pretty hard.
- shmerl 8y ago
  At least Linux gaming shows negative trend for Nvidia (though it's still a big majority), and for the obvious reason - AMD provide open source drivers which have become very competitive lately. See: https://www.gamingonlinux.com/index.php?module=statistics&view=trends https://www.gamingonlinux.com/index.php?module=statistics&vi...
  - mrtweetyhack 8y ago
    That' not a huge loss for Nvidia
- pavon 8y ago
  I'd say CUDA has an even bigger lead over OpenCL than Nvidia has over AMD in the gaming market.
  - shmerl 8y ago
    Not CUDA itself, but lock-in of various libraries that are CUDA-only. No one stops you from making a library that works with OpenCL or Vulkan for example for compute purposes.

Octoth0rpe 8y ago

It's certainly a very small part of the overall GPU-buying community, but nearly the entire hackintosh community has more or less abandoned / foresworn NVIDIA due to lack of mojave drivers. Even on older macos releases, the nvidia drivers were awful.

so_tired 8y ago

Wanna know why AMD drivers are so broken? I talked once to an AMD project managery guy. He told me how they have several teams in different countries. And for each feature/bug different managers have to "bid" with weekly resource estimates. Bid too high and you dont get enough work for your peoples. Bid too low and they end up with unpaid overtime. Rinse and repeat. And these are kernel developers... EDIT: to be clear, I am rooting for competition to Intel and NVIDIA. I just dont think this kind of culture can work on the software side.

thfuran 8y ago
That's totally insane.
ezoe 8y ago
Seriously? That doesn't work in an entity who share the same revenue. Everyone lose. They should rather hire the economist as their boss.
bane 8y ago
I'm not sure how to respond to this other than WTF?
Yizahi 8y ago
Though it is anecdotal information and relevant to AMD drivers from several years ago, but when AMD driver crashed (about once a year) it did so without affecting the system and restarted itself correctly, I only saw error message and windows going briefly to "basic" theme and back to aero. When Nvidia driver crashed (again, about once a year) it takes down entire system, it actually freezed Windows so completely that even ctrl-alt-del didn't work, and I had to power cycle the PC.

xvilka 8y ago

Good, NVIDIA should bankrupt as soon as possible, because of their opensource stance.

m0zg 8y ago

I (selfishly) hope they succeed. NVIDIA is getting ridiculous with their constrained supply of $1200+ high end GPUs.

verelo 8y ago
as someone that bought AMD stock with the belief that NVIDIA was over priced and it was about time it swung back the other way...me too!

mrtweetyhack 8y ago

This article tells me AMD lost this battle. Even having a 7nm advantage, AMD basically tied with Nvidia at 14nm. When Nvidia moves to 7nm (anybody can, just contract with TSMC and some engineering effort) what's AMD's next move?

jclay 8y ago

Maybe for the competitive consumer graphics market, but I don't see them disrupting Nvidia's hold in the HPC world. With Nvidia's NVLink, you can achieve high bandwidth data transfer between graphics cards without having to pass through the PCIe to CPU. If you have large computations that require syncing data among multiple GPU's, NVLink is your most performant option by a large margin. That's not to mention how much further ahead CUDA is from Sycl, OpenCL, ROCm, etc. I certainly welcome the competition (and hopefully an open standard). In my experience, CUDA is ahead on developer tooling, performance and productivity features (Thrust, Unified Memory, C++17 support, etc).

ct520 8y ago
AMD's NVLink is infinity fabric (MI60, MI50) isnt it? with 200gb card to card transfer rate... Did you take that into account? I agree the toolset is light years ahead of what I seen from AMD, but I'm not much into that.
- jclay 8y ago
  Ah, I hadn't seen that announcement. It looks like this was announced recently (November 2018) and it's still 100Gb/s slower throughput than the latest NVLink. Either way, it could certainly be interesting if they compete on price, but I cannot find any information yet on actually using it to sync with OpenCL / ROCm.

deleted 8y ago

[deleted]