Well, they're using GPUs to perform the light calculations required to create a photomask that will get the designs they've already produced onto real silicon. But sure, they're using GPUs to design GPUs. I'm sure this technology will create more opportunities to use inverse lithography and therefore have huge implications for the actual designs, which may no longer have to hold back quite as much due to compute concerns.
It's just sad how absent AMD is from such innovative uses of GPUs. It wouldn't bother me too much if at least their GPUs were much more affordable than Nvidia's, but they're not. They're at best playing catch-up months or years later with slight price discounts (the Steam HW survey still reflects this market discrepancy)
And I'm not talking about gimmicks like RTX, I'm talking about all these cool use cases around ML and DL like background noise cancelling, video upscaling, camera eye contact real-time deepfakes and now this. And that's if you ignore all the mind-blowing research papers put out by Nvidia which aren't featured in consumer apps yet.
This is Nvidia's biggest moat and AMD isn't even in the race here and for some reason Lisa Su seems to not give enough of a shit to compete.
I hate Nvidia for their price gouging and anti-consumer practices, but at least they haven't gotten complacent and are innovating on all fronts to keep pushing the envelope. Massive respect for the tech leadership at Nvidia.
Sure, but I think you can't really blame AMD for it.
Nvidia has dominated the market for a long time, and unlike Intel they up the prices and wisely spent enough of it on R&D, Nvidia is just reaping the rewards for it.
Sure you can. The difference between the CPU and GPU markets is that AMD is a competent competitor in one of them. Pre-Ryzen AMD knew they weren't competitive and AMD CPU pricing reflected that. The reason nVidia is getting away with their pricing is that AMD has been producing mediocre hardware (and drivers) and pricing it as if it were premium and competitive for the money. AMD's continually declining GPU market share indicates that customers aren't buying their argument.
But it applies to AMD in every way. I could understand that pre-ryzen when they were really cash restricted and had nothing to compete anyways. So you don't throw money at software devs. but the software side apart from (Windows) gaming is still a shit show with AMD today.
We wanted to use MI50s at work because it was promised they can do SRIOV, but we never got any further with AMD support than "it should work". They took ages to respond, and could not tell what was wrong from the extensive logs and hwinfo we provided them with.
Also the PCI reset bug that plagued multiple generations. There's a guy maintaining a kernel module that works around that issue in a whacky way. According to his research and reverse engineering, AMD could fix that with a firmware update to those cards. Even got in contact with AMD engineers briefly and outlined what the problem was. Then radio silence, and a couple months later AMD added a very similar workaround in their kernel module, the amdgpu driver. It's just that a fix in there doesn't make any sense whatsoever, because you need that fix when you do PCI passthrough, in which case you explicitly do not load the amdgpu module, as you don't use the GPU on the host machine but, well, pass it through to the VM.
They haven't been rich enough for long enough for it to matter.
As you noted pre-Ryzen they just didn't have the FCF to persue this kind of R&D. Ryzen was a bet the farm situation, if you are already betting the farm on one thing it's highly inadvisable to try do it on two things at the same time.
Nvidia benefits greatly from not having a split focus. They make GPUs, this is all. AMD needs to divide their efforts between staying ahead of Intel now that they have finally won themselves a lead which is no mean feat given how hard Intel has been chasing them down -and- putting out reasonable gaming GPUs -and- trying to come up with their first home-run datacenter GPU product which just hasn't happened yet.
I just don't see how they could have possibly had the money to try beat Nvidia over the last 5-6 years.
The money didn't come to Nvidia immediately. They were in exactly the same spot as ATI when they introduced hardware shaders in GF3 and later pioneered GPGPU on them. Moreover, ATI sometimes progressed in huge leaps (such as Radeon 9800Pro which was miles ahead of anything from Nvidia). ATI and then AMD just ignored general purpose massively parallel computations for a while, and then didn't know what to do with it, while Nvidia had a vision and actually implemented it.
"didn't know what to do with it" in a direst of times. It amazes me how selective people's memory is. Huang is not some amazing visionary. He's a ruthless businessman. Imagine if Intel had allowed him to steer that ship as he imagined all those years ago. Dark, dark times.
I applied for a job with AMD's GPU division. I am senior and qualified, and the hiring manager was a petty tyrant. At a company as large as AMD, departments have their own culture. Lisa Su has done an incredible job revitalizing their position in the CPU market, but the GPU side needs some serious attention.
The GPGPU situation is absolutely ridiculous. Imagine if you couldn't run code for an Intel CPU on an AMD chip, who would buy them? But somehow we accept that our GPUs, small super computers that often cost 50% of the total computer cost, can only run games and vendor proprietary code. I thought we would have this figured out a decade ago.
I can't even blame Nvidia, of course they're gonna do what's best for them, and it has worked. I blame AMD for completely dropping the ball on the GPU compute segment, and I blame users for preferring Cuda libraries instead of OpenCL.
I hope Intel and maybe AMD can get the GPGPU market to something that resembles something open and most importantly interoperable. But Nvidia has a big head start.
AMD64 is an extension of x86, it still runs older 32-bit code just fine. I don't see the relevance of IA64, the point wasn't about what Intel have done but about code running on different vendor's platforms.
For the most part you can recompile code written for x86 (x64) to run on ARM, and when you do it will run on future ARM processors as well. If you have Cuda code, you can't just recompile it to run on AMD or Intel, and if you compile ROCm code you can't run it on future AMD GPUs or on Windows or Mac. It's objectively a mess compared to the much easier CPU market, even though programmable GPUs have been around for two decades now.
Right. Pointedly, what happened when AMD came out with AMD64?
1. AMD made it a compatible superset of the existing standard x86. You could still run all other x86 code on it.
2. Intel then immediately made their new chips compatible with it. So if you're writing brand new code, you still don't have to pick only one horse or the other.
That was nothing remotely like the gpu situation.
Even a totally different ISA like ARM still isn't the same situation.
Practically the entire body of c code can be compiled and run on arm or x86 with no more difficulty than optimizing for 486 vs 686.
Most of the problems in arm land are just platform integration with bootloaders and peripheral drivers because phones are just not treated like generic user-programmable devices the way pc's started out. Not because it's fundamentally so unique and incompatible with anything else.
If the gpu situation were the same, then we would equally have both amd and nvidia drivers that take similar enough interface that a compiler could handle 90% of the translation and there would only need to be a little bit of platform awareness in the code, and as a result, all games and apps would work on all gpus, the same way bash works the same on both my i7 and my pi, and it's such a non-thing that no one even thinks that's remarkable. That's the difference. There is not even a hint of such a problem when it comes to cpu's, even cpus with different ISAs.
The fact that you can compile the same c code and run it on all of those is exactly the difference.
It doesn't matter that the ISA's are merely different, if the compiler automatically abstracts 99% of the difference. In the end, the developer of a random app doesn't have to do much of anything or care much what cpu the user is on. I have such code myself and it doesn't care.
I think that is the goal, but for various reasons are not actually usable (not good enough, not supported by things you actually need and have no control over, etc) I think part of the problem is unlike the cpu, the isa is not actually available fully. You have to use a blob that does sekrit majik stuff to use the card fully.
There are certain features that can't be replicated with ML-based rendering, or are poorly suited to it. It doesn't have a concept of worldspace, for one, which makes it struggle with light propagation and game logic in particular.
It's more likely that they'll complement each other - tagged geometry + hard raytracing for certain features + ML style transfer/rendering. At least until convincing and fully hallucinated worlds appear (which might or might not happen).
the approach to RT is basically cramming more and more cores and next to no specialised hardware anyway... so it is a safe path to take regardless what the drivers end up doing with them later
it's all about more cores, faster cores, more VRAM, faster VRAM - I doubt any research achieving any of that will go to waste
Current uses, with the notable exception of Quake 2 and possible that nvidia sponsored Portal mod, are pure gimmicks. The real thing requires ridiculous resources which are not available for real-time graphics.
Whenever use of AMD GPUs for ML comes up on HN I echo your points with the added personal experiences (PAIN) I've had trying to actually use an AMD GPU for anything other than driving a display.
In terms of the tech leadership at Nvidia, all you need to do is peek at the mind-blowing number of repos they have on Github - literally hundreds of component software pieces across every layer that at this point can do anything from drastic performance increases to completely unique (CUDA only of course) functionality.
On HN especially the whole "proprietary driver on Linux desktop situation" has hurt Nvidia significantly in terms of hearts and minds. As I said, then you look at almost any other software provided by Nvidia and realize they're actually a huge champion and supporter of open source for just about every aspect of the ecosystem other than the driver itself - and they're working on open sourcing the driver as well.
AMD occupies a weird space in GPU compute - there are massive HPC deployments of AMD GPUs. Presumably they only work because AMD is throwing a ton of essentially one-off support at them for deployment. On the other end you have their "support" for low to mid-range GPU compute. I say "support" with quotes because you realize very quickly it's absolutely pathetic to the point of useless and run back screaming to Nvidia/CUDA.
I'm not an Nvidia fanboy but my opinion at this point is the hardware markups for Nvidia GPU essentially subsidize all of the incredible (largely open source) software and ecosystem support they provide. Yes, they engage in anti-competitive practices but please show me a large corporation that doesn't. Fact is Nvidia has invested a massive amount of resources for well over a decade to earn their dominance of GPU compute.
Spending twice as much (somewhat factual but overblown popular opinion on HN) on Nvidia hardware becomes an obvious choice when you realize you're going to burn A TON of time (and still fail) trying to get AMD GPU hardware to actually do anything in ML.
Aside: Nvidia named this cuLitho, which I learned from my Spanish speaking mother-in-law basically looks like they named it 'butt'. So if you see a bunch of rear-end related memes about this software you know why!
According to the article, rule based patterns are already used, but inverse lithography is required in more unique or problematic cases. Ideally they would use it in all cases, maybe we end up with slightly wobbly but tolerable features for the more generic or less esoteric features that use the heuristics based approach.
> Even a change to the thickness of a material can lead to the need for a new set of photomasks
You can imagine the light spreading out through the other side of the mask, diffracting and interfering with neighbouring features through some radius. That it's not trivial to compute suggests the number of combinations within this radius is large enough to not be highly cacheable.
> - the computation output depends only on local features (my guess)
This is not correct: the features on the mask are larger than the features required on the target, which is the whole problem, so you need a diffraction pattern over a large area to produce a target feature. But then you need to overlap with the diffraction pattern of the next feature, and so on. I suspect that every pixel on the output gets determined by almost every pixel on the input, which is why it takes so much computation in the first place.
The chipmaking computation is inverse lithography, and the Nvidia system that is speeding it up is cuLitho on DGX H100.
I like how inverse lithography and neural network backpropagation were both techniques introduced in the 1980s and now we are finally seeing them both come to life, so to speak, with our sufficiently advanced GPUs.
40 comments
[ 2.2 ms ] story [ 101 ms ] threadAnd I'm not talking about gimmicks like RTX, I'm talking about all these cool use cases around ML and DL like background noise cancelling, video upscaling, camera eye contact real-time deepfakes and now this. And that's if you ignore all the mind-blowing research papers put out by Nvidia which aren't featured in consumer apps yet.
This is Nvidia's biggest moat and AMD isn't even in the race here and for some reason Lisa Su seems to not give enough of a shit to compete.
I hate Nvidia for their price gouging and anti-consumer practices, but at least they haven't gotten complacent and are innovating on all fronts to keep pushing the envelope. Massive respect for the tech leadership at Nvidia.
Nvidia has dominated the market for a long time, and unlike Intel they up the prices and wisely spent enough of it on R&D, Nvidia is just reaping the rewards for it.
We wanted to use MI50s at work because it was promised they can do SRIOV, but we never got any further with AMD support than "it should work". They took ages to respond, and could not tell what was wrong from the extensive logs and hwinfo we provided them with.
Also the PCI reset bug that plagued multiple generations. There's a guy maintaining a kernel module that works around that issue in a whacky way. According to his research and reverse engineering, AMD could fix that with a firmware update to those cards. Even got in contact with AMD engineers briefly and outlined what the problem was. Then radio silence, and a couple months later AMD added a very similar workaround in their kernel module, the amdgpu driver. It's just that a fix in there doesn't make any sense whatsoever, because you need that fix when you do PCI passthrough, in which case you explicitly do not load the amdgpu module, as you don't use the GPU on the host machine but, well, pass it through to the VM.
As you noted pre-Ryzen they just didn't have the FCF to persue this kind of R&D. Ryzen was a bet the farm situation, if you are already betting the farm on one thing it's highly inadvisable to try do it on two things at the same time.
Nvidia benefits greatly from not having a split focus. They make GPUs, this is all. AMD needs to divide their efforts between staying ahead of Intel now that they have finally won themselves a lead which is no mean feat given how hard Intel has been chasing them down -and- putting out reasonable gaming GPUs -and- trying to come up with their first home-run datacenter GPU product which just hasn't happened yet.
I just don't see how they could have possibly had the money to try beat Nvidia over the last 5-6 years.
AMD might be right not to put effort into manually optimizing for the old approach.
0. https://www.youtube.com/watch?v=yHrdEcsr9V0
I can't even blame Nvidia, of course they're gonna do what's best for them, and it has worked. I blame AMD for completely dropping the ball on the GPU compute segment, and I blame users for preferring Cuda libraries instead of OpenCL.
I hope Intel and maybe AMD can get the GPGPU market to something that resembles something open and most importantly interoperable. But Nvidia has a big head start.
Enough people that the Intel standard would lose out and you'd need to ask the reverse question? (See IA64 vs. AMD64.)
But if you mean, “what if there was a major microprocessor line incompatible with AMD64”, well, its called ARM and lots of people buy it.
For the most part you can recompile code written for x86 (x64) to run on ARM, and when you do it will run on future ARM processors as well. If you have Cuda code, you can't just recompile it to run on AMD or Intel, and if you compile ROCm code you can't run it on future AMD GPUs or on Windows or Mac. It's objectively a mess compared to the much easier CPU market, even though programmable GPUs have been around for two decades now.
1. AMD made it a compatible superset of the existing standard x86. You could still run all other x86 code on it.
2. Intel then immediately made their new chips compatible with it. So if you're writing brand new code, you still don't have to pick only one horse or the other.
That was nothing remotely like the gpu situation.
Even a totally different ISA like ARM still isn't the same situation.
Practically the entire body of c code can be compiled and run on arm or x86 with no more difficulty than optimizing for 486 vs 686.
Most of the problems in arm land are just platform integration with bootloaders and peripheral drivers because phones are just not treated like generic user-programmable devices the way pc's started out. Not because it's fundamentally so unique and incompatible with anything else.
If the gpu situation were the same, then we would equally have both amd and nvidia drivers that take similar enough interface that a compiler could handle 90% of the translation and there would only need to be a little bit of platform awareness in the code, and as a result, all games and apps would work on all gpus, the same way bash works the same on both my i7 and my pi, and it's such a non-thing that no one even thinks that's remarkable. That's the difference. There is not even a hint of such a problem when it comes to cpu's, even cpus with different ISAs.
It doesn't matter that the ISA's are merely different, if the compiler automatically abstracts 99% of the difference. In the end, the developer of a random app doesn't have to do much of anything or care much what cpu the user is on. I have such code myself and it doesn't care.
The same is not true for gpus.
It's more likely that they'll complement each other - tagged geometry + hard raytracing for certain features + ML style transfer/rendering. At least until convincing and fully hallucinated worlds appear (which might or might not happen).
it's all about more cores, faster cores, more VRAM, faster VRAM - I doubt any research achieving any of that will go to waste
Whenever use of AMD GPUs for ML comes up on HN I echo your points with the added personal experiences (PAIN) I've had trying to actually use an AMD GPU for anything other than driving a display.
In terms of the tech leadership at Nvidia, all you need to do is peek at the mind-blowing number of repos they have on Github - literally hundreds of component software pieces across every layer that at this point can do anything from drastic performance increases to completely unique (CUDA only of course) functionality.
On HN especially the whole "proprietary driver on Linux desktop situation" has hurt Nvidia significantly in terms of hearts and minds. As I said, then you look at almost any other software provided by Nvidia and realize they're actually a huge champion and supporter of open source for just about every aspect of the ecosystem other than the driver itself - and they're working on open sourcing the driver as well.
AMD occupies a weird space in GPU compute - there are massive HPC deployments of AMD GPUs. Presumably they only work because AMD is throwing a ton of essentially one-off support at them for deployment. On the other end you have their "support" for low to mid-range GPU compute. I say "support" with quotes because you realize very quickly it's absolutely pathetic to the point of useless and run back screaming to Nvidia/CUDA.
I'm not an Nvidia fanboy but my opinion at this point is the hardware markups for Nvidia GPU essentially subsidize all of the incredible (largely open source) software and ecosystem support they provide. Yes, they engage in anti-competitive practices but please show me a large corporation that doesn't. Fact is Nvidia has invested a massive amount of resources for well over a decade to earn their dominance of GPU compute.
Spending twice as much (somewhat factual but overblown popular opinion on HN) on Nvidia hardware becomes an obvious choice when you realize you're going to burn A TON of time (and still fail) trying to get AMD GPU hardware to actually do anything in ML.
- the computation output depends only on local features (my guess)
- most transistors look the same, so you can cache these results heavily
- the same holds for the interconnect layers
> Even a change to the thickness of a material can lead to the need for a new set of photomasks
You can imagine the light spreading out through the other side of the mask, diffracting and interfering with neighbouring features through some radius. That it's not trivial to compute suggests the number of combinations within this radius is large enough to not be highly cacheable.
This is not correct: the features on the mask are larger than the features required on the target, which is the whole problem, so you need a diffraction pattern over a large area to produce a target feature. But then you need to overlap with the diffraction pattern of the next feature, and so on. I suspect that every pixel on the output gets determined by almost every pixel on the input, which is why it takes so much computation in the first place.
I like how inverse lithography and neural network backpropagation were both techniques introduced in the 1980s and now we are finally seeing them both come to life, so to speak, with our sufficiently advanced GPUs.