The Ideal (Hypothetical) Gaming Processor

[Qaridarium]

A 286 is too slow for interpolation but fast enough for interactive raytracing, are you serious?

YES! because of the definition of of REAL TIME RAY TRACING! and the "Murmuring"

if you have 99,9x% murmuring you don't need performance at all.

Also, your "I can ramp up the fps as much as I want" is only true if you're willing to completely sacrifice image quality. If you want any kind of consistent image quality then you need to use a consistent number of rays. Otherwise there's no point in using a raytracer in the first place.

no its not the "image Quality" its the Murmuring rate.

you get the same image quality with the intel-286 but you get 99,9x% murmuring.

a example for murmuring:



sure i know raytracing murmuring is different i only post the picture to make sure you know what murmuring is!

[Qaridarium]

Because if you haven't got the computing power to cast at least one real primary ray per pixel, you either just leave the rest of the pixels black, or you fill them in based on the colours of nearby pixels where you *have* cast primary rays.

For example, if you imagine a grid of 10x10 squares on your screen, and cast primary rays at every point where two grid lines meet, you can "guess" the colours of the rest of the pixels by blending the colours from the corners of the squares. You won't have a lot of detail in the resulting image, but it will at least cover the screen. This is just a naive example, there are better ways of deciding where to cast primary rays than a fixed-space grid.

sorry this was only a rhetorical question this means interpolation is not a part of real time ray tracing!

"you either just leave the rest of the pixels black," i already write that the "Pixel black" murmuring is 99,9x%

sure i know you talk about getting raytracing without "murmuring" but this was not the question.

murmuring in your definition= "you either just leave the rest of the pixels black,"

Bilinear interpolation can be performed much quicker than the calculations needed to cast a primary ray, unless your scene is really, really simple. When I say interpolation in this context, I basically mean "colour blending".

sure i know you want a product to sell it to people to earn money be sure no one buy a product with a murmuring rate of 99% means 99% is = "you either just leave the rest of the pixels black,"

but my rhetorical point was: FPS don't care because only the murmuring rate care!

[Wildfire]

I do understand what your so called "murmuring" is. And this is exactly what I mean be image quality. This "murmuring" is a trick employed on current hardware to be able to reach interactive speeds. For most applications this loss of image quality is _not_ acceptable, however. Would you want to play a game which looks like the television screen in your example? Which means you need to use a consistent number of rays. All the time. Which means you are no longer able to maintain interactive speeds.

[mangobrain]

Oh geez... I can't find any good screenshots demonstrating an adaptive sampling grid. I may have to resurrect my years-old raytracing code and make some.

When I said earlier that I wrote a raytracer, I should have said I wrote an *interactive* raytracer, specifically. It wasn't a very *good* interactive raytracer - it wasn't even multi-threaded, for example - but I was proud of it at the time, and I learned a lot in the process of writing it.

[Qaridarium]

I do understand what your so called "murmuring" is. And this is exactly what I mean be image quality.

the murmuring is not the same as Quality because in many cases the murmuring is a good effect makes the movement more natural this improve the image quality in some cases.
because in the reality you do have similar effect of a movement is fast in a fast movement you can't get the view clear all becomes a washed out washed out/wishy-washy

this means the murmuring makes it more "natural" in many cases.
because you get a wisky-washy effect in fast movements.

on the other side bad quality is always bad but murmuring is not always bad!

This "murmuring" is a trick employed on current hardware to be able to reach interactive speeds.

no its not a rick its a god law of real-time-raytracing but on fast hardware you get less and less murmuring.

For most applications this loss of image quality is _not_ acceptable, however.

no for the most applications this rate of murmuring is not acceptable!

