Marek <p...@s...com> writes:

>> Nie musimy zgadywać, wiadomo że tak jest, bo to jest esencja LUTa.
>> Gdyby tam tego nie było, nikt by tego nie nazwał LUTem.
>
> No chwila, a jak się ma do tego to co sam zauważyłeś, że scalak ma od
> groma pinów? Jaki jest ich cel?

Idea LUTa to jest np. taki EEPROM, ma np. 28 pinów w obudowie DIP28
i kasuje się go ultrafioletem. No dobrze, niech będzie flash i DIP40.
I tak kiedyś LUTy wyglądały (pomijając takie programowe, bo też są
używane).
W tej chwili nie opłaca się wstawiać osobnego scalaka do takich rzeczy
(są duże i musielibyśmy użyć ich sporo). Wstawia się ASIC, albo w wersji
eksperymentalnej np. FPGA, i to robi wszystko - oprócz LUTów także
np. skaluje obraz, ew. rozmywa go itd. Częścią takiego ASICa jest także
procesor, np. jakiś ARM albo inny microblaze, więc od razu mamy OSD i co
tam jeszcze trzeba. Pewnie dostajemy tam wejściowe i wyjściowe serdesy,
GPIO do mrugania lampkami, i jeśli nie potrzebujemy dużo RAMu ani
flasha, to nic (dużego) tam już nie musimy wkładać (no może jakiś układ
do wyłączania/włączania zasilania).

Usera to pewnie niespecjalnie interesuje, ale można łatwo otworzyć
obudowę i samemu obejrzeć. Tylko ostrożnie, i po wypięciu kabla
zasilającego.

> Dlatego stosuje się procesory sygnałowe. Zwykłe CPU nie mają tu
> zastosowania. Kiedyś (dawno temu) oprogramowywałem procesory sygnałowe
> związane z akustyką. Już wtedy bez problemu dawały one radę robić FFT
> 1024 punktowe w czasie rzeczywistym.

LUTów nie robi się na procesorach sygnałowych, bo i po co? FFT nie
zrobisz LUTem. LUTy sprawdzają się tam, gdzie masz stosunkowo mało bitów
wejściowych (niezależnych od wcześniejszych i późniejszych danych),
a w FFT używa się długich ciągów bitów.

No i wymagania akustyczne, nawet takie 7.1 96 kHz 24-bit są minimalnie
mniejsze niż w monitorze.

Tak samo np. skalera nie robi się jako LUT, bo skaler musi (typowo)
buforować dwie linie obrazu. Załatwia się to właśnie czymś w rodzaju
prostego DSP. Oczywiście nie jest to oddzielny scalak, bo i po co.

> Żadne procesor nie był w stanie
> dorównać. Zapewne w tej chwili różnice prędkości specjalizowanych
> procesorów są znacząco większe względem zwykłych. Patrz Open GL itp.

OpenGL akurat jest złym przykładem, jest zbyt specjalizowany. OpenCL
może. Z drugiej strony, zwykłe procesory także są w tym dużo szybsze
- SIMD oraz specjalizowane rozwiązania (np. crypto, video
encoding/decoding itd). Ale obawiam się, że optymalna implementacja LUTa
w monitorze to będzie jednak LUT.
--
Krzysztof Hałasa