Natywny build MacOS

[piopawlu]

Jeżeli ktoś byłby zainteresowany to przygotowałem natywny build MacOS najnowszej znanej mi wersji kodu (na bazie brancha sim od @Milek7).
Build ten oparty jest na bibliotekach statycznych więc nie wymaga instalowania niczego za pomocą homebrew. Dodatkowo naprawiona została obsługa myszy dla monitorów retina. Build jest przygotowany dla wersji systemu BigSur 11.1, ale jeżeli jest taka potrzeba to mogę zbudować dla jakiegoś starszego wydania.

Binarka:
http://piopawlu.net/tmp/maszyna/macos/eu07_210108.bz

Mój branch z poprawkami dla MacOS można znaleźć tutaj:
https://github.com/piopawlu/maszyna/tree/MacOSNativeFixes

Do budowania statycznego używam zmodyfikowanego pliku CMakeLists którego aktualnie nie wrzucam do repozytorium bo popsuje pozostałe buildy jeżeli nie nawrzucam drabinek if/else.

Pozdrawiam,
Piotr

[wedkarz]

Byłbyś w stanie jakoś pomóc w uruchomieniu na maku?
Udało mi się skompilować (korzystając z definicji w pipeline'ach azurowych).
Pozostałe pliki ściągnąłem z torrenta (nie widzę innej opcji do ściągnięcia zasobów a plik exe z instalką nie za bardzo zadziała maku).
Przy uruchomieniu jest jednak problem: Bad init: failed to create glfw window
Oczywiście OpenGL na maku to problem:

Kod: [Zaznacz]

OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: AMD Radeon Pro 560X OpenGL Engine
OpenGL version string: 2.1 ATI-4.6.20
Jest szansa, żeby to działało?
Druga kwestia, jak ustawić środowisko, żeby dało się debugować aplikację?

[Stele]

Bez OGL 3.3 nie ruszy bo gui wymaga.

[Hubertnator23]

Musiałbyś skompilować sam plik exe, ustawiając flagę DUSE_IMGUI_GL3=OFF, wtedy legacy powinno zadziałać na OpenGL 2.0. Nie wiem na ile stabilne :v

[wedkarz]

Z kompilacją nie ma jakichś większych problemów.
Używałem proponowanej przez ciebie flagi. Wziąłem w całości to co jest w definicji pipelien'a:

Kod: [Zaznacz]

cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_OSX_ARCHITECTURES=x86_64 -DCMAKE_TOOLCHAIN_FILE=/tmp/vcpkg/scripts/buildsystems/vcpkg.cmake -DVCPKG_TARGET_TRIPLET=x64-osx -DWITH_ZMQ=OFF -DWITH_OPENVR=OFF -DWITH_UART=OFF -DUSE_IMGUI_GL3=OFF -DUSE_LTO=ON
źródło: https://github.com/eu07/maszyna/blob/master/azure-pipelines.yml

Niestety nadal przy uruchomieniu mam Bad init: failed to create glfw window.
Podebugowałbym, może coś by się wyjaśniło ale potrzebuję wsparcia przy konfiguracji projektu.

[Czarodziej]

Dobry wieczór, odgrzewam kotleta.
Rewizja 98050176 (najnowsza z oficjalnego GitHuba Maszyny, o ile można tak to nazwać).
Buduję tak:

Kod: [Zaznacz]

build % cmake -DWITH_LUA=false -DWITH_OPENVR=false -DCMAKE_BUILD_TYPE=Release -DPYTHON_LIBRARY=$(python-config --prefix)/lib/libpython2.7.a -DPYTHON_INCLUDE_DIRS=$(python-config --prefix)/include/python2.7 -DOPENAL_INCLUDE_DIR=/opt/homebrew/Cellar/openal-soft/1.22.2/include -DOPENAL_LIBRARY=/opt/homebrew/Cellar/openal-soft/1.22.2/lib/libopenal.dylib ..
make -j20Kompilator: Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: arm64-apple-darwin21.5.0
Zależności dla cmake zainstalowałem z homebrew.
Starożytnego pythona 2.7 zainstalowałem pyenvem, skopiowałem do katalogu z grą i nazwałem macpython64. Symulator się o dziwo uruchamia, FPS jak na kalkulatorze, od 7 do 12. Załączam logi z uruchomienia toru testowego i Zwierzyńca. Poważniejszych nawet nie próbowałem.

[Milek7]

Nie zainstalowałeś pillow do katalogu pythona, nie będą ci działać ekrany.
Co do wydajności niestety renderer shaderowy jakoś się gryzie z tą implementacją OpenGL. Na legacy jest dużo lepiej, ale żeby legacy się odpaliło musisz mieć nowszą wersję.
Najnowsza wersja jest tu: https://github.com/Milek7/maszyna/tree/sim
Na azure budują się też binarki, myślę że też powinny działać.

[Czarodziej]

Rzeczywiscie, na legacy z twojej gałęzi włącza się, jest dużo FPS, ale wszystko jest czarne. Dasz link do buildów na Azure?

-- Edit
Po zainstalowaniu Pillow dostaję segfault

Kod: [Zaznacz]

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process:               eu07mac.exe [92801]
Path:                  /Users/USER/*/eu07mac.exe
Identifier:            eu07mac.exe
Version:               ???
Code Type:             ARM-64 (Native)
Parent Process:        launchd [1]
Responsible:           Terminal [28384]
User ID:               501

Date/Time:             2022-07-06 13:13:51.2257 +0200
OS Version:            macOS 12.4 (21F79)
Report Version:        12
Anonymous UUID:        CD285B66-886C-7E9B-3D5A-DE9D1255DD4A

Sleep/Wake UUID:       AFCA71DD-5CA5-4BFA-81D5-B32965CA0502

Time Awake Since Boot: 64000 seconds
Time Since Wake:       7805 seconds

System Integrity Protection: enabled

Crashed Thread:        6

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Codes:       0x0000000000000001, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process:   exc handler [92801]

VM Region Info: 0 is not in any region.  Bytes before following region: 4294967296
      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
---> 
      __TEXT                      100000000-100494000    [ 4688K] r-x/r-x SM=COW  ...*/eu07mac.exe

Thread 0::  Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib               0x182556a90 __write_nocancel + 8
1   libsystem_c.dylib                     0x1824845b0 __swrite + 24
2   libsystem_c.dylib                     0x182463444 _swrite + 108
3   libsystem_c.dylib                     0x18246156c __sflush + 232
4   libsystem_c.dylib                     0x18246140c fflush + 36
5   libc++.1.dylib                       0x1824fd958 std::__1::basic_filebuf<char, std::__1::char_traits<char> >::sync() + 328
6   libc++.1.dylib                       0x1824ee324 std::__1::basic_ostream<char, std::__1::char_traits<char> >::flush() + 144
7   eu07mac.exe                           0x1000e7d28 WriteLog(char const*, logtype) + 528
8   eu07mac.exe                           0x1000cbe00 event_manager::AddToQuery(basic_event*, TDynamicObject const*, double) + 384
9   eu07mac.exe                           0x1000cbb94 multi_event::run_() + 116
10  eu07mac.exe                           0x1000c55f0 basic_event::run() + 272
11  eu07mac.exe                           0x1000d292c event_manager::update() + 176
12  eu07mac.exe                           0x1001c1308 driver_mode::update() + 884
13  eu07mac.exe                           0x1001ba610 eu07_application::run() + 696
14  eu07mac.exe                           0x1000c182c main + 328
15  dyld                                 0x10067108c start + 520

Thread 1:
0   libsystem_pthread.dylib               0x18258b078 start_wqthread + 0

Thread 2:
0   libsystem_pthread.dylib               0x18258b078 start_wqthread + 0

Thread 3:: com.apple.NSEventThread
0   libsystem_kernel.dylib               0x1825528b0 mach_msg_trap + 8
1   libsystem_kernel.dylib               0x182552d20 mach_msg + 76
2   CoreFoundation                       0x18265d2b0 __CFRunLoopServiceMachPort + 372
3   CoreFoundation                       0x18265b760 __CFRunLoopRun + 1180
4   CoreFoundation                       0x18265ab24 CFRunLoopRunSpecific + 600
5   AppKit                               0x18532e374 _NSEventThread + 196
6   libsystem_pthread.dylib               0x18259026c _pthread_start + 148
7   libsystem_pthread.dylib               0x18258b08c thread_start + 8

Thread 4:: AMCP Logging Spool
0   libsystem_kernel.dylib               0x1825528ec semaphore_wait_trap + 8
1   caulk                                 0x18affea2c caulk::mach::semaphore::wait_or_error() + 28
2   caulk                                 0x18afe27ac caulk::concurrent::details::worker_thread::run() + 56
3   caulk                                 0x18afe23cc void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::*)(), std::__1::tuple<caulk::concurrent::details::worker_thread*> > >(void*) + 96
4   libsystem_pthread.dylib               0x18259026c _pthread_start + 148
5   libsystem_pthread.dylib               0x18258b08c thread_start + 8

