Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user maak ! (Registered 2024-04-18) You are not logged in - nap
CSDb User Forums


Forums > CSDb Discussions > VICE threaded UI test builds
2020-05-18 16:10
chatGPZ

Registered: Dec 2001
Posts: 11100
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....
 
2020-05-18 23:28
Flavioweb

Registered: Nov 2011
Posts: 442
Distributor ID: openSUSE
Description:    openSUSE Tumbleweed
3D controller: NVIDIA Corporation GM108M [GeForce MX110] (rev a2)
Model name: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz

On Boot:
** (x64sc:25894): WARNING **: 23:23:29.369: AT-SPI: Could not obtain desktop path or name
** (x64sc:25894): WARNING **: 23:23:29.373: AT-SPI: Could not obtain desktop path or name
** (x64sc:25894): WARNING **: 23:23:29.374: atk-bridge: get_device_events_reply: unknown signature
** (x64sc:25894): WARNING **: 23:23:29.374: atk-bridge: get_device_events_reply: unknown signature
** (x64sc:25894): WARNING **: 23:23:29.374: atk-bridge: GetRegisteredEvents returned message with unknown signature
Sound: Opened device `alsa', speed 44100Hz, fragment size 2,9ms, buffer size 101ms
** (x64sc:25894): WARNING **: 23:23:29.378: AT-SPI: Could not obtain desktop path or name
** (x64sc:25894): WARNING **: 23:23:29.378: atk-bridge: get_device_events_reply: unknown signature
** (x64sc:25894): WARNING **: 23:23:29.378: atk-bridge: get_device_events_reply: unknown signature
** (x64sc:25894): WARNING **: 23:23:29.378: atk-bridge: GetRegisteredEvents returned message with unknown signature

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.)
2020-05-19 04:07
dqh

Registered: Jun 2019
Posts: 46
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.
2020-05-19 06:59
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.
2020-05-19 07:15
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.
2020-05-19 07:39
Flavioweb

Registered: Nov 2011
Posts: 442
Quoting dqh
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.

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.
2020-05-19 08:44
dqh

Registered: Jun 2019
Posts: 46
Quoting Flavioweb
Quoting dqh
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.

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.
2020-05-19 08:53
JackAsser

Registered: Jun 2002
Posts: 1987
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.
2020-05-19 08:53
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.
2020-05-19 09:10
dqh

Registered: Jun 2019
Posts: 46
Quoting JackAsser
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.


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.
2020-05-19 11:31
JackAsser

Registered: Jun 2002
Posts: 1987
Quote: Quoting JackAsser
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.


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.
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 17 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Codey/Second Dimension
Andy/AEG
Jucke
iAN CooG/HVSC
St0rmfr0nt/Quantum
Yogibear/Protovision
Alakran_64
Guests online: 66
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 The Ghost  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 It's More Fun to Com..  (9.8)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 Rainbow Connection  (9.5)
6 Wafer Demo  (9.5)
7 TRSAC, Gabber & Pebe..  (9.5)
8 Onscreen 5k  (9.5)
9 Dawnfall V1.1  (9.5)
10 Quadrants  (9.5)
Top Groups
1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Original Suppliers
1 Derbyshire Ram  (9.5)
2 Black Beard  (9.4)
3 hedning  (9.2)
4 Baracuda  (9.1)
5 Irata  (8.5)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.044 sec.