Dolphin, the GameCube and Wii emulator - Forums

Pages: 1 2 3 4 5

(03-27-2018, 09:43 PM)degasus Wrote: [ -> ]Sorry for double post, but I was asked for a better screenshot: May you run any VC game (eg Ocarina of Time) and make a screenshot with the outer operation system? I think of a x64 -> arm -> ppc -> mips interpreter chain

I had another problem to solve before i could upload an OOT screenshot, namely the only available input driver (Xinput) does not support keyboards but only controller, so i could not pass the start screen. I did add keyboard support to the Xinput driver and finally could start the game - i guess having keyboard support for Xinput is not the worst idea anyway.

So here we go MIPS->PPC->ARM64->x64
image0
image1

(03-29-2018, 02:24 AM)Gerdya Wrote: [ -> ]I had another problem to solve before i could upload an OOT screenshot, namely the only available input driver (Xinput) does not support keyboards but only controller, so i could not pass the start screen. I did add keyboard support to the Xinput driver and finally could start the game - i guess having keyboard support for Xinput is not the worst idea anyway.

So here we go MIPS->PPC->ARM64->x64
image0
image1

Oh nice. You've made my day. Feel free to create PRs for such patches. About your JIT issue, just revert https://github.com/dolphin-emu/dolphin/pull/4204 and it may work. Our libc cache invalidation was broken on Exynos as they have different cache line sizes on the big/little cluster.

(03-29-2018, 05:08 PM)degasus Wrote: [ -> ]Oh nice. You've made my day. Feel free to create PRs for such patches. About your JIT issue, just revert https://github.com/dolphin-emu/dolphin/pull/4204 and it may work. Our libc cache invalidation was broken on Exynos as they have different cache line sizes on the big/little cluster.

I did make an assembly implementation for flush. It should reflect pretty much the C/intrinsic version (unless i made a mistake).

Code:

    EXPORT    |_FlushIcacheSection|

    AREA    |.text$mn|, CODE, ARM64

|_FlushIcacheSection| PROC

    mrs   x3, CTR_EL0                            ;x3 = ctr_el0

    mov   x5, #4

    mov   x6, #0xf

    and   x4, x3, x6                        

    lsl   x4, x5, x4                            ; isize = 4 << ((ctr_el0 >> 0) & 0xf) -> x4

    and   x3, x6, x3, lsr #16

    lsl   x3, x5, x3                            ; dsize = 4 << ((ctr_el0 >> 16) & 0xf) -> x3

    sub   x5, x31, x3

    and   x6, x0, x5                            ; addr = (u64)start & ~(u64)(dsize - 1);

dcache

    dc    civac, x6

    add   x6, x6, x3                            ; addr += dsize

    cmp   x6, x1

    blt   dcache                                    ; addr < end

    dsb   ish

    sub   x5, x31, x4

    and   x6, x0, x5                            ; addr = (u64)start & ~(u64)(isize - 1);

icache

    ic    ivau, x6

    add   x6, x6, x4                            ; addr += isize

    cmp   x6, x1                                    

    blt   icache                                    ; addr < end

    dsb   ish

    isb

    ret 

    ENDP  ; |_FlushIcacheSection|

    END

It does ask for both cache lines size of I$ and D$ via CTR_EL0.
And then modified ARM64XEmitter:

Code:

void ARM64XEmitter::FlushIcacheSection(u8* start, u8* end)

{

  if (start == end)

    return;

#if defined(IOS)

  // Header file says this is equivalent to: sys_icache_invalidate(start, end - start);

  sys_cache_control(kCacheFunctionPrepareForExecution, start, end - start);

#elif defined _MSC_VER

  //MSC does not support inline assembly for ARM64

  //instead an assembly implementation in Arm64Emitter_util.asm is called

  _FlushIcacheSection(start, end);

#else

But i still get a Bluescreen when enabling JIT. Well i need to wait for device since debugging with QEmu is not possible at the moment.

(03-29-2018, 08:24 PM)Gerdya Wrote: [ -> ]But i still get a Bluescreen when enabling JIT. Well i need to wait for device since debugging with QEmu is not possible at the moment.

I fear you don't need to debug this kind of issue. An application must not be able to trigger a blue screen :/

Through it might be a qemu bug as well.

Might you try to drop W18 here: https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/Core/PowerPC/JitArm64/JitArm64_RegCache.cpp#L323
It might be used as some kind of plattform register.

Hey, nice to hear of an ARM64 port in development! Smile

I have the first ever Arm64 laptop - HP Envy x2 - so let me know if you need me to test anything... gilius2k15@gmail.com

Good luck with the project!

(03-27-2018, 09:43 PM)degasus Wrote: [ -> ]Sorry for double post, but I was asked for a better screenshot: May you run any VC game (eg Ocarina of Time) and make a screenshot with the outer operation system? I think of a x64 -> arm -> ppc -> mips interpreter chain

I read that last bit and became excite.

Few updates. I finally got an HP Envy X2. Unfortunately the emulator crashes as soon as a load an ISO. The added keyboard support for the XInput driver does work though - i can configure keyboard and controller with this single driver - i did test it with XBox360 controller connected via USB.
Since it is running on QEMU i do not expect some big issues.

However i did not figure out how to remote debug the device with Visual Studio. Typically for remote debugging i need to install the remote debug tools on the device, but i have not found a version for ARM64.

So any ideas or pointers are appreciated!

(04-24-2018, 04:27 AM)Gerdya Wrote: [ -> ]Few updates. I finally got an HP Envy X2. Unfortunately the emulator crashes as soon as a load an ISO.

Which configuration have you used? Interpreter, software renderer, D3D reference renderer, null video, ... ?

(04-24-2018, 06:05 AM)degasus Wrote: [ -> ]Which configuration have you used? Interpreter, software renderer, D3D reference renderer, null video, ... ?

On QEmu (where all interpreter modes work) i did use D3D reference renderer and no sound output.
On the HP Envy X2 i did test all Interpreter modes in conjunction with the Qualcomm D3D driver.

Are there options to enable tracing/logging to see at least how far we get?

If we assume that their D3D shader compiler is about the same quality as their GLSL compiler, you should try the software drivers as well.

Pages: 1 2 3 4 5