Thread 5:: com.apple.audio.IOThread.client
0   libsystem_kernel.dylib               0x1825528b0 mach_msg_trap + 8
1   libsystem_kernel.dylib               0x182552d20 mach_msg + 76
2   CoreAudio                             0x1842a1ef4 HALB_MachPort::SendSimpleMessageWithSimpleReply(unsigned int, unsigned int, int, int&, bool, unsigned int) + 104
3   CoreAudio                             0x18412f238 HALC_ProxyIOContext::IOWorkLoop() + 3396
4   CoreAudio                             0x18412defc invocation function for block in HALC_ProxyIOContext::HALC_ProxyIOContext(unsigned int, unsigned int) + 100
5   CoreAudio                             0x1842fa304 HALB_IOThread::Entry(void*) + 88
6   libsystem_pthread.dylib               0x18259026c _pthread_start + 148
7   libsystem_pthread.dylib               0x18258b08c thread_start + 8

Thread 6 Crashed:
0   ???                                           0x0 ???
1   eu07mac.exe                           0x10015679c python_taskqueue::run(GLFWwindow*, threading::lockable<std::__1::deque<render_task*, std::__1::allocator<render_task*> > >&, threading::lockable<std::__1::deque<render_task*, std::__1::allocator<render_task*> > >&, threading::condition_variable&, std::__1::atomic<bool>&) + 332
2   eu07mac.exe                           0x100157ed0 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (python_taskqueue::*)(GLFWwindow*, threading::lockable<std::__1::deque<render_task*, std::__1::allocator<render_task*> > >&, threading::lockable<std::__1::deque<render_task*, std::__1::allocator<render_task*> > >&, threading::condition_variable&, std::__1::atomic<bool>&), python_taskqueue*, GLFWwindow*, std::__1::reference_wrapper<threading::lockable<std::__1::deque<render_task*, std::__1::allocator<render_task*> > > >, std::__1::reference_wrapper<threading::lockable<std::__1::deque<render_task*, std::__1::allocator<render_task*> > > >, std::__1::reference_wrapper<threading::condition_variable>, std::__1::reference_wrapper<std::__1::atomic<bool> > > >(void*) + 72
3   libsystem_pthread.dylib               0x18259026c _pthread_start + 148
4   libsystem_pthread.dylib               0x18258b08c thread_start + 8

