• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

NVIDIA Shows PhysX Comparison

As for your question, you don't need to do a thing. Just enable PhysX support in the drivers and you'll be using your GeForce for physics. Haven't seen it done with cards other than NVIDIA's, but it should work, because PhysX was ported to CUDA, which doesn't require SLI or anything like that to work. Just plug your card in a PCI-e slot, install PhysX drivers, enable the option and you should be set.

Absolutely..Depending on your GPU your performance obviuosly will vary.I think the benefits will come obviously when games start really making use of it.Benchies are one thing,but gameplay is more important.In Warmonger,running PhysX on my GTX280 only,nets me around~15-20fps less that running it on my 9800GT SC.With that said,its not like the performance on my GTX280 is shabby when running PhysX on it.It does free up resources using the second card.Hopefully,Mirrors Edge really shows what can be done and the performance will be clearer.Again,time will tell.
 
Silus, you are either very stupid or a terrible baiter.

I will not bother going through your wall of text however, in regard havoc, if you haven't noticed this whole discussion has been about hardware acceleration and alot of what i have been saying is about hardware tie-ins.

Havoc is part of a game, it is also hardware agnostic, it does not to my knowledge flag up what hardware is running it and make changes to what can and cannot be enabled.

We are discussing hardware, stop changing tact to it is up to the dev's to decide.
 
Silus, you are either very stupid or a terrible baiter.

I will not bother going through your wall of text however, in regard havoc, if you haven't noticed this whole discussion has been about hardware acceleration and alot of what i have been saying is about hardware tie-ins.

Havoc is part of a game, it is also hardware agnostic, it does not to my knowledge flag up what hardware is running it and make changes to what can and cannot be enabled.

We are discussing hardware, stop changing tact to it is up to the dev's to decide.

Neither does PhysX you idiot. PhysX API was ported to CUDA and everything is translated through the drivers. There's NOTHING hardware specific about it and that's why PhysX is more flexible in terms of hardware components where it can be executed - CPUs, CUDA ready GPUs and PPUs at this point - unlike Havok's API which can only be executed on the CPU! Since you don't READ people's posts, because you "don't bother", you're ignorant in such a simple thing, that's been explained a thousand times already.

Actually THINK before you TYPE! And I'm done with you. All I'm doing is losing my time...
 
No, i read your post, i just wasn't going ot respond to your wall of text in which you break down my post into points and respond to them out of context.

Cuda was designed for nvidia's hardware, it is not that general a GPGPU program from all i have read.

I would love to hear your arguments if ATI were the ones using physx, it would be very different trust me.
 
Neither does PhysX you idiot. PhysX API was ported to CUDA and everything is translated through the drivers. There's NOTHING hardware specific about it and that's why PhysX is more flexible in terms of hardware components where it can be executed - CPUs, CUDA ready GPUs and PPUs at this point - unlike Havok's API which can only be executed on the CPU! Since you don't READ people's posts, because you "don't bother", you're ignorant in such a simple thing, that's been explained a thousand times already.

Actually THINK before you TYPE! And I'm done with you. All I'm doing is losing my time...

really? is that why your resorting to name calling? being a fanboi is one thing there is no reason to be rabid about it.
 
I'm a little confused here. Are you saying that I can buy a cheap nVidia GeForce 9 graphics card and use it as a dedicated PhysX card?

Actually not only could you do that... but you could just use a single 8 series and up and do both Video and PhysX on one card. I have seen this situation first hand on a 8800GTX (running double duty) where it outshined the 8800GTX + PPU combo.
 
really? is that why your resorting to name calling? being a fanboi is one thing there is no reason to be rabid about it.

Right :rolleyes:
Did you even read to whom and what I was replying to ? Guess some people in here have a hard time reading other people's posts. Maybe you can evaluate who's the fanboy if you actually read...
 
As a game developer I can only say in response to the negative comments that if one were to really use PhysX to its full potential no one with an ATi GPU would be running the game, as the FPS at any resolution would be downright abysmal, like running the entire game on the CPU in a software renderer.

