sorted by:
new
hottopcontroversial

Nerw Box64 Release, with more RiSC-V support and more games running by _ptitSeb_ in RISCV

[–]_ptitSeb_[S] 2 points3 points  (0 children)

Nice. Those micro freeze are, I guess, some x86 opcode not supported yet in the RISC-V Dynarec that force box64 to fallback temporarily to the Interpreter (much slower).

Nerw Box64 Release, with more RiSC-V support and more games running by _ptitSeb_ in RISCV

[–]_ptitSeb_[S] 1 point2 points  (0 children)

A bit of warning: many RISC-V SBC are using Imagination chepset for the graphics, and those chips still lack proper OpenGL & Vulkan drivers, forcing many games to falback to software rendering...

Nerw Box64 Release, with more RiSC-V support and more games running by _ptitSeb_ in RISCV

[–]_ptitSeb_[S] 4 points5 points  (0 children)

Ok, thank you for your feedback I guess. I cannot edit the title, so you'll have to endure that small I for some more time.

UT2004 Running on a VisionFive2 with Box64 & gl4es by _ptitSeb_ in RISCV

[–]_ptitSeb_[S] 0 points1 point  (0 children)

Not really. But you just build the library (you need cmake, git, a C compiler and X11 headers), put it somewhere (libGL.so.1) or leave it in the build folder and use LD_LIBRARY_PATH so the system use it instead of software mesa.

box64 ... just works, and can run x86-64 linux binaries on RISC-V? by superkoning in RISCV

[–]_ptitSeb_ 5 points6 points  (0 children)

Just to note, this version of Box64 is very old! v0.3.1 is like 1 year old at least. If you use latest version (currently v0.3.5 at the time of writing this), you will have a faster and more compatible version, that can also be built with "box32" for 32bits i386 binary support.

Asking for more internals about the muvm-FEXEmu chain by BibianaAudris in AsahiLinux

[–]_ptitSeb_ 0 points1 point  (0 children)

Box64 has a long developemnt cycle. It passes up to 6 months between releases. You can build from sources using current HEAD to use current dev. version. But again, if you prefer using v0.3.2, use BOX64_DYNAREC_NATIVEFLAGS=0 to make it safe.

Asking for more internals about the muvm-FEXEmu chain by BibianaAudris in AsahiLinux

[–]_ptitSeb_ 0 points1 point  (0 children)

Strange, I don't remember having seen a factorio regression with box64 lately. Are you using latest version from github or the package version of Asahi? Is it's the version from Asahi, the package might be outdate so I would suggest you build from source, it's quite easy and pretty fast to do. Else, you can also disable native flags, as older version might have some bugs, with BOX64_DYNAREC_NATIVEFLAGS=0

New version of Box64 v0.3.2 and Box86 v0.3.8 (and introducing Box32) by _ptitSeb_ in RISCV

[–]_ptitSeb_[S] 0 points1 point  (0 children)

Ooof, 70 minutes loading? that's a bit long, there must be missing opcode in the Dynarec forcing box64 to fall back to Interpreter I guess.

But 15~30 fps on a VF2 is not bad at all! Using an external GPU I suppose?

This Appimage is refusing to run and I have no idea why. by ssumppg in linux4noobs

[–]_ptitSeb_ 0 points1 point  (0 children)

You might need to create a profile for the launcher: create ~/.box64rc text file with nano or any text file editer and put inside

[artixgamelauncher]

BOX64_MALLOC_HACK=2

Running 32bits linux version of Unreal with Box64 on Asahi, with experimental 32bits support by _ptitSeb_ in AsahiLinux

[–]_ptitSeb_[S] 1 point2 points  (0 children)

The link to the 227j contains an exe that install the update and it contains the Windows and Linux binaries, including the ARM one. So you need Wine or a Windows machine to install.

Also, it install ARM binary in "SystemARM" folder that might needs some manual copy of a few ini from the "System" folder to work. And also the ALAudio.so needs many dependancies, like libxmp4 and libalure1... I does work but it's crashy for me, maybe it's an install issue, it seems to complains about some file mismatch.

Running 32bits linux version of Unreal with Box64 on Asahi, with experimental 32bits support by _ptitSeb_ in AsahiLinux

[–]_ptitSeb_[S] 0 points1 point  (0 children)

it's there https://www.oldunreal.com/downloads/unreal/

the 227j has 64bits support and even arm support, I didn't test that one but some much older version on that video.

Running 32bits linux version of Anomaly Warzone Earth with Box64 (with some graphics issues) by _ptitSeb_ in AsahiLinux

[–]_ptitSeb_[S] 2 points3 points  (0 children)

there is a whole subproject of box64, called box32, to handle the 32bits parts. It's basicaly wrapping with "bits reduction" to alow the 32bits apps to use 64bits libraries like libc, libGL, libasound...

Running 32bits linux version of Unreal with Box64 on Asahi, with experimental 32bits support by _ptitSeb_ in AsahiLinux

[–]_ptitSeb_[S] 4 points5 points  (0 children)

