• Guest, The rules for the P & N subforum have been updated to prohibit "ad hominem" or personal attacks against other posters. See the full details in the post "Politics and News Rules & Guidelines."

Article [SA] "Samsung kills off a major silicon design program" ... RIP Mongoose?

Page 2 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

ThatBuzzkiller

Senior member
Nov 14, 2014
851
81
91
NVidia GPUs aren't VLIW.
Yes, they actually are according to some guys who reverse engineered the SASS (Shader ASSembly) for Kepler/Maxwell/Pascal ISAs. Nvidia doesn't publicly document their ISAs but if you disassemble the .cubin files with nvdisasm, it's pretty clear as day that their GPUs uses a VLIW instruction encoding scheme. Even Volta/Turing still uses control codes but I guess it's anything to win benchmarks ...
 

soresu

Senior member
Dec 19, 2014
650
162
116
How so ? Adreno GPUs and even most popular Nvidia GPUs currently in use today use VLIW as well ...
Those 2 companies have years of experience in that area though.

Also, I'm not altogether sure that either Adreno or nVidia currently use a VLIW based architecture - Adreno has doubtless gone through evolutions as ARM's Mali has (Utgard -> Midgard (VLIW) -> Bifrost (scalar) -> Valhall (scalar)), I would be surprised if Adreno at least still used the same basic architecture they bought from AMD/ATI at this point.
 

porcupineLTD

Junior Member
Dec 14, 2018
3
4
41
nVidia's current custom v8-A core Carmel is clearly aimed at AI/ML applications rather than general use, I doubt we shall see it in a Shield someday, it trades blows with A76, but A77 was announced 4 months ago, and A78 will add at least 15% IPC on top of that in 2020-21.
Carmel trades blows with A75 and with worse efficiency (thou that can be attributed to older process node) as per Anandtech's review of it.
 

Tup3x

Senior member
Dec 31, 2016
243
107
86
This makes sense as ARM's reference designs have outstripped everyone but Apple in the CPU (well ARM CPU, although ARM has started pushing Intel and AMD). Nvidia, who desperately needs CPU now that AMD and Intel are making GPUs (which means they'll be able to start squeezing Nvidia out), haven't had any luck getting traction on their CPU design (of course they took a more drastic approach). But Qualcomm couldn't either so it was becoming kinda futile. On top of that, custom ARM designs in many ways was fracturing the market, causing software related issues that prevent them from maximizing development (its why all the ARM GPUs have been chasing feature set of the PC GPUs, meet the standards to maximize compatibility). With ARM growing outside of mobile, it kinda needs to converge some to aid software development.

I'd guess another elephant in the room is IP issues. I think that was the major impetus behind the AMD GPU deal, but like with that, if they work with others they can pool R&D money and Samsung can trim some fat. Now Samsung lets others do the grunt of the chip design, and they can focus on the production engineering. Seems like a smart move for Samsung.

