Announcement

Collapse
No announcement yet.

The Ideal (Hypothetical) Gaming Processor

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by Wildfire View Post
    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.

    Originally posted by Wildfire View Post
    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!

    Comment


    • #32
      Originally posted by mangobrain View Post
      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,"

      Originally posted by mangobrain View Post
      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!

      Comment


      • #33
        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.

        Comment


        • #34
          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.

          Comment


          • #35
            Originally posted by Wildfire View Post
            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!

            Originally posted by Wildfire View Post
            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.

            Originally posted by Wildfire View Post
            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

            Originally posted by Wildfire View Post
            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

            Originally posted by Wildfire View Post
            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.

            Comment


            • #36
              Originally posted by mangobrain View Post
              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!

              Comment


              • #37
                Originally posted by Pyre Vulpimorph View Post
                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.

                Comment


                • #38
                  Originally posted by Qaridarium View Post
                  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?

                  Comment


                  • #39
                    Originally posted by Qaridarium View Post
                    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

                    Comment


                    • #40
                      Originally posted by WillyThePimp View Post
                      (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.
                      Originally posted by WillyThePimp View Post
                      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.

                      Comment


                      • #41
                        Originally posted by mangobrain View Post
                        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
                        "Now you're just playing with words."

                        in never play with words the only problem is you try to play with words!

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

                        sure here you are right but i never use the words "high performance"

                        "it just means raytracing at a high enough frame rate"

                        no this is just wrong real-time-ray-tracing do not mean "frame rate"

                        "enough detail for a human being to watch/interact with the scene whilst it is being rendered. "

                        this is new for me i never read any definition like this.

                        do you mean its not ray tracing and not real time if the details are not a product buyed from humans? you do have a much different definition in REAL you mean capitalism you mean only if someone spend money on it then its the "True" real-time-raytracing.

                        yes sure in my definition no one spend money on it because my definition is only a technical definition and not a capitalism definition of selling a product to stupid humans.

                        " 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"."

                        be sure if people like me talk about real-time-raytracing they realy mean ""real-time" means guaranteeing a response within a certain time frame" and this means FPS doesn't matter because the time of the frame is only the deat-line to calculate.

                        and interactive raytracing is really what you mean this means you really rendering FPS but yes this is just stupid because calulating a result with only 99% trueness is much more faster than calculating a result with 100% trueness.

                        real-time-ray-tracing plays with this "Trueness" rate 0-100% its variable this is much faster and always playable and interactive!
                        Last edited by Qaridarium; 03-12-2012, 11:57 AM.

                        Comment


                        • #42
                          uh... what? I never mentioned anything about capitalism or buying products. I'm just pointing out that a lot of people say "real-time raytracing" when all they really mean is high-performance/interactive raytracing. Often the people who say "real-time raytracing" don't even know what real-time computing actually means.

                          You could write a raytracer which worked hard to try and guarantee a particular frame rate, and stop casting any more rays when the time budget for the current frame is elapsed, but that still isn't hard real-time computing because the correctness of the system does not rely on that frame rate being met. If the frame rate is not met, all that happens is the performance drops for a moment. Such a system is at best soft real-time, using the definitions from the Wikipedia page under "Criteria for real-time computing".

                          "Interactive raytracing" just means raytracing at a frame rate high enough to interact with the scene. It's not very realistic to interact with a scene in a system which takes 10 minutes to render each frame, is it? "Interactive" doesn't imply any hard constraints, the speed needed to consider something "interactive" is subjective.

                          Comment


                          • #43
                            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.
                            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.

                            Comment


                            • #44
                              Originally posted by mangobrain View Post
                              uh... what? I never mentioned anything about capitalism or buying products. I'm just pointing out that a lot of people say "real-time raytracing" when all they really mean is high-performance/interactive raytracing. Often the people who say "real-time raytracing" don't even know what real-time computing actually means.
                              its not my problem if the people are dump and without knowledge.

                              and i really think you mean it in the way that you can sell it to humans.
                              because if you write a software or build a hardware what fits all your criteria you are a rich man and you sell well to humans.

                              because of this you really think in "Capitalism"



                              Originally posted by mangobrain View Post
                              You could write a raytracer which worked hard to try and guarantee a particular frame rate, and stop casting any more rays when the time budget for the current frame is elapsed, but that still isn't hard real-time computing because the correctness of the system does not rely on that frame rate being met. If the frame rate is not met, all that happens is the performance drops for a moment. Such a system is at best soft real-time, using the definitions from the Wikipedia page under "Criteria for real-time computing".
                              "Interactive raytracing" just means raytracing at a frame rate high enough to interact with the scene. It's not very realistic to interact with a scene in a system which takes 10 minutes to render each frame, is it? "Interactive" doesn't imply any hard constraints, the speed needed to consider something "interactive" is subjective.
                              " frame rate high enough " LOL there is no frame rate. really there IS NO FRAME RATE°!

                              with raytracing you can have 100fps or higher ALL the time ! to think in FPS is useless in this tropic!

                              "It's not very realistic to interact with a scene in a system which takes 10 minutes to render each frame, is it?"

                              if you do have a real-time-ray-tracing engine then your interacting time with the system is always fast and always the same!

                              there is only FPS in ray-tracing if you FORCE it by the stupidest ever written code. and because of this stupid code you need fast hardware to get a good interacting time rate.

                              if you do it right then you do it with the highest possible interacting rate this means you only can save resources on the resolution and murmuring rate.

                              all other ways are bullshit because it hurts the interacting rate and force you to buy faster hardware.

                              Comment


                              • #45
                                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.
                                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.

                                Comment

                                Working...
                                X