Przy instalacji Windows XP 32bit, po podaniu kilku informacji - następuje błyskawiczny proces instalacji systemu (nie ma żadnych dodatkowych pytań itp.). To samo miało miejsce przy instalacji Solarisa 10 64bit, podobno ma to miejsce przy systemach linuks, ale tylko w wybranych dystrybucjach np. Ubuntu.
Pozostaje również możliwość instalacji systemu jak wcześniej czyli krok po kroku.
Wg DAK system mocno przyspieszył działanie, co prawda za wcześnie na przeprowadzenie dokładnych testów, ale na oko wzrost wydajności maszyny wirtualnej w niektórych operacjach sięga nawet 100%!
Wprowadzono zgodność z DirectX9 i 3D. W stosunku do DX 9.0c to błędnie działa jedna z funkcji API, więc DAK szacuje że jest to bardziej DX 9.0b niż 9.0c. Widoczna aplikacja osiąga mniej więcej 1/5 wydajności (w stosunku do real) oraz działa to do rozdzielczości 1024x768 (np. widoczne dość pamięciożerne demko HDR).
Jednak biorąc pod uwagę nasze niepowodzenia w ostatnich testach jakie przeprowadzaliśmy (o czym częściowo wspominałem w tym miejscu), to i tak jest to bardzo dużo i chętnie samodzielnie przeprowadzę kilka testów, wydajności i zgodności.
Dzięki za info, jak widać jest to istotny krok w rozwoju i to we właściwym kierunku:)
Update:
DAK przesłał nam dodatkowe ciekawe uwagi - dzięki !:)
Ograniczenia w możliwych do wykorzystania rozdzielczościach wynikają jedynie z małej przestrzeni pamięci VRAM. O ile dany program nie przepełni jej to będzie działał, jeśli nie działa to trzeba mu ustawić mniejszą rozdzielczość, przy której nie będzie potrzebował alokować zbyt dużych obszarów VRAM.
Bez problemu można też korzystać z innych rozdzielczości np. o proporcjach 16:9, a także tych które są niestandardowe.
Dalej DAK informuje: "Po kilku wygibasach z maszyną i programikiem HDR udało mi się zmniejszyć zapotrzebowanie na pamięć video (na załączonych scr widać jak demko alokuje pamięć vir video (ma jej do dyspozycji tylko 128MB - co również świetnie widać na scr)) w różnych rozdzielczościach i co ciekawe z włączonym AAx4 jeszcze udało mi się w miarę wyrobić zostało jeszcze ponad 20MB (oczywiście w zależności od złożoności obiektu poddawanego obróbce).
Jak widać np. demko Azure Temple jest bardzo mocno pamięciożerne, gdyż uruchomienie go w 640x480 powoduje praktycznie zużycie pamięci na bufor ramki i tekstury w całości. Każda próba zwiększenia rozdzielczości powoduje wyczerpanie pamięci i przerwanie działania programu.
Nie ma tu niestety możliwości adresowania dodatkowej pamięci jak ma to miejsce w przypadku AGP czy PCI-expres.
Dowodzi to jednak, że starsze programy i gierki będą świetnie działały w rozdzielczościach wysokich, aż do wyczerpania pamięci na bufor ramki.
Co do zgodności z SM3.0 (dx 9.0c -- to błędy w generowaniu demka Azure Temple mówią wystarczająco dużo)."
Dzięki DAK!:)
Brak komentarzy:
Prześlij komentarz