Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Silicon Graphics, Inc. (SGI) -- Ignore unavailable to you. Want to Upgrade?

To: Woody_Nickels who wrote (6126)	6/2/1999 10:17:00 AM
From: Alexis Cousein	Read Replies (1) \| Respond to of 14451

> Doesn't the VW320 handle large amounts of main memory as video > buffers It can. You actually reserve a chunk of memory for the gfx subsystem (as large as you want), and then you can use that as: -framebuffer -accumulation buffer -off-screen graphics buffers (pbuffers) -texture memory on an IRIX UMA machine (aka Silicon Graphics O2), you can allocate this dynamically, but NT 4.0's architecture doesn't really let you do that, hence the split at boot. > (?) and move the data into the video/graphics processor in one > piece? If you decide to move things around this gfx memory Cobalt can use the full bandwidth to memory, without using up any bandwidth on the Intel Frontside bus. E.g., there aren't a lot of systems that can use large textures, and lots of them, and achieve the fill-rates that a 320 can in the NT space (though SGI could probably sell you an Onyx2 as well ;) ). Of course, there are also e.g. OpenGL extensions to avoid having to copy stuff around -- you can e.g. render something in an off-screen buffer, then use that as a texture source, and Cobalt will use the pbuffer directly for texturing. That's one way of doing 2x2 supersampled anti-aliasing.