When Will UT3 For Linux Be Released?

[deanjo]

Game-Spy is a rather tricky devil to have in your project. Beware of them. And UT3 is pregnant with this shit so this is most probably a problem. What goes for PhysX it's anyways gonna die. nVidia puts this all into CUDA so it's deprecated soon anyways. But the reason for UT3 to not go Linux is in my opinion more the drama that went down over the course of the last year.

Nvidia has no intention of killing Cuda. They have been very clear on that. Cuda already enjoys hundreds of universities teaching Cuda and still has several advantages to using it on Nvidia hardware over openCL. Plus there are many Cuda apps already out there (not the consumer side but on the academic/scientific side). Cuda has had enough of a nice lead in the area that it is going to be hard for openCL to kill it especially when there is no current plans on bringing openCL support to windows which is still the 10,000 pound gorrilla.

[Thetargos]

Nvidia has no intention of killing Cuda. They have been very clear on that. Cuda already enjoys hundreds of universities teaching Cuda and still has several advantages to using it on Nvidia hardware over openCL. Plus there are many Cuda apps already out there (not the consumer side but on the academic/scientific side). Cuda has had enough of a nice lead in the area that it is going to be hard for openCL to kill it especially when there is no current plans on bringing openCL support to windows which is still the 10,000 pound gorrilla.

*ring**ring* Glide, anyone?