Heck, maybe AMD would absorb the team and put them to work developing the Samsung designs (pairing ARM reference with AMD GPU)? I think AMD could make the case, especially for their semi-custom unit as not having a track record with ARM very possibly cost them the Nintendo Switch deal (and there's definitely going to be others that want ARM designs, as streaming and VR/AR begins to grow).

Seemingly the team would be complete so AMD wouldn't need to do much more than give them some resources (money mostly, and if they use the ARM reference stuff mostly then ARM will be doing most of the chip design work) and since its still some time before the Samsung chips will be showing up, it shouldn't upset anything currently (i.e. steal production from AMD's other stuff; while giving them some help in using Samsung's fabs) and AMD could possibly work a deal with Samsung to get the team for cheap due to their established deal.
Speaking of NVIDIA they really should consider taking on Qualcomm in laptop/2-in-1 Windows devices. It is a bad thing for others if Qualcomm manages to monopolise Windows on ARM.
 

Thala

Senior member
Nov 12, 2014
845
194
116
Speaking of NVIDIA they really should consider taking on Qualcomm in laptop/2-in-1 Windows devices. It is a bad thing for others if Qualcomm manages to monopolise Windows on ARM.
Windows on ARM essentially runs on any ARMv8 system, provided it has a proper UEFI and drivers.
 

ThatBuzzkiller

Senior member
Nov 14, 2014
851
81
91
Those 2 companies have years of experience in that area though.

Also, I'm not altogether sure that either Adreno or nVidia currently use a VLIW based architecture - Adreno has doubtless gone through evolutions as ARM's Mali has (Utgard -> Midgard (VLIW) -> Bifrost (scalar) -> Valhall (scalar)), I would be surprised if Adreno at least still used the same basic architecture they bought from AMD/ATI at this point.
Adreno, I'm not too sure since Qualcomm doesn't release any information about their ISA but as for relatively recent Nvidia GPUs like Maxwell/Pascal they definitely do use VLIW instruction encoding for their control codes since they're organized into a 'bundle' of 4 instructions ...

It's not like it matters that much though since Nvidia has the best shader compiler team in the world to hack the game's shaders day in and day out to replace them with their optimized shaders. Nvidia's driver stack is probably well over 50+ million lines of code by now ...
 

ThatBuzzkiller

Senior member
Nov 14, 2014
851
81
91
We don't know what's inside Adreno, and nV stuff is anything but VLIW.
Not true for the latter, to them VLIW is actually an advantage since they can afford to keep doing per-game specific hacks in their drivers to win benchmarks while also winning at power efficiency too ...
 

soresu

Senior member
Dec 19, 2014
650
162
116
Nvidia's driver stack is probably well over 50+ million lines of code by now
That is its own problem, even with modularised code that quantity would be a mess to administrate - though no doubt AMD's is little different despite their assertions to GCN scalar being easier to code for.
 

gdansk

Senior member
Feb 8, 2011
404
68
91
This is unfortunate, hopefully they find new and interesting work. Given the number of companies trying to make ARM chips for servers I'm surprised Samsung didn't give that a shot before axing the group.
 

ThatBuzzkiller

Senior member
Nov 14, 2014
851
81
91
Control codes?
It's pretty similar stuff to Intel's Itanium ...

That is its own problem, even with modularised code that quantity would be a mess to administrate - though no doubt AMD's is little different despite their assertions to GCN scalar being easier to code for.
AMD's GCN architecture pretty much is easier for the compiler designers but that doesn't mean it translates to the most highest performance strategy since AMD hardware makes the trade of power efficiency for scheduling simplifications ...

Heck, even Valve who is a 3rd party with limited knowledge about AMD HW was able to make a shader compiler (ACO) for GCN!

Nvidia also changes it's ISA very aggressively compared to AMD so they'd have to account for several totally different ISAs in their driver stack compared to AMD just dealing with a couple of variants of GCN ...

nV GPUs are nothing VLIW, just read their execution model.
Quite a few modern NV GPUs are VLIW. What exactly are you reading about ? If it's high level material such as PTX then that is not useful information to how Nvidia's SASS actually works under the hood inside their hardware. Kepler/Maxwell/Pascal are all VLIW and nothing is going to change that ...
 

Yotsugi

Golden Member
Oct 16, 2017
1,029
469
106
Quite a few modern NV GPUs are VLIW
None of them are.
how Nvidia's SASS actually works under the hood inside their hardware.
Something something whitepapers made by some people.
Kepler/Maxwell/Pascal are all VLIW and nothing is going to change that ...
None of them are whatever-slot VLIW.
Do you mean companies should just bet on what currently works? That's not a good way to increase revenues and that means they'd be already late :)
No, they don't bet against the biggest x86 server fistfight since Opteron DC.
 

NTMBK

Diamond Member
Nov 14, 2011
8,456
1,295
126
Do you mean companies should just bet on what currently works? That's not a good way to increase revenues and that means they'd be already late :)
ARM servers looked like a good bet a few years ago, when it looked like x86 was going to turn into an Intel monopoly and big customers wanted a real competitor. But now AMD is competitive again, and migrating your stack to AMD is a damn sight easier than migrating to ARM.
 

Nothingness