Blame AMD/ATi, not the game devs for not supporting a very useful technology. Yes, Havok is nice, but won't be hardware accelerated until 2010 at this rate, if ever.
 
Kinda like dx10 huh, nvidia don't support that, a nerfed version yes, but not what it was meant to be, so if dev's were to use dx10 properly no nvidia card would run it at all, would be slow on ati no doubt but they have the proper support at least.

You do come off as very naive with your post on this subject. (ye, ye say the same about me)
 
Kinda like dx10 huh, nvidia don't support that, a nerfed version yes, but not what it was meant to be, so if dev's were to use dx10 properly no nvidia card would run it at all, would be slow on ati no doubt but they have the proper support at least.

What are you on? NVidia supports DX10 just fine, only not 10.1.
 
My apologies, however, you shouldn't ignore the politics of these things. It would be great if companies were to try and benefit the customer by ensuring things are done to advance pc gaming and if they can't admit it, however they don't. Nvidia especially.
 
Well, I read plenty of videocard reviews, so if nVidia screwed up the DX10 implementation I think I should have heard about it. There was enough whining about nVidia not adding 10.1 support.
 
No, it is about the proposed dx10 and how the dx10 that was finally shipped was changed. Indeed, some of what dx10 was apparently meant to be was implemented in dx10.1(almost the true dx10) and other stuff left till 11.

True, getting actual proof for such claims may be difficult as none of the companies would admit to it, but ati's efforts is some circumstantial evidence of it, in that the dx10 they designed the R600 for, was not the dx10 that ended being needed.

People will scoff at these claims but there are plenty of people who shares these views.
 
To be honest I care little about DX anyway, as my company only works with OpenGL :)
 
Well, I read plenty of videocard reviews, so if nVidia screwed up the DX10 implementation I think I should have heard about it. There was enough whining about nVidia not adding 10.1 support.

Pay no attention to those rumblings. NVIDIA supports DX10 just fine and DX10.1 is just a minor upgrade. It's also a gimmick, since almost no games support it. Actually DX10 itself is a gimmick, since it wasn't adopted by many developers either.
 
Pay no attention to those rumblings. NVIDIA supports DX10 just fine and DX10.1 is just a minor upgrade. It's also a gimmick, since almost no games support it. Actually DX10 itself is a gimmick, since it wasn't adopted by many developers either.

Yeah, that's what my esteemed colleague (who wrote most of our game engine and tools) told me as well. That DX10 adds virtually nothing that is relevant and is more a DX9.1. 10.1 also merely adds a few things which have limited use.

Fortunately we're an OpenGL-only company ;)
 
That's funny, i have read that alot of people really like dx10, only thing they don't like is the fact that it is seperate from dx9, it is the legacy support that is the issue, from what i have read anyway.

Oh and silus, trust me. They support what they want to, neither company has supported all features of dx releases but nvidia more so only looks to what can be marketed, not what can be of actual use.

My opinion only of course.
 
Yeah, that's what my esteemed colleague (who wrote most of our game engine and tools) told me as well. That DX10 adds virtually nothing that is relevant and is more a DX9.1. 10.1 also merely adds a few things which have limited use.

Fortunately we're an OpenGL-only company ;)

Sounds like your esteemed colleague is an OpenGL fanboy :)
DX10 completely changes the way that renderstates are handled, greatly reducing CPU overhead.
Aside from that it adds a few very interesting new texture/rendertarget formats, allowing for higher quality and/or more efficient shadowmap and HDR processing, for example.
And then ofcourse there's geometry shaders (which OpenGL still doesn't have).
And ofcourse SM4.0 with various new things such as integer support.

So DX10 does add quite a bit of value.
DX10.1 doesn't add so much value, but that's why they called it DX10.1, not DX11. Still, the extensions to MSAA that DX10.1 offers are interesting for improving image quality and at the same time making AA processing more efficient.

Now let's discuss what OpenGL 3.0 has offered us over OpenGL 2.x :)
 
Oh and silus, trust me. They support what they want to, neither company has supported all features of dx releases but nvidia more so only looks to what can be marketed, not what can be of actual use.