Thread 7:
0   libsystem_pthread.dylib               0x18258b078 start_wqthread + 0


Thread 6 crashed with ARM Thread State (64-bit):
    x0: 0x0000000000000de1   x1: 0x0000000000000de1   x2: 0x0000000000002801   x3: 0x00000001701ceefc
    x4: 0x0000000000000001   x5: 0x0000000000000020   x6: 0x00000001701ced2c   x7: 0x00000001701ced24
    x8: 0x0000000000000000   x9: 0x0000000000002703  x10: 0x000000000000000a  x11: 0x000000000000000f
   x12: 0x0000000000000058  x13: 0x0000000000000001  x14: 0xffffffffffffffff  x15: 0x0000000000000000
   x16: 0x00000001e3e8c4bc  x17: 0x00000001e3e8c158  x18: 0x0000000000000000  x19: 0x00006000003aa440
   x20: 0x00000001004e0198  x21: 0x00000001004e3648  x22: 0x00000001004e35d8  x23: 0x0000000100ca9770
   x24: 0x00000001004e3510  x25: 0x0000600003508160  x26: 0x00000001004e3678  x27: 0x00000001004e3608
   x28: 0x00006000003aa440   fp: 0x00000001701cef30   lr: 0x0000000100155cfc
    sp: 0x00000001701cef10   pc: 0x0000000000000000 cpsr: 0x60001000
   far: 0x0000000000000000  esr: 0x82000006 (Instruction Abort) Translation fault
-- ciach ---

-- Edit 2
Wygląda na to, że przez chwilę obraz wygląda w miarę normalnie, a po chwili wszystko robi się ciemne, czarne.

-- Edit 3
I dzieje się tak dlatego, że jakaś lokomotywa na scenerii włącza jakiekolwiek światło. W załącznikach ten efekt na torze testowym.
Da się coś z tym zrobić?

-- Edit 4
Znalazłem Azure: https://dev.azure.com/milek7/maszyna/_build, exe stamtąd nie działa, mam aktualnego macOSa, Apple już jakiś czas temu usunęło Pythona 2.7 z systemu

Kod: [Zaznacz]

