Slashdot Mirror
NVIDIA To Enable PhysX For Full Line of GPUs
MojoKid brings news from HotHardware that NVIDIA will be enabling PhysX for some of its newest graphics cards in an upcoming driver release. Support for the full GeForce 8/9 line will be added gradually. NVIDIA acquired PhysX creator AGEIA earlier this year.
Hardware accelerated physical acceleration, gravity and particlestuff if I remember correctly, atleast old examples used to be throwing away items or exploding walls and such.
http://en.wikipedia.org/wiki/PhysX
Realtime hardware accelerated physics. Used to be on a separate expensive board which few games supported but Nvidia are implementing it on CUDA so it can run on their graphic cards instead.
That's not true at all. It works in a single card configuration as well. Modern GPUs have more than enough spare parallel processing power to chug away at some physics operations. Guys are already modifying the beta drivers to test it out on their Geforce 8 cards. The OP in this thread is using a single card configuration:
http://forums.overclockers.com.au/showthread.php?t=689718
Reading comprehension...anything built on the Unreal 3 engine.
Like one of these many licensees:
http://www.unrealtechnology.com/news.php
Native PhysX Support:
http://www.theinquirer.net/en/inquirer/news/2007/05/30/unreal-3-thinks-threading
Yes, it works on one card. I have enabled it on my 8800GT earlier today. The CUDA/PhysX layer gets time-sliced access to the card. Yes, it will drop framerates by about 10%.
OTOH if you have 2 cards, you can dedicate one to CUDA and one to rendering so there won't be a hit. The cards need to NOT be in SLI (if they're in SLI, the driver sees only one GPU, and it will time-slice it like it does with a single card). This is actually the preferred configuration.
I hadn't known there were so many idiots in the world until I started using the Internet -Stanislaw Lem
Um, except if you you have exactly 1 physics thread you have to juggle complex scheduling considerations about who needs how much CPU, handle the prioritization against the render and AI threads, handle intermixing them, etc. You have to implement a task scheduler. ... which is exactly what Quake 1 did. Carmack wrote a userspace thread library, and spawned multiple threads. Since DOS didn't have threads this worked rather well.
An OS thread will give any thread a base priority, and then raise that priority every time it passes it over in the queue when it wants CPU time. It lowers the priority to the base when it runs. If a task sleeps, it gets passed over and left at lowest priority; if it wakes up and wants CPU, it climbs the priority tree. In this way, tasks which need a lot of CPU wind up getting run regularly-- as often as possible, actually-- and when multiple ones want CPU they're split up evenly.
If you make the render thread one thread, you have to implement this logic yourself. Further, the OS will see your thread as exactly one thread, and act accordingly. If you have 10000 physics objects and 15 AIs, keeping both threads CPU-hungry, then the OS will give 1/3 CPU to the physics engine; 1/3 CPU to the AI; and 1/3 CPU to the render thread. This means your physics engine starves, and your physics start getting slow and choppy well before you reach the physical limits of the hardware. The game breaks down.
You obviously don't understand either game programming or operating systems.
Support my political activism on Patreon.
You need the latest unreleased yet drivers for toe GTX2xx series, version 177.39. Then edit the nv4_disp.inf file and add an entry for device ID of 0611 (=8800GT). You will then be able to install the driver on the 8800GT. Next, install the new (also unreleased yet, but google is your friend) 8.06 software for PhysX. That's it.
I hadn't known there were so many idiots in the world until I started using the Internet -Stanislaw Lem