| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
VICE threaded UI test builds
In this thread i will post test builds of the (hopefully) soon to be merged threaded ui rewrite.
Linux and OSX users can always grab the current state from dqh's git repo here: https://github.com/dqh-github/vice-experiments/tree/threaded-ui.. (make sure to checkout the "threaded-ui-exp" branch after cloning the repo)
Please test and report back positive and negative results. Especially interesting right now are rendering errors/problems and unexpected crashes. Please tell exactly what OS you are using, and what GPU.
I will keep posting new windows builds here - starting with todays: https://sourceforge.net/projects/vice-emu/files/experimental%20..
64bit only right now - i'll have to figure out how to build proper 32bit binaries on my box (not that you should be still using a 32bit OS in 2020). |
|
... 149 posts hidden. Click here to view all posts....
|
| |
dqh
Registered: Jun 2019
Posts: 46 |
Quoting Flavioweb
X64sc crash if i open monitor (Alt+h) then try i command like "d" with:
uimon.c:142: Error: lib_debug_guard_size(): Cannot find debug address 0x7f8a000c2df0!
uimon.c:141: Error: lib_debug_guard_remove(): Cannot find debug address 0x7f8a000c2df0! (make sure to use functions from lib.h, do NOT use lib_free on pointers allocated by other functions.)
I hadn't been testing with --enable-debug , it turns out that the memory debug code wasn't thread safe. I have pushed a fix for this, thanks. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Quoting Mr. SID
But it seems that now would be a great time to consider alternatives. But there's no single API for all platforms, so VICE is out of luck.
A single API isn't the problem - in a vacuum it would be simple to write some DirectX or Metal code to get an image on the screen. The problem is that whatever we do needs to integrate with the GTK3 UI around it. OpenGL views are natively supported by GTK3. Once this single threaded to multi threaded conversion is complete and stable, I intend to look at what it would take to hack in a native child window or similar to host a DirectX / Metal view for VICE. It may even be possible for these APIs to attach to the main GTK3 window itself and just be told where to render .. hopefully I find a good option. |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Quoting dqhI hadn't been testing with --enable-debug , it turns out that the memory debug code wasn't thread safe. I have pushed a fix for this, thanks.
Now, during compilation, I get this:lib.c:117:41: error: ‘PTHREAD_RECURSIVE_MUTEX_INITIALIZER’ undeclared here (not in a function); did you mean ‘PTHREAD_MUTEX_INITIALIZER’?
117 | static pthread_mutex_t lib_debug_lock = PTHREAD_RECURSIVE_MUTEX_INITIALIZER;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| PTHREAD_MUTEX_INITIALIZER
compilation terminated due to -Wfatal-errors. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Quoting FlaviowebQuoting dqhI hadn't been testing with --enable-debug , it turns out that the memory debug code wasn't thread safe. I have pushed a fix for this, thanks.
Now, during compilation, I get this:lib.c:117:41: error: ‘PTHREAD_RECURSIVE_MUTEX_INITIALIZER’ undeclared here (not in a function); did you mean ‘PTHREAD_MUTEX_INITIALIZER’?
117 | static pthread_mutex_t lib_debug_lock = PTHREAD_RECURSIVE_MUTEX_INITIALIZER;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| PTHREAD_MUTEX_INITIALIZER
compilation terminated due to -Wfatal-errors.
Ugh, lost my previous reply.
I've pushed a fix for this and a bunch of other issues that were WIP when this thread was posted (i'd stupidly been using this git branch as a conduit between my dev machines, and so it wasn't in a good state)
macOS, Windows, Linux are stable for me at the moment, although I should point out that i don't expect OpenGL to be stable at all as it is running without any locking. As I said - was between sensible places. But i'll fix that soon. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Quoting JackAsser
./configure --enable-native-gtk3ui --enable-embedded
host_vsync_macos.m:30:10: fatal error: 'NSOpenGL.h' file not found
Do you have Xcode installed? What version? Are you following the build instructions at https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/do.. ?
Edit: I just edited those instructions to stop recommending that we disable OpenGL during the build.
I have XCode 11.4.1 (11E503a) running on macOS 10.15.4 (Catalina)
The problem is that NSOpenGL has been deprecated and is now finally removed from AppKit. Since you only use NSOpenGL to acquire the current GL context and change swapInterval you might as well use OpenGL directly (i.e. gl/opengl.h) which still is not removed from MacOS.
However you will need to get the GL context from GTK somehow in this case and then ask for the swapInterval extension and use that instead.
Another way is to skip using OpenGLs mechanisms for vsyncing and instead hook your screen refresh directly to the CVDisplayLink.
Anyway, with the OpenGL code removed I simply got a segfault instead so there is something else broken. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Quoting JackAsser
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8)
[/code]
Any chance you can revert your local changes, git pull the latest code and try again? macOS Builds with no OpenGL support at all now work again.
That said - you should be using OpenGL on macOS now. My primary dev machine is running macOS 10.14 and VICE OpenGL backend is many many times better than the cairo backend, which is slow AF. If you like, you can try a recent (non-threaded) macOS GTK binary with GL support: https://sourceforge.net/projects/vice-emu/files/releases/binari..
If you are building with latest Xcode and they've completely removed the OpenGL headers, then you can install an older Xcode and use xcode-select to pick one. I'm using Xcode 10.3 for various reasons relating to being able to produce working macOS 10.9 binary distributions. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Quoting JackAsserI have XCode 11.4.1 (11E503a) running on macOS 10.15.4 (Catalina)
The problem is that NSOpenGL has been deprecated and is now finally removed from AppKit. Since you only use NSOpenGL to acquire the current GL context and change swapInterval you might as well use OpenGL directly (i.e. gl/opengl.h) which still is not removed from MacOS.
However you will need to get the GL context from GTK somehow in this case and then ask for the swapInterval extension and use that instead.
Another way is to skip using OpenGLs mechanisms for vsyncing and instead hook your screen refresh directly to the CVDisplayLink.
Anyway, with the OpenGL code removed I simply got a segfault instead so there is something else broken.
If the non-NS* openGL stuff is still there, then my latest commit should build for you then. I migrated to using CGL to enable vsync.
Previously I assumed you were building with --disable-hwscale to disable OpenGL but i see how that this wasn't the situation. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Quoting JackAsserI have XCode 11.4.1 (11E503a) running on macOS 10.15.4 (Catalina)
The problem is that NSOpenGL has been deprecated and is now finally removed from AppKit. Since you only use NSOpenGL to acquire the current GL context and change swapInterval you might as well use OpenGL directly (i.e. gl/opengl.h) which still is not removed from MacOS.
However you will need to get the GL context from GTK somehow in this case and then ask for the swapInterval extension and use that instead.
Another way is to skip using OpenGLs mechanisms for vsyncing and instead hook your screen refresh directly to the CVDisplayLink.
Anyway, with the OpenGL code removed I simply got a segfault instead so there is something else broken.
If the non-NS* openGL stuff is still there, then my latest commit should build for you then. I migrated to using CGL to enable vsync.
Previously I assumed you were building with --disable-hwscale to disable OpenGL but i see how that this wasn't the situation.
I can confirm it now builds, but I still get the immediate segfault crash immediatly on launch. I'm investigating as I'm quite sure it has something to do with my setup. |
| |
dqh
Registered: Jun 2019
Posts: 46 |
Quoting JackAsserI can confirm it now builds, but I still get the immediate segfault crash immediatly on launch. I'm investigating as I'm quite sure it has something to do with my setup.
You could build in Xcode and run it in the Xcode debugger - there's doc on how to do it in in doc/building. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Quoting JackAsserI can confirm it now builds, but I still get the immediate segfault crash immediatly on launch. I'm investigating as I'm quite sure it has something to do with my setup.
You could build in Xcode and run it in the Xcode debugger - there's doc on how to do it in in doc/building.
It now works, I had forgotten the initial make install. Thought it wasn't needed since I build my VICE all the time and install them. Will test performance and reports bugs now. :) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 16 - Next |
