Nvidia GT300 core: Speculation

Discussion in 'Architecture and Products' started by Shtal, Jul 20, 2008.

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

    Regular

    Joined:
    Jan 22, 2003
    Messages:
    306
    Likes Received:
    0
    How many people bought into the hype and purchased cards based on that? What was delivered? How far would all this have progressed had they not tried to monopolize the game physics and simply worked towards an open standard? How was physics good for anyone, except for possibly nVidia?

    Edit: Didn't read til the end of the thread!
     
    #2421 Chris123234, Sep 25, 2009
    Last edited by a moderator: Sep 25, 2009
  2. ChrisRay

    ChrisRay <span style="color: rgb(124, 197, 0)">R.I.P. 1983-
    Veteran

    Joined:
    Nov 25, 2002
    Messages:
    2,234
    Likes Received:
    26
    You know Rys.. I havent seen on IM in ages.. :(
     
  3. MfA

    MfA
    Legend

    Joined:
    Feb 6, 2002
    Messages:
    6,757
    Likes Received:
    470
    A few weeks? What's going to change in a few weeks? 2H 2010 might be Charlie FUD, but what is the chance that AMD would point out of the ballpark and tell everyone they were going to be first with just a 6 week lead? Of all the information available I still find AMD's 100% certainty of being first the greatest reason to not expect anything before Christmas (well product wise at any rate).
     
  4. trinibwoy

    trinibwoy Meh
    Legend

    Joined:
    Mar 17, 2004
    Messages:
    10,428
    Likes Received:
    426
    Location:
    New York
    Since when does the definition of first include a > 6 week lead?
     
  5. INKster

    Veteran

    Joined:
    Apr 30, 2006
    Messages:
    2,110
    Likes Received:
    30
    Location:
    Io, lava pit number 12
  6. trinibwoy

    trinibwoy Meh
    Legend

    Joined:
    Mar 17, 2004
    Messages:
    10,428
    Likes Received:
    426
    Location:
    New York
    He's referring to his own speculation here.

     
  7. MfA

    MfA
    Legend

    Joined:
    Feb 6, 2002
    Messages:
    6,757
    Likes Received:
    470
    Trinibwoy ... it doesn't, but when you are looking into the future by 4 months and a lot can still go wrong it's a rather small margin of error.
     
  8. trinibwoy

    trinibwoy Meh
    Legend

    Joined:
    Mar 17, 2004
    Messages:
    10,428
    Likes Received:
    426
    Location:
    New York
    Sure, but Rys isn't necessarily referring to GT300 showing up at Newegg. There are lots of other tidbits that could leak or be released before that.
     
  9. nAo

    nAo Nutella Nutellae
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    4,325
    Likes Received:
    93
    Location:
    San Francisco
    Regarding the MIMD rumour, it's quite unlikely that GT300 has an instruction decoder and scheduler (+ I$?) per SP. Perhaps it refers to be able to have some sort of task parallelism while running in compute mode.
     
  10. trinibwoy

    trinibwoy Meh
    Legend

    Joined:
    Mar 17, 2004
    Messages:
    10,428
    Likes Received:
    426
    Location:
    New York
    Ever since I read that dynamic warp formation paper, whenever I hear about MIMD on GPUs I always assume it's still SIMD hardware but MIMD from the view of the running program. I've never really understood why the data sent to a SIMD has to be from the same warp. The SIMD doesn't care does it?

    Could they practically extend GT200's scoreboarding mechanism to simply collect bundles of "ready" threads and their associated operands from any/all running warps? It would probably require some sort of operand buffering mechanism and trickier prioritization but it doesn't sound much different from what they're doing now anyway.
     
  11. nAo

    nAo Nutella Nutellae
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    4,325
    Likes Received:
    93
    Location:
    San Francisco
    There are two different arguments mixing here. One thing is being able to re-converge your threads and pack in a warp only (or mostly..) threads that share the same IP. Another thing is being able to schedule instructions from diverged control flow or even different programs into the same warp. The latter is way more complex (and requires more instruction decoders)
     
  12. MfA

    MfA
    Legend

    Joined:
    Feb 6, 2002
    Messages:
    6,757
    Likes Received:
    470
    As long as there is enough local shared memory to accommodate all the warps I don't see why it should ... control flow gets less coherent, but how much would that matter with shaders used at the moment?
     
  13. MfA

    MfA
    Legend

    Joined:
    Feb 6, 2002
    Messages:
    6,757
    Likes Received:
    470
    BTW, what is already accumulated in warps at the moment? Are only vertices/fragments of a single drawcall combined? Or will it try to see what changes in between drawcalls?
     
  14. trinibwoy

    trinibwoy Meh
    Legend

    Joined:
    Mar 17, 2004
    Messages:
    10,428
    Likes Received:
    426
    Location:
    New York
    Could you expand on that a bit? Why is packing by PC easier than packing by instruction?
     
  15. nAo

    nAo Nutella Nutellae
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    4,325
    Likes Received:
    93
    Location:
    San Francisco
    Packing by PC *is* packing by instruction (not the other way around though :) ).
    What's harder is to pack different instructions in the same warp, as you need to improve, among other things, your instructions decoding rate.
     
  16. dnavas

    Regular

    Joined:
    Apr 12, 2004
    Messages:
    375
    Likes Received:
    7
    I'd be concerned about operand fetching as well.

    Does this get easier if your instruction set is simplified? I don't recall the exact details, but it seems like the instruction set is already pretty sparse, with MADD being the odd outlier and operand types (int16 vs. int32 vs. float vs. double?) contributing. Do we gain much by splitting the MADD? At some cost to operand bandwidth, one could gain greater use of the two math units, and it is a simplification (no more triple operand fetches, fewer instructions to support).
     
  17. trinibwoy

    trinibwoy Meh
    Legend

    Joined:
    Mar 17, 2004
    Messages:
    10,428
    Likes Received:
    426
    Location:
    New York
    No, I'm saying to pack the same instruction but not necessarily the same PC. A PC specifies not only an instruction, but an instruction at a specific point in the program. Not sure why you would need a faster decoding rate if you're packing by decoded instruction. There'll be more latency between decoding and execution but that shouldnt matter.

    Edit: I'm assuming here that instructions and operand addresses are kept separate. If that's not the case then ignore me :)
     
  18. nAo

    nAo Nutella Nutellae
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    4,325
    Likes Received:
    93
    Location:
    San Francisco
    You make the assumption that you can decode more instructions without stalling execution, but that works only if you increase the instructions decoding rate (unless you also want to assume that current parts are unbalanced..)
     
  19. trinibwoy

    trinibwoy Meh
    Legend

    Joined:
    Mar 17, 2004
    Messages:
    10,428
    Likes Received:
    426
    Location:
    New York
    Ok, now I understand what you're saying. :oops: But that investment could be amortized over wider SIMDs or something (which they probably need to do regardless to avoid AMD completely running away with flops/mm).
     
  20. nAo

    nAo Nutella Nutellae
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    4,325
    Likes Received:
    93
    Location:
    San Francisco
    Well, if you make it wider, than you need even more decoders to able to fill a bigger warp with useful work to do :)
     
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...