- Symulator MaSzyna -
Symulator EU07 (i nie tylko) => Na warsztacie => Wątek zaczęty przez: piopawlu w 08 Stycznia 2021, 23:33:31
-
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 (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
-
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:
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ę?
-
Bez OGL 3.3 nie ruszy bo gui wymaga.
-
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
-
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:
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.
-
Dobry wieczór, odgrzewam kotleta.
Rewizja 98050176 (najnowsza z oficjalnego GitHuba Maszyny, o ile można tak to nazwać).
Buduję tak:
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 -j20
Kompilator: 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.
-
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ć.
-
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
-------------------------------------
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
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)
-
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.
-
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
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.
-
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.
-
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 :(
-
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?
-
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:
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:
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 :)
-
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?
-
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:
codesign -s - eu07mac.exe
-
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?
-
Tak.