New nVidia drivers to have more peformance, dual-core support!

[herulach]

The question still stands then, i arent trying to start an argument, i honestly wouldnt have thought that graphics card drivers did very many things on the cpu, surely thats the entire point of graphics cards? Or am i missing something blindingly obvious?

[dangel]

The question still stands then, i arent trying to start an argument, i honestly wouldnt have thought that graphics card drivers did very many things on the cpu, surely thats the entire point of graphics cards? Or am i missing something blindingly obvious?

Yes the card offloads the job of rendering the graphics, but it's till got to be fed geometry information to do it - and that's the job of the cpu (as the game engine runs on your CPU!) as well as all the non-graphic related tasks. That's why a faster cpu will result in better framerates on high end graphic cards..

[herulach]

Yes the card offloads the job of rendering the graphics, but it's till got to be fed geometry information to do it - and that's the job of the cpu (as the game engine runs on your CPU!) as well as all the non-graphic related tasks. That's why a faster cpu will result in better framerates on high end graphic cards..

I realise that, but surely the geometry is done by the game engine?

[sawyen]

Its definitely kudos for Nv to include these performance boost drivers for us, but the graphical issues that resulted from that extra 10fps (at the moment) isn't really worth it. Until they sort out all the bits and pieces (like my GTR crashes), its really a hit and miss thingy..

I also agree that optimising the support for dual core processors are the thing now.. splitting work load to different cores would (in theory) significantly reduce data latencies hence better performance. Its really an idle power sitting there waiting to be unleashed.

[dangel]

I realise that, but surely the geometry is done by the game engine?

Ok, bad choice of words but how does "vertex data" sound? It's still got to b e calculated but the game engine, on the cpu, before being fired off to the gpu to do it's funky stuff

[dangel]

Its definitely kudos for Nv to include these performance boost drivers for us, but the graphical issues that resulted from that extra 10fps (at the moment) isn't really worth it. Until they sort out all the bits and pieces (like my GTR crashes), its really a hit and miss thingy..

I also agree that optimising the support for dual core processors are the thing now.. splitting work load to different cores would (in theory) significantly reduce data latencies hence better performance. Its really an idle power sitting there waiting to be unleashed.

I guess until we have the finals it's not fair to judge them..

[sawyen]

I guess until we have the finals it's not fair to judge them..

fair enuf.. but for now the beta only works fine for cetain games.. hope the 80 series drivers arrive soon..

[kempez]

I got a decent boost using these drivers in games and benchmarks. BUT I got artifacts when the CPU was being heavily used (3DMark03 CPU test). Apart from that everything ran ok.

I still rolled back after a while and I will await the final drivers with baited breath

[shaithis]

x64 version now released/leaked:

http://downloads.guru3d.com/download.php?id=28

Still get the same artifacts in 3D Mark though......I guess its somewhat encouraging that the same problems are evident in both the 32 and 64 bit drivers.

[StormPC]

To say "MULTI-THREADED video-drivers are rediculous. They will run like crap on a single-core system, as will multi-threaded games." is to completely misunderstand how threading works on a modern operating system and how 3D graphics drivers are already multi-threaded anyway.

It's ridiculous that you keep crapping all over threads in my forum with your constant tirades about dual-core. Enough of the aggressive tone and nature of your posts about dual-core or I'll find you a forum that only you have posting rights for and you can sit and crap all over yourself.

Everyone: Stay on topic or I'll summon Zak and his enormous ban hammer.

If you want to look at it that way, Windows is a multi-threaded operating system. How many programs run as soon as windows boots up? Anywhere from 20 to 1000 depending on what you have on your computer (whether you wanted it there or not).

Obviously when I talk about multi-threading as it relates to multi-core CPUs I am talking about CPU INTENSIVE threads, not every program resident in memory.

When a single-core system runs more than one CPU INTENSIVE thread it runs like crap compared to a multi-CPU or multi-core system.

The reason this thread is stupid is that most videogames these days are 90% videocard anyway. The CPU doesn't enter into it at all as long as you have something more current than a P4.

You know I don't do this in every thread RYS, but you do what your heart tells you. I don't give a rats arse. Never have and never will!

[dangel]

"I don't give a rats arse. Never have and never will!"

I pity you. How sad.

I'm sorry but all you come across as being is as someone convinced they know it all, without actually possessing either the knowledge or the facts to back anything up. This is the second time you've done your best to drill this thread into the ground - are you so ignorant as to feel that if you shout the loudest then everyone else will listen to you more? Calm the heck down, _listen_ to others and you might learn something you don't already know.

