[HN Gopher] Box86 vs native: OpenGL is almost native, CPU bound ...
___________________________________________________________________
Box86 vs native: OpenGL is almost native, CPU bound 50%, SSE3 is
slower
Author : marcodiego
Score : 105 points
Date : 2021-03-28 13:31 UTC (9 hours ago)
(HTM) web link (stands.fosdem.org)
(TXT) w3m dump (stands.fosdem.org)
| xaduha wrote:
| If it they can run Warhammer: Dark Omen with 3d acceleration,
| then that would be pretty impressive. Pretty famous for being a
| pain in the butt when it comes to running it on modern or
| emulated hardware.
| zapt02 wrote:
| Funny coincidence, I was just playing it last month! It was a
| bit annoying to get everything running but after consulting the
| guide over at http://forum.dark-omen.org/help-section/read-me-
| ultimate-dar... I was able to get a really great HD experience.
| But I agree with you, it took me probably 30-40 minutes of
| fiddling!
| marcodiego wrote:
| Really hope Box86 or wine hangover allow windows x86 binaries to
| run well on arm sbc on a not too distant future.
| ben-schaaf wrote:
| Someone's already gotten wine working on the pinephone:
| https://www.reddit.com/r/PinePhoneOfficial/comments/m4bvti/w...
| ekianjo wrote:
| > windows x86 binaries
|
| That may only work for 32 bits binary applications since Box86
| does not support 64 bits. You can already see Box86 + Wine
| running older Windows games here:
| https://www.youtube.com/watch?v=yoIptyr6zV4
| rijoja wrote:
| Me to! Maybe it is not in the scope of these projects. Apple
| however managed to do this for their latest architecture and
| also I think it was done quite a lot for the Pandora game
| console. So that would be by translating the binary files
| themselves to a new architecture before executing them.
|
| In the case that someone targets one application run in wine
| this is not to much work I believe. If someone would be
| interested into doing this, I would be very happy to help!
|
| https://www.giantpockets.com/starcraft-pandora-port-came/
| [deleted]
| RPiNews wrote:
| Well box86 actually supported running wine since a while ago,
| which means you can install x86 wine and use it.
| ekianjo wrote:
| Yes, that is precisely why you can play x86 Linux games
| through Box86 on ARM.
| spijdar wrote:
| Well, no -- you can also run the Linux version of Steam and
| games with a native Linux version with no need to use wine.
| The performance should be better than using wine, too.
| techrat wrote:
| Steam does not exist in repos on ARM based distributions.
| So no, you can't just also run the Linux version of Steam
| and games without a need to use Wine... When it comes to
| using Box86 on ARM.
| stuaxo wrote:
| Will there ever be a Box64 ?
| kcb wrote:
| Yes, already in early stages of development.
| https://www.youtube.com/watch?v=Ec3vIdpoPIM
| ant6n wrote:
| Does box86 have a jit?
| bri3d wrote:
| Yes, it's DynaRec (dynamic recompilation) which is a form of
| JIT. (I suppose you could call it an optimizing JIT of sorts) -
| with a fallback to a more "normal" JIT for x86 code which is
| emitting other x86 code (like Unity games).
| rijoja wrote:
| How do they detect when the fallback should be used?
| bri3d wrote:
| It's right in the README - "Box86's Dynarec uses a
| mechanism with Memory Protection and a SegFault signal
| handler to handle JIT code." Essentially, code areas are
| write protected and when they trigger a write fault, the
| area is marked as "dirty" to be recompiled.
|
| https://github.com/ptitSeb/box86/commit/2aa2e53fef61d00df53
| 5...
|
| first "protect memory, fault handler purges that code block
| as 'invalid' approach"
|
| and
|
| https://github.com/ptitSeb/box86/commit/4778760622df90c97da
| 2...
|
| second, "mark block as dirty rather than purging it"
| approach
| my123 wrote:
| Yes
| flatiron wrote:
| Dynarec
| q-big wrote:
| How does Box86 implement x86's strong memory model? It is, for
| example, well-known that for emulating x86 code on Apple M1,
| there exists a special mode on this specific CPU that enables a
| strong(er) memory model.
| monocasa wrote:
| Maybe it doesn't. If it only supports running on a single core
| at a time, it doesn't need to.
| moonchild wrote:
| > On a CPU intensive app [...] the emulated software is roughly
| 50% of the native speed. While this number can still be improved
| [...] this probably won't change much in the future (it will
| probably top at maybe 60%)
|
| This is a shame if true. What's the difference between this and
| something like rosetta 2 that allows the latter to achieve
| greater performance?
| floo wrote:
| Possibly M1 hardware optimisation for x86 emulation?
| Duralias wrote:
| Unless I am mistaken M1 chips have hardware dedicated to making
| translations faster.
| chmod775 wrote:
| I'll watch this with great interest.
|
| Looks like possibly a way to get Skype working on a rPI.
| ekianjo wrote:
| Zoom is already working via Box86:
| https://www.youtube.com/watch?v=9yx3XzYnHV4
| marcodiego wrote:
| A small list of command lines would be so much faster, easier
| and simpler than a youtube video...
| virtue3 wrote:
| But you can monetize a youtube video so much better >_>
| zozbot234 wrote:
| How would Box86 compare with QEMU user-level emulation?
| marcodiego wrote:
| No sure, but I think QEMU-user only translates syscalls. Box86
| (also) translates library calls. That way more code (libraries)
| can be run natively and, because of it, much faster.
| pm215 wrote:
| Yes, QEMU user-mode only emulates syscalls, so all the guest
| program's libraries are guest-architecture code, translated
| and run via the JIT.
| stuaxo wrote:
| Ah, it works the way I wrongly assumed qemu-usermode does.
| retrac wrote:
| The nice thing about Box86 is that it intercepts calls to
| things like the libc, SDL, font rendering and OpenGL, and runs
| the native library versions.
|
| In that regard, it's actually more like WINE than something
| like QEMU system mode. QEMU only emulates kernel system call
| interfaces and any library code is also emulated, and so is
| much slower.
___________________________________________________________________
(page generated 2021-03-28 23:00 UTC)