News NVIDIA and MediaTek want to bring RTX graphics to ARM laptops

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

NTMBK

Lifer
Nov 14, 2011
10,239
5,026
136
What would an ARM-based laptop look like with an RTX graphics card? That's something NVIDIA is exploring together with MediaTek, a company best known for building ARM-based chips. Together, they're building a reference laptop platform that'll support Chromium, Linux and NVIDIA SDKs (software development kits). While it's unclear what, if anything, this partnership will lead to, it's not hard to get excited about the idea of a next-generation Chromebook that's light, energy efficient and equipped with NVIDIA's ray-tracing RTX hardware, even if they inevitably end up being stripped down.


I don't really get why Mediatek is involved here? NVidia can clearly produce their own ARM SoCs. And I'm not taking it seriously until it runs Windows.

BUT... I can definitely see a future where an ARM laptop chip can emulate x86 games faster than an x86 chip in the same power envelope. And at that point, this could be viable.
 
  • Like
Reactions: SarahKerrigan

Shivansps

Diamond Member
Sep 11, 2013
3,855
1,518
136
Prove something? I do not have to prove something, what is clearly defined by the ARMv8 architecture specification - namely that unaligned data access is allowed, when HW checking is switched off.

I know what the specs say, but i was still having this issue both on RPI3 and 4 under 32 bits (armhf) with the kernel set to fixup when the game tried to access data to a struct that had a x,y,z floats on a bad memory offset, maybe it dosent happens on arm64, i told you that i never tested that. It should not, but i also dont know what are the "exclusive and ordered accesses" that the ARMv8 spec say that still need to be aligned.

Maybe I miss how slow they are but when i'm typing in word or what I'm doing right now, typing this post, certainly would work just fine on a A55, right? So the X1 could sleep and save power. Till I hit on "Post Reply" and loading a web site with X1 cores certainly will be much faster.

Yes, A55 is slow but it helps with power, certanly, the problem is that A55 is 4 years old now, what is considered ancient by ARM standarts and it is still used in new designs, i really dont know why it still has no replacement. X1 and A78 are very good and with a good implementation i think they are competitive vs current x86 offerings, but A55... i think it is around Braswell, so A55 is going to save power but it will also going to kill performance vs Alder lake or anything with 8 big cores like Zen3/4 for example.
 

Nothingness

Platinum Member
Jul 3, 2013
2,421
753
136
I know what the specs say, but i was still having this issue both on RPI3 and 4 under 32 bits (armhf) with the kernel set to fixup when the game tried to access data to a struct that had a x,y,z floats on a bad memory offset, maybe it dosent happens on arm64, i told you that i never tested that. It should not, but i also dont know what are the "exclusive and ordered accesses" that the ARMv8 spec say that still need to be aligned.
So you know that but that didn't prevent you from making claims that alignment is a killer issue for ARM porting (it really isn't):
Playing around my RPI 4 i did discover that is not all about performance, x86 has a huge advantage in software development, and that is unaligned memory access, is so common in x86 world that CPUs are actually optimised for it. ARM is a big "NOPE", therefore software must be developed with memory aligment in mind, failing to do that that, the kernel can fix most of these cases at a performance cost, in other is just a big NO, SIGBUS.

Or betting that any crash is due to alignment issues (there might be many reasons such as buggy translation of x86 SIMD instructions):
Yes the the 4GB version, question have run intro crashing issues with some x86_64 apps/games? Because i did noticed some issues, just as LTT, i noticed the same crashing with Luxmark and Handbrake, and there is even more people mentioning crashing stuff on youtube. Ill bet these are unaligned memory access crashes, i have no way to make sure on Windows (that i know of) on Linux they show up as "bus error".

And then making again a wrong deduction based on a wrong premise:
Ill say this because i actually had to make code changes to a x86 game to run it on ARM Linux on the PI due to this, YET, that same game runs perfectly fine whiout changes on the M1 both native and under Rosetta 2. I know that Apple added stuff to the M1 in order for x86 to ARM translation to work properly on the M1. That just awfull news for Microsoft.
What Apple added is a flag to natively support x86 memory ordering, not change alignment support.

You simply missed that AArch64 vs 32-bit is not the same despite several people pointing it to you months ago. And what I asked back then is to show the exact instruction that caused the issue. We could have then pointed you at the exact reason in the reference manual.

