TinyGPU v2.0 działa w krzemie, ale jego twierdzenie o najmniejszym GPU czeka większy test

Tom Hardware informuje, że TinyGPU v2.0 działa już w fizycznym krzemie, przekształcając około 240 000 tranzystorów w działający procesor grafiki 3D. Projektant Pongsagon Vichit pokazał, jak układ generuje grafikę po procesie produkcyjnym Tiny Tapeout. Projekt przestał więc być eksperymentem FPGA, a stał się wyprodukowanym układem scalonym specyficznym dla zastosowania, czyli ASIC.

Wynik ma znaczenie, ponieważ produkcja ujawnia problemy, które mogą pozostać ukryte w symulacji programowej i testach FPGA. Zachowanie zegara, synchronizacja sygnałów, dostęp do pamięci oraz integracja na poziomie płytki muszą sprawdzić się w fizycznym sprzęcie. Film Vichita wskazuje, że podstawowy potok działa, choć dostępna demonstracja nie odpowiada na wszystkie pytania dotyczące wydajności lub niezawodności.

Nie jest to miniaturowy rywal dla Nvidia, AMD ani Intel. TinyGPU v2.0 renderuje celowo skromne sceny w niskiej rozdzielczości i z ograniczoną głębią kolorów. Jego prawdziwym przeciwnikiem jest przepaść między interesującym prototypem FPGA a powtarzalnie działającym krzemem. Pokonanie tej przepaści nadaje projektowi wartość techniczną znacznie wykraczającą poza liczbę klatek na sekundę.

Kolejne pytanie dotyczy TinyGPU v3.0. Vichit rozwija bardziej programowalną konstrukcję z funkcjami pixel shaderów i poprawkami znanych ograniczeń v2.0. Ta mapa rozwoju podnosi stawkę, ponieważ każda dodatkowa funkcja zużywa zasoby logiki, przepustowość pamięci i nakład pracy na weryfikację.

Tom Hardware podaje, że TinyGPU przetrwał test w krzemie

Istotna zmiana nie polega na tym, że TinyGPU wyświetla prostą grafikę 3D. Chodzi o to, że wyprodukowany układ podobno realizuje to, co obiecywał jego cyfrowy projekt.

Vichit wcześniej testował TinyGPU v2.0 na płytce FPGA Basys3. FPGA to konfigurowalny układ, który pozwala projektantom testować logikę sprzętową przed przejściem na stały układ fizyczny. Ten etap pokazał, że architektura może renderować modele, przyjmować dane z kontrolera i sterować wyświetlaczem VGA.

Wyprodukowanie ASIC usuwa tę elastyczność. Logika staje się fizycznym układem tranzystorów i połączeń. Błędu projektowego nie da się poprawić przez wgranie nowej konfiguracji do tego samego układu. Poważne błędy zwykle wymagają kolejnego cyklu produkcyjnego.

Według raportu z 4 sierpnia silicon test report, zwrócony krzem TinyGPU v2.0 generował podczas testów rzeczywistą grafikę. Raport opisuje wynik jako udaną demonstrację w rzeczywistych warunkach po serii produkcyjnej Tiny Tapeout.

Dowody te wspierają węższe twierdzenie niż pełną kwalifikację produktu. Film może pokazać, że główne funkcje działają w jednej testowanej konfiguracji. Nie potwierdza jednak uzysku produkcyjnego, tolerancji napięciowej, stabilności podczas długiej pracy ani wydajności wielu próbek.

Te rozróżnienia mają znaczenie w relacjach o półprzewodnikach. Inżynierowie często nazywają pierwszą zwróconą wersję krzemem A0. Uzyskanie użytecznych wyników z A0 jest istotne, ponieważ wiele błędów sprzętowych staje się kosztownych po tapeoucie. Tapeout to moment, w którym ukończony projekt układu trafia do produkcji.

Zaprezentowany potok podobno obsługuje transformację, oświetlenie, rasteryzację i wyjście obrazu. Transformacja przekształca współrzędne modelu w pozycje na ekranie. Rasteryzacja określa, które piksele należą do każdego trójkąta. Oświetlenie dostosowuje widoczny kolor powierzchni na podstawie wybranego kierunku światła.

