The Ideal (Hypothetical) Gaming Processor

[Qaridarium]

Did you try reversing the polarity of the neutron flow?

i do not unterstand your sentense sorry but i try to explain it.

if you have resolution zones zones

how zone based deinterlace raytracing works

for example 2 zones

0000
0000
0000
0000

0000
0000
0000
0000


then the first ray hits a zone in the first pass

X000
0000
0000
0000

now 3 more rays hits the second zone:
X000
00x0
0x00
000x

this turns the resulution to:

X0/00
00/x0
------
0x/00
00/0x


then in the first zone your resulution is the lowest and in the second zone your resolution is higher 4 of 16


the first zone is stile the lowest resulution
X000
0000
0000
0000

the second zone now hits all rays to a pixel then its goes to the max resulution:

X/x/x/x
---------
x/x/x/x
--------
x/x/x/x
----------
x/x/x/x

now you turn the result to the frame

X000
0000
0000
0000
=x


X0/00
00/x0
------
0x/00
00/0x
=
xx
xx

X/x/x/x
---------
x/x/x/x
--------
x/x/x/x
----------
x/x/x/x
=
xxxx
xxxx
xxxx
xxxx


in this way you do have a scaling in real time without murmuring over a "Virtual" "zone" resolution

First run makes sure every zone gets a

X

second run makes sure every zone gets a

xx
xx

and the last run makes sure every zone gets a

xxxx
xxxx
xxxx
xxxx

if the time is over for a frame it skips the next level and send the result to the frame.

adam7 for example:

[Qaridarium]

Just keep the previous frame and overwrite only those pixels you have calculated. Will probably look like trying to decode a video with missing data, people should be used to that by now from digital tv.

Right! it works! and if you do have fast hardware and if you have a zone based deinterlace algorithm you get maybe a better result than that.

[Petteri]

Sorry, but it doesn't work at all if the scene changes ALL THE TIME. The raytracer gets scene and traces few rays -> scene changes, tracer traces few rays -> scene changes, etc. etc.
The result is huge amount of wasted compute power and mess as an output.
Why not do it the traditional way?
Raytracer gets scene, traces lots of rays for x milliseconds and after that the 'finished' frame is drawn to screen and loop starts again. If the rendering time is shorter than display refresh interval you can't notice any difference in smoothness.
For defining frames per second you lose nothing and get better quality output and smaller resource usage.

It's just bad programming to run the code without speedlimits if it doesn't gain you anything. If screen refresh rate is xHz, it is just stupid and pointless to run game engine over x times per second.

[Qaridarium]

If screen refresh rate is xHz, it is just stupid and pointless to run game engine over x times per second.

LOL this is my point not "there" point for me the xhz of the screen is the time death line of the real-time raytracer!

the real point is the "Others" want less FPS than screen refresh rate and i always push the screen refresh rate !

[Pyre Vulpimorph]

Sweet mother of John DeLancie... what the hell happened to my thread?!

Oh, right, got hijacked by Q. Spirit of Chaos and Disharmony.

[Petteri]

Sweet mother of John DeLancie... what the hell happened to my thread?!

Oh, right, got hijacked by Q. Spirit of Chaos and Disharmony.

I have to admit that Q is very good. Amazing ability to steer thread to offtopic with full power and everyone follows.

LOL this is my point not "there" point for me the xhz of the screen is the time death line of the real-time raytracer!

the real point is the "Others" want less FPS than screen refresh rate and i always push the screen refresh rate !

Ah, I think I get the point now (again). The consept of frames per second applies for raytracing and this real-time ray-tracing just means that it is being kept at display refresh rate at all times. And raytracer keeps rendering the frame as long as it can before next screen refresh.

[Pyre Vulpimorph]

Here, ACTUAL CONTENTS OF THIS THREAD:

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.

If floating points are handled by your CPU, make sure they are deterministic. http://nicolas.brodu.numerimoire.net...lop/index.html describes the problems you can encounter on current PCs.

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.

If physics takes place entirely on the GPU, then your bi-directional communication needs to be rather good between CPU and GPU. Physics will generally trigger game logic events (depending on the game of course), so while the GPU can handle physics calculations faster, it's the need for a feedback system that destroys it for anything more than eye-candy with current architectures. I have been curious how well AMD's Fusion systems can be made to work with that, but I don't really have time to delve into it in more than a theoretical capacity. At least, don't have the time yet.

If I think of a single simulation step:
Prediction
Broadphase
Contact Generation
Correction/Solver

Lets say the intermediate results form the last step are available to the cpu to tinker with at the same time. There will be a lag of at least one frame. But for game events it should be negligible.

Reading back from the GPU is quite costly. You certainly want to avoid it as much as possible - unless you can share the memory with a zero-copy buffer (in theory). Sure it's getting easier with current architectures and bus speeds for data readback, but I'm pretty sure it's still costly enough that you don't want to do it. This is why most games will only use particle effects, or physics related calculations that's classified as "eye candy" and doesn't directly affect gameplay logic.
Also, graphics cards still need to do graphics.
I guess it depends on the game, how much physics calculations you need to affect game logic (those ones are generally very simplistic compared to, say, cloth simulation) and where your bottleneck will be (calculations vs data transfer). It would be interesting to see just what kind of balance point can be found...maybe something like ants (for path update AI code) combined with "dodge the particles". Sucks having a day job and not being able to explore such ideas properly.

