Announcement

Collapse
No announcement yet.

Did you see this??

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Like the g200 <--->g400 ?

    Comment


    • #17
      No, I have to disagree with you LAMFDTK - The G400 is not what the G200 was meant to be - the G200 with the current drivers is what the G200 was meant to be a year ago. It's like the TNT <--> TNT2 and the S3 Savage3D <--> (Um, anyone?)

      ------------------
      Cheers,
      Steve

      "The chances of anything coming from Mars, are a million-to-one", he said.

      Comment


      • #18
        it's gonna be fun to easedrop on one of those "gee whores" forums and read the nightmares that people will have with drivers for a card that's not ready for primetime

        ------------------
        PIII-500mhz @ 620 ! with an Abit BE6 mobo
        128mb pc-100
        Mill G400 (YAHOO!!!) 32mb @ 165/205 with MGATweak), PD 5.30 & bios 1.5-22
        Maxtor 14.3 gb Uata66 hdd
        SB Live!
        Winblows 98se & DX7
        32 lbs. of fans, heatsinks and aluminum ductwork
        3DMark Result 5954.69 3DMarks
        Synthetic CPU 3D Speed 9325.69 CPU 3DMarks
        Rasterizer Score 2791.72 3DRasterMarks
        Game 1 - Race 65.07 FPS
        Game 2 - First Person 54.89 FPS
        Fill Rate 268.79 MTexels/s


        System 1:
        AMD 1.4 AYJHA-Y factory unlocked @ 1656 with Thermalright SK6 and 7k Delta fan
        Epox 8K7A
        2x256mb Micron pc-2100 DDR
        an AGP port all warmed up and ready to be stuffed full of Parhelia II+
        SBLIVE 5.1
        Maxtor 40g 7,200 @ ATA-100
        IBM 40GB 7,200 @ ATA-100
        Pinnacle DV Plus firewire
        3Com Hardware Modem
        Teac 20/10/40 burner
        Antec 350w power supply in a Colorcase 303usb Stainless

        New system: Under development

        Comment


        • #19
          The G200 and G400 are different parts - DualHead for one, 32MB RAM support for second, the new memory scheme for third, and don't forget the nifty fan on the MAX.

          The TNT2 is just a TNT with a revamped core that can make it up to higher speeds. They didn't add any new features to the TNT2 OR the Ultra OR the new TNT2-A (.22 micron core).

          Drivers are one thing - if it takes a year to get drivers working *cough* Riva 128 OpenGL *cough*, that's one thing. That's not the case with nVidia. Downloading drivers is free. Replacing hardware isn't.
          The pessimist says: "The glass is half empty."
          The optimist says: "The glass is half full."
          The engineer says: "I put half of my water in a redundant glass."

          Comment


          • #20
            Ignoring some of the flaming crap above...

            About vertex buffers:
            The most simple way for a program to draw triangles in 3D (OpenGL) is as follows:

            glBegin(GL_TRIANGLES);
            glVertex3f(0.0f, 0.0f, 0.0f);
            glVertex3f(1.0f, 0.0f, 0.0f);
            glVertex3f(0.0f, 1.0f, 0.0f);
            glVertex3f(2.0f, 0.0f, 0.0f);
            glVertex3f(2.0f, 0.0f, 0.0f);
            glVertex3f(2.0f, 1.0f, 0.0f);
            glEnd(GL_TRIANGLES);

            Now I have drawn two polygons. This way is very slow because everytime the program gives coordinates which have to be transferred via AGP/PCI to the 3D card.

            Using vertex buffers you combine several vertexes and process them as a group.

            When no T&L is onboard, this T&L calculations must be done in system memory by the CPU. After T&L that data is sent to the 3D card. So for every frame the T&L must be done by the CPU, so the vertex data stays in system memory and is sent every frame over the AGP/PCI bus.

            When T&L is onboard, the NOT TRANSFORMED vertex data is sent over AGP/PCI, then T&L is applied on the 3D card. Next frame, the data doesn't have to be sent again over AGP/PCI, since it is already in video mem. So then it is simply T&L, T&L, T&L...

            No T&L onboard would mean, T&L, send, T&L, send... You get the picture.

            So as you can see bandwidth requirements are much less.

            Comment


            • #21
              I know Ice I'm just being a Dick...

              ------------------
              PIII-450@504, 128 HDSRAM, Asus P3BF, G400/32, SBLive!, Nokia 447Xi 17", oh yea, a nice floppy drive

              Comment


              • #22
                Maybe, LAM, but you're still a Tribes Player! Hoocha! Stand Proud! *high five mee-yah!*

                ------------------
                ~Godzilla:~
                • ASUS P2B-LS motherboard, BIOS rev.1010;UW/SCSI o/b
                • Intel P-III 500 mHz; 64 megs PC-100 RAM
                • Millenium G400MAX AGP w/Powerdesk 5.25
                • and
                • Diamond Monster 3D {Voodoo2 12 meg}
                • NEC E1100 20" monitor
                • 6.5 gig UW/SCSI HD
                • SB Live! w/ current driver set {October}
                • WACOM artpad-II and generic mouse
                • SCSI scanner, JAZ drive, printer, yada yada
                • WIN95 OSR2, still going!
                • 2 dogs, 5 cats, 2 ferrets, iguana, box turtle, various fish, 3 tarantulas


                ~Godzilla:~
                • ASUS P2B-LS motherboard, BIOS rev.1010;UW/SCSI o/b
                • Intel P-III 500 mHz; 64 megs PC-100 RAM
                • Millenium G400MAX AGP w/Powerdesk 5.25
                • and
                • Diamond Monster 3D {Voodoo2 12 meg}
                • NEC E1100 20" monitor
                • 6.5 gig UW/SCSI HD
                • SB Live! w/ current driver set {October}
                • WACOM artpad-II and generic mouse
                • SCSI scanner, JAZ drive, printer, yada yada
                • WIN95 OSR2, still going!
                • 2 dogs, 5 cats, 2 ferrets, iguana, box turtle, various fish, 3 tarantulas

                Comment


                • #23
                  Shazbot! I need an APC pick-up !

                  Comment


                  • #24
                    I know it´s really not THAT interesting, but I took a little deeper look at bandwidth and T&L and wanted to share it with frank, so sorry if the others get boared.

                    Regarding vertex-buffers on or off card, I asked because both approaches are thinkable and both have their advantages and disadvantages.
                    For now I´d just like to cover the issue of local(the card) vertex-buffer in regards to T&L.

                    Assuming we have a scene with about 100000 tris (no strips or fans for now) which should be a target for new games based on T&L.

                    This results in a vertex-buffer(GLdouble) of 2,4 MB size transferred once to the card.
                    Now for every frame (assume sustained target fps=40) a transformation scheme has to be loaded via AGP (size,bandw. irrelevant)
                    So now the GPU first has to store the transformation scheme in local mem. They probably integrated caches for those transforms as well but for sure not large enaugh to keep all transformations onchip.

                    Here I start counting the bandwidth of the upcoming GPU-work:

                    For every sub-scheme of transformations (these schemes must be subtiled in order to allow hirachical usage on "objects" rather than unique or global triangles) the depending vertrice(s) will be loaded to GPU and the appropriate scheme is used (ie trans,move,scale,rotate) and the result is written to local mem. This repeats unless there are no more transformations to be worked on. After this the GPU displays the resultscene ( the normal tri-setup and rasterizer stuff that we already know ).

                    I haven´t integrated gpu execution times in the calculation as this does not effect bus-bandwidth in the case of todays decoupled memorybuses.I´m also ignoring all the bandwidth that comes through loading the transforms.

                    1. The whole vertex-buffer needs to be read by the GPU at least twice. First as I assume that the scene is at least rotated or moved every frame. Second as the transformed buffer goes to the rasterizer(s).
                    4,8MByte per frame

                    2. Scenes usually contain interacting objects . I´ll assume that we have 10 moving objects with approx 5000 tris costing us at least
                    1,1MByte per frame


                    So that´s 5,9 MByte per frame and that means
                    with a sustained fps of 40 we´re likely to suffer a 236 MByte / sec bus-traffic only (!!!) due to T&L and that IS alot although
                    the Geforce maxes 2,4 Gbyte/s in the normal
                    SDRAM config. But than again, this clearly shows that apart from bandwidth-issues of todays 3d-cards in resolutions higher 1024*768*32, T&L further increases the need for higher bandwidth. And GeForce doesn´t have enaugh of it if you ask me. (Altough it´s still the most powerful 3d-gaming-card available)


                    bye ... Bjoern

                    BTW: After I wrote this thing, I took a quick look at the news ... and I couldn´t believe it but SharkyExtreme has an article up that covers this issue . They also say that T&L may hit the bus up to 0,5GByte/sec.

                    Comment

                    Working...
                    X