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

91–100 of 149 posts

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

#91

Post by pjc50 »

baq wrote: post #82
panick21_ wrote: post #81

Earlier quoted context omitted.

> This didn't work out ... except it did. You had literal students design chips that outperformed industry cores that took huge teams and huge investment. Acorn had a team of just a few people build a core that outperformed an i460 with likely 1/100 investment. Not to mention the even more expensive VAX chips. Can you imagine how fucking baffled the DEC engineers at the time were when their absurdly complex and absur…

All fine except Itanium happened and it goes against everything you list out...?

Itanium was not in any sensible way RISC, it was "VLIW". That pushed a lot of needless complexity into compilers and didn't deliver the savings.

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

#92

Post by aithrowaway1987 »

panick21_ wrote: post #67
aithrowaway1987 wrote: post #59

Earlier quoted context omitted.

I think the 1600 number is a coarse metric for this sort of thing. Keep in mind that these instructions are limited in the number of formal parameters they can take: e.g. 16 nominally distinct instructions can be more readily understood/memorized as one instruction with an implicit 4-bit flag. Obviously there's a ton of legacy cruft in Intel ISAs, along with questionable decisions, and I'm not trying to take away fro…

> clearly necessary for highly performance-sensitive work Its clearly necessary to have comparability back to the 80s. Its clearly necessary to have 10 different generation of SIMD. Its clearly necessary to have multiple different floating point systems.

[flagged]

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

#93

Post by pjc50 »

panick21_ wrote: post #81
Joker_vD wrote: post #39

Earlier quoted context omitted.

There was such dream. It was about getting the mind-bogglingly simple CPU, put caches into the now empty place where all the control logic used to be, and clock it up the wazoo, and let the software deal with load/branch delays, efficiently using all 64 registers, etc. That'll beat the hell out of those silly CISC architectures at performance, and at the fraction of the design and production costs! This didn't work o…

> This didn't work out ... except it did. You had literal students design chips that outperformed industry cores that took huge teams and huge investment. Acorn had a team of just a few people build a core that outperformed an i460 with likely 1/100 investment. Not to mention the even more expensive VAX chips. Can you imagine how fucking baffled the DEC engineers at the time were when their absurdly complex and absur…

> You had literal students design chips that outperformed industry cores that took huge teams and huge investment

Everyone remember to thank our trans heroine Sophie Wilson (CBE).

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

#94

Post by pjc50 »

foldr wrote: post #27
flanked-evergl wrote: post #25

Earlier quoted context omitted.

If adding more instructions negatively impacts efficiency, performance, cost and complexity, nobody would do it.

Probably 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%20Ge... : • All branches (including the one caused by CALL, below) take place after execution of the following instruction. • The po…

Delay slots were such a hack. ARM never needed them.

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

#95

Post by packetlost »

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…

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

Right, but most of the time those are architecture specific and RVV 1.0 is substantially different than say, NEON or SSE2, so you need to change it anyways. You also typically use specialized registers for those, not the general purpose registers. I'm not saying there isn't work to be done (especially in for an application like this one, that is extremely performance sensitive), I'm saying that most applications won't have these problems are be so sensitive that register spills matter much if at all.

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

#96

Post by bee_rider »

I 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?)

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

#97

Post by tormeh »

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'd assume it uses RADV, same as the Steam Deck. For most workloads that's faster than AMD's own driver. And yes, it uses Wine and DXVK. As dar as the game is concerned it's running on a DirectX-capable x86 Windows machine. That's a lot of translation layers.

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

#98

Post by ben-schaaf »

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.

ARM64 has approximately 1300 instructions.

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

#99

Post by Joker_vD »

vlovich123 wrote: post #90
Joker_vD wrote: post #39

Earlier quoted context omitted.

There was such dream. It was about getting the mind-bogglingly simple CPU, put caches into the now empty place where all the control logic used to be, and clock it up the wazoo, and let the software deal with load/branch delays, efficiently using all 64 registers, etc. That'll beat the hell out of those silly CISC architectures at performance, and at the fraction of the design and production costs! This didn't work o…

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.

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

#100

Post by packetlost »

dzaima wrote: post #84
packetlost wrote: post #83

Earlier quoted context omitted.

It's certainly something I would take into consideration when making a (language) runtime, but probably not at all during all but the most performance sensitive of applications. Certainly a difference, but far lower level than what most applications require

Yep. Unfortunately I am one to be making language runtimes :) It's just the potentially most significant thing I could come up with at first. Though perhaps RVV not being in rva20/rv64gc is more significant.

Looks like an APL project? That's really cool!
Post reply on HN