dyld[59793]: Library not loaded: /System/Library/Frameworks/Python.framework/Versions/2.7/Python
  Referenced from: /Volumes/Samsung_T5/gry/MaSzyna/eu07milek.exe
  Reason: tried: '/System/Library/Frameworks/Python.framework/Versions/2.7/Python' (no such file), '/Library/Frameworks/Python.framework/Versions/2.7/Python' (no such file)

[Milek7]

Hmm. To znowu jakiś problem z GLem, podobnie jak bywało na intelach.

Zrobiłem zmiany:
Dodałem parametr do wyłączania pythona przy kompilacji, żeby nie przeszkadzał przy testach.
Dozwolona jest wartość 0 dla parametru dynamiclights. Świateł nie ma, ale chociaż tyle że nie ma ciemnicy.

[Czarodziej]

Dziękuję. Dałem na 0 i nie zapada zmrok po włączeniu świateł. Zmiana z Pythonem jest chyba zbędna, nie doprecyzowałem, że tak się zaczęło robić, jak doinstalowałem Pillow. Zmieniłem tymczasowo nazwę modułu i nie ma segfaulta. Jak będę miał nieco więcej czasu, to spróbuję przejechać jakiś większy scenariusz i zobaczę, jak się w ogóle to exe sprawuje.

Czy istnieje jakakolwiek szansa na znalezienie problemu z wydajnością na kartach innych niż NVidia? Trochę przeszukałem forum i ludzie z całkiem poważnymi Radeonami też narzekają na wydajność i jeżdżą na "legacy".

-- Edit
No nie wyszło najlepiej :D

Kod: [Zaznacz]

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   eu07mac.exe                           0x1001617e4 audio::openal_source& audio::openal_source::bind<std::__1::__wrap_iter<unsigned long*> >(sound_source*, std::__1::vector<unsigned int, std::__1::allocator<unsigned int> >, std::__1::__wrap_iter<unsigned long*>, std::__1::__wrap_iter<unsigned long*>) + 408
1   eu07mac.exe                           0x1001617cc audio::openal_source& audio::openal_source::bind<std::__1::__wrap_iter<unsigned long*> >(sound_source*, std::__1::vector<unsigned int, std::__1::allocator<unsigned int> >, std::__1::__wrap_iter<unsigned long*>, std::__1::__wrap_iter<unsigned long*>) + 384
2   eu07mac.exe                           0x10016145c void audio::openal_renderer::insert<std::__1::__wrap_iter<unsigned long*> >(std::__1::__wrap_iter<unsigned long*>, std::__1::__wrap_iter<unsigned long*>, sound_source*, std::__1::vector<unsigned int, std::__1::allocator<unsigned int> >) + 152
3   eu07mac.exe                           0x10015e59c void sound_source::insert<std::__1::__wrap_iter<unsigned int*> >(std::__1::__wrap_iter<unsigned int*>, std::__1::__wrap_iter<unsigned int*>) + 812
4   eu07mac.exe                           0x10015db48 sound_source::play_basic() + 244
5   eu07mac.exe                           0x1000b6a34 TDynamicObject::powertrain_sounds::render(TMoverParameters const&, double) + 3252
6   eu07mac.exe                           0x1000b4074 TDynamicObject::RenderSounds() + 204
7   eu07mac.exe                           0x10001dad4 TTrack::RenderDynSounds() + 96
8   eu07mac.exe                           0x100198ea8 scene::basic_region::update_sounds() + 280
9   eu07mac.exe                           0x1001bd97c driver_mode::update() + 1100
10  eu07mac.exe                           0x1001b6bac eu07_application::run() + 696
11  eu07mac.exe                           0x1000c1830 main + 328
12  dyld                                 0x10067108c start + 520
Spróbuję dodać tam jakieś logowanie, zobaczę, co się dzieje.

[Milek7]

Implementacja OpenGL od AMD nie jest zbyt wydajna (np. sterownik radeonsi na Linuxie działa lepiej). To że silnik jest technologicznie stary, jednowątkowy i robi dużo drawcalli również nie pomaga.
Nie wiem dlaczego shaderowy renderer na AGX działa aż tak źle. Podejrzewam dwie możliwości:
- jest to jakiś głupi problem, np. używamy w jednym miejscu jakiejś funkcji nieobsługiwanej przez sprzęt i wchodzi jakaś powolna emulacja
- systemowy translator na Metal jest nieprzystosowany do obecnego sposobu renderowania, czyli aktualizacji UBO przez glBufferSubData, wykonanie drawcalla, po czym następny submodel też natychmiastowo aktualizuje glBufferSubData, zakładając że aktualizacja nie będzie blokująca i sterownik wepchnie to do oddzielnej pamięci.

