Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthormrk
   • CommentTime25 May 2021 01:05

    
   ->link<- - wygląda na to że pojawił się działający backend LLVM dla 65xx!
   Bawię się tym od wczoraj - oryginalnie była dostępna konfiguracja pod c64, ale po drobnych zmianach udało się utworzyć konfigurację dla małego atari (produkującą pliki xex), PR w drodze.
   Co to oznacza w praktyce - na początek nowoczesny toolchain z kompilatorem C/C++ i assemblerem, docelowo zapewne także inne języki bazujące na LLVM (mam nadzieję na Rust'a :] )

   • Screenshot_from_2021-05-25_00-09-25.png
     
     
     
     
2. • 2:
      
     CommentAuthorpirx
   • CommentTime25 May 2021 04:05

    
   najs! Ile ma .xex?
3. • 3:
      
     CommentAuthorlaoo
   • CommentTime25 May 2021 06:05 zmieniony

    
   O, fajnie, że facetowi udało się to pchnąć do przodu.
   Coś tam nawet dopisałem ( np. SHF_MOS_ZEROPAGE to mój pomysł i implementacja ), ale wnętrzności LLVM są strasznie skomplikowane, a gość wymagał, żeby pisać testy do wszystkiego, no i przez engine testów LLVM już nie przebrnąłem i odpadłem :)
4. • 4: CommentAuthormrk
   • CommentTime25 May 2021 08:05 zmieniony

    
   @pirx za dużo - jakieś 11kB :) Zerkałem do wygenerowanego pliku asm i widzę dużo nieużywanego kodu, więc powinno się dać ładnie z tego zejść.
   
   @laoo - nieźle. Teraz pewnie przyda się pewnie parę rąk do pracy nad SDK dla atari - z wywołań systemowych zaimplementowany jest na razie tylko `putchar` (EOUTCH).
5. • 5:
      
     CommentAuthorlaoo
   • CommentTime25 May 2021 08:05

    
   Co do tych 12kB - w ogóle cudem jest, że facetowi udało się zmusić Clanga do generowania jakiegokolwiek kodu 6502. Z tego co ja liznąłem wnętrzności, to mogę sobie wyobrazić, ile wysiłku i "brainpower" to wymaga. Więc mamy pierwszą wersję i dowód że się da. Clang/llvm potrafi być dość agresywny z optymalizacją, tylko trzeba go nastroić. Więc trzymamy kciuki, żeby autor nie zeszedł ze stanem baterii za nisko i żeby ktoś znalazł się do pomocy. Ja trochę pomagałem, bo widziałem zastosowanie dla GASa w swoim projekcie (podobała mi się idea ELFa dla 6502), ale ostatecznie odkryłem, że ELF nie jest taki elastyczny jak potrzebuję i oczywiście poszło w pisanie kolejnego własnego asemblera :)
6. • 6:
      
     CommentAuthorYosh
   • CommentTime25 May 2021 09:05 zmieniony

    
   Ło, niezłe osiągniecie. Wiem ile to pracy bo sam robiłem podejście i aż głupio zbyć to:
   
   "jak przeskoczy jakość kodu c65 (ktora jest tez dosc toporna) to pogadamy"
   "... potem mad pascala podejrzewam"
   "... a ręczny kod asm?"
   
   No ale marzenia mam duże, trzeba zasypać gościa feature requestami np.
   
   const uint16_t var[2] __attribute__((lohi)) = {0x1234, 0xabcd};
   
   mialo by zamienic tablice na
   var_lo
   dta $12,$ab
   var_hi
   dta $34,$cd
   
   dla szybszego adresowania, a to najprostszy 'trik' 6502 ...
   
   A jak ogarnąć, że flaga procesora Decimal może być użyta jako szybki bool - o ile w danym obszarze nikt nie wykonuje dodawań i odejmowań ;)
   
   Gorąco trzymam kciuki, ktoś w końcu realizuje moje marzenia na które nie mam czasu :)
7. • 7:
      
     CommentAuthorlaoo
   • CommentTime25 May 2021 10:05 zmieniony

    
   Jest topic na 6502.org i widzę, że jest ich dwóch, stąd liczba mnoga na wiki (a nie figura stylistyczna dodająca powagi). W ostatnim wpisie piszą, że odpalają testy llvm, żeby jak najwięcej przeszło, potem dopiero zajmą się optymalizacją, więc na razie tym '12kb' bym się nie przejmował, a llvm ma strasznie duży potencjał optymalizacyjny.
   
   ->link<-
8. • 8: CommentAuthormrk
   • CommentTime25 May 2021 14:05

    
   Pytanie do praktyków.
   
   Wrzuciłem PR dodający konfigurację dla atari800xl: ->link<-
   
   Trzeba zadecydować jak ma wyglądać domyślny 'layout' pamięci - od jakiego adresu generować kod oraz gdzie umieścić software'owy stos (stos rośnie w dół, trzeba określić jego koniec).
   
   Przykładowo dla c64 kod jest umieszczany od adresu 2061 (dec) , koniec stosu to 0x9fff
   
   Do testów na emulatorze ustawiałem sobie segment kodu na 0x1000 i stos poniżej na 0x0fff
   
   W review dostałem sugestię by stos ustawić podobnie jak w c64, czyli na koniec dostępnej pamięci.
   
   Mogę ustawić go runtime na MEMTOP - ale co wtedy z ewentualną zmianą trybu graficznego (via S:) - olać?
   
   Jakie są dobre praktyki jeśli chodzi o umieszczanie kodu za DOS'em, jakie MEMLO można bezpiecznie przyjąć?
9. • 9:
      
     CommentAuthorKaz
   • CommentTime25 May 2021 14:05

    

   mrk:

   po drobnych zmianach udało się utworzyć konfigurację dla małego atari (produkującą pliki xex), PR w drodze. Co to oznacza w praktyce - na początek nowoczesny toolchain z kompilatorem C/C++ i assemblerem, docelowo zapewne także inne języki bazujące na LLVM (mam nadzieję na Rust'a :]

   
   
   Nieźle, kurde felek! Brawo panie kolego. A Javę też będziemy odpalać na małym Atari?
   
   

   Yosh:

   No ale marzenia mam duże, trzeba zasypać gościa feature requestami np.

   
   
   Słusznie, zasypuj! :D
10. • 10: CommentAuthorilmenit
    • CommentTime25 May 2021 14:05 zmieniony

     
    Tutaj jaki ma layout pamięci CC65:
    ->link<-
    CC65 zaczyna domyślnie program od $2E00, ale można przyjąć $2000 i będzie działać z większością DOSów.
    
    Jak będę miał więcej czasu to chętnie zerknę na wygenerowany kod.
    Zbyti jakiś czas temu przygotował zestaw dla KickC ->link<- , a ponieważ jest analogiczny do tego z MadPascala, można porównywać kilka nowo tworzonych języków.
11. • 11: CommentAuthormrk
    • CommentTime25 May 2021 14:05

     
    @ilmenit dzięki! w takim razie ustawiam program na $2000, stos na MEMTOP
12. • 12:
       
      CommentAuthorlaoo
    • CommentTime25 May 2021 15:05 zmieniony

     
    Zakładam, że zerkanie do wygenerowanego kodu może być zwodnicze, bo dostaniemy tylko kod przemielony przez wysokopoziomową optymalizację (czyli że kompilator "wykonuje sobie" program i sprawdza czy nie wyszło coś statycznego), ale nic niskopoziomowego, bo LLVM ma bardzo dużo opcji strojenia optymalizatora pod konkretną platformę, ale to dużo pracy, którą na pewno będą chcieli zrobić później.
13. • 13: CommentAuthormrk
    • CommentTime26 May 2021 09:05 zmieniony

     
    Polecam przeczytanie całego wątku na 6502.org który podlinkował wyżej @laoo ->link<- - masa ciekawych informacji jak to działa pod spodem, sporo przykładów wygenerowanego kodu (piszą też na przykład dlaczego spora ilość optymalizacji które już były zaimplementowane została na razie usunięta (why WorseIsBetter).
    
    A PR dodający atari/800xl.cfg został już wmergowany :) ->link<- - co ciekawe mysterymath zdążył już zrobić tam mały refaktor
14. • 14: CommentAuthormrk
    • CommentTime27 May 2021 00:05

     
    Jeszcze jeden update. Wyżej pisałem że dzięki llvm-mos mam nadzieję na Rust'a dla Atari (Rust używa LLVM do generowania kodu) - i okazuje się że to już praktycznie działa :)
    Więcej szczegółów: ->link<-
15. • 15:
       
      CommentAuthorYosh
    • CommentTime27 May 2021 01:05

     
    Kciuki mi naszły krwią! no ale trzymam. Może jak dopłyną do mikro optymalizacji to się w to zerknie i coś pogrzebie:)
16. • 16: CommentAuthorilmenit
    • CommentTime27 May 2021 09:05

     
    Świetne, trzymam kciuki. mrk, projekt potrzebuje atarowego wsparcia i super, że jesteś tym zainteresowany.
17. • 17: CommentAuthormrk
    • CommentTime27 May 2021 10:05

     
    @ilmenit dzięki, będę obserwował na pewno i pewnie co jakiś czas wrzucał coś do SDK dla Atari. BTW _ilm_ na reddicie to Ty? Jak ktoś ma konto na Reddit to prośba o podbicie: ->link<- :)
18. • 18: CommentAuthorilmenit
    • CommentTime27 May 2021 11:05

     
    tak, ja
19. • 19: CommentAuthormrk
    • CommentTime17 Jun 2021 00:06 zmieniony

     
    Update:
    
    Prace nad llvm-mos nie zwalniają - autor ostro ciśnie i cały llvm-test-suite już się kompiluje (z wyłączeniem testów operacji zmiennoprzecinkowych których obsługi jeszcze nie ma oraz części testów które na przykład zakładają 32-bitowy int), na ponad 1300 testów nie działa tylko kilkanaście. Podsumowanie od autora sprzed kilku dni tutaj: ->link<- - mocno już nieaktualne, bo wtedy failowała jeszcze połowa :)
    
    Ze swojej strony cisnę wsparcie dla 6502 w Rust - jakiś czas temu dodałem obsługę target triple dla mos-6502: 'mos-unknown-none' i od kilku dni jestem już w stanie budować binarki bezpośrednio za pomocą cargo :) więcej szczegółów tutaj: ->link<-

    • Screenshot from 2021-06-17 00-12-27.png
      
      
      
      
20. • 20:
       
      CommentAuthorpirx
    • CommentTime17 Jun 2021 02:06

     
    oh boy
21. • 21:
       
      CommentAuthorEnjo
    • CommentTime18 Jun 2021 08:06 zmieniony

     
    Teraz dodajcie to, że kolega napisał zestaw zasad ulepszających optymalizację kodu (nie pamiętam gdzie to było. Na Atariki?). Można by dodać te zasady do clang-tidy jako kolejny moduł.
    
    (clang-tidy to narzędzie LLVM do statycznej analizy kodu)
22. • 22: CommentAuthormrk
    • CommentTime20 Jun 2021 13:06

     
    Aktualny status: ->link<-
23. • 23:
       
      CommentAuthorPeri Noid
    • CommentTime20 Jun 2021 15:06

     
    Że tak zapytam: jak to się ma do cc65? Pomijając fakt, że cc65 chyba stanęło w rozwoju. Chodzi mi o możliwości i kompatybilność źródeł.
24. • 24:
       
      CommentAuthorjhusak
    • CommentTime20 Jun 2021 23:06

     
    CC65 się powolutku dowija, czyli: błędy i optymalizacje, oraz pewnie nowe architektury, jak już.
    Natomiast C++ czy Rust na Atari to już petarda (pomijając sensowność C++ na kilkudziesięciu kilobajtach pamięci).
25. • 25: CommentAuthormrk
    • CommentTime21 Jun 2021 00:06 zmieniony

     
    Z kompatyblilnością powinno być dobrze: cc65 to ANSI C (prawie), clang to C99, czyli powinien być kompatybilny w dół z cc65. Oczywiście gorzej trochę będzie na początku z bilbliotekami - llvm-mos zawiera na razie szczątkową bibliotekę libc, brak oczywiście na razie bibliotek dla poszczególbych platform) - ale mam nadzieję że zostanie to szybko nadrobione (i nie liczę tu na obecnych autorów llvm-mos ale raczej na społeczność).
    
    Mi na przykład udało się bez problemu skompilować wszystkie kroki z "CC65-Advanced-Optimizations" @ilmenit'a bez zmian w kodzie samego programu (game.c), musiałem jedynie dodać kilkulinijkowy "atari.h" i poprawić nieco benchmark.h
26. • 26: CommentAuthorilmenit
    • CommentTime21 Jun 2021 12:06

     
    CC65 jest wciąż rozwijany, ale bardzo rzadko kwestie optymalizacji. Większość rozwoju idzie w lepsze wsparcie różnych platform.
    CC65 robi bardzo mało high-level optymalizacji i tutaj już teraz LLVM jest bez porównania lepszy. Optymalizacje takie można robić "ręcznie", ale dobry kompilator wiele z tego, co zrobiłem w tym artku na githubie, powinien zrobić automatycznie. Wątpię jednak, że będzie niektóre rzeczy (jak zastępowanie wskaźników indeksami tablic) robił, ponieważ nie ma takiej potrzeby w "większych procesorach". Ale kto wie, współczesne optymalizatory robią czasem cuda.
    CC65 ma całkiem dobry (choć daleki od ideału) peephole optimizer i tutaj będzie sporo pracy nad LLVM. Jak dobrze może zrobić niskopoziomowe optymalizacje zależy od założeń odnośnie stosu, sterty czy strony zerowej, które przyjął autor tego backendu LLVM.
27. • 27: CommentAuthortebe
    • CommentTime21 Jun 2021 16:06

     
    ->link<-
    
    taki uniwersalny, konfigurowalny kompilator do wszystkiego ;)
    
    FPC (Free Pascal Compiler) dla LLVM
    
    ->link<-
28. • 28: CommentAuthormrk
    • CommentTime29 Sep 2021 15:09 zmieniony

     
    Jak pisałem wyżej jakiś czas temu przeportowałem `CC65-Advanced-Optimizations` @ilmenit'a do clang'a i zacząłem go używać do benchmarkowania nowych wersji llvm-mos (wrzucając do repozytorium wyniki). Wczoraj zebrałem te dane razem i powstał załączony obrazek :)
    
    Jak widać autor zaczął optymalizować już generowany kod i idzie to całkiem nieźle :)
    
    Zainteresowanym polecam dołączenie do llvm-mos na slacku, dużo ciekawych informacji z pierwszej ręki. Przykładowo kolejność w jakiej autor wybiera rzeczy do optymalizacji, cyt.:
    
    1. Things that are in all loops
    2. Things that are usually in loops
    3. Things that are occasionally in loops.
    4. Everything else
    
    :)

    • Screenshot from 2021-09-28 20-02-03.png
      
      
      
      
29. • 29: CommentAuthorilmenit
    • CommentTime29 Sep 2021 15:09

     
    Bardzo ciekawe podejście. Jeżeli kompilator będzie w stanie doścignąć optymalizacjami te ręcznie robione, to będzie to mega narzędzie. Zakładam jednak, że niektóre optymalizacje (jak użycie lookup tables) nie będą domyślnie robione.
30. • 30: CommentAuthor0xF
    • CommentTime29 Sep 2021 20:09

     
    Co jest na osi pionowej i jak wygląda porównanie z cc65?
31. • 31: CommentAuthormrk
    • CommentTime29 Sep 2021 22:09 zmieniony

     
    @0xF
    Na osi pionowej jest czas wykonania danego programu w cyklach cpu. Ciekawostka - programy uruchamiane są na bardzo prostym dedykowanym emulatorze poskładanym na potrzeby llvm-mos on nazwie `sim` (procesor 6502, 64kB pamięci i bardzo proste IO pozwalające wypisywać znaki na terminal / zakończyć emulację / pobrać aktualną ilość cykli procesora). Wszystko można uruchomić `headless`, i na stdout dostać wyniki z emulatora (w ten sposób uruchamiany jest też cały test-suite llvm'a)
    
    Myślę że ten `sim` mógłby być też super przydatny do testowania kodu który się tworzy na Atari.
    
    Jeśli chodzi o porównanie z CC65 to jest już bardzo dobrze, w większości z tych benchmarków llvm-mos już jest na prowadzeniu (co ciekawe widać że wiele z tych kolejnych kroków które @ilmenit robi dla cc65 nic nie wnosi w llvm-mos, a nawet potrafi pogorszyć wynik (na przykład 05, co jest tu akurat nieco zaskakujące)).
    
    01-start
    cc65: 9495416
    ticks: 8426796
    
    03-smallest-unsigned-data-types
    cc65: 9204740
    ticks: 4845761
    
    04-get-rid-of-C-stack
    cc65: 7848252
    ticks: 4861848
    
    05-replace-array-of-structs
    cc65: 7388015
    ticks: 5004379
    
    06-get-rid-of-enums
    cc65: 7170008
    ticks: 4792125
    
    08-get-rid-of-parameter-passing
    cc65: 7194231
    ticks: 5030650
    
    09-replace-calculations-and-switches-with-lookup-tables
    cc65: 1622941
    ticks: 1131785
    
    11-improve-array-access
    cc65: 775136
    ticks: 1020785
    
    12-inline-functions
    cc65: 702467
    ticks: 1215081
    
    14-llvm-mos-opts
    cc65: 1913617
    ticks: 917727
32. • 32: CommentAuthor0xF
    • CommentTime30 Sep 2021 07:09

     
    Dzięki!
    
    Taki symulator jest też w CC65: ->link<-
    
    Jak rozumiem, najlepszy wynik dla tego benchmarku to 702 kC (kilocykli) dla cc65 i 918 kC dla llvm-mos?
33. • 33: CommentAuthorilmenit
    • CommentTime30 Sep 2021 08:09

     
    @mrk - w każdym przypadku kompilujesz kod CC65 z -Osir i -Cl?
34. • 34: CommentAuthormrk
    • CommentTime30 Sep 2021 10:09 zmieniony

     

    0xF:

    Jak rozumiem, najlepszy wynik dla tego benchmarku to 702 kC (kilocykli) dla cc65 i 918 kC dla llvm-mos?
    

    
    Tak. Przy czym najlepszy wynik llvm-mos był już nawet sporo lepszy (jakieś 650k) ale celowo został wyłączony chwilowo jakiś pass który powodował problemy (ten schodek na samym dole na wykresie).
    
    

    ilmenit:

    w każdym przypadku kompilujesz kod CC65 z -Osir i -Cl?

    
    Tak (najprawdopodobniej, bo wersje z CC65 skompilowałem kiedyś raz by mieć referencyjne wyniki, ale widzę te flagi w Makefile)
    
    BTW mój fork jest tutaj: ->link<- - chętnie wystawię jakieś PR'y pozwalające na skompilowanie z llvm-mos
35. • 35:
       
      CommentAuthorjhusak
    • CommentTime30 Sep 2021 12:09 zmieniony

     
    Szybkość to jedno, a wielkość kodu wynikowego to drugie.
    Dla mnie to drugie jest bardziej istotne (szybkie wstawki robię wtedy w asm)
    
    Czy benchmarki na optymalizację rozmiaru też będziesz robił?
36. • 36: CommentAuthormrk
    • CommentTime30 Sep 2021 13:09 zmieniony

     
    @jhusak
    Wydaje mi się że na obecnym etapie jedno z drugim idzie często w parze (autor pokazywał na slacku jak wyglądało wcześniej porównywanie długich integerów - koszmarny i długi potworek, po ostatnich poprawkach przypomina to nareszcie kod jaki napisałby człowiek - jest i krótsze i szybsze).
    
    Poza tym optymalizacja rozmiaru jest pewnie w sporej części niezależna od samego llvm-mos, przykładowo blokowanie inline'owania funkcji (co llvm lubi domyślnie robić)
    
    Ale masz rację, rozmiar na pewno warto zacząć też zbierać, pomyślę jak to dodać.
37. • 37:
       
      CommentAuthorPeri Noid
    • CommentTime30 Sep 2021 13:09

     
    Takie rzeczy jak porównywanie standardowych typów nie powinny być przypadkiem zrobione kodem według "template" zadanym przez twórcę kompilatora? Ewentualnie w bibliotece?
38. • 38: CommentAuthormrk
    • CommentTime30 Sep 2021 15:09 zmieniony

     
    Pewnie mogą - ale najwidoczniej nie muszą, wygląda na to że po dobrym nauczeniu llvm'a podstaw jest on w stanie sam domyślić się jak robić to optymalnie (odsyłam do slack'a projektu gdzie jest to dość dokładnie opisane).
    Trzeba pamiętać że na razie rozwija to praktycznie jedna osoba - im więcej roboty zrobi się automatycznie, tym lepiej.
    
    Autor to mega kumaty gość i wygląda na to że naprawdę wie co robi, ja nie jestem niestety w stanie ogarnąć 95% rzeczy które tam się dzieją pod spodem :/
39. • 39:
       
      CommentAuthorPeri Noid
    • CommentTime30 Sep 2021 17:09

     
    Co znaczy "domyślić" w powyższym? Możesz rzucić tym linkiem do którego odsyłasz? (tylko konkretnie bym poprosił bo obawiam się, że jak nie wiadomo czego szukać to szansa znalezienia jest równa 0).
40. • 40: CommentAuthormrk
    • CommentTime30 Sep 2021 17:09 zmieniony

     
    Nie dam linka bo to kanał #general na slack'u projektu, nie czuję się też upoważniony by cytować stamtąd rzeczy publicznie w internecie :)
    
    Jeżeli interesują Cię takie detale to naprawdę zachęcam do dołączenia do slack'a, jest to kopalnia wiedzy o llvm-mos i samym llvm. Tu znajdziesz informację jak dołączyć: ->link<- (z tego co wiem nie trzeba instalować klienta slack'a, można użyć tego web'owego)
41. • 41:
       
      CommentAuthorjhusak
    • CommentTime30 Sep 2021 17:09 zmieniony

     
    Ha, nawet na tej stronie jest twój przykład w ruście z silnią :)
    
    Ale rozumiem, że w tym można już pisać/ kompilować, testy integralności zawsze przechodzi przecież, czyż nie? :)
42. • 42: CommentAuthormrk
    • CommentTime30 Sep 2021 17:09 zmieniony

     
    @jhusak
    
    Można. Prace nad optymalizowaniem kodu zaczęły się tak późno bo autor chciał mieć najpierw pewność że generuje się poprawny kod.
    Mi nawet pierwsze w życiu a8 'demo' (i pierwsze na świecie demo w rust na a8) udało się napisać: ->link<- (premiera na aol)
    
    BTW jakaś muzyczka by się przydała, nie? ;)
    
    BTW2 widać że mój emulator źle liczy cykle jeszcze, bo jak odpalam to na Alitra / Atari800 to nie wyrabiam się czasowo i na dole są glitch'e - muszę w sumie przekompilować na ostatniej wersji llvm-mos to może zacznie się wyrabiać :)