I am assuming shared/unified memory in my proposal.

Ah, I appear to have misunderstood that. My bad. So.....excellent idea!

You need more than that, though. For instance, quite a few non-trivial games need to have pre-contact callbacks in the contact generator in order to properly ignore contacts. The absolute simplest example is a 2.5D platformer (think Trine) where you can jump up through some objects but still land on them. This is generally implemented by an engine with contact caching (requiring random-access read-write storage in the physics engine, which is not GPU-friendly) and a pre-contact callback that flags the contact as ignored if the surface-player contact normal is not pointing up.

More complex 3D physics uses those callbacks for more complex needs.

Physics can be made GPU-friendly, but only in the non-general case. That is to say, certain features of fully-featured physics engines like Havok or PhysX or whatnot simply do not work well with GPUs, and only games that avoid those features can reasonably use GPU-based physics.

So far as the rest of this thread... why in the fuck are any of you trying to converse with Qaridium still? Theres's an Ignore User feature on this forum. Use it.

I'm new here... is there a "Block User From My @#$%! Thread" feature?

The simple example could be dealt with on the GPU by passing additional state to decide whether a contact is added or not. Of course there are limits to this method. I've got some experience with bullet physics lib. I've used callbacks, but more out of convenience. To avoid having to adapt the code for my needs and not because there was no other way to implement certain functionality. But that is my (limited) point of view of course.

Apologies if I missed other relevant posts.

The point of this thread, really, was so I can learn more about how modern games work. Specifically, what the CPU is left doing while the GPU is busy rendering frames. So, let's shoot for the moon and say my client's system will include a Radeon HD 7870 (pitcarin) GPU, and "normal" output resolution is going to be 1920x1080p.

System memory will be 2-4 GiB of DDR3 CAS-6 @ 1600 MHz, framebuffer memory will be 2 GiB of GDDR5 @ 6000 MHz

I decide to build and 8-core MIPS64 that's 4-lane superscalar, but no SMT. It has dynamic out-of-order execution, speculative execution, regester renaming, and a fairly long (for RISC) instruction pipeline with aggressive branch prediction. Each core has 512-bit deterministic floating point units. Each core has 128 KiB of L1 cache, 512 KiB of private L2 cache, and 16 MiB of L3 cache is shared across the 8 cores (2 MiB per core).

The chip has a quad-channel memory controller, and talks directly to the GPU via 32-bit HyperTransport 3.1 connection link.

--------

Again, while I don't presume to know everything there is to know about CPU design, the goal is to make the chip as small and cheap as possible without ever bottlenecking the GPU, and still providing advanced functionality (like accurate real-time physics). So, all that junk I just spit out might not be an "optimal" design.

Any thoughts?

[Qaridarium]

Ah, I think I get the point now (again). The consept of frames per second applies for raytracing and this real-time ray-tracing just means that it is being kept at display refresh rate at all times. And raytracer keeps rendering the frame as long as it can before next screen refresh.

wow now you get it... and if the refresh frame rate is all the time the same then what a sense does the FPS rate make? nothing!

but yes I'm happy you understand me finally.

I have to admit that Q is very good. Amazing ability to steer thread to offtopic with full power and everyone follows.

first of all thank you... but this time you are wrong because if ray-tracing is the future you need ray-tracing hardware and this is the tropic! ray tracing doesn't care about "Single-thread-performance" the fastest hardware for ray-tracing right now is a hd7970 with 6gb of vram.

no CPU on earth can beat that card in ray-tracing.

this means this time I'm innocent.

[Qaridarium]

Sweet mother of John DeLancie... what the hell happened to my thread?!

Oh, right, got hijacked by Q. Spirit of Chaos and Disharmony.

yes i like it very much i believe in discordianism!

but this time i'm innocent! if ray-tracing is the future you need raytracing hardware and not your old style CPUs

read the thread again my claim is : the hd7970(6gb vram) is the fastest card for ray-tracing!

this means you don't need a fast cpu... you can buy a quatcore for 50€ or a ARM quatcore for less than 50€ and use a bigblock hd7970 or 4 of them and just push the rays..

this technique just bankrupt "INTEL"

and yes you really need much ram for your gpu 6GB or higher because this is a bottle neck in raytracing.

[Mathias]

To derail this thread further: Did anyone ever try motion compensated raytracing? I was amazed to realize they are using the last frame as an initial guess for the new rendering, so you get free motion blur. What I'd do is, from the known motion vectors, interpolate the next frame and use that as an initial guess for the raytracer. I think that would reduce the "murmuring" a lot without creating too much motion blur. Also if the interpolation was fast enough, an intelligent raytracer could shoot more rays in those sections that are unknown from the interpolation, like if a moving object reveals what lied behind, shoot rays there because the interpolated image can't know what should be there.
Kind of what was done with SW Foce Unleashed, but not to increase framerate, but to increase picture quality. (One could of course render at half the fps and interpolate to double the fps, but thats not the idea here.)

Also a question to Qaridarium: I think most of us understand what youre trying to do, but youre not a native speaker are you? (neither am I) I think much of the misunderstanding are because people don't understand what you say or you don't understand what others say. Everyone knows how real time raytracing works, but at least to my knowledge, you use uncommon terms like murmuring and you are very much fixated on those terms. Are there any technical papers that use the same terms like you?