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

Page 2 - 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,236
5,018
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
Windows can always fall back on WARP when it lacks a proper driver (and does if you use the MS basic one), but that is too slow to run anything past the GUI on. Unless you have a massively more powerful system then a Pi.

The problem with that, forget gaming, whiout GPU support doing normal stuff, like web browsing, youtube, already peaks the cpu cores to 100% too often, it is mostly OK, specially with CPU OC past 2Ghz, but thats something that it would not happen with GPU rendering. It is a damn shame because it is almost there to be usable as a actual PC.
I need to try again, now that there is 64-bit emulation on ARM Windows, one thing i always wanted to do is a performance/power comparison to my Z3735D tablet.
 
Last edited:

ThatBuzzkiller

Golden Member
Nov 14, 2014
1,120
260
136
Yeah ive been looking at gaming videos on the Surface Pro X and the Mali GPU is a complete trash, i dont even think it is FL 11.1 there is a shitload of games that dont run, have issues or just crash, not sure if the crashing is due to the GPU or unaligned memory access from the game itself, i saw that problem in two open source games that run on linux when i tryied to run then on the RPI (never tested on ARM64).

The features don't really matter. As long as you're FL 11.1+ capable which is pretty much nearly all of the latest mobile GPU architectures. Those most developers will use now is resource binding tier 2/3 which is useful for doing descriptor indexing ...

D3D in general is just a dumb abstraction for how mobile GPUs work because they don't operate how the API describes them to. Tons of harmful features that will kill performance over there so using anything but Vulkan on tile-based GPUs is a fool's errand. The only other good potential candidate API for Adreno, Mali, & etc would've been Metal API which is exclusive on Apple devices ... (OpenGL is stupid on mobile & so is D3D)
 

Shivansps

Diamond Member
Sep 11, 2013
3,855
1,518
136
Emulation results on the RPI 4 @ 2ghz:

OBnG456.png


uHMDG4R.png


E8lMNEO.png


32 bit emulation is just awful, 64 bits the results are around the MT score of a N3350 and the ST score about half of it.
On native and at the same freq A72 may be close to matching Apollo Lake IPC. But thats not really a lot, specially considering that a notebook would run a ton of stuff behind emulation.

A72 and Apollo Lake are both 2016 stuff, this is old, i think the 4 A76 cores on the 8CX should be about twice as fast at the same freq and thats not counting the small ones.

Anyway this is what the "LOW END" on ARM looks like, and A72 are "big" cores.
 

LightningZ71

Golden Member
Mar 10, 2017
1,627
1,898
136
A72 are OLD big MOBILE FIRST cores. A72 is positively ancient today. The ARM derived chips that are in use in 90% of the cheap little single board computers that are out there are designed to be as cheap as possible, often hamstrung themselves by the nodes they are produced on, the actual number of enabled memory channels they may have, and minimal software support that they actually do have. I'm not trying to make ARM out to be more than it really is, but it definitely deserves a better showing than this look at a least effort/least cost implementation like this one. Low end ARM could be substantially better than the digital performance penalty box that most STB computers really are.
 

Shivansps

Diamond Member
Sep 11, 2013
3,855
1,518
136
Yeah A78 should be A LOT faster than A72, likely around x4. The problem is, if someone, lets say Nvidia, where to make a full lineup of ARM cpus like AMD and Intel do, A78 will be only used for the high end and in premium devices, and it would be in a big.little configuration with... A55? Thats old today, im not sure what replaces A55, and A55 is not going to match A72 perf.

When you start going into the lower end you start having this problem. This is why we only see Windows ARM in premium devices using the best of the best at the moment.

For memory bandwidth i could run AIDA here, but i know it is about 5GB/s on the RPI4. It has LPDDR4-3200 on i belive it is a 32 bit bus. The N3350 has 10GB/s on the ECS LIVA Q.
 

uzzi38

Platinum Member
Oct 16, 2019
2,626
5,927
146
I wonder if they can do it. AFAIK AMD's license mentioned Samsung can only use their GPUs in devices that are not in direct competiton with AMD's own offerings. Laptops to me would seem to breach that.