43. • 43:
       
      CommentAuthorjhusak
    • CommentTime1 Oct 2021 07:10 zmieniony

     
    Super.
    Napisz jeszcze na stronce emulatora wymagania. W Safari na iPadzie nie działa, 14.6 iOS. Podobnie w Firefox. Na czym to uruchomić?
44. • 44:
       
      CommentAuthorgalu
    • CommentTime1 Oct 2021 09:10

     
    Załączam logi z desktopowego Safari / macOS dla architektury ARM64 (Mac z procesorem M1) w wersji stabilnej (14) i rozwojowej (15) - bo tu też nie działa. Z tego co kojarzę to na intelowym Safari działało.

    • safari-current.txt
45. • 45:
       
      CommentAuthorgalu
    • CommentTime1 Oct 2021 09:10

     
    Drugi log

    • safari-tp.txt
46. • 46: CommentAuthormrk
    • CommentTime1 Oct 2021 09:10

     
    Wymagania to WebGL2 + WebAudio - powinno działać na aktualnych wersjach Firefox i Chrome (Safari do niedawna nie miało WebGL2 jeszcze by default, dało się włączyć to chyba jakoś eksperymentalnie, ale jakość tej implementacji z tego co pamiętam jest mocno średnia)
    
    Sprawdziłem właśnie u siebie - działa a Chrome 93 i Firefox 92, Ubuntu 20.04, zintegrowany Intel.
    
    Emulator dość mocno wykorzystuje GPU (emulacja antica / wykrywanie kolizji jest na shader'ach), wykorzystuje do tego dość niestandardowe formaty tekstur (standard WebGL2 wymaga niby by były dostępne) - i pewnie wywala się na jakichś drobnych różnicach w implementacji WebGL2 na jakichś kombinacjach (Przeglądarka / OS / GPU).
    
    To co by się przydało to jakaś szybka diagnostyka przy uruchamianiu (np. sprawdzenie czy wymagane formaty tekstur są dostępne) + link do issue trackera z prośbą o podanie (Browser / OS / GPU) a jeszcze lepiej automatyczne zbieranie tych informacji jak emulator się nie uruchomi.
47. • 47: CommentAuthormrk
    • CommentTime1 Oct 2021 09:10 zmieniony

     
    @galu
    
    Z tego co widzę w logu wywala się po prostu na tworzeniu kontekstu webgl2 - możesz zerknąć czy działają Ci przykłady z ->link<- ?
    
    EDIT chociaż w drugim logu widzę że poszedł jednak dalej. I żadnych błędów niestety - więc prawdopodobnie jakieś różnice w bindowaniu uniform buffers do shaderów. Ciężko będzie mi to debugować bo brak Mac'a pod ręką.
    
    I odeszliśmy nieco od tematu wątku :) - 'demo' polecam ściągnąć ->link<- i uruchomić pod normalnym działającym emulatorem ;)
48. • 48: CommentAuthormrk
    • CommentTime1 Oct 2021 10:10

     
    Właśnie przkompilowałem demko na najświeższej wersji llvm-mos i jest faktycznie dużo szybciej (wyrabia się teraz w ramce i zniknęły te glitch'e na dole):
    
    Aktualna wersja: ->link<-
    
    Poprzednia wersja: ->link<-
49. • 49:
       
      CommentAuthorgalu
    • CommentTime1 Oct 2021 10:10

     
    ->link<-
    
    Wysypuje się na glsl_flat_smooth_interpolators - pozostałe działają.
50. • 50: CommentAuthor0xF
    • CommentTime1 Oct 2021 11:10

     
    Właśnie przkompilowałem demko na najświeższej wersji llvm-mos

    
    Wrzucisz źródło?
    
    Jaki emulator? Jaki webgl2? Bo się pogubiłem.