Xbox One (Durango) Technical hardware investigation

[dobwal]

That and probably servicing all that extra logic that exist outside the core of the gpu. Seems like there are bunch more logic on gpu that the core gpu logic treats like peripheral i/o devices, which would encourage increasing the DMA count.

Seems like to me unless the DMEs do something special, there has been an over emphasis on those devices. What the difference of calling these devices "DMEs with compression functionality" and calling the traditional AMD DMAs "DMEs with gpu functionality".

 

[Grall]

I thought that would be the case but when I was reading Humus's post about EDRAM, he says:

The X360 GPU likely stops because the copying process blocks access to eDRAM for a relatively long period of time since you're reading out an entire framebuffer in one go and there is not - as you point out - generally room for more than one buffer at a time either; the RAM is not multiported, so only one data consumer can read or write to memory. However there's fundamentally nothing that says the shader arrays has to stop working just because you're DMAing stuff in RAM, as long as the shader programs don't need access to memory also; it's not the shader processors that handle DMA transfers. In fact it would be really bad if the entire GPU halted entirely many times per frame just because some stuff needs to be transferred to or from local memory.

 

[Cranky]

That and probably servicing all that extra logic that exist outside the core of the gpu. Seems like there are bunch more logic on gpu that the core gpu logic treats like peripheral i/o devices, which would encourage increasing the DMA count.

Seems like to me unless the DMEs do something special, there has been an over emphasis on those devices. What the difference of calling these devices "DMEs with compression functionality" and calling the traditional AMD DMAs "DMEs with gpu functionality".

MS has stated before that the tiling is custom and enhanced specifically for their architecture.

 

[Betanumerical]

MS has stated before that the tiling is custom and enhanced specifically for their architecture.

Can you give us a link on that, I remember that they added new texture formats, but tiling not so much.

 

[tunafish]

since Xbox One has 32MB, this may change, so the GPU wouldn't have to wait for its result to be transferred to main ram.

You could treat the sram as two 16MB buffers that you swap around, but honestly, for most real use cases having twice the pool is *way* better than the rather small portion of throughput you lose for idling the rops while you copy out.

So what do the XBO-specific DME's 'improve' or reduce the need for?

I have a feeling that the extra Move Engines are there for Kinect & the OS. (well the JPEG part anyway)

I wouldn't say that. Seems to me that they were designed to allow virtual geometry and texturing for near zero cost. JPEG is a decent format for keeping most of your textures in, when you need some texture you can just issue a DMA command to copy and uncompress it to the live set. LZ is bad for textures but I think it's pretty decent for geometry?

 

[dumbo11]

I wouldn't say that. Seems to me that they were designed to allow virtual geometry and texturing for near zero cost. JPEG is a decent format for keeping most of your textures in, when you need some texture you can just issue a DMA command to copy and uncompress it to the live set. LZ is bad for textures but I think it's pretty decent for geometry?

The LZ compressor is 150-200MB/s, the JPEG compressor at ~220-330MB/s.

In terms of usage, AFAICT neither appears to be intended for direct rendering-related functions.

The canonical use for the LZ decoder is decompression (or transcoding) of data loaded from off-chip from, for instance, the hard drive or the network. The canonical use for the LZ encoder is compression of data destined for off-chip. Conceivably, LZ compression might also be appropriate for data that will remain in RAM but may not be used again for many frames—for instance, low latency audio clips.

The Eurogamer/DF interview implied that the JPEG feature was primarily to help kinect data transfer.

 

[onQ]

You could treat the sram as two 16MB buffers that you swap around, but honestly, for most real use cases having twice the pool is *way* better than the rather small portion of throughput you lose for idling the rops while you copy out.





I wouldn't say that. Seems to me that they were designed to allow virtual geometry and texturing for near zero cost. JPEG is a decent format for keeping most of your textures in, when you need some texture you can just issue a DMA command to copy and uncompress it to the live set. LZ is bad for textures but I think it's pretty decent for geometry?

The LZ compressor is 150-200MB/s, the JPEG compressor at ~220-330MB/s.

In terms of usage, AFAICT neither appears to be intended for direct rendering-related functions.


The Eurogamer/DF interview implied that the JPEG feature was primarily to help kinect data transfer.

Maybe it's like this:

2 normal DMA blocks for the 2 Graphic commands & the 2 with special features are for the 2 Compute commands.

 

[Betanumerical]

