Able to upgrade not just the speed but manufacturer of CPU?


I am pretty sure the x86 CPU is more power efficient, however, based on the experience of the prototypes, Windows totally kills that advantage by needing a lot more CPU power all the time compared to Linux.
Even when not running any games but just doing simple tasks (LibreOffice, etc.) the GPD Win gets warmer than the Pyra.
And before I disabled all the unneeded Windows Crap, it even got warm when just lying around (and predicted a battery time of 5 hours).
 
I am pretty sure the x86 CPU is more power efficient, however, based on the experience of the prototypes, Windows totally kills that advantage by needing a lot more CPU power all the time compared to Linux.
Even when not running any games but just doing simple tasks (LibreOffice, etc.) the GPD Win gets warmer than the Pyra.
And before I disabled all the unneeded Windows Crap, it even got warm when just lying around (and predicted a battery time of 5 hours).

X86 does not dictate Windows. Regardless of the hypothetical future CPU architecture, stick with Linux as the supported OS.
 
True, but the BayTrails are not known to work well with Linux.

That smells of perpetuated myth.

Linux incompatibilities has a lot more to do with UEFI locks and other component selection than it does the actual SoC.

Bay Trail stick with factory pre-loaded Ubuntu:
http://www.cnx-software.com/2016/04/08/mele-pcg02u-intel-bay-trail-tv-stick-runs-ubuntu-costs-59/

Linux build for Cherry Trail Intel Compute Sticks:
http://liliputing.com/2016/10/ubunt...-builds-bay-trail-cherry-trail-computers.html

Frankly I don't see how it is any worse than setting up Linux on an ARM SoC based system - might even be a bit easier as the Bay & Cherry trail SoC is itself is rolled into the main kernels now. Wireless and audio component selection (and thus drivers) seem to be the main headache in doing it.

When Liliputing reviewed the Gole1, they simply put in an Ubuntu USB stick and it simply booted (sans network and sound).
http://liliputing.com/2016/07/gole1-mini-pc-review-blurring-lines-tablets-desktop-pcs.html
Kernel support for the SoC itself is pretty sound.

I'm not advocating for a new SoC board inside of the next 2-3 years. Get the Pyra out, get it sold, make some money - then consider an upgrade SoC board. I thought that was the plan all along after all.

When making that consideration sometime in 2018-2019, consider all possibilities available at the time. I have no idea what will be available or workable then.
 
True, but the BayTrails are not known to work well with Linux.
I have Linux running just fine on a BayTrail computer. I'm using it as a small headless server but it was at one time being used for a basic internet box for my niece. I did test Xcom on it and other than poor FPS ran fine.
Admittedly I had to manually set it to BIOS legacy boot as it wouldn't boot Linux in UEFI mode.
 
Is it the latest version of the BayTrail?
I didn't have any issues with UEFI on the GPD Win prototype, but it even crashed when I just tried to use xrandr to rotate the display.

And no battery or charging information either, no way to change the brightness of the screen.
 
Is it the latest version of the BayTrail?
I didn't have any issues with UEFI on the GPD Win prototype, but it even crashed when I just tried to use xrandr to rotate the display.

And no battery or charging information either, no way to change the brightness of the screen.

That seems to be a false expectation. The manufacturer of the GPD Win was not particular in selecting components compatible with Linux - that was not their objective. If people are going to run Linux on that specialized hardware, some localization should be expected.

Did battery or battery charging information or screen rotation and everything else work out of the box for the Pyra with default drivers and settings from the Debian ARM repository? I would not expect it to.

The same type of work would need to be done regardless of the SoC used.
 
I would expect that future x86 processors would be from the Pentium or Celeron lines (or other new line that does not exist now) since Atom is now at end-of-line. It does not make sense to speculate about using a z8700 or z8750 processor since they will be "old" and probably obsolete options by the time an x86 option will be realistically considered for a Pyra update in a number of years yet to come.

Regardless of x86 or ARM based, there will undoubtedly need to be driver adjustments or other software tweaks to make it work.
 
Did battery or battery charging information or screen rotation and everything else work out of the box for the Pyra with default drivers and settings from the Debian ARM repository? I would not expect it to.

Well, at least screen rotation should work without issues on any Intel Baytrail with any Linux, as it has a standard Intel GPU included where drivers exist.

I'm not sure how battery / charging stuff etc. works on x86 PCs, but I thought they have a BIOS which provides all those details as standard API via something like ACPI?
So if properly done, it should work out of the box.

The same type of work would need to be done regardless of the SoC used.

Not if the whole system uses standard APIs like ACPI or similar (is that still used?)
But still, rotation should really work as it uses the standard Intel graphics driver.

Also, audio also doesn't work on current BayTrails, AFAIK.
There isn't an existing driver yet, but without many details about it, no one could code one.
 
It's an older j2900 computer (Foxconn iBT-29) I bought in 2014 and the UEFI issues more likely have more to do with my use of Mageia Linux (witch didn't officially support it at the time).
I never needed to rotate the screen so never tried and it's a VHS sized desktop so no battery info and screen brightness is handled by the screen.
Audio worked fine but I wasn't using HDMI audio.
 
