Page 10 of 11 FirstFirst ... 891011 LastLast
Results 91 to 100 of 108

Thread: The Ideal (Hypothetical) Gaming Processor

  1. #91
    Join Date
    Oct 2007
    Posts
    912

    Default

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

  2. #92
    Join Date
    Feb 2012
    Posts
    67

    Default

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

    Quote 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?

  3. #93
    Join Date
    Jun 2008
    Posts
    74

    Default

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

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

    Default

    Quote 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-

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

    Default

    Quote 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,
    Quote Originally Posted by Wildfire View Post
    try actually learning their language to a sufficient degree?
    why not ask this google translate ?

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


    Quote 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.,

  6. #96
    Join Date
    Jun 2008
    Posts
    74

    Default

    Quote 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?

  7. #97
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

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

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

    Default

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

  9. #99
    Join Date
    Sep 2008
    Posts
    23

    Default

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

  10. #100
    Join Date
    Jun 2008
    Posts
    74

    Default

    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"

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
  •