Symulator EU07 (i nie tylko) > Na warsztacie
Natywny build MacOS
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: ---for (int i=0; i < m_buffers.size(); i++) ErrorLog(to_string(i).append(": ").append(to_string(m_buffers[i].id)), logtype::generic)
--- Koniec kodu ---
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: ---buffer_manager() { m_buffers.emplace_back( openal_buffer() ); }
--- Koniec kodu ---
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?
Nawigacja
[#] Następna strona
Idź do wersji pełnej