Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V

box86.org

Post reply on HN
Print view View original

71–80 of 149 posts

Re: Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V

#71

Post by phkahler »

renox wrote: post #8
dmitrygr wrote: post #4

Earlier quoted context omitted.

None 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....

Whoa, 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..

IMHO they made a mistake by not allowing immediate data to follow instructions. You could encode 8 bit constants within the opcode, but anything larger should be properly supported with immediate data. As for the C extension, I think that was also inferior because it was added afterward. I'd like to see a re-encoding of the entire ISA in about 10 years once things are really stable.

Re: Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V

#72

Post by newpavlov »

camel-cdr wrote: post #47
newpavlov wrote: post #40

Earlier quoted context omitted.

Another 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.

Are just 32-bit and naturally aligned 64 bit instruction a better path than fewer 32 bit, but 16/48/64 bit instructions? I think it's quite unclear which one is better. 48-bit instructions have a lot of potential imo, they have better code density then naturally aligned 64 bit instructions, and they can encode more that 32-bit. (2/3 to 3/4 of 43-bits of encoding) There are essentially two design philosophies: 1. 32-b…

There is also a middle ground of requiring to pad 16/48-bit sequences with 16-bit NOP to align them to 32 bits. I agree that at this time it's not clear whether the C extension is a good idea or not (same with the V extension).

Re: Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V

#73

Post by jokoon »

Question 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?

Re: Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V

#74

Post by dzaima »

jokoon wrote: post #73

Question 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?

RISC-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)).

Re: Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V

#76

Post by glitchc »

brandonpelfrey wrote: post #2

Incredible 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!

Would be useful to see test results on a game that relies more heavily on the graphics core than the CPU. Perhaps Divinity 2?

Re: Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V

#77

Post by sylware »

lol, 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.

Re: Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V

#78

Post by panick21_ »

fanf2 wrote: post #29
impossiblefork wrote: post #23

Earlier quoted context omitted.

But we define the RISC dream as a dream that efficiency, performance and low-cost could be achieved by cores with very small instruction sets?

Not small instruction sets, simplified instruction sets. RISC’s main trick is to reduce the number of addressing modes (eg, no memory indirect instructions) and reduce the number of memory operands per instruction to 0 or 1. Use the instruction encoding space for more registers instead. The surviving CISCs, x86 and z390 are the least CISCy CISCs. The surviving RISCs, arm and power, are the least RISCy RISCs. RISC V i…

Lets be real, its about business models. POWER was and is backed by IBM. ARM won on mobile. Does this mean POWER and ARM are better then MIPS, SPARC, PA-RISC, Am29000, i860? I don't think so.

Re: Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V

#79

Post by packetlost »

dzaima wrote: post #74
jokoon wrote: post #73

Question 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?

RISC-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 doe…

That seems like something the compiler would generally handle, no? Obviously that doesn't apply everywhere, but in the general case it should.

Re: Box64 and RISC-V in 2024: What It Takes to Run the Witcher 3 on RISC-V

#80

Post by dzaima »

packetlost wrote: post #79
dzaima wrote: post #74

Earlier quoted context omitted.

RISC-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 doe…

That seems like something the compiler would generally handle, no? Obviously that doesn't apply everywhere, but in the general case it should.

It's something that the compiler would handle, but can still moderately influence programming decisions, i.e. you can have a lot more temporary variables before things start slowing down due to spill stores/loads (esp. in, say, a loop with function calls, as more registers also means more non-volatile registers (i.e. those that are guaranteed to not change across function calls)). But, yes, very limited impact even then.
Post reply on HN