11 ms·
Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V
- brandonpelfrey 2y agoIncredible result! This is a tremendous amount of work and does seem like RV is at its limits in some of these cases. The bit gather and scatter instructions should become an extension!
- glitchc 2y agoWould be useful to see test results on a game that relies more heavily on the graphics core than the CPU. Perhaps Divinity 2?
- justahuman74 2y agoI hope they're able to get this ISA-level feedback to people at RVI
- dmitrygr 2y agoNone of this is new. None of it. In fact, bitfield extract is such an obvious oversight that it is my favourite example of how idiotic the RISCV ISA is (#2 is lack of sane addressing modes). Some of the better RISCV designs, in fact, implement a custom instr to do this, eg: BEXTM in Hazard3: https://github.com/Wren6991/Hazard3/blob/stable/doc/hazard3.pdf https://github.com/Wren6991/Hazard3/blob/stable/doc/hazard3....
- renox 2y agoWhoa, someone else who doesn't believe that the RISC-V ISA is 'perfect'! I'm curious: how the discussions on the bitfield extract have been going? Because it does really seem like an obvious oversight and something to add as a 'standard extension'. What's your take on 1) unaligned 32bit instructions with the C extension? 2) lack of 'trap on overflow' for arithmetic instructions? MIPS had it..
- dmitrygr 2y ago1. aarch64 does this right. RISCV tries to be too many things at once, and predictably ends up sucking at everything. Fast big cores should just stick to fixed size instrs for faster decode. You always know where instrs start, and every cacheline has an integer number of instrs. microcontroler cores can use compressed intrs, since it matters there, while trying to parallel-codec instrs does not matter there. Trying to have one arch cover it all is idiotic. 2. nobody uses it on mips either, so it is likely of no use.
- bonzini 2y agoFixed size instructions are not absolutely necessary, but keeping them naturally aligned is just better even if that means using C instructions a bit less often. It's especially messy that 32-bit instructions can span a page.
- loup-vaillant 2y ago> Fast big cores should just stick to fixed size instrs for faster decode. How much faster, though? RISC-V decode is not crazy like x86, you only need to look at the first byte to know how long the instruction is (the first two bits if you limit yourself to 16 and 32-bit instructions, 5 bits if you support 48-bits instructions, 6 bits if you support 64-bits instructions). Which means, the serial part of the decoder is very very small. The bigger complain about variable length instruction is potentially misaligned instructions, which does not play well with cache lines (a single instruction may start in a cache line and end at the next, making hardware a bit more hairy). And there’s an advantage to compressed instructions even on big cores: less pressure on the instruction cache, and correspondingly fewer cache misses. Thus, it’s not clear to me that fixed size instructions is the obvious way to go for big cores.
- newpavlov 2y agoAnother argument against the C extension is that it uses a big chunk of the opcode space, which may be better used for other extensions with 32-bit instructions.
- Findecanor 2y agoBitfield-extract is being discussed for a future extension. E.g. Qualcomm is pressing for it to be added. In the meantime, it can be done as two shifts: left to the MSB, and then right filling with zero or sign bits. There is at least one core in development (SpaceMiT X100) that is supposed to be able to fuse those two into a single µop, maybe some that already do. However, I've also seen that one core (XianShan Nanhu) is fusing pairs of RVI instructions into one in the B extension, to be able to run old binaries compiled for CPUs without B faster. Throwing hardware at the problem to avoid a recompile ... feels a bit backwards to me.
- camel-cdr 2y agoThe scalar efficiency SIG has already been discussing bitfield insert and extract instructions. We figured out yesterday [1], that the example in the article can already be done in four risc-v instructions, it's just a bit trickier to come up with it: # a0 = rax, a1 = rbx slli t0, a1, 64-8 rori a0, a0, 16 add a0, a0, t0 rori a0, a0, 64-16 [1] https://www.reddit.com/r/RISCV/comments/1f1mnxf/box64_and_riscv_in_2024/ https://www.reddit.com/r/RISCV/comments/1f1mnxf/box64_and_ri...
- bonzini 2y agoNice trick, in fact with 4 instructions it's as efficient as extract/insert and it works for all ADD/SUB/OR/XOR/CMP instructions (not for AND), except if the source is a high-byte register. However it's not really a problem if code generation is not great in this case: compilers in practice will not generate accesses to these registers, and while old 16-bit assembly code has lots of such accesses it's designed to run on processors that ran at 4-20 MHz. Flag computation and conditional jumps is where the big optimization opportunities lie. Box64 uses a multi-pass decoder that computes liveness information for flags and then computes flags one by one. QEMU instead tries to store the original operands and computes flags lazily. Both approaches have advantages and disadvantages...
- ptitSeb 2y agoActually, Box64 can also store operands for later computation, depending on what comes next...
- brucehoult 2y ago> except if the source is a high-byte register That's just one more instruction, to right-align the AH, BH etc src operand prior to exactly the same instructions as above. And, yes, this being 64 bit code compilers won't be generating such instructions. In fact they started avoiding them as soon as OoO hit in the Pentium Pro, P II, P III etc in the mid 90s because of "partial register update stalls".
- ksco 2y agoAuthor here, we have adopted this approach as a fast path to box64: https://github.com/ptitSeb/box64/pull/1763 https://github.com/ptitSeb/box64/pull/1763, thank you very much!
- littlecranky67 2y agoArticle is a bit short on "the basics" - I assumed they used some kind of wine port to run it. But it seems they implemented the x86_64 ISA on a RISC-V chip in some way - anyone can shed more light on that part how that is done?
- anewhnaccount2 2y agoThe basics are here: https://box86.org/ https://box86.org/ It is an emulator but: > Because box86 uses the native versions of some “system” libraries, like libc, libm, SDL, and OpenGL, it’s easy to integrate and use with most applications, and performance can be surprisingly high in some cases. Wine can also be compiled/run as native.
- ThatPlayer 2y ago> Wine can also be compiled/run as native. I'm not sure you can run Wine natively to run x86 Windows programs on RISC-V because Wine is not an emulator. There is an ARM port of Wine, but that can only run Windows ARM programs, not x86. Instead box64 is running the x86_64 Wine https://github.com/ptitSeb/box64/blob/main/docs/X64WINE.md https://github.com/ptitSeb/box64/blob/main/docs/X64WINE.md
- gary_0 2y agoIt should be theoretically possible to build Wine so that it provides the x86_64 API while compiling it to ARM/RISCV. Your link doesn't make it clear if that's what's being done or not. (Although I suspect providing the API of one architecture while building for another is far easier said than done. Toolchains tend to be uncooperative about such shenanigans, for starters.)
- ThatPlayer 2y agoBox64's documentation is just on installing the Wine x64 builds from winehq repos, because most arm repos aren't exactly hosting x64 software. It's even possible to run Steam with their x64 Proton running Windows games. At least on ARM, not sure about RISC-V. Wine's own documentation says it requires an emulator: https://wiki.winehq.org/Emulation https://wiki.winehq.org/Emulation > As Wine Is Not an Emulator, all those applications can't run on other architectures with Wine alone. Or do you mean provide the x86_64 Windows API as a native RISC-V/ARM to the emulator layer? That would require some deeper integration for the emulator, but that's what Box64/box86 already does with some Linux libraries: intercept the api calls and replace them with native libraries. Not sure if it does it for wine
- int0x29 2y agoThat screenshot shows 31 gb of ram which is distinctly more than the mentioned dev board at max specs. Are they using something else here?
- victor_cl 2y agoI remember learning RISC-V in Berkeley CS61C. Anyone from Berkeley？
- Manfred 2y ago> At least in the context of x86 emulation, among all 3 architectures we support, RISC-V is the least expressive one. RISC was explained to me as a reduced instruction set computer in computer science history classes, but I see a lot of articles and proposed new RISC-V profiles about "we just need a few more instructions to get feature parity". I understand that RISC-V is just a convenient alternative to other platforms for most people, but does this also mean the RISC dream is dead?
- flanked-evergl 2y agoIs there a RISC dream? I think there is an efficiency "dream", there is a performance "dream", there is a cost "dream" — there are even low-complexity relative to cost, performance and efficiency "dreams" — but a RISC dream? Who cares more about RISC than cost, performance, efficiency and simplicity?
- impossiblefork 2y agoBut we define the RISC dream as a dream that efficiency, performance and low-cost could be achieved by cores with very small instruction sets?
- flanked-evergl 2y agoIf adding more instructions negatively impacts efficiency, performance, cost and complexity, nobody would do it.
- foldr 2y agoProbably true now, but in ye olde days, some instructions existed primarily to make assembly programming more convenient. Assembly programming is a real pain in the RISCiest of RISC architectures, like SPARC. Here's an example from https://www.cs.clemson.edu/course/cpsc827/material/Code%20Generation/SPARC%20Reference%20Card.pdf https://www.cs.clemson.edu/course/cpsc827/material/Code%20Ge...: • All branches (including the one caused by CALL, below) take place after execution of the following instruction. • The position immediately after a branch is the “delay slot” and the instruction found there is the “delay instruction”. • If possible, place a useful instruction in the delay slot (one which can safely be done whether or not a conditional branch is taken). • If not, place a NOP in the delay slot. • Never place any other branch instruction in a delay slot. • Do not use SET in a delay slot (only half of it is really there).
- lyu07282 2y agoAnother technically impressive Witcher 3 feat was the Switch port, it ran really well. Goes to show how much can be done with optimization and how much resources are wasted on the PC purely by bad optimization.
- laserbeam 2y agoAnd with using much lower quality textures and 3D models, therefore using much less RAM for assets. It's not an apples to apples comparison and you can't really make claims about bad optimization on PCs when the scope of what's shown on screen is vastly different.
- zamadatix 2y agoYou too can run Witcher 3 equally on a minimal PC if you're willing to set the render resolution to 720p (540p undocked), settings to below minimum, and call ~30 FPS well.
- theragra 2y agoReminded me how one famous Russian guy ran Atomic Heart on Elbrus 8S. Elbrus has native translator, though, and pretty good one, afaik. Atomic Heart was kinda playable, 15-25 fps.
- high_na_euv 2y agoGreat game choice!
- mrlonglong 2y agoIs this the 86Box? I found it fun reliving the time I got my Amstrad PC1512, I added two hard cards of 500MB and a 128k memory expansion to 640KB which made things a lot more fun. Back then I only had two 360KB floppies and added a 32MB hard card a few years later. I had Borland TurboPascal and Zortech C too. Fun times.
- ptitSeb 2y agoNo, it's Box64, a completly different project. (But I do remember the time I had an Amstrad PC1512 too :D )
- mrlonglong 2y agoIt will be interesting to try out Box64 as soon as I get my hands on some suitable RISCV hardware. I have played with RISCV microcontrollers they're quite nice to work with.
- nolist_policy 2y ago> The x86 instruction set is very very big. According to rough statistics, the ARM64 backend implements more than 1,600 x86 instructions in total, while the RV64 backend implements about 1,000 instructions This is just insane and gets us full-circle to why we want RISC-V.
- patmorgan23 2y agoNot really. RISC-V's benefits are not the "Reduced Instruction Set" part, it's the open ISA part. A small instruction set as actually has several disadvantages. It means you binary bigger because what was a single operation in x86 is now several in RISC-V, meaning more memory bandwidth and cache is taken up by instructions instead of data. Modern CPUs are actually really good at deciding operations into micro-ops. And the flexibility of being able to implement a complex operation in microcode, or silicon is essential for CPU designers. Is there a bunch of legacy crap in x86? Yeah. Does getting rid of dramatically increase the performance ceiling? Probably not. The real benefit of RISC-V is anybody can use it. It's democratizing the ISA. No one has to pay a license to use it, they can just build their CPU design and go.
- zozbot234 2y ago> Modern CPUs are actually really good at deciding operations into micro-ops. The largest out-of-order CPUs are actually quite reliant on having high-performance decode that can be performed in parallel using multiple hardware units. Starting from a simplified instruction set with less legacy baggage can be an advantage in this context. RISC-V is also pretty unique among 64-bit RISC ISA's wrt. including compressed instructions support, which gives it code density comparable to x86 at a vastly improved simplicity of decode (For example, it only needs to read a few bits to determine which insns are 16-bit vs. 32-bit length).
- panick21_ 2y ago> means you binary bigger .... meaning more memory bandwidth and cache Except this isn't actually true. > Does getting rid of dramatically increase the performance ceiling? Probably not. No but it dramatically DECREASES the amount of investment necessary to reach that ceiling. Assume you have 2 teams, each get the same amount of money. Then ask them to make the highest performing spec compatible chip. What team is gone win 99% of the time? > And the flexibility of being able to implement a complex operation in microcode, or silicon is essential for CPU designers. You can add microcode to a RISC-V chip if you want, most people just don't want to. > The real benefit of RISC-V is anybody can use it. That is true, but its also just a much better instruction set then x86 -_-
- anthk 2y agoI used to use GL4ES on the PocketCHIP. And I daily use it on a netbook to get more performance on some GL 2.1 games.
- Havoc 2y ago>15 fps in-game Wow...that's substantially more than I would have guessed. Good times ahead for hardware
- deleted 2y ago[deleted]
- KingOfCoders 2y ago"which allows games like Stardew Valley to run, but it is not enough for other more serious Linux games" Hey! ;-)
- deleted 2y ago[deleted]
- stuckinhell 2y agowow very impressive
- jokoon 2y agoQuestion for somebody who doesn't work in chips: what does a software engineer has to do differently when targeting software for RISC5? I would imagine that executable size increases, meaning it has to be aggressively optimized for cache locality? I would imagine that some types of softwares are better suited for either CISC or RISC, like games, webservers?
- dzaima 2y agoRISC-V with the compressed instruction extension actually ends up smaller than x86-64 and ARM on average. There's not much inherent that needs to change in software approach. Probably the biggest thing vs x86-64 is the availability of 32 registers (vs 16 on x86-64), allowing for more intermediate values before things start spilling to stack, which also applies to ARM (which too has 32 registers). But generally it doesn't matter unless you're micro-optimizing. More micro-optimization things might include: - The vector extension (aka V or RVV) isn't in the base rv64gc ISA, so you might not get SIMD optimizations depending on the target; whereas x86-64 and aarch64 have SSE2 and NEON (128-bit SIMD) in their base. - Similarly, no popcount & count leading/trailing zeroes in base rv64gc (requires Zbb); base x86-64 doesn't have popcount, but does have clz/ctz. aarch64 has all. - Less efficient branchless select, i.e. "a ? b : c"; takes ~4-5 instrs on base rv64gc, 3 with Zicond, but 1 on x86-64 and aarch64. Some hardware can also fuse a jump over a mv instruction to be effectively branchless, but that's even more target-specific. RISC-V profiles kind of solve the first two issues (e.g. Android requires rva23, which requires rvv & Zbb & Zicond among other things) but if linux distros decide to target rva20/rv64gc then they're ~forever stuck without having those extensions in precompiled code that hasn't bothered with dynamic dispatch. Though this is a problem with x86-64 too (much less so with ARM as it doesn't have that many extensions; SVE is probably the biggest thing by far, and still not supported widely (i.e. Apple silicon doesn't)).
- packetlost 2y agoThat seems like something the compiler would generally handle, no? Obviously that doesn't apply everywhere, but in the general case it should.
- Thaxll 2y agoBox86 is so good, I run x86-64 steam games ( servers ) on free Oracle instance ( ARM64 ) with it.
- sylware 2y agolol, I am going the other way around. Since RISC-V ISA is worldwide royalty free and more than nice, I am writting basic rv64 assembly which I do interpret on x86_64 hardware with a linux kernel. I did not push the envelop up to have a "compiler", because it is indeed while waiting for hardcore performant desktop, aka large, rv64 hardware implementations.
- bee_rider 2y agoI wonder if systems will ship at some point that are a handful of big RISC-V CPUs, and then a “GPU” implemented as a bunch of little RISC-V CPUs (with the appropriate vector stuff—actually, side-question, can classic vectors, instead of packed SIMD, be useful in a GPU?)
- krishnamegh801 2y ago[dead]
- Beijinger 2y agoPreviously: https://news.ycombinator.com/item?id=19118642 https://news.ycombinator.com/item?id=19118642 And: Milk-V Pioneer A 64-core, RISC-V motherboard and workstation for native development https://www.crowdsupply.com/milk-v/milk-v-pioneer https://www.crowdsupply.com/milk-v/milk-v-pioneer
- sdwrj 2y agobox64 is getting too advanced lol
- ChoHag 2y ago[dead]
- nikitau 2y agoI'm not very familiar with the ecosystem, but I have used this on an RPi4 to run some games through wine. I'm wondering, how's the landscape nowadays. Is this the leading project for x86 compatibility on ARM? With the rising popularity of the architecture for consumer platforms, I'd guess companies like Valve would be interested in investing in these sort of translation layers.