big difference (no this isn't a joke its really a difference)

bad quality means= you need better software
a lot of murmuring means= you need faster hardware

Would you want to play a game which looks like the television screen in your example?

YES! because i also play on drugs like GBL and LSD

Which means you need to use a consistent number of rays. All the time. Which means you are no longer able to maintain interactive speeds.

interactive is not real time. you can get interactive speed with an offline ray-tracing engine if the hardware is fast. but with a real time ray-tracing engine you just have different murmuring.

[Qaridarium]

Oh geez... I can't find any good screenshots demonstrating an adaptive sampling grid. I may have to resurrect my years-old raytracing code and make some.

When I said earlier that I wrote a raytracer, I should have said I wrote an *interactive* raytracer, specifically. It wasn't a very *good* interactive raytracer - it wasn't even multi-threaded, for example - but I was proud of it at the time, and I learned a lot in the process of writing it.

now you pointing out the "interactive" part.. but you never get it a iterative ray-tracing engine is not a "Real-time-ray-tracing-engine"

Real time really means you only chance the murmuring rate. ALL the time on ALL costs!

[log0]

Hi everyone. I've been wondering what the "best" types of gaming CPUs would be, and I would like to know what it takes to make an idealized gaming-oriented processor.

Suppose I had a fabless semiconductor company, and I was contracted to design the CPU for a new game console. The GPU was already determined to be something relatively powerful, like a die-shrunk Radeon HD 6870. The goal is to make the chip as small and cheap as possible, but will never bottleneck the graphics processor.

What sort of difference does a processor's ISA make? Suppose I had licenses for MIPS, ARM, SPARC, and other risc-based architectures. Is the ISA really that important, or just the micro-architectural "plumbing" underneath?

What types of instructions do modern video games make the most use of? Do games find integer performance most important, floating point performance, or both? If floating-point calculations can be offloaded to the GPU, can the CPU's floating-point units be excised to make the chip smaller and cheaper, or would that harm system performance? If FP power is still important, would adding complex 256- or even 512-bit units be beneficial to total system performance, or just a waste of space?

How important is cache size? Intel's SNB i5, i7, and SNB-E i7 processors have 1.5, 2.0, and 2.5 MiB of L3 cache per core, but looking at benchmarks from Anandtech and other places, there doesn't seem to be too much difference. At least, not enough difference to justify the added space and expense. How much cache per core is "enough"?

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.

To get back to the topic. Assume one would use OpenCL for physics and rendering. I think you could get away with 2-4 simple RISC cores(without FPU). The cores would be there to feed the GPU with data and take care of game logic, interrupts and other boring stuff. Make them as fast as you can afford. Make sure there are no bottlenecks or large latencies between CPU cores and GPU. Throw 8GB shared memory with enough bandwidth into the mix and you should be good to go.

And make sure to keep the production costs low and yields high. No experiments a la PS3.

[WillyThePimp]

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!

(Rays per minute/60) / (Rays needed per scene to be considered complete) = Number of times the scene will be updated per second (FPS).

Everything in the computational world works in a discrete metric, you need to update the scene sometime, but you can't do it in a infinitely small gradient of time. Even real world works like this, if not, you would be leading yourself into to a paradox.

You don't have much idea of what you are talking, right?

[mangobrain]

now you pointing out the "interactive" part.. but you never get it a iterative ray-tracing engine is not a "Real-time-ray-tracing-engine"

Real time really means you only chance the murmuring rate. ALL the time on ALL costs!

Now you're just playing with words. "Real-time raytracing" does not have any hard and fast definition, it just means raytracing at a high enough frame rate & enough detail for a human being to watch/interact with the scene whilst it is being rendered. I prefer the term "interactive raytracing" because, in other areas of computing, the term "real-time" means guaranteeing a response within a certain time frame, which is usually NOT what people mean when talking about "real-time raytracing".

"Real-time" is NOT just another word for "high performance".

http://en.wikipedia.org/wiki/Real-time_computing

[Qaridarium]

(Rays per minute/60) / (Rays needed per scene to be considered complete) = Number of times the scene will be updated per second (FPS).

Everything in the computational world works in a discrete metric, you need to update the scene sometime, but you can't do it in a infinitely small gradient of time. Even real world works like this, if not, you would be leading yourself into to a paradox.

a real-time-ray-tracing engine is valid with 100% murmuring without sending any data to the screen.

ok this is not correct but this is correct: a real-time-ray-tracing engine is valid with 99,9999999% murmuring with sending only 0,0000000000000001 data to the screen.

You don't have much idea of what you are talking, right?

i do understand what is a real time ray-tracing engine!

and a realtime raytracing engine do not work in "FPS" it works in ray per second and murmuring rate.