Announcement

Collapse
No announcement yet.

The Ideal (Hypothetical) Gaming Processor

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

  • #91
    Originally posted by Pyre Vulpimorph View Post
    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.
    I think the best thing you can do to learn how a modern game works is to make one. Failing that (time pressure is a good reason why that's not feasible), go talk to game developers. Encompass the full range - indie, AAA, 2D, 3D, web browser based, desktop based, console based, mobile based, the works. Look at multi vs single threading, and how engines differ with that. Look at what OpenGL does across the different platforms. Look at actual engines and profile them (ogre, irrlicht, id software stuff, if you can't get numbers from elsewhere). Look at the power requirements, heat dissipation, active or passive cooling, etc etc etc. Look at peripherals (how many controllers are attached, etc).
    And also, talk to game developers about what they currently have, what problems they have to work around, and what they would like to have. Don't just look at things such as "virtualised textures", "cache control for data streaming", "z-buffer access", but also what languages to program in, if there's an OS to work with (or around), support, compilers, toolkits, the works. It's not just about the hardware, but software support too.

    Comment


    • #92
      @Pyre Vulpimorph: Why exactly are you focused on the CPU part? If you want to learn how modern games work you should probably take a look at 1. what they are doing, 2. how they are doing it, and finally "where" they are doing it (CPU/GPU). Like mirv said, either take a look at some open source games or ask people actually involved in such things.

      Basically anything aside from graphics is done on the CPU. This includes loading and saving stuff (levels, models, textures, ...), AI, input processing, game logic (path finding, scripted events, ...). Physics is usually also done on the CPU unless you're using a GPU that supports it.

      Originally posted by Qaridarium View Post
      Logic is a ultimate truth and if nativ speakers are not logical there thinking are damaned and this is a fact! this is right for all languages only in the mad-house this is wrong. "Language" is a lifing beeing you can fix that irratonal unlogic stuff.
      Yes, language is a living thing. But it's also an expression of cultural differences. You may be able to express a complex thought with a single word in one language while you need several sentences in another. Aside from that: Just because you're not fluent in a foreign language does not make it illogic (unlogic is not a word). If "noise" is the correct word to use in a given context this does not make it "wrong" just because you think it should be "murmuring". Instead of insulting native speakers, try actually learning their language to a sufficient degree?

      Comment


      • #93
        Qaridarium how would your ray trace engine handle vsync? Because you know if you dont use vsync your image will have tears.

        Comment


        • #94
          Originally posted by Pickle View Post
          Qaridarium how would your ray trace engine handle vsync? Because you know if you dont use vsync your image will have tears.
          a engine forced to the screen frame rate as a deathline of "realtime" do have a natural vsync ---

          if you get tearing then your realtime engine fail completely-

          Comment


          • #95
            Originally posted by Wildfire View Post
            Yes, language is a living thing. But it's also an expression of cultural differences. You may be able to express a complex thought with a single word in one language while you need several sentences in another. Aside from that: Just because you're not fluent in a foreign language does not make it illogic (unlogic is not a word). Instead of insulting native speakers,
            Originally posted by Wildfire View Post
            try actually learning their language to a sufficient degree?
            why not ask this google translate ?

            Originally posted by Wildfire View Post
            If "noise" is the correct word to use in a given context this does not make it "wrong" just because you think it should be "murmuring
            google image search prove it other people also use murmuring for the same
            maybe the english language is not that constistent.


            Originally posted by Wildfire View Post
            illogic (unlogic is not a word)
            Unlogik is a german word: http://de.wikiquote.org/wiki/Unlogik its a combination of 2 fragmentation of un-logik
            and in english logic is writen with C and "undo" is the same in english its a combination of 2 fragmentations un-do

            unlogic is "Right" and valid if the language is Logic!

            if this is wrong then undo is writen ido? yes the new I-Apple speach...

            also google translate gives me a good fall back in this point because google translate don't translate illogic to german....

            but google translate translate unlogic to the German:Unlogik

            this means Google translate really think unlogic is the translation for UNLOGIK

            this means ilogic is wrong.

            also there is no wikipedia article about ilogic and no wikiquote article and no wikionary article about ilogic !

            but there are nativ speakers using unlogic for example: http://startrekunlogic.wikia.com/wik...:_Unlogic_Wiki

            or http://www.beatportal.com/artists/unlogic/

            this means unlogic is a valid english word.

            this means you try to teach me the english language but your proving skill is worst.,

            Comment


            • #96
              Originally posted by Qaridarium View Post
              a engine forced to the screen frame rate as a deathline of "realtime" do have a natural vsync ---

              if you get tearing then your realtime engine fail completely-
              Never heard of a deathline, sounds bad though

              Can you engine support double buffering?

              Comment


              • #97
                Originally posted by Wildfire View Post
                illogic (unlogic is not a word).
                hey i search some more time on this tropic and my Dyslexia hit me i search for ilogic LOL ..

                yes Illogic is also right but unlogic is not wrong. both are posible.

                and google translate do it right and turn illogic to Unlogik

                so yes my Dyslexia hit me here sorry.

                Comment


                • #98
                  Originally posted by Pickle View Post
                  Never heard of a deathline, sounds bad though

                  Can you engine support double buffering?
                  LOL... double buffering is trivial... double buffering only mean your screen frame buffer is not the engine frame buffer.

                  real time means the rendering is finished in time to push the data to the output buffer.

                  Comment


                  • #99
                    Originally posted by Pickle View Post
                    Qaridarium how would your ray trace engine handle vsync? Because you know if you dont use vsync your image will have tears.
                    This Q's raytracer isn't "hard real-time" raytracer. The renderer is synchronized to display and every frame is rendered as long as it has time before next display refresh.

                    Comment


                    • real time means the rendering is finished in time to push the data to the output buffer.
                      ok there we have it, you are constructing a final image to put into the buffer to be displayed.

                      Your frames per second would be how often you do this complete transfer per second.
                      You would have tearing because your transfer is not in sync with the screen refresh rate. (meaning your updating the frame buffer as the hardware reads it to display on the screen)
                      You use murmuring to decrease the time to render, thus maintaining a frame rate or higher framerate than without murmuring.

                      Ray tracing is no different than rasterization in that it does computational work in order to produce a 2d image for display. Both can use different techniques to shorten the time it takes to produce the final image. In fact your murmuring is basically the same idea as level of detail or reducing screen resolution.

                      Both can have "unlimited fps" based on how they are written, ray tracing is limited by the CPU and rasterization is limited by the GPU. I have a simple game engine that uses rasterization and it can produce as many images as the GPU can calculate. Of course I can also limit it to vysnc.

                      This Q's raytracer isn't "hard real-time" raytracer. The renderer is synchronized to display and every frame is rendered as long as it has time before next display refresh.
                      Petteri then the Q's raytracer doesnt support "unlimited fps"

                      Comment

                      Working...
                      X