Then again maybe it's a more intimate partnership rather than pure licencing? If AMD want's to make ARM chips, samsung could offer quite a few IP blocks AMD does not have
I originally thought this as well, but turns out Windows on Exynos devices are OK. The main reason for the clause was for consoles.
 
  • Like
Reactions: Tlh97 and Gideon

Thala

Golden Member
Nov 12, 2014
1,355
653
136
Dont try to move the goalposts here, you didnt mention anything about power efficiency, you did a comparison based on raw perf and i did another comparison based on raw perf using more modern cpus.

How can i possibly move goalpost, when my post was not intended to make competitive comparisons between different CPUs. The intention was to give ballpark numbers for emulation performance. In addition I gave a reference number for my particular build of 7-zip (which is different then the 7-zip version anyone can download as binary) on a known x86 architecture.

In fact this thread is about laptops, thats the market for Renoir-U 15W chips, i dont see whats the problem in bringing Renoir-U perf and there is no rant there either.
I more than welcome ARM CPUs in the laptop market, but you cant forget about pricing and the proper x86 counterparts, the 8CX is a ultra premium SKU that has lower emulation MIPS than the entry-level 4300U and lower native MIPS than the 4500U at 50% TDP, but 7W vs 15W is not that much of a issue for a laptop, it is for ultra-portables, like that Surface.
Offcourse ill like to see a proper comparison.

Nothing wrong with putting a 15W chip into a laptop. But when making, as you claim "fair" ,comparisons you would have to consider the power envelope. Point in case, the highest end premium phone SoC with a TDP of like 3W - would not look as premium anymore when put into a desktop computer - where it would compete with the 5950X.
So a 8CX being the fastest SoC within 7W TDP makes it very premium - that is unless something faster is released in this segment. I do not propose to put a 7W SKU into a laptop, which can probably dissipate 15W, either.
 
  • Like
Reactions: Lodix

Thala

Golden Member
Nov 12, 2014
1,355
653
136
32 bit emulation is just awful, 64 bits the results are around the MT score of a N3350 and the ST score about half of it.
On native and at the same freq A72 may be close to matching Apollo Lake IPC. But thats not really a lot, specially considering that a notebook would run a ton of stuff behind emulation.
A72 and Apollo Lake are both 2016 stuff, this is old, i think the 4 A76 cores on the 8CX should be about twice as fast at the same freq and thats not counting the small ones.
Anyway this is what the "LOW END" on ARM looks like, and A72 are "big" cores.

First of all thanks for the numbers! This is on a 4GByte PI4 i assume?
Regarding the relative performance compared to A76 cores, my Surface Pro X single core score is 406 under x64 emulation. So roughly 4x as fast a the PI - normalized for frequency the Cortex A76 would be roughly 2.7 times as fast as the A72 in the PI4 at iso frequency.

ps. I saw you are on an older Windows build. There could be some differences coming from there, as Microsoft is still improving x64 emulation performance. For reference i am on build 21364.
 

dark zero

Platinum Member
Jun 2, 2015
2,655
138
106
I wonder if they can do it. AFAIK AMD's license mentioned Samsung can only use their GPUs in devices that are not in direct competiton with AMD's own offerings. Laptops to me would seem to breach that.

Then again maybe it's a more intimate partnership rather than pure licencing? If AMD want's to make ARM chips, samsung could offer quite a few IP blocks AMD does not have
Unless... AMD and Samsung joins together in doing not only GPU chips for phones... but also preparing their offerings on the Laptop side.
But still, they knows that their offerings would be on lower tiers instead of higher ones.
 

Shivansps

Diamond Member
Sep 11, 2013
3,855
1,518
136
First of all thanks for the numbers! This is on a 4GByte PI4 i assume?
Regarding the relative performance compared to A76 cores, my Surface Pro X single core score is 406 under x64 emulation. So roughly 4x as fast a the PI - normalized for frequency the Cortex A76 would be roughly 2.7 times as fast as the A72 in the PI4 at iso frequency.