[Snoopafella]

Well Storm you actually do this in every thread. You have the attitude that you’re always right and never seem to acknowledge anybody else that makes a valid point. The whole I don't give a **** attitude doe4sn't wash. As you actually otherwise you would actually be arguing at EVERY opportunity. I do hope that one day your balls actually drop and you are mature enough to make a concise argument and except your not always right.

[sawyen]

Remember Zak's ban hammer everyone.. remember.. remember...

[Butcher]

Ok, bad choice of words but how does "vertex data" sound? It's still got to b e calculated but the game engine, on the cpu, before being fired off to the gpu to do it's funky stuff

Actually the vertex data passes more-or-less untounched from memory to the GPU on a modern card. It;s the vertex shaders on the GPU that do most of the processing there.

What CPUs actually do in graphics drivers is mainly data movement (i.e. shovelling data at the GPU and sending command streams). In some cases unsupported features can be emulated on the CPU if neccessary (including but not limited to, vertex shaders, higher-order primitives (bezier patches and whatnot), displacement mapping). Most games will not use a feature they don't have hardware for though as it's too expensive. Also drivers will do any format conversion needed, for instance textures are almost always converted to a GPU native format before being uploaded to the GPU.

I actually agree with you, it's just that i'm not so sure that a difference in instruction set will fundementally change the situation for porting - does it become any harder?
Machines will still share the same AI, shaders etc should they not? Does the graphic API for the current XBOX not have anything in common with DX (i'd heard it was basically dx 8.1 with extensions)? I thought all you needed for development was the XBOX SDK?

Out of interest, i'd like to know how much of - per say - Unreal Engine 3 was rewritten for each platform they target - percentage wise i'd suspect it's less than you'd guess as there's a heck of alot of code in there abstracted away from the hardware itself.

I'll try to keep this fairly brief as it's a bit esoteric...
Instruction sets in and of themselves aren't too big of a deal, the main differences are when the architecture varies itself. For instance a PPC based chip has completely different timings for data access and computation. You have to do things in a markedly different way in some cases because of what a machine is good at. More or less cache for instance can make a large difference to how you write code because you generally want to avoid cache misses.

AI is usually shared (though with a radically difference arch like CELL it may be less so), shaders are almost always platform specific as they rely on the particular GPU you have. Even xbox and PC with their similar arch don't have entirely compatible shaders.
Xbox has DX 8.1 plus a bit of XBOX stuff. The main differences are that you can tweak the underlying GPU native data with xbox and there's no cocept of upload to the GPU as everything shares the same memory. You can code it like a PC, but to get the most out of it you have to code it like an xbox.
Yes all you need is the XDK and a devkit, but then that's all you need for any console really.

I'm not sure on unreal 3 in terms of percentages, but typically it's between 25 and 40% I'd say for platform specific code. It depends somewhat on the game in question, games with more complex gameplay mechanics tend to have less platform specific code (pretty much all gameplay code is platform independent).

[dangel]

I'll try to keep this fairly brief as it's a bit esoteric...
Instruction sets in and of themselves aren't too big of a deal, the main differences are when the architecture varies itself. For instance a PPC based chip has completely different timings for data access and computation. You have to do things in a markedly different way in some cases because of what a machine is good at. More or less cache for instance can make a large difference to how you write code because you generally want to avoid cache misses.

How much of this really isn't compiler dependant tho thesedays? Gone are the days (for me anyway) of needing to write assembler to do things as tightly as possible. I'm sure carmack has said that the last hardcore inner loop he wrote was for the quake 2 engine - back when the gpu really wasn't doing as much work as it is now - and even then the builk of the code was C.

AI is usually shared (though with a radically difference arch like CELL it may be less so),

With what? The GPU? (!)

I'm not sure on unreal 3 in terms of percentages, but typically it's between 25 and 40% I'd say for platform specific code. It depends somewhat on the game in question, games with more complex gameplay mechanics tend to have less platform specific code (pretty much all gameplay code is platform independent).

I'd guess that in modern, large asset games that a heck of a lot of it is platform independant and certainly for something like the U3 engine they're going to want to keep it that way. Interesting stuff.. Still, even with the percentages quoted that makes porting remarkably easy for games using a universal game engine..

[oralpain]

Video drivers do actually eat alot of CPU cycles.

NVIDIA is not alone in this. ATI's current drivers have hidden options that allow you to enable multi threading (you can set the min and max threads for the drivers to use). I'm not sure how well it works. I have a single core CPU and can't imagine there would be any significant difference on my system, so I have yet to try it.