| Age | Commit message (Collapse) | Author |
|---|
|
|
|
for now (lightrec crashes at startup)
|
|
Requires the impl. of the rw/rx patches first
|
|
|
|
|
|
|
|
|
|
|
|
Allow threaded rendering for peops and enable on unix
|
|
|
|
By default, iOS are built with either DYNAREC=ari64 or DYNAREC=lightrec, with lightrec used as an override flag to build the interpreter instead, which is DYNAREC=0.
This PR removes DYNAREC?=ari64 which seems to block the overrides from working.
Hopefully...:
|
|
This change adds a gpulib implementation that accepts GPU commands and
runs them through a real gpulib implementation on a thread. Depending
on a setting, it can either force a sync every frame, or continue to
work until the next frame arrives.
|
|
|
|
|
|
|
|
|
|
|
|
After the dynarec writes new instructions, it has to flush the
instruction and data caches. Some of these flush operations are
privileged on the 3DS, so the clear cache functions have to run
through svcBackdoor. The Nintendo implementation (and CFW
reimplementation) of svcBackdoor has a problem where interrupts and
context switches will cause crashes.
Even though we can disable interrupts in the flush function, there's
still a window of time between svcBackdoor being called and the
function being run where an interrupt will corrupt the stack.
Luma3DS implemements a svcCustomBackdoor call we can use that also
runs a function in supervisor mode, but uses an implementation that
avoids this problem.
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
|
|
|
|
I don't know what build errors were happening before, but this built
cleanly for me.
|
|
It now builds properly, and is much much faster.
|
|
|
|
|
|
- all platforms compiles with CHD support.
- compile with HAVE_CHD=0 for no chd support.
- CHD fails building for 3DS, not sure its even fast enough for the device. I tried asking in discord channel but haven't got reply. Disabling it till someone familiar with 3ds can fix it.
http://p.0bl.net/123458
|
|
* Committer: Wes Smith <wraith@smithmedia.wraithbox.com>
On branch master
Your branch is up to date with 'origin/master'.
Changes to be committed:
modified: Makefile.libretro
Added v8a35 to Makefile
* modified makefile with libretro changes
* New makefile format from libretro
* Updated with PSClassic Make again
* Updated PSC config
* Fix compile flags
Re-add optimizations, -mtune
|
|
* Committer: Wes Smith <wraith@smithmedia.wraithbox.com>
On branch master
Your branch is up to date with 'origin/master'.
Changes to be committed:
modified: Makefile.libretro
Added v8a35 to Makefile
* modified makefile with libretro changes
* New makefile format from libretro
* Updated with PSClassic Make again
* Updated PSC config
|
|
The recompiler can't handle Thumb instructions, so they must be disabled.
This is accomplished via the `-marm` flag being set for different platforms.
However, when using `platform=unix` and manually configuring the build,
the check for Thumb instructions is not done in `Makefile.libretro`.
Therefore, when building with a compiler that defaults to Thumb instructions
(e.g. ODROID-XU4), the build can fail with this error:
libpcsxcore/new_dynarec/backends/psx/pcsxmem.c:18:2: error:
#error the dynarec is incompatible with Thumb functions,
libpcsxcore/new_dynarec/backends/psx/pcsxmem.c:19:2: error:
#error please add -marm to compile flags
To address this, we simply backport the define check from the configure script
for when we build with `ARCH=arm`. This change doesn't affect the buildbot.
|
|
Large file support is not enabled in `Makefile.libretro`, therefore when loading
large PBP files you might get "Value too large" errors in some 32-bits systems
such as the Raspberry Pi. For example:
Could't open 'Final Fantasy VIII (USA).pbp' for reading: Value too large
for defined data type
Error opening CD-ROM plugin!
|
|
* Made DEBUG and WANT_ZLIB variables configurable from make parameters
* Removed duplicate block of code near the end of the Makefile
* Matched formatting style with the rest of the Makefile
* Changed spaces to tabs for consistency with the rest of the Makefile
|
|
* Default to `HAVE_NEON=0` until the `platform` is checked for `neon`
* Fixes build with `platform=armv` alone (no NEON requested) in a NEON
device where the autodetection using `$(CC) -E -dD` will enable it
|
|
it keeps breaking 3DS compilation on the buildbot.
|
|
- As per request for performance testing sacrificing quality
|
|
- similar to IOS build fix
|
|
related: https://github.com/libretro/libretro-super/issues/976
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
