GPD Win (x86 Computer / Palmtop)

[ZXDunny]

I have to say, I'm tempted. I mean, I love my Pandora, warts and all, but it's so bloody frustrating spending hours building my projects for it (even though I've got perfectly working Linux ports) and having them fail in creative ways because of the ARM CPU, where with the WIN they'd just... work.

 

[Exophase]

I have to say, I'm tempted. I mean, I love my Pandora, warts and all, but it's so bloody frustrating spending hours building my projects for it (even though I've got perfectly working Linux ports) and having them fail in creative ways because of the ARM CPU, where with the WIN they'd just... work.

In what creative ways has your software failed because of ARM?

I've been hit by a differing behavior of variable shift operations in C but that's pretty esoteric.

 

[vcoleiro1]

Well , we are within the final 9 hours folks. Final call if you are interested.

Currently 1706 backers and $524K raised

 

[ZXDunny]

In what creative ways has your software failed because of ARM?

I've been hit by a differing behavior of variable shift operations in C but that's pretty esoteric.

The one that springs to mind immediately is the difference in size between extended precision and double precision - that's mostly the fault of the compiler though, declaring as float and getting 10 bytes on x86 and 8 bytes on ARM was a real stumper for a while (and before anyone says you shouldn't be relying on the size of a data item if you're porting - I was saving/loading blocks of memory as raw dumps, and then getting errors when loading them in on ARM). I got around it, and thanks to that I can now port to x64 which would have had the same issues...

Others were compiler issues, such as the x86 version having no trouble casting the value held in a float to a pointer (because only numeric value in a record was a float and I couldn't be arsed to go through several thousand lines changing it!) which the ARM version of the compiler balked at. Not being able to address doubles via a pointer which was unaligned. That was a head-scratcher too for a while.

Then there was the really bizarre issues with SDL - things like SDL_UpdateRects() under x86 behaving as expected, but not on the Pandora (it updates the entire screen if it doesn't crash instead - seems to be about 50/50 and if I could just get a pointer to the screen surface I'd drop SDL like a stone).

And the list goes on... And of course, when it comes to performance on the Pandora sometimes I wonder why I bother as my interpreter in particular is designed around a multi-core CPU which is almost certainly going to suffer speed-wise on the Pandora, but absolutely flies on a Pi (first gen).

I'm aware that most of my problems are of my own making, but even so - we all have to start learning how to make portable code somewhere and this is mine.

D.

 

[WizardStan]

getting 10 bytes on x86 and 8 bytes on ARM

WUT? That doesn't make sense to me. I can see it being the other way around (8 bytes on ARM but only 6 on x86), ARM absolutely needing to be 32bit aligned and x86 not so much, but I can't think of why x86 would get padded out where ARM doesn't. Did you ever figure out what was actually going on, or did you just work around the problem?

 

[slaeshjag]

x86 FPU is 80-bit.

 

[Exophase]

WUT? That doesn't make sense to me. I can see it being the other way around (8 bytes on ARM but only 6 on x86), ARM absolutely needing to be 32bit aligned and x86 not so much, but I can't think of why x86 would get padded out where ARM doesn't. Did you ever figure out what was actually going on, or did you just work around the problem?

It is 8 bytes on ARM and 10 bytes on x86 like Dunny said. x86's 80-bit long double format is fairly unique, especially today. It should be avoided unless you really need it, the performance isn't very good either.

 

[slaeshjag]

To my knowledge, the only microprocessors using 80-bit long doubles as interal representation in the FPU is x86/x87 and 68k+68881/68882.

 

[WizardStan]

OH! Double. He said float. World of difference, I was so confused. I get it now.

 

[vcoleiro1]

So the GPD WIN Indiegogo campaign has just ended.

It finished up with 1753 backers and raised $538,847

 

[Chip]

Decided against backing it. It's still very interesting, and I may pick one up when they're available through regular channels, depending on reviews. In the end, I wasn't convinced their heat solution would be sufficient, or that their battery life claims were realistic. It wasn't worth $300 (or the effort of trying to convince to my wife why I needed to spend $300) when the final quality/usability is still unknown.

 

[Faust]

I can't convince myself to buy one instead of the Pyra, mainly because of the durability, the keyboard and the gamepad. I would love to be able to play Windows games on this kind of handled, but I'm planning to play game that requires keyboard control.

Because on Pyra the gamepad has keyboard function, it's alot better to play games made for keyboard and mouse, because you can change biding without playing with third party software (diablo, unreal tournament, might and magic 7, etc...)

The layout on the GPD is a mess, I don't want any compromise.

 

[fusion_power]

I was eyeing the CAT S60 with the built in FLIR Thermal Imaging camera. It may be my next smartphone.

I've seen that phone, not bad but of course not really cheap due the thermal camera.

If this is legit a thing, then maybe one day we can have Core M or even those fancy U processors in our clamshell handhelds (think of the graphical power of the HD/Iris iGPUs)...

Of course it's legit, various pages reported about this new colling solution and it really seems to be enough to cool down a mobile Skylake.

 

[Chip]

Of course it's legit, various pages reported about this new colling solution and it really seems to be enough to cool down a mobile Skylake.

Just because you can cool it, doesn't mean you can power it. The most conservative core M chip still sucks down more than twice the power of a cherry trail atom. 4.5W is impressively low for a laptop chip, but you're never going to be able to keep the beast fed in something pocket-sized. You'd be very lucky to get 2hrs out of the battery.

Barring some miraculous new battery technology, power concerns are going to limit handheld SoCs to around 2W for the foreseeable future. You can engineer around cooling issues, but you can't magic your way above the energy density limitations of currently-available battery chemistry.

 

[AJLond1]

Just because you can cool it, doesn't mean you can power it. The most conservative core M chip still sucks down more than twice the power of a cherry trail atom. 4.5W is impressively low for a laptop chip, but you're never going to be able to keep the beast fed in something pocket-sized. You'd be very lucky to get 2hrs out of the battery.

True, though I wouldn't mind carrying a clip-on battery pack or a using charging dock add-on (which could make use of the Core M pcie lanes for usb, ethernet, or a separate low-power graphics chip that's only usable when plugged into a wall). That said, battery life in an issue that unfortunately plagues all mobile devices, yet no battery oem has fixed it yet (or at least has tried and publicly shared it)...

 

[Chip]

battery life in an issue that unfortunately plagues all mobile devices, yet no battery oem has fixed it yet (or at least has tried and publicly shared it)...

Whoever develops a battery chemistry that substantially beats LiPoly on on energy density (volume/weight), longevity, and cost will be a billionaire within a couple years. There are dozens of big companies and institutions dumping tens of millions into the problem every year, and they've been at it for over a decade. From portable electronics to electric/hybrid cars to home power storage, lithium-based batteries are a $40bn/year industry, and it's likely to double in size in less than a decade.

Believe me, if there was a better battery out there, it wouldn't be a secret.

 

[AJLond1]

Believe me, if there was a better battery out there, it wouldn't be a secret.

And it's likely coming sooner than expected...
http://phys.org/news/2016-03-chinese-battery-technology.html

TL;DR: Chinese researchers developed a new type of battery that allegedly is greener, low-cost, and has a higher electric density, made with Aluminum and Graphite...

Quote: "Compared with conventional LIBs, this battery (AGDIB) shows an obvious advantage in production cost (~ 50 percent lower), specific density (~1.3-2.0 times), and energy density (~1.6-2.8 times)"

 

[fusion_power]

Just because you can cool it, doesn't mean you can power it. The most conservative core M chip still sucks down more than twice the power of a cherry trail atom. 4.5W is impressively low for a laptop chip, but you're never going to be able to keep the beast fed in something pocket-sized. You'd be very lucky to get 2hrs out of the battery.

Barring some miraculous new battery technology, power concerns are going to limit handheld SoCs to around 2W for the foreseeable future. You can engineer around cooling issues, but you can't magic your way above the energy density limitations of currently-available battery chemistry.

I only spoke about the cooling solution, not about having an mobile Core CPU into an handheld because that's just ridiculus. I can imagine a smaller cherry Trail Atom with that cooling solution in an handheld. I just meant that if it can cool a Skylake(U), this cooling solution should be able to cool an smaller Atom without any trouble.

 

[AJLond1]

I only spoke about the cooling solution, not about having an mobile Core CPU into an handheld because that's just ridiculus.

Never say never...

 

[levi]

Quote: "Compared with conventional LIBs, this battery (AGDIB) shows an obvious advantage in production cost (~ 50 percent lower), specific density (~1.3-2.0 times), and energy density (~1.6-2.8 times)"

Reminds me about the hype about Lithium-Sulphur batteries, but I'm still waiting for those to come to market.