Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
PCSX2 + Lua Development - Question with thread model
#1
I think this topic is more suitable for Developer Discussion, but I'm posting it here since I was unable to create new thread in the developer forum.

Hi. I am a coder who interested in adding TAS capabilities to PCSX2 emulator.

A half year ago, I have implemented the very basic of Lua scripting engine.
https://github.com/gocha/pcsx2/tree/lua-v1.4.0
Edit: See https://github.com/gocha/pcsx2 instead (Mar 4, 2018)

TASVideos / Lua Scripting
http://tasvideos.org/LuaScripting.html

However, my motivation was lost rapidly since I was stuck in a problem.
The problem is thread model between the emulation core and Lua.

TASVideos emulators I know are single-thread, that can be achieved so naturally, but PCSX2 is a multi-thread emulator. Since I am not very familier with PCSX2 and its internal models, I have no idea how I should handle the communication between Lua and the emulation core (or how to integrate the Lua interpreter to the core thread).

Script will run:
  1. When UI (or whatever a trigger) requests starting the script, the script will run immediately.
  2. When a script has registered some callbacks on step #1, they will be called by certain triggers. (e.g. on frame boundary, memory read, etc.)
  3. Additionally, most of TASVideos emulators have a co-routine style function: emu.frameadvance(). The function will stop the script execution temporary, then emulate the game for only 1 frame, then resume the script after the function call.
At present, my prototype can start a script from GUI, then the script will be executed on the UI thread. Of course, the emulation keeps running asynchronously while the script is running.

I would be happy if someone teaches me an easy and smart idea for this or any hints. Moreover, I will be more happy if someone would code the rest of things. Thank you.
Reply

Sponsored links

#2
Hey man, not sure if you are aware of the somewhat-recent updating of the old PCSX2-RR emulator, but it appears to have similar Lua functionality.  This is the most updated fork of it https://github.com/DocSkellington/pcsx2-1.4.0-rr and DocSkellington appears to have made a handful of changes to Lua specific problems.  I'm not sure if they address your particular problems but maybe it might help you out.
Reply
#3
@xtvaser
Thanks for your info. I will have a look when I have a free time.
Reply
#4
For the threads

Basically you have
* GUI
* EE dynarec recompiler include IOP/VU0/plugins. If no MTVU1
* if MTVU, a dedicated thread for VU1
* a thread for GS/GPU rendering

I don't know if it can help you, but there is a VSYNC/counter info on the EE thread.
Reply
#5
OH GOWD
This smells exactly what I had in mind for

https://github.com/PCSX2/pcsx2/issues/1923
EDIT: https://en.wikipedia.org/wiki/List_of_pr...bject_code
Lua is certainly good and all (also, pretty much the standard for TAS).
But did anybody ever looked at AngelScript,Squirrel or GameMonkey?
Reply
#6
@gregory Thank you. I have confirmed my understanding and I haven't known there are MTVU threads.

A year has passed from when I wrote the initial Lua code. I faced to pcsx2 code again a few days ago, then I noticed there are some misunderstanding on my pcsx2 thread knowledges, and I made a possible answer by myself.

So what thread the Lua VM should run on?
  • Main (GUI) thread: No. I think lua script shouldn't block GUI responsibility.
  • Core (EE) thread: Probably no, because it's not a part of EE. (Note: The thread basically should be paused while a lua script is running, but a script sometimes requires to unpause emulation. Other threads can pause the core thread via Pause() method by the way, I guess most of developers already know that, though.)
  • Executor thread: I had thought this is the exact thread for lua, but I don't think so now. If I understand correctly, the thread processes queued tasks one by one. If lua ran on this thread, it would be harder to execute nested slow task (making a savestate, for example)
My final answer is having its own thread for each lua VMs. It will require some advanced implementation, such as thread-safe lua engine, communication with main thread for GUI update, pause/unpause core thread for non-volatile execution, and so on.

Thank you for reading and all the responses.
Reply




Users browsing this thread: 1 Guest(s)