a) starsze karty (serie poniżej gf 8k i radeon 4k) można olać... dużo prędzej niż np. XP (karty z obsługą cuda/opencl kosztują grosze).
b) takie GPU są i tak szybsze w obliczeniach fizyki niż procki i w wielu grach (nie liczących fizyki w osobnym wątku) i tak będzie zysk.
a)Słabsze karty (nie obsługujące dx10) posiada (wg steam) ponad 20% graczy. Niecałe 50% graczy posiada karty DX10 pod vistą/w7. 30% posiada karty dx10 ale pod xp, więc open cl w ogóle nie ma w tym przypadku racji bytu. Innymi słowy można stwierdzić, że ponad połowa graczy nie ma wsparcia ze strony openCL. (statystycznie oczywiście).
b) Nie widać tego po grach wspierających physX GPU. Poza tym, skoro karta nie najlepiej radzi sobie z samym wyświetlaniem grafiki, to dokładając do tego fizykę (nawet mało zaawansowaną) obniżasz ilośc FPS z powodu większej ilości obliczeń dla grafiki i mniejszej mocy do tego celu przeznaczonej.
a) OpenCL/Cuda/OpenGL 3.2 (z możliwościami dx10.1) działają na XP (tak jak na linuksie, macos, bsd i innych).
b) Co z tego, że karta ledwo sobie radzi z grafiką skoro w większości gier i tak z renderowaniem musi czekać na CPU (renderuje dopiero jak fizyka jest policzona), więc szybiej będzie jak fizykę będzie liczyć GPU, zamiast CPU (w czasie w którym gpu się nudzi czekając na dane - przykład nawet szybkich kart które działają powoli bo fizykę liczy CPU to GTA4).
chizra @ 2010.03.09 13:28
'59th Annual Technology & Engineering Emmy Awards for advancing the development of physics engines in electronic entertainment'
To, że nagroda jest za wkład w electronic entertainment czyli elektroniczną rozrywkę ( filmy, muzyka i gry ) ? Piszesz ze zmywaka, udajesz czy naprawdę coś z tobą nie tak ?
Tak tylko co z tego jak tu dostał przede wszystkim za filmy (za muzykę nie dostał, a za gry w minimalnym stopniu).
chizra @ 2010.03.09 13:28
Kto gra w te gry ? Pewnie wielbiciele pustych serwerów. Rankingi popularności poproszę. Nędzne i mało znane produkcje, które nawet by nie powstały, gdyby nie pieniądze nV.
Wiele osób gra w te gry i są to znane produkcje (m.in. wszystkie na silniku Unreal Engine 3).
skoti - mylisz się, już jakiś czas temu testowano jakie karty nv nadają się do liczenia fizyki (physx) w grach korzystających z akceleracji fizyki przez GPU. Nie ma sensu wydawać pieniędzy na nic poniżej 96 shaderowego 8800GS/9600GSO.
a)Słabsze karty (nie obsługujące dx10) posiada (wg steam) ponad 20% graczy. Niecałe 50% graczy posiada karty DX10 pod vistą/w7. 30% posiada karty dx10 ale pod xp, więc open cl w ogóle nie ma w tym przypadku racji bytu. Innymi słowy można stwierdzić, że ponad połowa graczy nie ma wsparcia ze strony openCL. (statystycznie oczywiście).
b) Nie widać tego po grach wspierających physX GPU. Poza tym, skoro karta nie najlepiej radzi sobie z samym wyświetlaniem grafiki, to dokładając do tego fizykę (nawet mało zaawansowaną) obniżasz ilośc FPS z powodu większej ilości obliczeń dla grafiki i mniejszej mocy do tego celu przeznaczonej.
a) OpenCL/Cuda/OpenGL 3.2 (z możliwościami dx10.1) działają na XP (tak jak na linuksie, macos, bsd i innych).
b) Co z tego, że karta ledwo sobie radzi z grafiką skoro w większości gier i tak z renderowaniem musi czekać na CPU (renderuje dopiero jak fizyka jest policzona), więc szybiej będzie jak fizykę będzie liczyć GPU, zamiast CPU (w czasie w którym gpu się nudzi czekając na dane - przykład nawet szybkich kart które działają powoli bo fizykę liczy GPU to GTA4).
chizra @ 2010.03.09 13:28
'59th Annual Technology & Engineering Emmy Awards for advancing the development of physics engines in electronic entertainment'
To, że nagroda jest za wkład w electronic entertainment czyli elektroniczną rozrywkę ( filmy, muzyka i gry ) ? Piszesz ze zmywaka, udajesz czy naprawdę coś z tobą nie tak ?
Tak tylko co z tego jak tu dostał przede wszystkim za filmy (za muzykę nie dostał, a za gry w minimalnym stopniu).
chizra @ 2010.03.09 13:28
Kto gra w te gry ? Pewnie wielbiciele pustych serwerów. Rankingi popularności poproszę. Nędzne i mało znane produkcje, które nawet by nie powstały, gdyby nie pieniądze nV.
Wiele osób gra w te gry i są to znane produkcje (m.in. wszystkie na silniku Unreal Engine 3).
Dałeś przykład GTA.. a ja dam jakąkolwiek grę z physX GPU, gdzie nawet mocna karta pokroju gtx260 nie daje rady. Sacred2 - w którym efekty wcale nie powalają daje mocno w kość karcie po włączeniu physX. na GTS250 z 44 (ograniczone przez CPU) robi nam się poniżej 20fps. W przypadku GTX280 wydajność bez physX GPU jest na podobnym poziomie, po włączeniu physx otrzymujemy niecałe 25fps. Dopiero po dołożeniu 9800GTX mamy akceptowalne 33fps.
a)Słabsze karty (nie obsługujące dx10) posiada (wg steam) ponad 20% graczy. Niecałe 50% graczy posiada karty DX10 pod vistą/w7. 30% posiada karty dx10 ale pod xp, więc open cl w ogóle nie ma w tym przypadku racji bytu. Innymi słowy można stwierdzić, że ponad połowa graczy nie ma wsparcia ze strony openCL. (statystycznie oczywiście).
b) Nie widać tego po grach wspierających physX GPU. Poza tym, skoro karta nie najlepiej radzi sobie z samym wyświetlaniem grafiki, to dokładając do tego fizykę (nawet mało zaawansowaną) obniżasz ilośc FPS z powodu większej ilości obliczeń dla grafiki i mniejszej mocy do tego celu przeznaczonej.
a) OpenCL/Cuda/OpenGL 3.2 (z możliwościami dx10.1) działają na XP (tak jak na linuksie, macos, bsd i innych).
b) Co z tego, że karta ledwo sobie radzi z grafiką skoro w większości gier i tak z renderowaniem musi czekać na CPU (renderuje dopiero jak fizyka jest policzona), więc szybiej będzie jak fizykę będzie liczyć GPU, zamiast CPU (w czasie w którym gpu się nudzi czekając na dane - przykład nawet szybkich kart które działają powoli bo fizykę liczy GPU to GTA4).
chizra @ 2010.03.09 13:28
'59th Annual Technology & Engineering Emmy Awards for advancing the development of physics engines in electronic entertainment'
To, że nagroda jest za wkład w electronic entertainment czyli elektroniczną rozrywkę ( filmy, muzyka i gry ) ? Piszesz ze zmywaka, udajesz czy naprawdę coś z tobą nie tak ?
Tak tylko co z tego jak tu dostał przede wszystkim za filmy (za muzykę nie dostał, a za gry w minimalnym stopniu).
chizra @ 2010.03.09 13:28
Kto gra w te gry ? Pewnie wielbiciele pustych serwerów. Rankingi popularności poproszę. Nędzne i mało znane produkcje, które nawet by nie powstały, gdyby nie pieniądze nV.
Wiele osób gra w te gry i są to znane produkcje (m.in. wszystkie na silniku Unreal Engine 3).
Grrrrr, no właśnie nie wszystkie gry na Unreal Engine 3 wykorzystują PhysX ( np. Blacksite: Area51 ), a na Unrealu Tournamencie 3, mimo zainstalowania Extreme Patcha i karty z PhysX ( wtedy był to 8800GTS 512 ) przynajmniej u mnie nie chodził, ale wiem też, że to nie był odosobniony przypadek
Nie, no proszę... TF2, L4D2, L4D i CS:S vs. te 'znane produkcje'
skoti - mylisz się, już jakiś czas temu testowano jakie karty nv nadają się do liczenia fizyki (physx) w grach korzystających z akceleracji fizyki przez GPU. Nie ma sensu wydawać pieniędzy na nic poniżej 96 shaderowego 8800GS/9600GSO.
Tak i o takich kartach mówię pisząc za grosze, bo cena karty graficznej która równa się cenie gry to grosze. Ale i nawet słabsze karty w fizyce radzą sobie lepiej niż procki (tylko mają więcej do liczenia niż procki w grach z akceleracją fizyki na GPU).
Amitoza @ 2010.03.09 14:01
Dałeś przykład GTA.. a ja dam jakąkolwiek grę z physX GPU, gdzie nawet mocna karta pokroju gtx260 nie daje rady. Sacred2 - w którym efekty wcale nie powalają daje mocno w kość karcie po włączeniu physX. na GTS250 z 44 (ograniczone przez CPU) robi nam się poniżej 20fps. W przypadku GTX280 wydajność bez physX GPU jest na podobnym poziomie, po włączeniu physx otrzymujemy niecałe 25fps. Dopiero po dołożeniu 9800GTX mamy akceptowalne 33fps.
Problem leży nie w GPU tylko w tym, że jak jest włączona akceleracja na GPU to gry liczą dużo więcej fizyki - w przypadku takich samych obliczeń mógłbyś mieć np. 44fps vs 60fps (lub gry CPU liczyłby to co GPU to 20fps vs 5fps).
chizra @ 2010.03.09 14:02
Grrrrr, no właśnie nie wszystkie gry na Unreal Engine 3 wykorzystują PhysX ( np. Blacksite: Area51 ), a na Unrealu Tournamencie 3, mimo zainstalowania Extreme Patcha i karty z PhysX ( wtedy był to 8800GTS 512 ) przynajmniej u mnie nie chodził, ale wiem też, że to nie był odosobniony przypadek
Nie, no proszę... TF2, L4D2, L4D i CS:S vs. te 'znane produkcje'
Dobra wszystkie bez wyjątków do policzenia na jednej ręce.
Brothers in Arms: Hell's Highway, Gears Of War, Gears Of War 2, Heavy Rain, Mass Effect, Mass Effect 2, Batman: Arkham Asylum, Mirror's Edge, Medal of Honor (cała seria i ten który ma się pojawić) i wiele innych vs te 'znane produkcje' z Havok
Problem leży nie w GPU tylko w tym, że jak jest włączona akceleracja na GPU to gry liczą dużo więcej fizyki - w przypadku takich samych obliczeń mógłbyś mieć np. 44fps vs 60fps (lub gry CPU liczyłby to co GPU to 20fps vs 5fps).
masz racje, ze wzrasta zlozonosc samej sceny i dlatego karta sie dusi, ale imho sama arch ukladu tez tutaj ma znacznie - obecne gpu nv nie moga liczyc roznych danych w tym samym czasie, wiec jak zapusczacz np. kod shader, no to rownolegle tez nie moze byc liczone physx/cuda. to jest tez jedna z glownych zmian w arch gf100/fermi i po pierwszych testach widac, ze to dziala. spadek framerate jest nizszy po zalaczneiu physx/cuda
Problem leży nie w GPU tylko w tym, że jak jest włączona akceleracja na GPU to gry liczą dużo więcej fizyki - w przypadku takich samych obliczeń mógłbyś mieć np. 44fps vs 60fps (lub gry CPU liczyłby to co GPU to 20fps vs 5fps).
masz racje, ze wzrasta zlozonosc samej sceny i dlatego karta sie dusi, ale imho sama arch ukladu tez tutaj ma znacznie - obecne gpu nv nie moga liczyc roznych danych w tym samym czasie, wiec jak zapusczacz np. kod shader, no to rownolegle tez nie moze byc liczone physx/cuda. to jest tez jedna z glownych zmian w arch gf100/fermi i po pierwszych testach widac, ze to dziala. spadek framerate jest nizszy po zalaczneiu physx/cuda
No nie wiem, bo z całą pewnością GTX275 rendering + 8500GT fizyka działa gorzej niż GTX275 rendering i fizyka. Opinie WIELU użytkowników tej pierwszej karty. Jak wcześniej napisałem - nie opłaca się zupełnie NIC poniżej 96SP 8800GS/9600GSO.
masz racje, ze wzrasta zlozonosc samej sceny i dlatego karta sie dusi, ale imho sama arch ukladu tez tutaj ma znacznie - obecne gpu nv nie moga liczyc roznych danych w tym samym czasie, wiec jak zapusczacz np. kod shader, no to rownolegle tez nie moze byc liczone physx/cuda. to jest tez jedna z glownych zmian w arch gf100/fermi i po pierwszych testach widac, ze to dziala. spadek framerate jest nizszy po zalaczneiu physx/cuda
Arch w Fermi wcale się tak nie zmieniło jak zapowiadano i też nie potrafi liczyć wszystkiego osobno (tylko tak jak dawniej MIMD jest nazwana jako cała karta, a tak naprawdę to SIMD jak wcześniej - każdy cuda core może wykonywać tylko jedną instrukcję (czyli 'wszystkie procki w Cuda core dodają x do y...', zamiast każdy robi swój program) - wprawdzie u nVidii jest to i tak lepiej niż u Amd gdzie w jednym Core jest 80 procków upchanych, ale w fermi tu się wiele nie zmieniło - dalej jest tak jak było).
Co do tego że karty nie mogą liczyć 2ch rzeczy na raz się mylisz (część cuda core może się zająć jednym, a druga część czymś innym (jak np. szadery wierzchołków, geometrii i pikseli działające równolegle)), ale to nie jest potrzebne w tym wypadku po wyrenderowaniu klatki gpu nic nie robi i musi czekać na CPU aż policzy fizykę i prześle to do GPU, a w tym czasie GPU mogłoby liczyć fizykę i czas oczekiwania by się skrócił.
Promilus1984 @ 2010.03.09 14:42
No nie wiem, bo z całą pewnością GTX275 rendering + 8500GT fizyka działa gorzej niż GTX275 rendering i fizyka.
Jest to możliwe:
275 renderuje (8500 nie robi nic) -> (275 czeka i nic nie robi) 8500 oblicza fizykę -> 275 renderuje (8500 nie robi nic)....
vs
275 renderuje -> 275 oblicza fizykę -> 275 renderuje...
jednak nawet w pierwszym wypadku gdyby fizyką zajmowałoby się CPU to wydajność byłaby jeszcze niższa.
Co do tego że karty nie mogą liczyć 2ch rzeczy na raz się mylisz
ale typ danych/wykonywany program jest identyczny. w femi mozesz zapuscic rownolegle rozne 'programy', a GTS odpowiednio bedzie zarzadzal zasobami GPU - nie bedzie systuacji, ze jeden 'program' bedzie musial czekac na drugi , az ten sie zakonczy. np. zapuszczacz CUDA, rownolegle sa robione shadery. sprawnosc ukladu przez to bardziej wzrosnie.
Co do tego że karty nie mogą liczyć 2ch rzeczy na raz się mylisz
ale typ danych/wykonywany program jest identyczny. w femi mozesz zapuscic rownolegle rozne 'programy', a GTS odpowiednio bedzie zarzadzal zasobami GPU - nie bedzie systuacji, ze jeden 'program' bedzie musial czekac na drugi , az ten sie zakonczy. np. zapuszczacz CUDA, rownolegle sa robione shadery. sprawnosc ukladu przez to bardziej wzrosnie.
Rozchodzi ci się o to, że Fermi niby do 16 kerneli naraz obsluguje?
Co do tego że karty nie mogą liczyć 2ch rzeczy na raz się mylisz
ale typ danych/wykonywany program jest identyczny. w femi mozesz zapuscic rownolegle rozne 'programy', a GTS odpowiednio bedzie zarzadzal zasobami GPU - nie bedzie systuacji, ze jeden 'program' bedzie musial czekac na drugi , az ten sie zakonczy. np. zapuszczacz CUDA, rownolegle sa robione shadery. sprawnosc ukladu przez to bardziej wzrosnie.
Dane mają inne - szadery wierzchołków mają inne dane wejściowe i wyjściowe niż fragmentów, a działają równolegle (sterowniki decydują który core będzie shaderem wierzchołków, a który fragmentów/geometrii). A co do tego co się dzieje w samym Core to dalej jeśli masz np. pętle i np. 1 procek z 80 (na przykładzie amd) będzie spełniał warunki pętli, a reszta nie, to i tak wszystkie muszą robić to co ten któremu akurat potrzeba coś obliczyć więcej (inne pracują na próżno, zamiast zająć się czymś innym) niestety i w Fermi Core działa tak jak działał - czyli może dostać jedną instrukcję dla wielu danych (SIMD), a nie wiele instrukcji dla wielu danych (MIMD).
Rozchodzi ci się o to, że Fermi niby do 16 kerneli naraz obsluguje?
tak
skoti48 @ 2010.03.09 15:21
niestety i w Fermi Core działa tak jak działał - czyli może dostać jedną instrukcję dla wielu danych (SIMD), a nie wiele instrukcji dla wielu danych (MIMD).
no i tutaj mam inne zdanie - stery definiuja, ale to GigaThread zarzadza w jak sposob sa wykonywane.
niestety i w Fermi Core działa tak jak działał - czyli może dostać jedną instrukcję dla wielu danych (SIMD), a nie wiele instrukcji dla wielu danych (MIMD).
no i tutaj mam inne zdanie - stery definiuja, ale to GigaThread zarzadza w jak sposob sa wykonywane.
Tu nie masz gdzie mieć inne zdanie - tak po prostu jest (poczytaj papierki nVidii) - jest 32 cuda core, każdy po 16 prockow (512 procków w sumie - te dane są prawdziwe jeśli specyfikacja oficjalnie potwierdzi w dniu premiery) i GigaThread może rozrzucać zadania po cuda core (tak jak się to działo do tej pory z shaderami), ale nie pozwala na wiele instrukcji w cuda core, który jest normalnym SIMD.
@SuLac0 - tak, ale to nvidia osiągnęła bez MIMD Po prostu jest przeprojektowanie zarządzanie wątkami by pozwolić kilku kernelom z tym samym 'context' (sry, nie jestem wysokopoziomowym programistom, rozumiem o co chodzi, ale nie wiem jak to na polski przełożyć ) pracę w tym samym czasie. Czyli kilka kerneli physx naraz na podanym przykładzie, ale już nie może to być w tym momencie cieniowanie jeśli dobrze rozumiem Znaczenie zasadniczo - chyba głównie w GPGPU.
Czyli kilka kerneli physx naraz na podanym przykładzie, ale już nie może to być w tym momencie cieniowanie jeśli dobrze rozumiem Znaczenie zasadniczo - chyba głównie w GPGPU.
w ten sposob tez mozna i dokladnie o to chodzi. no tak. efekt cuda/physx moze sie skladac z roznych 'kerneli' ( roznych mniejszych efektow), a te moga byc wykonywane rownolegle. zas wszystkie inne musza nadal byc 'kolejkowane', ale tez ich 'kernele' moga byc wykonywane rownolegle. troche mnie oswiecilo. nowy GT tez ma bardzo szybki 'przelacznik' i byc moze wlasnie to tez powoduje wzrost sprawnosci ukladu.
Kto gra w te gry ? Pewnie wielbiciele pustych serwerów. Rankingi popularności poproszę. Nędzne i mało znane produkcje...
http://www.nzone.com/object/nzone_physxgames_home.html
tutaj lista wspierająca physX gpu.
http://www.nzone.com/object/nzone_physxgames_all.html
a tutaj to co wspiera physX na cpu. (oczywiście uwzględniony każdy dodatek do gry, żeby było więcej
Taaa, czytałem już jakiś czas temu, ale dzięki
może trochę sie zapędziłem. Direct compute nie ma wsparcia pod xp.
a) starsze karty (serie poniżej gf 8k i radeon 4k) można olać... dużo prędzej niż np. XP (karty z obsługą cuda/opencl kosztują grosze).
b) takie GPU są i tak szybsze w obliczeniach fizyki niż procki i w wielu grach (nie liczących fizyki w osobnym wątku) i tak będzie zysk.
a)Słabsze karty (nie obsługujące dx10) posiada (wg steam) ponad 20% graczy. Niecałe 50% graczy posiada karty DX10 pod vistą/w7. 30% posiada karty dx10 ale pod xp, więc open cl w ogóle nie ma w tym przypadku racji bytu. Innymi słowy można stwierdzić, że ponad połowa graczy nie ma wsparcia ze strony openCL. (statystycznie oczywiście).
b) Nie widać tego po grach wspierających physX GPU. Poza tym, skoro karta nie najlepiej radzi sobie z samym wyświetlaniem grafiki, to dokładając do tego fizykę (nawet mało zaawansowaną) obniżasz ilośc FPS z powodu większej ilości obliczeń dla grafiki i mniejszej mocy do tego celu przeznaczonej.
a) OpenCL/Cuda/OpenGL 3.2 (z możliwościami dx10.1) działają na XP (tak jak na linuksie, macos, bsd i innych).
b) Co z tego, że karta ledwo sobie radzi z grafiką skoro w większości gier i tak z renderowaniem musi czekać na CPU (renderuje dopiero jak fizyka jest policzona), więc szybiej będzie jak fizykę będzie liczyć GPU, zamiast CPU (w czasie w którym gpu się nudzi czekając na dane - przykład nawet szybkich kart które działają powoli bo fizykę liczy CPU to GTA4).
'59th Annual Technology & Engineering Emmy Awards for advancing the development of physics engines in electronic entertainment'
To, że nagroda jest za wkład w electronic entertainment czyli elektroniczną rozrywkę ( filmy, muzyka i gry ) ? Piszesz ze zmywaka, udajesz czy naprawdę coś z tobą nie tak ?
Tak tylko co z tego jak tu dostał przede wszystkim za filmy (za muzykę nie dostał, a za gry w minimalnym stopniu).
Kto gra w te gry ? Pewnie wielbiciele pustych serwerów. Rankingi popularności poproszę. Nędzne i mało znane produkcje, które nawet by nie powstały, gdyby nie pieniądze nV.
Wiele osób gra w te gry i są to znane produkcje (m.in. wszystkie na silniku Unreal Engine 3).
skoti jestes jedna z niewielu osob tutaj, ktore wiedza o czym pisza a twoje komenty czytam z przyjemnoscia. Szacun
a)Słabsze karty (nie obsługujące dx10) posiada (wg steam) ponad 20% graczy. Niecałe 50% graczy posiada karty DX10 pod vistą/w7. 30% posiada karty dx10 ale pod xp, więc open cl w ogóle nie ma w tym przypadku racji bytu. Innymi słowy można stwierdzić, że ponad połowa graczy nie ma wsparcia ze strony openCL. (statystycznie oczywiście).
b) Nie widać tego po grach wspierających physX GPU. Poza tym, skoro karta nie najlepiej radzi sobie z samym wyświetlaniem grafiki, to dokładając do tego fizykę (nawet mało zaawansowaną) obniżasz ilośc FPS z powodu większej ilości obliczeń dla grafiki i mniejszej mocy do tego celu przeznaczonej.
a) OpenCL/Cuda/OpenGL 3.2 (z możliwościami dx10.1) działają na XP (tak jak na linuksie, macos, bsd i innych).
b) Co z tego, że karta ledwo sobie radzi z grafiką skoro w większości gier i tak z renderowaniem musi czekać na CPU (renderuje dopiero jak fizyka jest policzona), więc szybiej będzie jak fizykę będzie liczyć GPU, zamiast CPU (w czasie w którym gpu się nudzi czekając na dane - przykład nawet szybkich kart które działają powoli bo fizykę liczy GPU to GTA4).
'59th Annual Technology & Engineering Emmy Awards for advancing the development of physics engines in electronic entertainment'
To, że nagroda jest za wkład w electronic entertainment czyli elektroniczną rozrywkę ( filmy, muzyka i gry ) ? Piszesz ze zmywaka, udajesz czy naprawdę coś z tobą nie tak ?
Tak tylko co z tego jak tu dostał przede wszystkim za filmy (za muzykę nie dostał, a za gry w minimalnym stopniu).
Kto gra w te gry ? Pewnie wielbiciele pustych serwerów. Rankingi popularności poproszę. Nędzne i mało znane produkcje, które nawet by nie powstały, gdyby nie pieniądze nV.
Wiele osób gra w te gry i są to znane produkcje (m.in. wszystkie na silniku Unreal Engine 3).
a)Słabsze karty (nie obsługujące dx10) posiada (wg steam) ponad 20% graczy. Niecałe 50% graczy posiada karty DX10 pod vistą/w7. 30% posiada karty dx10 ale pod xp, więc open cl w ogóle nie ma w tym przypadku racji bytu. Innymi słowy można stwierdzić, że ponad połowa graczy nie ma wsparcia ze strony openCL. (statystycznie oczywiście).
b) Nie widać tego po grach wspierających physX GPU. Poza tym, skoro karta nie najlepiej radzi sobie z samym wyświetlaniem grafiki, to dokładając do tego fizykę (nawet mało zaawansowaną) obniżasz ilośc FPS z powodu większej ilości obliczeń dla grafiki i mniejszej mocy do tego celu przeznaczonej.
a) OpenCL/Cuda/OpenGL 3.2 (z możliwościami dx10.1) działają na XP (tak jak na linuksie, macos, bsd i innych).
b) Co z tego, że karta ledwo sobie radzi z grafiką skoro w większości gier i tak z renderowaniem musi czekać na CPU (renderuje dopiero jak fizyka jest policzona), więc szybiej będzie jak fizykę będzie liczyć GPU, zamiast CPU (w czasie w którym gpu się nudzi czekając na dane - przykład nawet szybkich kart które działają powoli bo fizykę liczy GPU to GTA4).
'59th Annual Technology & Engineering Emmy Awards for advancing the development of physics engines in electronic entertainment'
To, że nagroda jest za wkład w electronic entertainment czyli elektroniczną rozrywkę ( filmy, muzyka i gry ) ? Piszesz ze zmywaka, udajesz czy naprawdę coś z tobą nie tak ?
Tak tylko co z tego jak tu dostał przede wszystkim za filmy (za muzykę nie dostał, a za gry w minimalnym stopniu).
Kto gra w te gry ? Pewnie wielbiciele pustych serwerów. Rankingi popularności poproszę. Nędzne i mało znane produkcje, które nawet by nie powstały, gdyby nie pieniądze nV.
Wiele osób gra w te gry i są to znane produkcje (m.in. wszystkie na silniku Unreal Engine 3).
Grrrrr, no właśnie nie wszystkie gry na Unreal Engine 3 wykorzystują PhysX ( np. Blacksite: Area51 ), a na Unrealu Tournamencie 3, mimo zainstalowania Extreme Patcha i karty z PhysX ( wtedy był to 8800GTS 512 ) przynajmniej u mnie nie chodził, ale wiem też, że to nie był odosobniony przypadek
Nie, no proszę... TF2, L4D2, L4D i CS:S vs. te 'znane produkcje'
Tak i o takich kartach mówię pisząc za grosze, bo cena karty graficznej która równa się cenie gry to grosze. Ale i nawet słabsze karty w fizyce radzą sobie lepiej niż procki (tylko mają więcej do liczenia niż procki w grach z akceleracją fizyki na GPU).
Problem leży nie w GPU tylko w tym, że jak jest włączona akceleracja na GPU to gry liczą dużo więcej fizyki - w przypadku takich samych obliczeń mógłbyś mieć np. 44fps vs 60fps (lub gry CPU liczyłby to co GPU to 20fps vs 5fps).
Grrrrr, no właśnie nie wszystkie gry na Unreal Engine 3 wykorzystują PhysX ( np. Blacksite: Area51 ), a na Unrealu Tournamencie 3, mimo zainstalowania Extreme Patcha i karty z PhysX ( wtedy był to 8800GTS 512 ) przynajmniej u mnie nie chodził, ale wiem też, że to nie był odosobniony przypadek
Nie, no proszę... TF2, L4D2, L4D i CS:S vs. te 'znane produkcje'
Dobra wszystkie bez wyjątków do policzenia na jednej ręce.
Brothers in Arms: Hell's Highway, Gears Of War, Gears Of War 2, Heavy Rain, Mass Effect, Mass Effect 2, Batman: Arkham Asylum, Mirror's Edge, Medal of Honor (cała seria i ten który ma się pojawić) i wiele innych vs te 'znane produkcje' z Havok
Kto gra w te gry ? Pewnie wielbiciele pustych serwerów. Rankingi popularności poproszę. Nędzne i mało znane produkcje...
http://www.nzone.com/object/nzone_physxgames_home.html
tutaj lista wspierająca physX gpu.
http://www.nzone.com/object/nzone_physxgames_all.html
a tutaj to co wspiera physX na cpu. (oczywiście uwzględniony każdy dodatek do gry, żeby było więcej
To co wy mi tu wciskacie, że Havok nie prowadzi w popularności?
Problem leży nie w GPU tylko w tym, że jak jest włączona akceleracja na GPU to gry liczą dużo więcej fizyki - w przypadku takich samych obliczeń mógłbyś mieć np. 44fps vs 60fps (lub gry CPU liczyłby to co GPU to 20fps vs 5fps).
masz racje, ze wzrasta zlozonosc samej sceny i dlatego karta sie dusi, ale imho sama arch ukladu tez tutaj ma znacznie - obecne gpu nv nie moga liczyc roznych danych w tym samym czasie, wiec jak zapusczacz np. kod shader, no to rownolegle tez nie moze byc liczone physx/cuda. to jest tez jedna z glownych zmian w arch gf100/fermi i po pierwszych testach widac, ze to dziala. spadek framerate jest nizszy po zalaczneiu physx/cuda
Problem leży nie w GPU tylko w tym, że jak jest włączona akceleracja na GPU to gry liczą dużo więcej fizyki - w przypadku takich samych obliczeń mógłbyś mieć np. 44fps vs 60fps (lub gry CPU liczyłby to co GPU to 20fps vs 5fps).
masz racje, ze wzrasta zlozonosc samej sceny i dlatego karta sie dusi, ale imho sama arch ukladu tez tutaj ma znacznie - obecne gpu nv nie moga liczyc roznych danych w tym samym czasie, wiec jak zapusczacz np. kod shader, no to rownolegle tez nie moze byc liczone physx/cuda. to jest tez jedna z glownych zmian w arch gf100/fermi i po pierwszych testach widac, ze to dziala. spadek framerate jest nizszy po zalaczneiu physx/cuda
No nie wiem, bo z całą pewnością GTX275 rendering + 8500GT fizyka działa gorzej niż GTX275 rendering i fizyka. Opinie WIELU użytkowników tej pierwszej karty. Jak wcześniej napisałem - nie opłaca się zupełnie NIC poniżej 96SP 8800GS/9600GSO.
Arch w Fermi wcale się tak nie zmieniło jak zapowiadano i też nie potrafi liczyć wszystkiego osobno (tylko tak jak dawniej MIMD jest nazwana jako cała karta, a tak naprawdę to SIMD jak wcześniej - każdy cuda core może wykonywać tylko jedną instrukcję (czyli 'wszystkie procki w Cuda core dodają x do y...', zamiast każdy robi swój program) - wprawdzie u nVidii jest to i tak lepiej niż u Amd gdzie w jednym Core jest 80 procków upchanych, ale w fermi tu się wiele nie zmieniło - dalej jest tak jak było).
Co do tego że karty nie mogą liczyć 2ch rzeczy na raz się mylisz (część cuda core może się zająć jednym, a druga część czymś innym (jak np. szadery wierzchołków, geometrii i pikseli działające równolegle)), ale to nie jest potrzebne w tym wypadku po wyrenderowaniu klatki gpu nic nie robi i musi czekać na CPU aż policzy fizykę i prześle to do GPU, a w tym czasie GPU mogłoby liczyć fizykę i czas oczekiwania by się skrócił.
No nie wiem, bo z całą pewnością GTX275 rendering + 8500GT fizyka działa gorzej niż GTX275 rendering i fizyka.
Jest to możliwe:
275 renderuje (8500 nie robi nic) -> (275 czeka i nic nie robi) 8500 oblicza fizykę -> 275 renderuje (8500 nie robi nic)....
vs
275 renderuje -> 275 oblicza fizykę -> 275 renderuje...
jednak nawet w pierwszym wypadku gdyby fizyką zajmowałoby się CPU to wydajność byłaby jeszcze niższa.
ale typ danych/wykonywany program jest identyczny. w femi mozesz zapuscic rownolegle rozne 'programy', a GTS odpowiednio bedzie zarzadzal zasobami GPU - nie bedzie systuacji, ze jeden 'program' bedzie musial czekac na drugi , az ten sie zakonczy. np. zapuszczacz CUDA, rownolegle sa robione shadery. sprawnosc ukladu przez to bardziej wzrosnie.
ale typ danych/wykonywany program jest identyczny. w femi mozesz zapuscic rownolegle rozne 'programy', a GTS odpowiednio bedzie zarzadzal zasobami GPU - nie bedzie systuacji, ze jeden 'program' bedzie musial czekac na drugi , az ten sie zakonczy. np. zapuszczacz CUDA, rownolegle sa robione shadery. sprawnosc ukladu przez to bardziej wzrosnie.
Rozchodzi ci się o to, że Fermi niby do 16 kerneli naraz obsluguje?
ale typ danych/wykonywany program jest identyczny. w femi mozesz zapuscic rownolegle rozne 'programy', a GTS odpowiednio bedzie zarzadzal zasobami GPU - nie bedzie systuacji, ze jeden 'program' bedzie musial czekac na drugi , az ten sie zakonczy. np. zapuszczacz CUDA, rownolegle sa robione shadery. sprawnosc ukladu przez to bardziej wzrosnie.
Dane mają inne - szadery wierzchołków mają inne dane wejściowe i wyjściowe niż fragmentów, a działają równolegle (sterowniki decydują który core będzie shaderem wierzchołków, a który fragmentów/geometrii). A co do tego co się dzieje w samym Core to dalej jeśli masz np. pętle i np. 1 procek z 80 (na przykładzie amd) będzie spełniał warunki pętli, a reszta nie, to i tak wszystkie muszą robić to co ten któremu akurat potrzeba coś obliczyć więcej (inne pracują na próżno, zamiast zająć się czymś innym) niestety i w Fermi Core działa tak jak działał - czyli może dostać jedną instrukcję dla wielu danych (SIMD), a nie wiele instrukcji dla wielu danych (MIMD).
Rozchodzi ci się o to, że Fermi niby do 16 kerneli naraz obsluguje?
tak
no i tutaj mam inne zdanie - stery definiuja, ale to GigaThread zarzadza w jak sposob sa wykonywane.
no i tutaj mam inne zdanie - stery definiuja, ale to GigaThread zarzadza w jak sposob sa wykonywane.
Tu nie masz gdzie mieć inne zdanie - tak po prostu jest (poczytaj papierki nVidii) - jest 32 cuda core, każdy po 16 prockow (512 procków w sumie - te dane są prawdziwe jeśli specyfikacja oficjalnie potwierdzi w dniu premiery) i GigaThread może rozrzucać zadania po cuda core (tak jak się to działo do tej pory z shaderami), ale nie pozwala na wiele instrukcji w cuda core, który jest normalnym SIMD.
Tu nie masz gdzie mieć inne zdanie
no coz. widoczniei ja rozumiem to troche inaczej
http://www.nvidia.com/object/IO_86776.html
str 18.
w ten sposob tez mozna