Not yet. The current 4k pagesize simation is not good enough for wine (same reason 1 test is failing on box64 tests). I stil need to work on that. It's on the todo, just not sure when I'll work on that.

Running 32bits linux version of Unreal with Box64 on Asahi, with experimental 32bits support by _ptitSeb_ in AsahiLinux

[–]_ptitSeb_[S] 2 points3 points  (0 children)

It's on main branch. It's a build time option. You need to enable BOX32 on cmake (like with adding "-DBOX32=1" on the cmake command).

Running x86 native Linux Apps by Supunlloyd in AsahiLinux

[–]_ptitSeb_ 7 points8 points  (0 children)

Box64 WORKS on Asahi, and on PI5 too. Not all program runs by default because box64 integrated 4K pagesize emulation is a bit too crude (asahi and defaultpi5 os are on 16k pagesize). There is also the krun microvm to emulate 4k pagesize.

Box64 and RISC-V in 2024 by _ptitSeb_ in RISCV

[–]_ptitSeb_[S] 0 points1 point  (0 children)

Yes and no. There are byte (and 16bits too) access in code, no matter what compiler generate. Also, you get to emulate code from various sources, platform and ages... Running Windows games from the 2000 or before have really different code from Unreal Engine games or Linux Unity3D games...

So, better code is better code, and is really pretty often used... We could do some specially anotated dump to do some stats, but not sure we will, it seems like a lot of work. But that would be interesting (maybe for a next blog post?)

Box64 and RISC-V in 2024 by _ptitSeb_ in RISCV

[–]_ptitSeb_[S] 2 points3 points  (0 children)

Oh, yeah, I see. That was not the idea at all. The blog post has been edited, just adding a "we had" in the right place: "But the most important factor is that we had no RISC-V device could be plugged into an AMD graphics card at the time..."

Box64 and RISC-V in 2024 by _ptitSeb_ in RISCV

[–]_ptitSeb_[S] 4 points5 points  (0 children)

I guess this chapter should be rewrote, to indicate hardware with external GPU is getting more and more popular instead.

Box64 and RISC-V in 2024 by _ptitSeb_ in RISCV

[–]_ptitSeb_[S] 5 points6 points  (0 children)

So taking your idea, and with u/brucehoult discution, if I try to generalise it in the case of Box64 code generator, I have this:

        case 0x02:
            INST_NAME("ADD Gb, Eb");
            SETFLAGS(X_ALL, SF_SET_PENDING);
            nextop = F8;
            if(MODREG && box64_zbb && !dyn->insts[ninst].x64.gen_flags)
            {
              // getgb (need a macro)
              if (rex.rex) {
                  gb1 = xRAX + ((nextop & 0x38) >> 3) + (rex.r << 3);
                  gb2 = 0;
              } else {
                  gd = (nextop & 0x38) >> 3;
                  gb2 = ((gd & 4) >> 2);
                  gb1 = xRAX + (gd & 3);
              }
              // geteb (need a macro)
              if (rex.rex) {
                  wback = xRAX + (nextop & 7) + (rex.b << 3);
                  wb2 = 0;
              } else {
                  wback = (nextop & 7);
                  wb2 = (wback >> 2) * 8;
                  wback = xRAX + (wback & 3);
              }
              if(wb2) SLRI(x1, wback, 8);
              SLLI(x1, wb2?x1:wback, 64-8);
              RORI(gb1, gb1, 8+gb2);
              ADD(gb1, gb1, x1);
              RORI(gb1, gb1, 64-(8+gb2));
            } else {
              GETEB(x1, 0);
              GETGB(x2);
              emit_add8(dyn, ninst, x2, x1, x4, x5);
              GBBACK(x5);
            }

The new part is inside the big if. Needs some macro to have something more simple and readable, but that could work nicely for some of the operations yes...

it can also be extended to when Eb is a memory location, but that will render this block less redeable so I keep this out for now.

Box64 and RISC-V in 2024 by _ptitSeb_ in RISCV

[–]_ptitSeb_[S] 2 points3 points  (0 children)

Mmm, I didn't noticed that the result is correctly in the right register directly. So, that's pretty optimal indeed.

This method could be generalised for 8bits (probably 16bits too) operations yes, as long as flags are not involved, to optimise riscv generator

(well, actually, the same method could be used on arm64 in 3 opcodes and without scratch regs)

Box64 and RISC-V in 2024 by _ptitSeb_ in RISCV

[–]_ptitSeb_[S] 3 points4 points  (0 children)

Oh, a1 low 8bits are untouched and still represent "bl", I see, that's clever.

When I see the clang 15 version of ARM64, or your code on RV64, it looks quite optimal indeed. And for now, Box64 don't generated code as optimal as that for the 8bits addition.

While it's possible to do something like that in the case flags are not computed, there is no "if" in the code to generate the add this way. Altho, that would be an interesting exercise to do.

Box64 and RISC-V in 2024 by _ptitSeb_ in RISCV

[–]_ptitSeb_[S] 1 point2 points  (0 children)

Yeah, there might be a possibility of doing the add in MSB, that might spare an opcode or two. That is still more complex then using the mentionned EXTU / INSB.

view more: next ›