[Czarodziej]

AMD może nie, ale Maszyna ma problemy na Intelach też. I wychodzi na to, że na M1 również, a to wbrew pozorom wcale nie jest słaba karta. No ale jedyne, co mogę pomóc, to debugowanie tych segfaultów, bo się na niczym nie znam :(

[Milek7]

Intele to słabe integry, więc ciężko tu porównywać.
Nie wiem, jak obecnie profilować OpenGL na MacOS. Ten profiler Metal z Xcode zadziała?

[Czarodziej]

Jeśli działał wcześniej, to i teraz powinien. Mogę spróbować :)

-- Edit
Segfault powodowany jest przez wołanie .front() na pustym wektorze buffers w audiorenderer_extra.h. Tu otworzyłem ci PR: https://github.com/Milek7/maszyna/pull/20 z tymczasowym naprawieniem problemu. Z tym AI przejechało jeden scenariusz od początku do końca. W łikend jeśli będę miał chwilę, to spróbuję znaleźć, czemu ten bufor jest pusty.

-- Edit2
Popatrzyłem w kod i oczywiście buffer jest pusty, bo wcześniej w lambdzie buffer.id == null_resource. A to jest prawdą, bo wcześniej dzieje się "sound: failed to create AL buffer" z jakiegoś powodu :(

-- Edit3
Cóż, posiedziałem nad tym jeszcze chwilę i przyczyna zwracana z alGetError() to Invalid Value. W związku z tym, że wygląda to na problem z samym tworzeniem buforów przez alGenBuffers(), postawiłem kilka breakpointów i sprawdziłem, jak właściwie wygląda efekt końcowy, czyli wektor m_buffers. Odpaliłem w konsolce debugowania:

Kod: [Zaznacz]

for (int i=0; i < m_buffers.size(); i++) ErrorLog(to_string(i).append(": ").append(to_string(m_buffers[i].id)), logtype::generic)Efekt w załączniku. Zadziwiające, że akurat 1024 i wszystkie dalsze mają id o wartości null_resource. Co dziwne, również zerowy jest zepsuty.

-- Edit4
Zerowy jest zepsuty, bo jest dodawany w konstruktorze:

Kod: [Zaznacz]

buffer_manager() { m_buffers.emplace_back( openal_buffer() ); }Czyli z jakiegos powodu alGenBuffers można zawołać tylko 1023 razy o_O'

-- Edit5
No i wszystko jasne. Ehh… Apple: https://opensource.apple.com/source/OpenAL/OpenAL-67/Source/OpenAL/oalImp.h.auto.html
Spróbuję z OpenAL-soft

-- Edit6
Z OpenAL-soft działa :)

[Czarodziej]

Nie umiem używać Xcode, więc zająłem się pythonem póki co. Przy rendererze "pełnym" ekrany działają. Przy "legacy" wylatuje wyjątek "BAD_ACCESS" (null pointer?) w funcji render_task::upload(), konkretnie dzieje się to w glGenerateMipmap(GL_TEXTURE_2D); Niestety, sam tego raczej nie rozwiążę. Czy ktoś jest w stanie powiedzieć tak na szybko, co może być nie tak lub jaka jest właściwie różnica w ustawieniach GL dla różnych trybów renderowania i gdzie mogę znaleźć kod odpowiedzialny za te różnice?

[Czarodziej]

Wydaje mi się, że moje zmiany są już częścią 22.08, zatem wyciągnąłem gałąź youBy'ego i spróbuję się przejechać.
Dodatkowo, macos zaczął protestować i musiałem "podpisać" exe:

Kod: [Zaznacz]

codesign -s - eu07mac.exe

[Czarodziej]

Odkopuję. Status "prac":
- Paczka 23.04 działa dość dobrze z wersją 27e03ab9e8d287fe28bbed8c8eed159c41ad9346 (nie wiem, czy to najnowszy) z gita. Po kilku testowych przejazdach nie zauważyłem nic podejrzanego.
- Udało mi się naprawić ekrany. Pillow ma binarki, nie można sobie ich tak sobie skopiować z wersji na Windows. Doinstalowałem pipem ręcznie. Do tego musiałem wyłączyć python.mipmaps w ini.
Zostaje tylko naprawienie renderera, ale to już nie na moje umiejętności. Jeśli ktoś jest zainteresowany zbudowaną wersją (na arm64), to mogę wrzucić gdzieś binarki.

-- Edit --

Wychodzi na to, że nie działają mi papierowe rozkłady w kabinach. To też jest generowane pythonem, prawda?

[jakubg1]

Tak.