In the case of DX10 the companies have no choice. Microsoft doesn't have any 'optional' features in DX10. You either have to support the full DX10 featuerset completely (which also includes meeting or exceeding the precision requirements).
So yes, all manufacturers support DX10 completely.
DX10.1 can be seen as an extension to DX10, but again the entire featureset of DX10.1 has to be supported. nVidia doesn't do this, although they do support some features through extensions to DX10.
 
So DX10 does add quite a bit of value.
DX10.1 doesn't add so much value, but that's why they called it DX10.1, not DX11. Still, the extensions to MSAA that DX10.1 offers are interesting for improving image quality and at the same time making AA processing more efficient.
Well, I didn't say it didn't add nothing at all over DX 9 :p I didn't know that they completely changed the rendering model, though.

Now let's discuss what OpenGL 3.0 has offered us over OpenGL 2.x :)

Oh, piles :) people mostly got pissed about a) backwards compatibility being present (you can also use the new mode, which is not BC but only FC) and b) the lack of transparancy (and the long delay) by Khronos.

Fortunately OGL is an open standard, so nVidia and ATi keep adding new extensions to OGL all the time. It is also still the only rendering API outside Windows (we target Windows/Linux/BSD/OS X with our games), which is one feature DX isn't likely to add any time soon :p
 
I didn't know that they completely changed the rendering model, though.

That was the biggest point of DX10. The Win2k/XP/DX9 driver model was running into serious CPU overhead problems.
OpenGL didn't have this problem as much, because pretty much the entire OGL API is implemented by the hardware vendor itself, so they can streamline the CPU overhead a bit.
With DX the API portion is static, and the driver interfaces at a lower level. This makes it much easier for hardware vendors to develop drivers. But because this interface was desinged years ago, with completely different types of GPUs, it was no longer sufficient.

Oh, piles :) people mostly got pissed about a) backwards compatibility being present (you can also use the new mode, which is not BC but only FC) and b) the lack of transparancy (and the long delay) by Khronos.

From what I understood, OpenGL 3.0 is little more than OpenGL 2.x with a bunch of common extensions now integrated into the core. Basically the same thing that they did with OpenGL 1.x -> 2.0.
In both cases they had big plans for completely revising the API, making it more streamlined, more userfriendly, more up-to-date etc... but in the end nothing really changed.

Fortunately OGL is an open standard, so nVidia and ATi keep adding new extensions to OGL all the time.

For me as a developer that is actually the biggest reason NOT to use OpenGL.
Because every vendor supplies their own incompatible extension to do the same basic functions, you end up having to write a lot of duplicate codepaths. Direct3D is much faster with adopting and standardizing new hardware features, so you never really have to worry about that sort of thing. Especially with DX10 it's one codepath for all.
I stopped using OpenGL years ago for any cutting-edge programming for exactly that reason. It just isn't worth the effort.

It is also still the only rendering API outside Windows (we target Windows/Linux/BSD/OS X with our games), which is one feature DX isn't likely to add any time soon :p

Depends on how you look at it. There are implementations of DirectX for Apple (see www.macdx.com) and Linux/BSD, such as Wine/WineX/Cedega etc.
Many game studios use these libraries to port their games. They seem to prefer it over developing with OpenGL for some reason.
You might argue that it's not a native implementation, but a wrapper around OpenGL... but that's just because there's no way the manifacturers will support yet another driver model for yet another OS.
Aside from that, there are bigger performance issues on these OSes than just a DX->Windows wrapper. Native OpenGL games such as Doom3 have shown that they can't match Windows performance either. There are still some bottlenecks in the linux kernel and driver model. Yet anothe reason why many developers don't care to develop games or other realtime interactive software for linux.
 
That was the biggest point of DX10. The Win2k/XP/DX9 driver model was running into serious CPU overhead problems.
OpenGL didn't have this problem as much, because pretty much the entire OGL API is implemented by the hardware vendor itself, so they can streamline the CPU overhead a bit.
With DX the API portion is static, and the driver interfaces at a lower level. This makes it much easier for hardware vendors to develop drivers. But because this interface was desinged years ago, with completely different types of GPUs, it was no longer sufficient.
I see, very interesting information :) I knew that in Vista the driver model had been completely changed, especially for GPUs. Apparently DX got a make-over at the same time :p