Dokumentacja projektu projektanta opisuje architekturę 25 MHz wykorzystującą w wyprodukowanej postaci około 240 000 tranzystorów. Obsługuje ona modele zawierające do 1 000 trójkątów, chociaż rzeczywista szybkość zależy od złożoności sceny i włączonych funkcji.

Udokumentowany cel wyświetlania to 320 na 240 pikseli z 4-bitowym kolorem. Czterobitowy kolor zapewnia 16 możliwych wartości kolorów w odpowiednim schemacie palety. To skrajnie ograniczone w porównaniu z nowoczesną grafiką, ale wystarczające do wyświetlania rozpoznawalnych, cieniowanych lub teksturowanych obiektów.

Projekt korzysta także z zewnętrznej pamięci QSPI. QSPI to interfejs szeregowy przesyłający dane przez wiele linii sygnałowych. TinyGPU wykorzystuje ten zewnętrzny sprzęt do przechowywania danych modeli, klatek i informacji o głębi, które zajęłyby zbyt dużo miejsca w samym układzie.

Konfiguracja Vichita obejmuje moduł wyjścia VGA, sprzęt QSPI, interfejs gamepada i kontroler SNES. Użytkownicy mogą obracać modele, zmieniać ich skalę lub dostosowywać światło kierunkowe. Te elementy sterujące sprawiają, że demonstracja jest interaktywna, a nie stanowi stałej animacji zapisanej w układzie.

Tom Hardware opisywał wcześniej projekt przed produkcją, gdy podawane oszacowanie liczby tranzystorów było bliższe 200 000. Obecna liczba 240 000 odzwierciedla wyprodukowaną implementację opisaną przez Vichita. Szacunki mogą się zmieniać, gdy synteza i fizyczny projekt układu przekładają logikę źródłową na rzeczywiste komórki standardowe.

Wynik zamyka zatem jedną niewiadomą, pozostawiając otwartych kilka innych. TinyGPU v2.0 nie jest już wyłącznie twierdzeniem opartym na symulacji lub FPGA. To podobno działający krzem, ale nadal eksperymentalny układ, a nie kwalifikowany komercyjny GPU.

GPU z 240 000 tranzystorów to w istocie studium ograniczeń

TinyGPU staje się interesujący, gdy jego ograniczenia traktuje się jako wymagania projektowe, a nie zawstydzające porównania z desktopowymi kartami graficznymi.

Nowoczesny dyskretny GPU zawiera miliardy tranzystorów, rozbudowaną pamięć cache, wyspecjalizowane bloki obliczeniowe, silniki wideo i szerokie interfejsy pamięci. TinyGPU v2.0 nie ma takiej skali. Porównanie ich deklarowanej wydajności niewiele powiedziałoby o problemie inżynieryjnym, który Vichit postanowił rozwiązać.

Jego problemem jest kompresja. Architektura musi zachować wystarczającą część konwencjonalnego potoku graficznego, aby przekształcać i rysować geometrię 3D przy bardzo małym budżecie logiki. Każdy rejestr, mnożnik, bufor i stan sterowania rywalizuje o tę samą ograniczoną powierzchnię krzemu.

Arytmetyka stałoprzecinkowa pomaga utrzymać ten budżet pod kontrolą. Liczby stałoprzecinkowe rezerwują z góry określone bity dla części całkowitej i ułamkowej. Wymagają mniej obwodów niż ogólne operacje zmiennoprzecinkowe, lecz projektanci muszą starannie zarządzać zakresem i precyzją.

Potok wykorzystuje także płaskie cieniowanie z jednym dynamicznym światłem kierunkowym. Płaskie cieniowanie przypisuje stałą wartość oświetlenia całemu trójkątowi, zamiast obliczać płynne zmiany dla każdego wierzchołka lub piksela. Taki wybór ogranicza obliczenia, zachowując widoczną formę 3D.

Odrzucanie tylnych ścian usuwa trójkąty zwrócone tyłem do kamery. Powierzchnie te zwykle nie są widoczne, więc ich pominięcie oszczędza pracę rasteryzacji. To standardowa technika graficzna, której korzyść staje się szczególnie istotna przy małym budżecie tranzystorów i zegara.

8-bitowy bufor głębi zapisuje, która powierzchnia powinna być widoczna z przodu w każdym miejscu. Bez testowania głębi trójkąty rysowane później mogłyby nieprawidłowo zasłaniać bliższą geometrię. Ograniczona precyzja pasuje do tych kompaktowych scen, choć byłaby niewystarczająca w wielu większych środowiskach.

