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

131–140 of 149 posts

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

#131

Post by kllrnohj »

Closi wrote: post #34
gary_0 wrote: post #26

Earlier quoted context omitted.

As I've heard it explained, RISC in practise is less about "an absolutely minimalist instruction set" and more about "don't add any assembly programmer conveniences or other such cleverness, rely on compilers instead of frontend silicon when possible". Although as I recall from reading the RISC-V spec, RISC-V was rather particular about not adding "combo" instructions when common instruction sequences can be fused by…

Put another way, "try to avoid instructions that can't be executed in a single clock cycle, as those introduce silicon complexity".

But that's not even close to true, either, eg any division or memory operation.

In practice there's no such thing as "RISC" or "CISC" anymore really, they've all pretty much converged. At best you can say "RISC" now just means that there aren't any mixed load + alu instructions, but those aren't really used in x86 much, either

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

#132

Post by fngjdflmdflg »

vlovich123 wrote: post #124
fngjdflmdflg wrote: post #118

Earlier quoted context omitted.

I read somewhere that since floating point addition is not associative the compiler will not autovectorize because the order might change.

It’s somewhat more complicated than that (& presumed your hot path is floating point instead of integral), but that can be a consideration.

What are the other considerations? (assuming we are dealing with FP)

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

#133

Post by theragra »

Beijinger wrote: post #104
theragra wrote: post #21

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

Elbrus is/was RISC?-V?

Nah, it is fully custom VLIW

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

#134

Post by vlovich123 »

fngjdflmdflg wrote: post #132
vlovich123 wrote: post #124

Earlier quoted context omitted.

It’s somewhat more complicated than that (& presumed your hot path is floating point instead of integral), but that can be a consideration.

What are the other considerations? (assuming we are dealing with FP)

Disclaimer: not an expert here so could be very very wrong. This is just my understanding so happy to be corrected.

Another would be that something like fused multiple add would have different (higher if I recall correctly) precision which violates IEE754 and thus vectorization since default options are standard compliant.

Another is that some math intrinsics are documented to populate errno which would prevent using autovec in paths that have an intrinsic.

There may be other nuances depending on float vs double.

Basically most of the things that make up ffast-math i believe would prevent autovectorization.

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

#135

Post by sweetjuly »

Dylan16807 wrote: post #108
sweetjuly wrote: post #89

Earlier quoted context omitted.

The C extension authors did consider requiring alignment/padding to prevent the misaligned 32-bit instruction issues, but they specifically mention rejecting it since it ate up all the code size savings.

Did they specifically analyze doing alignment on a cache line basis?

This would require specifying a cache line size in the ABI, which is a somewhat odd uarch detail to bubble up. While 64-bytes is conventional for large application processors and has been for a long time, I wouldn't want to make it a requirement.

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

#136

Post by snvzz »

patmorgan23 wrote: post #54
nolist_policy wrote: post #49

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

Not 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. An…

>It means you binary bigger

False premise, as size tool shows RVA20(RV64GC) binaries were already smallest among 64bit architectures.

Code gets smaller still (rather than larger) with newer extensions such as B in RVA22.

As of recently, the same is true in 32bit when comparing rv32 against former best (thumb2). But it was quite close before to begin with.

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

#137

Post by adgjlsfhk1 »

vlovich123 wrote: post #123
adgjlsfhk1 wrote: post #112

Earlier quoted context omitted.

Apple's m1 chips are 8 wide. and AMD and Intel's newest chips are also doing more fancy things than 4 wide

Any reading resources? I’d love to learn better the techniques they’re using to get better parsllelism. The most obvious solution I can imagine is that they’d just try to brute force starting to execute every possible boundary and rely on it either decoding an invalid instruction or late latching the result until it got confirmed that it was a valid instruction boundary. Is that generally the technique or are they do…

https://chipsandcheese.com/2024/08/14/amds-ryzen-9950x-zen-5... is a pretty good overview of the microarchitecture. I don't think they say how they get there, because trade secrets.

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

#138

Post by dzaima »

vlovich123 wrote: post #134
fngjdflmdflg wrote: post #132

Earlier quoted context omitted.

What are the other considerations? (assuming we are dealing with FP)

Disclaimer: not an expert here so could be very very wrong. This is just my understanding so happy to be corrected. Another would be that something like fused multiple add would have different (higher if I recall correctly) precision which violates IEE754 and thus vectorization since default options are standard compliant. Another is that some math intrinsics are documented to populate errno which would prevent using…

Fused multiply add applies equally to scalar and vectorized code (and C actually allows compilers to fuse them; there's -ffp-contract=off / the FP_CONTRACT pragma to turn that off); the compiler/autovectorizer can trivially just leave multiply & add as separate if so requested (slower than having them fused? perhaps. But no impact at all on scalar vs vector given that both have the same fma applicability).

For errno, there's -fno-math-errno; indeed included in -ffast-math, but you don't need the entirety of that mess for this.

Loops with a float accumulator is I believe the only case where -ffast-math is actually required for autovectorizability (and even then iirc there are some sub-flags such that you can get the associativity-assuming optimizations while still allowing NaN/inf).

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

#139

Post by brucehoult »

bonzini wrote: post #14
camel-cdr wrote: post #7

Earlier quoted context omitted.

The 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_ri...

Nice 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…

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

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

#140

Post by adgjlsfhk1 »

Suppafly wrote: post #127
adgjlsfhk1 wrote: post #111

Earlier quoted context omitted.

complexity that the compiler removes doesn't have to be handled by the CPU at runtime

Sure but that's not necessarily at odds with "programmer conveniences or other such cleverness" is it?

it is in the sense that those are programmer conveniences only for assembly programmers and Riscv's view is that to the extent possible the assembly programmer interface should largely be handled by psuedo-instructions that disappear when your go to machine code rather than making the chip deal with them
Post reply on HN