From what I understood, OpenGL 3.0 is little more than OpenGL 2.x with a bunch of common extensions now integrated into the core. Basically the same thing that they did with OpenGL 1.x -> 2.0.
In both cases they had big plans for completely revising the API, making it more streamlined, more userfriendly, more up-to-date etc... but in the end nothing really changed.
Actually they implemented a new mode in OGL 3. If you use it you can't use any old OGL 2 stuff. This is the forward compatibility mode :) In 3.1 it should get expanded a lot more and BC may get dropped in the process.

For me as a developer that is actually the biggest reason NOT to use OpenGL.
Because every vendor supplies their own incompatible extension to do the same basic functions, you end up having to write a lot of duplicate codepaths. Direct3D is much faster with adopting and standardizing new hardware features, so you never really have to worry about that sort of thing. Especially with DX10 it's one codepath for all.
I stopped using OpenGL years ago for any cutting-edge programming for exactly that reason. It just isn't worth the effort.
We're not using different code paths in our engine/games. It is true that for ultra-modern, totally up-to-date functions the implementations at both sides can differ, but if you don't try to chase the bleeding edge it's fairly safe. Survival of the fittest: one implementation wins, the other doesn't :)

However, it should be noted that DX 10 initially supported render-to-vertex buffer, which only worked on nVidia GPUs, so DX isn't immune to this either.

Depends on how you look at it. There are implementations of DirectX for Apple (see www.macdx.com) and Linux/BSD, such as Wine/WineX/Cedega etc.
Many game studios use these libraries to port their games. They seem to prefer it over developing with OpenGL for some reason.
You might argue that it's not a native implementation, but a wrapper around OpenGL... but that's just because there's no way the manifacturers will support yet another driver model for yet another OS.
Well, the thing is that these are not as elegant as using OGL directly. They'll also never be 100% compatible or up-to-date, and provide more overhead than a native API like OGL. I wouldn't feel comfortable using what seems like a hack to me (I have in-depth experience with Wine, especially the GDI and DX implementations).

Aside from that, there are bigger performance issues on these OSes than just a DX->Windows wrapper. Native OpenGL games such as Doom3 have shown that they can't match Windows performance either. There are still some bottlenecks in the linux kernel and driver model. Yet anothe reason why many developers don't care to develop games or other realtime interactive software for linux.
That's comparing apples to oranges.

Doom3 used a very unique rendering engine because Carmack refused to use what everyone else was. It used a lot of GPU bandwidth for things that normally don't, in some cases didn't even use custom shaders because they wanted to support really old GPU hardware. So it used register combiners for a lot of stuff, which are notoriously slower than custom shaders as they aren't as tailored to individual tasks.

Besides, DirectX has this silly call named DrawPrimitive () which is incredibly slow compared to the openGL equivalent, DrawRangeElements (). DrawPrimitive initiates a whole series of state changes... which is why they had to start an entire new method of instancing geometry to compensate.
 
I see, very interesting information :) I knew that in Vista the driver model had been completely changed, especially for GPUs. Apparently DX got a make-over at the same time :p

In fact, DX (and Aero) was the main reason why the driver model was changed.
Outside of video and audio drivers, not much has changed, and certain drivers work as-is in their XP form.
It also explains why it is not supported on XP. The XP kernel can't deal with the new DX10 drivers. Modifying the XP kernel to support it is not an option. Not only would it take a lot of resources to backport it... it would also most likely introduce incompatibilities with existing XP software and hardware.

Actually they implemented a new mode in OGL 3. If you use it you can't use any old OGL 2 stuff. This is the forward compatibility mode :) In 3.1 it should get expanded a lot more and BC may get dropped in the process.

That's the first I hear of this.
Are you referring to the new API codenamed Longs Peak? Because that was dropped.
As far as I know there is no new mode at all in OGL3, and I can't find any references on either the Khronos site nor Wikipedia.
Or are you talking about the new deprecation model? Which basically has little to do with any kind of 'mode'.