ps. I saw you are on an older Windows build. There could be some differences coming from there, as Microsoft is still improving x64 emulation performance. For reference i am on build 21364.

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".

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.
 

insertcarehere

Senior member
Jan 17, 2013
639
607
136
Yeah A78 should be A LOT faster than A72, likely around x4. The problem is, if someone, lets say Nvidia, where to make a full lineup of ARM cpus like AMD and Intel do, A78 will be only used for the high end and in premium devices, and it would be in a big.little configuration with... A55? Thats old today, im not sure what replaces A55, and A55 is not going to match A72 perf.

When you start going into the lower end you start having this problem. This is why we only see Windows ARM in premium devices using the best of the best at the moment.

I'd be shocked if any ARM laptop comes out with A55s only when even the lowest of the low-end snapdragon SoCs are starting to come with at least A76s, which are themselves already very outdated in terms of their architecture.

The A78 itself isn't even the highest end ARM core available, that would be the X1.
 
Last edited:
  • Like
Reactions: Tlh97

Shivansps

Diamond Member
Sep 11, 2013
3,855
1,518
136
I'd be shocked if any ARM laptop comes out with A55s only when even the lowest of the low-end snapdragon SoCs are starting to come with at least A76s, which are themselves already very outdated in terms of their architecture.

The A78 itself isn't even the highest end ARM core available, that would be the X1.

Im not saying it will come with only A55, that will never work, but what else you are going to use as the little core? They are starting to use some kind of "Big.mid.Little", because they are using X1+A78+A55 on the Snapdragon 888 5G, so A55 is still used today :/

Lets cut to the chase, a Windows device cant have A55 cores, it needs to be X1, A78 and maybe A77/A76 as "little cores" (TODAY). You need to offer skus that are competitive from a Athlon U to a 5800U, you cant just launch a 4x X1 + 4x A78 in the 5800U+ price range.

So a Windows ARM SoC needs to have premium cores in the mainstream market, you need to add A LOT of PCI-E lanes, at least x8 4.0 just for the posibility of a dGPU, x4 for a NVME, and lets say 2 extra for random extra stuff, so at least 14 PCI-E lanes, it needs to have at least 1 sata, a iGPU that at the very least matches Vega 8 in Cezanne for desktop workloads, and it needs to have the same stuff Apple added to the M1 in order to properly run the x86 to arm translation.

So i really want to see someone try, if Nvidia and Mediatek can do it it would be great, but i dont know if that would use less power than a x86 cpu under the same conditions. A ARM phone/tablet SoC will always use less power than a x86 desktop/notebook hybrid that OEMs allow them to run way over their TDP in order to look better in reviews.
 
  • Like
Reactions: scineram

Thala

Golden Member
Nov 12, 2014
1,355
653
136
Lets cut to the chase, a Windows device cant have A55 cores, it needs to be X1, A78 and maybe A77/A76 as "little cores" (TODAY). You need to offer skus that are competitive from a Athlon U to a 5800U, you cant just launch a 4x X1 + 4x A78 in the 5800U+ price range.

You need to be competitive in your power range in the first place. On the other hand, I am very clear here, if anyone is offering ARM SoC in the 15W TDP range, it needs to beat any 15W x86 solution in performance handily, if the price and other features are the same.
There is nothing wrong with releasing an ultra-slim premium tablet with a 7W TDP SoC, which clearly will not convincingly beat the 15W competition with respect to performance - but it will beat the 7W competition easily, just like the Surface Pro X is doing. That having said, i would never buy a tablet with more than 10W TDP - so yes i do want to have maximum performance given the power limit and i am very willing to pay a premium for that.
 
Last edited:

Shivansps