Golden Member
Jul 3, 2013
1,988
280
126
No, they don't bet against the biggest x86 server fistfight since Opteron DC.
Now go back 20 years ago and apply your claim to the market. With your logic we would have no x86 server now. Of course the past does not always repeat itself, and various things are different here, but still if we follow your thought, nothing will ever change in the server market.

ARM servers looked like a good bet a few years ago, when it looked like x86 was going to turn into an Intel monopoly and big customers wanted a real competitor. But now AMD is competitive again, and migrating your stack to AMD is a damn sight easier than migrating to ARM.
That's a very good point (and I somehow agree with @Yotsugi). My point is just that if you don't take risks, you're sure things will not change. And bets in the server markets are long time ones; it took Intel many years to get really strong here (and not mocked by the RISC mobs).

Let's see how Fujitsu, Marvell and Ampere bets turn out. Oh and the various Chinese bets too. I'm not optimistic, but I'm glad to see some try.
 

soresu

Senior member
Dec 19, 2014
650
162
116
AMD just dealing with a couple of variants of GCN
6 variants - Southern Islands, Sea Islands, Volcanic Islands, Polaris, Vega, Vega 2/Vega 7nm/Radeon 7.

Arcturus could be a 7th if rumours/driver code holds true.

I don't know where people have been getting the idea that AMD have been lax in uArch/ISA changes - sure they have had trouble putting out a full line up for each generation (to be expected from a cash strapped company), but there certainly has been serious iteration in the last decade.
 
Last edited:

soresu

Senior member
Dec 19, 2014
650
162
116
But now AMD is competitive again, and migrating your stack to AMD is a damn sight easier than migrating to ARM
A lot of the stack migration problems stemmed from adequate ARM ports of various software, which is admittedly not at parity with x86 still, but a great leap from where it was only a few years ago - the efforts of Linaro have not been solely limited to ARM Android by any means.

The presentation on Neoverse N1/Ares seemed pretty impressive, and that is really just their first serious effort in this direction.

I'm not saying they are by any means likely to gain huge market share, but they are definitely in a much better position, even with AMD's Phoenix like ascent.

If anything, the x86 market is still tricky, despite AMD's resurgence because of where its IP development occurs - especially for China currently.

ARM may not be a sure bet, but it is more so to some than either x86 vendors which are both based in the US.
 

ThatBuzzkiller

Senior member
Nov 14, 2014
851
81
91
None of them are.

Something something whitepapers made by some people.

None of them are whatever-slot VLIW.
Those whitepapers are made by computer engineering/science specialists so if it's anyone that knows about the architecture of Nvidia GPUs aside from Nvidia employees themselves then it would be them ...

Instruction bundling is the defining feature of VLIW architectures. It is this explicit encoding that is required for Maxwell/Pascal GPUs to be able to dual-issue instructions ...

Kepler/Maxwell/Pascal are all able to to dual-issue instructions from each warp. Kepler has different dual-issue rules compared to Maxwell/Pascal (same ISA). Why else were previous Nvidia architectures able to hold significant area/power efficiency advantages against AMD's ? It is simply because Nvidia had a VLIW architecture all along that they were able to save on die area and power consumption due to not having the addition of more functional units ...

Intel's Itanium had the ability to triple-issue instructions per bundle ...

Consequently, Volta/Turing are only able to single-issue instructions so this means that they aren't VLIW anymore but this comes at a fairly significant price in terms of increased die area of which this change can be attributed to ...

6 variants - Southern Islands, Sea Islands, Volcanic Islands, Polaris, Vega, Vega 2/Vega 7nm/Radeon 7.

Arcturus could be a 7th if rumours/driver code holds true.

I don't know where people have been getting the idea that AMD have been lax in uArch/ISA changes - sure they have had trouble putting out a full line up for each generation (to be expected from a cash strapped company), but there certainly has been serious iteration in the last decade.
It's a fact. How else would Valve be able to make their ACO shader compiler be compatible with several AMD architectures ? Valve would be one of the last places I'd expect to see specialists in shader compilers ...

That being said it's not a bad idea for AMD to go with a maintenance friendly strategy and it could potentially pay off if the industry decides to one day converge to AMD's architecture ...
 

ASK THE COMMUNITY

TRENDING THREADS