4-bitowy podwójny bufor utrzymuje oddzielne powierzchnie rysowania i wyświetlania. Jeden bufor może być pokazywany, podczas gdy przygotowywana jest następna klatka. Ich zamiana ogranicza widoczne rozrywanie obrazu, gdy fragmenty dwóch klatek pojawiają się jednocześnie podczas aktualizacji.

Te funkcje sprawiają, że TinyGPU v2.0 jest czymś więcej niż sprzętowym generatorem wzorów. Układ przyjmuje dane modeli i przetwarza geometrię przez rozpoznawalne etapy. Pozostaje jednak konstrukcją o stałej funkcjonalności, z rygorystycznymi ograniczeniami dotyczącymi rozmiaru sceny, jakości wyjścia i obsługiwanych efektów.

Podawany zakres liczby klatek na sekundę sięga około 7,5 do 15 przy odpowiednich scenach. Repozytorium dokumentuje również teksturowany przykład z 1 000 trójkątów działający z szybkością 6,5 FPS. Dane te opisują różne obciążenia, więc nie należy traktować ich jako sprzecznych, uniwersalnych benchmarków.

Liczba klatek na sekundę zależy od liczby trójkątów, widocznego obszaru, pracy tekstur, opóźnień pamięci i innych szczegółów sceny. Mały obiekt może wymagać mniej przetwarzania pikseli niż geometria pokrywająca większość wyświetlacza. Każde poważne porównanie wymaga identycznych modeli, ustawień, zegarów i warunków wyjścia.

Kontekst benchmarków pozostaje nadal niepełny. Film z krzemu potwierdza widoczne działanie, ale nie przedstawia szerokiego zestawu testów wydajności. Nie ustala również, czy podczas zarejestrowanego testu sprawdzono każdą udokumentowaną funkcję.

To właśnie tutaj określenie najmniejszego GPU wymaga ostrożności. „GPU” nie ma jednego progu liczby tranzystorów, a niezależne projekty hobbystyczne implementują różne podzbiory funkcji graficznych. Niektóre rysują tylko podstawowe prymitywy, podczas gdy inne obejmują transformacje, tekstury, oświetlenie lub programowalne etapy.

Tytuł jest zatem użytecznym skrótem, a nie znormalizowanym wyróżnieniem. Bardziej uzasadnionym wyróżnikiem TinyGPU jest połączenie wyprodukowanego krzemu z kompaktowym, samodzielnym potokiem 3D. Czytelnicy powinni oceniać udokumentowane funkcje, zamiast polegać wyłącznie na tym superlatywie.

To połączenie tworzy również wartość edukacyjną. Kod źródłowy udostępnia potok w Verilog, języku opisu sprzętu używanym do definiowania obwodów cyfrowych. Programiści mogą sprawdzić, jak pojęcia graficzne stają się maszynami stanów, jednostkami arytmetycznymi i transakcjami pamięciowymi.

Dla studentów znajomy obraz wizualny staje się w ten sposób wejściem do projektowania układów. Obracający się model jest łatwiejszy do zinterpretowania niż abstrakcyjny przebieg. Każda widoczna klatka nadal zależy jednak od tych samych zasad synchronizacji, weryfikacji i fizycznego projektowania, które stosuje się w większych układach.

Tiny Tapeout czyni lukę między prototypem a produkcją głównym polem rywalizacji

Główne zwycięstwo TinyGPU dotyczy bariery kosztów i koordynacji, która zwykle trzyma małe projekty sprzętowe z dala od wyprodukowanego krzemu.

Produkcja układów scalonych zwykle sprzyja organizacjom, które mogą wypełnić duży układ i zarządzać wyspecjalizowanymi procesami inżynieryjnymi. Samodzielny projektant rzadko potrzebuje całego wafla. Nawet niewielki układ eksperymentalny wiąże się z wymaganiami dotyczącymi przygotowania, obudowy, walidacji i produkcji.

Program współdzielonego wafla zmienia tę sytuację, umieszczając wiele małych projektów na tym samym wyprodukowanym układzie. Każdy uczestnik otrzymuje określony obszar kafelka. Wspólna infrastruktura obsługuje standardowe interfejsy, logikę wyboru i dostęp za pośrednictwem płytki demonstracyjnej.