Diamond Member
Sep 11, 2013
3,855
1,518
136
You need to be competitive in your power range in the first place. On the other hand, I am very clear here, if anyone is offering ARM SoC in the 15W TDP range, it needs to beat any 15W x86 solution in performance handily, if the price and other features are the same.
There is nothing wrong with releasing an ultra-slim premium tablet with a 7W TDP SoC, which clearly will not convincingly beat the 15W competition with respect to performance - but it will beat the 7W competition easily, just like the Surface Pro X is doing. That having said, i would never buy a tablet with more than 10W TDP - so yes i do want to have maximum performance given the power limit and i am very willing to pay a premium for that.

But at the end of the day i think we all want another option both for notebooks and for desktops too if it comes to it, and in order for that to happen ARM Windows needs to stop being this niche product here and there, and for that we need more than SoCs designed for tablets and phones.

I think thats possible, but i dont think it will be as low power as most people expect. And price is definately a concern, imagine a 8x X1 SoC, that is not going to be cheap or low power. And it is still lacking SMT/HT vs x86.
 
Last edited:
  • Like
Reactions: Tlh97

insertcarehere

Senior member
Jan 17, 2013
639
607
136
But at the end of the day i think we all want another option both for notebooks and for desktops too if it comes to it, and in order for that to happen ARM Windows needs to stop being this niche product here and there, and for that we need more than SoCs designed for tablets and phones.

I think thats possible, but i dont think it will be as low power as most people expect. And price is definately a concern, imagine a 8x X1 SoC, that is not going to be cheap or low power. And it is still lacking SMT/HT vs x86.

Why prevents an 8x X1 SoC (or some X1 + A78) from being cheap or low power?

ARM quotes the Neoverse V1 (basically Cortex X1 w/SVE 256bit) as being 1.7x the core area (iso-process) of Neoverse N1, which itself is supposedly ~1.4mm^2 w/1MB L2 on TSMC 7nm. So that would leave projections the X1 at <= 2.4mm^2/core.

Zen 3 cores have been measured at 4.04mm^2 w/ 512kb L2, on the same process, yet AMD is just fine selling 8c APUs with reasonable prices.

So, apples to apples, the ARM SoC will likely be smaller, and given ARM's mobile roots, should excel in low-power situations (like smartphones, Firestorm is a huge core and works just fine in iPhones). I don't see why ARM implementations can't be very competitive hardware wise with x86 contemporaries.
 

Thala

Golden Member
Nov 12, 2014
1,355
653
136
But at the end of the day i think we all want another option both for notebooks and for desktops too if it comes to it, and in order for that to happen ARM Windows needs to stop being this niche product here and there, and for that we need more than SoCs designed for tablets and phones.

Nothing wrong with that. I would like to see higher power ARM SoCs as well - just not for a tablet :) Apple M1 is a god starting point, when talking about higher power ARM SoCs.

I think thats possible, but i dont think it will be as low power as most people expect. And price is definately a concern, imagine a 8x X1 SoC, that is not going to be cheap or low power. And it is still lacking SMT/HT vs x86.

No worries here, the ARMs are so much more efficient, that they should easily beat any x86 design at iso power.
 
Last edited:

Thala

Golden Member
Nov 12, 2014
1,355
653
136
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".

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.

I am not sure, that you know what you are talking about. If alignment checks are disabled by the OS, ARMv8 CPUs happily access unaligned memory addresses - as is the case on all the Windows ARM machines (including WSL2 Linux) i have. No awful news for Microsoft either.
 
Last edited:
  • Like
Reactions: Nothingness

Shivansps

Diamond Member
Sep 11, 2013
3,855
1,518
136
I am not sure, that you know what you are talking about. If alignment checks are disabled by the OS, ARMv8 CPUs happily access unaligned memory addresses - as is the case on all the Windows ARM machines (including WSL2 Linux) i have. No awful news for Microsoft either.

Well, tell that to the bus errors that i was getting (even with OS alignment fixing on) and i had to go and expend a week undestanding the process and fixing the code. And both RPI 3 and 4 are ARMv8... The changes i had to do are on my github account in case you want to check. So i dont know what to tell you, that happened.
 
Last edited:

Thala