I don't think you invented that alignment issue. You very likely got one, in one of the few corner cases that exist (ldrd on 32-bit for instance). But then drew the wrong conclusion that alignment is required on ARM. That's where I disagree, not on your capacity to identify and fix a bug you found ;)
 
  • Like
Reactions: lobz and Thala

Shivansps

Diamond Member
Sep 11, 2013
3,855
1,518
136
You simply missed that AArch64 vs 32-bit is not the same despite several people pointing it to you months ago. And what I asked back then is to show the exact instruction that caused the issue. We could have then pointed you at the exact reason in the reference manual.

I don't think you invented that alignment issue. You very likely got one, in one of the few corner cases that exist (ldrd on 32-bit for instance). But then drew the wrong conclusion that alignment is required on ARM. That's where I disagree, not on your capacity to identify and fix a bug you found ;)

Fair enoght, if i only had some way to know the crash reason on windows i would have never said that, on linux it is actually very clear. As LTT pointed out, there are some apps crashing that does not happens on the M1 running W10 under Rosetta 2 (and i know that this game i mentioned runs fine on the M1). But at the same time it does not seems to happen to Thala (at least with those apps that LTT mentioned.).
 

Shivansps

Diamond Member
Sep 11, 2013
3,855
1,518
136
Is Laptop Gaming a large enough Market to even make this viable?

See the huge interest there is on Ryzen laptop cpus?, i dont see how a ARM cpu + RTX GPU wouldnt be just as or even more interesting. It is just a matter of price vs performance.

Also, it does not have to be about gaming, we are well pass the point were we can have ARM SoC for mainstream laptops, it is just a matter of someone putting the money to design the SoCs at this point, and Apple already played a key part in creating interest and support from software houses.

But i think OEM are going to ruin it from the power saving part, if there is any power saving, they are going to use that to cheap on the batteries and coolers, or they are going to go crazy with the power configuration and allow those chips to run well over their TDP, just like they do with x86 SoCs.
 
Last edited:

Thala

Golden Member
Nov 12, 2014
1,355
653
136
See the huge interest there is on Ryzen laptop cpus?, i dont see how a ARM cpu + RTX GPU wouldnt be just as or even more interesting. It is just a matter of price vs performance.

Also, it does not have to be about gaming, we are well pass the point were we can have ARM SoC for mainstream laptops, it is just a matter of someone putting the money to design the SoCs at this point, and Apple already played a key part in creating interest and support from software houses.

But i think OEM are going to ruin it from the power saving part, if there is any power saving, they are going to use that to cheap on the batteries and coolers, or they are going to go crazy with the power configuration and allow those chips to run well over their TDP, just like they do with x86 SoCs.

Agreed, there certainly is interest. As i mentioned in my earlier post i do use the Surface Pro X for gaming ... in fact i am doing the same as you did with FS2_open, i just compile SW, which i intend to use native for ARM64. And if i am going over the list, there are surprisingly many games or emulators i did port - for instance Doom3, Quake3, Mame, SNES9X, PCSX, PPSSPP, Dolphin, Fellow etc.
 

moinmoin

Diamond Member
Jun 1, 2017
4,952
7,666
136
Looks like Nvidia may be using this to get Mediatek to support its planned takeover of Arm:

 

Tup3x

Senior member
Dec 31, 2016
965
951
136
I somehow missed this: https://blogs.windows.com/windowsde...and-interoperable-apps-for-windows-11-on-arm/

Office on ARM64 is built as an ARM64EC (Emulation Compatible) application, which allows for the ARM64 code of Office to interoperate with x64 code of legacy add-ins. Learn more about ARM64EC.

Should help with getting more applications to ARM64.
 
  • Like
Reactions: NTMBK

Doug S

Platinum Member
Feb 8, 2020
2,267
3,519
136
I somehow missed this: https://blogs.windows.com/windowsde...and-interoperable-apps-for-windows-11-on-arm/



Should help with getting more applications to ARM64.


I'm skeptical it will make much difference. The better the support is for getting by on x64 code, the less incentive there is to actually port to ARM64.

Microsoft doesn't have the luxury of a forced migration like Apple, they added ARM64 support as a second platform and keep x64. The path of least resistance for developers is to build for x64 only, and wait and see if the market for ARM64 hardware ever gets big enough to matter before considering a port (which may be as easy as a recompile in some cases, but if you offer a port you have to support it, which requires owning ARM hardware and takes time away from x64 where you make all your money)

