I've done a second pass with a lower threshold now, but I don't think it will get much better without splitting posts sentence-by-sentence. Which would be silly.
GPD Win (x86 Computer / Palmtop)
- Thread starter Xcl4m4t10n
- Start date
quartercast
Well-Known Member
- Joined
- Feb 13, 2007
- Messages
- 1,551
hmmm.. can you copy instead of split (is that even done on forums?)
Now ED's replies refer to two posts in the other thread.
Now ED's replies refer to two posts in the other thread.
Hmm, looking at the threads on Dingoonity, while the GPD devices quality seems a bit better than the JXD ones, there still seem to be many issues.
Dying devices, light bleed, DPad issues...
It seems no one anymore is working on custom roms and the official one seems to have a lot of bloat in it.
Let's see how this will work out
Dying devices, light bleed, DPad issues...
It seems no one anymore is working on custom roms and the official one seems to have a lot of bloat in it.
Let's see how this will work out
levi
Still fresh, damnit!
Theoretically, at least, if this comes out as an x86 device with a non-broken BIOS, we can install our own linuxes on it with however much bloatware we desire.
That's less true with the Android ARM devices they're selling currently, but perhaps it's still possible to install a cleaner version with only the google-provided spyware in it. And then buy the emulators based on the free ones we use on the Dingoo or Pandora
That's less true with the Android ARM devices they're selling currently, but perhaps it's still possible to install a cleaner version with only the google-provided spyware in it. And then buy the emulators based on the free ones we use on the Dingoo or Pandora
Yes, it depends on the Bios... AFAIK, a manufacturer builds his own BIOS around the CherryTrail (which is the reason we didn't consider it further for the Pyra)
If GPD is licensing a standard BIOS (I don't think they'll create their own), it could very well be that nothing can be installed easily (as this is the case with most devices these days).
If GPD is licensing a standard BIOS (I don't think they'll create their own), it could very well be that nothing can be installed easily (as this is the case with most devices these days).
levi
Still fresh, damnit!
Really? So it won't be a standard UEFI BIOS, or an old style one that reads the MBR that reads the VBR that boots up whatever you've chosen to install? I've not bought a new x86 box for a number of years now, so I don't really have a good feeling for the current state of the art.
AFAIK, the mobile SoCs don't use a standard BIOS that normal PCs use. They're meant for mobile usage, so you usually can't boot from any other media.
But that's just AFAIK, it might be different.
Has anyone who got a CherryTrail tablet ever tried to boot from something else?
EDIT:
Okay, so apparently, a Surface 3 can boot from USB:
https://www.microsoft.com/surface/e...urface-from-usb-recovery-device?os=windows-10
SNESFAN
Retro game fanatic
I don't have a cherry trail, but a bay trail and while things like secure boot are enabled by default, it only takes about 30 seconds to go in there and turn that option off and turn this like boot to USB on.
The UEFI did or does make booting up your own OS a little bit more difficult, especially if it doesn't have legacy bios boot options, I remember having to modify Ubuntu quite a bit before it would boot, and even more to get it to load from internal storage. Not quite as strait forward as a PC install.
And this was from a Chinese Windows tab.
The problem I had, that more than likely won't be a problem anymore was the 32 bit UEFI with the 64 bit processor, I have read/heard that they have moved to a proper 64 bit UEFI so 64 bit OS can be used.
https://help.ubuntu.com/community/UEFIBooting
The UEFI did or does make booting up your own OS a little bit more difficult, especially if it doesn't have legacy bios boot options, I remember having to modify Ubuntu quite a bit before it would boot, and even more to get it to load from internal storage. Not quite as strait forward as a PC install.
And this was from a Chinese Windows tab.
The problem I had, that more than likely won't be a problem anymore was the 32 bit UEFI with the 64 bit processor, I have read/heard that they have moved to a proper 64 bit UEFI so 64 bit OS can be used.
https://help.ubuntu.com/community/UEFIBooting
Last edited:
Thanks for the info, then it should work installing a new OS at least.
SNESFAN
Retro game fanatic
I would put money, and lots of it, on it being UEFI if they are using bay or cherry trail chipset and Windows 8/10. My question, if I had one, was if the UEFI is 32 or 64 bit, as it makes a significant difference of what is possible as far as your OS options.
I have not played with "UEFI mode" Ubuntu, as it didn't work for me in v13, but given the way UEFI works, your boot loader binary must be UEFI compatible, i.e. Named a specific file name in a specific directory on the partition your booting to. Be it grub, or Windows bootloader or whatever. (It's hidden in Windows, but exists)
I was exploring the possibilities of installing a custom bootloader directly into the UEFI, (it's almost like a miniature OS with its own language) and I'm sure something like that is possible, it's offered on some Windows platforms. The default appears to always be an option for recovery reasons, is to load the secondary bootloader through an external (to the UEFI) source.
Again, I don't know what all is involved in UEFI mode of Ubuntu, but from lite reading, it seems to just install grub UEFI compliant binary to the expected directory.
Sent from my iPad using Tapatalk
I have not played with "UEFI mode" Ubuntu, as it didn't work for me in v13, but given the way UEFI works, your boot loader binary must be UEFI compatible, i.e. Named a specific file name in a specific directory on the partition your booting to. Be it grub, or Windows bootloader or whatever. (It's hidden in Windows, but exists)
I was exploring the possibilities of installing a custom bootloader directly into the UEFI, (it's almost like a miniature OS with its own language) and I'm sure something like that is possible, it's offered on some Windows platforms. The default appears to always be an option for recovery reasons, is to load the secondary bootloader through an external (to the UEFI) source.
Again, I don't know what all is involved in UEFI mode of Ubuntu, but from lite reading, it seems to just install grub UEFI compliant binary to the expected directory.
Sent from my iPad using Tapatalk
Last edited:
levi
Still fresh, damnit!
I guess, with most Linuxes recently been busy porting their OSen to ARM and other chips, targetting a subset of a single platform for a fancy feature isn't a high priority, once they can get their existing bootloader to load on the platform.
SNESFAN
Retro game fanatic
I agree, having UEFI mode would in theory make it more compatible with a much wider range of devices than to create individual loaders apps for a specific UEFI's.
The benefit of having that feature is probably specifically for devices with a dedicated support group so it's possible to create it to reduce or streamline booting. Might be other reasons I'm missing maybe? I'm not sure how much time you'd save on boot, but it surely is a non-zero amount. Plus from your random mild tinkerer's perspective, it just looks cool that your bios would have an option made specifically for your chosen OS.
One thing that crossed my mind would be to program a hypervisor in UEFI so you could load virtual machines. Or maybe, and here's a cool one, have a recovery partition so you can slave your device though USB and reflash the OS image as a package instead of goring though the whole install process native on the device, similar to android/ios/winmo smartphones and tablets do it.
The benefit of having that feature is probably specifically for devices with a dedicated support group so it's possible to create it to reduce or streamline booting. Might be other reasons I'm missing maybe? I'm not sure how much time you'd save on boot, but it surely is a non-zero amount. Plus from your random mild tinkerer's perspective, it just looks cool that your bios would have an option made specifically for your chosen OS.
One thing that crossed my mind would be to program a hypervisor in UEFI so you could load virtual machines. Or maybe, and here's a cool one, have a recovery partition so you can slave your device though USB and reflash the OS image as a package instead of goring though the whole install process native on the device, similar to android/ios/winmo smartphones and tablets do it.
thatgui
Advanced Member
- Joined
- Apr 2, 2009
- Messages
- 3,048
A liitle late, but what the heck:
The only problem that may have been a thing in the past is probably already gone by now: driver support. As Windows 10 will be the last "versioned" Windows, thus everything new will just be delivered via updates, people can have a device now for a long time without worrying too much about wether there will be driver support for their hardware in the next version of Windows.
I wonder whether they have got their hands on a "real" landscape display or if they let Windows do all the rotation work.
Well I guess that's one of the rare occasions where the lack of source code is actually some awkward kind of benefit (only in combination with the fact that most commercial games were/are developed for Windows, of course) > either it runs or it does not, nothing a dev could change much about it (with notable exceptions of course, like notaz and mh-t).
The only problem that may have been a thing in the past is probably already gone by now: driver support. As Windows 10 will be the last "versioned" Windows, thus everything new will just be delivered via updates, people can have a device now for a long time without worrying too much about wether there will be driver support for their hardware in the next version of Windows.
I would say, most people don't really car about the details when they are making their decision to buy it or not. They will just see, that they can play titles x,y,z they like, that will be enough at that point. And later on, depending on the circumstances (lots of mobile time to fill, desire for a certain game, etc.) they will just make do: Jedi Knight, Minecraft, Starcraft, etc., all titles that were designed to be played with mouse and keyboard, still they are played with nubs (and without the special treatment games usually get before they are released on consoles). Same goes for text in games that will be too small, people just adapt, either they will just ignore the text and try to figure things out without it, or they already know the important parts as they played it on a desktop PC beforehand. That was my modus operandi for many years as kid > could not understand a single word of english, but still, about 95% of the games I played were completely in english- most of the time I did figure out by trial and error what to (not) do, sometimes not at all, and I probably missed a lot of the story parts, but I did not care.
That is still true, but an occasional reinstall (or reflash) isn't a very big deal - especially if you employ a Steam like service, that is already taking care of installing the games you play and syncing your save games. Or use other means or services to backup/sync the things you want to keepAnd... don't know if Windows has improved, but I remember it slowing down and being cluttered after installing / deinstalling lots of things... I don't want to know what that will mean if I try out 200 games and only keep the ones I want to play
I wonder whether they have got their hands on a "real" landscape display or if they let Windows do all the rotation work.
SNESFAN
Retro game fanatic
the rotation thing for windows shouldn't be that big of a deal here in reality, for the same reason smart phones and even if you were to run debian. X (xorg/xserver whatever) for linuxes, Surface flinger for android, and I'm not sure what it's called in windows, does the rotation computations automatically. Surely it costs some CPU/GPU time to do constantly, but it doesn't appear to be that expensive comparatively, running an application in one rotation doesn't seem to drastically effect performance vs another in side by side comparisons.
I don't think the issue will be *THAT* big of a deal on the pyra in reality for lots of use cases, but as there are some needs out there for using directfb for optimization sake, it's going to be a hassle for developers to rotate all their elements to accommodate for it when using it. An example of where it was a negative for me, was I ported the GCW Zero's Open Dingux OS to the nvidia shield, the shield had a portrait display in a landscape mounting. Normally because of android's surface flinger, you don't notice it except for some random applications that have it hard coded for portrait (less of a OS problem than a application problem there though) But Open Dingux doesn't use X what so ever, it uses directfb exclusively, so everything came out rotated 90 degrees, and I had no real easy way of fixing it without modifying every executable's source to adapt. That presented it's self as a insurmountable challenge to me. I can see that same kind of problem being more frequent on the pyra than most normal situations due to the nature of what kind of software we like to run, and how optimized people in this community likes to make their software, but for normal uses, and normal people, probably a non-issue.
I also think for your average pyra user, just the thought of your device doing things it probably shouldn't have to do, even if it doesn't cost a substantial amount of processing power, is going drive owners batty. "We" are particularly sensitive to even the slightest amount of non optimization.
levi
Still fresh, damnit!
I'm not convinced rolling releases are the reason behind long term driver support; most linuxes didn't have rolling releases, historically, and even those that don't still still support that old printer that windows barfs at these days. I suspect the reason is most windows drivers are supplied by the manufacturer: especially old installer code is likely to be broken by API changes in my experience, even if the underlying code works fine still. Drivers also seem to be smaller in Linux, so it's not so costly to support those thousands of devices out of the box.
I also wouldn't be surprised if another paid for release of Windows is announced at some point, or at least if new features become monetised. Office is still a big seller to, well, offices and other businesses, but I know of a few individual users who just get by with libreoffice these days, and I only see that option getting more popular as time goes on. Are their phone and game businesses making any real money these days? They need some income to at least maintain the pension pot and not make the shareholders too nervous.
thatgui
Advanced Member
- Joined
- Apr 2, 2009
- Messages
- 3,048
Looking at Androids rotation I am not so sure about the costs beeing trivial - but maybe the implemented rotator in Android (3.?-5.0) has a lot of "optimization potential" - don't know about Windows though
I am not sure Linux and Windows are that easily to compare in that regard: MS revamped their driver Model a lot for XP and refined it even more for 7, and again for 8/10. Of course there is a big chance that there will be modifications again, but I can only see that several years down the road. But for the next few years you get a regularly updated system were you just don't have to worry about the underlying system.
Additionally with most (if not all parts) of the chipset coming from one specific big manufacturer (Intel) its a lot more likely the plattform is supported for a longer period of time > maybe Microsoft is even having some kind of agreement with Intel regarding an ongoing driver support
Oh, I am pretty sure about that (but not as a new, seperate System, like Windows 11): There is a reason Steam went the SteamOS route as soon as it was clear that MS will introduce its own store, and MS has also reason to give a way their OS for free currently, while simultaneously artificially limiting their other products (like peripherals or games) to need W10. Eventually Windows will get a subscription based (maybe SaaS or DaaS) licensing model, with MS gradually strengthening it store as the only viable option to install software on a PC running Windows. Till Windows user will end up in the same situation as Apple users.
[doublepost=1452078866,1452078601][/doublepost]
There is a possibility to ask for a custom board...imagine a custom cpu x86 board for Pyra...
Really interesting.
There is a possibility to ask for a custom board...imagine a custom cpu x86 board for Pyra...
Really interesting.
SNESFAN
Retro game fanatic
it's trivial in comparison when considering everything is rendered in the GPU (GLES) before being displayed regardless of orientation.
IIRC the hardware acceleration requirement started with 4.0
That would be extremely interesting, MOQ seems about the scale of this project as well... ED?
Last edited:
Don't underestimate the rotation problem - rotation CAN but doesn't NEED to slow things down!
On Android, everything is done using OpenGL. The programs send their graphics output to the Android system which uses OpenGL to display it.
I don't think there's a way to directly access the screen.
For that reason, I've never seen an Android system which does not stutter occasionally during gameplay, which is annoying for me.
Things have improved, but they're still not perfect.
As mentioned above, porting Dingux to the Shield causes rotation issues.
To fix that, you either need to change the game code so that everything is rendered in portrait mode (which is annoying and complex), or rotate each frame in the game before showing it, which slows things down a LOT, unless you have some dedicated chip (like our rotator) to do that.
Why does it slow things down, it's such a simple mathematical task?
Well, the problem is not CPU power, it's memory bandwidth.
The fastest way for games and emulators is to write into the display framebuffer directly. Means: The image appears instantly, without any speed loss.
The display reads out the framebuffer line by line - so you need to write to it line by line. You cannot rotate when writing directly to the framebuffer.
So, you first need to write your image fully into some other memory (line by line) and when one frame is in there, you can read it out column by column (random access memory) and write that into the framebuffer.
With 60fps and a 720p display, you can imagine the massive data that's being pushed through the memory!
We tried that with PicoDrive, and it ran with about 10fps on the Pyra devboard with that rotation - that's an IMMENSE slowdown!
So the fix would be to either use OpenGL for rotation (which would work with wayland, but we still couldn't use the fastest mode, direct framebuffer access) or to use some hardware that can do that (our rotator chip).
I don't know how Windows handles that - has someone tried running an emulator rotated on his monitor to see how much CPU Power increases or the FPS decrease?
Maybe the GPU has a dedicated 2D rotator included, I don't know.
But as mentioned, how grave the impact of the portrait display is depends also on the program!
On Android, everything is done using OpenGL. The programs send their graphics output to the Android system which uses OpenGL to display it.
I don't think there's a way to directly access the screen.
For that reason, I've never seen an Android system which does not stutter occasionally during gameplay, which is annoying for me.
Things have improved, but they're still not perfect.
As mentioned above, porting Dingux to the Shield causes rotation issues.
To fix that, you either need to change the game code so that everything is rendered in portrait mode (which is annoying and complex), or rotate each frame in the game before showing it, which slows things down a LOT, unless you have some dedicated chip (like our rotator) to do that.
Why does it slow things down, it's such a simple mathematical task?
Well, the problem is not CPU power, it's memory bandwidth.
The fastest way for games and emulators is to write into the display framebuffer directly. Means: The image appears instantly, without any speed loss.
The display reads out the framebuffer line by line - so you need to write to it line by line. You cannot rotate when writing directly to the framebuffer.
So, you first need to write your image fully into some other memory (line by line) and when one frame is in there, you can read it out column by column (random access memory) and write that into the framebuffer.
With 60fps and a 720p display, you can imagine the massive data that's being pushed through the memory!
We tried that with PicoDrive, and it ran with about 10fps on the Pyra devboard with that rotation - that's an IMMENSE slowdown!
So the fix would be to either use OpenGL for rotation (which would work with wayland, but we still couldn't use the fastest mode, direct framebuffer access) or to use some hardware that can do that (our rotator chip).
I don't know how Windows handles that - has someone tried running an emulator rotated on his monitor to see how much CPU Power increases or the FPS decrease?
Maybe the GPU has a dedicated 2D rotator included, I don't know.
But as mentioned, how grave the impact of the portrait display is depends also on the program!