Well, at least screen rotation should work without issues on any Intel Baytrail with any Linux, as it has a standard Intel GPU included where drivers exist.

I'm not sure how battery / charging stuff etc. works on x86 PCs, but I thought they have a BIOS which provides all those details as standard API via something like ACPI?
So if properly done, it should work out of the box.



Not if the whole system uses standard APIs like ACPI or similar (is that still used?)
But still, rotation should really work as it uses the standard Intel graphics driver.

Also, audio also doesn't work on current BayTrails, AFAIK.
There isn't an existing driver yet, but without many details about it, no one could code one.

You keep referencing Bay Trail, but isn't the GPD Win Cherry Trail? Not that there should be that much difference.

Work has been done on the audio issues. Several of those drivers exist but have not been pushed up to the kernel yet - and are dependent on what components were put in the individual device.

The "Mele" branded Ubuntu Bay Trail compute stick that I have does HDMI audio fine.

See above:

I would be interested to know if that build is any 'better' on the GPD Win even though it wasn't designed for it specifically. It might be a solid improvement over stock distributions though.

Expecting -any- Linux build to run on -any- highly customized hardware with Bay/Cherry Trail in it regardless of what the supporting hardware is might be asking too much. That would be akin to expecting the Pyra OS to run out of the box on my phone since they're both ARM. However, there are several examples where the driver issues have been overcome to result in pretty solid working products utilizing Ubuntu (not my favorite - but at least it's based on Debian).

Again, I'm not arguing to push for a Cherry Trail Pyra CPU board. That boat has sailed. I'm just trying to squash a few myths regarding Bay/Cherry Trail and Linux. It has come a long ways over the last 2 years to the point where commercial products with fully operational hardware/driver support have shipped with Linux installed. The necessary drivers exist, but are dependent on the 'right' supporting hardware and are not all upstream and into the kernel (they might not ever be). It is highly device dependent based on whatever the manufacturer used for networking and audio.

An example would be USB WiFi dongles for the Pandora. Some worked, some needed additional drivers to work, some simply won't work because there are no Linux drivers for the chipset. The same WiFi chipset roulette applies to all of the Bay/Cherry Trail devices. Some might work, most need drivers, some will never work.

I doubt someone could buy a commercial Windows 10 package and simply install it 'out of the box' on the GPD Win or even the Microsoft Surface without making a round trip for additional device specific drivers.
 
Well, I think one of the problems is that people expect some things.
On an x86 Intel system, many expect that it behaves exactly like a desktop PC and therefore expect a normal Linux to run.

ARM always had to be customized, so it's different here.

Honestly, I also thought until a while ago that Intels mobile SoC is mostly compatible to the normal desktop system and didn't expect such issues.
 
Honestly, I also thought until a while ago that Intels mobile SoC is mostly compatible to the normal desktop system
But SoC itself is MOSTLY compatible with Intel's desktop system! It's when you want to do things that usually aren't needed in the desktop world that the big problems show up and actually require special drivers for Windows too.
 
Well, I think one of the problems is that people expect some things.
On an x86 Intel system, many expect that it behaves exactly like a desktop PC and therefore expect a normal Linux to run.

ARM always had to be customized, so it's different here.

Honestly, I also thought until a while ago that Intels mobile SoC is mostly compatible to the normal desktop system and didn't expect such issues.
The SoC is. It is the rest of the crap that seem to cause issues.
 
Rotation and audio are both part of the Included GPU on the SoC and should work with the intel graphics drivers, right?
 
everything is possible and that would be a cool idea... its the time and cost and finding someone who can that is the problem.
 
Rotation and audio are both part of the Included GPU on the SoC and should work with the intel graphics drivers, right?

Are you sure that you got the most up to date Intel graphics drivers installed? The successes that have been shown so far didn't just pop in a live CD and get instant success. I wonder if it would work better with the Ubuntu build noted here:
http://liliputing.com/2016/10/ubunt...-builds-bay-trail-cherry-trail-computers.html
I haven't had a need to force rotation on the Mele Bay Trail Ubuntu compute stick though and cannot state whether it works or doesn't.

I thought the whole thing was moot anyway, unless you're stating that a stable Debian on a Cherry Trail SoC would mean that you would consider building the SoC board - then it might be relevant. At this stage it might not be a great idea though. Confined to the Pyra's thermal envelope a Cherry Trail SoC would have to be clocked down - a lot. It would get compared 'head to head' with the GPD Win and it's active (fan) cooling on game FPS benchmarks - which isn't going to turn out well. If you build an X86 Linux Pyra would I buy one? In a heartbeat. But then, I also bought the ARM Pyra and am looking forward to getting it some day.

Produce the device that you're working on. It wins Vs the GPD based on overall capabilities - particularly in the 'other than games' categories. Frankly I think that the Pyra will be better in every way but one - X86 games. There are people that see that as their primary purpose in a device. There are others who want the true 'everything in a pocket' device that you're working on.

On the up side, there seems to be a bit of a renaissance in handheld gaming. More devices, more people interested, etc.
 
Back
Top