Quote:
|
it's useful when you want guarenteed real time performance for example for uncompressed video i/o or time critical audio programming.
|
Well ofcourse, you can think a good use of every common misuse if you try hard enough. However, there are betters ways to solve such problems like using realtime priorities on processes and such, or simply using a realtime operating system. Also, we were (at some point anyway) talking about software and software quality. I was merely posting an example, and never intended to go into a pissing contest with you.
Quote:
|
we're talking about two different things and you've missed my point.
|
You've seem to have missed mine entirely as well. I wouldn't lose any sleep over it though
Quote:
|
Just to be nitpicking i would say that 2d could or could not be faster than 3d. Especially on the Amiga since the blitter only could blitt in planar mode. So if you needed to say read a pixel, rotate it and draw it again you had to convert planar pixels to chunky, rotate it and convert back to planar. This made effects like rotation be slower than effects like plasma. Todays GPU?s has strongpoints and weakpoints just like this so there is noway to say if 2d is slower/faster than 3d without having to look at the actuall processing being done. This becomes especially troublesome when you have to read back data from the GPU, if that is an requirement for your process the time render will skyrocket.
|
Finally someone who actually knows what he's talking about. I agree with you that if you're switching back and forth between GPU and CPU processing you are hogging the databus wich does serious damage to the framerate. But, I cannot think of any effects I would use that cannot be done entirely on the GPU (I'm sure you could think of some if you think hard enough though).
On unified memory architectures (like the xbox) however, they can be mixed more easily. But can you say that either method is slow because it doesn't mix well with the other?