Model ten przypomina współdzielony transport. Każdy projekt zajmuje tylko część dostępnego pojazdu, więc żaden uczestnik nie musi finansować całej podróży. Analogia nie jest doskonała, ale wyjaśnia, dlaczego wafle wieloprojektowe stały się wartościowe dla edukacji i eksperymentów.

TinyGPU v2.0 wykorzystuje przydział 4 na 4, równy 16 kafelkom Tiny Tapeout. To duży projekt w ramach kompaktowego modelu projektowego platformy. Przydział nadal zmusza Vichita do podejmowania decyzji, które zespół tworzący desktopowy GPU rozwiązałby za pomocą znacznie większej ilości krzemu.

Program narzuca także ograniczenia interfejsów. Zewnętrzna pamięć, wyjście wideo i wejście z kontrolera muszą przechodzić przez dostępne piny oraz obsługiwane płytki rozszerzeń. Ograniczenia te kształtują architekturę równie bezpośrednio jak liczba tranzystorów.

Proces zaczyna się na długo przed produkcją. Vichit musi opisać obwód w syntezowalnym Verilog, czyli kodzie, który narzędzia mogą przekształcić w rzeczywistą logikę. Zautomatyzowane kontrole weryfikują następnie interfejsy, założenia dotyczące synchronizacji i wymagania fizycznego projektu układu.

Synteza mapuje projekt na bibliotekę standardowych komórek. Rozmieszczenie przypisuje tym komórkom fizyczne położenia. Trasowanie łączy je metalowymi ścieżkami z uwzględnieniem reguł produkcyjnych. Gotowy layout trafia następnie do wspólnego tapeoutu wraz z innymi projektami.

Symulacja pozostaje niezbędna na każdym etapie tego procesu. Testbench dostarcza wejścia i sprawdza oczekiwane wyjścia przed produkcją. Prototypowanie na FPGA dodaje kolejną warstwę, uruchamiając podobną logikę na rekonfigurowalnym sprzęcie z rzeczywistymi urządzeniami peryferyjnymi.

Żaden z tych kroków nie przewiduje jednak idealnie zachowania krzemu. Trasowanie FPGA, bloki pamięci i parametry czasowe różnią się od procesu ASIC. Fizyczne układy wprowadzają także zachowania związane z zegarem, resetem, zasilaniem i integralnością sygnału, których uproszczone testy mogą nie wychwycić.

Dlatego działające wyjście po produkcji ma większą wagę niż kolejne wideo z FPGA. Wynik wskazuje, że przepływ narzędzi, współdzielona platforma, połączenie z płytką, pamięć zewnętrzna i logika graficzna zadziałały razem. Awaria dowolnego krytycznego ogniwa mogła uniemożliwić wyświetlenie obrazu.

Historyczne wyniki Tiny Tapeout zapewniają użyteczny kontekst. We wcześniejszych uruchomieniach na współdzielonym krzemie umieszczano procesory, generatory sygnału, wyświetlacze, akceleratory i eksperymentalne układy analogowe. Platforma nie jest przeznaczona wyłącznie dla grafiki, co czyni TinyGPU testem obciążeniowym jej ogólnego modelu projektowego.

Potok graficzny łączy obliczenia, sekwencjonowanie, ruch pamięci i rygorystyczne taktowanie wyświetlania. Utrata synchronizacji może uszkodzić cały obraz. Skuteczne skoordynowanie tych elementów sprawia, że projekt jest bogatszą demonstracją niż prosty licznik lub migające światło.

Mimo to współdzielony tapeout nie eliminuje ryzyka inżynieryjnego. Redystrybuuje on infrastrukturę i obniża próg wejścia. Projektanci nadal odpowiadają za poprawność funkcjonalną, czas działania, wykorzystanie zasobów oraz zachowanie otaczającego sprzętu.

Platforma nie może też sprawić, by ograniczony układ zachowywał się jak większy. Rozdzielczość TinyGPU, głębia kolorów, częstotliwość zegara i budżet sceny pozostają bezpośrednią konsekwencją jego wyborów projektowych. Dostępność nie usuwa związku między powierzchnią a możliwościami.

Presja spada zatem na tradycyjne założenia dotyczące tego, kto może wytworzyć interesujący procesor. TinyGPU nie wywiera presji na mapę produktową Nvidia. Podważa przekonanie, że niestandardowy krzem graficzny należy wyłącznie do dużych firm lub laboratoriów uniwersyteckich.

