Xbox One (Durango) Technical hardware investigation

Discussion in 'Console Technology' started by Love_In_Rio, Jan 21, 2013.

Thread Status:
Not open for further replies.
  1. Brad Grenz

    Brad Grenz Philosopher & Poet
    Veteran

    Joined:
    Mar 3, 2005
    Messages:
    2,531
    Likes Received:
    2
    Location:
    Oregon
    Even doing it in software would only cost like one half of one percent of the Orbis GPU's total processing power. So unless the Orbis version inexplicably needs 100+ HUDs composited in one at a time it should be fine.
     
  2. inefficient

    Veteran

    Joined:
    May 5, 2004
    Messages:
    2,121
    Likes Received:
    53
    Location:
    Tokyo
    Like it has been said before... lots of PS3 games already do this. People are making mountains out of mole hills.
     
  3. patsu

    Legend

    Joined:
    Jun 25, 2005
    Messages:
    27,614
    Likes Received:
    60
    Yep, I think it's more for features like in-game video chat (for example) with Rockstar's next game. Our regular HUDs are quite trivial in comparison. Those video chat live feeds should give way to the game, like how Torne DVR yields to PS3 game during recording.
     
  4. astrograd

    Regular

    Joined:
    Feb 10, 2013
    Messages:
    418
    Likes Received:
    0
    I know, I thought we were referring to the other 2 display planes. :?:
    Hmmm...fair enough. I don't see anyone suggesting they aren't 'sacrificing' anything. That seems to be the point of having them! I view these planes are moreso giving devs an extra tool for deciding how to manage resources effectively.

    Why utilize a software solution that requires additional processing first and foremost when hardware does it for free? I can see doing both, but why prioritize the software approach ahead of the hardware approach instead of the other way around? Just by the sound of it wouldn't the hardware approach be objectively smarter to leverage first and then use software if need be?
    If it wasn't useful we wouldn't be having a conversation about which is the better way to implement it would we? :wink:

    I am still unsure about your assertion here though. I agree the planes do all of that, but if (might be a big if, honestly not sure so feel free to correct me with evidence to the contrary!) the planes have no distinction between one another, what would keep devs from rendering foregrounds in the HUD plane and a background in the game plane? This sounds like it could be much more helpful in terms of resource management since backgrounds are inherently blurry in most modern games anyhow. In this sense I am suggesting they may be pretty big deals due to the options they afford devs as opposed to only viewing their benefits from the perspective of a hardware vs. software dynamic res comparison.

    I'm not disagreeing with this. I'm suggesting that there are gaming benefits for visuals that may be leveraged in addition to the obvious OS applications.

    But this right here sounds like it may be leveraged to do foreground/background sort of stuff instead of simply HUD overlays. That to me sounds like a HUGE difference in terms of how devs can leverage it in modern games.

    Certainly possible (practically guaranteed imho). That doesn't somehow limit its application to gaming though.
     
  5. Averagejoe

    Regular

    Joined:
    Jan 20, 2013
    Messages:
    328
    Likes Received:
    0
    Well the PS2 was more powerful in all areas than the DC,from GPU to CPU to ram.

    The dreamcast was just friendlier to develop for.
     
  6. astrograd

    Regular

    Joined:
    Feb 10, 2013
    Messages:
    418
    Likes Received:
    0
    So just to ask, does anyone see anything either in the patent or the VGLeaks article that suggests devs couldn't use one plane to display a foreground in a game at one res and the background of the game world in another, with DoF or whatnot applied to it? It seems to me that if the 2 application/game planes are the same in their operation you could do something like that, leaving the lower LOD background at dynamic res/HDR, etc and potentially save tons on the fillrate. Or no?
     
  7. patsu

    Legend

    Joined:
    Jun 25, 2005
    Messages:
    27,614
    Likes Received:
    60
    Because software is flexible and specific. You can usually find pockets of stuff to optimize based on additional application knowledge. Modern GPU is done by programmable shaders and compute units right ?

    I'm not prioritizing it based on h/w vs s/w. The dynamic resolution technique (even if done by software) starts with compromise first. I'm saying developers will look at the whole "picture" first and see if they can do it without compromises.

    As for hardware leverage, they will take advantage of h/w acceleration as long as they see benefits; and the h/w setup doesn't interfere with where they want to go. 360 has "free" AA but I think not everyone used it (unless the TRC mandates its use).
     
  8. astrograd

    Regular

    Joined:
    Feb 10, 2013
    Messages:
    418
    Likes Received:
    0
    You said devs should start with a software approach first. That kinda statement makes it sound like you were prioritizing sw over hw.

    Right...and this gives those devs one more option to tweak/manage while trying to decide how to maximize the meaningful detail displayed on screen. This is in addition to any software approach they may want to take.
     
  9. patsu

    Legend

    Joined:
    Jun 25, 2005
    Messages:
    27,614
    Likes Received:
    60
    I said:
    ...because you started talking about dynamic resolution using the display planes first.

    Sure, but I doubt they will start by talking about dynamic resolution first. If they can find a way to avoid downgrading the resolution, they may prefer that approach. Whether it uses the display planes would be a natural decision after that.

    e.g. They may look at their existing engine architecture first. Some devs also have multiplatform considerations. They may also consider display plane uses in other ways.
     
  10. Shifty Geezer

    Shifty Geezer uber-Troll!
    Moderator Legend

    Joined:
    Dec 7, 2004
    Messages:
    40,597
    Likes Received:
    11,002
    Location:
    Under my bridge
    Yes, but ti's not as exciting as you think. Firstly, DOF applied to a plance is just a background blur. Planes won't help in creating high quality DOF effects. Secondly, the game engine still needs to render out two seperate passes into two separate buffers and combine them. The rendering output resolution and refresh is developer controlled. Any game can choose to separate out the background, render it a lower resolution (and not just background, but particles and other 'layers' which happens frequently), and then composite. The difference with Durango is the compositing is happening in a hardware video out device. I still expect games to use software multiresolution buffers and composite just as they do now. Particles and reflections will be rendered in a separate pass to a lower resolution, blurred, upscaled, and composited with the many geometry and lighting. If Durango isn't a hardware deferred renderer, it'll have no advantage in any of that. And with deferred rendering, you'll have lots of buffers where the ability to alpha blend two in hardware isn't going to help.

    The planes system is pretty clear to have low res game + high res UI + OS. That's why it's fixed at 3 planes instead of being generic upscale and blend hardware. It's probably a tiny piece of silicon, using 1% of the silicon budget to provide 3% of the rendering power, making it an efficiency optimisation more than a performance optimisation. The on-screen results are likely just going to be very clean UIs and smooth OS integration. ;)
     
  11. Love_In_Rio

    Veteran

    Joined:
    Apr 21, 2004
    Messages:
    1,444
    Likes Received:
    108
    What are the average latency differences between:
    -6T - SRAM
    -1T - SRAM
    -DRAM

    This article about SiSoft Sandra´s caches latency measurement is very very good to understand how a low latency main pool of memory could improve efficiency in a GPU in a radical way:
    http://www.sisoftware.net/?d=qa&f=gpu_mem_latency

    The latency of the main memory directly influences the efficiency of the GPU, thus its performance: reducing wait time can be more important than increasing execution speed. Unfortunately, memory has huge latency (today, by a factor of 100 or more): A GPU waiting for 100 clocks for data would run at 1/100 efficiency, i.e. 1% of theoretical performance!
     
    #1031 Love_In_Rio, Feb 13, 2013
    Last edited by a moderator: Feb 13, 2013
  12. french toast

    Veteran

    Joined:
    Jan 5, 2012
    Messages:
    1,667
    Likes Received:
    9
    Location:
    Leicestershire - England
    Damn that latency!! If durango has a very low latency sram..then thatooks to be a VERY smart thing to do...interesting how that article says improved latency would increase gpu performance better than faster execution resources. ....mmm.
     
  13. Love_In_Rio

    Veteran

    Joined:
    Apr 21, 2004
    Messages:
    1,444
    Likes Received:
    108
    If latency is 20 cycles or less we could see the 800 mhz CUs behave like a 3x800 = 2400 mhz CUs, and so, getting the rumored 680GTX performance.

    What if it is called Kryptos because the ESRAM is the system kryptonite?.
     
  14. french toast

    Veteran

    Joined:
    Jan 5, 2012
    Messages:
    1,667
    Likes Received:
    9
    Location:
    Leicestershire - England
    Ha yes! Now were talking...does seem hard to believe we will be seeing anywhere near that kind of performance though...

    Edit perhaps we could see some increased performace with the shaders...3x seems too fantastical to me.
     
  15. kots

    Regular

    Joined:
    Oct 30, 2008
    Messages:
    394
    Likes Received:
    0
    So that's why Microsoft put an outdated GPU inside the 720 , because of the ESRAM ... maybe it will more than make up for any limitations ... that's how you get the"680gtx performance" .
    That's amazing .
     
  16. Love_In_Rio

    Veteran

    Joined:
    Apr 21, 2004
    Messages:
    1,444
    Likes Received:
    108
    Well, the ESRAM if really 6T-ESRAM will be very big but the TDP that will provide will be very little. And yields, well, will be very low. But if performance / tdp is so good then MS could be in something.

    Let´s wait for the Vgleaks memory config article.
     
  17. Gubbi

    Veteran

    Joined:
    Feb 8, 2002
    Messages:
    3,519
    Likes Received:
    852
    The size of the embedded RAM array won't affect yield at all. It is trivial to build rendundancy into the array to counter any yield issues.

    It is unlikely to be SRAM because of cost.

    The low latency won't help rendering much, but it might very well boost GP compute.

    The extra bandwidth will help both, the alternative is to cut capacity and spend more money doing so.

    Cheers
     
  18. Love_In_Rio

    Veteran

    Joined:
    Apr 21, 2004
    Messages:
    1,444
    Likes Received:
    108
    When you say rendering you include also avoiding ALUs stalls?. Because in the article i posted you can see how when the more random accesses to main memory the more cycles ALUs are waiting for data. So, the boost would not restrict only to GPGPU ops, but also to GPU ordinary shader ops.
     
    #1038 Love_In_Rio, Feb 13, 2013
    Last edited by a moderator: Feb 13, 2013
  19. Gubbi

    Veteran

    Joined:
    Feb 8, 2002
    Messages:
    3,519
    Likes Received:
    852
    The article you linked to specifically mentioned SiSoft Sandra's cryptography benchmark, a GPGPU benchmark.

    Cheers
     
  20. Love_In_Rio

    Veteran

    Joined:
    Apr 21, 2004
    Messages:
    1,444
    Likes Received:
    108
    In that case the example of 3x800 mhz would be only for GPGPU ops, and in this way we already would have matched the 7970 performance for GPGPU ops.

    Well, i don´t know how much efficiency GCN architecture gets with general shader ops but i supposse that wavefronts management in the CUs won´t be able to hide all the latency misses in the 100% of the cases when we are talking of visual memories with 300-500 latency cycles, so, the question is now...
    What are the ALU average usage in the GCN architecture when not doint GPGPU ops with rendering shader intensive code?.
     
    #1040 Love_In_Rio, Feb 13, 2013
    Last edited by a moderator: Feb 13, 2013
Loading...
Thread Status:
Not open for further replies.

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...