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

111–120 of 149 posts

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

#111

Post by adgjlsfhk1 »

Suppafly wrote: post #107
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…

>and more about "don't add any assembly programmer conveniences or other such cleverness, rely on compilers instead of frontend silicon when possible" What are the advantages of that?

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

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

#112

Post by adgjlsfhk1 »

Joker_vD wrote: post #99
vlovich123 wrote: post #90

Earlier quoted context omitted.

To add on to what the sibling said, ignoring that CISC chips have a separate frontend to break complex instructions down into an internal RISC-like instruction set and thus the difference is blurred, more RISC instruction sets do tend to win on performance and power for the main reason that the instruction set has a fixed width. This means that you can fetch a line of cache and 4 byte instructions you could start dec…

x86 instruction lengths range from 1 to 15. > a line of cache and 4 byte instructions you could start decoding 32 instructions in parallel In practice, ARM processors decode up to 4 instructions in parallel; so do Intel and AMD.

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

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

#113

Post by adgjlsfhk1 »

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?

that seems really tough for compilers.

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

#114

Post by Pet_Ant »

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?

No, any ISA pretty much should be equally good for any type of workload. If you are doing assembly programming then it makes a difference but if you were doing something in Python or Unity it really isn’t going to matter.

This is more about being free of ARM’s patents and getting a fresh start using the lessons learned

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

#115

Post by dmitrygr »

adgjlsfhk1 wrote: post #113
Dylan16807 wrote: post #108

Earlier quoted context omitted.

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

that seems really tough for compilers.

Not really. Most modern x86 compilers already align jump targets to cache line boundaries since this helps x86 a lot. So it is doable. If you compile each function into a section (common), then the linker can be told to align them to 64 or 128 bytes easily. Code size would grow (but tetris can be played to reduce this by packing functions)

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

#116

Post by zamadatix »

lyu07282 wrote: post #20

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

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

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

#117

Post by Closi »

Suppafly wrote: post #107
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…

>and more about "don't add any assembly programmer conveniences or other such cleverness, rely on compilers instead of frontend silicon when possible" What are the advantages of that?

Instructions can be completed in one clock cycle, which removes a lot of complexity compared to instructions that require multiple clock cycles.

Removed complexity means you can fit more stuff into the same amount of silicon, and have it be quicker with less power.

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

#118

Post by fngjdflmdflg »

vlovich123 wrote: post #86
packetlost wrote: post #79

Earlier quoted context omitted.

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

Vector stuff is typically hand coded with intrinsics or assembly. Autovectorization has mixed results because there’s no way to request the compiler to promise that it vectorized the code. But for an emulator like this, box64 has to pick how to emulate vectorized instructions on RiscV (eg slowly using scalars or trying to reimplement using native vector instructions). The challenge of course is that typically you don…

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

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

#119

Post by wang_li »

Manfred wrote: post #18

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

Beyond the most trivial of microcontrollers and experimental designs there are no RISC chips under the original understanding of RISC. The justification for RISC evaporated when we became able to put 1 million, 100 million, and so on, transistors on a chip. Now all the chips called "RISC" include vector, media, encryption, network, FPUs, and etc. instructions. Someone might want to argue that some elements of RISC designs (orthogonal instruction encoding, numerous registers, etc.) make a particular chip a RISC chip. But they really aren't instances of the literal concept of RISC.

To me, the whole RISC-V interest is all just marketing. As an end user I don't make my own chips and I can't think of any particular reason I should care whether a machine has RISC-V, ARM, x86, SPARC, or POWER. In the end my cost will be based on market scale and performance. The licensing cost of the design will not be passed on to me as a customer.

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

#120

Post by RiverCrochet »

Manfred wrote: post #18

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

The RISC dream was to simplify CPU design because most software was written using compilers and not direct assembly.

Characteristics of classical RISC:

- Most data manipulation instructions work only with registers.

- Memory instructions are generally load/store to registers only.

- That means you need lots of registers.

- Do your own stack because you have to manually manipulate it to pass parameters anyway. So no CALL/JSR instruction. Implement the stack yourself using some basic instructions that load/store to the instruction pointer register directly.

- Instruction encoding is predictable and each instruction is the same size.

- More than one RISC arch has a register that always reads 0 and can't be written. Used for setting things to 0.

This worked, but then the following made it less important:

- Out-of-order execution - generally the raw instruction stream is a declaration of a path to desired results, but isn't necessarily what the CPU is really doing. Things like speculative execution, branch prediction and register renaming are behind this.

- SIMD - basically a separate wide register space with instructions that work on all values within those wide registers.

So really OOO and SIMD took over.

Post reply on HN