Ta zmiana ma konsekwencje wykraczające poza GPU. Małe, otwarte układy pozwalają deweloperom testować nietypowe akceleratory, interfejsy i procesory edukacyjne w ich finalnym fizycznym medium. Niektóre pomysły zawiodą, lecz ich porażki mogą stać się widocznym i powtarzalnym dowodem inżynieryjnym.

Czego demonstracja TinyGPU v2.0 nie dowodzi

Działające wyjście potwierdza podstawową funkcjonalność, ale nie stanowi pełnego benchmarku, dowodu gotowości produkcyjnej ani bezspornego rekordu świata.

Pierwsza niepewność dotyczy zakresu testów. Publiczne nagranie może pokazać model pojawiający się na monitorze i reagujący na wejście. Nie ujawnia jednak, czy każda ścieżka arytmetyczna, stan pamięci, orientacja trójkąta lub stan sterowania działa prawidłowo.

Kompleksowa walidacja wymagałaby wielu scen testowych i powtarzalnych pomiarów. Recenzenci potrzebowaliby również informacji o próbkach krzemu, stabilności zegara, napięciu, temperaturze, resetach i długotrwałej pracy. Wyniki te nie towarzyszyły początkowemu raportowi.

Druga niepewność dotyczy wydajności. Podawany zakres 7,5–15 FPS wydaje się zgodny z wcześniejszymi oczekiwaniami dla FPGA, lecz obciążenia silnie wpływają na wynik. Benchmark wymaga ustalonego modelu, kamery, tekstury, viewportu i metody pomiaru.

Zależność układu od zewnętrznej pamięci QSPI dodatkowo komplikuje interpretację. Opóźnienia pamięci mogą zatrzymywać lub regulować tempo różnych etapów potoku. Repozytorium dokumentuje nawet regulowane ustawienia opóźnienia dla podłączonego modułu pamięci.

Nie osłabia to projektu. Pamięć zewnętrzna jest uzasadnionym wyborem architektonicznym, zwłaszcza gdy pamięć na układzie zdominowałaby jego powierzchnię. Oznacza to jedynie, że określenia „samodzielny GPU” nie należy mylić z pojedynczym komponentem niewymagającym sprzętu pomocniczego.

GPU nadal potrzebuje pamięci, zegara, zasilania, połączeń wideo i sprzętu wejściowego. Procesory komercyjne również zależą od otaczających je systemów. W tym przypadku „samodzielny” oznacza, że potok graficzny działa w wyprodukowanej logice, a nie wewnątrz FPGA lub mikrokontrolera.

Trzecia niepewność to błąd viewportu udokumentowany przez Vichit. W v2.0 geometria wykraczająca poza widoczny viewport może zawiesić GPU i wymusić reset. Viewport definiuje prostokątny obszar ekranu, w którym powinna pojawić się scena.

To istotne ograniczenie dla ogólnego renderowania 3D. Kamery rutynowo przesuwają obiekty częściowo poza ekran. Procesor graficzny powinien przycinać lub odrzucać odpowiednią geometrię bez blokowania potoku.

Vichit twierdzi, że TinyGPU v3.0 rozwiązuje ten problem. Dopóki ta wersja nie zostanie opublikowana i przetestowana, poprawka pozostaje częścią mapy rozwoju. Ograniczenie to pokazuje również, dlaczego programowalny lub elastyczny sprzęt zwiększa wymagania dotyczące weryfikacji.

Czwarta kwestia dotyczy opisu „najmniejszy na świecie”. Wcześniejszy pierwszy projekt GPU Vichit wykorzystywał około 16 000 bramek i renderował tylko dwa teksturowane trójkąty. Inne małe układy graficzne wybierają odmienne kompromisy, co utrudnia bezpośrednie rankingi.

Wcześniejszy układ był przeznaczony do wyjścia 640 na 480 przy 60 FPS, co brzmi szybciej niż v2.0. Obsługiwał jednak radykalnie mniejszą scenę i nie miał zdolności v2.0 do pracy z plikami modeli zawierającymi do 1 000 trójkątów.

Ta pozorna sprzeczność pokazuje, dlaczego jednowymiarowe porównania zawodzą. Wyższa rozdzielczość lub liczba klatek na sekundę nie oznacza automatycznie bardziej zaawansowanej architektury. TinyGPU v2.0 obsługuje znacznie bogatszą geometrię przy niższej częstotliwości wyświetlania.

