> Is anyone actively working on the 3D acceleration?
I implemented "remote" rendering compatible with both exagear and qemu years ago in glshim. glshim+WINE doesn't fully work for me which would probably be a few weeks of work (or pulling some code from gl4es)
It's not that simple.
https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation
Aside from kernel components, the Pyra OS should not be required under the GPL to distribute source for all userspace components unless those components are directly linked to non-exempt GPL components. I'd...
I'm on break from fixing WINE as my last effort on that went toward completely rebuilding remote rendering instead :)
Someone (probably me) just needs to sit down with glshim and WINE and tweak glshim until it passes all the weird initialization checks in WINE.
What was your order of running NOSPAWN/remote? Remember Exagear runs in a chroot so you need to use a path inside there for NOSPAWN and the absolute path for libgl_remote.
If you set up opath you shouldn't need NOSPAWN.
That said, I changed the value of NOSPAWN. It now needs to be a valid file system path (a file will be created by that name), which you also pass into libgl_remote
You don't submit a hash to login. You submit the actual password, so salt won't affect the ability to login to another forum. Per-hash salt just prevents an attacker from using rainbow tables and slows down cracking (because you must crack hashes individually instead of as a group).
Just tagged release 0.42 which has remote rendering included, better synchronization, and all of my wrapping tests pass. If anyone previously playing around with remote rendering could try it again, that would be wonderful.
Don't expect Dolphin or PCSX2, or any other emulator for those platforms to run on the Pyra without some serious work.
Someone might still pull a DraStic out of their hat for either platform (or even something crazy like limited Xbox emulation) and say "look I got HLE and finely tuned JIT in...
You can't use EGL with remote rendering. Only works on GLX right now.
@nighteagle I moved and haven't set up my GLES dev hardware yet so I haven't got a chance to fix this
LIBGL_FB=1 is in theory not necessary anymore btw. You built a libgl_remote binary for ARM and a libGL.so.1 binary for x86 from the same source revision (latest unstable branch), then set up opath so libgl_remote would be executed, correct?
I'm intimately familiar with the inner workings of ZFS. In many workloads increased L1ARC (ZFS RAM cache) will increase read performance of frequently and recently accessed data, but you should also consider having a large L2ARC SSD. As a filesystem, ZFS also has no feelings either way about...