Xbox One November SDK Leaked

They have some quick shortcuts to record ... double hit xbox button then choose directional pad to record that or snap other apps.

 

maybe add a warning at game boot if the game allowed to use such extreme system resource? just like PS Vita says "WIFI is DISABLED while you are playing this game" that allows the GPU to be overclocked. So xbox says "Voice command is disabled while you are playing this game".

 

System voice commands cannot be disabled, as far as I can tell. It's only removing the ability to add custom commands to your game.

 

hope MS sticking with this. Keep pushing voice command and make it even more easier to use until people will miss voice command when its unavailable.

 

Caches and Coherency on the Xbox One GPU

Command Lists, Draw Bundles, and Deferred Contexts

Xbox One GPU Overview

 

So is this something specific to the Xbox One implementation of GCN (they have a custom bus iirc) or is it part of PC and PS4 implementations too?

I recall an audio developer talking about high latency for compute tasks limiting what they could do using compute - I think for PS4 - and at least superficially this would seem to be at odds with that.

 

alias "Xbox One / GCN supports multiple wavefronts in flight per CU"
It's regular stuff, just MS not using tech words.

 

Yes, I understand that all GCN support multiple wavefronts and can interleave rendering and compute, but this part:

"In particular, compute tasks can leapfrog past pending rendering tasks, enabling low-latency handoffs between CPU and GPU."

... wasn't something I remember reading a before. It makes it sound like you can explicitly push chosen compute tasks to the front of the queue, rather than add them and just let the GPU prioritise based on unused resources in the CUs.

But perhaps that's just a standard part of GCN. Being able to chose the order and priority of things in the queue would be useful on all platforms, I guess.

 

I'm not sure if this helps answer the question, because from the sounds of it, the bolded above is ultimately about efficiency when you require it.

From the architects interview the customizations to the command processor are the following:

 

That would be a pretty shitty thing to do to people who paid extra for Kinect only to have the advertised universal functions taken away.

 

In general, voice commands work great on the Bone. I would not want to go back to a time when we didn't have them.

 

I use the Kinect every time. Snapping and unsnapping apps through Kinect is pretty useful when double-tapping the guide button doesn't work too well (and there are plenty of times when I double-tap the guide button and it sends me to the dashboard instead of snapping).

 

Seems the new SDK eSRAM flexibility the Dying Light devs spoke of lets them put things into DRAM much easier than before. Hopefully this allows many more games to get to 1080p instead of trying to stuff everything into eSRAM and ending up around 900p.

 

Thanks. It really does seem that MS have made some none standard additions to the command processor. Whether these do relate to gaming, and the aforementioned queuejumping of compute I dunno. Hopefully DF can get them to spill more beans over time.

The common (mis)conception is that because the X1 is less powerful, it means that MS didn't do as much work as Sony. On the contrary, MS seem to have put far more work into customising the AMD IP. Unfortunately them aimed a little low with their performance target ...

 

Okay, so here's a question for those that unlike me have read the leaked docs:

Would the virtual addressing for GPU buffers allow developers to control precisely which sections of a buffer were is sram? I'm talking about at a much finer level than just "the top 30%".

For example, the sections of a render buffer that would be obscured by the hud. They an energy bar wouldn't be represented by a single range of virtual memory, but (probably?) by several strips/linear ranges of memory. If you knew which these addresses would be and could put these completely obscured ranges in main memory then you could save on the amount of sram needed to store the sections of the buffer that required R/W.

If, say, 10% of your screen was obscured by the HUD, then putting that section in low BW memory and simply not writing to it might be useful ...?

 

I don't see anything in the leaked docs that proves it's possible. Not to mention that linear page addressing will get you more or less to the same scenario: just use top and bottom parts of a render target, the HUD is usually there anyway.

 

Yes, I know that a HUD is normally to the top and bottom, but I was wondering about fine control over which pixels you put where. For example, driving through fire and water at ground level (potentially lots of overdraw) wouldn't be a good fit for putting the bottom part in main ram. If you could still put most of the none hud area in sram it'd work better.

 

It appears that any part of a pixel within your render target can be selectively placed in esram vs ddr3 .. up to the dev an how much optimizing they want to do ..

A more complex option is to enable 4x multisampling with the first two fragments of every pixel in ESRAM and the last two fragments in DDR3.

 

Pretty please, keep this thread to information out of the SDK doc?

 

Things moved to the HW discussion thread: https://forum.beyond3d.com/threads/xbox-one-durango-technical-hardware-investigation.53537/