Golden Member
Nov 12, 2014
1,355
653
136
Well, tell that to the bus errors that i was getting (even with OS alignment fixing on) and i had to go and expend a week undestanding the process and fixing the code. And both RPI 3 and 4 are ARMv8... The changes i had to do are on my github account in case you want to check. So i dont know what to tell you, that happened.

If you switching alignment checks off in the CPU for EL0, then you will not get alignment errors - i am not talking about some OS level fixing but switching it off in HW. Did you check in the kernel, that HW alignment checks were switched off in SCTLR_EL1 for the CPUs?
 
Last edited:

Nothingness

Platinum Member
Jul 3, 2013
2,408
739
136
If you switching alignment checks off in the CPU for EL0, then you will not get alignment errors - i am not talking about some OS level fixing but switching it off in HW. Did you check in the kernel, that HW alignment checks were switched off in SCTLR_EL1 for the CPUs?
Not sure the discussion led anywhere last time we discussed it: https://forums.anandtech.com/threads/arm-apple-high-end-cpu-intel-replacement.2571738/post-40007359
I provided code and evidence of mis alignment support. But no code was provided in answer to show what instruction led to the fault.
 

Shivansps

Diamond Member
Sep 11, 2013
3,855
1,518
136
If you switching alignment checks off in the CPU for EL0, then you will not get alignment errors - i am not talking about some OS level fixing but switching it off in HW. Did you check in the kernel, that HW alignment checks were switched off in SCTLR_EL1 for the CPUs?

I had enabled unaligned support both on boot asm code and in /proc/cpu/alignment, and i was still getting a SIGBUS, no idea why. But, this was under armhf, since there was no 64 bit kernel avalible at the time, i never actually tested it under AArch64. ARM64 makes any difference here?

Not sure the discussion led anywhere last time we discussed it: https://forums.anandtech.com/threads/arm-apple-high-end-cpu-intel-replacement.2571738/post-40007359
I provided code and evidence of mis alignment support. But no code was provided in answer to show what instruction led to the fault.

Because i was getting a SIGBUS trying a game on a RPI, since ive been playing this game since i was a kid and it is open source i took it upon myself to find the cause and fix it, i did just that and i moved on.

But if you insist, this is one of the functions were the game was crashing.

C++:
bool mc_check_sldc(int offset)
{
    if (offset > Mc_pm->sldc_size-5) //no way is this big enough
        return false;
    char *type_p = (char *)(Mc_pm->shield_collision_tree+offset);
 
    // split and polygons
    vec3d *minbox_p = (vec3d*)(Mc_pm->shield_collision_tree+offset+5);
    vec3d *maxbox_p = (vec3d*)(Mc_pm->shield_collision_tree+offset+17);

    // split
    unsigned int *front_offset_p = (unsigned int*)(Mc_pm->shield_collision_tree+offset+29);
    unsigned int *back_offset_p = (unsigned int*)(Mc_pm->shield_collision_tree+offset+33);

    // polygons
    unsigned int *num_polygons_p = (unsigned int*)(Mc_pm->shield_collision_tree+offset+29);

    unsigned int *shld_polys = (unsigned int*)(Mc_pm->shield_collision_tree+offset+33);



    // see if it fits inside our bbox
    if (!mc_ray_boundingbox( minbox_p, maxbox_p, &Mc_p0, &Mc_direction, NULL ))    {
        return false;
    }

    if (*type_p == 0) // SPLIT
    {
            return mc_check_sldc(offset+*front_offset_p) || mc_check_sldc(offset+*back_offset_p);
    }
    else
    {
        // poly list
        shield_tri    * tri;
        for (unsigned int i = 0; i < *num_polygons_p; i++)
        {
            tri = &Mc_pm->shield.tris[shld_polys[i]];
                     
            mc_shield_check_common(tri);

        } // for (unsigned int i = 0; i < leaf->num_polygons; i++)
    }

    // shouldn't be reached
    return false;
}

But not sure were you are trying to get to, i was not seeing illusions, that was happening.
 
Last edited:

Thala

