Deano Calver
Newcomer
Been a while since I last made a post.
The internet rumours are going full strength at the moment, from Nintendo DS specs to Xenon to NV40 and R420. One surprising thing is the amount of time the real specs are posted and then ignored by people happily guessing randomly.
I'm presonally interested in when PC are going multi-core, I know we have hyper-threading but thats not proper SMP. Its got to happen soon as every non-PC system will be multi-processing in 2005+
One effect this may have is that vertex shaders will be less important in future, with spare powerful CPU cores you have less reason not to do the vertex processing on the CPU(s). With next-gen cores having 3Ghz+ clocks and 4D dotproduct sustained throughput every 1 or 2 cycles , they will be able to do VS_3_0+ vertex shader at speed, with all the advantages of a true general processing unit.
So far this technique has only been used on value GPUs in PC land (Intel Extreme, GF4MX) but with a powerful vector unit and a fast link from CPU to GPU in many cases (especially things that don't fit into the normal GPU route, things like dynamic data or work that requires lots of array look-ups or recursive tesselation) it makes more sense to just get a CPU doing the work. Particular if you have a GPU that can devote the 'wasted' vertex shader power into pixel work.
I'm personally betting on the wheel of reincarnation taking a spin in the next couple of year and a lot of vertex work going back to general CPU's for a little while.A similar thing is happening in sound hardware, where the dedicated chips are being reduced to high quality decompressors and DACs and the rest (occulusion, 3D sounds, etc.) are moving back on the CPU.
Serious multi-processing game/rendering coding is the next big shift, doesn't matter how much you don't like it, its almost here. I'm currently playing with the concept of micro-threads and borrowing techniques from the real-time OS field, as a way of maximising multi CPU's
.
The idea I'm playing with is to work on function level multi-tasker, each frame there is a list of functions to execute, they are placed onto the processors, when one finishes it pops another off the list. The main advantages is static thread scheduling, the problems are dependencys and breaking things into independent functions. I have a feeling it will be more work upfront but will produce better results in the 2+ simulatanous thread situations we are going to encounter soon.
The internet rumours are going full strength at the moment, from Nintendo DS specs to Xenon to NV40 and R420. One surprising thing is the amount of time the real specs are posted and then ignored by people happily guessing randomly.
I'm presonally interested in when PC are going multi-core, I know we have hyper-threading but thats not proper SMP. Its got to happen soon as every non-PC system will be multi-processing in 2005+
One effect this may have is that vertex shaders will be less important in future, with spare powerful CPU cores you have less reason not to do the vertex processing on the CPU(s). With next-gen cores having 3Ghz+ clocks and 4D dotproduct sustained throughput every 1 or 2 cycles , they will be able to do VS_3_0+ vertex shader at speed, with all the advantages of a true general processing unit.
So far this technique has only been used on value GPUs in PC land (Intel Extreme, GF4MX) but with a powerful vector unit and a fast link from CPU to GPU in many cases (especially things that don't fit into the normal GPU route, things like dynamic data or work that requires lots of array look-ups or recursive tesselation) it makes more sense to just get a CPU doing the work. Particular if you have a GPU that can devote the 'wasted' vertex shader power into pixel work.
I'm personally betting on the wheel of reincarnation taking a spin in the next couple of year and a lot of vertex work going back to general CPU's for a little while.A similar thing is happening in sound hardware, where the dedicated chips are being reduced to high quality decompressors and DACs and the rest (occulusion, 3D sounds, etc.) are moving back on the CPU.
Serious multi-processing game/rendering coding is the next big shift, doesn't matter how much you don't like it, its almost here. I'm currently playing with the concept of micro-threads and borrowing techniques from the real-time OS field, as a way of maximising multi CPU's
.
The idea I'm playing with is to work on function level multi-tasker, each frame there is a list of functions to execute, they are placed onto the processors, when one finishes it pops another off the list. The main advantages is static thread scheduling, the problems are dependencys and breaking things into independent functions. I have a feeling it will be more work upfront but will produce better results in the 2+ simulatanous thread situations we are going to encounter soon.
