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
I don't need to Google. Anything built on the Unreal 3 engine has PhysX support built in.
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
They might have some incentive to now that AMD is both working with Havok and releasing Linux drivers with the new ATI card.
horror vacui
No, there are a few games which use the Unreal 3 engine:
Clicky
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
When we're talking about game worlds in which there could easily be 50 or 100 objects on the screen at once, it makes much more sense to have maybe one physics thread (separate from the render thread, and the AI thread) -- or maybe one per core. I very much doubt one real OS thread per object would work well at all.
Don't thank God, thank a doctor!
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.
The source engine, while "capable" of scaling to multiple cores, does a very poor job on current x86 chips. The games become very unstable with mat_queue_mode 2 on, and there are problems with jerky motion in any sort of latency.
It's a shame, too, because the engine works with multicore on various consoles, and it's a lot faster when it does work on PC.
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
Except that general purpose CPUs aren't really particularly great for raytracing. GPUs are simply special-purpose processors designed with raster graphics in mind. The newest fad is, of course, using all that special-purpose horsepower in more imaginative ways, but it's still a raster graphics processor at heart.
Why is it that they're raster graphic special purpose processors? Because raster dominates the playfield. What's the logical conclusion there? As soon as raytraced graphics engines start becoming popular enough to write a standard library for them, a la OpenGL or Direct3D, nVidia and ATI will be marketing special-purpose raytracing processors, and intel will either radically shift their core market (general purpose CPUs), or be in the same position as it is today relative to games. The raytracing push has nothing to do with intel wanting to keep its present product line relevant.