Współczesne GPU reprezentują przeciwległy biegun. Ich miliardy tranzystorów obsługują masowo równoległą arytmetykę, złożone harmonogramowanie, programowalne shadery, hierarchie pamięci podręcznej i pamięć o wysokiej przepustowości. TinyGPU celowo usuwa większość tych systemów.

Nvidia GeForce 256 stanowi bardziej trafne odniesienie historyczne niż współczesna karta do gier. Wprowadzony w 1999 roku, pomógł spopularyzować sprzętową transformację i oświetlenie jako definiującą funkcję GPU. TinyGPU odtwarza pokrewne koncepcje w skali eksperymentalnej.

Wspólna terminologia nie oznacza jednak porównywalnego zakresu możliwości. Sprzęt klasy GeForce był przeznaczony dla komercyjnych gier, zgodności z oprogramowaniem i stałych obciążeń klientów. TinyGPU jest otwartym projektem edukacyjnym, który ilustruje wybrane mechanizmy.

Tom Hardware trafnie przedstawia urządzenie jako osiągnięcie entuzjasty, a nie alternatywę zakupową. Najbardziej użyteczna interpretacja wynika z tego rozróżnienia. Jego znaczenie leży w widocznym krzemie i oszczędności architektonicznej, a nie w wydajności konsumenckiej.

Projekt zyskałby mocniejsze podstawy dowodowe dzięki powtarzalnym plikom testowym, zarejestrowanym warunkom zegarowym i wynikom z kilku układów. Niezależni konstruktorzy mogliby wtedy porównywać zachowanie sprzętu z symulacją i wynikami FPGA.

Open source umożliwia ten proces, lecz sama publikacja go nie kończy. Kod źródłowy pozwala na inspekcję. Powtarzalne testy sprzętowe przekształcają inspekcję w silniejszą weryfikację.

TinyGPU v3.0 sprawdzi, czy programowalność mieści się w tej samej niewielkiej formie

Kolejna wersja musi dodać elastyczność bez utraty zdyscyplinowanej prostoty, która pozwoliła v2.0 osiągnąć działający krzem.

Publiczna mapa rozwoju Vichit opisuje TinyGPU v3.0 jako przejście od stałego potoku w stronę programowalnego przetwarzania pikseli. Pixel shader to niewielki program obliczający kolor wyjściowy pikseli. Umożliwia efekty, których nie wyrażają stałe reguły oświetlenia i teksturowania.

Publiczne wpisy przypisywane Vichit opisują projekt inspirowany wczesnymi pixel shaderami DirectX 8. Proponowany rdzeń przetwarza równolegle cztery piksele, wykorzystując wykonanie jednej instrukcji na wielu danych. SIMD stosuje jedną instrukcję do kilku elementów danych jednocześnie.

Opisywany projekt wykorzystuje kompaktowy zestaw instrukcji i ograniczoną liczbę rejestrów tymczasowych. Maskowane wykonanie zapewnia ograniczoną metodę obsługi zachowania warunkowego. Wybory te mają zachować programowalność bez wprowadzania złożoności nowoczesnej architektury shaderów.

To właśnie ten mechanizm warto obserwować. Programowalność może zastąpić kilka stałych układów wielokrotnego użytku logiką arytmetyczną i sterującą. Może też wymagać pamięci instrukcji, dekodowania, rejestrów, harmonogramowania i bardziej rozległych testów zagrożeń.

V3.0 musi również rozwiązać problem viewportu. Vichit omawiał odrzucanie względem bliskiej i dalekiej płaszczyzny wraz z przycinaniem guard-band. Przycinanie guard-band dopuszcza współrzędne wykraczające poza widoczny obszar, zanim późniejsze etapy ograniczą piksele do ekranu.

Jeśli mechanizm ten zadziała, częściowo widoczne obiekty powinny przestać zawieszać procesor. Usprawnienie uczyni ruch kamery i ogólne sceny bardziej praktycznymi. Rozwiąże także wyraźnie udokumentowaną słabość v2.0, zamiast dodawać funkcje dla nich samych.

Najważniejsze są teraz trzy sygnały.