The funny thing is, the majority of x86 PC consumer buyers could switch to ARM64 PCs and it wouldn't increase the size of the Windows/ARM application market at all. Most consumers aren't performance sensitive, PCs have been more than fast enough for a long time so the performance being less than ordinary Intel PCs doesn't matter. The only application they run is a browser, they don't buy ANY third party applications.

So even if Windows/ARM reached well into the double digits of PC marketshare (higher than Mac) there STILL might not be an incentive for developers to port to ARM64. That is, if almost everyone who switched were those who use their PC exclusively for surfing, shopping, email, video chat and streaming - all done via their browser. Which could easily be the case if the ARM64 PCs are sold as a "cheaper than the Intel offerings not deliberately designed to be terrible like Atom" alternative.

Microsoft has at various times supported MIPS, Sparc, PowerPC, Alpha and Itanium. The only two that saw even moderate success were Alpha and Itanium, and both only on servers. They dropped them all. Trusting Microsoft to not drop ARM support if it meets with a similar lack of success is like trusting Google to not drop support for anything new they announce 2-3 years later.
 

NTMBK

Lifer
Nov 14, 2011
10,239
5,026
136
Microsoft has at various times supported MIPS, Sparc, PowerPC, Alpha and Itanium. The only two that saw even moderate success were Alpha and Itanium, and both only on servers. They dropped them all. Trusting Microsoft to not drop ARM support if it meets with a similar lack of success is like trusting Google to not drop support for anything new they announce 2-3 years later.

The last version of Windows to support Alpha, PowerPC and MIPS was NT 4.0, which came out 25 years ago. Microsoft is basically a completely different company after such a long period. How many members of staff still remain from those days?
 

Tup3x

Senior member
Dec 31, 2016
965
951
136
Wolfenstein: Youngblood running on an NVIDIA GeForce RTX 3060 GPU paired with a MediaTek Kompanio 1200.
Still1-1280x720.jpg
 
  • Like
Reactions: Tlh97 and NTMBK

moinmoin

Diamond Member
Jun 1, 2017
4,952
7,666
136
The YouTube video itself:
MediaTek Kompanio 1200
Also known as MediaTek MT8195 which "is a 6nm octa-core chipset featuring four high-performance ARM Cortex-A78 cores and four power-efficient ARM Cortex-A55 cores" for Chromebooks.
 

aigomorla

CPU, Cases&Cooling Mod PC Gaming Mod Elite Member
Super Moderator
Sep 28, 2005
20,846
3,190
126
Geforces are not the most power efficient things we have computers.

Infact its what makes me turn away from gaming laptops more, as i really would like that 8hour battery life as well as be no thicker then 1.25inches closed.

Infact i am always a advocate of adding TB3 on all gaming portables in general to allow people who really want to game on one, to get a egpu for it instead.

Wolfenstein: Youngblood running on an NVIDIA GeForce RTX 3060 GPU paired with a MediaTek Kompanio 1200.

whats the battery life on it?
This is what makes it or breaks it in portables.
 

aigomorla

CPU, Cases&Cooling Mod PC Gaming Mod Elite Member
Super Moderator
Sep 28, 2005
20,846
3,190
126
That's why an ARM processor is so good- the efficient CPU gives you even more thermal headroom to waste on the GPU! :D

Such an american way to fix things...
Put a bandaid and shove it under the rug and walk away.... maybe no one will see it or notice it before we make profit.
 
  • Like
Reactions: Thibsie

insertcarehere

Senior member
Jan 17, 2013
639
607
136
More impressed that what's basically a rebranded mobile SoC for mid/high-end (not flagship) phones can at least nominally work with fairly high-end gpu hardware. Would be a great thing especially for gaming laptops moving forward given ARM's efficiency.
 

Shivansps

Diamond Member
Sep 11, 2013
3,855
1,518
136
As long as they have at least 4 threads running a on a modern big core they are going to be fine. The problem starts when they start mixing big.low, because the small core is slow and in-order, even the newer one. For example 2 big + 4 low, may be just enoght or completely awful. I would consider 4 big + 4 low to be something like a 4c/8t on x86 terms.