To jest właśnie ten przypadek, który opisałem w poście powyżej. ;)

Reasumując, Glide to API tylko w którym się mówi co ma być rasteryzowane, w którym miejscu i w jaki sposób. Wszelkie operacje transformacji są po stronie aplikacji, często wykorzystywaną biblioteką była tlib dostarczana przez 3DFX będąca programową implementacją operacji na macierzach, jest ona linkowana statycznie. Innym przypadkiem jest napisanie własnego kodu implementującego te operacje przez twórcę aplikacji, lecz nadal jest to kod linkowany statycznie i działa to tak samo jak użycie tlib.

Osoba, która skompilowała ze źródeł Glide tylko ustawiła w kompilatorze flagi optymalizacyjne dla konkretnego procesora, w tym wypadku AMD K6-2 z dodatkowym zestawem instrukcji SIMD 3D Now!, jednak jak wcześniej wspomniałem nie implikuje to tego że w ogóle te instrukcje zostały wykorzystane podczas generowania kodu przez kompilator. Dlaczego? Dlatego, że tam nie ma jak wykorzystać tych instrukcji. Jedyne operacje na wierzchołkach to min. clipping oraz konwersja i upakowanie do wewnętrznego "formatu" jak i przekazanie do układu graficznego. Jeżeli mi nie wierzysz to możesz zrobić disasm binarki i zobaczysz że te instrukcje nie zostały praktycznie wykorzystane.

Jeżeli chodzi o SIMD to nie jest tak różowo, nawet BARDZO przydatne SSE/SSE2 musi zostać sprytnie wykorzystane żeby odczuć przyrost wydajności. Zmiana flagi w kompilatorze nie sprawi, że coś magicznie zostanie zoptymalizowane. Aczkolwiek dzisiejsze kompilatory są już naprawdę mądre (zastosowanie metod heurystycznych) i nie jest już to do końca prawdą.