The same it was said about 3dfx's Glide. At the time it was the first consumer-apps 3D API available (some called it a distilled version of OpenGL and implemented in hardware [Voodoo architecture]). The way CUDA stands right now, is exactly that... Despite the momentum and advantage they had to be first to arrive to the market, see what fate did the API (and the company) had in the end. OpenGL out-grew Glide, simply because it was easier to extend the API and then wait for the hardware to catch up, since Glide was so intrinsically tied to the hardware 3dfx had much more trouble catching up. I know this won't necessarily be the same case for nVidia and CUDA, but the fact that the API is "proprietary" meaning that no other capable hardware can run it, will in the end (just like Glide's fate was) be its Achilles ankle. DirectX 11 (more so than OpenCL, I must admit) are the big problems CUDA will have to face, and knowing how scientific applications work, it is more likely that they will adopt OpenCL over CUDA or even DirectX 11, simply due to multiplatform (software and hardware) support. Still GPGPU is in its infancy by comparison (much like it was consumer 3D back in 1996 when the first consumer 3D accelerators appeared on the market), so what will it happen, we can only guess and speculate. Maybe CUDA grows itself to be a cross-platform (hardware) standard, and nVidia licenses it (like Intel did with the x86 microcode, MMX extensions, and other SIMD instructions) so that other manufacturers can implement it, and make it a standard API... Knowing their track record, that (today) seems highly unlikely, though.

[deanjo]

*ring**ring* Glide, anyone?

The same it was said about 3dfx's Glide. At the time it was the first consumer-apps 3D API available (some called it a distilled version of OpenGL and implemented in hardware [Voodoo architecture]). The way CUDA stands right now, is exactly that... Despite the momentum and advantage they had to be first to arrive to the market, see what fate did the API (and the company) had in the end. OpenGL out-grew Glide, simply because it was easier to extend the API and then wait for the hardware to catch up, since Glide was so intrinsically tied to the hardware 3dfx had much more trouble catching up. I know this won't necessarily be the same case for nVidia and CUDA, but the fact that the API is "proprietary" meaning that no other capable hardware can run it, will in the end (just like Glide's fate was) be its Achilles ankle. DirectX 11 (more so than OpenCL, I must admit) are the big problems CUDA will have to face, and knowing how scientific applications work, it is more likely that they will adopt OpenCL over CUDA or even DirectX 11, simply due to multiplatform (software and hardware) support. Still GPGPU is in its infancy by comparison (much like it was consumer 3D back in 1996 when the first consumer 3D accelerators appeared on the market), so what will it happen, we can only guess and speculate. Maybe CUDA grows itself to be a cross-platform (hardware) standard, and nVidia licenses it (like Intel did with the x86 microcode, MMX extensions, and other SIMD instructions) so that other manufacturers can implement it, and make it a standard API... Knowing their track record, that (today) seems highly unlikely, though.

I'm not saying it will never give way to the alternatives just that is going to be a much slower adoption then what Glide was. Glide wasn't what killed 3dfx though. 3dfx's decision to kill distributing it's chip to it's card partners and it's refusal to adopt such things as 24/32 bit color is what truely killed 3dfx and glide.

[Dragonlord]

You have to keep in mind that we have nowadays a couple of strong parties to satisfy. Especially we have 2 major graphics card chip produces: nVidia and ATI. I don't know the exact numbers of usage of those but it should be half-half ( between the two, of course there is Intel and others but I neglect those for this post ). Having a standard that works only on nVidia and only on elected platforms and OpenCL which works on all ( due to not being proprietary ) then I would bet my money on OpenCL to win. Furthermore it's based like the other OpenX products ( OpenGL, OpenAL and now OpenCL ) on the same architecture. That's a huge plus to not have learning a new structure as the basic mechanics learned for OpenGL for example spill over. In my opinion a huge plus.

[deanjo]

You have to keep in mind that we have nowadays a couple of strong parties to satisfy. Especially we have 2 major graphics card chip produces: nVidia and ATI. I don't know the exact numbers of usage of those but it should be half-half ( between the two, of course there is Intel and others but I neglect those for this post ). Having a standard that works only on nVidia and only on elected platforms and OpenCL which works on all ( due to not being proprietary ) then I would bet my money on OpenCL to win. Furthermore it's based like the other OpenX products ( OpenGL, OpenAL and now OpenCL ) on the same architecture. That's a huge plus to not have learning a new structure as the basic mechanics learned for OpenGL for example spill over. In my opinion a huge plus.

In marketshare of workstation class cards Nvidia still has a pretty healthy lead (gobbling up close to 75% of the marketshare IIRC). This is the market that GPGPU solutions primarily currently cater too. Comparing consumer class trends to that market is not really a good comparison in this arena. Nvidia's implementation of openCL is a layer ontop of Cuda driver interface. The other option is to use C for Cuda or in the future DX11. If you take a look at the Cuda apps (or even GPGPU apps in general) most of the apps out there are C for Cuda apps and a vast majority are scientific or educational in nature. That market has been very slow to change in the past. They tend to use solutions that work and remain with it, despite there being a new kid on a block. That world is still full of people utilizing the likes of Fortran, Cobal, C, Pascal, etc where as your mainstream developers have more or less moved past that point.

Also just because something has a open alternative it does not guarantee that it will be the new defacto standard. We have seen how openGL has deteriorated in it's support over the years in favor of closed (and sometimes propriatary) solutions.

Most CAD type applications which were once the stronghold of openGL for example offer DirectX support and most of the time is even the default renderer. PS3 and Wii systems are openGL capable but game devs still prefer using their propriatary solutions such as libgsm instead. Samethings goes with physics libraries. There have been opensource alternatives for quite some time now but your industry leaders would still have to be Physx and Havoc in commercially supported API's or a in house solution. Physx has been steadily gaining support over the last little while with some big game publishers signing up. That's not usually a sign of a quick to be dead tech.

Like I said I'm not saying C for Cuda will not die, it just won't be as fast to happen as you might expect. When you have a small number of competitors it's not enough to just equal each other efforts but one has to greatly exceed it's competeition to become the new standard. openCL still has a good 1.5 to 2 years of development before going toe to toe with the other established solutions, perhaps longer in any other OS outside of OS X. EAX has proven that for years a propriatary solution can enjoy market dominance. openAL has been available for years but didn't really start enjoying a solid backing until recently when Microsoft killed off sound acceleration in DX10 and even then EAX support is still going strong.

[D0pamine]

possibly the 5th of march if not then its burning time for sure on the 6th

Thermite i'm thinking...

[Svartalf]

possibly the 5th of march if not then its burning time for sure on the 6th

Thermite i'm thinking...

Make sure you capture it on video and share the link w/us...

[MaestroMaus]

possibly the 5th of march if not then its burning time for sure on the 6th

Thermite i'm thinking...

I suggest you start sharpening your pitchfork then...

[Aradreth]

possibly the 5th of march if not then its burning time for sure on the 6th

Thermite i'm thinking...

It may very well be released on the 5th of march... in 2020...

[me262]

Well, I'm holding my breath.
Although it's for another matter entirely!