Page 8 of 11 FirstFirst ... 678910 ... LastLast
Results 71 to 80 of 108

Thread: The Ideal (Hypothetical) Gaming Processor

  1. #71
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by mangobrain View Post
    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:
    Last edited by Qaridarium; 03-13-2012 at 10:48 AM.

  2. #72
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by AnonymousCoward View Post
    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.

  3. #73
    Join Date
    Sep 2008
    Posts
    22

    Default

    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.

  4. #74
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by Petteri View Post
    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 !

  5. #75

    Default

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

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

  6. #76
    Join Date
    Sep 2008
    Posts
    22

    Default

    Quote Originally Posted by Pyre Vulpimorph View Post
    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.

    Quote Originally Posted by Qaridarium View Post
    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.

  7. #77

    Default

    Here, ACTUAL CONTENTS OF THIS THREAD:

    Quote Originally Posted by Wildfire View Post
    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.
    Quote Originally Posted by AnonymousCoward View Post
    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.
    Quote Originally Posted by log0 View Post
    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.
    Quote Originally Posted by mirv View Post
    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.
    Quote Originally Posted by log0 View Post
    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.
    Quote Originally Posted by mirv View Post
    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.
    Quote Originally Posted by log0 View Post
    I am assuming shared/unified memory in my proposal.
    Quote Originally Posted by mirv View Post
    Ah, I appear to have misunderstood that. My bad. So.....excellent idea!
    Quote Originally Posted by elanthis View Post
    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?

    Quote Originally Posted by log0 View Post
    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?

  8. #78
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by Petteri View Post
    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.

    Quote Originally Posted by Petteri View Post
    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.

  9. #79
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by Pyre Vulpimorph View Post
    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.

  10. #80
    Join Date
    Nov 2009
    Posts
    22

    Default

    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?

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •