Look at the 3 month graph of the stock here. Look at the volume starting on Dec 17. They went from trading less than 500,000 shares a day to approx 5,000,000 a day from the 17th to today.
When there is no external information that would cause the stock to move that much, it is very fishy (as others have said, possibly a pump & dump). These things set off alarms over at the SEC. Unfortunately (or fortunately, if you're in on it), they move verrrryyy sloooowwly.
It is quite possible Infinium had nothing to do with this.
A modeler has to be a complete nitwit to fill up 128MB with verticies Agreed...for now.
Or even 12MB with vertices. . .. Well, now you're calling some pretty important people in the gaming community nitwits. If you believe some of the rumors floating around, Doom 3 will have models with 250,000 polygons...well that's probably bullshit, so let's say they will have 10% of that, 25,000. If we assume they're stripped (so the number of polygons is close to the number of vertices), and each vert contains position, normal, color, and 3 2-d textures (this seems like a valid assumption if the app uses the GPU to do most of the graphics computations), then you've got...
25000 verts * 52 bytes = 1.3MB of vertex data per model! That means if there are 10 different models on screen at once, there will be 13MB of vertex data in memory...not including the surrounding scenery.
If you believe the Unreal 2 rumors of 7000-10000 polys/model, using the same calculation you get 364KB-520KB per model.
This isn't limited to future games. Aquanox supposedly has scenes with 170,000 polygons...that's 8.4MB of vertex data in a game that is on the shelves right now.
Of course keep in mind that textures will fill up a nice chunk of this memory also. So, yes, I agree that 128MB of video memory for now is overkill. But you were suggesting that today's games don't need 32MB and 64MB, and that is clearly false.
It is not like verticies have to be loaded THAT often You're correct in that an app does not have to load data into memory very often, but that's not very relavant. The app loading vertex data into memory does not consume much memory bandwith (assuming it is not a poorly written app).
A GPU needs to read the vertex data from memory EVERY TIME it has to draw it (since it will need to use the data to transform it, light it, clip it, texture it, etc.). This is what I was talking about in my previous post. If you create the example app I was talking about, the app will load the buffer into memory only 1 time...but the GPU will access it every time it draws something.
As a professional game programmer;), I agree with you to an extent. nVidia is "in the lead" when it comes to resolving issues and putting out good drivers, but things have changed at ATI.
In the Rage128 days, when you pointed out a bug to their developer relations people, you were only guaranteed 1 thing...you'd be contacting them again because their 'fixed' driver would break 2 other seeming unrelated things.
With Radeon, it was a bit better, but there were still those "how the fuck could you break that? It's worked fine for months" moments. But now with Radeon8500, for the past year every fixed driver was better than the previous one. I don't think nVidia is winning "hands down" anymore, but they're still winning. Now if only ATI could release the drivers with fewer bugs...
This is noting that having over 32MB of memory has proven to be of NO benefit in benchmarks outside of the occasional 1 or 2 FPS difference (and when you are getting over 100FPS any ways. . ..)...blah...blah...
This isn't true. Textures are not the only things stored in local video memory (i.e. the 32 MB you are talking about). Vertex buffers can also be stored in local video memory. It is quicker for a video card to fetch the vertex data from a buffer in local video memory, than it is to read it from system or AGP memory and feed it to the chip. Simply put, bandwith is less of a bottleneck with local video memory than it is with AGP.
Don't believe me? Try it yourself! There are many example OpenGL and Direct3D apps out there that you could hack (just check out the DevRel sites for both nVidia and ATI). Throw a frame counter in there, and measure it when you create a vertex buffer in system memory, in AGP and local video memory.
Now, you're correct that with "older" apps (pre-2000...heh, only in CS can you call something that's 2-years-old, old), there will be no difference in performance...but that's because those apps were written with 32MB boards as the high performance parts...so they didn't try to use much more than that out of fear of running too slow on what was current hardware. There will be a difference on any graphics-intensive app that was made in the last couple of years.
As games begin to use more complex models (and larger textures), even 128 MB will someday be too small.
Slashdot Mirror
When there is no external information that would cause the stock to move that much, it is very fishy (as others have said, possibly a pump & dump). These things set off alarms over at the SEC. Unfortunately (or fortunately, if you're in on it), they move verrrryyy sloooowwly.
It is quite possible Infinium had nothing to do with this.
Agreed...for now.
Or even 12MB with vertices. . . .
Well, now you're calling some pretty important people in the gaming community nitwits. If you believe some of the rumors floating around, Doom 3 will have models with 250,000 polygons...well that's probably bullshit, so let's say they will have 10% of that, 25,000. If we assume they're stripped (so the number of polygons is close to the number of vertices), and each vert contains position, normal, color, and 3 2-d textures (this seems like a valid assumption if the app uses the GPU to do most of the graphics computations), then you've got...
3 dwords (position) + 3 dwords (normal) + 1 dword (packed color) + 6 dwords (textures 0,1,2) = 13 dwords = 52 bytes per vert
25000 verts * 52 bytes = 1.3MB of vertex data per model! That means if there are 10 different models on screen at once, there will be 13MB of vertex data in memory...not including the surrounding scenery.
If you believe the Unreal 2 rumors of 7000-10000 polys/model, using the same calculation you get 364KB-520KB per model.
This isn't limited to future games. Aquanox supposedly has scenes with 170,000 polygons...that's 8.4MB of vertex data in a game that is on the shelves right now.
Of course keep in mind that textures will fill up a nice chunk of this memory also. So, yes, I agree that 128MB of video memory for now is overkill. But you were suggesting that today's games don't need 32MB and 64MB, and that is clearly false.
It is not like verticies have to be loaded THAT often
You're correct in that an app does not have to load data into memory very often, but that's not very relavant. The app loading vertex data into memory does not consume much memory bandwith (assuming it is not a poorly written app).
A GPU needs to read the vertex data from memory EVERY TIME it has to draw it (since it will need to use the data to transform it, light it, clip it, texture it, etc.). This is what I was talking about in my previous post. If you create the example app I was talking about, the app will load the buffer into memory only 1 time...but the GPU will access it every time it draws something.
In the Rage128 days, when you pointed out a bug to their developer relations people, you were only guaranteed 1 thing...you'd be contacting them again because their 'fixed' driver would break 2 other seeming unrelated things. With Radeon, it was a bit better, but there were still those "how the fuck could you break that? It's worked fine for months" moments. But now with Radeon8500, for the past year every fixed driver was better than the previous one. I don't think nVidia is winning "hands down" anymore, but they're still winning. Now if only ATI could release the drivers with fewer bugs...
This isn't true. Textures are not the only things stored in local video memory (i.e. the 32 MB you are talking about). Vertex buffers can also be stored in local video memory. It is quicker for a video card to fetch the vertex data from a buffer in local video memory, than it is to read it from system or AGP memory and feed it to the chip. Simply put, bandwith is less of a bottleneck with local video memory than it is with AGP.
Don't believe me? Try it yourself! There are many example OpenGL and Direct3D apps out there that you could hack (just check out the DevRel sites for both nVidia and ATI). Throw a frame counter in there, and measure it when you create a vertex buffer in system memory, in AGP and local video memory.
Now, you're correct that with "older" apps (pre-2000...heh, only in CS can you call something that's 2-years-old, old), there will be no difference in performance...but that's because those apps were written with 32MB boards as the high performance parts...so they didn't try to use much more than that out of fear of running too slow on what was current hardware. There will be a difference on any graphics-intensive app that was made in the last couple of years.
As games begin to use more complex models (and larger textures), even 128 MB will someday be too small.