I wouldn't say that. Seems to me that they were designed to allow virtual geometry and texturing for near zero cost. JPEG is a decent format for keeping most of your textures in, when you need some texture you can just issue a DMA command to copy and uncompress it to the live set. LZ is bad for textures but I think it's pretty decent for geometry?

JPEG is actually a horrible format to keep your textures in, for one you will blow out your cache and memory due to the fact that it only decompresses them and that video card's dont have native decompression in the TEX units for JPEG. For second it was pretty explicitly mentioned that it was there to help with Kinect processing, and that was it really.

 

[scently]

@Gubbi : Thanks a lot for the insight.



I thought that would be the case but when I was reading Humus's post about EDRAM, he says:



But I'm guessing this may also be due to the fact that since EDRAM was so small, I guess you would have to finish your work and move stuff before you can start working on new stuff inside the EDRAM, but since Xbox One has 32MB, this may change, so the GPU wouldn't have to wait for its result to be transferred to main ram. Like you say, this wouldn't be because of the "data move engines" having new features but simply because there's more ESRAM (But not really much, actually)

JPEG is actually a horrible format to keep your textures in, for one you will blow out your cache and memory due to the fact that it only decompresses them and that video card's dont have native decompression in the TEX units for JPEG. For second it was pretty explicitly mentioned that it was there to help with Kinect processing, and that was it really.

That it was intended for use with the Kinect does not mean that it cannot be used for anything else. The interview states that it will be useful for Kinect, no where does it state that that is its sole purpose.

If I recall correctly RAGE uses a variant of JPEG textures for its mega/virtual texture.

 

[Zeross]

That it was intended for use with the Kinect does not mean that it cannot be used for anything else. The interview states that it will be useful for Kinect, no where does it state that that is its sole purpose.

If I recall correctly RAGE uses a variant of JPEG textures for its mega/virtual texture.

Rage is using HD Photo (renamed later JPEG XR but it is more advanced than classical JPEG) to store its texture data on the disc, at load time this data is then decompressed and recompressed to DXT before sending it to the GPU.

 

[dumbo11]

That it was intended for use with the Kinect does not mean that it cannot be used for anything else. The interview states that it will be useful for Kinect, no where does it state that that is its sole purpose.

If I recall correctly RAGE uses a variant of JPEG textures for its mega/virtual texture.

The DME only supports the basic 1994 JPEG.

It seems a useful ability for 'utility' features (loading screens, snapshot images of save files, player avatars etc). It's basically "free" background JPEG decompression - which should be helpful.

 

[TheWretched]

The DME only supports the basic 1994 JPEG.

It seems a useful ability for 'utility' features (loading screens, snapshot images of save files, player avatars etc). It's basically "free" background JPEG decompression - which should be helpful.

Would you really include a hardware feature for stuff like this, though? I can't imagine that.

 

[AlphaWolf]

Would you really include a hardware feature for stuff like this, though? I can't imagine that.

Can you imagine it doesn't cost much? It's still a move engine, it just has added functionality.

 

[dobwal]

Here is a paper from ID from 2006, which may explain why jpeg compression may be more relevant than we think.

http://mrelusive.com/publications/papers/Real-Time-Texture-Streaming-&-Decompression.pdf

 

[fehu]

If in 2006 anyone was so sure that jpg was a better alternative to s3tc, and if it cost so little space, why it hasn't ended up in any api or gpu?
Just this

 

[dobwal]

If in 2006 anyone was so sure that jpg was a better alternative to s3tc, and if it cost so little space, why it hasn't ended up in any api or gpu?
Just this

It ended up in the XB1. And rage uses jpeg XR for texture compression which was released 2011 or five years later.

Its not like megatexture was widely adopted. S3TC may have been the more practical choice for the majority of other devs.

 

[Laa-Yosh]

Any kind of lossy texture compression sucks in my humble opinion. Another thing games will need to overcome sooner or later...

 

[taisui]

Any kind of lossy texture compression sucks in my humble opinion. Another thing games will need to overcome sooner or later...

lossless compression ratio is either bad or computationally expensive though...

 

[Laa-Yosh]

So is practically everything in computer graphics. Like, 3dfx thought 16-bit color is enough and 32-bit is too expensive because it requires two times as many resources.

And then it turned out that even 32 bits are not enough...

 

[taisui]

I think there's a line between noticeable difference or not, I also think there's more ideal situation to utilize the same amount of data. If you can pack 2X the resolution with lossy versus lossless, the lossy would actually look better.