The Ideal (Hypothetical) Gaming Processor

[RealNC]

also you are wrong at the FPS because ray tracing engines never make FPS!

they always pushes rays per "minute"

That has nothing to do with it. With current GPUs you have stuff like "polygons per second", not FPS.

FPS is how much times per second you can update the whole scene, regardless of whether it's "polygons per second" or "rays per minute".

[Qaridarium]

what?
fps means frame per second.

o man ray tracing dosn't work in FRAMES!

ray tracing work in ray per minutes!

a Real time Ray tracing engine dosn'T have FRAMES per SECOND!

because of this all of your writing is wrong!

[Wildfire]

As for the core count itself, would it be best to make a quad-core chip and call it a day? I know most game engines today simply do not scale past four cores, and simultaneous multithreading is pretty much useless for games. But, since consoles are expected to last around 5 years, would making a 6- or 8-core CPU prove beneficial in the future, so long as the chip stayed within the client's budget? I know this is just a lot of speculation, but I'm just curious what makes games tick.

I think you're looking at this the wrong way around. You're looking at what current games are doing and you're then trying to design a CPU that is optimal for that. In terms of progress you would need to design a CPU that offers things that current CPUs are lacking (in terms of performance for gaming) so that future games can be optimized for that. Let the software adapt to your CPU not the CPU to your software.

ray tracing dosn't work in FRAMES! ray tracing work in ray per minutes! a Real time Ray tracing engine dosn'T have FRAMES per SECOND! because of this all of your writing is wrong!

Sure it does. Your rays per minute translate back into frames per second. If your average scene requires 1,000,000 rays and your raytracer can do 10,000,000 rays per second (or 600,000,000 per minute) then it's going to require 0.1 seconds for a single image (aka frame). Which means it can render 10 images per second aka 10 fps.

[Qaridarium]

Sure it does. Your rays per minute translate back into frames per second. If your average scene requires 1,000,000 rays and your raytracer can do 10,000,000 rays per second (or 600,000,000 per minute) then it's going to require 0.1 seconds for a single image (aka frame). Which means it can render 10 images per second aka 10 fps.

"Sure it does. Your rays per minute translate back into frames per second."

LOL this is just stupid! because you can have unlimited FPS with any kind of hardware if you use raytracing but the result is still crap!

"If your average scene requires 1,000,000 rays and your raytracer can do 10,000,000 rays per second (or 600,000,000 per minute) then it's going to require 0.1 seconds for a single image (aka frame)"

this is just wrong! because realtime Raytracing engine do NEVER handle any pixel in a frame!

you conclusion is complete wrong! it always do the same FPS FRAME-RATE! the only factor what is chancing with power full or lesspower full hardware is the rush murmuring

this means good fast hardware make 99% pixels less strong hardware only do 90% at the same FPS rate and this means less strong hardware do have withe or black rush murmuring and good fast hardware do have less murmuring. m

but the FPS frames per second rate is exactly the same!

your suggestion is just not REAL TIME RAY TRACING?!

you can watch the murmuring at 1,00 minutes in this video:

[Geri]

Qaridarium: every image processing mechanism have a frame/second value, also ray tracing have.

this is just wrong! because realtime Raytracing engine do NEVER handle any pixel in a frame!

oh jesus, stop posting nonsense

[Qaridarium]

Qaridarium: every image processing mechanism have a frame/second value, also ray tracing have.


oh jesus, stop posting nonsense

no you posting nonsense! ray tracing have nothing to do with FPS! with an real-time-ray-tracing engine you can get any FPS rate you want if you want 1000fps no problem 2000fps no problem!

because only the murmuring makes the difference!

without murmuring you don't have a mealtime ray-tracing rendering.

realtime raytracing always mean skip the rendering means skip to lowering the murmuring to send the data to the screen but you can set the FPS rate complete arbitrarily! 100fps or 1000fps it just doesn't matter!

the only point that maters in ray tracing is: the murmuring rate slow hardware means high murmuring fast hardware means less murmuring and its NEVER without murmuring if someone claim raytracing without murmuring then its a offline renderer and not a realtime renderer!

here in this video you can watch the murmuring all the time and the FPS rate dosn't matter:

[mangobrain]

Sorry, Q, but I've *written* a raytracer and you are very confused. It is true that you can dynamically alter the performance of a raytracer by changing the number of rays cast, but that does not magically mean raytracers are somehow completely divorced from the concept of FPS. It's also worth nothing that casting any less than one primary ray per pixel* will have a negative impact on quality: what you see in the Intel video is that when the camera moves, the engine casts fewer rays to keep the framerate at a level suitable for interacting with the scene; then, when the camera stops, the engine ramps the ray count back up again because there's no need for a high framerate when nothing is moving.

It's a clever trick, but there's no magic which means you can scale from 1 FPS to 1000 FPS with no impact on quality.