Po pierwsze, Vichit musi opublikować stabilną architekturę v3.0 i implementację nadającą się do syntezy. Opisy funkcji mogą się zmieniać podczas optymalizacji logiki. Publiczne repozytorium ujawniłoby rzeczywisty format instrukcji, potok i wykorzystanie zasobów.

Po drugie, projekt potrzebuje powtarzalnych wyników FPGA z użyciem scen, które jednocześnie obciążają przycinanie i wykonywanie shaderów. Utrzymanie liczby klatek przy prostym efekcie nie wystarczy. Testy powinny umieszczać geometrię na granicach ekranu, jednocześnie wykorzystując głębię i pamięć zewnętrzną.

Po trzecie, v3.0 ostatecznie potrzebuje kolejnego wyniku z krzemu. Sukces FPGA zweryfikowałby dużą część logiki, lecz główna lekcja v2.0 brzmi, że produkcja stanowi odrębny próg. Działający krzem A0 wzmocniłby twierdzenia nowej architektury.

Niepowodzenie na dowolnym etapie nadal dostarczyłoby użytecznych informacji. Przekroczenie budżetu kafelka ujawniłoby koszt powierzchniowy programowalności. Problemy czasowe wskazałyby wolne ścieżki. Błędy wizualne mogłyby ujawnić założenia dotyczące precyzji lub porządku pamięci.

Mapa rozwoju ma zatem znaczenie, nawet jeśli v3.0 nie zmieści się w planowanym oknie wydania w 2026 roku. Harmonogramy układów zależą od gotowości projektu i współdzielonych możliwości produkcyjnych. Opóźnienie byłoby mniej informacyjne niż jego przyczyna.

Czytelnicy powinni również powstrzymać się od traktowania v3.0 jako nieuniknionej linii produktowej. Nie ogłoszono rynku konsumenckiego, ekosystemu sterowników ani komercyjnego stosu oprogramowania. Projekt obecnie działa jako rozwój otwartego sprzętu i publiczny eksperyment.

To skupienie pozwala Vichit podejmować decyzje, których komercyjni producenci GPU nie mogą podejmować. Zgodność z istniejącymi grami jest niepotrzebna. Obsługa sterowników może pozostać ograniczona. Projekt może przedkładać przejrzystość i edukację wizualną nad wydajność ogólnego przeznaczenia.

Jednocześnie programowalność zaprosi do trudniejszych porównań. Gdy procesor będzie wykonywał instrukcje shaderów, deweloperzy zapytają o limity instrukcji, zachowanie rozgałęzień, dostęp do tekstur, precyzję i przepustowość. Każda odpowiedź tworzy kolejne zobowiązanie weryfikacyjne.

Osiągnięcie v2.0 nadaje tej mapie rozwoju wiarygodność, ponieważ jego poprzednik dotarł do krzemu i podobno wygenerował grafikę. Nie gwarantuje jednak, że v3.0 się zmieści, uruchomi lub zostanie pomyślnie wyprodukowany. Postęp sprzętowy pozostaje kumulatywny, lecz bezlitosny.

Dla deweloperów śledzących materiały Tom Hardware najlepszym kolejnym krokiem jest zbadanie otwartego projektu zamiast skupiania się na superlatywie. Porównajcie specyfikację repozytorium z przyszłymi benchmarkami, scenami testowymi i nagraniami z krzemu.

Trwała wartość TinyGPU będzie zależeć od tego, czy inni będą mogli odtwarzać, badać i rozwijać jego techniki. Pojedyncza udana demonstracja przyciąga uwagę. Udokumentowana weryfikacja przekształca tę uwagę w wiedzę inżynieryjną nadającą się do ponownego wykorzystania.

Warto obserwować, czy v3.0 zachowa wyraźny związek między każdą funkcją a jej kosztem sprzętowym. Jeśli elastyczność shaderów, przycinanie i równoległe przetwarzanie pikseli pozostaną zrozumiałe, projekt utrzyma swoją największą przewagę.

Najmniejszy użyteczny GPU nie musi być tym z najmniejszą liczbą tranzystorów. To ten, którego ograniczenia pokazują, jak naprawdę działa sprzęt graficzny. TinyGPU v2.0 osiągnął ten punkt w krzemie.

Teraz v3.0 musi pokazać, czy ta sama przejrzystość przetrwa w bardziej programowalnym potoku. To sprawdzian, a nie rywalizacja z desktopowymi GPU, wyznaczy kolejny rozdział projektu.