Golden Member
Nov 12, 2014
1,355
653
136
I had enabled unaligned support both on boot asm code and in /proc/cpu/alignment, and i was still getting a SIGBUS, no idea why. But, this was under armhf, since there was no 64 bit kernel avalible at the time, i never actually tested it under AArch64. ARM64 makes any difference here?



Because i was getting a SIGBUS trying a game on a RPI, since ive been playing this game since i was a kid and it is open source i took it upon myself to find the cause and fix it, i did just that and i moved on.

But if you insist, this is one of the functions were the game was crashing.

C++:
bool mc_check_sldc(int offset)
{
    if (offset > Mc_pm->sldc_size-5) //no way is this big enough
        return false;
    char *type_p = (char *)(Mc_pm->shield_collision_tree+offset);

    // split and polygons
    vec3d *minbox_p = (vec3d*)(Mc_pm->shield_collision_tree+offset+5);
    vec3d *maxbox_p = (vec3d*)(Mc_pm->shield_collision_tree+offset+17);

    // split
    unsigned int *front_offset_p = (unsigned int*)(Mc_pm->shield_collision_tree+offset+29);
    unsigned int *back_offset_p = (unsigned int*)(Mc_pm->shield_collision_tree+offset+33);

    // polygons
    unsigned int *num_polygons_p = (unsigned int*)(Mc_pm->shield_collision_tree+offset+29);

    unsigned int *shld_polys = (unsigned int*)(Mc_pm->shield_collision_tree+offset+33);



    // see if it fits inside our bbox
    if (!mc_ray_boundingbox( minbox_p, maxbox_p, &Mc_p0, &Mc_direction, NULL ))    {
        return false;
    }

    if (*type_p == 0) // SPLIT
    {
            return mc_check_sldc(offset+*front_offset_p) || mc_check_sldc(offset+*back_offset_p);
    }
    else
    {
        // poly list
        shield_tri    * tri;
        for (unsigned int i = 0; i < *num_polygons_p; i++)
        {
            tri = &Mc_pm->shield.tris[shld_polys[i]];
                
            mc_shield_check_common(tri);

        } // for (unsigned int i = 0; i < leaf->num_polygons; i++)
    }

    // shouldn't be reached
    return false;
}

But not sure were you are trying to get to, i was not seeing illusions, that was happening.

I just compiled FS2_open from git master branch for both Windows x64 and Windows ARM64 with Visual Studio 2019 - and both variants (first variant under x64 emulation and the second native) are running without any crashes. In short, i cannot verify your alignment issue at all - how could I even - given that unaligned access is supported with ARMv8?
 
Last edited:

Shivansps

Diamond Member
Sep 11, 2013
3,855
1,518
136
I just compiled FS2_open from git master branch for both Windows x64 and Windows ARM64 with Visual Studio 2019 - and both variants (first variant under x64 emulation and the second native) are running without any crashes. In short, i cannot verify your alignment issue at all - how could I even - given that unaligned access is supported with ARMv8?

Running what exactly? This is problem with using modified game model data, the original game data always worked. I even have a video tutorial of how to run it on the pi :/
You are so focused in trying to prove something that you didnt even bothered to ask the conditions of when it happens. And thats not even what i asked you, i asked if you had problems with crashing apps, because i saw that LTT had those and i saw it too, i just mentioned aligment as a possibility, you are just blinded.

But if it works that good, i cant try whiout gpu drivers.
 
Last edited:

Thala

Golden Member
Nov 12, 2014
1,355
653
136
You are so focused in trying to prove something that you didnt even bothered to ask the conditions of when it happens.

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.

And thats not even what i asked you, i asked if you had problems with crashing apps, because i saw that LTT had those and i saw it too...

I almost always run native ARM64 SW - except my DAW system (Mixcraft 9 Studio) and a few games. In order to answer your particular question, i did test Luxmark and Handbrake and they appear to run just fine.
 

beginner99

Diamond Member
Jun 2, 2009
5,210
1,580
136
Lets cut to the chase, a Windows device cant have A55 cores

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.