Hum, I'm not sure what happened exactly... I just re-downloaded the DX SDK on my laptop, and this time it installed just fine. Oh well.
Well, I took the time to convert all projects and solutions of the D3D engine to VS2010. Was quite a bit of work, because I have 6 configurations and 2 platforms for the code (D3D9/10/11 in both debug and release, and all those for both Win32 and x64 platforms). VS2010 seems to manage multiple configurations slightly better than VS2008 though, so I can more easily adjust settings that are the same for all debug or all release configurations.
It seems that my D3D10 code is now broken, because apparently some of the D3D11 stuff is now included even with D3D10 headers in the new SDK. I previously redefined some D3D10 constants, enums etc to the equivalent names in D3D11, making most code D3D version-agnostic. I'll have to see how much work it is to adjust my code... if it is too much work, I guess it's time to drop D3D10 support. There's not much point in D3D10 anyway... It's only for people who haven't updated their Vista yet. After the update they can use D3D11 anyway. I just kept the D3D10 code around because it was there anyway.
I've also converted my OpenGL code to VS2010. That code should also work in the Express version, since it doesn't depend on MFC or anything.
Still haven't quite decided whether to continue with D3D or OpenGL though. If the performance difference in the Unigine Heaven benchmark between OpenGL 4.0 and D3D11 are any indication, D3D11 still looks like the most attractive option by far. If I want to use 'real' OpenGL 4.0, rather than the legacy API with new extensions, I'll also have to make separate codepaths just like with D3D9/D3D11... After all, not all hardware will be supporting OpenGL 4.0, so there has to be a fallback to older versions. Different version contexts will have different behaviour with API functions, GLSL and whatnot.
Oh well, for most of the stuff I have planned for now, the API itself isn't really important. It's mostly about developing the proper algorithms. The actual implementations should be easy to implement on either API after that.
I must say I'm quite happy with VS2010 so far. Even on my modest 1.5 GHz Core2 Duo laptop it works quite smoothly, don't notice a difference with VS2008. And the project settings seem to have improved a bit, making it even more powerful to use. I also like how the WPF-based editor now allows easy scaling of text, making it easier to navigate your code. In the "Small Challenge" topic we have also seen that VS2010 generates even tighter code.
It seems that my D3D10 code is now broken, because apparently some of the D3D11 stuff is now included even with D3D10 headers in the new SDK. I previously redefined some D3D10 constants, enums etc to the equivalent names in D3D11, making most code D3D version-agnostic. I'll have to see how much work it is to adjust my code... if it is too much work, I guess it's time to drop D3D10 support. There's not much point in D3D10 anyway... It's only for people who haven't updated their Vista yet. After the update they can use D3D11 anyway. I just kept the D3D10 code around because it was there anyway.
I've also converted my OpenGL code to VS2010. That code should also work in the Express version, since it doesn't depend on MFC or anything.
Still haven't quite decided whether to continue with D3D or OpenGL though. If the performance difference in the Unigine Heaven benchmark between OpenGL 4.0 and D3D11 are any indication, D3D11 still looks like the most attractive option by far. If I want to use 'real' OpenGL 4.0, rather than the legacy API with new extensions, I'll also have to make separate codepaths just like with D3D9/D3D11... After all, not all hardware will be supporting OpenGL 4.0, so there has to be a fallback to older versions. Different version contexts will have different behaviour with API functions, GLSL and whatnot.
Oh well, for most of the stuff I have planned for now, the API itself isn't really important. It's mostly about developing the proper algorithms. The actual implementations should be easy to implement on either API after that.
I must say I'm quite happy with VS2010 so far. Even on my modest 1.5 GHz Core2 Duo laptop it works quite smoothly, don't notice a difference with VS2008. And the project settings seem to have improved a bit, making it even more powerful to use. I also like how the WPF-based editor now allows easy scaling of text, making it easier to navigate your code. In the "Small Challenge" topic we have also seen that VS2010 generates even tighter code.
I am not a C/c++ programmer, so every time Microsoft screw the headers, I have to MANUALLY adjust my transcription of them (none of those header translator things works 100%).
It was Microsoft's predilection to screwing with the dx headers / breaking backward compatibility which finally made up my mind for me - the ability to operate on other platforms is a nice bonus... I can live with a marginal performance discrepancy.
It was Microsoft's predilection to screwing with the dx headers / breaking backward compatibility which finally made up my mind for me - the ability to operate on other platforms is a nice bonus... I can live with a marginal performance discrepancy.
Well, the headers only affect C++ users directly.
Obviously MS cannot change names, structures or constant values, else they will run into binary incompatibilities (say what you want, but MS doesn't break backward compatibility. On Windows 7 you can still run DX3 code if you want (earliest version with D3D)... DX code built with any SDK will work on any OS supporting the API). If you stick to older versions of headers, it still works.
But yes, you do have to update your headers manually when you want to use new features etc, and that can get hairy. Personally I wouldn't recommend using assembly for D3D. I would suggest a C++ framework that handles the D3D-portion, and then use inline assembly, or link against assembly functions to implement the part that is not directly API-dependent. Best of both worlds.
Sadly the grass isn't that much greener on the other side... OpenGL depends on extensions, and you need to update headers for those aswell, and have some custom code to dynamically load extensions and all that. Frameworks like GLEW make that slightly easier for the C++ programmer (although they often lag behind), but in assembly you're still in the same boat as with D3D... You need to translate your own headers and keep them up to date manually. This requires scraping the OpenGL extension registry website.
As for the marginal performance discrepancy... I wish... D3D11 runs pretty much twice as fast as OpenGL 4.0 in the Unigine Heaven benchmark. I think that's pretty significant. And that's under Windows. Under linux ubuntu 10.04, OpenGL performance was dramatic on my Radeon 5770.
Obviously MS cannot change names, structures or constant values, else they will run into binary incompatibilities (say what you want, but MS doesn't break backward compatibility. On Windows 7 you can still run DX3 code if you want (earliest version with D3D)... DX code built with any SDK will work on any OS supporting the API). If you stick to older versions of headers, it still works.
But yes, you do have to update your headers manually when you want to use new features etc, and that can get hairy. Personally I wouldn't recommend using assembly for D3D. I would suggest a C++ framework that handles the D3D-portion, and then use inline assembly, or link against assembly functions to implement the part that is not directly API-dependent. Best of both worlds.
Sadly the grass isn't that much greener on the other side... OpenGL depends on extensions, and you need to update headers for those aswell, and have some custom code to dynamically load extensions and all that. Frameworks like GLEW make that slightly easier for the C++ programmer (although they often lag behind), but in assembly you're still in the same boat as with D3D... You need to translate your own headers and keep them up to date manually. This requires scraping the OpenGL extension registry website.
As for the marginal performance discrepancy... I wish... D3D11 runs pretty much twice as fast as OpenGL 4.0 in the Unigine Heaven benchmark. I think that's pretty significant. And that's under Windows. Under linux ubuntu 10.04, OpenGL performance was dramatic on my Radeon 5770.
I have decided that if there's going to be a remake of Croissant 9, it should be done with OpenGL. The performance isn't that big of an issue... and with OpenGL I can make a multiplatform demo, which is in the spirit of the original demo in Java, which runs pretty much everywhere. If I stick to OpenGL ES functionality, it can even be made to run on mobile devices and such.
Once I have a working OpenGL version, it shouldn't be very difficult to plug in a D3D rendering backend either. So I may decide to do that at a later point in time. Always fun for OpenGL vs D3D comparisons... or Windows vs linux etc :)
Anyway, the D3D10 issues are first on the list... Then I'll have to port some of the loading code so that I can get the Croissant 9 content working in a C++ environment... and from there, I can pimp it up with modern shaders, post-processing, and some nice shadowing algos.
Once I have a working OpenGL version, it shouldn't be very difficult to plug in a D3D rendering backend either. So I may decide to do that at a later point in time. Always fun for OpenGL vs D3D comparisons... or Windows vs linux etc :)
Anyway, the D3D10 issues are first on the list... Then I'll have to port some of the loading code so that I can get the Croissant 9 content working in a C++ environment... and from there, I can pimp it up with modern shaders, post-processing, and some nice shadowing algos.
Just read the review of the new GeForce GTX460 on Anandtech:
http://www.anandtech.com/show/3809/nvidias-geforce-gtx-460-the-200-king
Looks good... solves the problems of price/performance, power consumption and noise for me.
I think I'm going to get one of these, the 1 GB version.
A GeForce 9800GTX died in another box, I could use my Radeon 5770 there.
But for my primary development PC I'd love to get an nVidia card again, with its better driver and SDK support. The Radeon didn't really satisfy.
http://www.anandtech.com/show/3809/nvidias-geforce-gtx-460-the-200-king
Looks good... solves the problems of price/performance, power consumption and noise for me.
I think I'm going to get one of these, the 1 GB version.
A GeForce 9800GTX died in another box, I could use my Radeon 5770 there.
But for my primary development PC I'd love to get an nVidia card again, with its better driver and SDK support. The Radeon didn't really satisfy.
OpenGL depends on extensions, and you need to update headers for those aswell, and have some custom code to dynamically load extensions and all that.
Haven't looked at OGL for a while and now I was surprised to see that 99% of the really needed extensions have been absorbed into the core. So you can just require OGL2.1 (comparable to DX8 capability-wise, from what I see), which has almost everything one can need, and additionally check for, like, 2-3 extensions (highest version of vertex/fragment program supported, for example).
Also, this tool NVparse looks helpful in automating some repetitious tasks, but unfortunately its precise documentation is nowhere to be found, it seems o_O I'm especially interested in its texture stage configuration capabilities, as well as register combiners configuration capabilities. All examples I could find were vertex/pixel shaders.
This tool looks interesting as well: OpenGL extension viewer. It can tell many useful things about many useful features ^^ Esp. nice is theinfo about the OGL version number in which a particular extension has been absorbed into the core.
As for the GTX460: Yeah, looks like GTX460 is going to be my next buy too. I'm relieved to see that it draws only ~30W when in idle state. It's comparable to my current 9600GT.
OpenGL depends on extensions, and you need to update headers for those aswell, and have some custom code to dynamically load extensions and all that.
Haven't looked at OGL for a while and now I was surprised to see that 99% of the really needed extensions have been absorbed into the core. So you can just require OGL2.1 (comparable to DX8 capability-wise, from what I see), which has almost everything one can need, and additionally check for, like, 2-3 extensions (highest version of vertex/fragment program supported, for example).
Well, there are two problems with that, I think:
1) If you care about Intel IGPs... most of them only support OpenGL 2.0 core, some even 1.5 (yes, DX9 and DX10-capable IGPs aswell). I think my Radeon 9600XT also has only 2.0 support. Drivers just didn't update anymore. But many of the extensions are there.
2) Because Microsoft has never updated their OpenGL32.dll/lib, you always link to a core library for 1.4. So even if you create a 2.1 or higher context, I believe you need to use wglGetProcAddress() to get the addresses of the core functions. Might aswell get the ARB functions then, they are more compatible with the situation in 1).
What's different with 4.0 is that some extensions are not available for lower versions at all, I believe. So now for the first time you NEED a higher context, and run into the problems that certain stuff is deprecated or behaviour has changed.
This tool looks interesting as well: OpenGL extension viewer. It can tell many useful things about many useful features ^^ Esp. nice is theinfo about the OGL version number in which a particular extension has been absorbed into the core.
Yea, that tool is nice. What's also nice is the database of hardware/drivers that they have. So you can see which hardware supports what, without having to have physical access to it.
I found a bunch of 1 GB GTX460s for pre-order. I went with the cheapest option, a Gigabyte GTX460 OC 1 GB, for 211 euros.
Now we wait :)
Now we wait :)
No sign of the GTX460 yet, sadly... ETA is 12th of August...
I'd really like to see how it does in the Unigine Heaven benchmark, OpenGL 4.0 vs DX11. I am more or less hoping that the difference is a lot smaller than on the Radeon.
I also like to try Ubuntu again with the GeForce. Performance of my OpenGL code was very poor on the Radeon with Ubuntu.
In other news, I've been busy reinstalling my laptop, so that it now also has a copy of Windows 7 x64 on it. I've decided to only install VS2010 there. Not planning on using the older versions anymore anyway, and it saves a lot of diskspace.
Then I started to fix and update the object loader for the old .ASE format that the Artnouveau and Croissant 9 demos used.
I've got the basic geometry parsing and animation working in D3D9 now. D3D10/11 still need a bit of work to load the correct shaders, I gather. Nothing big.
So pretty soon I can hopefully load the original geometry content from the Croissant 9 demo, and display it on screen. Then I'll have to recreate all the effects and special-case stuff so that the complete demo can be recreated. And then it's time to pimp the stuff with new-and-improved effects and whatnot.
Gonna be interesting to wade through that 7-year old Java code to see what I did exactly, and where :)
I'll have to build an XML parser at least, to parse the original demo script, which contains references to the textures, shaders, materials etc, and controls some effects.
I will also have to update my sound player library for the new fmod. I haven't touched that in years.
I'd really like to see how it does in the Unigine Heaven benchmark, OpenGL 4.0 vs DX11. I am more or less hoping that the difference is a lot smaller than on the Radeon.
I also like to try Ubuntu again with the GeForce. Performance of my OpenGL code was very poor on the Radeon with Ubuntu.
In other news, I've been busy reinstalling my laptop, so that it now also has a copy of Windows 7 x64 on it. I've decided to only install VS2010 there. Not planning on using the older versions anymore anyway, and it saves a lot of diskspace.
Then I started to fix and update the object loader for the old .ASE format that the Artnouveau and Croissant 9 demos used.
I've got the basic geometry parsing and animation working in D3D9 now. D3D10/11 still need a bit of work to load the correct shaders, I gather. Nothing big.
So pretty soon I can hopefully load the original geometry content from the Croissant 9 demo, and display it on screen. Then I'll have to recreate all the effects and special-case stuff so that the complete demo can be recreated. And then it's time to pimp the stuff with new-and-improved effects and whatnot.
Gonna be interesting to wade through that 7-year old Java code to see what I did exactly, and where :)
I'll have to build an XML parser at least, to parse the original demo script, which contains references to the textures, shaders, materials etc, and controls some effects.
I will also have to update my sound player library for the new fmod. I haven't touched that in years.
I've got the basic geometry parsing and animation working in D3D9 now. D3D10/11 still need a bit of work to load the correct shaders, I gather. Nothing big.
I found the problem... it was very sneaky...
With the old DrawPrimitive() function in D3D9, you specify the number of triangles you want to render.
With the new Draw() in D3D10/11, you specify the number of vertices. So that's different.
Since I recycled some old D3D9 loader code, it specified the number of triangles properly.
The number of vertices were never initialized though, because that didn't exist in D3D9 yet.
So in D3D10/11, it always rendered 0 vertices (as it was nicely initialized to 0 ofcourse.. :))... which meant that everything worked as expected, no errors... just nothing on screen :)
Okay, so XML parsing is up next, I'm afraid... I might have to use TinyXML or such, so that I can use it on both Windows and linux/FreeBSD platforms. Or just roll my own, like I did with Java (back then, XML parsing wasn't a standard feature in Java, and I didn't feel like using one of those huge prefab libraries, which would have to be distributed along with my demos etc).
Woo, finally the GTX460s have arrived at ye olde webshoppe. With a bit of luck, it can be delivered tomorrow. But, it will probably turn out to be Monday or Tuesday....
Interesting :)
Well, turned out to be Tuesday ofcourse... but, better late than never... I have my GeForce GTX460 1 GB.
Did a quick run of the Unigine Heaven benchmark in OpenGL 4.0 mode vs DX11.
And indeed the difference is negligible: 42.6 fps average in OpenGL, 43.9 fps in DX11, both tested in Windows 7.
On the Radeon it was more like 22 fps in OpenGL, 32 fps in DX11. In Windows 7 that is. In Windows XP the OpenGL performance was considerably better, but still only 26 fps average, so not quite at the same level as DX11.
The card also seems to be more silent than the Radeon, even under load. Very nice.
Did a quick run of the Unigine Heaven benchmark in OpenGL 4.0 mode vs DX11.
And indeed the difference is negligible: 42.6 fps average in OpenGL, 43.9 fps in DX11, both tested in Windows 7.
On the Radeon it was more like 22 fps in OpenGL, 32 fps in DX11. In Windows 7 that is. In Windows XP the OpenGL performance was considerably better, but still only 26 fps average, so not quite at the same level as DX11.
The card also seems to be more silent than the Radeon, even under load. Very nice.
Can you measure its power consumption?
I don't have the tools to measure that myself...
But here are a bunch of cards:
http://www.anandtech.com/show/3810/nvidias-geforce-gtx-460-part-2-the-vendor-cards/6
The GTX460 is great in idle mode, one of the most efficient... under load it's not bad either, somewhere around the Radeon 5830/5850, which matches with the performance level. So performance/watt seems to be about on par with AMD, which is more than you can say of the super-hungry 465/470/480 models (especially the 465 is really bad... as it isn't even faster than the 460).
But here are a bunch of cards:
http://www.anandtech.com/show/3810/nvidias-geforce-gtx-460-part-2-the-vendor-cards/6
The GTX460 is great in idle mode, one of the most efficient... under load it's not bad either, somewhere around the Radeon 5830/5850, which matches with the performance level. So performance/watt seems to be about on par with AMD, which is more than you can say of the super-hungry 465/470/480 models (especially the 465 is really bad... as it isn't even faster than the 460).
Well, first impression of the card is quite good.
It really is incredibly silent compared to the 5770. It's much like the 8800GTS I used to have... the fans have a barely audible low hum. I mainly hear the large fan in my PSU spinning up when the card is under load. With the Radeon 5770, the fan had a nasty whine to it, which could be heard over all other sound.
What's worse: the 5770 apparently boots into full 3D clocks. Even though there is some fan control, if you stay in the POST screen too long (that is, more than say 30 seconds), the fan will spin up like crazy (probably a sign that the GPU is also running at very high temperature). And if you boot into an OS without the proper drivers installed, it will stay like this all the time. Only when the driver is loaded to control the fans and GPU speed, the noise finally dies. Not nice when you boot into a linux live CD with open source drivers, which don't have this fan control...
It also fixes some gripes regarding drivers... Firstly I don't have the problem anymore that when I do a remote desktop session to my machine, that the Catalyst Control Panel dies on me. Typical unprofessional bug in ATi's drivers, has been there as long as I've had the card (since November last year), and was never fixed.
Secondly, OpenGL works, and works well. With the 10.7 Catalysts, the Unigine Heaven benchmark would just hang your entire PC with a black screen (even though the release notes specifically say that this has been fixed). And with older drivers, although Heaven worked, the OpenGL performance was considerably worse than DX11, as I mentioned.
I've run it in XP on my GTX460 aswell now, and the average framerate was 43.6. So right between OGL in Windows 7 and DX11.
Initially I thought that OpenCL was broken on the GTX460, because every OpenCL application I tried, just crashed. Then I realized what the problem was: Since OpenCL isn't installed with the Catalyst drivers, it is not UNINSTALLED either. The OpenCL runtime is actually part of the Stream SDK, and ATi sets some environment variables that point to the binaries. So it was still pointing to these OpenCL binaries rather than the nVidia ones (which were properly installed in system32 and syswow64). After manually cleaning out my path variable, things started to work... and work well.
I guess I don't have to worry about OpenCL anymore, it just works and comes with the standard drivers. And they bother to test it too..
The Catalyst 10.7 release notes stated that OpenCL was not tested for conformance in these drivers, and they recommended going back to 10.5 if you needed OpenCL... great... while at the same time they release a marketing campaign like this:
http://sites.amd.com/us/game/community/Pages/aboutgamingevolved.aspx
Okay... so you promise to 'nurture' open industry standards like OpenGL and OpenCL... but at the same time you release a driver where OpenGL literally hangs your PC so badly that powering off is the only option... and you don't even bother to test the OpenCL portion in your drivers, and recommend using older drivers instead?
Right... I think I'm going to be very happy to have gotten rid of my Radeon 5770. Seeing as I like to use open industry standards like OpenGL and OpenCL.
Oh, and I played a small game of Mirror's Edge. Running with PhysX for the first time since my 8800GTS died. Still pretty cool to have the extra effects.
You know... this is the second time where I actually started to appreciate a brand more because I was using their competitor's stuff.
The first time was with my Athlon. Okay, it had a VIA chipset, so you can't blame AMD for everything (except perhaps for too low supply of their own chipsets), but it was a total disaster to get that thing stable... and even when it finally was stable, it ran very hot and noisy. My brother bought an Athlon aswell at that time, and he eventually gave up, chucked the lot and bought a Pentium 4 and Intel chipset. Although I stuck with the AMD system myself, I could understand his move. You really learn to appreciate the qualities of Intel's chipset, power management, cooling solution etc when you've been using an AMD system for a while.
Same thing now... Although I've had various ATi cards before, and never really had a problem with them at the time (Radeon 8500, Radeon 9600, X1900), I guess the situation is slightly different today.
I had gotten used to my 8800GTS, with good OpenCL support, Cuda, PhysX, and everything. Nice and silent too.
So the ATi card was a bit of a letdown. I had to give up on a lot of stuff, and also ran into various driver bugs... Another thing... if I made a bug in a D3D shader, causing the app to send geometry without setting a valid shader, the driver/GPU would often crash. Which would take a while to recover, very annoying. I haven't tested that yet, but I never had that problem with the 8800GTS at the time. I hope the GTX460 is just as robust.
It really is incredibly silent compared to the 5770. It's much like the 8800GTS I used to have... the fans have a barely audible low hum. I mainly hear the large fan in my PSU spinning up when the card is under load. With the Radeon 5770, the fan had a nasty whine to it, which could be heard over all other sound.
What's worse: the 5770 apparently boots into full 3D clocks. Even though there is some fan control, if you stay in the POST screen too long (that is, more than say 30 seconds), the fan will spin up like crazy (probably a sign that the GPU is also running at very high temperature). And if you boot into an OS without the proper drivers installed, it will stay like this all the time. Only when the driver is loaded to control the fans and GPU speed, the noise finally dies. Not nice when you boot into a linux live CD with open source drivers, which don't have this fan control...
It also fixes some gripes regarding drivers... Firstly I don't have the problem anymore that when I do a remote desktop session to my machine, that the Catalyst Control Panel dies on me. Typical unprofessional bug in ATi's drivers, has been there as long as I've had the card (since November last year), and was never fixed.
Secondly, OpenGL works, and works well. With the 10.7 Catalysts, the Unigine Heaven benchmark would just hang your entire PC with a black screen (even though the release notes specifically say that this has been fixed). And with older drivers, although Heaven worked, the OpenGL performance was considerably worse than DX11, as I mentioned.
I've run it in XP on my GTX460 aswell now, and the average framerate was 43.6. So right between OGL in Windows 7 and DX11.
Initially I thought that OpenCL was broken on the GTX460, because every OpenCL application I tried, just crashed. Then I realized what the problem was: Since OpenCL isn't installed with the Catalyst drivers, it is not UNINSTALLED either. The OpenCL runtime is actually part of the Stream SDK, and ATi sets some environment variables that point to the binaries. So it was still pointing to these OpenCL binaries rather than the nVidia ones (which were properly installed in system32 and syswow64). After manually cleaning out my path variable, things started to work... and work well.
I guess I don't have to worry about OpenCL anymore, it just works and comes with the standard drivers. And they bother to test it too..
The Catalyst 10.7 release notes stated that OpenCL was not tested for conformance in these drivers, and they recommended going back to 10.5 if you needed OpenCL... great... while at the same time they release a marketing campaign like this:
http://sites.amd.com/us/game/community/Pages/aboutgamingevolved.aspx
Our promise to nurture open industry standards
PC game developers have a right to the best possible gaming platform. AMD’s Gaming Evolved program confirms our promise to deliver the most innovative technologies, tools, and industry support to maintain the PC platform as world’s premier gaming environment. We will participate in the development and cultivation of OpenCL and OpenGL industry standards, and we will move quickly to move our innovations into the industry standards whenever feasible.
PC game developers have a right to the best possible gaming platform. AMD’s Gaming Evolved program confirms our promise to deliver the most innovative technologies, tools, and industry support to maintain the PC platform as world’s premier gaming environment. We will participate in the development and cultivation of OpenCL and OpenGL industry standards, and we will move quickly to move our innovations into the industry standards whenever feasible.
Okay... so you promise to 'nurture' open industry standards like OpenGL and OpenCL... but at the same time you release a driver where OpenGL literally hangs your PC so badly that powering off is the only option... and you don't even bother to test the OpenCL portion in your drivers, and recommend using older drivers instead?
Right... I think I'm going to be very happy to have gotten rid of my Radeon 5770. Seeing as I like to use open industry standards like OpenGL and OpenCL.
Oh, and I played a small game of Mirror's Edge. Running with PhysX for the first time since my 8800GTS died. Still pretty cool to have the extra effects.
You know... this is the second time where I actually started to appreciate a brand more because I was using their competitor's stuff.
The first time was with my Athlon. Okay, it had a VIA chipset, so you can't blame AMD for everything (except perhaps for too low supply of their own chipsets), but it was a total disaster to get that thing stable... and even when it finally was stable, it ran very hot and noisy. My brother bought an Athlon aswell at that time, and he eventually gave up, chucked the lot and bought a Pentium 4 and Intel chipset. Although I stuck with the AMD system myself, I could understand his move. You really learn to appreciate the qualities of Intel's chipset, power management, cooling solution etc when you've been using an AMD system for a while.
Same thing now... Although I've had various ATi cards before, and never really had a problem with them at the time (Radeon 8500, Radeon 9600, X1900), I guess the situation is slightly different today.
I had gotten used to my 8800GTS, with good OpenCL support, Cuda, PhysX, and everything. Nice and silent too.
So the ATi card was a bit of a letdown. I had to give up on a lot of stuff, and also ran into various driver bugs... Another thing... if I made a bug in a D3D shader, causing the app to send geometry without setting a valid shader, the driver/GPU would often crash. Which would take a while to recover, very annoying. I haven't tested that yet, but I never had that problem with the 8800GTS at the time. I hope the GTX460 is just as robust.
Heh, after a bit of a struggle, I managed to get ALL Futuremark benchmarks working on my GeForce GTX460, and from within Windows 7 x64 too :)
In fact, some of them didn't actually work in XP anymore, but they do work in Windows 7 :)
So that includes the following:
- Final Reality (I had to install that from within a 32-bit OS, because the installer is 16-bit. Once I had the extracted binaries, it could run from Windows 7 without a problem... funny thing is, it still has a software path... and no, on my 3 GHz Core2 Duo it STILL doesn't get good framerates in 640x480. I've seen Java demos that run better ;))
- 3DMark99 MAX (I had prepared a special patched executable a long time ago, which fixes the problem that it reports that it cannot find DirectX 6.1... while in reality it means something else, forgot what it was exactly)
- 3DMark2000 (Only works in compatibility mode for XP, else it complains that there is not enough memory (probably uses a signed 32-bit integer, then it sees a VERY large amount of memory from within my 64-bit environment)
- XL-R8R
- 3DMark2001SE (Complains about not having enough memory as well, but doesn't see that as a fatal error, so no need to use any compatibility settings or anything)
- 3DMark03
- 3DMark05
- 3DMark06
- 3DMark Vantage
And in a few months I should be able to add 3DMark11 to the list.
Has anyone seen the teaser on YouTube? The geometry detail is really incredible: http://www.youtube.com/watch?v=xEQrPZntkU8
I bet that's going to hurt those DX11 tessellators. nVidia is probably going to be looking pretty good in that benchmark.
In fact, some of them didn't actually work in XP anymore, but they do work in Windows 7 :)
So that includes the following:
- Final Reality (I had to install that from within a 32-bit OS, because the installer is 16-bit. Once I had the extracted binaries, it could run from Windows 7 without a problem... funny thing is, it still has a software path... and no, on my 3 GHz Core2 Duo it STILL doesn't get good framerates in 640x480. I've seen Java demos that run better ;))
- 3DMark99 MAX (I had prepared a special patched executable a long time ago, which fixes the problem that it reports that it cannot find DirectX 6.1... while in reality it means something else, forgot what it was exactly)
- 3DMark2000 (Only works in compatibility mode for XP, else it complains that there is not enough memory (probably uses a signed 32-bit integer, then it sees a VERY large amount of memory from within my 64-bit environment)
- XL-R8R
- 3DMark2001SE (Complains about not having enough memory as well, but doesn't see that as a fatal error, so no need to use any compatibility settings or anything)
- 3DMark03
- 3DMark05
- 3DMark06
- 3DMark Vantage
And in a few months I should be able to add 3DMark11 to the list.
Has anyone seen the teaser on YouTube? The geometry detail is really incredible: http://www.youtube.com/watch?v=xEQrPZntkU8
I bet that's going to hurt those DX11 tessellators. nVidia is probably going to be looking pretty good in that benchmark.
Why can't I bring myself to just cut the D3D10-code out of my codebase completely and simplify the lot?
Why can't I bring myself to just cut the D3D10-code out of my codebase completely and simplify the lot?