The New and Improved "G80 Rumours Thread" *DailyTech specs at #802*

Discussion in 'Pre-release GPU Speculation' started by Geo, Sep 11, 2006.

Thread Status:
Not open for further replies.
  1. _xxx_

    Banned

    Joined:
    Aug 3, 2004
    Messages:
    5,008
    Likes Received:
    86
    Location:
    Stuttgart, Germany
    And: how will they achieve it?
     
  2. Geo

    Geo Mostly Harmless
    Legend

    Joined:
    Apr 22, 2002
    Messages:
    9,116
    Likes Received:
    213
    Location:
    Uffda-land
    And for your GX2 config, would you need two Sage, or could you get by with one? :smile:
     
  3. Arun

    Arun Unknown.
    Moderator Legend Veteran

    Joined:
    Aug 28, 2002
    Messages:
    5,023
    Likes Received:
    300
    Location:
    UK
    Not really. Assuming 32 bytes/vertex, 100M Vertices/second wouldn't even be 3.2GB/s. Now, please don't tell me next-gen games are going to sue 10x that, because I might just have to kill you then :)

    Uttar
     
  4. _xxx_

    Banned

    Joined:
    Aug 3, 2004
    Messages:
    5,008
    Likes Received:
    86
    Location:
    Stuttgart, Germany
    Hehe, Voodoo2 time all the way! How about one G-chip and two P-chips on one board? So many possibilities... :razz:
     
  5. RoOoBo

    Regular

    Joined:
    Jun 12, 2002
    Messages:
    308
    Likes Received:
    31
    Based on some statistics we got for a paper that is going a be published in a workshop/conference in late October for the 'old' OpenGL games that we can run with our simulator. The bandwidth consumption for 'geometry' (vertex indices and attribute data) is around 4% of the per frame bandwidth. And for those old games the bandwidth requeriment was around 100 MB/frame. Oblivion anb a few other more recent D3D9 games seem to be sending 2x to 4x more indices per frame but we can't simulate them to get 'real' bandwidth usage ... yet.
     
    Jawed likes this.
  6. Jawed

    Legend

    Joined:
    Oct 2, 2004
    Messages:
    10,873
    Likes Received:
    767
    Location:
    London
    There is no bandwidth directly between the two dies, in the scheme I'm suggesting.

    All data from the G die is written to the post-GS cache, from which it is consumed by the setup engine in the P die. That's a basically serial read, running asynchronously with writes from the G die. It's the asynchronisity that requires the cache (as well as the fact that any kind of data amplification in a GS could generate monstrous amounts of data).

    ---

    There is a problem in my hypothesis, to do with the CPU interface. Data from the CPU (vertices, constants, textures, shader code) has to be delivered to either or both GRAM and VRAM. This split means there's either some fancy PCI-Express routing on the card or it means that the PCI Express lanes are split (asymmetrically?) between the two dies, say 4 lanes for G and 12 lanes for P?

    Jawed
     
  7. elroy

    Regular

    Joined:
    Jan 29, 2003
    Messages:
    269
    Likes Received:
    1
    Where's this two dice rumour coming from (besides trumpsiao??)?
     
  8. _xxx_

    Banned

    Joined:
    Aug 3, 2004
    Messages:
    5,008
    Likes Received:
    86
    Location:
    Stuttgart, Germany
    Last year, geo picked it up somewhere though with two chips I think.
     
  9. Geo

    Geo Mostly Harmless
    Legend

    Joined:
    Apr 22, 2002
    Messages:
    9,116
    Likes Received:
    213
    Location:
    Uffda-land
    Umm, NO. Not to my memory anyway. It's a perennial that pops up now and again, because if 3dfx was going to do it, it must have been magic, right? :smile: My "two dice" thing last year was all about what eventually became GX2.
     
  10. elroy

    Regular

    Joined:
    Jan 29, 2003
    Messages:
    269
    Likes Received:
    1
    Hahaha, well you shouldn't joke about it!! :p Us 3dfx supporters are still waiting for the day when the mighty Fear rises up from the ashes!!

    :D
     
  11. Jawed

    Legend

    Joined:
    Oct 2, 2004
    Messages:
    10,873
    Likes Received:
    767
    Location:
    London
    I believe PS3 has read access to vertex data of 4GB/s peak and Xenos 8GB/s.

    Plus, with streamout, any vertex data written and then read by the GPU consumes bandwidth twice.

    But, apart from anything else, my emphasis on GRAM is a balance of space and bandwidth. Which is why DDR (cheap) might be all that's needed for GRAM.

    And, if GRAM is also used to hold constant buffers and post-GS cache then GRAM space becomes more useful, and not dedicated solely to input vertex data.

    Jawed
     
  12. Geo

    Geo Mostly Harmless
    Legend

    Joined:
    Apr 22, 2002
    Messages:
    9,116
    Likes Received:
    213
    Location:
    Uffda-land
    So you're suggesting the GRAM has two sets of memory traces to it, one from each gpu die?
     
  13. ants

    Newcomer

    Joined:
    Feb 10, 2006
    Messages:
    44
    Likes Received:
    3
    Not sure if you covered this in a previous post but how do you think the TMUs (TCPs?) are going to work. The Vertex/Geometry die will need access to the main VRAM to access textures but I don't see it having a bus to the main VRAM as well...

    The two dies could share a bus between them or the Geometry die could write the requests out to its mem and get the data returned by the Pixel die (heavy latency hiding needed here?).
     
  14. Jawed

    Legend

    Joined:
    Oct 2, 2004
    Messages:
    10,873
    Likes Received:
    767
    Location:
    London
    Yeah that's my primary thinking, which clearly complicates things.

    The busses could even be half the widths I've been suggesting, but counting them twice (once per die) producing the 128-bit and 64-bit values being thrown around.

    The alternative, I presume, is a small memory controller chip, which obviously costs money, too.

    Jawed
     
  15. Jawed

    Legend

    Joined:
    Oct 2, 2004
    Messages:
    10,873
    Likes Received:
    767
    Location:
    London
    In my understanding of vertex/geometry shading, the "texture data" used is not shared with the textures being used by pixel shading.

    Also, "texture data" is really a catch-all statement in the context of VS/GS. It effectively includes all the data required to define vertices (a lot of which is just straightforward vertex data). Which is why D3D10 provides a generalised "data fetch" concept (vertex fetch) whose latency is hidden, and which can fetch from multiple streams concurrently (e.g. when performing geometry instancing).

    In SM3 VS, textures are provided logically for the sake of constants. In D3D10, we have constant buffers, which obviate the need to navigate around textures. CBs are dually useful though, both to geometry (vertex) shading and pixel shading. In a sense CB and textures overlap in memory-storage and access patterns. The idea with CBs is that a shader can be re-bound to a different set of constants, on the fly. A bit like choosing which texture to read, or which portion of a texture to read.

    So, the way I see it, "textures" in VS/GS are less important than in the SM3 view of the world (which didn't work well, anyway). So most usage of "textures" will actually constitute CBs or vertex buffer streams.

    Jawed
     
  16. nAo

    nAo Nutella Nutellae
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    4,325
    Likes Received:
    93
    Location:
    San Francisco
    no :)
     
  17. Arun

    Arun Unknown.
    Moderator Legend Veteran

    Joined:
    Aug 28, 2002
    Messages:
    5,023
    Likes Received:
    300
    Location:
    UK
    Uhm. The buffer is also created with CreateBuffer, but that's about where the similarities stop. You still need to use IASetVertexBuffers afterwards, for example. There is no way in hell that "texture data" has become a catch-all term in D3D10, afaik. While a creative IHV could reuse the same functionality to fetch that information as they're using for constant buffers if they think it's more practical or efficient to do so, I do not believe they have any obligation whatsoever to do so.

    That's relatively correct, although I wouldn't say that everything in textures in DX9 VS had to be considered "constants". Just like not everything in D3D10 CBs would have to be considered constants, if you thought about it from a certain pov.

    I perfectly well agree that this is just stupid nomenclature talk, but it can matter that to differentiate what's inside something, and what the container is called. In the case of D3D10, it seems likely that proper support for FP16 texture filtering (and performance characteristics) will be the most likely reason to use textures instead of constant buffers in the VS.


    Uttar
     
  18. joe.latino

    Newcomer

    Joined:
    Sep 19, 2006
    Messages:
    15
    Likes Received:
    0
    What about one bus for graphics (with 512mb of ram) and another to handle physics?
     
  19. joe.latino

    Newcomer

    Joined:
    Sep 19, 2006
    Messages:
    15
    Likes Received:
    0
    ...or for the new AA mode/buffer such xbox360?
     
  20. Jawed

    Legend

    Joined:
    Oct 2, 2004
    Messages:
    10,873
    Likes Received:
    767
    Location:
    London
    Actually I was arguing against thinking of everything as "texture data". D3D10, by introducing CBs and more flexible VB reading methods, lessens the relevance of "texture data" in the VS/GS. Textures were more attractive (as the most flexible option) in SM3 VS - though practically unused - but now most of the time VBs/CBs will suffice.

    That's my interpretation, anyway.

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