* A primary ray is one traced out from the camera's viewpoint, usually through the centre of a pixel in the image plane, to see what part of the scene it intersects. "Shadow" rays, reflected rays, refracted rays etc. are then cast from a primary ray's point of impact, and contribute to the final colour value rendered at the appropriate pixel, but if you don't cast at least one primary ray per pixel then you have to fill in the gaps with some sort of interpolation. Casting more than one primary ray per pixel is a great way to do anti-aliasing, but can be very expensive in terms of performance.

[artivision]

If you want to make a technology FPS-less (even raster) you can do it. The problem is when you move the 3D world around, you need new calculations (in a fixed point, a new frame). Frames are fixed points of the flow of information and its only typical if you want them. The best processor is OpenCores and needs only 1 million transistor for a typical 48macs/hz or 2,5dmips/mhz. That is 13 times less transistor than a9-arm, for a little better speed. http://en.wikipedia.org/wiki/Loongson see this in L3C part, has 3D instructions as emulation instructions and I believe that are important for every processor. Also see ZMS, has a cemi-fpga that doubles or even quads the CPU speed for a 30% more energy, and you cant measure ZMS in gflops because are special operations. Any way a mix of technology (better free) can give as 10x-tflops/watt.

[mangobrain]

No, you can't make things magically FPS-less. It's simple.

The maximum FPS is determined by how long it takes to gather one frame's worth of information at the lowest acceptable quality. For example, in an interactive raytracer, you may decide that casting primary rays every 10 pixels (in a grid) is acceptable, but there is no point in displaying a new frame until you have cast at least that many rays. This takes a non-zero amount of time, so you can only do it so many times per second. If the camera has moved, there is no point updating the screen individually for each ray cast, because THE ENTIRE PREVIOUS FRAME'S WORTH OF INFORMATION IS NOW INVALID.

If the camera is stationary, then some of the information in the previous frame may still be valid, so you can increase image quality by simply casting more rays into the existing scene, filling in the gaps in the previous frame. However, if there are moving objects - or, in the worst case, moving light sources - in the scene, then again, you have to discard at least some of the information from the previous frame. Again, gathering enough new information to make a screen update worthwhile will take a non-zero amount of time, so you can only do it so many times per second.

If the camera, objects and light sources are all stationary, and you have already cast enough rays to satisfy the upper bounds of your image quality settings, then you can stop casting until something changes. This doesn't mean your FPS becomes "infinite", it just means that a raytracer with a well-written dynamic image quality system, effectively devolves to a static image viewer under optimal conditions.

[Qaridarium]

Sorry, Q, but I've *written* a raytracer and you are very confused.

no I'm not confused!

It is true that you can dynamically alter the performance of a raytracer by changing the number of rays cast, but that does not magically mean raytracers are somehow completely divorced from the concept of FPS.

you don't get it if you want have 24fps you do it if you want 100fps you do it if you want 1000fps you do it! ray-tracing doesn't matter about FPS at all!
in your "stupid" words: if you force 1000fps instead of 10 you only get less rays per "frame"
this prove the fact that FPS doesn't mean anything in the Ray-tracing world!

this means you are just wrong and i'm right!

It's also worth nothing that casting any less than one primary ray per pixel* will have a negative impact on quality:

this is also wrong in raytracing every ray do have the same quality ALL THE TIME!
you get the same Quality on slow hardware than on FAST hardware!

it is what i say from the start one: only the murmuring is different! slow hardware do have more murmuring and fast hardware do have less murmuring!

and ALL real-time Ray tracing do have murmuring this is a GOD law!

what you see in the Intel video is that when the camera moves, the engine casts fewer rays to keep the framerate at a level suitable for interacting with the scene; then, when the camera stops, the engine ramps the ray count back up again because there's no need for a high framerate when nothing is moving.

wen you start talking about framerate in a raytracing tropic you just LIE!

the Framerate doesn't matter you can force 1000fps! by GOD LAW! it just doesn't matter!

but you get a lot of "murmuring"

so please stop spamming bullshit to me.

Real Time Ray-tracing is all about "murmuring" and not frames per second.

It's a clever trick, but there's no magic which means you can scale from 1 FPS to 1000 FPS with no impact on quality.

o man the Quality of the RAYS are always the SAME! you use the wrong words if you talk about impact on quality its in REAL the "murmuring" rate what grows up.

you only get "murmuring" free rendering of you use a offline raytracing renderer then you calculate unlimited time to get a ray for every pixel.

in REAL time Raytracing you NEVER calculate unlimited time only to get a full frame without murmuring.

* A primary ray is one traced out from the camera's viewpoint, usually through the centre of a pixel in the image plane, to see what part of the scene it intersects. "Shadow" rays, reflected rays, refracted rays etc. are then cast from a primary ray's point of impact, and contribute to the final colour value rendered at the appropriate pixel, but if you don't cast at least one primary ray per pixel then you have to fill in the gaps with some sort of interpolation. Casting more than one primary ray per pixel is a great way to do anti-aliasing, but can be very expensive in terms of performance.

in real time raytracing you are just wrong you never calculate 1 ray per "Pixel" because of this you never get a FULL frame and because of this you never push frames per second because you never wait for a frame painted every pixel!

NEVER! means NEVER!

you push rays per second and if the pixel in the frame painted or not you send it to the display.