We're not using different code paths in our engine/games. It is true that for ultra-modern, totally up-to-date functions the implementations at both sides can differ, but if you don't try to chase the bleeding edge it's fairly safe. Survival of the fittest: one implementation wins, the other doesn't :)

You'll be developing for the lowest common denominator, which can be pretty dang low depending on what you're aiming for. For example, Intel's IGPs have very, VERY poor OpenGL support. On the other hand, they fully support DX9 and DX10.

However, it should be noted that DX 10 initially supported render-to-vertex buffer, which only worked on nVidia GPUs, so DX isn't immune to this either.

Not sure where you got that. I think you are referring to DX9, in which case you're right. The GPU in the XBox supports it (even through DX), but the regular Windows version of DX doesn't.
In DX10 however, there is no 'vertex buffer' anymore.
They abstracted the whole texture/vertex/backbuffer etc concept, and everything is now just a 'buffer'. So you can render to a buffer and then 'cast' it to a vertexbuffer and use it as such.

Well, the thing is that these are not as elegant as using OGL directly.

I wouldn't use the word 'elegant' in relation to OpenGL in the first place. The API isn't even object-oriented. It's all very archaic.
For a programmer, writing object-oriented D3D code might actually be the more elegant way. After all, he doesn't see what the wrapper does underneath, and doesn't have to care.

They'll also never be 100% compatible or up-to-date

Neither are different OpenGL implementations. In fact, OpenGL doesn't even have a strict definition of how to rasterize triangles (Direct3D does, so you are guaranteed to always render the same pixels on all WHQL-certified hardware).

and provide more overhead than a native API like OGL.

Which may or may not be an issue.

I wouldn't feel comfortable using what seems like a hack to me (I have in-depth experience with Wine, especially the GDI and DX implementations).

Well, many large game studios use it for commercial games. Just look at the games available for Mac. Most of them are not native OpenGL games, but Direct3D games ported to Mac using one of the various D3D wrappers on the market (there are companies specialized in porting these games, and they will in some cases create custom versions of the Wine libraries that work for a particular game).

Doom3 used a very unique rendering engine because Carmack refused to use what everyone else was. It used a lot of GPU bandwidth for things that normally don't, in some cases didn't even use custom shaders because they wanted to support really old GPU hardware. So it used register combiners for a lot of stuff, which are notoriously slower than custom shaders as they aren't as tailored to individual tasks.

How does that have anything to do with the fact that it performs better on Windows than on linux? All this is GPU-related, and you use the same GPU on both OSes.
Since it is OpenGL, pretty much all of the rendering API and driver is also supplied by the same manufacturer, and is most probably based on the same codebase.

Besides, DirectX has this silly call named DrawPrimitive () which is incredibly slow compared to the openGL equivalent, DrawRangeElements (). DrawPrimitive initiates a whole series of state changes... which is why they had to start an entire new method of instancing geometry to compensate.

I think you already forgot what I mentioned above about how DX10 changes the API to have lower CPU overhead for state changes and all that. That is exactly about this sort of thing.
Aside from that, Direct3D wasn't THAT much slower than OpenGL anyway. The way an OpenGL driver works allowed the developers to optimize their drivers a bit more, but state changes were still expensive because the OpenGL API doesn't quite handle state changes elegantly by itself. OpenGL drivers mostly rely on internal caching and heuristics to batch state changes together before feeding them to the GPU. nVidia used to have a huge advantage over other brands because they were the only ones with a really intelligent and optimized implementation of the OpenGL API, where most other drivers were rather dumb and bruteforce.
Even so, it all depends mostly on the programmer, and how smart he is at sending his data to the GPU (DrawPrimitive() itself is not the problem, changing states around all the time and using a lot of calls is). You can get OpenGL really slow aswell if you just render each triangle separately with some glVertex() calls (common mistake made by rookie OpenGL programmers... you can't make this mistake in D3D because it forces you to use vertexbuffers).
 
Back
Top